Hi, Brian, Thanks so much for your feedback! Please find my comments in-line...
On 07/14/2014 01:29 AM, Brian E Carpenter wrote: > > Thanks for starting this work. > > First, a general point. I think you need to be much clearer in the > Introduction that there are rules in RFC 7045 that need to be followed. > The advice that you give later is all conditional on those rules being > applied first. In particular, 7045 has this requirement: > >> If a forwarding node discards a packet containing a standard IPv6 >> extension header, it MUST be the result of a configurable policy and >> not just the result of a failure to recognise such a header. This >> means that the discard policy for each standard type of extension >> header MUST be individually configurable. We will try to make this explicit -- but yes, we were assuming this (the filtering rules not being the result of failure to recognise a header, etc.). > The default configuration > SHOULD allow all standard extension headers. > > There is also a reminder in the Security Considerations that this > requirement applies to firewalls. You need to be explicit, perhaps, > that you are advising operational configurations, not changing the > implementation defaults required by RFC 7045. Good point. FWIW, we were kind of hesitating between doing an IPv6 version of RFC7123, and writing a document aimed at firewalls. I'd argue that this one is mostly an IPv6 version of RFC7126 -- i.e., much more permisive than what a firewalls document would be. > It was out of scope for 7045, but IMHO we should have the same rule > for IPv6 options: provide a configuration switch (allow/drop) for > each one, and a reasonable default. You could certainly suggest > that. I'd generally agree with you. The only issue is that for some architectures, doing a per-option-type filtering would imply processing the packet on the slow path.... and this requirement might be deemed as honerous. I guess one could say something like "If you support filtering on a per-option-type basis, then such filtering should be configurable on a per-option-type basis", etc.? > Now some more specific comments on the extension headers: > >> 2.3.1.1. Uses >> >> >> The Hop-by-Hop Options header is used to carry optional information >> that must be examined by every node along a packet's delivery path. > > In fact, RFC 7145 changes that: > >> 2.2. Hop-by-Hop Options >> >> The IPv6 Hop-by-Hop Options header SHOULD be processed by >> intermediate forwarding nodes as described in [RFC2460]. However, it >> is to be expected that high-performance routers will either ignore it >> or assign packets containing it to a slow processing path. > > You could s/must/should/. Will do. Thanks! > More important: > >> 2.3.1.5. Advice >> >> Intermediate systems should, by default, drop packets containing a >> IPv6 Hop-by-Hop Option Extension Header. > > You can't say that! Firstly, RFC 7045 makes it permissible to > simply ignore them. While I understand your point (and agree that RFC7045 is authoritative here), (FWIW) this is what RFC7126 says about Router Alert option, which in some sense is analogous to the HBH EH: ---- cut here ---- This option SHOULD be allowed only in controlled environments, where the option can be used safely. [RFC6398] identifies some such environments. In unsafe environments, packets containing this option SHOULD be dropped. A given router, security gateway, or firewall system has no way of knowing a priori whether this option is valid in its operational environment. Therefore, routers, security gateways, and firewalls SHOULD, by default, ignore the Router Alert option. Additionally, routers, security gateways, and firewalls SHOULD have a configuration setting that governs their reaction in the presence of packets containing the Router Alert option. This configuration setting SHOULD allow to honor and process the option, ignore the option, or drop packets containing this option. ---- cut here ---- My question is: do we want to do something different with HBH EH than what we do with Router Alert in IPv4? FWIW, defaulting to "ignore" seems sensible to me. >> 2.3.2. Routing Header for IPv6 (Number=43) > ... >> 2.3.2.5. Advice >> >> >> Drop packets containing a RHT0. > > In fact there is considerably more detailed guidance already > in RFC 7045 (last paragraph of section 2.1). I think you should > send the reader to that. Will do. > >> 2.3.9. Shim6 Protocol (Number=140) > ... >> 2.3.9.3. Specific Security Implications >> >> >> TBD. > > You could mention that shim6 uses CGA or HBA cryptographic > addresses to prevent a 3rd party hijacking a session by > forging shim6 headers with a bogus address. There is an > extensive security discussion in RFC 5533. Thanks for the note! >> 2.3.10. Use for experimentation and testing (Numbers=253 and 254) > ... >> 2.3.10.5. Advice >> >> >> Routers, security gateways, and firewalls SHOULD have configuration >> knobs for IP packets that contain this extension header to select >> between "ignore & forward" and "drop & log". > > Well, you might prefer to put that text at the top, since RFC 7045 requires > all headers to have a configuration option. To be precise, 7045 says: > >> Experimental IPv6 extension headers SHOULD be treated in the same way >> as standard extension headers, including an individually configurable >> discard policy. However, the default configuration MAY drop >> experimental extension headers. Our bad :-( -- will cite RFC7045 as appropriate. Thanks so much! -- Fernando Gont e-mail: [email protected] || [email protected] PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1 _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
