RE: Treatment of ICMP for PMTU

"Lubashev, Igor" <ilubashe@akamai.com> Thu, 28 June 2018 06:11 UTC

Return-Path: <ilubashe@akamai.com>
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 31A47130E06 for <quic@ietfa.amsl.com>; Wed, 27 Jun 2018 23:11:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.71
X-Spam-Level:
X-Spam-Status: No, score=-2.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=akamai.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 eR53HvVa7JV6 for <quic@ietfa.amsl.com>; Wed, 27 Jun 2018 23:11:27 -0700 (PDT)
Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7F19126F72 for <quic@ietf.org>; Wed, 27 Jun 2018 23:11:27 -0700 (PDT)
Received: from pps.filterd (m0122333.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w5S67Q1l031401; Thu, 28 Jun 2018 07:11:22 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=jan2016.eng; bh=hpVCh4/gkrDoxR3E/6lkN9keQEConJLU2DYoXEiX4I4=; b=hnGCTBylCr7EyMyqaydHjZyeYi4IXOFEmhRbabcPRpmnaUL2acv95ek/cRmQiuQ7eE7m kwZ61gh5FEefVD0+j2AMVk9Ng98ppflIcz6YXODRHxWGAUe1KvY4UaWbMA+tEGMnawAN 7ePvFh3SGJjOyUv2HA4Iwn1Gpyv5XS/ENfIII9eAf7/YF/QXwpbBjmSKqRGnoJpBLKAE tB+KrT43LN9keXMU+wvf4nALYNorE/cwaIfUoA9GDdeqgVUAEIQYjTKbCEHVRI6rz0tR Al0uyHsEc0K9nEgAY+sw21IQp5bWG+kIX4Sh7ZqqSLFK0oGLNY0+hIlzCyi1Rm/8VPW1 kA==
Received: from prod-mail-ppoint4 (a96-6-114-87.deploy.static.akamaitechnologies.com [96.6.114.87] (may be forged)) by mx0a-00190b01.pphosted.com with ESMTP id 2jvk1jh0vg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 28 Jun 2018 07:11:22 +0100
Received: from pps.filterd (prod-mail-ppoint4.akamai.com [127.0.0.1]) by prod-mail-ppoint4.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w5S6Acqg021331; Thu, 28 Jun 2018 02:11:21 -0400
Received: from email.msg.corp.akamai.com ([172.27.25.33]) by prod-mail-ppoint4.akamai.com with ESMTP id 2ju9bvrq03-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 28 Jun 2018 02:11:21 -0400
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb3.msg.corp.akamai.com (172.27.27.103) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Thu, 28 Jun 2018 01:11:20 -0500
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com ([172.27.27.105]) by ustx2ex-dag1mb5.msg.corp.akamai.com ([172.27.27.105]) with mapi id 15.00.1365.000; Thu, 28 Jun 2018 01:11:20 -0500
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: Lucas Pardue <Lucas.Pardue@bbc.co.uk>, 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: AdQOVlbAt8rn27zdQrag9H62mpvY5wABihw5AANGU0AABKuwsgAJFrAw
Date: Thu, 28 Jun 2018 06:11:20 +0000
Message-ID: <4674cc2be90e4b5b9056cc63a0735664@ustx2ex-dag1mb5.msg.corp.akamai.com>
References: <924fbd75dbcf4d62a9062570b0d2ba5a@ustx2ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB5B9DC@bgb01xud1012>, <2f0e251a9b274272968a8b3053d3a3a5@ustx2ex-dag1mb5.msg.corp.akamai.com> <7CF7F94CB496BF4FAB1676F375F9666A3BB5BA29@bgb01xud1012>
In-Reply-To: <7CF7F94CB496BF4FAB1676F375F9666A3BB5BA29@bgb01xud1012>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [172.19.43.160]
Content-Type: text/plain; charset="koi8-r"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-28_02:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806280069
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-28_02:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806280068
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/UO0op4OBxamttjIbpOTCEG98nT0>
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: Thu, 28 Jun 2018 06:11:31 -0000

I think I see what you are talking about.

At least the way it is specced in H2 and HTTP/QUIC, CONNECT proxies forward data streams, not packets.  Hence, MTU concept on a tunnel-stream is meaningless.  The text says it explicitly: "Note that the size and number of TCP segments is not guaranteed to map predictably to the size and number of HTTP DATA or QUIC STREAM frames."  From the client's perspective there is only one PMTU that is relevant -- the one to the proxy.  The proxy will keep tracks of the PMTUs to the CONNECT endpoints itself and will generate TCP segments accordingly.

Trying to design a CONNECT-like method to proxy an entire QUIC connection over a single QUIC stream would create HOLB for QUIC packets to and from the proxy.  Some sort of a partially reliable QUIC stream could help here.

This proxying scheme would require an extension to CONNECT to open a UDP/IP tunnel instead of a TCP/IP tunnel.  That extension would also mandate that HTTP/QUIC DATA frame corresponds to a UDP frame.  I suspect that it would be a very good idea for such a proxy to add a new frame for providing ICMP-like explicit PMTU feedback to the sender (why leave the sender guessing and probing, if the PMTU is already known to the proxy?).

- Igor

-----Original Message-----
From: Lucas Pardue [mailto:Lucas.Pardue@bbc.co.uk] 
Sent: Wednesday, June 27, 2018 9:23 PM
To: Lubashev, Igor <ilubashe@akamai.com>; Martin Duke <martin.h.duke@gmail.com>; IETF QUIC WG <quic@ietf.org>
Subject: RE: Treatment of ICMP for PMTU

Hi Igor,

The difference as I see it is, if we were to follow a model similar to how CONNECT is defined in the HTTP/QUIC mapping, then QUIC tunnels are assigned to different streams (tunnel-streams) within a single connection. Remaining streams are used for client-proxy communications (control streams, request/response etc)

On such a tunnel-stream, if we follow the CONNECT model of encapsulation, the client sends/receives only QUIC packets. It is the proxy's job to read/write IP.

This leads me to thinking that a proxy cannot return ICMP on the tunnel-stream, and any ICMP cannot be disambiguated.

Or, perhaps I'm missing something here?

Kind regards
Lucas
________________________________________
From: Lubashev, Igor [ilubashe@akamai.com]
Sent: 28 June 2018 00:09
To: Lucas Pardue; Martin Duke; IETF QUIC WG
Subject: RE: Treatment of ICMP for PMTU

Hi Lucas,

How is this different from PMTUD in IP-in-IP case?  The endpoint computes and caches PMTU per endpoint.  PMTU for connections to proxy is kept separately from PMTUs for connections to endpoints that go via the proxy.

The proxy itself can learn PMTU between itself and the endpoints, subtract the overhead, and send ICMP to the sender of the proxied QUIC flow.

I see the common case of QUIC implementation not being able to make use of ICMP is when QUIC is implemented in userspace on a platform that does not expose ICMP to the application.  QUIC's desire to receive ICMP will likely cause vendors of such platforms to add the missing functionality.


  *   Igor


From: Lucas Pardue [mailto:Lucas.Pardue@bbc.co.uk]
Sent: Wednesday, June 27, 2018 5:27 PM
To: Lubashev, Igor <ilubashe@akamai.com>; Martin Duke <martin.h.duke@gmail.com>; IETF QUIC WG <quic@ietf.org>
Subject: RE: Treatment of ICMP for PMTU

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<https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_quicwg_base-2Ddrafts_pull_1412&d=DwMFIw&c=96ZbZZcaMF4w0F4jpN6LZg&r=Djn3bQ5uNJDPM_2skfL3rW1tzcIxyjUZdn_m55KPmlo&m=Z8Jztem09Whn8ur3u4CIXydQ2bFcxT7J8RP_5EIqqN0&s=GfFHhZ-IsLfWzrc3Dd83k__I6Golxxd3W2LduTHYc_I&e=>)
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



-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender immediately.
Please note that the BBC monitors e-mails sent or received.
Further communication will signify your consent to this.
-----------------------------