Hi, (Excuse cross posting but I'm sure v6ops folk will have an opinion, and I'm not on opsec.)
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. 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. 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 won't comment in detail on the options - at a quick glance, your suggested defaults seems about right. 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/. 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. That's the simplest DoS defence. Secondly, well, dropping them is the wrong default because it breaks stuff. You could discuss whether to inspect them for valid contents, and you could discuss rate-limiting, which I understand some vendors support already. > 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. > 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. > 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. Regards Brian _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
