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

[Gorry Fairhurst <gorry at erg.abdn.ac.uk>]

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

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

On 12/7/06 10:57, "John Heffner" <jheffner at psc.edu> wrote:

> Thanks for reviewing.  Comments inline below.
> 
> 
> Gorry Fairhurst wrote:
>> 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.
> 
> 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.
> 
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.

>> * 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.
> 
> 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...
> 
IMHO, it should at the least say something.

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

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

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

> 
>> * 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?
> 
> 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.
> 
Aha - now understood.

>> * 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.
> 
> 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.
> 
Fine. Maybe you could check that it says this?

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

>> * Security Considerations
>> - See above. IMHO, it is worth stressing the performance vulnerability of
>> 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?
> 
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
> some of the muddy parts.
> 
Thanks.

>    -John
> 



_______________________________________________
pmtud mailing list
pmtud at ietf.org
https://www1.ietf.org/mailman/listinfo/pmtud