From nobody Mon Jul 6 06:04:11 2020 Return-Path: X-Original-To: tram@ietf.org Delivered-To: tram@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A27803A146D; Mon, 6 Jul 2020 06:04:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: tram@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.7.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: tram@ietf.org Message-ID: <159404064450.18094.10495728014282220651@ietfa.amsl.com> Date: Mon, 06 Jul 2020 06:04:04 -0700 Archived-At: Subject: [tram] I-D Action: draft-ietf-tram-stun-pmtud-17.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 13:04:05 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the TURN Revised and Modernized WG of the IETF. Title : Packetization Layer Path MTU Discovery (PLMTUD) For UDP Transports Using Session Traversal Utilities for NAT (STUN) Authors : Marc Petit-Huguenin Gonzalo Salgueiro Felipe Garrido Filename : draft-ietf-tram-stun-pmtud-17.txt Pages : 23 Date : 2020-07-06 Abstract: The datagram exchanged between two Internet endpoints have to go through a series of physical and virtual links that may have different limits on the upper size of the datagram they can transmit without fragmentation. Because fragmentation is considered harmful, most transports and protocols are designed with a mechanism that permits dynamic measurement of the maximum size of a datagram. This mechanism is called Packetization Layer Path MTU Discovery (PLPMTUD). But the UDP transport and some of the protocols that use UDP were designed without that feature. The Session Traversal Utilities for NAT (STUN) Usage described in this document permits retrofitting an existing UDP-based protocol with such a feature. Similarly, a new UDP-based protocol could simply reuse the mechanism described in this document. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-tram-stun-pmtud-17 https://datatracker.ietf.org/doc/html/draft-ietf-tram-stun-pmtud-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stun-pmtud-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 06:57:55 2020 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 046183A1547 for ; Mon, 6 Jul 2020 06:57:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.102 X-Spam-Level: X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.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 8nwLgcf5hWGJ for ; Mon, 6 Jul 2020 06:57:44 -0700 (PDT) Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00089.outbound.protection.outlook.com [40.107.0.89]) (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 1E5B43A1522 for ; Mon, 6 Jul 2020 06:57:44 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Q/n+KDhojxAxF4okGUr5T7ZoiDmp910PEgcgR/KFj+Bc44YraKPw6JBrkwaACxSknzaKGq14LYUU6i7QbtVOwSEkl5jPCycgw4qO6ZjMW/ayKj9FyV1o0ez6oiEB+vKfYMWcG5KuGOBN3h+q8cG+3s9BUzYZXY35QTzD/gJpBUGXB7qZ46RlaVgGsIJAIkOymqr18O0ICj6pyTX6uK7h8+BabcOoFSUtMMsJlAyfFQLWQWl9eDLwHDe8ApPGcCDZVmrYOVXSVsN2AHK3Cic+DmU1EBP4CsCcbr16xO4nlbLC7S6BeVPhy6G5LlY6OH1j2d42PzYgUfD6S/7LUX+Zig== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ikwufXYsZNM8XJwEYzliCRJmuCDZC3ZeNOxl0vhM50k=; b=X1QrtGHtSiMPuSsEg7C2fcuXcTpKyC4ug17kl6CNP6KkBIva9EyasU5jJYTWSP7JAgYlvpt/9C4DSC+nc/gx6sXtMiVu/uAqdE3Sn1IVxjAWntjlYT4W2D5Txk59XfxtpAIR5zCJq+qcvi7fH2fK/jCeuaKIgTiLkZ8cA3mDY4xuEfpmMnI6FGuIw+8p6NPFHi6RQDOszn3eI9eYNPoOHP2uaTH2X3JNmEnb9EHS0VhuKPL7cXAMwK6rWBhfLI7UgTX0uSicGYncZY4lpk49Ke15mi/8oh/lIF+3njlllk7DbHMbcVQm4DIbSksjrK1srUsE0DQOj2vNXMVdR5GrTQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ericsson.com; dmarc=pass action=none header.from=ericsson.com; dkim=pass header.d=ericsson.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ikwufXYsZNM8XJwEYzliCRJmuCDZC3ZeNOxl0vhM50k=; b=YrBY2KUadyNqCtpoVSs/KqfL5BthLhvtH1+LTnwsrVRf1Kpjn76gsiU/1TrC1h8ycZgCkpWC/Tv4mvuSJAHHPfMHZUzyWveG8ZUOlETJvf9ZRky1fjGdDaWnlAmBUT/9RdYWDedsb6XqBbM7Fd6jZCnxTMUIyTxRCvfJ3J9qdiQ= Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com (2603:10a6:7:8e::14) by HE1PR0701MB2683.eurprd07.prod.outlook.com (2603:10a6:3:98::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3174.16; Mon, 6 Jul 2020 13:57:41 +0000 Received: from HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::546c:3b3:9193:3351]) by HE1PR0702MB3772.eurprd07.prod.outlook.com ([fe80::546c:3b3:9193:3351%6]) with mapi id 15.20.3174.019; Mon, 6 Jul 2020 13:57:41 +0000 From: Magnus Westerlund To: "tram@ietf.org" Thread-Topic: I-D Action: draft-ietf-tram-stun-pmtud-17.txt Thread-Index: AQHWU5X/e48yVSivD0CvHxDTNvZjAqj6k6cA Date: Mon, 6 Jul 2020 13:57:41 +0000 Message-ID: <79512ccd052d9dca09de14dc35efd9cb77fef033.camel@ericsson.com> References: <159404064450.18094.10495728014282220651@ietfa.amsl.com> In-Reply-To: <159404064450.18094.10495728014282220651@ietfa.amsl.com> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-mailer: Evolution 3.28.5-0ubuntu0.18.04.2 authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=ericsson.com; x-originating-ip: [192.176.1.82] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 3dce370c-e747-40a0-dad4-08d821b48d15 x-ms-traffictypediagnostic: HE1PR0701MB2683: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ew4qM+Yfm305qShv8yBgtVO3WcawCcv5DTpxis80qffaOMwnf4n8jUzGDi9rSvo6+jHOXJW6usqQNrj5zXLgMy9ejNhEUSkE2+5RpjfJQL0w2x5gF1xmUZ69LVnJXO6mwqewOec+p1SQ1hV4igEGo2yzv3NT95r1YOcLqlaQFW/7Nr6ydvilTh9Rte27sFgWB9i5+5stgCnyI8OPPrwWYx0pptzGnATTCvZGlBemmGzLeildKxmqxLXxs78xKLfygBDerUAN8c1AvsoKhIftHWmxKg2RkvLQw4bPRSsbz09oHTUKLJD4fzE9SPaTEMCiKX8RIk6sW73AiirmRy19vutfIYkePZKkBZJ/cdnV7qr7b5uR0QoGW3zHEAt0KuQrSGbwoHKl+V7vaPvgGiLJDsuQv6QBeox17vwJ8B+ZJU4g92ixUzgiBn6h6BdQK2HD x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:HE1PR0702MB3772.eurprd07.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(366004)(39860400002)(346002)(376002)(396003)(6486002)(26005)(478600001)(71200400001)(186003)(6512007)(86362001)(6916009)(966005)(83380400001)(316002)(2906002)(66574015)(36756003)(44832011)(5660300002)(66446008)(64756008)(6506007)(2616005)(66556008)(66476007)(66946007)(76116006)(91956017)(8676002)(8936002)(99106002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: UOk60qdi3USDUz4FySbjg7GWyGryPG4yeA2TySj4UY4T6pXYaKpxHQ9e5t/e2Zh9yLVAHcYpnqBYnwTznjWlfcYeEDaGb3rDp3Yi5Mv4QWqnOgVG0/B+DjLv/idGvfFRsyGoMB/X7nT9qu71NULV+6wXc4A3xev+i+lx3awv/CN0aLkCU65ZL/8NBI40ugWXHJjUyXLnmSYqiwIqoA8qhvnp5C1Kulx3dCUyJZ/kdoMjZINEFSwFMtGB7OkWMf84uUp0UyR4kCT0cYocOdRg+6slfaWI9353dQeQ6LAuMY3BFBnRXvhBVaE7IST0Ie9HcfrjtqhOuTiObN5Vo5qPvxTqpDj9knC+G5avogXzDDVYt67LNosGPL5ZzTUPgBKq/zmIcG0RNa5G1Fknu4SEAJtop+vAepyQweydxmMVLTXIHjZtEJRHRtjot3JgiT8RQKjqi9w7ZfWZZz8rSfzE3Z2FQ/stYER3Q4PD5v90dgE= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="utf-8" Content-ID: <41CCFE669183EF4FB210495972D48FDB@eurprd07.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: ericsson.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: HE1PR0702MB3772.eurprd07.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 3dce370c-e747-40a0-dad4-08d821b48d15 X-MS-Exchange-CrossTenant-originalarrivaltime: 06 Jul 2020 13:57:41.6225 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: pjXbjI0Sh3tvyfrQykMHv9EBF47HjEl0lUl4Hpjc2lhjIjOF3mXPz4O/gbcTB57ntPF92n8qIkv8oVb0AWs2qfTKnRIQBHWgGqgDiT/zXMU= X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB2683 Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-stun-pmtud-17.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2020 13:57:53 -0000 SGksDQoNClRoYW5rcyBmb3IgdXBkYXRpbmcgdGhlIGRvY3VtZW50LiBJIHdpbGwgcmV2aWV3IHRo aXMgZG9jdW1lbnQuIA0KDQpDaGVlcnMNCg0KTWFnbnVzDQoNCk9uIE1vbiwgMjAyMC0wNy0wNiBh dCAwNjowNCAtMDcwMCwgaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIHdyb3RlOg0KPiBBIE5ldyBJ bnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFm dHMNCj4gZGlyZWN0b3JpZXMuDQo+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIFRV Uk4gUmV2aXNlZCBhbmQgTW9kZXJuaXplZCBXRyBvZiB0aGUgSUVURi4NCj4gDQo+ICAgICAgICAg VGl0bGUgICAgICAgICAgIDogUGFja2V0aXphdGlvbiBMYXllciBQYXRoIE1UVSBEaXNjb3Zlcnkg KFBMTVRVRCkgRm9yDQo+IFVEUCBUcmFuc3BvcnRzIFVzaW5nIFNlc3Npb24gVHJhdmVyc2FsIFV0 aWxpdGllcyBmb3IgTkFUIChTVFVOKQ0KPiAgICAgICAgIEF1dGhvcnMgICAgICAgICA6IE1hcmMg UGV0aXQtSHVndWVuaW4NCj4gICAgICAgICAgICAgICAgICAgICAgICAgICBHb256YWxvIFNhbGd1 ZWlybw0KPiAgICAgICAgICAgICAgICAgICAgICAgICAgIEZlbGlwZSBHYXJyaWRvDQo+IAlGaWxl bmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLXRyYW0tc3R1bi1wbXR1ZC0xNy50eHQNCj4gCVBhZ2Vz ICAgICAgICAgICA6IDIzDQo+IAlEYXRlICAgICAgICAgICAgOiAyMDIwLTA3LTA2DQo+IA0KPiBB YnN0cmFjdDoNCj4gICAgVGhlIGRhdGFncmFtIGV4Y2hhbmdlZCBiZXR3ZWVuIHR3byBJbnRlcm5l dCBlbmRwb2ludHMgaGF2ZSB0byBnbw0KPiAgICB0aHJvdWdoIGEgc2VyaWVzIG9mIHBoeXNpY2Fs IGFuZCB2aXJ0dWFsIGxpbmtzIHRoYXQgbWF5IGhhdmUNCj4gICAgZGlmZmVyZW50IGxpbWl0cyBv biB0aGUgdXBwZXIgc2l6ZSBvZiB0aGUgZGF0YWdyYW0gdGhleSBjYW4gdHJhbnNtaXQNCj4gICAg d2l0aG91dCBmcmFnbWVudGF0aW9uLiAgQmVjYXVzZSBmcmFnbWVudGF0aW9uIGlzIGNvbnNpZGVy ZWQgaGFybWZ1bCwNCj4gICAgbW9zdCB0cmFuc3BvcnRzIGFuZCBwcm90b2NvbHMgYXJlIGRlc2ln bmVkIHdpdGggYSBtZWNoYW5pc20gdGhhdA0KPiAgICBwZXJtaXRzIGR5bmFtaWMgbWVhc3VyZW1l bnQgb2YgdGhlIG1heGltdW0gc2l6ZSBvZiBhIGRhdGFncmFtLiAgVGhpcw0KPiAgICBtZWNoYW5p c20gaXMgY2FsbGVkIFBhY2tldGl6YXRpb24gTGF5ZXIgUGF0aCBNVFUgRGlzY292ZXJ5IChQTFBN VFVEKS4NCj4gICAgQnV0IHRoZSBVRFAgdHJhbnNwb3J0IGFuZCBzb21lIG9mIHRoZSBwcm90b2Nv bHMgdGhhdCB1c2UgVURQIHdlcmUNCj4gICAgZGVzaWduZWQgd2l0aG91dCB0aGF0IGZlYXR1cmUu ICBUaGUgU2Vzc2lvbiBUcmF2ZXJzYWwgVXRpbGl0aWVzIGZvcg0KPiAgICBOQVQgKFNUVU4pIFVz YWdlIGRlc2NyaWJlZCBpbiB0aGlzIGRvY3VtZW50IHBlcm1pdHMgcmV0cm9maXR0aW5nIGFuDQo+ ICAgIGV4aXN0aW5nIFVEUC1iYXNlZCBwcm90b2NvbCB3aXRoIHN1Y2ggYSBmZWF0dXJlLiAgU2lt aWxhcmx5LCBhIG5ldw0KPiAgICBVRFAtYmFzZWQgcHJvdG9jb2wgY291bGQgc2ltcGx5IHJldXNl IHRoZSBtZWNoYW5pc20gZGVzY3JpYmVkIGluIHRoaXMNCj4gICAgZG9jdW1lbnQuDQo+IA0KPiAN Cj4gVGhlIElFVEYgZGF0YXRyYWNrZXIgc3RhdHVzIHBhZ2UgZm9yIHRoaXMgZHJhZnQgaXM6DQo+ IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtdHJhbS1zdHVuLXBt dHVkLw0KPiANCj4gVGhlcmUgYXJlIGFsc28gaHRtbGl6ZWQgdmVyc2lvbnMgYXZhaWxhYmxlIGF0 Og0KPiBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi10cmFtLXN0dW4tcG10 dWQtMTcNCj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvaHRtbC9kcmFmdC1pZXRm LXRyYW0tc3R1bi1wbXR1ZC0xNw0KPiANCj4gQSBkaWZmIGZyb20gdGhlIHByZXZpb3VzIHZlcnNp b24gaXMgYXZhaWxhYmxlIGF0Og0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtaWV0Zi10cmFtLXN0dW4tcG10dWQtMTcNCj4gDQo+IA0KPiBQbGVhc2Ugbm90ZSB0aGF0 IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNz aW9uDQo+IHVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZmIGFyZSBhdmFpbGFibGUg YXQgdG9vbHMuaWV0Zi5vcmcuDQo+IA0KPiBJbnRlcm5ldC1EcmFmdHMgYXJlIGFsc28gYXZhaWxh YmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+IGZ0cDovL2Z0cC5pZXRmLm9yZy9pbnRlcm5ldC1k cmFmdHMvDQo+IA0KPiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCj4gSS1ELUFubm91bmNlIG1haWxpbmcgbGlzdA0KPiBJLUQtQW5ub3VuY2VAaWV0 Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3Vu Y2UNCj4gSW50ZXJuZXQtRHJhZnQgZGlyZWN0b3JpZXM6IGh0dHA6Ly93d3cuaWV0Zi5vcmcvc2hh ZG93Lmh0bWwNCj4gb3IgZnRwOi8vZnRwLmlldGYub3JnL2lldGYvMXNoYWRvdy1zaXRlcy50eHQN Ci0tIA0KQ2hlZXJzDQoNCk1hZ251cyBXZXN0ZXJsdW5kIA0KDQoNCi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCk5l dHdvcmtzLCBFcmljc3NvbiBSZXNlYXJjaA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KRXJpY3Nzb24gQUIgICAg ICAgICAgICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQpUb3JzaGFtbnNnYXRhbiAyMyAg ICAgICAgICAgfCBNb2JpbGUgKzQ2IDczIDA5NDkwNzkNClNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3 ZWRlbiB8IG1haWx0bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tDQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQoNCg0K From nobody Tue Jul 14 06:24:07 2020 Return-Path: X-Original-To: tram@ietfa.amsl.com Delivered-To: tram@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556203A011B for ; Tue, 14 Jul 2020 06:24:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.896 X-Spam-Level: X-Spam-Status: No, score=-1.896 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 SsIoWubb-ZE1 for ; Tue, 14 Jul 2020 06:24:03 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [IPv6:2001:630:42:150::2]) by ietfa.amsl.com (Postfix) with ESMTP id 9A6B93A095D for ; Tue, 14 Jul 2020 06:23:37 -0700 (PDT) Received: from GF-MacBook-Pro.lan (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id E929C1B007BF; Tue, 14 Jul 2020 14:23:31 +0100 (BST) References: <7c201e29-1a63-39ed-cdd9-3b8b9ac383e6@erg.abdn.ac.uk> To: tram@ietf.org From: Gorry Fairhurst Cc: gorry@abdn.ac.uk X-Forwarded-Message-Id: <7c201e29-1a63-39ed-cdd9-3b8b9ac383e6@erg.abdn.ac.uk> Message-ID: <860e8240-ce51-5407-4187-92478262f87c@erg.abdn.ac.uk> Date: Tue, 14 Jul 2020 14:23:30 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <7c201e29-1a63-39ed-cdd9-3b8b9ac383e6@erg.abdn.ac.uk> Content-Type: multipart/alternative; boundary="------------E0414D64CA152CC24AD6D79D" Content-Language: en-GB Archived-At: Subject: [tram] A few comments on draft-ietf-tram-stun-pmtud-17.txt X-BeenThere: tram@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Discussing the creation of a Turn Revised And Modernized \(TRAM\) WG, which goal is to consolidate the various initiatives to update TURN and STUN." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Jul 2020 13:24:06 -0000 This is a multi-part message in MIME format. --------------E0414D64CA152CC24AD6D79D Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit I had a look at draft-ietf-tram-stun-pmtud-17 with respect to the last comments, and saw some changes and I have a few comments. These comments are sent to the TRAM mailing list, Gorry --- Section 2 does not discuss the frequency of the probe. This is a congestion control case, and the method needs to assert some guidance/requirements on the probing. Do probe packets count against cwnd when using this method? In section 4.1. I think this is misleading, and not a feature of the simple method: “   Note: Routers can be configured to clear the DF bit or ignore the DF    bit which can be difficult or impossible to detect if reassembly    occurs prior to receiving the packet, rendering PLPMTUD inaccurate. “ - I wouldn’t call this inaccurate? If the path contains a link-layer (or tunnel or anything) that fragments and reassembles - then the path MTU is whatever size that assembly is performed to. It has always been this way, if links fragment and reassemble, IP uses the reassembled size. In section 4.2.2.  Receiving an ICMP Packet This ID currently recommends “ Validation SHOULD be performed on the ICMP    packet as specified in [RFC8085].” - Since this is a method above UDP, I think this implicitly also checks the UDP port information, hence this recommendation actually is an unavoidable consequence when using a normal stack - if you have one that forwards ICMP to the socket. This becomes a requirement (or is always true) in dplpmtud: - “Any received PTB message MUST be validated before it is used to update the PLPMTU discovery information”. - Should this be a requirement in this spec, to avoid off-path attack? In section 4.2.5 “It could have been possible to use the checksum generated in the UDP    checksum for this, but this value is generally not accessible to    applications.  Also, sometimes the checksum is not calculated or is    off-loaded to network hardware.“ - I do not agree this could be used (even if the checksum was returned to user space), and think it suggests something that isn’t possible. The UDP checksum includes the pseudo header information, including the ports. Wouldn’t this make the method very fragile in the face of NAPT? In section 5: I don’t yet see changes in this version to section 5. “The PMTUD mechanism described in this document is intended to be used    by any UDP-based protocols that do not have built-in PMTUD    capabilities, irrespective of whether those UDP-based protocols are    STUN-based or not.  So the manner in which a specific protocol    discovers that it is safe to send PMTUD probes is largely dependent    on the details of that specific protocol, with the exception of the    Implicit Mechanism described below, which applies to any protocol." - Please see comments made in the previous last call. In section 7: This has added a section that is a cross-reference of which sections contain information that relates to DPLPMTUD. I see a mapping of requirements in section 7.1 to refer to the described method  with STUN. This seems like a useful addition (and appropriate). Currently this doesn’t really have enough detail to clearly see how the two sets of text relate, one might have to read both to figure out the details, and if that’s the case, maybe it should be explained up front. That could be helpful. However, this does not resolve the last call questions raised about the method, and it seems to require someone to read both documents, which really  isn't that easy. Section 7.1.  Probe loss recovery -  I think understand that the probes themselves do not need to be recovered, but the text in section 7.1 does not quite say this. Section 7.1. Section 7 doesn’t describe the implications of probing on flow control control. I’m not sure the current text is enough: - Do probe packets count as credit to an upper layer protocol using this method? *---* On 06/07/2020 15:02, Magnus Westerlund wrote: > Hi, > > Gorry did have feedback on this document, and they have done some attempt > to define a DPLPMTUD mapping for their mechanism. I looked at it briefly and > think it is horrible terse with just requirements to combine sections. Which > unfortunately requires one to sit and cross reference the two documents. > > I would appreciate any feedback from any of you have and if there appear some > glaring failures or problems with things they declare out of scope etc. > Privately or publicly to the TRAM mailing list (tram@ietf.org). > > Cheers > > Magnus > > On Mon, 2020-07-06 at 06:04 -0700,internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the TURN Revised and Modernized WG of the IETF. >> >> Title : Packetization Layer Path MTU Discovery (PLMTUD) For >> UDP Transports Using Session Traversal Utilities for NAT (STUN) >> Authors : Marc Petit-Huguenin >> Gonzalo Salgueiro >> Felipe Garrido >> Filename : draft-ietf-tram-stun-pmtud-17.txt >> Pages : 23 >> Date : 2020-07-06 >> >> Abstract: >> The datagram exchanged between two Internet endpoints have to go >> through a series of physical and virtual links that may have >> different limits on the upper size of the datagram they can transmit >> without fragmentation. Because fragmentation is considered harmful, >> most transports and protocols are designed with a mechanism that >> permits dynamic measurement of the maximum size of a datagram. This >> mechanism is called Packetization Layer Path MTU Discovery (PLPMTUD). >> But the UDP transport and some of the protocols that use UDP were >> designed without that feature. The Session Traversal Utilities for >> NAT (STUN) Usage described in this document permits retrofitting an >> existing UDP-based protocol with such a feature. Similarly, a new >> UDP-based protocol could simply reuse the mechanism described in this >> document. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-tram-stun-pmtud-17 >> https://datatracker.ietf.org/doc/html/draft-ietf-tram-stun-pmtud-17 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stun-pmtud-17 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> >> _______________________________________________ >> I-D-Announce mailing list >> I-D-Announce@ietf.org >> https://www.ietf.org/mailman/listinfo/i-d-announce >> Internet-Draft directories:http://www.ietf.org/shadow.html >> orftp://ftp.ietf.org/ietf/1shadow-sites.txt --------------E0414D64CA152CC24AD6D79D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

