Re: [pmtud] Comments in response to WGLC of PLPMTUD (rev-07)
Gorry Fairhurst <gorry@erg.abdn.ac.uk> Wed, 12 July 2006 23:59 UTC
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0obr-0004gJ-Og; Wed, 12 Jul 2006 19:59:15 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G0obq-0004fq-Qp for pmtud@ietf.org; Wed, 12 Jul 2006 19:59:14 -0400
Received: from [2001:630:241:204:203:baff:fe9a:8c9b] (helo=erg.abdn.ac.uk) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G0obp-00049h-WF for pmtud@ietf.org; Wed, 12 Jul 2006 19:59:14 -0400
Received: from [142.131.134.110] ([142.131.134.156]) (authenticated bits=0) by erg.abdn.ac.uk (8.13.4/8.13.4) with ESMTP id k6CNwxTh020152 (version=TLSv1/SSLv3 cipher=DES-CBC3-SHA bits=168 verify=NOT); Thu, 13 Jul 2006 00:59:01 +0100 (BST)
User-Agent: Microsoft-Entourage/11.2.4.060510
Date: Wed, 12 Jul 2006 19:59:00 -0400
Subject: Re: [pmtud] Comments in response to WGLC of PLPMTUD (rev-07)
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
To: John Heffner <jheffner@psc.edu>
Message-ID: <C0DB0504.5B80%gorry@erg.abdn.ac.uk>
Thread-Topic: [pmtud] Comments in response to WGLC of PLPMTUD (rev-07)
Thread-Index: AcamDyTfYymBnRICEdu+kwAKlc/qXg==
In-Reply-To: <44B50DF5.2070904@psc.edu>
Mime-version: 1.0
Content-type: text/plain; charset="US-ASCII"
Content-transfer-encoding: 7bit
X-ERG-MailScanner: Found to be clean
X-ERG-MailScanner-From: gorry@erg.abdn.ac.uk
X-Spam-Status: No
X-Spam-Score: 0.0 (/)
X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e
Cc: mathis@psc.edu, pmtud@ietf.org
X-BeenThere: pmtud@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Path Maximum Transmission Unit Discovery <pmtud.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/pmtud>, <mailto:pmtud-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/pmtud>
List-Post: <mailto:pmtud@ietf.org>
List-Help: <mailto:pmtud-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/pmtud>, <mailto:pmtud-request@ietf.org?subject=subscribe>
Errors-To: pmtud-bounces@ietf.org
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@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@ietf.org https://www1.ietf.org/mailman/listinfo/pmtud
- [pmtud] Comments in response to WGLC of PLPMTUD (… Gorry Fairhurst
- Re: [pmtud] Comments in response to WGLC of PLPMT… John Heffner
- Re: [pmtud] Comments in response to WGLC of PLPMT… Gorry Fairhurst