Re: [OPSEC] Robert Wilton's No Objection on draft-ietf-opsec-ipv6-eh-filtering-08: (with COMMENT)

["Eric Vyncke (evyncke)" <[e-mail]>]

Replying with my IPv6  + shepherd hats

Indeed, I fail to understand why *transit* SP are dropping EH (as opposed to final destination router/firewall, which should drop some EH)

I sincerely hope that this document will rather 'open the gate' as some EH are recommended to go through

-éric
-----Original Message-----
From: iesg <[e-mail]> on behalf of Robert Wilton via Datatracker <[e-mail]>
Reply-To: "Rob Wilton (rwilton)" <[e-mail]>
Date: Wednesday, 14 July 2021 at 16:21
To: The IESG <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, Eric Vyncke <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Robert Wilton's No Objection on draft-ietf-opsec-ipv6-eh-filtering-08: (with COMMENT)

    Robert Wilton has entered the following ballot position for
    draft-ietf-opsec-ipv6-eh-filtering-08: No Objection

    When responding, please keep the subject line intact and reply to all
    email addresses included in the To and CC lines. (Feel free to cut this
    introductory paragraph, however.)


    Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
    for more information about DISCUSS and COMMENT positions.


    The document, along with other ballot positions, can be found here:
    https://datatracker.ietf.org/doc/draft-ietf-opsec-ipv6-eh-filtering/



    ----------------------------------------------------------------------
    COMMENT:
    ----------------------------------------------------------------------

    Hi,

    Thanks for this document, it is useful to try and tame how SPs are filtering
    IPv6 extension headers.

    However, I did find some of this document somewhat surprising in the context of
    RFC 8200, and this is perhaps just my naivety on how it is actually deployed:

    My reading on RFC 8200 extension headers can be summarized as:
     - Hop by hop options default to being off unless you enable them.
     - Other extension headers only have relevance once the packet reaches the
     destination node, and hence I would have thought that all transit nodes should
     by default just ignore them.

    Given that this document is specifically only for transit nodes where the
    packets are not destined to them, I was expecting a summary along the lines of:
     - Ignore hop by hop options unless they protocols in the transmit domain are
     making use of them. - Allow, and ignore, all other extension headers.  Maybe
     filter RH types 0 and 1 because they should not be used, but even this
     processing could be left until the destination node.

    My slight fear with the current draft is that it makes this all seem very
    complicated and protocol specific which possibly might encourage ISPs to just
    drop all packets using EHs.

    Regards,
    Rob