I had a look at draft-ietf-tram-stun-pmtud-17 with respect to the last comments, and saw some changes and I have a few comments. These comments are sent to the TRAM mailing list,

Gorry

---

Section 2 does not discuss the frequency of the probe. This is a congestion control case, and the method needs to assert some guidance/requirements on the probing. Do probe packets count against cwnd when using this method?

In section 4.1.
I think this is misleading, and not a feature of the simple method:
“   Note: Routers can be configured to clear the DF bit or ignore the DF
   bit which can be difficult or impossible to detect if reassembly
   occurs prior to receiving the packet, rendering PLPMTUD inaccurate.
“
- I wouldn’t call this inaccurate? If the path contains a link-layer (or tunnel or anything) that fragments and reassembles - then the path MTU is whatever size that assembly is performed to. It has always been this way, if links fragment and reassemble, IP uses the reassembled size.

In section 4.2.2.  Receiving an ICMP Packet
This ID currently recommends “ Validation SHOULD be performed on the ICMP
   packet as specified in [RFC8085].”
- Since this is a method above UDP, I think this implicitly also checks the UDP port information, hence this recommendation actually is an unavoidable consequence when using a normal stack - if you have one that forwards ICMP to the socket.

This becomes a requirement (or is always true) in dplpmtud:
- “Any received PTB message MUST be validated before it is used to update the PLPMTU discovery information”.
- Should this be a requirement in this spec, to avoid off-path attack?
 
