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

Michael Richardson <[email protected]> Mon, 22 May 2023 11:53:38 -0400

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

David Farmer <[email protected]> wrote:
    > "permissionless innovation."  That being said, we MUST balance these
    > multiple priorities. which means we can not completely sacrifice
    > "permissionless innovation" to "security" and "privacy" either.

+1

    > 1. Certain EH constructs SHOULD never be allowed; we need reasonable
    > and practical limits; I think Tom's draft makes significant progress
    > here.  2. Certain EHs SHOULD be allowed in certain places and SHOULD
    > NOT be allowed in others; this thread is at least a good starting point
    > for some recommendations along these lines.  3. Certain EHs almost
    > always need to be allowed; these need to be enumerated similarly to RFC
    > 4890 for ICMPv6.

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")

    > Dropping EHs just because they are unknown, especially by transit
    > providers, probably isn't appropriate in most situations. Dropping
    > unknown EHs by a host or by a middlebox very close to the host could be
    > appropriate, at least in some situations. Nevertheless, that doesn't
    > mean there are no EHs that it is appropriate for transit providers to
    > drop.

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.

    > third-party server, often referred to as firewall traversal. Similarly,
    > we should think about techniques for hosts wanting the communicate
    > using EHs that are not allowed on the network path between them. Maybe
    > call this EH traversal, and it likely involves a tunnel or
    > encapsulating the packet with the unknown EHs between the two
    > hosts. I'll note that adding EHs in flight is not allowed, and a common
    > technique is to add a new IPv6 header with the new EHs encapsulating
    > the old packet.

Hmm. That's an interesting idea.


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

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