Subject: [pmtud] Comments in response to WGLC of PLPMTUD (rev-07)

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 06 Jul 2006 15:09:57 +0100

Please see comments below on the current draft.

Best wishes,

Gorry

(Matt - could you post to the list if this "bounces", I'm working from my
laptop as I travel to the IETF and don't have access to my other "gf"
account from here).

--------------------

* The title does not contain the abbreviation: PLPMTUD - this would greatly
help people searching titles to locate the RFC.

* page 11, section 4, para 2.
"limited clock stabilities"
- the scenario and implications of this is not clear.

* page 16, section 6.1, para 3.
- Mention is made of SACK blocks, it would be good to also cite RFC4341,
DCCP-CCID2:
   DCP CCID 2 uses an ACK Vector that provides information equivalent
   to that transmitted in a TCP SACK option.

* page 18, section 7.2 (and section 7.7, 8)
- I like the use of 512 as an acceptable common minimum MTU in the current
IPv4 Internet, but this is by no means a required value. If PLPMTUD sets
this as a minimum, what can be done if the discovery fails to find a path
that supports this MTU? It would be a shame to have this "black-holed".

Allowing PLPMTUD to drive the PMTU of a flow down to the minimum for IPv4
appears to me to expose a much bigger DoS threat.  IPv4 ICMP messages which
suggest such small MTUs may be a big performance hinderance to hosts and
routers.

One other option available only in IPv4, would be to enable "IP Router
Fragmentation - but clearing the DF bit". Is this good, evil or acceptable?

* Section 7.6.
- This section does not make use of RFC2119, it seems that some of these
cases should use "SHOULD" or "MUST". Was this intentional?

* Page 21, section 7.6.1, first para
- So what must the node do when the reported result of a probe is successful
for a smaller PMTU than that which is currently in use. Is this a case where
the probe should be treated as successful, but the probe value should be
ignored?

* Section 7.8
- This looks good.

* Section 10
- RFC4340 describes DCCP's Path MTU discovery mechanisms, in section 14.
This seems to be compatible with that described for SCTP and DCCP in the
current document. Can text be added to describe intended DCCP behavior with
PLPMTUD? (I can work with you on this text, if it helps).

   "DCCP also allows upward probing of the PMTU [PMTUD], where the DCCP
   endpoint begins by sending small packets with DF set and then
   gradually increases the packet size until a packet is lost.  This
   mechanism does not require any ICMP error processing.  DCCP-Sync
   packets are the best choice for upward probing, since DCCP-Sync
   probes do not risk application data loss.  The DCCP implementation
   inserts arbitrary data into the DCCP-Sync application area, padding
   the packet to the right length.  Since every valid DCCP-Sync
   generates an immediate DCCP-SyncAck in response, the endpoint will
   have a pretty good idea of when a probe is lost."

* Page 27
-  I don't particularly like the idea of probing the return path MTU at the
same time as the forward path MTU (i.e. Using an ECHO mechanism). There does
not seem to be any need for a sender to know the MTU of the return path...
For example, a corner case in the use of ICMP-ECHO-REQUEST to probe for
bandwidth is that this actually performs a bi-directional test for the PMTU
probe size. Paths exist that have assymmetric properties (e.g. Scenarios
described in RFC3449), where the response to the probe mail fail, even
though the PMTU in the forward direction was accepted. Section 10.4 also
talks about the idea of probing the return path.

* Page 27, final para
(e.g., 1kBytes or less)
- Is this thinking directed to IPv4?
- Would this better be 512B for IPv4 and 1280 for IPv6 to be consistent with
earlier?

* Security Considerations
- See above. IMHO, it is worth stressing the performance vulnerability of
setting an outrageously small PMTU size in IPv4.

---------------------------------------------

NiTs for the authors:

* The abstract does not include the definition of the abbreviation: PLPMTUD.

* The abstract does not include the abbreviation: PMTUD, which would be
helpful. 

* Is section 1.1 to be removed by the RFC Ed?

* page 6, section 2, para 2
/protocols which/protocols that/

* page 8 top para
PTB should be defined in the text.

* page 11, section 4, para 1.
/in order to/to/

* page 20, section 7.4
/Section Section/Section/

* page 20, section 7.2 (what is "it"?)
/the loss to detect it/a loss to detect it/

* page 20, section 7.5
/equal the probe/equal to the probe/

* Page 25, section 9
/Diagnostic application are/ Diagnostic applications are/

* Page 25, section 9
/be be/be/

* Page 25, section 9
/a probes/a probe/

* Security Considerations
/Such and/Such an/

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

---

From: John Heffner <[email-masked]>
Date: Wed, 12 Jul 2006 10:57:57 -0400

