Subject: [pmtud] Agenda for PMTUD at IETF 62 in Minneapolis

From: Matthew J Zekauskas <[email-masked]>
Date: Thu, 03 Mar 2005 14:37:23 -0500

Here's the agenda for pmtud at IETF 62.  If anyone has
any comment, or additional issues, do let us know,
either on the mailing list or directly to the chairs.

--Matt

Path MTU Discovery WG (pmtud)
Tuesday, March 8, 15:30--16:30
=====================================

CHAIRS: Matt Mathis <[email-masked]>
        Matt Zekauskas <[email-masked]>

AGENDA:

1. Agenda bashing, milestones review [5 min]

2. PMTUD method draft issues [30 min]
   --Matt Mathis

   http://www.ietf.org/internet-drafts/draft-ietf-pmtud-method-04.txt

3. PMTUD method draft implementation experience [15 min]
   --John Heffner
   --others

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

---

From: Fernando Gont <[email-masked]>
Date: Fri, 04 Mar 2005 03:13:18 -0300

>either on the mailing list or directly to the chairs.

I don't think any of the issues I raised on the mailing-list about a month 
ago have been addressed in the latest revision on the draft.

Also, unless you are planning to discuss the as part of "PMTUD method draft 
issues [30 min]", it doesn't seem they will be discussed at the IETF, either.

I will re-send my post to the mailing-list.

Thanks!

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

---

From: Matt Mathis <[email-masked]>
Date: Sat, 5 Mar 2005 16:07:52 -0500 (EST)

Sorry, this was my overload.   Our push since the last IETF has been to get a
running implementation, and although I intended to incorporate all the markups
that various people submitted, we didn't get to many of them.  I know that this
is very uncool, but I have been very busy.   We will not loose them.

About global changes to ICMP processing: this is really beyond the TCPM and
PMTUD working groups.   I hope we discuss it in TSVWG.

I see our work here as gating some of the possible global ICMP changes because
as far as I know RFC1191 is the only protocol or algorithm that requires ICMP
for correct operation.  (please correct me if I am wrong).  PLPMTUD alleviates
that requirement thereby creating the opportunity to reclassify all ICMP as
soft-error/advisory, with uniform processing for all messages along the lines
described in section 6.2.1 of the pmtud-method draft.   (Which has been my
goal all along - it is just out of scope for this working group.)

As to checking TCP sequence numbers inside of ICMP, yes of course.  That is a
no brainer.  I don't think anybody has suggested that is a bad idea.

However, you have to be careful about how you characterize your proposal.  On a
scale of "security {wall,fence,curb,speed-bump}", checking sequence numbers is
a security curb.  Unconditionally tossing all ICMP is a security wall.  They
are not even in the same league.  Security people get really hostile about over
hyped security features because they create an illusion of security where it
may not be warranted.  I suspect that if you rephrased you proposal as "enhanced
consistency checking for ICMP", there would be no debate.

Yes we can talk about this some more at the WG.

Best regards,
--MM--
-------------------------------------------
Matt Mathis      http://www.psc.edu/~mathis
Work:412.268.3319    Home/Cell:412.654.7529
-------------------------------------------
Evil is defined by people who think they know
"The Truth" and use force to apply it to others.

---

From: Fernando Gont <[email-masked]>
Date: Sat, 05 Mar 2005 21:13:35 -0300

>is very uncool, but I have been very busy.   We will not loose them.

I did not mean the issues I raised should have been implemented, but rather 
that they should have been mentioned in the latest revision of the draft.

Some of them were not even conceptual (i.e., "hard to document", if you 
want), but errors in the existing spec, such as considering IPv4's minimum 
MTU to be 576 bytes, rather than 68 bytes (as specified by the current specs).

>PMTUD working groups.   I hope we discuss it in TSVWG.

While I agree that the changes proposed in my draft could be extrapolated 
to other transport protocols, my draft proposes changes to TCP (only). 
That's why I don't think it's beyond the scope of TCPM.

As for the PMTUD-related stuff, the changes proposed in my draft could be 
adopted by PLPMTUD, so that you can decrease the current convergence time 
of PLPMTUD, a pretty safe fashion.

>for correct operation.  (please correct me if I am wrong).

I disagree. The changes proposed in my draft are needed, anyways. The 
current specs leave the door open to blind connection-reset attacks and 
blind throughtput-reduction attacks. The current specs state that ICMP 
Source Quench messages should be honored to throttle down the connection, 
and that the so-called ICMP "hard errors" should cause connections to be 
aborted.

It's not only PMTUD that pushes the changes to the existing specs.

>  PLPMTUD alleviates

I think it's a great idea to make PMTUD do not *depend* on ICMP messages, 
as we all know all the problems this has. However, completely ignoring ICMP 
error messages eads to long convergence times.

The PMTUD-specific fix proposed in my draft could be incorporated so that 
the convergence time of PLPMTUD for connections that have just been 
established is greatly reduced, while still keeping the connection 
protected from attack.

Note that I'm not talking about just the TCP SEQ checking, but, about the 
PMTUD-specific fix, which involves dividing PMTUD into to phases: Initial 
PMTU Discovery (i.e., the connection has just been established) and PMTUD 
Update (when you want to *reduce* the assumed Path-MTU).

This basically means: Perform the TCP SEQ check and honor ICMP messages for 
connections that have just been established, but be conservative after that 
initial phase.

>no brainer.  I don't think anybody has suggested that is a bad idea.

I agree with you that this is a no brainer. However, a couple of folks did 
argue against it on the TCPM WG mailing-list.

>a security curb.  Unconditionally tossing all ICMP is a security wall.

As mentioned above, the TCP SEQ checking is a general counter-measure. 
Specific counter-measures are proposed for each of the possible attacks.

For the PMTUD, the counter-measures include, at some point, requiring 
segments to time-out before honoring ICMP "Packet Too Big" error messages. 
If an attacker is able to drop packets from the coresponding connection, I 
don't think there's much sense in trying to DoS the connection by means of 
performing the PMTUD attack.

Best regards,