Subject: Re: [pmtud] Improvement for the current PMTUD mechanism

From: John Heffner <[email-masked]>
Date: Mon, 3 Oct 2005 23:24:31 -0400

On Sep 30, 2005, at 7:33 PM, Fernando Gont wrote:

>> It might be a good idea to add some text about layering issues. 
>> Classic PMTUD
>> occurs at both the IP and TCP layers.  In implementations with which 
>> I'm
>> familiar, the ICMP message is processed by the IP layer, updating the 
>> pmtu in
>> the route cache, then the message is demuxed and passed down to TCP, 
>> which
>> updates is MSS and retransmits the packet.  To implement these the 
>> algorithm you
>> describe, you'll need the ability for TCP to be able to "override" 
>> the IP
>> layer's idea of the pmtu.
>
> This is not the case in NetBSD's and OpenBSD's PMTUD implementations. 
> I can't speak for Linux and FreeBSD, though.

I'm less familiar with BSD implementations than I am with Linux.  
However, my observations are largely based on the recommendations of 
RFC 1191, sections 6.1 and 6.2 regarding processing and storing 
information for pmtud.  If your recommendations are contrary to this, 
it is probably worth documenting.

More generally, there are issues with sharing pmtu information between 
various protocols.  If you have a pmtu discovered by a connectionless 
UDP protocol, can you use this value in TCP?  Can UDP use TCP's values? 
  What about a pmtu discovered by SCTP?  If no state is shared at all, 
it can be more expensive to do the discovery repeatedly for every 
protocol.  As an implementor, I wouldn't mind seeing some discussion on 
these issues and the trade-offs involved.

Thanks,
   -John

_______________________________________________
pmtud mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/pmtud

---

From: Fernando Gont <[email-masked]>
Date: Wed, 05 Oct 2005 19:12:50 -0300

At 11:37 p.m. 30/09/2005, John Heffner wrote:

>>>One thing to consider is the case where one flow is traversing multiple 
>>>paths
>>>concurrently.  In the algorithm you describe, in this case it's likely a 
>>>host
>>>will ignore the ICMP PTB messages since it can still make progress, but
>>>ignoring them is clearly the wrong thing to do and will drastically hurt
>>>performance.
>>
>>No, it won't. As long as the segment claimed by the ICMP PTB has been 
>>dropped (which will always be the case for legitimate ICMP PTBs), the 
>>Path-MTU will be updated.
>>
>>Or am I missing something?
>
>Using the algorithm specified in section 7.2 of 
>draft-gont-tcpm-icmp-attacks-04, imagine the following scenario.  Some 
>packets take a path with pmtu 1500, and every nth packet takes a path with 
>pmtu < 1500.  So the first n-1 packets get through fine and are 
>acked.  The nth packet will be lost and an ICMP PTB message sent back.
>The segment is fast-retransmitted and will get through, causing the 
>delayed response to the ICMP to become no response.  This will continue 
>indefinitely, with a loss rate of 1/n.

Good point. I think the simple answer to this issue is to disable "fast 
retransmit" when there's a pending ICMP message. What do you think?