Thanks for reviewing.  Comments inline below.

> laptop as I travel to the IETF and don't have access to my other "gf"

There are devices that can deliver packets of a certain size with some
probability depending on the packet's size and other factors such as
temperature.  Such devices should use an MTU sufficiently low such that
they can reliably (for some definition of reliably) deliver packets of
that size.  The text could probably be a little clearer here.

>    to that transmitted in a TCP SACK option.

We haven't put anything specifically about DCCP in this doc.  We might
consider doing so (it wasn't ready yet before), but it could also be a
separate draft.  We can talk about this...

> suggest such small MTUs may be a big performance hinderance to hosts and

We're not specifying any real change to how ICMPs are processed.  Most
systems today have a configurable lower bound on MTU, and that's not
likely to change.  However, with black hole detection described in 7.7
(lowering MTU in response to persistent timeout), you can actually
support even smaller MTUs while maintaining the limit on ICMPs.

> Fragmentation - but clearing the DF bit". Is this good, evil or acceptable?

I think that qualifies as evil. ;)

Packets sent with the DF bit set usually have zeroed IP ID fields, and
reassembly would be impossible.  Unless the router also set the IP ID,
but then you're getting yourself into a mess... per address-pair state,
etc. in the router.

> cases should use "SHOULD" or "MUST". Was this intentional?

Yes.  We felt like 2119 language here was unnecessarily strict for most
of this section, as it's describing a somewhat flexible method that
might have room for future refinement.  I think all the really critical
stuff has 2119 language.

> the probe should be treated as successful, but the probe value should be

In such a case, it wouldn't be entirely ignored -- you still set
search_low, while eff_pmtu remains the same.  So, it doesn't have an
immediate observable effect, but you do make a state change.

> talks about the idea of probing the return path.

Probing both paths is less than ideal, but is conservative in that if 
the probe succeeds, you know the forward path is capable.  We view pings 
as a sort of last resort if you can't do anything else.

> - Would this better be 512B for IPv4 and 1280 for IPv6 to be consistent with

This is describing an initial eff_pmtu, not a search_low (which would be
512 or 1280) like described in the initial values section.  If you are
using ipv6, something larger than 1k would be appropriate, so we could
change the text to "(e.g., 1280 bytes or less)".  OTOH, it's not
unreasonable to try 1k regardless of protocol.  It saves you from
needing separate config values for both ipv4 and ipv6.  This text is
really only a hint, not specifying anything.  We can try to clarify this 
better.

> setting an outrageously small PMTU size in IPv4.

Possibly.  We're not really specifying changes to the ICMP processing
though, so that might not be in scope.  I guess it couldn't hurt to
mention it?

Thanks again for the comments.  Will pull in the nits and try to fix up 
some of the muddy parts.

   -John

---

From: Gorry Fairhurst <[email-masked]>
Date: Wed, 12 Jul 2006 19:59:00 -0400

So it seems that mostly you have good answers to the issues, thanks very
much (see in-line comments that follow).

Gorry

----

On the point below, are you SURE?

I would like this to receive more consideration. The language seems that it
already does say things like " In this case alone, ...", " is the one
situation under which", " it is required that", " At this point" etc. -
which makes it seems like these are important to correct. Using standards
keywords also helps to ensure consistency of behaviour.

----- Other comments -----

> that size.  The text could probably be a little clearer here.
I think it would be nice to see some new text that more clearly sets out
what the example is, and how this property impact MTU.

> separate draft.  We can talk about this...
IMHO, it should at the least say something.

As you say, it could also point to another document.

> support even smaller MTUs while maintaining the limit on ICMPs.
OK

> but then you're getting yourself into a mess... per address-pair state,
What you say could indeed be "evil", but that was not what I was suggesting.

I was suggesting the SENDER could revert to clearing the DF and then
re-sending (presumably with a suitable IP ID field). This could offer a
mitigation when receiving an ICMP with an unexpectedly low PMTU indication,
and could be less vulnerable to off-path forged PTB messages. This could
also have side-effects.

> immediate observable effect, but you do make a state change.
Aha - now understood.

> as a sort of last resort if you can't do anything else.
Fine. Maybe you could check that it says this?

> really only a hint, not specifying anything.  We can try to clarify this
I think someone should choose a number as an example, putting one in the RFC
at least gives the possibility of consistent approaches across platforms,
nice when looking at packet traces.

> though, so that might not be in scope.  I guess it couldn't hurt to
I think the text could perhaps say something like, "This protocol does not
modify the processing of ICMP PTB messages, however the small miminimum
packet size defined in IPv4 has a vulnerability in that ...."

> Thanks again for the comments.  Will pull in the nits and try to fix up
Thanks.