Hello Fernando, Thanks for addressing my previous comments about destination options. I have a few comments on this new version.
Last paragraph of the introduction: Section 3 of this document discusses IPv6 extension headers and IPv6 options, and provides advice in the area of filtering IPv6 packets that contain such IPv6 Extension Headers and/or options. This needs a small editorial fix since Section 3 discusses extension headers and Section 4 discusses specific options. Section 2.2: 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]. The second half of the first sentence is not quite tre, since the draft does provide advice on default processing of the CALIPSO option. There is no equivalent to RFC 7045 for options, so presumably the defaults specified in RFC 2460 for an intermediate system would apply. These are: - pass by default all options in a Destination Options header - obey the instructions in the top two bits of the option type for options in a Hop-by-Hop Options header My inclination is to suggest that Section 2.2 be beefed up to point this out, e.g., by saying 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 [RFC2460]. and to suggest that all advice for option implementation defaults be left out of this document -- at most, it should be pointed out what the default configuration default _is_. Section 3.3.1.1, uses of Hop-by-Hop option header, fails to mention the following hop-by-hop options: o Quick-Start [RFC4782] o CALIPSO [RFC5570] I missed this the first time around, sorry about that. Also, as an editorial nit, I would suggest either including the type in this list, as was done in Section 3.3.6.2, or leaving it out in both places (and while I am at it, I would also suggest listing the options in the same subsection in both places, either Uses or Specification -- I also missed that in my previous comments). Section 3.10.5, advice regarding experimental use headers (253/254): Advice from -00: 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". Otherwise, no legitimate experiment using these options will be able to traverse any IP router. The aforementioned configuration knob SHOULD default to "drop & log". Special care needs to be taken in the case of "drop & log". Devices SHOULD count the number of packets dropped, but the logging of drop events SHOULD be limited so as to not overburden device resources. Advice from -01: Intermediate systems should discard packets containing these extension headers. Presumably the reason for this change to avoid giving advice to implementors regarding the default configuration and to focus on advice to operators on what configuration to set. If so, maybe something along the following lines would have less dissonance with the preceding paragraphs (c.f. jumbogram option advice): Alternative advice: Intermediate systems should discard packets containing these extension headers. This policy could be overridden in specific environments where the experimental headers are used. General comment on Section 4, advice about options: should the advice be nuanced to distinguish between cases where an option appears in a Hop-by-Hop option header vs a Destination Options header? For instance, should the advice be to discard all options that are supposed to appear only in a Destination Options header if they appear in a Hop-by-Hop options header? This is done for Tunnel Encapsulation Limit but not for other destination options (other than Line-Identification, for which the advice is unconditional discard). Also, should it be recommended that implemention allow separate polcies for these cases? Section 4.3.6.5, advice on Router Alert option: Current text: Intermediate systems should discard packets that contain this option. Recommended text: Intermediate systems should discard packets that contain this option. This policy could be overridden in specific environments where support for RSVP or similar protocols is desired. Section 4.3.8.5, advice on processing CALIPSO option: eliminate the text that provides advice about implentation defaults. Section 4.3.17.1, Uses if RFC3692-style experimental options: I would recommend s/MUST NOT/must not/ since this document does not levy that requirement -- RFC 4727 does. Section 4.3.17.5, advice regarding RFC3692-style experimental options: Current text: Intermediate systems should discard packets that contain these options. Recommended text: Intermediate systems should discard packets that contain these options. This policy could be overridden in specific environments where support for one or more of these options is desired. Unknown options: there is no section covering these. I am not concerned if the RFC 2460 implementation defaults (i.e., obey the instructions in the top two bits of the option type) is operationally acceptable. Thanks for considering these comments. Mike Heard On Sat, 16 Aug 2014, Fernando Gont wrote: > Folks, > > This revision > (<http://www.ietf.org/internet-drafts/draft-gont-opsec-ipv6-eh-filtering-01.txt>) > of the I-D should address the comments that you have sent so far. Please > do let us know if this is the case. > > Thanks! > > Best regards, > Fernando (& co-authors) > > > > > -------- Forwarded Message -------- > Subject: New Version Notification for > draft-gont-opsec-ipv6-eh-filtering-01.txt > Date: Sat, 16 Aug 2014 10:07:31 -0700 > From: [email protected] > To: Will(Shucheng) Liu <[email protected]>, Shucheng LIU (Will) > <[email protected]>, Fernando Gont <[email protected]>, Ron > Bonica <[email protected]>, Fernando Gont <[email protected]>, > Ronald P. Bonica <[email protected]> > > > A new version of I-D, draft-gont-opsec-ipv6-eh-filtering-01.txt > has been successfully submitted by Fernando Gont and posted to the > IETF repository. > > Name: draft-gont-opsec-ipv6-eh-filtering > Revision: 01 > Title: Recommendations on Filtering of IPv6 Packets Containing > IPv6 > Extension Headers > Document date: 2014-08-16 > Group: Individual Submission > Pages: 28 > URL: > http://www.ietf.org/internet-drafts/draft-gont-opsec-ipv6-eh-filtering-01.txt > Status: > https://datatracker.ietf.org/doc/draft-gont-opsec-ipv6-eh-filtering/ > Htmlized: > http://tools.ietf.org/html/draft-gont-opsec-ipv6-eh-filtering-01 > Diff: > http://www.ietf.org/rfcdiff?url2=draft-gont-opsec-ipv6-eh-filtering-01 > > Abstract: > This document provides advice on the filtering of IPv6 packets based > on the IPv6 Extension Headers and the IPv6 options they contain. > Additionally, it discusses the operational and interoperability > implications of discarding packets based on the IPv6 Extension > Headers and IPv6 options they contain. > > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > > > _______________________________________________ OPSEC mailing list [email protected] https://www.ietf.org/mailman/listinfo/opsec
