Re: IPsec vs ssh

[Robert Elz <kre%munnari.OZ.AU@localhost>]

    Date:        Mon, 11 Nov 2013 07:19:11 +1100
    From:        Darren Reed <darrenr%NetBSD.org@localhost>
    Message-ID:  <527FEA3F.2070301%netbsd.org@localhost>

  | If I change "icmp" to "any", any currently established ssh
  | sessions stop working.

Just to be sure, and ask the obvious question, you are adding the spdadd
policies at both ends (with the obvious address changes etc) at the same
time, right?

  | To be more precise, I don't want ssh packets to be handled
  | by IPsec because (a) there's no need to encrypt encrypted
  | data

Until you get it working, I think I'd ignore this, and your other
reason, and just make ssh work over ipsec to show that it can be done
the same as any other tcp client application.  Once you have overcome
whatever problem appears to be preventing that working, then I'd start
looking at avoiding ipsec for ssh (which unless hiding the fact that you're
using ssh is an objective, does look like it would be overkill.)

  | this is the policy that I want to deploy
  | and it seems like it should be possible. Question is,
  | why can't I?

The real reason reason I'm here, is that it seems that ipsec knowledgable
people are (probably) reading this thread, and I have long had a similar
(but even more specific) ipsec application in mind, which I also have no
idea at all how to achieve, but which, at least to me, seems like it should
be possible (for ipsec as it is specified, whether or not it is as
implemented).

That is, I'd like to be able to enable ipsec on a single already established
tcp (or udp) connection (for udp, imagine as much an equivalent of a
connection as makes sense for this) (that is, on the IP packets that
support the connection, and not (by virtue of this request) on any others
between the same, or different, peers.

For the purposes of this question, you can assume that there are no issues
with either synchronisation of the enabling of ipsec, nor of keying.
(For the actual application I have in mind, that's true, but it is too
convoluted to bother explaining here.)   For the purpose of this message,
assume that the applications simply know to enable ipsec immediately after
the TCP 3 way handshake has completed, or after the first (one) packet
is sent/received (before the first reply) for UDP, and that the key is N bits
of all 0's (where N is whatever is appropriate for whichever encryption
algorithm is selected, which the applications will simply know in advance).
That is, you can assume for this that what I really want is neither secrecy
nor authentication, but just a much stronger checksum algorithm than TCP
offers, and by using IPsec with a constant key, that's more or less what
I get (silly idea, but not absurd, if we assume that the application protocol
cannot be altered in any way, and that it simply assumes that TCP (or UDP)
is good enough - but I want better data accuracy that that.

So, given I have a connected (TCP or UDP) socket, what ioctl's do I need
to emit to get ipsec enabled on exactly this one connection (obviously
I know the port numbers and addresses of both ends, and which protocol I
am using ...)  ?

For this purpose, I obviously want to do it directly from the application,
not go fiddling with ipsec configuration files, setkey commands, or anything
like that.

That is, if this is possible at all?   Everything I've seen in the ipsec
documentation seems to assume that I want to use it for a VPN style use,
where (almost) all communications between two end points are to be protected.
There is however, nothing I can see in the base design of ipsec that
requires that model (allows it, certainly, but not requires.)

Any hints?

kre