On Fri, 19 Sep 2014, Mark Townsley wrote:
My own experience attempting to use IPsec as an add-on security solution (a.k.a. "pixie dust) for a protocol isn't all that positive. We tried that with L2TP, and in the process failed to kill off PPTP on windows clients. I can't tell you how many times over the years I've had to point people to the Windows Registry setting to disable IPsec with L2TP. OSPFv3 is another one where I get complaints about requiring IPsec. So, I agree with Ted; We should be wary of falling into the trap of using IPsec just because it is there.
As far as I can see, there are 2 ways of doing security. Either each protocol does its own security completely (both auth and encryption), or we have generic ways of doing these. The generic ways can be either a new protocol and method, or a method that any protocol can use, so at least the method is standard.
What I have seen so far, it seems most implementations are doing things from scratch, but with known methods, but with little code re-use?
What I would like to see is an implementation that is generic, but perhaps where the information is carried over a lot of different protocols, for instance HNCP, ND and others.
There is no security and zero configuration at the same time. It just doesn't work. I still think we need user intervention to set policy for each device. "What trust do I put in this device and what role should it have" is something the user has to answer. The result of this answer sets policy for the devices in relation to this new device. This has to be really simple and easy to use. Since a lot of people have smartphones nowadays, I still think that the device popping up in an App they have, and then configuring it there, is the best way. Perhaps in combination with some kind of device key fingerprint using QR codes or alike to really make sure this is the device you're trying to configure policy for.
So my proposal is that we make HNCP capable of using several methods, one is unsecure, one is secure by means of a shared secret, and then add other optional methods using PKI that would enable the above mentioned "accept each device manually" more secure way.
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?
-- Mikael Abrahamsson email: swm...@swm.pp.se _______________________________________________ homenet mailing list homenet@ietf.org https://www.ietf.org/mailman/listinfo/homenet
