Re: [Edm] Please review draft-iab-use-it-or-lose-it-01

[Brian E Carpenter <[e-mail]>]

On 19-Jul-21 14:24, Martin Thomson wrote:
> On Mon, Jul 19, 2021, at 11:54, Brian E Carpenter wrote:
>>> The unexpected participation observation doesn't really apply to the IP version example as you have to expect that every router on path needs to participate.
>>
>> Not really. That's what Router Alert is all about. I'm saying it is 
>> much of a success, but it recognized from the start that not all 
>> routers are equal.
>>
>> The ineffectiveness of both RFC2113 and RFC2711 illustrates that there 
>> is fundamentally no difference between IPv4 Options and IPv6 Extension 
>> Headers in this respect. The network is equally ossified and opaque to 
>> new ones in both cases.
> 
> Oh, the options/header extension mess is multi-dimensional.  I didn't get the impression that misuse at the root of the problem, 

I don't think so. There is a 3-way tussle here between the realities of line-speed routing hardware, a tendency by protocol designers to assume that routers are general-purpose computers with lots of time to analyse packet headers, and the desire of firewall vendors to block anything suspicious, including anything new.

By way of anecdote, when my student a few years ago deployed the SHIM6 header extensions between the University of Auckland and a site in Ireland, we had to circumvent firewall rules at both sites in order to do so; traversing the wide-area Internet was no problem at all. But "greasing" those site firewalls simply isn't a meaningful concept; they *exist* to prevent unknown stuff getting through.

The generic issue is that any mechanism that requires an intermediate system to analyse a transport header (or, worse, a payload) at line speed is stymied by unexpected IPv6 extension headers. You can't say "don't do that" when doing so is a requirement, as it is for firewalls and server load balancing to name but two cases. (We tried to fix this problem for server load balancing with RFC7098, but I'm not sure we succeeded.)

> though your first reference implies that it might be.  I'm not following that work closely to say that it is the only problem here or even if it is the main problem.  
> 
> Do you think that it is worth talking about here?  A one paragraph contribution that talked about the Router Alert Option/EH might help.  if only to highlight how this is not always caused by bugs, but it can be interaction with policies that participants might choose to implement (that look like bugs).  To some extent, that's consistent with the SIP intermediation story, which is dominated by policy.

I certainly think the point is worth mentioning, if only as a case where greasing probably won't help.

    Brian