PS - I have a day job, and this isn't it. If others care about this doc, I encourage them to speak up.
In its current form, I don't support its adoption by any WG. Joe On 9/25/2014 1: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. > > 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
