Re: [tcpm] PLPMTUD for all protocols

[Toerless Eckert <[e-mail]>]

William,

Thanks for making suggestions how the network can behave
better, no idea why i am starting to give up on that idea *sigh*

This part of the discussion would probably be better on [e-mail]

more inline.

On Fri, Mar 30, 2018 at 08:44:46AM -0400, William Herrin wrote:
> My thoughts run this direction:
> 
> 1. Recommend that router implementations "SHOULD" provide the option
> to generate ICMPv4 type 3 code 4 (fragmentation needed) messages and
> ICMPv6 type 2 (packet too big) messages from an address different than
> the source interface address. They Dan't today, creating lots of cases
> where the operator has to sacrifice PMTUD.

rfc1918/ULA on interfaces plus RPF later on ?
SP edge filtering of IF-address ranges ?
Any other known systematic reasons ?

Would be good to document systematic reasons to make sure suggested
workarounds can fix them.

The main problem iwth such a command is to make operators not forget
applying it. Or even having an address that would allow for the packet
to be passed back.

> 2. Recommend that firewall implementations "SHOULD NOT" filter ICMPv4
> type 3 code 4 (fragmentation needed) messages or ICMPv6 type 2 (packet
> too big) messages unless explicitly configured to do so. In other
> words, the instruction to filter all ICMP will not result in dropping
> fragmentation needed messages but the explicit instruction to drop
> fragmentation needed messages specifically will. Today's firewall
> tools make it too easy to accidentally kill PMTUD.

I am a lot more pessimistic of any form of IETF recommendation to
impact firewalls positively. At its core, most IETF design does not
even acknowledge the need for firewalls and has not designed network
services for their presence. I would also bet there are possible
attack vectors with ICMP fragmentation needed messages. And what else
does a fireall operator need to break something...

We can try of course. I think these days the way how you would be
achieve something like that is to define some YANG model that
contains the equivalent of such commands - You can make such a YANG
model standards track. CLI recommendations at best are BCP.

> Let's maximize the chance of PMTUD working as designed and then build
> something optimized for the residual cases where it still doesn't.
> 
> > Write rfc4821bis with recommendations for an additional,
> > simplified procedure dropping to 1280/576 and use most simple upspeeding
> > option ?
> 
> That is #3. And I'd like to be smart about fallback at the expense of
> efficiency in the black hole case. Send the 1280 packet. If it works,
> send another full size packet to confirm it still fails before
> accepting 1280 as the path mtu. If the 1280 and 576 packets don't work
> either, don't try the fallback again: it's not path mtu. Maybe the RFC
> is already smart about this; I didn't read closely enough.
> 
> 4. Go back to the ground truths and reconsider whether we have
> satisfactory information at layer 3 to make reliable decisions about
> path mtu. Because of the fate sharing issue, I think PMTUD wants to be
> a layer 4 problem implemented independently in each layer 4 protocol
> with layer 3 offering hints from ICMP when available. Maybe this is
> something that should be kicked over to the IRTF for investigation.

Sure, you can bring the problem to PANRG.

The main issue is that cool new solutions will not fix broken old
equipment, so most efforts we seem to spend in IETF are about
workarounds for that broken old equipment (points 1..3).

And every time you try to
do something new & better, you get hammered down by IETF with
"oh, this will take a decade to see any adoption, go away". 

> Regards,
> Bill Herrin
> 
> 
> -- 
> William Herrin ................ [e-mail]  [e-mail]
> Dirtside Systems ......... Web: <http://www.dirtside.com/>
> 
> _______________________________________________
> tcpm mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tcpm

-- 
---
[e-mail]