[Openswan Users] DNSSEC opportunistic encryption: just a beautiful dream?
darkbasic at linuxsystems.it
Sun Mar 11 16:18:49 EDT 2012
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 :)
More information about the Users