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

Joe Touch <touch@isi.edu> Thu, 16 February 2017 16:00 UTC

Return-Path: <touch@isi.edu>
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 18B011295F3; Thu, 16 Feb 2017 08:00:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level:
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 2z_PEEV2yxMq; Thu, 16 Feb 2017 08:00:34 -0800 (PST)
Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) (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 6892B12962E; Thu, 16 Feb 2017 08:00:28 -0800 (PST)
Received: from [192.168.1.189] (cpe-172-250-240-132.socal.res.rr.com [172.250.240.132]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id v1GFxSao006367 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 16 Feb 2017 07:59:30 -0800 (PST)
Subject: Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt> (Path MTU Discovery for IP version 6) to Internet Standard
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> <ed4e3ab5-e93e-d9ca-28c0-43f8bf22039a@isi.edu> <2fc3beb1-86d1-2436-71e1-a90c525cb0d6@erg.abdn.ac.uk>
From: Joe Touch <touch@isi.edu>
Message-ID: <2eb7f087-571e-d2be-2c57-1d287f443ad7@isi.edu>
Date: Thu, 16 Feb 2017 07:59:27 -0800
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.1
MIME-Version: 1.0
In-Reply-To: <2fc3beb1-86d1-2436-71e1-a90c525cb0d6@erg.abdn.ac.uk>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Archived-At: <https://mailarchive.ietf.org/arch/msg/ipv6/lOwgr0C5BuJjbUD1uvEZDSMt2jI>
Cc: "tsv-area@ietf.org" <tsv-area@ietf.org>, "6man-chairs@ietf.org" <6man-chairs@ietf.org>, 6man WG <ipv6@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "draft-ietf-6man-rfc1981bis@ietf.org" <draft-ietf-6man-rfc1981bis@ietf.org>
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.17
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: Thu, 16 Feb 2017 16:00:36 -0000

Hi, Gorry,


On 2/16/2017 6:08 AM, Gorry Fairhurst wrote:
>
> The text below is not about tunnels - this is about  the operation of
> transport, and the quoted text is from the new UDP Guidelines ID.
Oh - I was distracted by some of the text then - see below...

>
> On 15/02/2017 21:26, Joe Touch wrote:
>> Hi, Gorry (et al.),
>>
>> Again, the following text should not drift into discussing how tunnels
>> are handled IMO. That should be addressed in a different document (and I
>> don't think it's troublesome at all if viewed correctly).
>>
>> Joe
>>
>>
>> On 2/14/2017 9:23 AM, Gorry Fairhurst wrote:
>>> - Introduces 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). .

The issue is the IPv6 limit. Issues of "encapsulated packets" not
fitting in this limit are already handled by transport protocols using
IPv6 (if this is about layering encapsulation) and tunneling (if this is
about tunneling, which is how I inferred "encapsulated packets").

>>>
>>> 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). …“
>
> The comment below could easily be handled by something that clearly
> indicates the problem and points to the tunnel draft for guidance, I
> agree no need to go into algorithms/methods here.

The problem isn't unique to tunnels - it happens on any link whose MTU
can vary, and IMO the solution is the same. React to the change in
subsequent traffic, rather than attempting to rely in ICMP relaying from
signaling inside the link layer -- regardless of that link layer.

Joe

>
>>> - clearly handling this in IP-layer tunnels can be troublesome, but
>>> that's a problem that should be described, not obscured.
>>
>
> Gorry