On Tue, Jul 03, 2018 at 03:06:34PM +0100, Stuart Henderson wrote: > > If that is the case, what is going on here is unacceptable. > > > > That is exactly what was intended with the 2012/11/29 commit. > This is the scenario it tries to avoid: > > - user has a vpn for 0.0.0.0/0 on a host with the intention of > diverting all traffic from that machine over VPN > > - at some point later, host gains an IPv6 address and default > route > > - now there is traffic to v6-capable hosts which is sent directly > and in the clear rather than via vpn > > Whether it's acceptable or not I can't say, but it's working exactly > as expected/advertised. If this is changed, we should probably add > "flow esp out from ::/0 to ::/0 type deny" to examples/iked.conf > with some description. > >
A dual-homed host should not have IPsec on v4 and "open" v6 at the same time; the leakage is a real risk. I did add it intentionally; we've discussed it in depth when the problem was reported by Gont. In other words: I don't think that people spend much or any thought on the problem when they enable v4-IPsec on a dual-homed host; they would be open for the attack. Putting this as a note into /etc/examples/iked.conf and not turning it on by default is almost useless. My suggestion: 1. Fix the manpage as suggested (but add the RFC in the STANDARDS section) 2. Add a log_debug() (only visible when running iked in foreground/verbose) 3. Fix iked to really only load the deny flow if no IPv6 is configured! The 3rd one used to be the case: iked only installed the "deny-all-IPv6" flow when there was no IPv6 configured in iked.conf. This seems to be broken as my tests still get the deny flow even if I add an IPv6 flow or peer configuration in iked.conf. It is a real bug that has to be fixed. I can look at it at the hackathon if nobody beats me to it. We can also think about tweaking the semantics, like only blocking non-local traffic, but this is very difficult to achieve. Reyk
