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

[Brian E Carpenter <[e-mail]>]

On 2018-11-25 05:14, C. M. Heard wrote:
> 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.

As background, the *end* of the discussion of HbH in the draft says:

   Finally, when
   packets containing a HBH Options EH are processed in the slow-path,
   and the underlying platform does not have any mitigation options
   available for attacks based on these packets, we recommend that such
   platforms discard packets containing IPv6 HBH Options EHs.

I'm not sure what else a firewall recommendation could say (as a default
configuration, because the whole document is really about defaults). But
it's worth reading the preceding text at
https://tools.ietf.org/html/draft-ietf-opsec-ipv6-eh-filtering-06#section-3.4.1.5
to get the context for that "Finally".

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

Let's see. We have:

3.5.2.  Specification

   The processing of unknown IPv6 EHs is specified in [RFC8200] and
   [RFC7045].

In fact RFC8200 doesn't discuss EH processing by intermediate nodes.
RFC7045 does (see https://tools.ietf.org/html/rfc7045#section-2.1 ).
Again, read the whole section for context, but the key sentence is:

   Forwarding nodes MUST be configurable to allow packets containing
   unrecognised extension headers, but the default configuration MAY
   drop such packets.

That was a careful compromise between the ideal (a transparent Internet)
and reality (an Internet with security-aware operators). The current draft
changes this MAY into a lower-case should:

3.5.5.  Advice

   Intermediate systems should discard packets containing unknown IPv6
   EHs.

I'm with Mike Heard. This is an informational document attempting
to override a Proposed Standard. That's not OK.

That doesn't mean Nick Hilliard is wrong. Operators make their own
decisions, so I think that is what the draft should say. Something like:

3.5.5.  Advice

   Operators should determine according to their own circumstances
   whether to discard packets containing unknown IPv6 EHs.

And at the same time, delete the 2nd and 3rd sentences of this:

3.5.3.  Specific Security Implications

   For obvious reasons, it is impossible to determine specific security
   implications of unknown IPv6 EHs.  However, from security standpoint,
   a device should discard IPv6 extension headers for which the security
   implications cannot be determined.  We note that this policy is
   allowed by [RFC7045].

I don't expect these changes to have much impact in the real world,
however.

    Brian

> 
> Mike Heard
> 
>