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. When both are used (both 2119-sense and not), I use the following text to make the distinction explicit: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119 [RFC2119]. In this document, these words will appear with that interpretation only when in ALL CAPS. Lower case uses of these words are not to be interpreted as carrying RFC-2119 significance. >>>> - deprecates the flags in HBH options intended to declare how an option >>>> is handled when not known by providing advice specific to each option >>>> type that does not consider the flag setting >>> >>> The advice in this I-D essentially mimics RFC7045 for options. That was >>> the intent. Am I missing something? >> >> 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. > 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. Your doc would have to say something like "when the following attack is noticed,..." or "in the following specific use case...". > 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. Joe _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