(As a side note, I'm not sure the behavior you describe would happen in 
practice. Particularly because of TCP's slow-start algorithm. As there are 
only a few segments "in flight" just after connection establishment or a 
period of idleness, in many cases there won't be enough duplicate ACKs for 
fast retransmit to be triggered. Anyway, as the fix to the point you raised 
is pretty simple and inoffensive, that's the easier way to go).

P.S.: I beg your pardon for the delay in my response.

--
Fernando Gont
e-mail: [email-masked] || [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Wed, 05 Oct 2005 19:34:44 -0300

At 12:24 a.m. 04/10/2005, John Heffner wrote:

>>>It might be a good idea to add some text about layering issues. Classic 
>>>PMTUD
>>>occurs at both the IP and TCP layers.  In implementations with which I'm
>>>the route cache, then the message is demuxed and passed down to TCP, which
>>>describe, you'll need the ability for TCP to be able to "override" the IP
>>This is not the case in NetBSD's and OpenBSD's PMTUD implementations. I 
>>can't speak for Linux and FreeBSD, though.
>
>However, my observations are largely based on the recommendations of RFC 
>1191, sections 6.1 and 6.2 regarding processing and storing information 
>for pmtud.  If your recommendations are contrary to this, it is probably 
>worth documenting.

Can you mention any specific point in which it is contrary?

>various protocols.  If you have a pmtu discovered by a connectionless UDP 
>protocol, can you use this value in TCP?  Can UDP use TCP's values?

Yes. Basically: You receive the ICMP message. You handle it to TCP. TCP 
processes the message as recommended. Then you signal the Network Layer the 
MTU it should use. And every transport protocol instance which has the same 
host as the remote end-point will be notified, so that they reduce the 
amount of data they pass down to the network layer accordingly.

>What about a pmtu discovered by SCTP?  If no state is shared at all, it 
>can be more expensive to do the discovery repeatedly for every 

Yes, the state is shared. SO there's no problem.

Even then, I'd probably argue that given policy-based routing, sharing PMTU 
information might not be a good idea in all cases.

Thanks!

---

From: John Heffner <[email-masked]>
Date: Mon, 10 Oct 2005 14:10:53 -0400

> amount of data they pass down to the network layer accordingly.

If I'm an attacker, I will attack UDP instead of TCP.  These ICMPs cannot have 
the additional checks on them specified in draft-gont-tcpm-icmp-attacks.  If 
the MTU from these ICMPs is put in the IP route cache, and TCP uses it, then 
the additional ICMP checks for TCP are of no benefit.  If TCP does not use 
this IP cache value because it is considered too weak, then this is a 
departure from the normal mode of operation and should be specified.

  -John

---

From: John Heffner <[email-masked]>
Date: Mon, 10 Oct 2005 14:23:16 -0400

> retransmit" when there's a pending ICMP message. What do you think?

This concerns me because it could have real side effects beyond pmtud.  This 
might be a topic for tcpm.

> is pretty simple and inoffensive, that's the easier way to go).

It does feel like a corner case, probably difficult to trigger.  But I think 
it would be hard to prove it never happens, particularly if you consider all 
possible future behaviors of TCP (with modified slow start or retransmit 
algorithms).

  -John

---

From: John Heffner <[email-masked]>
Date: Mon, 10 Oct 2005 16:00:29 -0400

One more comment that just occurred to me.  The ICMP checking fails in the 
case of gear that doesn't honor the DF bit (that is, sends an ICMP but also 
fragments and forwards the packet despite the DF bit).  This is an issue we 
discussed at some pmtud meetings.

I think such gear can be considered broken for a number of reasons (and is 
certainly not standards compliant) but does supposedly exist in the wild.  It 
might be worth documenting this case.

  -John

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Oct 2005 10:22:47 -0300

>might be worth documenting this case.

As stated in my draft, my proposal does not address the issue of blackholes 
or broken implementations.
It's an *improvement* for the current PMTUD mechanism, rather than a 
replacement for it.

PLPMTUD (for example) is still needed to address these issues.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 11 Oct 2005 10:00:50 -0300

At 03:10 p.m. 10/10/2005, John Heffner wrote:

>If I'm an attacker, I will attack UDP instead of TCP.

Many systems implement PMTUD for TCP, but not for UDP.

>These ICMPs cannot have

Agreed. Will address this in the next revision of the draft.

Thanks!

---

From: John Heffner <[email-masked]>
Date: Tue, 11 Oct 2005 15:03:31 -0400

On Tuesday 11 October 2005 09:22 am, Fernando Gont wrote:
> >case of gear that doesn't honor the DF bit (that is, sends an ICMP but
> > also fragments and forwards the packet despite the DF bit).  This is an
> > issue we discussed at some pmtud meetings.
> >
> >certainly not standards compliant) but does supposedly exist in the wild. 
> > It might be worth documenting this case.
>

This is not a black hole issue.  In this case, classical pmtud works fine but 
adding in a loss check causes pmtud to "fail" such that all packets get 
fragmented.  This is not a total connection failure like a black hole, but is 
bad for a number of reasons.

http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf
http://www.psc.edu/~jheffner/drafts/draft-mathis-frag-harmful-XX.html

  -John

---

From: Fernando Gont <[email-masked]>
Date: Wed, 12 Oct 2005 17:25:35 -0300

>bad for a number of reasons.

I disagree. If packets get fragmented, then PMTUD is simply NOT working. 
Those implementations are simply broken. There may be other crazy behaviors 
out there.

>http://www.psc.edu/~jheffner/drafts/draft-mathis-frag-harmful-XX.html

Yes, I'm aware of these papers, and have already read them.

---

From: Fernando Gont <[email-masked]>
Date: Sun, 16 Oct 2005 16:02:17 -0300

>might be a topic for tcpm.

Actually, this cannot have interoperation problems. IIRC, TCP congestion 
control is not mandatory.
And even then, fast retransmit is not specifically congestion control. If 
anything, I'm proposing to slow down the packet rate, rather than 
increasing it. (i.e. being more conservative).

>possible future behaviors of TCP (with modified slow start or retransmit

Will address this in the next revision of my draft.

Kindest regards,

---

From: John Heffner <[email-masked]>
Date: Mon, 17 Oct 2005 16:08:40 -0400

On Sunday 16 October 2005 03:02 pm, Fernando Gont wrote:
> >This concerns me because it could have real side effects beyond pmtud. 
> > This might be a topic for tcpm.
>

In point of fact TCP congestion control is a MUST per RFC 1122, but this is 
entirely separate from the issue at hand. :-)

Any change to standards constraining how or when TCP may recover from a loss 
is pretty significant.  I think it is a discussion topic for tcpm.

  -John

---

From: Fernando Gont <[email-masked]>
Date: Sun, 23 Oct 2005 05:15:29 -0300

>possible future behaviors of TCP (with modified slow start or retransmit

Even then, I'm not sure this is behavior would be a bug, or a feature.

If one out of every four packets gets forwarded through the small-MTU link, 
then one should still consider whether assuming the Path-MTU is that of the 
smallest-MTU path is better than assuming the Path-MTU is that of the 
larger MTU.

If on one path the MTU is, say, 296 bytes, and on the other path the MTU 
is, say, 18000 bytes, then someone might argue it's better to lose one 
packet out of four, than to waste a large amount of bandwidth in headers of 
lots of 296-bytes packets.

Even then, it's so simple to address this case (by disabling 
fast-retransmit when there's a pending ICMP message) that I don't think one 
should worry about it. Disabling fast-retransmit while there's a pending 
ICMP PTB is simply being more conservative.

Kindest regards,