[Openswan Users] DNSSEC opportunistic encryption: just a beautiful dream?

[Niccolò Belli]

Il 11/03/2012 18:46, Paul Wouters ha scritto:
> Right, this works in the same way, as long as the gateway is also the
> resolver. However, there is a layer of NAT here. The tunnel would be a
> host to host tunnel between Y and B, and A would get SNAT'ed to B before
> going through the tunnel to Y. A difficulty here is if A actually
> supports this natively, it will ALSO try to setup a tunnel to Y,
> which\likely won't work because there is already a tunnel for "B" on Y.

True, we all know how bad NAT is and there is no real room for 
improvements (except if B acts like a man in the middle and fools A 
establishing the SA in place of Y). I don't even consider IPv4 anymore 
and I am much more interested in deploying such a scenario with IPv6 
connectivity, unfortunately there are still some showstoppers:

1) No bind support.
2) The validating resolver isn't really in B, it is in another local 
network behind B (not the same network of the clients anyway).

There is a solution which may solve both the problems: B intercepts DNS 
calls, asks for the IPSECKEY record and establish the ipsec SA. It would 
not require interaction (and so a specific compatibility) with the 
resolver and you can place the resolver everywhere (as long as it isn't 
OE capable). It sounds like a bad hack I know, that's why I told the old 
reverse dns approach was much more versatile: you just need to place 
openswan in B.

While I like the new approach I'm still convinced the right way to do 
things would be through reverse dns calls. Anyway, as fedoraproject.org 
just showed, things are rarely done in the right way :)

Cheers,
Niccolò