On 24.9.2014, at 8.56, Mikael Abrahamsson <[email protected]> wrote: > On paper it still seems IPSEC should be able to do this (I mean, isn't this > what Microsoft does with Direct Access, ie run IPSEC and have keys handled by > AD? From a theoretical level, it seems bad that we can't implement generic > security and then let other protocols run on top of that. What is it that > IPSEC is lacking? Is it the key/auth exchange that is lacking?
Big problem with IPsec + ‘any protocol’ is that it does not work _that_ well with multicast. Certainly, you can use manually keyed (static) IPsec SAs (although in case of Linux, out of the box, it does not work either but is easy to patch), but they have somewhat worse security properties, main things being lack of replay protection and fixed key used for crypto. You cannot really bootstrap them from anything else than that, though, which is a problem.http://tools.ietf.org/wg/msec/ attempted to address this, but I have not really seen it in the wild as open source (for example, no support in StrongSwan[1]). (Cisco did GDOI in e.g. DMVPN at least.) -Markus P.S. I’d like to be proven wrong on this front - ‘just use IKE+IPsec’ is a good story, but without equivalently good (in terms of what is used for auth*, and how secure it is) support for both unicast and multicast, I do not really think it applies as-is to anything that makes decisions that matter also based on multicast packets. [1] https://wiki.strongswan.org/projects/strongswan/wiki/IpsecStandards _______________________________________________ homenet mailing list [email protected] https://www.ietf.org/mailman/listinfo/homenet
