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 Tue, Nov 27, 2018 at 12:28 AM Ole Troan wrote:
> Fernando, et al,
>
>>> From reading the email thread, this sentence seems to me to be a
>>> good summary of the draft.
>>
>> Most of the content of this document is about analyzing the
>> implications of each EH and option, to help folks with the
>> aforementioned analysis -- regardless of what the outcome of [such]
>> analysis is.
>
> OK, that’s good to hear.
>
> If that’s the case I would have liked to see more text on explaining
> the background, give reasons why filtering in the middle of the
> network is harmful (protocol extensions, ossification, violates
> Internet architecture principles, packet parsing is costly, might
> required symmetric paths, etc).
>
> A very unfortunate consequence of this work, is that the IETF appears
> to send a message that routers in the Internet is now expected to
> parse deep into packets and perform filtering actions. That’s a big
> change of the Internet architecture, and our view of layering.
>
> A few comments on the actual advice:
>
> The HBH advice (3.4.1.5) is fine and reflects that I think.
> Likewise for the RH advice (3.4.2.5),  FH (3.4.3.5) and DestOpt (3.4.6.5).
>
> * Protocol numbers 253/254
>
> OLD:
> 3.4.10.5.  Advice
>    Intermediate systems should discard packets containing these EHs.
>    Only in specific scenarios in which RFC3692-Style experiments are to
>    be performed should these EHs be permitted.
>
> NEW:
> 3.4.10.5.  Advice
>    Intermediate systems should permit packets that contain these EHs.
>
> * New protocol types / extension headers
>
> OLD
> 3.5.5.  Advice
>    Intermediate systems should discard packets containing unknown IPv6
>    EHs.
>
> NEW:
> 3.5.5.  Advice
>    Intermediate systems should permit packets containing unknown IPv6
>    EHs.

Ole, you are in effect saying that the proposed text for Section 3 in
https://mailarchive.ietf.org/arch/msg/opsec/5SF7Q1dNnikQ23sx0nn6Iah1hMU
should have the "operators should determine ..." text replaced by
"intermediate systems should permit ..." (note that I include a portion
of Section 3.1 dealing with the "unable to determine" case, in addition
to the cases you mention above).

I have to admit that I think the Internet would be better served by
the choices that you propose, but the current consensus position of the
IETF, as expressed in RFC 7045 (PS), acknowledges that some systems
will parse deep into packets to perform filtering actions.  In levying
requirement on systems that do so, it is neutral on what the default
action is in the above cases.  Since the status of the current draft is
informational, it seems inappropriate to push the advice one way or
another and thereby turn "MAY" into "should" or "should not."

Hence, I think "operators should determine ..." is probably the way to go.

To make the point about RFC 7045 steering the advice perfectly clear, I'd
actually like to see Section 2.3 expanded along the following lines:

---
OLD:
2.3.  Conventions

   This document assumes that nodes comply with the requirements in
   [RFC7045].  Namely (from [RFC7045]),

   o  If a forwarding node discards a packet containing a standard IPv6
      EH, it MUST be the result of a configurable policy and not just
      the result of a failure to recognise such a header.

   o  The discard policy for each standard type of EH MUST be
      individually configurable.

   o  The default configuration SHOULD allow all standard IPv6 EHs.

NEW:
2.3.  Conventions

   This document assumes that nodes comply with the requirements in
   [RFC7045].  Namely (from [RFC7045]),

   o  Any forwarding node along an IPv6 packet's path that forwards the
      packet for any reason SHOULD do so regardless of any extension
      headers that are present.  Exceptionally, if a forwarding node is
      designed to examine extension headers for any reason, such as
      firewalling, it MUST recognise and deal appropriately with all
      standard IPv6 extension header types and SHOULD recognise and deal
      appropriately with experimental IPv6 extension header types.

   o  If a forwarding node discards a packet containing a standard IPv6
      EH, it MUST be the result of a configurable policy and not just
      the result of a failure to recognise such a header.

   o  The discard policy for each standard type of EH MUST be
      individually configurable.

   o  The default configuration SHOULD allow all standard IPv6 EHs.

   o  Experimental IPv6 extension headers SHOULD be treated in the same
      way as standard extension headers, including an individually
      configurable discard policy.  However, the default configuration
      MAY drop experimental extension headers.

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

Do you think that this would help?

> * MLD
> 4.3.7.5.  Advice
>    Intermediate systems should discard packets that contain this option.
>    Only in specific environments where support for RSVP, multicast
>    routing, or similar protocols is desired, should this option be
>    permitted.
>
> Multicast is fundamental to the function of e.g. IPv6 ND. IPv6 links
> must generally be multicast capable. A recommendation of a blanket kill
> of MLD can’t be right. I don’t know how this recommendation should be
> formed, perhaps say something to separate MLD as used on-link with
> hop-limit = 1?

As I look at the advice for specific options more carefully, I find some
inconsistencies in the advice for certain cases, and the Router Alert
option (which is the one that applies to MLD) is one of those. My
general take for Hop-by-Hop options would be:

- If the "act" bits are set to "00" (ignore if you don't support it),
  then the advice should probably be to pass packets with that option
  unless there is vulnerable equipment that needs to be protected (e.g.,
  legacy routers that could be subject to DOS attacks from Router Alert)

- if the "act" bits are set to anything else, then the advice should
  probably be to drop such packets unless part of a domain where the
  feature is used (which is what RFC 8200 says anyway)

> Unknown options types:
>
> OLD:
> 4.4.5.  Advice
>    Enterprise intermediate systems that process the contents of IPv6 EHs
>    should discard packets that contain unknown options.  Other
>    intermediate systems that process the contents of IPv6 EHs should
>    permit packets that contain unknown options.
>
> NEW:
> 4.4.5.  Advice
>    Intermediate systems should not discard packets based on the presence
>    of unknown options.

I see that Fernando subsequently agreed to this, and I do not object;
but I do questions why unknown options would be permitted while the ones
set aside for RFC3692-style are to be filtered unless such an experiment
is known to be ongoing. Consistent advice seems to be in order for
these two cases.

I will follow up after doing a more thorough review of the specific
advice for each option.

Mike Heard