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

Fernando Gont <fgont@si6networks.com> Thu, 09 February 2017 21:09 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 741F5126D74; Thu, 9 Feb 2017 13:09:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.851
X-Spam-Level:
X-Spam-Status: No, score=-0.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_12_24=1.049, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no 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 e3-kY8sjw7ym; Thu, 9 Feb 2017 13:09:32 -0800 (PST)
Received: from fgont.go6lab.si (fgont.go6lab.si [91.239.96.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 060471295BF; Thu, 9 Feb 2017 13:09:32 -0800 (PST)
Received: from [192.168.3.83] (142-135-17-190.fibertel.com.ar [190.17.135.142]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by fgont.go6lab.si (Postfix) with ESMTPSA id 05B9B80F4F; Thu, 9 Feb 2017 22:09:24 +0100 (CET)
Subject: Re: Last Call: <draft-ietf-6man-rfc1981bis-04.txt> (Path MTU Discovery for IP version 6) to Internet Standard
To: "Templin, Fred L" <Fred.L.Templin@boeing.com>, "otroan@employees.org" <otroan@employees.org>, Joe Touch <touch@isi.edu>
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>
From: Fernando Gont <fgont@si6networks.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <e201c72e-b7c1-5a5f-eacb-93896cd7a7bb@si6networks.com>
Date: Wed, 08 Feb 2017 19:35:50 -0300
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <706163b815ef439bbd9e0a17eba83512@XCH15-06-08.nw.nos.boeing.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/lVwBBKOpXcYkB57DUnM5u19Hgi8>
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: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 09 Feb 2017 21:09:33 -0000

Hi, Fred,

On 02/08/2017 01:35 PM, Templin, Fred L wrote:
>>>
>>> Also not to be lost in this discussion is the potential for spoofed ICMP messages
>>> that would report a size that is either too large or too small.
>>
>> RFC5927 is all about this.
> 
> Right. The point is that these data points would seem to indicate that standard
> PMTUD per rfc1981bis is not reliable nor secure enough for operation on open
> internetworks such as the global public Internet. Maybe the security section
> should say that?

PMTUD as per rfc1981bis is certainly not reliable, since ICMPv6 messages
are not reliable (actually, ICMP itself is obviously unreliable, but the
widespread filtering of ICMPv6 messages results in more deterministic
failures)

"security"-wise, you can improve things to a decent level. e.g., for TCP
based traffic all IPv6 implentations check the TCP sequence number (and
por numbers) in the embedded packet.

Besides, if you look at RFC5927, there a PMTUD-specific mitigation which
essentially means that during the life of a connection, upon receipt of
an ICMP PTB, you save the message, but only honor the message if there's
not progress on the connection. -- somehow mimicking RFC4821.

So I'd say that the issue with PMTUD is mostly reliability than security.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492