Treatment of ICMP for PMTU
"Lubashev, Igor" <ilubashe@akamai.com> Wed, 27 June 2018 20:36 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 0E298130E35 for <quic@ietfa.amsl.com>; Wed, 27 Jun 2018 13:36:37 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] 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 CIzgWh6WhhAK for <quic@ietfa.amsl.com>; Wed, 27 Jun 2018 13:36:34 -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 C5887130E29 for <quic@ietf.org>; Wed, 27 Jun 2018 13:36:34 -0700 (PDT)
Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by m0050095.ppops.net-00190b01. (8.16.0.22/8.16.0.22) with SMTP id w5RKVd2h026546; Wed, 27 Jun 2018 21:36:32 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=from : to : subject : date : message-id : content-type : mime-version; s=jan2016.eng; bh=GWqtqp5AmCKxgxIGKIz5+Uer22UiL/HCb6IrY4ZdmMI=; b=WKeP/1EUJfgIC5P0WRSnuZWQ91Fw11KsmKmXCZZwTo0zhd6x9vHBQb7mZHMoGKWSzYj1 7aqu5N9cKvMGt4isIY/3XcY5m4E3a9a9oytPWFFlCOqfdbdSacO8uracE+LOKNC1+MPt JicpFYgCF086aeegnyhJH/eyklMRIMhK9oTk5DBs6RTCLGI6sE9+jrZaqISgxSZBDdM5 zgiX7MboPSfP9Z6AnPthnTBBgoOt5+017RZ5hKVl4N5J72fmPJOB3G7Ku2tktsxlY8Ar FuyoxEP1kOpAcs6vyNP+WLN6ZBg4gbRMVJQ8FlPtxwUwuEJthZ3xCshxy2fV9PY4bfVK ZQ==
Received: from prod-mail-ppoint1 (prod-mail-ppoint1.akamai.com [184.51.33.18]) by m0050095.ppops.net-00190b01. with ESMTP id 2jvc8m8vut-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 27 Jun 2018 21:36:32 +0100
Received: from pps.filterd (prod-mail-ppoint1.akamai.com [127.0.0.1]) by prod-mail-ppoint1.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w5RKZrQ3027986; Wed, 27 Jun 2018 16:36:30 -0400
Received: from email.msg.corp.akamai.com ([172.27.25.33]) by prod-mail-ppoint1.akamai.com with ESMTP id 2ju9caavyy-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 27 Jun 2018 16:36:30 -0400
Received: from USTX2EX-DAG1MB5.msg.corp.akamai.com (172.27.27.105) by ustx2ex-dag1mb5.msg.corp.akamai.com (172.27.27.105) with Microsoft SMTP Server (TLS) id 15.0.1365.1; Wed, 27 Jun 2018 15:36:29 -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; Wed, 27 Jun 2018 15:36:29 -0500
From: "Lubashev, Igor" <ilubashe@akamai.com>
To: Martin Duke <martin.h.duke@gmail.com>, IETF QUIC WG <quic@ietf.org>
Subject: Treatment of ICMP for PMTU
Thread-Topic: Treatment of ICMP for PMTU
Thread-Index: AdQOVlbAt8rn27zdQrag9H62mpvY5w==
Date: Wed, 27 Jun 2018 20:36:29 +0000
Message-ID: <924fbd75dbcf4d62a9062570b0d2ba5a@ustx2ex-dag1mb5.msg.corp.akamai.com>
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.35.89]
Content-Type: multipart/alternative; boundary="_000_924fbd75dbcf4d62a9062570b0d2ba5austx2exdag1mb5msgcorpak_"
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-27_06:, , 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=902 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806270217
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-06-27_06:, , 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=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=823 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1806210000 definitions=main-1806270217
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/tGTfQNuMDPxKcoHzy4RGfkC5cCQ>
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 20:36:37 -0000
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