Re: [IPv6] [v6ops] Why folks are blocking IPv6 extension headers? (Episode 1000 and counting) (Linux DoS)

Michael Richardson <[email protected]> Mon, 22 May 2023 19:33:04 -0400

Newsgroups	gmane.ietf.opsec,gmane.ietf.v6ops,gmane.ietf.ipv6
Message-ID	<13042.1684798384@localhost>

David Farmer <[email protected]> wrote:
    >> I think that many of us are still reeling from default configuration
    >> of certain "firewalls" that banks seemed like, which dropped packets
    >> containing ECN, and TCP options, and made it very very difficult to
    >> deploy new things.  Even when at the IETF standards level... (so
    >> "innovation with permission")

    > So, I think we need "permissionless innovation" at the Internet level.
    > Nevertheless, that doesn't mean "innovation with permission" isn't
    > appropriate in some or even many situations. For example, in a
    > situation involving public safety, like a nuclear reactor or a missile
    > control system. We can all agree that "permissionless innovation" isn't
    > necessarily appropriate in situations like these.

Just to be clear: this means that the SSL/HTTPS VPN that let's Homer Simpson
do safety work from home, stops working when the browser-OS is upgraded with ECN,EH,etc.

    >> I guess I'd be okay if it were the EH itself that was dropped, but I
    >> suspect it's still the entire packet.  I don't even really want to
    >> drop the EH, so much as write over it with an EH that is blank.  I
    >> don't think that's a defined action.
    >>

    > If it's not ok to add an EH on the fly, why should it be ok to remove
    > or blank it out? We only allow relatively minor alterations to EHs on
    > the fly, removing or completely blanking them out seems too far.

Well, I agree: neither should be allowed.
So, why should it be okay to blank the ENTIRE PACKET?


--
Michael Richardson <[email protected]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

signature.asc (application/pgp-signature, 515 B)