Benjamin Kaduk has entered the following ballot position for draft-ietf-opsec-ipv6-eh-filtering-08: Discuss
When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-eh-filtering/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- It seems that we accumulated some factual errors by letting this draft sit mostly idle since 2018, as the world evolved around us. Hopefully these are easy to remedy... Section 3.4.1.2 claims to have a list of options that have been specified as Hop-by-Hop options, and Section 3.4.6.2 a list of options that have been specified as Destination Options, each respectively "at the time of this writing". IANA has a single registry for both Destination and Hop-by-Hop options, and assessing which ones are defined as Hop-by-Hop vs Destinationmay require following each reference, but it seems that the PDM option from RFC 8250 has been allocated and is in neither list, and the early allocations for IOAM and Path MTU Record may need to be considered as well. I suppose that we do attempt to go into the individual optiosn in detail in Section 4.3, so perhaps this is not quite so simple to remedy after all. (Note: while it is not the preferred outcome, merely changing the statement from "time of this writing" and "so far been specified" to "as of 2018" ought to be sufficient to resolve the discuss, as would Lars' suggestion of just referring to the IANA registry without incorporating the registry contents.) Section 3.4.8.1 refers to HIP as an "experimental protocol", but as of RFC 7401, HIP is on the standards track. Also, there seems to be some skew between Table 1 and Section 3.4.10.5 regarding the recommended filtering policy for the experimental/testing EH types (drop vs [no recommendation]) ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- Section 1 Recent studies (see e.g. [RFC7872]) suggest that there is widespread dropping of IPv6 packets that contain IPv6 Extension Headers (EHs). In some cases, such packet drops occur at transit routers. While some operators "officially" drop packets that contain IPv6 EHs, it is possible that some of the measured packet drops be the result of improper configuration defaults, or inappropriate advice in this area. The "it is possible that some" is not very confidence-inspiring; do we have much reason to think that there is any significant proportion of the packet drops that are due to these reasons? This document is similar in nature to [RFC7126], which addresses the same problem for the IPv4 case. [...] It is interesting to note that RFC 7126 has BCP status, while this document targets only Informational status. This document completes and complements the considerations for protecting the control plane from packets containing IP options that can be found in [RFC6192]. I see that RFC 6192 claims to provide "a method for protecting a router's control plane from undesired or malicious traffic" and in particular only claims applicability to traffic destined for the router itself (as opposed to traffic that is passing through the router). Is the claim here that fully protecting the router's control plane also requires filtering traffic that is not destined for the router itself? I'm not sure in what other sense this document would be "complet[ing] and complement[ing]" RFC 6192. In particular, protecting the network as a whole seems like a different goal than just protecting the router control plane. Section 2.3 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]. In light of the rtgdir reviewer's remarks (to which I cannot find a response in the mailarchive), I wonder if we might include a statement in here somewhere along the lines of "the network operator will need to make pragmatic engineering and business decisions about how to configure their routers, as constrained by the configuration options that the router vendor has made available and the nature of the traffic they are receiving. This document does not prescribe any specific configuration or course of action, but rather provides information and analysis regarding potential configuration options and the consequences thereof". o Discard (and log) packets containing this IPv6 EH or option type. Should this be "drop" to more properly contrast with the subsequent bullet that explicitly "reject"s (recalling that "discard" is claimed to be used for "either drop or reject without specification of which"? Section 3.3 I can't tell whether or not it's intentional that Table 1 has no entry for unregistered EH types (which do get discussion in the body of the document). Section 3.4.2.3 Would this be an appropriate place to include the discussion suggested by the rtgdir reviewer, that security issues with RHTs have been discovered in the past that required urgent action to disable them globally, and thus that devices should offer the ability to configure the discard of packets bearing RH on a per-RHT basis? Also, RFCs 6275 and 6554 seem to (respectively) have discussion of the security implications of their routing header types, and it's not clear why those references are not included in addition to the references for RHT0 and RHT4. Section 3.4.8.3 The security implications of the HIP header are discussed in detail in Section 8 of [RFC6275]. RFC 6725 is "Mobility Support in IPv6" and does not specifically mention HIP. While Mobile IPv6 and HIP are similar in some regards, it's not entirely clear to me that this is the correct reference. (Section 8 of RFC 7410 is its security considerations, so maybe that's the only change that's needed.) Section 3.4.10.5 I'm a bit surprised that the advice does not include a recommendation to allow the experimental-use/testing EHs with a rate limit, to give small experiments some chance of working across the Internet. Section 4.3.3.5 The previous subsections do not give much indication of harm caused by jumbograms so as to justify a recommendation to discard packets containing them. Section 4.3.4.5 As for jumbograms, the evidence of harm presented is sparse. Mention (in both places?) that their presence is indicative of unexpected traffic escaping from a controlled domain and that such unexpected traffic would potentially have harmful consequences when delivered might be helpful (if appropriate). Section 4.3.6.5 Intermediate systems should not discard packets based on the presence of this option. Is that synonymous with "ignore"? (I'll mention this just once, and skip the other places that use this phrasing.) Section 4.3.9.5 For Intermediate systems that DO NOT implement RFC-5570, there should be a configuration option to EITHER (a) drop packets containing the CALIPSO option OR (b) to ignore the presence of the CALIPSO option and forward the packets normally. In non-MLS environments, such intermediate systems should have this configuration option set to (a) above. In MLS environments, such intermediate systems should have this option set to (b) above. The default setting for this configuration option should be set to (a) above, because MLS environments are much less common than non-MLS environments. This is getting a fair bit closer to prescribing default behavior than the introductory material of the document had led me to expect. (Similarly for the following paragraph.) Section 4.3.14.3 Those described in [RFC6788]. The security considerations of RFC 6788 are pretty slim ... though I don't really expect us to have to document things more thoroughly in this document. Section 4.4.5 Operators should determine according to their own circumstances whether to discard packets containing unknown IPv6 options. Is there any guidance to give on whether to offer configuration on a per-option-type basis? Section 7 As the rtgdir reviewer notes, situations where a packet is rejected (with notification) result in traffic directed at the "sender"; in at least the case of spoofed source addresses this can be an attack in its own right. Routers that reject packets should probably rate-limit such notifications. Section 9.1 Some of these references may not actually need to be normative, e.g., when we're just referring to protocols that might be broken if an EH and/or option is blocked, such as RFC 2205. Section 9.2 Is [NIMROD-DOC] or RFC 1992 the better reference? We also have [draft-ietf-nimdor-eid] listed, but AIUI that's sufficiently different to be separate. NITS Section 2.3 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 recognize 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. If we're endeavoring to retain the normative language as used in RFC 7045, the last "SHOULD" should be capitalized. is of use for trouble-shooting purposes. However, throughout this document (when recommending that packets be discarded) we generically refer to the action as "discard" without specifying whether the sender is signaled of the packet drop. This bit is arguably redundant with the definition in ยง2.1 and thus a candidate for removal. Section 3.4.1.2 o Type 0x63: RPL Option [RFC6553] IANA has this as "RPL Option (DEPRECATED)" and also citing RFC 9008. _______________________________________________ OPSEC mailing list OPSEC@ietf.org https://www.ietf.org/mailman/listinfo/opsec