Re: [OPSEC] Last Call: <draft-ietf-opsec-ipv6-eh-filtering-06.txt> (Recommendations on the Filtering of IPv6 Packets Containing IPv6 Extension Headers) to Informational RFC

["C. M. Heard" <[e-mail]>]

On Sat, Nov 24, 2018 at 7:37 AM Nick Hilliard <[e-mail]> wrote:
> C. M. Heard wrote on 23/11/2018 16:20:
> > while promoting a **/_default deny_/** policy with respect to unknown
> > extension headers, experimental extension headers, and experimental
> > options. If every transit router followed that advice, it would be
> > impossible to transmit packets containing these things across the open
> > Internet. It is especially egregious to dispense that advice for
> > unknown extension headers, since that would severely impede deployment
> > of any new extension headers OR any new transport protocols in the open
> > Internet (as the document itself notes, unknown extension headers are
> > indistinguishable from unknown upper-layer protocol headers). This part
> > of the document's advice does nothing to improve the situation reported
> > in RFC 7872; if anything, it makes the situation worse. It certainly
> > will not make the Internet work better.
>
> transit operators would generally take the view that any data-plane
> packet which needs to be put through a slow path will be rate limited up
> to 100% loss.  We can argue endlessly at the IETF about the pros and
> cons of this from a protocol development and management point of view
> but at the end of the day, transit operators have networks to run, and
> there is a jarring disparity between data-plane forwarding speed and
> control-plane processing capacity.  If you expect one to bleed into the
> other, something needs to give.  This is often going to be
> silicon-specific; what is slow-pathed on one platform may not be
> slow-pathed on another, so generalised statements are difficult in this
> situation.

It's not clear to me what that has to do with the specific comments
that I made (and that you elided).  I would understand if I had brought
up handling of, say, HbH options rather than default drop policies for
unknown (and experimental) header types.  Perhaps you could clarify.

> Transit operators are going to make their own decisions about what to do
> about packet filtering, and take any specific recommendation in an ID
> like this with a grain of salt.  In that respect, this document needs to
> be seen as a store of information to help people make informed decisions
> about what to do rather than being a prescriptive list.

Agreed, that's the most useful part of the document. But it does in
addition give specific advice, and that advice should be reasonable
as a default.

My primary objection is to the advice that says discard unknown
EHs and upper-layer protocols by default.  That advice needs to
be more nuanced -- as is the advice for unknown option types
given in Sec. 4.4.5,   I see no reason why these cases should
get different advice.

Mike Heard