On Wed, 24 Sep 2014, Markus Stenberg wrote:
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.
How does multicast work at all with replay-protection? I am not a crypto
guy, but is there any way of doing multicast and not have this problem?
Is there something else that'll work as transport layer security for
multicast, or should we send a request for the IETF leadership to
investigate if this is something that needs to be developed?
I just can't help seeing this problem popping up all over the place and
everybody solving it by writing their own code and doing their own
implementation. IPSEC isn't widely used because it doesn't have ports so
it can't be NATed (so its now run over UDP to workaround that problem) and
also because key management is hard because keys are managed by the
operating system and not by the application?
So, do we need a mix between IPSEC and TLS that can be done on a
per-application level, but it's still a generic framework so that someone
can develop generic code that projects like HNCP can use, for instance by
linking to libraries?
--
Mikael Abrahamsson email: [email protected]
_______________________________________________
homenet mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/homenet
