Subject: [pmtud] Some comments on draft-ietf-pmtud-03

From: Fernando Gont <[email-masked]>
Date: Wed, 19 Jan 2005 09:43:53 -0300

Folks,

I have read draft-ietf-pmtud-03 method, and have some comments on it. I 
have not yet sync'ed with the discussions you have had both on-list and at 
the IETF. So some of these issues may have already been raised.

On page 8, the draft says:
"  In the most conservative configuration, from a security point of
    view, all ICMP PTB messages are ignored, and PLPMTUD is the sole
    method used to discover the path MTU.  This protects against
    malicious or erroneous ICMP PTB messages which might otherwise cause
    MTU discovery to arrive at the incorrect MTU for a path."
For connection-oriented protocols, you can usually process ICMP PTB without 
much *real* risk. I have authored a draft on ICMP attacks against TCP 
(draft-gont-tcpm-icmp-attacks-03.txt), which proposes, among other things, 
to have TCP check the sequence number contained in the payload of ICMP 
error messages. I think this should be mentioned in draft-ietf-pmtud-03. 
Also, the draft-gont-tcpm discusses the attack against th PMTUD mechanism, 
and proposes a minor modification to the PMTUD mechanism so as to protect 
from this attack. The proposed modification does not address blackholes, as 
the draft is meant to propose security counter-measures, rather than 
improving the functionality of the mechanism.

Page 19: At the risk of sounding "my" (*) own horn, I'd include a reference 
to draft-gont-tcpm-icmp-attacks-03.txt, which discusses a number of checks 
TCP can perform on the received ICMP error messages.
(*) The TCP sequence number check has been performed by Linux for *years*. 
Also, the whole draft has been discussed with many vendors, most of them 
from the Open Source community (Linux and *BSD).

Page 20: It says
"     If there was not a accepted PTB Message, then the indicated event
       is a "probe failure", which can be retried with a smaller probe
       size after a suitable delay for a probe_fail_event.  See section
       6.2.2 for more complete descriptions of failure events."
Note that *this* is Section 6.2.2, so I'd probably remove the last sentence.

Page 21: It says
"      It is important that the Packetization Layer
       retransmission machinery distinguish between loses at the old MTU
       (transition phase) and the provisional MTU (the verification
       phase, discussed next)."
I'm confused by that of "old MTU". As far as I can understand, during the 
ttransition phase you do use the provisional MTU. At least, page 18 says 
"The packetization layer provisionally raises the MTU to the probe 
size.  PLPMTUD enters the transitional phase when it starts sending data 
using the provisional MTU.".
Am I missing something?

Page 22: It says
"  The default IPV4
    restart_MTU should be the minimum MTU as specified by IPv4 (576
    Bytes)[1]."
Note that the minimum IPv4 MTU is 68, and not 576. If you use 576, then if 
there's an intervening link with a MTU of 296, none of your packets will 
get through.

Page 27: It says
"  While
    this is not difficult for most potential Packetization Layers, there
    are a few (e.g.  ISO TP4 [ISOTP]) that are not allowed to repacketize
    when doing a retransmission. "
Note that the ISO TP4 standard is not listed in the "References" section 
(Section 10).

Page 27: It says
"  Unresolved problem: what to do about very short flows?  No
    verification phase?  @@@@@"
The original counter-measure against the PMTUD proposed in 
draft-gont-tcpm-icmp-attacks was just to act on ICMP PTB when there was a 
RTO for the corresponding segment. However, this also meant that several 
RTOs could be required for the PMTUD mechanism to discover the actual Path 
MTU. I discussed this issue extensively with developers from major open 
source OSs, and they were not willing to have this penalty (i.e., How would 
you explain the user it takes too long to get a 1Kbyte web page?). We came 
up with an engineering solution to this problem: Divide the PMTUD into two 
phases "Initial PMTU Discovery" and "PMTU Update". Basically, in the 
"Initial PMTUD" you honor ICMP PTB as soon as you get them (provided they 
pass the corresponding security checks). On the other hand, in the "PMTU 
Update" phase you do wait for a RTO. I think this idea could be integrated 
in draft-ietf-pmtud-03.

Page 28: It says
"      SEARCH_LOW is the largest validated MPS, the same as them current
       MPS in use by the packetization layer.  The initial value for
       SEARCH_LOW is described in section 7.4."
Note that Section 7.4 does not describe this. Not explicitly, at least.

Page 29, first line: It says
"      SEARCH_HIGH is the least invalidated MPS.  In most cases is will"
s/least/last/
s/is will/it will/

Page 30: It says "   @@@@@ common link MTUs are: 1500......  ?"
RFC 1191 provides some data. I'd use it as a base, and then 
add/delete/modify it as as appropriate.

Page 32, "Probing method using TCP":
How about sending a packet that includes both data that has already been 
acked, and also *new* data?
Say I want to produce a 1044 TCP segment. This segment would include 512 
bytes of data that have already been acked, plus 512 bytes of *new* data 
(ie.e. that have never been sent), plus the 20-byte TCP header, making a 
TCP segment of 1044 bytes. This is sort of having "padding bytes". Just 
thinking out loud, though.

Page 33: It syas "
    The default action for an unknown chunk types in the
    range 128 to 190, (high bits = 10 ) is to "Skip this chunk and
    continue processing" [RFC2960] - exactly the required behavior for a
    PAD chunk.  "
May be the reference to RFC 2960 was hardcoded in the draft? (rather than 
included as an xml tag).

Page 36, "Probing method for applicatons"
I'd argue strongly against having applications concern with the PMTU. Not 
only from an architectural point of view, but because they may never do it.

Page 37: The references to the "Fragmentation considered harmful papers" 
([@@harm1] and [@@harm2]) should be linked to those listed in the 
"References" section. The same for "[@@NFS]".

Page 38, section 9.3: I'd also mention those tunnels meant for connecting 
IPv6-islands.

Page 39, last para: s/Tool/Too/  (two instances)

Page 39, last apra: s/lost lost/lost/

Page 42: Is there any reason for which the "Security Considerations" are 
included as an appendix, rather than a normal section?

Two additional issues:

* I think the draft should discuss the interaction with ECN. i.e., what 
should we do when congestion is being signalled by means of ECN?

* I'm concerned with how long it takes proposed mechanism to discover the 
initial PMTU for the connection. As stated above, I think the workaround 
proposed in draft-gont-tcpm-icmp-attacks could be integrated into this draft.

These are the more conceptual comments. Will come back with some more 
editorial notes I have marked in my printed copy of the draft.

Hope these comments are useful.

Thanks!

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

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