I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see ​http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft. Document: draft-ietf-opsec-ipv6-eh-filtering-06 Reviewer: Stewart Bryant Review Date: 5 December 2018 Intended Status: Informational Summary: This is a comprehensive and well written document. However the IESG needs to think carefully about whether this document end-runs the protocol development process. Comments: It is clear from the discussion on the list about this text that there is a disconnect between protocol theory, protocol implementation and protocol deployment with regard to IPv6 that needs to be resolved in the IETF, and which may be of broader scope than this text. Reading the text and the associated references I share those concerns. Major Issues: I am worried about the fragmented filter that this document attempts to mandate. It is easy to see why a router on the edge of its performance envelope would take the view : "if not UDP | TCP: slow path" if small queue to slow path full: drop Whilst this document performs a solid analysis of what actions should be taken on an option, it ought to make it clearer to the reader that how a router handles options needs to be a pragmatic engineering and business decision taken by the vendor and network operator. 3.4.2.5. Advice Intermediate systems should discard packets containing a RHT0 or RHT1. Other routing header types should be permitted, as required by [RFC7045]. SB> There also need to be advice to the protocol designers to SB> avoid the problems that got RHT0 deprecated in the first place. SB> Also, given the emergency deprecation of RHT0 there ought to SB> be a requirement on the fast path that it can block any RH type SB> at any time in the future. Minor Issues: The document includes the RFC 2119 template and makes very occasional use of RFC 2119 language, but as I read through the text I found instances where it looked as if such language could be usefully used but was not used. It is possible that the authors took the view that RFC 2119 language would only be used in quoted text, in which case a clarifying note to this effect might be useful. ============== o Ignore this IPv6 EH or option type (as if it was not present) and forward the packet. We note that if a packet carries forwarding information (e.g., in an IPv6 Routing Header) this might be an inappropriate or undesirable action. SB> If the node in question needed to see the routing information isn't SB> that a misconfiguration that should never happen? ============= Finally, we note that when discarding packets, it is generally desirable that the sender be signaled of the packet drop, since this is of use for trouble-shooting purposes. SB> Without further qualification of the action, isn't that also an attack vector SB> for a target "sender"? ============= 4.3.7.5. Advice Intermediate systems should discard packets that contain this option. SB> I think you mean should by default discard packets containing this option. SB> Otherwise this sentence technically conflicts with the next. Only in specific environments where support for RSVP, multicast routing, or similar protocols is desired, should this option be permitted. ============= 4.3.8.5. Advice Intermediate systems should not discard IPv6 packets based on the presence of this option. SB> Shouldn't this advice be more qualified given the advise in 4.3.8.4 ============= 4.3.10.5. Advice Intermediate system should discard packets that contain this option. SB> Shouldn't that be intermediate systems not in a MANET should...? ============= Nits: Blocking packets containing a RHT0 or RTH1 has no operational SB> That should be RHT1 in your notation) ============= Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC4304' is defined on line 1412, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-6man-hbh-header-handling' is defined on line 1554, but no explicit reference was found in the text