Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt> (Path MTU Discovery for IP version 6) to Internet Standard

Bob Hinden <bob.hinden@gmail.com> Sun, 26 March 2017 21:23 UTC

Return-Path: <bob.hinden@gmail.com>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18840127871; Sun, 26 Mar 2017 14:23:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QJvoAqKwZy7z; Sun, 26 Mar 2017 14:23:00 -0700 (PDT)
Received: from mail-wr0-x22f.google.com (mail-wr0-x22f.google.com [IPv6:2a00:1450:400c:c0c::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60D3E126BF0; Sun, 26 Mar 2017 14:23:00 -0700 (PDT)
Received: by mail-wr0-x22f.google.com with SMTP id u1so30186156wra.2; Sun, 26 Mar 2017 14:23:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=NLt274xY80wnDd8Lx3qrFJnF65/i8bPr1S8zWExwSVY=; b=Hp61IQgzzkepINfuBAkrwRlOqXMuwkUXyFVc5juv10ABPtoSL+LFKT8tiVMMAptJBC 8GdoFUJmsPfX0+1k+L72aN2t+YpaUsnLh3dT8YppdwsPrqpLObf5ayj/lAqFeJuPpctc MFAjLSMk3vVgohx84Cw2fcFK0hfRQqGVXjNlvfElEOpoPAKoofCdgaaEjwnuU5E+kGGD CL5eN9xnfSVb/7jZ1nlIDzRlGDumw8yIqGPbtC9lTr5JD4SXN0705p26yV+PhfCR4lts HYRNyws2+/kOIVqjN/7rFzwLlkibkijboGLTsDDLpEOfN34dRxZ1B2tUNb2VrhNVTF8S c+Ag==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=NLt274xY80wnDd8Lx3qrFJnF65/i8bPr1S8zWExwSVY=; b=cXLdc4yTtxgl8nfh7CHdpArBZp9FMurLS4ExTQgJKP+tYWlaTMe7BAEnqcGJZnSwJ2 pFQE0tioIDLhEoRQ6NlKvUzRtSTLyHb2kNx8Pj4CUGBW6pYCg4G6umUxweuDYSXR3+se NAOIxtWg01T0D83/Sso7TvZ8fZtFMNM8SasXam7De/vccvYnXqy8I9uri1XotlMMS56y wcJ3LSK5h6D77mmcmBEJ/E19nv/MpBiOBskrBZogxoPvypKqlS793DtxU1s8IQTrGF0X 1o1UUo4k8qIXUWWVC/uf/LowSAxGJK1NBgWGtOpDTpfyv2njAYzFWmEIFTo0StUcjADv MRsQ==
X-Gm-Message-State: AFeK/H01xpv6CYhJeDqVEaba9gh0UiON/hiED9MCpBfPGbmo97hRQI0hJ+cULht650CM9Q==
X-Received: by 10.28.11.130 with SMTP id 124mr6916926wml.3.1490563378478; Sun, 26 Mar 2017 14:22:58 -0700 (PDT)
Received: from dhcp-9201.meeting.ietf.org (dhcp-9201.meeting.ietf.org. [31.133.146.1]) by smtp.gmail.com with ESMTPSA id l21sm12180619wrl.59.2017.03.26.14.22.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 26 Mar 2017 14:22:56 -0700 (PDT)
From: Bob Hinden <bob.hinden@gmail.com>
Message-Id: <4BC1763E-9D76-4EAA-B0B4-35620421736B@gmail.com>
Content-Type: multipart/signed; boundary="Apple-Mail=_BA125144-D743-4BD9-923D-DD79D54571BC"; protocol="application/pgp-signature"; micalg=pgp-sha512
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
Subject: Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt> (Path MTU Discovery for IP version 6) to Internet Standard
Date: Sun, 26 Mar 2017 16:22:51 -0500
In-Reply-To: <58D518EA.5000508@erg.abdn.ac.uk>
Cc: Bob Hinden <bob.hinden@gmail.com>, "tsv-area@ietf.org" <tsv-area@ietf.org>, "6man-chairs@ietf.org" <6man-chairs@ietf.org>, IPv6 List <ipv6@ietf.org>, IETF <ietf@ietf.org>, "draft-ietf-6man-rfc1981bis@ietf.org" <draft-ietf-6man-rfc1981bis@ietf.org>
To: gorry@erg.abdn.ac.uk
References: <148599312602.18643.4886733052828400859.idtracker@ietfa.amsl.com> <1859B1D9-9E42-4D65-98A8-7A326EDDE560@netapp.com> <f8291774-409e-2948-3b29-83dbb09d39d9@si6networks.com> <63eaf82e-b6d5-bff5-4d48-479e80ed4698@gmail.com> <2d36e28c-ee7d-20fc-3fec-54561e520691@si6networks.com> <C0A114C1-5E4A-4B8E-A408-55AF1E30873F@netapp.com> <3A5429F6-0EA6-436A-AF30-E55C9026F456@employees.org> <8cf1fe7d-bdfd-5e81-e61f-55d9ecd5d28a@isi.edu> <7E9AB9E8-3FCB-4475-BEEB-F18CFC4BC752@employees.org> <8076a1ea-182d-9cbe-f954-3e50f0fc53d9@isi.edu> <E11F9A4D-DE9E-4BFD-8D0D-252842719FC5@employees.org> <619f0dc52a514f07a70b44126aeb66f3@XCH15-06-08.nw.nos.boeing.com> <da3de0a5-fe7f-c874-db1d-da2684619213@si6networks.com> <706163b815ef439bbd9e0a17eba83512@XCH15-06-08.nw.nos.boeing.com> <e201c72e-b7c1-5a5f-eacb-93896cd7a7bb@si6networks.com> <58A33D08.4090505@erg.abdn.ac.uk> <804AA9E4-A643-47A3-9FCC-DA1C450E7FB1@gmail.com> <58D518EA.5000508@erg.abdn.ac.uk>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/oULfCHhW3_Lc800mBGZ3dPiqRJI>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ipv6/>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 26 Mar 2017 21:23:03 -0000

Gorry,

> On Mar 24, 2017, at 8:02 AM, Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
> 
> On 17/03/2017, 21:56, Bob Hinden wrote:
>> Gorry,
>> 
>> Thanks for the detailed review.
>> 
>> Several of the reviews have suggested significant changes to this document.  The working group was trying to make a few changes to bring it into alignment with some changes to rfc2460bis (based on updating documents).  It was not attempting a major rewrite when advancing it to Internet Standard.  The alternative that the working group discussed was to file errata on RFC1981 and leave it to a future document update.
>> 
>> I don’t think many of these changes can be done and still advance it to Internet Standard. If we can’t advance the current document, then the w.g. may want to just do the errata and withdraw the advancement request.  Of course, if people want to work on a revision of IPv6 Path MTU Discovery, it would be welcomed, but it won’t be able to advanced to Internet Standard.
>> 
>> Comments below.
>> 
>> Thanks,
>> Bob
> Thanks Bob,
> 
> I note  the question of status, but in this case, there's a lot happened in the Internet since this PS was first published, and much of this was in the transport area. Please see replies to comments below. I'm happy to discuss or refine text, if this helps.

Comments below.  Let’s get together and go over the document while we are in Chicago.  I want to make sure the changes are made correctly and in context.

Thanks,
Bob

> 
> Gorry
>>> On Feb 14, 2017, at 9:23 AM, Gorry Fairhurst<gorry@erg.abdn.ac.uk>  wrote:
>>> 
>>> 
>>> I have some late transport comments on this ID. The update seems to retain a lot of thinking that is really historical and I'd really encourage people to look again to making the document uptodate.
>>> 
>>> Detailed comments follow.
>>> 
>>> Best wishes,
>>> 
>>> Gorry
>>> 
>>> ----
>>> The following text strikes me as a little odd in an update:
>>> " Moreover, TCP implementations that follow the "slow-
>>>   start" congestion-avoidance algorithm [CONG] typically calculate and
>>>   cache several other values derived from the PMTU.  It may be simpler
>>>   to receive asynchronous notification when the PMTU changes, so that
>>>   these variables may be updated.”
>>> - A modern TCP caches at least some path information in the TCB, why start with this clause at all:
>>> "Moreover, TCP implementations that follow the "slow start" congestion-avoidance algorithm [CONG] typically calculate and”
>>> and simply replace this with something like:
>>> "TCP implementations”?
>>> ——
>> To clarify, you are suggesting to replace it with:
>> 
>>    TCP implementations typically cache several other values derived
>>    from the PMTU.  It may be simpler to receive asynchronous notification when
>>    the PMTU changes, so that these variables may be updated.
>> I think that is editorial, and OK to change.  The paragraph will read:
>> 
>>    The TCP layer must track the PMTU for the path(s) in use by a
>>    connection; it should not send segments that would result in packets
>>    larger than the PMTU.  A simple implementation could ask the IP layer
>>    for this value each time it created a new segment, but this could be
>>    inefficient.  TCP implementation typically cache several other values
>>    derived from the PMTU.  It may be simpler to receive asynchronous
>>    notification when the PMTU changes, so that these variables may be
>>    updated.
> Thanks. Seems better, although I would suggest to revise this in this way:
> 
>   A packetization layer layer (e.g., TCP) must track the PMTU
>   for the path(s) in use by a
>   connection; it should not send segments that would result in packets
>   larger than the PMTU, except to probe during PMTU discovery.
>   A simple implementation could ask the IP layer
>   for this value each time it created a new segment, but this could be
>   inefficient.  An implementation typically caches other values
>   derived from the PMTU.  It may be simpler to receive asynchronous
>   notification when the PMTU changes, so that these variables may be
>   also updated.
> 
> - This would fix typos, and also make the text relevant to transport protocols,
> rather than only TCP. Which is I beleive the correct interpretation.

I think that’s good.  I will require some other changes to the Section that is titled "TCP layer action”, let’s discuss this later.

> 
>>> The following text also seems to not reflect a modern TCP stack:
>>> " It is sufficient
>>>   to treat this as any other dropped segment, and wait until the
>>>   retransmission timer expires to cause retransmission of the segment.”
>>> (and following 3 paras).
>>> Could this be replaced by text that does not exclude modern retransmission methods:
>>> " It is sufficient
>>>   to treat this in the same way as any other dropped segment, and
>>>   will be recovered by normal retransmission methods.”
>> Yes, resulting in:
>> 
>>    When a Packet Too Big message is received, it implies that a packet
>>    was dropped by the node that sent the ICMP message.  It is sufficient
>>    to treat this in the same way as any other dropped segment, and will
>>    be recovered by normal retransmission methods.  If the Path MTU
>>    Discovery process requires several steps to find the PMTU of the full
>>    path, this could delay the connection by many round-trip times.
> Good. Seems much better.

Good.

>> 
>>> —
>>> There is a block of text that describes retransmission triggered by ICMPv6.
>>> Has this code been implemented in modern releases of TCP?:
>>> "   Alternatively, the retransmission could be done in immediate response
>>>   to a notification that the Path MTU has changed, but only for the
>>>   specific connection specified by the Packet Too Big message.”
>>> - It seems to expose a number of attack vectors that really should not be exposed!!
>> Are you suggesting remove this text?  Following this text, there are two notes.
>> 
> I'd personally remove this and the notes (you decide) - more because it says think that it opens a can of worms about transport details that are largely beyond the scope of the document (such as whether to trust ICMPv6 as indications of actual loss, and how this interacts with re-packaging to a different segment size, congetsuon control, etc).
> 
> If the WG thinks retaining some text is good, I'd say (as a cautious transport person) that we should call out a warning to people doing transmissions...
> 
> OLD:
>     If the new estimated PMTU is
>      still wrong, the process repeats, and there is an exponential
>      growth in the number of superfluous segments sent.
> NEW:
>     If the new estimated PMTU is
>      still wrong, the process repeats, and there is an exponential
>      growth in the number of superfluous segments sent.
>      Retransmissions can increase network load in
>      response to congestion, worsening that congestion.  Any
>      packetization layer that uses retransmission is responsible for
>     congestion control of its retransmissions.
> 
> If you wish, cite RFC8085 and RFC4821 to let people figure this out? (these 2 sentences come directly from RFC8085).

Ok, I think that works.

>>> ---
>>> The discussion of NFS may still be a reasonable historic example, but to be current it should really refer also to NFSv4/TCP as utlising the MTU discovery provided by TCP, since UDP-based NFS is no longer a key application.
>>> —
>> I was planning to update the reference to NFS to RFC7530.   I could add text that says something like:
> The protocol changed though - so it's not just a replacement reference.
> 
> I think text should note that RFC7530 says NFS must be able to run over a congestion-controlled transport, such as TCP.
>>    It is recommended that NFS running over TCP utilize the MTU discovery
>>    provided by TCP.
>> 
>> Other suggestions?
> Maybe, you could say something like:
> "RFC191 used NFS as an example of a UDP-based application that benefits from PMTU discovery. Since then RFC7530, states the supported transport layer between NFS
> and IP must be an IETF standardized transport protocol that is specified to avoid
> network congestion; such transports include TCP and the Stream Control Transmission Protocol (SCTP). In this case, the transport is itself responsible for determining and using an effective Path MTU, including implementing PMTU discovery when this is needed.”


> 
> RFC8085 may well be a good place to point to say what is needed/desirable for PMTU for UDP applications, if you wish to say something about UDP.

Thanks, I think that works.  Not sure if the other paragraphs on NFS should remain.


>>> There is no mention that paths including tunnels can eat ICMPv6 PTB messages on the tunnel segment, blackholing them, which prevents reaching the destination.
>> As noted above, I think adding discussion about tunnels is out of scope of this effort.
> I agree that new mechanisms are out of scope, I was hoping that a simple note on tunnels would be in the security considerations.
> 
> RFC8085 or draft-ietf-intarea-tunnels could be pointed to describe the implications of tunnels.
>>> ---
>>> I think the security consideration is naive!
>> Suggestions?
> "   In the first attack, the false message indicates a PMTU much smaller
>   than reality.  This should not entirely stop data flow, since the
>   victim node should never set its PMTU estimate below the IPv6 minimum
>   link MTU.  It will, however, result in suboptimal performance."
> 
> So... In the case of the first attack, I still question whether this choice of words misrepresents the attack.
> What if, the false message advertises ~1280 bytes, and the path uses a tunnel encapsulation transporting IPv6, then the PTB message can be basis for a straight DoS attack that does stop data flow?
> 
> I would recommend revising the security considerations (at least to something like):
> "  In the first attack, the false message indicates a PMTU much smaller
>   than reality.  In response, the
>   victim node should never set its PMTU estimate below the IPv6 minimum
>   link MTU. A sender that falsely reduces to this MTU would observe suboptimal performance."
> 
> - Although this skirts the problem.

OK, I agree this is better.

>>> This statement in particular seems to open DOS vulnerability:
>>> "
>>>  When a node receives a Packet Too Big message, it MUST reduce its
>>>   estimate of the PMTU for the relevant path, based on the value of the
>>>   MTU field in the message."
>>> - Introdueces a significant vulnerability.  A rogue PTB message that reduces the PMTU to a minimum, can result in a path too small to carry an encapsulated packet. (Recently noted by Fernando Gont).
>> Suggestions?
> See below - and above.
>>> Moreover, other layers view ICMP messages with suspicion and have long noted the need to check ICMP payload and match only packets that relate to actual 5-tuples in use (effectively reducing vulnerability to off-path attacks). For example, the Guidelines for UDP, rfc5405bis, state:
>>> 
>>> " Applications SHOULD appropriately validate the payload of ICMP
>>>   messages to ensure these are received in response to transmitted
>>>   traffic (i.e., a reported error condition that corresponds to a UDP
>>>   datagram actually sent by the application). …“
>>> - clearly handling this in IP-layer tunnels can be troublesome, but that's a problem that should be described, not obscured.
>> I could add something like the following as a new second paragraph in Section 4 Protocol Requirements:
>> 
>>   Protocols SHOULD appropriately validate the payload of ICMPv6 PTB
>>   messages to ensure these are received in response to transmitted
>>   traffic (i.e., a reported error condition that corresponds to a UDP
>>   datagram actually sent by the application).
>> 
>> or similar.
> 
> That certainly is a nod in what I think is really the correct direction.
> Probably /UDP/ should be /IPv6 packet/ given the context of this ID.

Good, I think that makes sense.

>> 
>>> ——
>>> 
>>> I’d finally  like to add my concerns about the understatement of the value of PLPMTUD, which seems to not reflect the recommendations to use this method:
>>> “  It defines a method for Packetization Layer Path
>>>   MTU Discovery (PLPMTUD) designed for use over paths where delivery of
>>>   ICMP messages to a host is not assured.”
>>> This  seems under-stating the value and recommendations to deploy PLMTUD, compared with current transport-area recommendations, for instance, the UDP Guidelines provide much more on this important design consideration:
>> 
>> The w.g. spent a lot of time on this paragraph.  The intent was to point to it, but not into detail of how it worked, nor make it a new requirement.  There was some discussion that adding more detail about the relationship between PTMUD and PLPMTUD in the ongoing update to IPv6 Node Requirements would be helpful.
> 
> I appreciate people have spent time trying to get the IPv6 specifications progressed to standards status. This is a good effort, but I think just adding a nod in the introduction is rather feeble for soemthing now recommended. I think at least the security considerations should motivate the benefits of this approach (see next).
>>> "   Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821] does not
>>>   rely upon network support for ICMP messages and is therefore
>>>   considered more robust than standard PMTUD.  It is not susceptible to
>>>   "black holing" of ICMP message.  To operate, PLPMTUD requires changes
>>>   to the way the transport is used, both to transmit probe packets, and
>>>   to account for the loss or success of these probes.  This updates not
>>>   only the PMTU algorithm, it also impacts loss recovery, congestion
>>>   control, etc.  These updated mechanisms can be implemented within a
>>>   connection-oriented transport (e.g., TCP, SCTP, DCCP), but are not a
>>>   part of UDP, but this type of feedback is not typically present for
>>>   unidirectional applications."
>>> 
>>> ----
>>> 
>>> The examples used in the definition of  "upper layer" and "link" also makes this document appear as historic, rather than a new RFC!
>> As noted above, I think there would be support for a rewrite if some folks wanted to take that on.
> Could the WG consider to also add the first two sentences to the security considerations?

Sorry, which two sentences?

> 
> Gorry
> 
> P.S. A few more out-dated statements abiut TCP, based on the way specific stacks work when the original was written:
> 
> - The phrase below needs to be removed also, since not all TCP stacks behave in this way anymore:
> ", which is always a multiple of the segment size"
> 
> - There was very specific detailis relating to 4.2BSD TCP implementations, which would have been better not being here.
> 
> 

OK, I can remove both.