Hi, Joe, On 09/25/2014 05:24 PM, Joe Touch wrote: > On 9/25/2014 11:58 AM, Fernando Gont wrote: >> On 09/25/2014 01:39 PM, Joe Touch wrote: > ... >>> Further, this doc does not explicitly indicate the distinction between >>> upper and lowercase of the RFC2119 terms. >> >> It's the uppercase that are special, not the lowercase. There's a single >> bogus RFC2119 usage that needs to be changed to lowercase.. and that's it. > > The doc needs to remove the definition of 2119 language, and IMO also > needs to add a statement that no use of those terms is intended in the > 2119 sense. [...]
FWIW, I have no issues adding such a description if deemed necessary. However, if anything, this is easily fixable, and certainly not a show-stopper. >>> The places where you provide contradictory advice, notably (from 7045): >>> >>> RFC 2460 requires destination hosts to discard packets containing >>> unrecognised extension headers. However, intermediate forwarding >>> nodes SHOULD NOT do this, since that might cause them to >>> inadvertently discard traffic using a recently standardised extension >>> header not yet recognised by the intermediate node. The exceptions >>> to this rule are discussed next. >> >> Looks like you've decided to ignore the next paragraph, which says: >> >> 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. > > The term "standard" in that paragraph refers to a specific set of > extensions defined in RFC2460 - i.e., those that are deemed mandatory to > support. > > Your doc refers to other extensions that were not defined in RFC2460, > and for which that paragraph does not apply. That's not correct. NPlease see Section 1.1 of RFC7045, which says: In this document, "standard" IPv6 extension headers are those specified in detail by IETF Standards Actions [RFC5226]. "Experimental" extension headers include those defined by any Experimental RFC and the header values 253 and 254 defined by [RFC3692] and [RFC4727] when used as experimental extension headers. "Defined" extension headers are the "standard" extension headers plus the "experimental" ones. >> and also ignore the Security Considerations, which says: >> >> These changes do not affect a firewall's ability to filter out >> traffic containing unwanted or suspect extension headers, if >> configured to do so. However, the changes do require firewalls to be >> capable of permitting any or all extension headers, if configured to >> do so. The default configurations are intended to allow normal use >> of any standard extension header, avoiding the connectivity issues >> described in Sections 1 and 2.1. > > The recommendations in your document are to have a default that > overrides the security considerations in RFC2460. Nope. Please check Section 2.2 of our I-D, which says: The advice provided in this document is only meant to guide an operator in configuring forwarding devices, and is *not* to be interpreted as advice regarding default configuration settings for network devices. That is, this document provides advice with respect to operational configurations, but does not change the implementation defaults required by [RFC7045] and [draft-gont-6man-ipv6-opt-transmit]. i.e., our recommendations shouldn't be used as "default configurations" of any devices. >> draft-gont-opsec-ipv6-eh-filtering provides configuration advice, *not* >> a default policy or the like (and this is pretty clear in the Intro). So >> it doesn't go against RFC7045. For instance, that was the main/sole goal >> of the latest rev of the I-D > > Advice that doesn't give a specific context is advice to override a > default, IMO. You need a lot more context to explain when and/or where > such overrides are relevant. If you look closely at the I-D, it is essentially a "default allow", modulo HBH, in which case we provide recommendations 8a few options) well within RFC7045. Thanks, -- Fernando Gont SI6 Networks e-mail: [email protected] PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
