tech-net archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: IPsec vs ssh



On 11/Nov - 17:11, Robert Elz wrote:
>     Date:        Mon, 11 Nov 2013 07:19:11 +1100
>     From:        Darren Reed <darrenr%NetBSD.org@localhost>
>     Message-ID:  <527FEA3F.2070301%netbsd.org@localhost>
> 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.)

VPN is probably the 'classic usage' of IPSEC, through it is completely
possible to protect only specific port for specific IP, as shown by
Darren.

If you want to use a programming interface instead of setkey, you can
use the function ipsec_set_policy (3) from libipsec which takes the same
kind of input than setkey (8). Some low-level API exists, but are not
documented. Dig into libpfkey.h. The protocol used if PFKEY, as
described in RFC 2367.

Hope it helps.

Attachment: signature.asc
Description: Digital signature



Home | Main Index | Thread Index | Old Index