In section 4.2.5
“It could have been possible to use the checksum generated in the UDP
   checksum for this, but this value is generally not accessible to
   applications.  Also, sometimes the checksum is not calculated or is
   off-loaded to network hardware.“
- I do not agree this could be used (even if the checksum was returned to user space), and think it suggests something that isn’t possible. The UDP checksum includes the pseudo header information, including the ports. Wouldn’t this make the method very fragile in the face of NAPT?

In section 5:
I don’t yet see changes in this version to section 5.
“The PMTUD mechanism described in this document is intended to be used
   by any UDP-based protocols that do not have built-in PMTUD
   capabilities, irrespective of whether those UDP-based protocols are
   STUN-based or not.  So the manner in which a specific protocol
   discovers that it is safe to send PMTUD probes is largely dependent
   on the details of that specific protocol, with the exception of the
   Implicit Mechanism described below, which applies to any protocol."

- Please see comments made in the previous last call.

In section 7:

This has added a section that is a cross-reference of which sections contain information that relates to DPLPMTUD.

I see a mapping of requirements in section 7.1 to refer to the described method  with STUN. This seems like a useful addition (and appropriate). Currently this doesn’t really have enough detail to clearly see how the two sets of text relate, one might have to read both to figure out the details, and if that’s the case, maybe it should be explained up front. That could be helpful. 

