On Tue, Nov 27, 2018 at 12:28 AM Ole Troan wrote: > Fernando, et al, > >>> From reading the email thread, this sentence seems to me to be a >>> good summary of the draft. >> >> Most of the content of this document is about analyzing the >> implications of each EH and option, to help folks with the >> aforementioned analysis -- regardless of what the outcome of [such] >> analysis is. > > OK, that’s good to hear. > > If that’s the case I would have liked to see more text on explaining > the background, give reasons why filtering in the middle of the > network is harmful (protocol extensions, ossification, violates > Internet architecture principles, packet parsing is costly, might > required symmetric paths, etc). > > A very unfortunate consequence of this work, is that the IETF appears > to send a message that routers in the Internet is now expected to > parse deep into packets and perform filtering actions. That’s a big > change of the Internet architecture, and our view of layering. > > A few comments on the actual advice: > > The HBH advice (3.4.1.5) is fine and reflects that I think. > Likewise for the RH advice (3.4.2.5), FH (3.4.3.5) and DestOpt (3.4.6.5).. > > * Protocol numbers 253/254 > > OLD: > 3.4.10.5. Advice > Intermediate systems should discard packets containing these EHs. > Only in specific scenarios in which RFC3692-Style experiments are to > be performed should these EHs be permitted. > > NEW: > 3.4.10.5. Advice > Intermediate systems should permit packets that contain these EHs. > > * New protocol types / extension headers > > OLD > 3.5.5. Advice > Intermediate systems should discard packets containing unknown IPv6 > EHs. > > NEW: > 3.5.5. Advice > Intermediate systems should permit packets containing unknown IPv6 > EHs. Ole, you are in effect saying that the proposed text for Section 3 in https://mailarchive.ietf.org/arch/msg/opsec/5SF7Q1dNnikQ23sx0nn6Iah1hMU should have the "operators should determine ..." text replaced by "intermediate systems should permit ..." (note that I include a portion of Section 3.1 dealing with the "unable to determine" case, in addition to the cases you mention above). I have to admit that I think the Internet would be better served by the choices that you propose, but the current consensus position of the IETF, as expressed in RFC 7045 (PS), acknowledges that some systems will parse deep into packets to perform filtering actions. In levying requirement on systems that do so, it is neutral on what the default action is in the above cases. Since the status of the current draft is informational, it seems inappropriate to push the advice one way or another and thereby turn "MAY" into "should" or "should not." Hence, I think "operators should determine ..." is probably the way to go. To make the point about RFC 7045 steering the advice perfectly clear, I'd actually like to see Section 2.3 expanded along the following lines: --- OLD: 2.3. Conventions This document assumes that nodes comply with the requirements in [RFC7045]. Namely (from [RFC7045]), o If a forwarding node discards a packet containing a standard IPv6 EH, it MUST be the result of a configurable policy and not just the result of a failure to recognise such a header. o The discard policy for each standard type of EH MUST be individually configurable. o The default configuration SHOULD allow all standard IPv6 EHs. NEW: 2.3. Conventions This document assumes that nodes comply with the requirements in [RFC7045]. Namely (from [RFC7045]), o Any forwarding node along an IPv6 packet's path that forwards the packet for any reason SHOULD do so regardless of any extension headers that are present. Exceptionally, if a forwarding node is designed to examine extension headers for any reason, such as firewalling, it MUST recognise and deal appropriately with all standard IPv6 extension header types and SHOULD recognise and deal appropriately with experimental IPv6 extension header types. o If a forwarding node discards a packet containing a standard IPv6 EH, it MUST be the result of a configurable policy and not just the result of a failure to recognise such a header. o The discard policy for each standard type of EH MUST be individually configurable. o The default configuration SHOULD allow all standard IPv6 EHs. o 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. o Forwarding nodes MUST be configurable to allow packets containing unrecognised extension headers, but the default configuration MAY drop such packets. Do you think that this would help? > * MLD > 4.3.7.5. Advice > Intermediate systems should discard packets that contain this option. > Only in specific environments where support for RSVP, multicast > routing, or similar protocols is desired, should this option be > permitted. > > Multicast is fundamental to the function of e.g. IPv6 ND. IPv6 links > must generally be multicast capable. A recommendation of a blanket kill > of MLD can’t be right. I don’t know how this recommendation should be > formed, perhaps say something to separate MLD as used on-link with > hop-limit = 1? As I look at the advice for specific options more carefully, I find some inconsistencies in the advice for certain cases, and the Router Alert option (which is the one that applies to MLD) is one of those. My general take for Hop-by-Hop options would be: - If the "act" bits are set to "00" (ignore if you don't support it), then the advice should probably be to pass packets with that option unless there is vulnerable equipment that needs to be protected (e.g., legacy routers that could be subject to DOS attacks from Router Alert) - if the "act" bits are set to anything else, then the advice should probably be to drop such packets unless part of a domain where the feature is used (which is what RFC 8200 says anyway) > Unknown options types: > > OLD: > 4.4.5. Advice > Enterprise intermediate systems that process the contents of IPv6 EHs > should discard packets that contain unknown options. Other > intermediate systems that process the contents of IPv6 EHs should > permit packets that contain unknown options. > > NEW: > 4.4.5. Advice > Intermediate systems should not discard packets based on the presence > of unknown options. I see that Fernando subsequently agreed to this, and I do not object; but I do questions why unknown options would be permitted while the ones set aside for RFC3692-style are to be filtered unless such an experiment is known to be ongoing. Consistent advice seems to be in order for these two cases. I will follow up after doing a more thorough review of the specific advice for each option. Mike Heard
