Re: [Int-area] WG Adoption Call: IP Fragmentation Considered Fragile

[Christian Huitema <[e-mail]>]

On 8/30/2018 5:26 PM, Joe Touch wrote:
>
>
>> On Aug 29, 2018, at 11:19 PM, Christian Huitema <[e-mail]
>> <mailto:[e-mail]>> wrote:
>>
>>> Regardless, middleboxes shouldn't be avoiding their own effort by
>>> creating work for others. A corollary to the Postal Principle should
>>> be "you make the mess, you clean it up". 
>>
>> Joe's stubborn adherence to the letter of the RFC would be very nice
>> if the protocol police could somehow punish the merchants of NATs…
>
> My concerns are pragmatic - merely not supporting something does not
> make it unnecessary.
>
> There was a time when Internet service in hotels would regularly block
> all except basically DNS and HTTP/HTTPS; that’s becoming much less the
> case. There was a time when devices didn’t support IPv6 at all because
> it was considered merely an unnecessary expense; that’s becoming much
> less the case too.
>
> In this case, we have two problems 
> 1) NATs/firewalls as currently implemented do not support fragments
> 2) our current protocols, in many cases, require fragments (IPsec
> tunnel mode) and in other cases (tunnels in general) would benefit
> from IP fragmentation support
> 3) we DO NOT HAVE an alternative (there are some piece-wise proposals
> for various aspects, but none support IPsec tunnel mode and none are
> otherwise universal
>
> Yes, something needs to be done, but I argue that *until we have a
> worked alternative*, we need to keep restating the fact -
> NATs/firewalls MUST reassemble to work properly; where they don’t, the
> error is on them - not the rest of the Internet for using fragments.
>
>> The whole discussion reminds me of Martin Thomson's draft, "use it or
>> lose it" (draft-thomson-use-it-or-lose-it-02). Martin is describing
>> how extension mechanisms that are not actually used get ossified away
>> by the deployment of middle-boxes. The same happened long ago with IP
>> segmentation. With NATs, applications cannot assume that reassembly
>> will work. With Firewalls, transports cannot assume that ICMP will work. 
>
> Yes, that’s the tension:
> a) identify bugs and fix them
> b) accept bugs as de-facto protocol evolution
>
> The problem with (b) is that it is not guided by what Internet users
> need; it’s guided by what is profitable for individual vendors. That
> path is hazardous - there’s no reason to believe that the result will
> be a useful Internet. So until we know it’s safe to do (b), we need to
> stick with (a).

Shouting from the hilltops is not sufficient. We can very well do it,
but our voice is not very loud, and our hill is not very tall. Fixes
happen when there is some customer pressure, as in "your bug blocks some
application that many customers love." I just don't see any application
putting pressure on NATs and firewalls to support fragmentation. HTTP,
email, or Web RTC seem to be working just fine. It may be that IPSEC and
some tunnels do not work in theory, but VPNs do work in practice. It may
be that protocol stacks could clean up some of their kludges if
fragmentation worked, but the market does not care a whole lot about
that. And without such pressure, the protocol police is not going to be
very effective.

By the way, the biggest issue is not so much fragmentation as
black-holing. One thing is for a NAT to not support reassembly. Another
is to get a fragment and just drop it without telling anything to
anyone. Or even worse, forward an initial-but-incomplete fragment and
drop the other fragments, all that without telling anything to anyone.
Strategically, that may well be where to put the pressure. Reassembly
requires state and memory, but sending an ICMP at most requires some
form of rate control. That should not be too hard.

Of course, then we will have to convince firewalls to not drop these
ICMP packets. But there the dynamics are manageable, because the
firewalls dropping the ICMP and the servers that could benefit from them
are often managed by the same folks. So maybe there is some hope after all.

-- Christian Huitema