hi Brian, all, On Oct 9, 2013, at 1:02 AM, Brian E Carpenter <[email protected]> wrote:
> On 09/10/2013 11:23, Peterson, Jon wrote: >> Moving the bar from MTI to mandatory-to-use (can we overload the acronym >> MTU?) goes beyond just questions of policy, and into the questions of how >> we build consensus and what the shapes the output of our engineering >> process. > > How about mandatory-to-be-on-by-default and mandatory-to-have-an-off-switch? It doesn't seem to me that going any further is practical; declaring something "mandatory to use" especially in absence of a deployment certification program (and I hope we can agree we don't want to go there) essentially invites people to ignore you, Mandatory default (beyond MTI) would at the very least have the effect of moving testing "with security" up the priority list during interop testing. Case in point: IPFIX. SCTP + DTLS is MTI; TCP and UDP transports (each with TLS/DTLS) are optional. The situation is much better now, but at the time when the Proposed Standard revision (RFC 5101) was first undergoing interop testing, doing a compliant open-source implementation pretty much meant trying to hack working DTLS over SCTP into OpenSSL or similar, or worse, rolling your own DTLS from scratch. So the interop testing ran through all the features "insecure", then treated security as an afterthought. At the first one I took part in, we only managed to interop TCP+TLS. The temporary guidance we gave in this situation (RFC 5153): use SCTP on dedicated or otherwise-secured (e.g. IPsec tunnels) for new installations inside a trusted perimeter, use TCP+TLS for IPFIX on the open Internet until SCTP+DTLS works. Since NetFlow ran over UDP (very convenient especially for mostly-hardware implementations of exporters) and the NetFlow community is used to the myriad ways in which NetFlow over UDP can fail, we defined a UDP (and UDP+DTLS) binding for IPFIX as well. Now, SCTP has its own problems on the open Internet, and we'll probably end up defining IPFIX over SCTP over UDP+DTLS as an alternate binding to get around the dodgy middleboxes; that's a separate issue. But I do think part of the problem is that we did not specify default-on for security. The result? Most IPFIX I know of runs unsecured on UDP on local network links which are presumed secure since they're inside the perimeter and don't touch the Big Scary Internet, because that's what you get when you take the box out of the box and plug it in. Making mandatory default security work is difficult in current practice, in that it adds key management to the out-of-box experience, and there is very little if anything that is fun about key management. Moving toward opportunistic encryption here would be a significant improvement: it guarantees less than "doing it right", but much more than nothing, and in a lot of cases nothing is what we have. Cheers, Brian
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
