Le 2014-02-24 11:15, Fernando Gont a écrit : >> You should document all usage cases >> and agreement on the security risks imposed, together with a balanced >> view on how to address those risks. > > This seems to be out-of-scope. i.e., our document is on capabilities as > opposed to discussing security architectures (i.e., this document is not > meant to answer "centralized or distributed?", "what's the most secure > architecture", etc.).
Agreed. Personally, I'd be interested in a document for firewall implementers explaining how to do it correctly and how to cause minimal breakage. A little bit like the BEHAVE guidance for NAT implementers. For firewalls, you could talk about how to use ICMP / TCP RST / drop correctly and what the tradeoffs are, how to do L2 stuff, how to do stateful stuff, how to inspect packets and deal with extensions headers intelligently, what are good timeout values, etc. The goal being to define a filtering function that behaves well on the Internet. Ideally that guidance would apply to all kinds of settings: ISP, enterprise, CPE, single host, etc. That RFC could be used as a baseline for RFPs as well. Simon -- DTN made easy, lean, and smart --> http://postellation.viagenie.ca NAT64/DNS64 open-source --> http://ecdysis.viagenie.ca STUN/TURN server --> http://numb.viagenie.ca _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
