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 Fri, Nov 30, 2018 at 6:46 AM C. M. Heard <[e-mail]> wrote:
> > As I look at the advice for specific options more carefully, I find
> > some inconsistencies in the advice for certain cases [...].
> >
> > I will follow up after doing a more thorough review of the specific
> > advice for each option.
>
> Here is the promised/threatened follow up.
>
> Section 3.4.1.2, Specification of the Hop-by-Hop Options extension
> header: the deprecated Endpoint Identification Option (Type 0x8A)
> should not be listed here. The reference cited for this option states
> that it is a Destination Option to convey Nimrod EIDs.

Also, in the bullet for 0x4D, add the reference [RFC7731].

This will bring the section in line with the content of the registry.

> Section 3.4.6.2, Specification of the Destination Options extension
> header: the Performance and Diagnostic Metrics (PDM) Option should be
> listed here. The reference is RFC 8250.

Also, the deprecated option 0x4D should not be listed in this section. It
was an erroneous early version of the MPL option 0x6D that did not have
the chg bit set to 1. For details please ee:

https://mailarchive.ietf.org/arch/msg/roll/blyXhjgs0d3iBdce84Z7k2PISts

and related messages. Note that RFC 7731 does call this out as a
deprecated version of the MPL option.

> Section 4: A subsection documenting the PDM Option needs to be added.
> Insofar as this is a standard option that is to be ignored by systems
> that do not implement it, the advice "should not discard" would be an
> appropriate default.
>
> Section 4: The advice for specific options is not conditioned upon
> whether they are found in a Hop-by-Hop Options header or a Destination
> Options header. However, every defined option (other than padding and
> experimental types) is intended to appear in only one of those headers.
> At a minimum this needs to be pointed out. It may be appropriate to
> advise that packets with defined options that appear within the "wrong"
> header should be discarded.
>
> Section 4: The advice for Router Alert (Type=0x05, Proposed Standard)
> and SMF_DPD (Type=0x08, Experimental) is "should discard", while the
> advice for Quick-Start (Type=0x26, Experimental) is "should not
> discard". All of these Hop-by-Hop options are applicable only in limited
> domains (RFC 6398 says so for Router Alert), and Quick Start and Router
> Alert have substantial security implications. Thus, I have a hard time
> wrapping my head around the fact that they do not all get the same
> advice. How about something like "intermediate systems should discard
> packets that contain this option, except when deployed in an
> administrative domain where the option is in use" for all of them?
>
> Section 4: Randall Atkinson has provided detailed comments on CALIPSO.
> I support those comments. Note that systems compliant with RFC 8200
> that do not implement RFC 5570 would simply ignore the option.

Sections 4.3.15.1 and 4.3.15.2: note that 0x4D this was an erroneous early
allocation that was replaced by 0x6D.

> Sections 4.3.18.5 and 4.4.5: as I previously stated, I think the right
> strategy is to remain neutral and say that operators should determine
> according to their own circumstances whether to discard packets
> containing these options. Reiterated only for completeness.
>
> Unused reference: I-D.ietf-6man-hbh-header-handling

Mike Heard