----- Forwarded message from Nico Williams <nico@cryptonector.com> ----- Date: Thu, 12 Sep 2013 14:04:08 -0500 From: Nico Williams <nico@cryptonector.com> To: Eugen Leitl <eugen@leitl.org> Cc: cryptography@randombit.net, Cryptography List <cryptography@metzdowd.com> Subject: Re: [cryptography] very little is missing for working BTNS in Openswan User-Agent: Mutt/1.5.21 (2010-09-15) On Mon, Sep 09, 2013 at 10:25:03AM +0200, Eugen Leitl wrote:

Just got word from an Openswan developer:

" To my knowledge, we never finished implementing the BTNS mode.

It wouldn't be hard to do --- it's mostly just conditionally commenting out code. " There's obviously a large potential deployment base for BTNS for home users, just think of Openswan/OpenWRT.

Note: you don't just want BTNS, you also want RFC5660 -- "IPsec channels". You also want to define a channel binding for such channels (this is trivial). To summarize: IPsec protects discrete *packets*, not discrete packet *flows*. This means that -depending on configuration- you might be using IPsec to talk to some peer at some address at one moment, and the next you might be talking to a different peer at the same address, and you'd never know the difference. IPsec channels consist of ensuring that the peer's ID never changes during the life of a given packet flow (e.g., TCP connection). BTNS pretty much requires IPsec configurations of that make you vulnerable in this way. I think it should be obvious now that "IPsec channels" is a necessary part of any BTNS implementation. Nico -- ----- End forwarded message ----- -- Eugen* Leitl <a href="http://leitl.org">leitl</a> http://leitl.org ______________________________________________________________ ICBM: 48.07100, 11.36820 http://ativel.com http://postbiota.org AC894EC5: 38A5 5F46 A4FF 59B8 336B 47EE F46E 3489 AC89 4EC5