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

[Fernando Gont <[e-mail]>]

Ole,

On 27/11/18 05:28, 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 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).

As noted by a number of folks on this thread already, and as discussed
in https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops,
folks may have reasons to filter packets.

I don't think this document is the place to educate folks on whether
packet filtering is a good or a bad thing to do.



> 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 certainly not the message this document tries to convey, at least.


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

So far, the change proposed (and agreed upon) for unknown EHs, is:
"Operators should determine according to their own circumstances
    whether to discard packets containing unknown IPv6 EHs."

thoughts?



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

For packets that you ND and such, wouldn't those packets be directed to
the router, rather than requested to be forwarded?



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

Will do.

Thanks!

Fernando




-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492