[OPSEC] Rtgdir last call review of draft-ietf-opsec-ipv6-eh-filtering-06

[Stewart Bryant <[e-mail]>]

Reviewer: Stewart Bryant
Review result: Has Issues

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