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

On 22-May-23 22:03, Ole Troan wrote:
> It depends on your position in the network.
> 
> A) Transit AS:
> Should transparently pass all traffic and not look beyond the 40-byte IPv6 header.
> 
> With the exception of NH=0.
> Let’s have that discussion if there ever is a HBH option with “transit AS applicability”.
> 
> B) Limited Domain
> 
> C) Modern application
> With modern applications, it has become blurry where the application ends and the network starts.
> Where the “application” is disaggregated, embeds a custom network stack for it’s purpose.
> Has a set of IP addresses representing the “service”, but those addresses does in no way represent an interface on a host.
> That “cluster” of services is only going to support the functions that the application needs.
> An EH would essentially be a side channel here.
> 
> D) Enterprises
> What Fernando says.
> 
> It’s somewhat ironic that 25 years in, this debate is still hypothetical.
> “What if we ever got an EH that has Internet wide applicability”

Actually, we do: SHIM6. It failed to deploy for two main reasons:

1. Folks are blocking IPv6 extension headers. (For world-wide testing of SHIM6, we had to bypass firewalls at both sites involved.)

2. Some operators disliked SHIM6 precisely because it gave end-hosts control over path selection, thereby potentially bypassing traffic engineering. (For world-wide testing of SHIM6, we had to persuade ops people to install source routes.)

    Brian

> (and for the sake of argument I’ve rebranded ESP to a tunnel encap).
> 
> O.
> 
>> On 21 May 2023, at 23:28, Brian E Carpenter <brian.e.carpenter@gmail.com> wrote:
>>
>> On 21-May-23 21:33, Fernando Gont wrote:
>>> Hi, Tom,
>>> On 18/5/23 15:27, Tom Herbert wrote:
>>> [....]
>>>>>>
>>>>>> So, I’m not really happy with the all or nothing approach the two of you
>>>>>> seem to be offering for IPv6 extension headers, is there something in
>>>>>> between? If not, then maybe that is what we need to be working towards.
>>>>>
>>>>> FWIW, I[m not arguing for a blank "block all", but rather "just allow
>>>>> the ones you really need" -- which is a no brainer.
>>>>
>>>> Fernando,
>>>>
>>>> I'm not sure how that's a no brainer, who decides "the ones you really
>>>> need"?
>>> Typically. whoever runs the destination AS or network. Or the transit
>>> AS, if the packets will affect the transit AS.
>>
>> And there's the problem. The operator of a large network cannot possibly
>> know which extension headers every host on the network needs. It's
>> called permissionless innovation, and is supposed to be one of the main
>> success factors for the Internet.
>>
>>>> If everyone independently makes that decision then we wind up
>>>> with an Internet that can't evolve and is perpetually stuck in the
>>>> status quo.
>>> Well, yes, there's no big brother making decisions about mine or your
>>> networks' policies.... hence everyone makes decisions independently.
>>
>>  From the point of view of hosts, there is an anonymous Big Brother, the
>> moment that any upstream operator blocks a wanted extension header.
>>
>>> (IN a way that's why QUIC runs on top of UDP ... although in the case of
>>> QUIC, I bet it has more to do with NATs thatn with explicit firewalling)
>>
>> It's to do with *any* barrier to IP layer transparency. This is a very
>> basic tussle in the architecture.
>>
>>    Brian
>>
>>>>> The list you need
>>>>> is, maybe Frag and, say, IPsec at the global level? (from the pov of
>>>>> most orgs).
>>>>>
>>>>> (yeah... HbH and the like are mostly fine for the local link (e.g. MLD).
>>>>>
>>>> It might be productive if you suggested a more concrete direction
>>>> here. Maybe a proposed BCP suggesting the EHs that you believe should
>>>> be universally blocked and the rationalization for that and why the
>>>> problems with them can't be fixed.
>>> Are your referring to the "transit AS" case, the "dest AS/network" case,
>>> or both?
>>> In any case, my comment was simply a two-liner email comment, as opposed
>>> to full-fledged advice.
>>> Thanks!
>>> Regards,
>> _______________________________________________
>> v6ops mailing list
>> v6ops@ietf.org
>> https://www.ietf.org/mailman/listinfo/v6ops
> 
> 
> 