Re: [tram] Adam Roach's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS and COMMENT)
"Felipe Garrido (fegarrid)" <fegarrid@cisco.com> Tue, 10 September 2019 23:01 UTC
Return-Path: <fegarrid@cisco.com>
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 6D9D4120019; Tue, 10 Sep 2019 16:01:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.499
X-Spam-Level:
X-Spam-Status: No, score=-14.499 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_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=Z9rigHb1; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=AkN2zp3M
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 OvCGnwCIDpB0; Tue, 10 Sep 2019 16:01:10 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8541C12006B; Tue, 10 Sep 2019 16:01:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30039; q=dns/txt; s=iport; t=1568156470; x=1569366070; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=aKATlzIFZ27eBGKI2HsIeJrunKSnTA9c+UjDuNsJ6sI=; b=Z9rigHb1mh8qcapE38F5S5Sq0mNyI5dDSFxY7oM6+cOiPWBRGHJC/QAo emEAHBawy3l54E2MB/PsDtqxFO7AxyxUQRNeOknGvsfjMo9MFsqBa/Qgb SUqqedMGZgbwA0zZz3ixBW9uSLrBYBDKlvjQ2rdh4uPrVZSQwdxbJftJ3 M=;
IronPort-PHdr: 9a23:zqHw3xQun6puJlaK94ULLMhY3Npsv++ubAcI9poqja5Pea2//pPkeVbS/uhpkESXBNfA8/wRje3QvuigQmEG7Zub+FE6OJ1XH15g640NmhA4RsuMCEn1NvnvOiI3E81YTl5p13q6KkNSXs35Yg6arw==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0C6AADwKnhd/5xdJa1bChoBAQEBAQIBAQEBBwIBAQEBgWeBFi9QA21WIAQLKoQhg0cDinuCNyWXcIFCgRADVAkBAQEMAQEjCgIBAYQ/AheCMiM4EwIDCQEBBAEBAQIBBgRthS4BC4VKAQEBAQMSEQoTAQE3AQ8CAQgRAwECKAMCAgIwFAkIAgQOBRQHB4MAAYEdTQMdAQIMnUQCgTiIYXOBMoJ9AQEFgUZBgn8YghYDBoE0i3gYgUA/gREnDBOCTD6CYQIBAgGBKgEHCgIBCDYNCYJVMoImjFwEgiw0hSGWfG4KgiGHAY12G4I0h0CPFo1/iASQagIEAgQFAg4BAQWBaSFnWBEIcBVlAYJBgkIMFxWDOoUUhT9zAYEojn8BAQ
X-IronPort-AV: E=Sophos;i="5.64,491,1559520000"; d="scan'208,217";a="632005931"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 10 Sep 2019 23:01:08 +0000
Received: from XCH-ALN-010.cisco.com (xch-aln-010.cisco.com [173.36.7.20]) by rcdn-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id x8AN18S1014281 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 10 Sep 2019 23:01:08 GMT
Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-ALN-010.cisco.com (173.36.7.20) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 10 Sep 2019 18:01:07 -0500
Received: from xhs-rcd-003.cisco.com (173.37.227.248) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1473.3; Tue, 10 Sep 2019 18:01:06 -0500
Received: from NAM05-CO1-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-003.cisco.com (173.37.227.248) with Microsoft SMTP Server (TLS) id 15.0.1473.3 via Frontend Transport; Tue, 10 Sep 2019 18:01:06 -0500
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jyGYdBcdFINwAsUYVNvaO12nwHWOHGJUvWaPrMNX/LyEdFFHNuGNhYwFud5xTk5MQgM8d78NhIL40RhMgQIo4FV4iXahwtKlptkqrao/7N9uD4QSQ6c0fUviTs720sS1ClgdB/WAEs2KSBp00lZ5S+yoPGEVfkvI9VV/y/VpJ10mSArJUDWsCjhrqQgoQO23D/zOmSWWqhvsLtZSb+BAJUWWrAauFEulS4XhP3k647ORJfmCiA9lmnuUzDOhKtwO16FfWHdf0Y1bAuYua0qch39VUx/rqTyzKL8RsfXLJmHEYPI9H34Bs2k1ESAN5hJkyVgKSPd4hBxP46fMPKcHkw==
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=aKATlzIFZ27eBGKI2HsIeJrunKSnTA9c+UjDuNsJ6sI=; b=by03EiU9GX6YFnnHdEyr7Qb8ZJncyRwgm7druwHoUc/xCHFAefzrS15TqUPjXLS+1/WEtLOW6ZEI1yhMQSrkB0uik7udwGj6Ghc3LE5PvH7mUityI9uhtiAjLLrLKkwy7xjregEpFz6OHCZGIsRmDJG5HcTtFwbo7k3ZL+D8JZMwC2AM0Dn+Hzovs1w4bAby9T70qfUDi8J6ww46WGXSQBy8EM1im8A82ow9/w6n7bKHVS9dc1TCQZJhCgnV5WgCNVKQM1wE3nsk0xXA4YY+adKuYO3t4Q5vmn4fS4PbwkCwgBdr981Fvj60ju3MEA/NbJ8PbfeCiCHpC7qEjEXoJw==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aKATlzIFZ27eBGKI2HsIeJrunKSnTA9c+UjDuNsJ6sI=; b=AkN2zp3MRIaaEFJ8QxCFpSOCKrsCmgK9gmyYLXusqy+zcQJby4ZLm1ypzUq0/Tu5ESoAysshOPFX52UALAg4MOsdStexgYZdQTkcwQAGPPJxc2BlXs+oBk0THZMHSfhY+gBGHQfaHkhspAijfjGmwAOB7ZWN4ukcbUUW9zYXmbE=
Received: from SN6PR11MB2800.namprd11.prod.outlook.com (52.135.93.15) by SN6PR11MB2606.namprd11.prod.outlook.com (52.135.91.27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2199.21; Tue, 10 Sep 2019 23:01:05 +0000
Received: from SN6PR11MB2800.namprd11.prod.outlook.com ([fe80::46f:91cb:e269:d8d2]) by SN6PR11MB2800.namprd11.prod.outlook.com ([fe80::46f:91cb:e269:d8d2%4]) with mapi id 15.20.2241.018; Tue, 10 Sep 2019 23:01:04 +0000
From: "Felipe Garrido (fegarrid)" <fegarrid@cisco.com>
To: "adam@nostrum.com" <adam@nostrum.com>
CC: "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-tram-stun-pmtud@ietf.org" <draft-ietf-tram-stun-pmtud@ietf.org>, "tram-chairs@ietf.org" <tram-chairs@ietf.org>, "tasveren@rbbn.com" <tasveren@rbbn.com>, "tram@ietf.org" <tram@ietf.org>
Thread-Topic: Adam Roach's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS and COMMENT)
Thread-Index: AQHVWSqrsJN7Mz/hWEqmhYm63kbT7KcTnHOA
Date: Tue, 10 Sep 2019 23:01:03 +0000
Message-ID: <CF3F1FDF-98EC-4899-B641-45D9B2141EAF@cisco.com>
References: <153834237082.13405.1228259718885034461.idtracker@ietfa.amsl.com> <6AFAB611-2268-45F4-82C1-4993971168E7@cisco.com>
In-Reply-To: <6AFAB611-2268-45F4-82C1-4993971168E7@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.1c.0.190812
authentication-results: spf=none (sender IP is ) smtp.mailfrom=fegarrid@cisco.com;
x-originating-ip: [2001:420:2280:1272:6501:8be9:d2b8:e11b]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 6710a06c-f3d4-4802-67f9-08d73642c227
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600166)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:SN6PR11MB2606;
x-ms-traffictypediagnostic: SN6PR11MB2606:
x-ms-exchange-purlcount: 6
x-microsoft-antispam-prvs: <SN6PR11MB260651A7AB6CE5A6F84618DFC8B60@SN6PR11MB2606.namprd11.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 01565FED4C
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(366004)(396003)(376002)(136003)(39860400002)(346002)(199004)(189003)(14454004)(6916009)(446003)(790700001)(6116002)(91956017)(54906003)(2616005)(966005)(36756003)(11346002)(316002)(229853002)(2906002)(58126008)(476003)(86362001)(478600001)(46003)(486006)(76176011)(6506007)(99286004)(9326002)(7736002)(102836004)(8936002)(186003)(5640700003)(66946007)(66476007)(66446008)(66556008)(81166006)(6486002)(14444005)(2351001)(4326008)(2501003)(64756008)(71190400001)(53936002)(25786009)(1730700003)(606006)(76116006)(6306002)(6246003)(256004)(6512007)(5660300002)(236005)(6436002)(71200400001)(8676002)(54896002)(21615005)(81156014)(33656002); DIR:OUT; SFP:1101; SCL:1; SRVR:SN6PR11MB2606; H:SN6PR11MB2800.namprd11.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1;
received-spf: None (protection.outlook.com: cisco.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: Xs7v+GOTi+y9/rrBVxzzpMvzpD+sCX6SyYyYzjy4rE9rtQ3c5nJr6M8aI8YOlWK4W0f+xFvxVlVnnC1Fp0X+VUsFzjbJRIbGatyBVZqYmgRoOsqNPmNrAn4P2CplskYWaZuVFgLH+edpfKKpCkqSIdpYWNNm8236z1p8agLhV0rVjSypvWlVdRR2WaKIuzKJOBnv5oTDo98L6vgbId2wi07A9VH2/XWOWOx7BpV9fVTu1SbumUyg10YEsjlTdVNh33B15BUekeEU/V65qXVZoL82iOjegC+83MJKhsa6G1y8H9PO9RgJT22uZMcEahR5kl3XlLK5/vGKsBbZK6ZVen2IWzWili5NjoVhPDgvLFwGX9UxatSNFuOL3QPvMJzSwTqsevb8Dn6ATjlWgqDbJ8lrS94oCm+fHoSLJKBRHaw=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CF3F1FDF98EC4899B64145D9B2141EAFciscocom_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: 6710a06c-f3d4-4802-67f9-08d73642c227
X-MS-Exchange-CrossTenant-originalarrivaltime: 10 Sep 2019 23:01:04.5140 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: Hff0K3VM37XLbqxcsWaiQIoNkklDF5dw4HUDduB2hAig7iqR8x/4WYEwJbtBpuszZLiS6+AiGNeYDNGEdWGkuQ==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR11MB2606
X-OriginatorOrg: cisco.com
X-Outbound-SMTP-Client: 173.36.7.20, xch-aln-010.cisco.com
X-Outbound-Node: rcdn-core-5.cisco.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/QfdobO0mSdahLWTWzDlCHMItS8g>
Subject: Re: [tram] Adam Roach's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS and COMMENT)
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." <tram.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tram>, <mailto:tram-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tram/>
List-Post: <mailto:tram@ietf.org>
List-Help: <mailto:tram-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tram>, <mailto:tram-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 10 Sep 2019 23:01:15 -0000
Hi Adam, Please see responses, labeled with an [FG], inline with DISCUSS and COMMENTS. We’ve published a new version (-13) with the proposed changes. Thanks, -Felipe From: Adam Roach <adam@nostrum.com<mailto:adam@nostrum.com>> Subject: Adam Roach's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS and COMMENT) Date: September 30, 2018 at 5:19:30 PM EDT To: The IESG <iesg@ietf.org<mailto:iesg@ietf.org>> Cc: <draft-ietf-tram-stun-pmtud@ietf.org<mailto:draft-ietf-tram-stun-pmtud@ietf.org>>, Gonzalo Camarillo <gonzalo.camarillo@ericsson.com<mailto:gonzalo.camarillo@ericsson.com>>, Tolga Asveren <tasveren@rbbn.com<mailto:tasveren@rbbn.com>>, <tram-chairs@ietf.org<mailto:tram-chairs@ietf.org>>, <tasveren@rbbn.com<mailto:tasveren@rbbn.com>>, <tram@ietf.org<mailto:tram@ietf.org>> Resent-From: <alias-bounces@ietf.org<mailto:alias-bounces@ietf.org>> Resent-To: <marc@petit-huguenin.org<mailto:marc@petit-huguenin.org>>, <gsalguei@cisco.com<mailto:gsalguei@cisco.com>> Adam Roach has entered the following ballot position for draft-ietf-tram-stun-pmtud-10: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-tram-stun-pmtud/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- This seems like an interesting technique that warrants collection of operational experience. From a process perspective, I think we have a bit of an issue, unless I've overlooked something relevant. This is proposed as a Standards-Track document, but it relies on the use of the PADDING attribute defined in RFC 5780. RFC 5780 is Experimental, so this is a formal downref. And RFC 5780 does not appear in the downref registry [1], nor did the IETF last call [2] include a request that the IETF community consider allowing such a refernce. From a practical perspective, the mechanism described in this document seems like the kind of thing that it would be useful to gather operational experience with prior to putting it on the standards track. I have some operational concerns (described below) that I think could be either proven out or dispelled by experimental deployment of the technology. My recommendation is to recategorize this mechanism as experimental, adding some text about the desire to gather operational experience. For avoidance of doubt: My DISCUSS is only on the process issue, and I'll happily clear regardless of how this issue is rationalized (e.g., either by running IETF last call again, by reclassifying this mechanism as experimental, or perhaps some novel solution that I may not have thought of). Everything else is merely a recommendation. [FG] We went through the different options available to handle the Standards Track vs Experimental debate and following guidance offered by Ben Campbell, we’ve decided to pull the padding attribute definition into the document and remove the references to RFC5780 in the latest draft. ____ [1] https://datatracker.ietf.org/doc/downref/ [2] https://www.ietf.org/mail-archive/web/tram/current/msg02609.html ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- In the general case, STUN servers aren't aware of the signaling protocol that is in use. For example, when a TURN server is use with RTP and RTCP with a session set up via SIP, there is no requirement that the TURN server itself have any inherent knowledge of SIP or RTP or RTCP. From that perspective, the following text in section 4.2 is a bit confusing and/or problematic: Some application layer protocols may already have a way of identifying each individual UDP packet, in which case these identifiers SHOULD be used in the IDENTIFIERS attribute of the Report Response. It seems odd that I would have to teach my TURN server about the protocols I'm using it with just so that it can identify the packets. This behavior, combined with the requirement that all behavior be symmetrical ("As a result of the fact that all endpoints implementing this specification are both clients and servers") leads me to believe that perhaps the use cases that drove this mechanism are tightly scoped to direct peer-to-peer uses of ICE, while the other common uses of STUN (e.g., public TURN servers used for symmetric NAT traversal) were given no consideration. If that was intentional, then I think the abstract and introduction need to clearly describe the scenarios the mechanism was defined for; and, more importantly, clarify that it does not work for the general case, including STUN servers used for NAT traversal. I suspect that, once this mechanism begins to be deployed, the foregoing limitations will cause operational difficulties, which may in turn suggest changes to the mechanism that is currently defined, hence my suggestion above to recharacterize the mechanism as experimental. --------------------------------------------------------------------------- [FG]: I’m not sure I understand completely the point you’re trying to make but this draft does not propose a new protocol and therefore the TURN server does not need to be aware. The data will be tunneled within the STUN data stream. If I’m missing your point then please clarify. §4: The Probing mechanism is used to discover the Path MTU in one direction only, from the client to the server. Nit: "...only: from..." [FG]: Change made Two Probing mechanisms are described, a Simple Probing mechanism and Nit: "...described: a Simple..." [FG]: Change made a more complete mechanism that can converge quicker and find an Nit: "...converge more quickly..." [FG]: Change made appropriate PMTU in the presence of congestion. Additionally, the Nit: Please expand "PMTU" on first use. [FG]: Change made --------------------------------------------------------------------------- §4.2.5: algorithm used for the FINGERPRINT attribute (i.e., the CRC-32 of the payload XOR'ed with the 32-bit value 0x5354554e [ITU.V42.2002]). The location of the citation in here implies that the XOR'ing described is part of V.42. Given that 0x53545554E is ASCII for "STUN," I'm pretty sure that's not part of the underlying CRC. Would suggest reworking as: algorithm used for the FINGERPRINT attribute (i.e., the CRC-32 calculated per the algorithm defined in [ITU.V42.2002], such has subsequently been XOR'ed with 32-bit value 0x5354554e). [FG]: Change made
- [tram] Adam Roach's Discuss on draft-ietf-tram-st… Adam Roach
- Re: [tram] Adam Roach's Discuss on draft-ietf-tra… Spencer Dawkins at IETF
- Re: [tram] Adam Roach's Discuss on draft-ietf-tra… Simon Perreault
- Re: [tram] Adam Roach's Discuss on draft-ietf-tra… Spencer Dawkins at IETF
- Re: [tram] Adam Roach's Discuss on draft-ietf-tra… Simon Perreault
- Re: [tram] Adam Roach's Discuss on draft-ietf-tra… Spencer Dawkins at IETF
- Re: [tram] Adam Roach's Discuss on draft-ietf-tra… Gonzalo Camarillo
- Re: [tram] Adam Roach's Discuss on draft-ietf-tra… Spencer Dawkins at IETF
- Re: [tram] Adam Roach's Discuss on draft-ietf-tra… Gonzalo Salgueiro (gsalguei)
- Re: [tram] Adam Roach's Discuss on draft-ietf-tra… Gonzalo Camarillo
- Re: [tram] Adam Roach's Discuss on draft-ietf-tra… Gonzalo Salgueiro (gsalguei)
- Re: [tram] Adam Roach's Discuss on draft-ietf-tra… Gonzalo Camarillo
- Re: [tram] Adam Roach's Discuss on draft-ietf-tra… Gonzalo Camarillo
- Re: [tram] Adam Roach's Discuss on draft-ietf-tra… Gonzalo Salgueiro (gsalguei)
- Re: [tram] Adam Roach's Discuss on draft-ietf-tra… Gonzalo Camarillo
- Re: [tram] Adam Roach's Discuss on draft-ietf-tra… Gonzalo Salgueiro (gsalguei)
- Re: [tram] Adam Roach's Discuss on draft-ietf-tra… Felipe Garrido (fegarrid)
- Re: [tram] Adam Roach's Discuss on draft-ietf-tra… Felipe Garrido (fegarrid)
- Re: [tram] Adam Roach's Discuss on draft-ietf-tra… Adam Roach