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

[Ole Troan <[e-mail]>]

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 scuh 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 arc hitecture 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.


* 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?

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.



Ole