However, this does not resolve the last call questions raised about the method, and it seems to require someone to read both documents, which really  isn't that easy.

Section 7.1.  Probe loss recovery -  I think understand that the probes themselves do not need to be recovered, but the text in section 7.1 does not quite say this.

Section 7.1. Section 7 doesn’t describe the implications of probing on flow control control. I’m not sure the current text is enough:
- Do probe packets count as credit to an upper layer protocol using this method?

---

On 06/07/2020 15:02, Magnus Westerlund wrote:
Hi,

Gorry did have feedback on this document, and they have done some attempt
to define a DPLPMTUD mapping for their mechanism. I looked at it briefly and
think it is horrible terse with just requirements to combine sections. Which
unfortunately requires one to sit and cross reference the two documents. 

I would appreciate any feedback from any of you have and if there appear some
glaring  failures or problems with things they declare out of scope etc.
Privately or publicly to the TRAM mailing list (tram@ietf.org). 

Cheers

Magnus

On Mon, 2020-07-06 at 06:04 -0700, internet-drafts@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the TURN Revised and Modernized WG of the IETF.

        Title           : Packetization Layer Path MTU Discovery (PLMTUD) For
UDP Transports Using Session Traversal Utilities for NAT (STUN)
        Authors         : Marc Petit-Huguenin
                          Gonzalo Salgueiro
                          Felipe Garrido
	Filename        : draft-ietf-tram-stun-pmtud-17.txt
	Pages           : 23
	Date            : 2020-07-06

Abstract:
   The datagram exchanged between two Internet endpoints have to go
   through a series of physical and virtual links that may have
   different limits on the upper size of the datagram they can transmit
   without fragmentation.  Because fragmentation is considered harmful,
   most transports and protocols are designed with a mechanism that
   permits dynamic measurement of the maximum size of a datagram.  This
   mechanism is called Packetization Layer Path MTU Discovery (PLPMTUD).
   But the UDP transport and some of the protocols that use UDP were
   designed without that feature.  The Session Traversal Utilities for
   NAT (STUN) Usage described in this document permits retrofitting an
   existing UDP-based protocol with such a feature.  Similarly, a new
   UDP-based protocol could simply reuse the mechanism described in this
   document.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-tram-stun-pmtud-17
https://datatracker.ietf.org/doc/html/draft-ietf-tram-stun-pmtud-17

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-stun-pmtud-17


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


_______________________________________________
I-D-Announce mailing list
I-D-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
--------------E0414D64CA152CC24AD6D79D--