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

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

Folks,

These are the issues I raised about a month ago.

>Delivered-To: [email-masked]
>X-Sender: [email-masked]
>X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
>Date: Wed, 19 Jan 2005 09:43:53 -0300
>To: [email-masked]
>From: Fernando Gont <[email-masked]>
>X-Spam-Score: 0.0 (/)
>X-Scan-Signature: 3971661e40967acfc35f708dd5f33760
>Cc: Matt Mathis <[email-masked]>
>Subject: [pmtud] Some comments on draft-ietf-pmtud-03
>X-BeenThere: [email-masked]
>X-Mailman-Version: 2.1.5
>List-Id: Path Maximum Transmission Unit Discovery <pmtud.ietf.org>
>List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pmtud>,
>         <mailto:[email-masked]?subject=unsubscribe>
>List-Archive: <http://www1.ietf.org/pipermail/pmtud>
>List-Post: <mailto:[email-masked]>
>List-Help: <mailto:[email-masked]?subject=help>
>List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pmtud>,
>         <mailto:[email-masked]?subject=subscribe>
>Sender: [email-masked]
>
>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

Thanks!

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

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