RE: Treatment of ICMP for PMTU
Lucas Pardue <Lucas.Pardue@bbc.co.uk> Wed, 27 June 2018 21:26 UTC
Return-Path: <Lucas.Pardue@bbc.co.uk>
X-Original-To: quic@ietfa.amsl.com
Delivered-To: quic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D320130E33 for <quic@ietfa.amsl.com>; Wed, 27 Jun 2018 14:26:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=unavailable 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 IoVSL-4zQJYq for <quic@ietfa.amsl.com>; Wed, 27 Jun 2018 14:26:40 -0700 (PDT)
Received: from mailout0.cwwtf.bbc.co.uk (mailout0.cwwtf.bbc.co.uk [132.185.160.179]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02815130E2A for <quic@ietf.org>; Wed, 27 Jun 2018 14:26:39 -0700 (PDT)
Received: from BGB01XI1008.national.core.bbc.co.uk (bgb01xi1008.national.core.bbc.co.uk [10.161.14.22]) by mailout0.cwwtf.bbc.co.uk (8.15.2/8.15.2) with ESMTP id w5RLQZDP015496; Wed, 27 Jun 2018 22:26:35 +0100 (BST)
Received: from BGB01XUD1012.national.core.bbc.co.uk ([10.161.14.10]) by BGB01XI1008.national.core.bbc.co.uk ([10.161.14.22]) with mapi id 14.03.0389.001; Wed, 27 Jun 2018 22:26:35 +0100
From: Lucas Pardue <Lucas.Pardue@bbc.co.uk>
To: "Lubashev, Igor" <ilubashe=40akamai.com@dmarc.ietf.org>, Martin Duke <martin.h.duke@gmail.com>, IETF QUIC WG <quic@ietf.org>
Subject: RE: Treatment of ICMP for PMTU
Thread-Topic: Treatment of ICMP for PMTU
Thread-Index: AdQOVlbAt8rn27zdQrag9H62mpvY5wABihw5
Date: Wed, 27 Jun 2018 21:26:34 +0000
Message-ID: <7CF7F94CB496BF4FAB1676F375F9666A3BB5B9DC@bgb01xud1012>
References: <924fbd75dbcf4d62a9062570b0d2ba5a@ustx2ex-dag1mb5.msg.corp.akamai.com>
In-Reply-To: <924fbd75dbcf4d62a9062570b0d2ba5a@ustx2ex-dag1mb5.msg.corp.akamai.com>
Accept-Language: en-GB, en-US
Content-Language: en-GB
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.19.161.211]
x-exclaimer-md-config: c91d45b2-6e10-4209-9543-d9970fac71b7
Content-Type: multipart/alternative; boundary="_000_7CF7F94CB496BF4FAB1676F375F9666A3BB5B9DCbgb01xud1012_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/nXARH3R9siWADm9i1UnWqml33E4>
X-BeenThere: quic@ietf.org
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Main mailing list of the IETF QUIC working group <quic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/quic>, <mailto:quic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/quic/>
List-Post: <mailto:quic@ietf.org>
List-Help: <mailto:quic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/quic>, <mailto:quic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 27 Jun 2018 21:26:42 -0000
Hi Igor, If we consider tunnelling of QUIC within QUIC by means of a proxy (not currently specced anywhere but feasible), the tunnelled (end-to-end) path MTU is likely to be smaller than the hop-by-hop path MTUs. It may not be possible for the proxies to pass on ICMP in a way that the the tunnelled QUIC implementation can access it. (D)PLPMTUD seems to fit this case nicely as there can be two or more PLPMTUD contexts/values (one for the connection to the proxy, one for each tunnel within this connection). Lucas ________________________________ From: QUIC [quic-bounces@ietf.org] on behalf of Lubashev, Igor [ilubashe=40akamai.com@dmarc.ietf.org] Sent: 27 June 2018 21:36 To: Martin Duke; IETF QUIC WG Subject: Treatment of ICMP for PMTU I have a PR for treatment of ICMP for PMTU (https://github.com/quicwg/base-drafts/pull/1412) Many thanks to those who gave me ample feedback (both substantive and editorial). I’ve tried to incorporate it all. There are two technical issues that @Martin Duke<mailto:martin.h.duke@gmail.com> and I believe deserve a broader discussion with the group. 1. Is processing ICMP signals (and, especially, ICMP Packet Too Big signal) a MAY or a SHOULD? In the WG draft, processing ICMP is a MAY, but implementing PLPMTUD (RFC4821) is a SHOULD. However, PLPMTUD claims itself to be an extension of ICMP-based PMTUD process. So it makes sense to me that if PLPMTUD is a SHOULD, then ICMP itself is a SHOULD. QUIC implementations w/o access to ICMP would not be able to implement the ICMP part, and this is ok albeit unfortunate; and this also points to SHOULD (skipping on MAY is not "unfortunate"). 1. What to do, when an IPv4 ICMP (w/o on-path proof) request a PMTU reduction (after handshake)? There are three main options: ignore it, reduce your PMTU estimate, do not reduce but send PLPMTUD probes. Since this is very likely a valid signal, I do not like to ignore in the common case. Hence, the proposal is to allow an immediate PMTU reduction to up to some M, where 1280 ≤ M ≤ 1500. Once the reduction takes place, the endpoint can use PLPMTUD recommendations to see if it can probe a larger PMTU. If this sounds reasonable, then the question is picking M. I picked 1392 rather arbitrarily (GRE over IPsec + a few MPLS labels). If the requested reduction is 1280 ≤ X < M, then the recommendation is not to reduce but send PLPMTUD probes. Does this make sense, or should we have M=1280 and simplify things? Note: for ICMP w/ on-path proof, I think it makes sense to allow a reduction in PMTU up to 1280. It is hard to forge these, and the benefit of the effort for the attacker is minimal (slightly lower efficiency of the transport). So it is less likely that we’ll see forged ICMP w/ on-path proof. Any feedback is very welcome. * Igor
- RE: Treatment of ICMP for PMTU Lucas Pardue
- RE: Treatment of ICMP for PMTU Mikkel Fahnøe Jørgensen
- Re: Treatment of ICMP for PMTU Gorry (erg)
- Treatment of ICMP for PMTU Lubashev, Igor
- RE: Treatment of ICMP for PMTU Lubashev, Igor
- RE: Treatment of ICMP for PMTU Lucas Pardue
- RE: Treatment of ICMP for PMTU Lucas Pardue
- RE: Treatment of ICMP for PMTU Lucas Pardue
- RE: Treatment of ICMP for PMTU Lucas Pardue
- Re: Treatment of ICMP for PMTU Eggert, Lars
- RE: Treatment of ICMP for PMTU Lubashev, Igor
- RE: Treatment of ICMP for PMTU Mikkel Fahnøe Jørgensen
- RE: Treatment of ICMP for PMTU Mikkel Fahnøe Jørgensen
- Re: Treatment of ICMP for PMTU Gorry (erg)
- RE: Treatment of ICMP for PMTU Lubashev, Igor
- RE: Treatment of ICMP for PMTU Lubashev, Igor
- Re: Treatment of ICMP for PMTU joel jaeggli
- RE: Treatment of ICMP for PMTU Lubashev, Igor
- Re: Treatment of ICMP for PMTU Magnus Westerlund
- RE: Treatment of ICMP for PMTU Lubashev, Igor
- Re: Treatment of ICMP for PMTU Magnus Westerlund