Subject: [tcpm] ICMP attacks draft (issue 4): Make the current PMTUD mechanism more cautious

From: Fernando Gont <[email-masked]>
Date: Fri, 23 Sep 2005 08:14:08 -0300

Folks,

Issue 4:
While there's ongoing work for designing a *new* PMTUD, we are still 
dealing with the "old" (RFC1191) one, and will probably have to do so for a 
number of years.
My draft basically proposes to wait for an RTO before honoring an ICMP 
"fragmentation needed and DF bit set". We basically want to check progress 
on the connection. If there's progress, the error message must be false.

(The draft also includes a little workaround to avoid waiting several RTOs 
the first time you have to discover the Path-MTU).

By no means this is an alternative for the PLPMTUD of the PMTUD WG. It's 
just an improvement to the *current* PMTUD, to mitigate it's security 
implications.

OpenBSD and NetBSD (at least) are have been implementing this mechanism for 
the last few months.

Comments?

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

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

---

From: Joe Touch <[email-masked]>
Date: Fri, 23 Sep 2005 07:34:25 -0700

Fernando Gont wrote:
> dealing with the "old" (RFC1191) one, and will probably have to do so
> for a number of years.
> "fragmentation needed and DF bit set". We basically want to check
> progress on the connection. If there's progress, the error message must
> be false.

Again, an assertion that ignores correct operation. In this case, there
could be multiple alternate paths with different MTUs.

IMO, changes to interpretation of ICMP that argue based on 'connection
progress' should be made in the PMTUD document, and are not appropriate
as a separate document.

> (The draft also includes a little workaround to avoid waiting several
> RTOs the first time you have to discover the Path-MTU).

Further reason to take this idea to the PTMUD WG.

> just an improvement to the *current* PMTUD, to mitigate it's security

Perhaps, but this isn't the best place to discuss it, IMO.

Joe