Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt> (Path MTU Discovery for IP version 6) to Internet Standard
Gorry Fairhurst <gorry@erg.abdn.ac.uk> Wed, 15 February 2017 08:22 UTC
Return-Path: <gorry@erg.abdn.ac.uk>
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 7BF481294CD; Wed, 15 Feb 2017 00:22:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.131
X-Spam-Level:
X-Spam-Status: No, score=-2.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
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 f41AFD9NQ-zU; Wed, 15 Feb 2017 00:22:33 -0800 (PST)
Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [139.133.204.173]) by ietfa.amsl.com (Postfix) with ESMTP id 602F5129446; Wed, 15 Feb 2017 00:22:33 -0800 (PST)
Received: from Gs-MacBook-Pro.local (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPA id 2939D1B001C9; Wed, 15 Feb 2017 10:19:51 +0000 (GMT)
Message-ID: <58A33D08.4090505@erg.abdn.ac.uk>
Date: Tue, 14 Feb 2017 18:23:20 +0100
From: Gorry Fairhurst <gorry@erg.abdn.ac.uk>
Organization: University of Aberdeen
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:12.0) Gecko/20120428 Thunderbird/12.0.1
MIME-Version: 1.0
Subject: Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt> (Path MTU Discovery for IP version 6) to Internet Standard
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>
In-Reply-To: <e201c72e-b7c1-5a5f-eacb-93896cd7a7bb@si6networks.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/Sf4Jwc4i7DGLTk8npwg9TXE6k2g>
Cc: 6man WG <ipv6@ietf.org>, "draft-ietf-6man-rfc1981bis@ietf.org" <draft-ietf-6man-rfc1981bis@ietf.org>, "tsv-area@ietf.org" <tsv-area@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "6man-chairs@ietf.org" <6man-chairs@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: gorry@erg.abdn.ac.uk
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: Wed, 15 Feb 2017 08:22:36 -0000
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”? —--- 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." — 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!! --- 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. --- There is no mention that paths including tunnels can eat ICMPv6 PTB messages on the tunnel segment, blackholing them, which prevents reaching the destination. --- I think the security consideration is naive! 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). 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’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: " 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!
- Last Call: <draft-ietf-6man-rfc1981bis-04.txt> (P… The IESG
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Fernando Gont
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Eggert, Lars
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Fernando Gont
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Eggert, Lars
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Fernando Gont
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Brian E Carpenter
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Eggert, Lars
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… otroan
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Eggert, Lars
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Eggert, Lars
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Eggert, Lars
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… otroan
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Fernando Gont
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Brian E Carpenter
- RE: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Templin, Fred L
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Fred Baker
- RE: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Templin, Fred L
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Eggert, Lars
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… otroan
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Bob Hinden
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Joe Touch
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… otroan
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Joe Touch
- RE: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Templin, Fred L
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Joe Touch
- RE: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Templin, Fred L
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… otroan
- RE: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Templin, Fred L
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Joe Touch
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… otroan
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Joe Touch
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… otroan
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Joe Touch
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Fernando Gont
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Fernando Gont
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Fernando Gont
- RE: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Templin, Fred L
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Fernando Gont
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Gorry Fairhurst
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Joe Touch
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Joe Touch
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Gorry Fairhurst
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Gorry Fairhurst
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Joe Touch
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Gorry Fairhurst
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Joe Touch
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Gorry Fairhurst
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Joe Touch
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Bob Hinden
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Gorry Fairhurst
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Bob Hinden
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Gorry Fairhurst
- Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt… Bob Hinden