Subject: [pmtud] Improvement for the current PMTUD mechanism

From: Fernando Gont <[email-masked]>
Date: Mon, 05 Sep 2005 13:24:51 -0300

Folks,

Since August 2004 I have been woeking on an internet-draft on ICMP attacks 
against TCP. One of the attacks the draft addresses is a "blind 
performance-degrading attack" in which the traditional PMTUD is exploited 
to reduce the size of the packets used for a given connection.

We (me, and the community, including "traditional" vendors, open source 
ones, etc.) have been able to work out an improvement to the current PMTUD, 
to mitigate its security implications.

The fix just tries to address that. By no means is it an alternative to 
PLPMTUD. For instance, it does not address ICMP blackholes.

I'd like to get feedback from this WG on the PMTUD fix. I think the 
proposed mechanism could be used in some broader PMTUD such as PLPMTUD, so 
that ICMP can be used without the security implications of the traditional 
PMTUD, and thus the same convergnece time than the tradtional PMTUD could 
be achieved.

The draft will soon be available from the internet-drafts public 
repository. In the mean time, you can access it through my web site: 
http://www.gont.com.ar/drafts/draft-gont-tcpm-icmp-attacks-04.txt 
(http://www.gont.com.ar/drafts/icmp-attacks-against-tcp.html)

Kindest regards,

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

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

---

From: John Heffner <[email-masked]>
Date: Fri, 30 Sep 2005 16:31:52 -0400

Fernando,

I've read over the PMTUD-related section of your draft.  Here are a few
comments.

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.  You may consider incorrect operation in this case worth the
trade-off, but it should at least be explicitly documented.

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.  We have similar constraints for MTU probing, and
we're addressing this issue more directly in the next revision of
draft-ietf-pmtud-method.

One small suggestion is that it might be natural to use "R1" from RFC 1122
instead of specifying the new variable MAXSEGRTO.  This variable indicates
how long to wait before deciding the connection is making no progress.  This
may be what you're looking for, or possibly not.  But reusing an existing
variable does make implementation easier. :)

Thanks,
  -John

---

From: Fernando Gont <[email-masked]>
Date: Fri, 30 Sep 2005 20:33:47 -0300

John,

>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?

>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.

>may be what you're looking for, or possibly not.

I think R1 has a different meaning.

MAXSEGRTO would be set, in principle, to 1. That is, you would wait for one 
RTO, which is the amount of time you assume is enough for the segment to 
get to the remote endpoint and get acknowledged.

MAXSEGRTO could beset to some larger value in case you assume more varying 
network conditions, either because of the networking environment, or 
because of congestion caused by an attacker hitting your link.

Thanks so much for your feedback!

---

From: John Heffner <[email-masked]>
Date: Fri, 30 Sep 2005 22:37:20 -0400

> 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.

Using any value for MAXSEGRTO > 1 would result in this situation as 
well even without fast retransmit working.

   -John