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

[Nick Hilliard <[e-mail]>]

C. M. Heard wrote on 24/11/2018 16:14:
> On Sat, Nov 24, 2018 at 7:37 AM Nick Hilliard <[e-mail]> wrote:
>> C. M. Heard wrote on 23/11/2018 16:20:
>> 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.

hm yes, it was a bit obtuse.  What I was trying to get at (and 
completely failed to achieve) was:

1. that EHs are largely unusable anyway, so if this draft makes some 
types slightly more unusable, that isn't going to make much of a 
practical difference.  RFC7872 suggests failure rates of ~30% - 50% for 
fragment headers.  Once you're in this territory, nothing you can do 
will make things any worse.

2. transit operators don't like filtering stuff.  They will filter 
traffic if and only if that traffic is a nuisance or forms a threat to 
the operation of their networks, and:

> 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.

...3. Any recommendation that the IETF makes in this area may, or may 
not, be taken as input into a decision machine, the result of which will 
be to filter, or rate limit, or to forward.  From this perspective, the 
documentation needs to observe and make suggestions.

Nick