[tram] draft-ietf-tram-stun-pmtud-06 review
"Asveren, Tolga" <tasveren@rbbn.com> Sun, 18 February 2018 05:41 UTC
Return-Path: <tasveren@rbbn.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 3F59E12426E for <tram@ietfa.amsl.com>; Sat, 17 Feb 2018 21:41:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.11
X-Spam-Level:
X-Spam-Status: No, score=-4.11 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" header.d=sonusnetworks.onmicrosoft.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 xpy86HWuSKFi for <tram@ietfa.amsl.com>; Sat, 17 Feb 2018 21:41:02 -0800 (PST)
Received: from us-smtp-delivery-181.mimecast.com (us-smtp-delivery-181.mimecast.com [63.128.21.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 897F0124235 for <tram@ietf.org>; Sat, 17 Feb 2018 21:41:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=SonusNetworks.onmicrosoft.com; s=selector1-rbbn-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=103xbbC5YC6rpoxF8uo4/VYJ/xOOnjZxgQRNC/MVidw=; b=HvDV4ieB+SjjAQMhTuxJ21RPHotCSRULOZ+++sPuKWWg/FvPm4A3qXKvjnJPnQofDxY0ugMF0ne94zKSanPUnrVOqgcKN/zJsR8ie8//3+7QP1y27yywZR/WMXkW5IIJBqixLsW8fwI8OcbeP69kjw4mstlOjnGW6856tPuym9U=
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0178.outbound.protection.outlook.com [216.32.180.178]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-186-Rwi37nvuPFaoJc6MM4VPTw-1; Sun, 18 Feb 2018 00:40:58 -0500
Received: from CY4PR03MB3160.namprd03.prod.outlook.com (10.171.245.165) by CY4PR03MB3128.namprd03.prod.outlook.com (10.171.245.157) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.18; Sun, 18 Feb 2018 05:40:55 +0000
Received: from CY4PR03MB3160.namprd03.prod.outlook.com ([fe80::4499:4345:1b21:90b8]) by CY4PR03MB3160.namprd03.prod.outlook.com ([fe80::4499:4345:1b21:90b8%13]) with mapi id 15.20.0506.021; Sun, 18 Feb 2018 05:40:55 +0000
From: "Asveren, Tolga" <tasveren@rbbn.com>
To: Marc Petit-Huguenin <petithug@acm.org>, Marc Petit-Huguenin <marc@petit-huguenin.org>, "Gonzalo Salgueiro (gsalguei@cisco.com)" <gsalguei@cisco.com>, "tram@ietf.org" <tram@ietf.org>
Thread-Topic: draft-ietf-tram-stun-pmtud-06 review
Thread-Index: AdOoeuWqoyIVbPnJTkKqVXoa0q8HIQ==
Date: Sun, 18 Feb 2018 05:40:55 +0000
Message-ID: <CY4PR03MB316039CC07807621C64AFE39A5C90@CY4PR03MB3160.namprd03.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [73.29.251.142]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; CY4PR03MB3128; 7:Mv2fXV/CBsrxhJKrZVZNDm0/UxHc1ylys8h4f6X+x739ANddBfSueAlVJvqTHpHN43EFoIuzLD3bZazuuo6bfk9s9VdSPrHZ+BI4nUrlpgm9DdpAZPLQQTQwLEYOvfaBwldRWNVUgumbOHtGrJorksm3pc5XWAwIwX1y6tW9Ci0BG26bBci0tiyBiPXMtYb64Sd/T6iOI+5EBHod6fzU6AeeWKCQaO87lPKgHN7WkJYMxvmDe+qFG7DB44zRPXup; 20:Um4RzsmB2kv1xnQCLCPJ4SWRnCDekHyPYAvTQrM2WZg10r8Qsf5++Z4AfiJ2O5Knu8XryIACHbslYj8Uptl4rR8lHEvxMkwN0bCn/1yoWRkEYI2iC+Ss71g8kKNvL/dACyEDZCxuYGK0/9qRPp6tjo6omlePwFXJ723kCsH+BpQ=
x-ms-office365-filtering-correlation-id: a2d7fe9a-0664-4006-853d-08d576922e1d
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:CY4PR03MB3128;
x-ms-traffictypediagnostic: CY4PR03MB3128:
x-microsoft-antispam-prvs: <CY4PR03MB31284268D4F76E6F91563ADFA5C90@CY4PR03MB3128.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001056)(6040501)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231101)(944501161)(93006095)(93001095)(6041288)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:CY4PR03MB3128; BCL:0; PCL:0; RULEID:; SRVR:CY4PR03MB3128;
x-forefront-prvs: 058707456E
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(366004)(39380400002)(376002)(346002)(39850400004)(396003)(189003)(199004)(2906002)(5250100002)(81166006)(81156014)(14454004)(97736004)(8676002)(966005)(106356001)(3660700001)(478600001)(5660300001)(3280700002)(55016002)(68736007)(9686003)(25786009)(6116002)(8936002)(2501003)(3846002)(53936002)(6436002)(6306002)(2900100001)(74316002)(7736002)(7696005)(305945005)(110136005)(316002)(86362001)(59450400001)(6506007)(33656002)(26005)(102836004)(186003)(105586002)(66066001)(99286004); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR03MB3128; H:CY4PR03MB3160.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
x-microsoft-antispam-message-info: w9DvWo0c7NTJNeZ2PhmphHpFSnhHQXRxNyvir7UK2NyeTArXPFniYC5afMvnbXMm2z6TydhsugAoKddlZ8eHPL/wdEPTg/9HqBeQabA5XDxQl0Q6evBWc4hd2JDxLChS9uxjp8+IQVN3EOyawB6Ecd7erptFibyqnGnvSZNoOK8=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
MIME-Version: 1.0
X-OriginatorOrg: rbbn.com
X-MS-Exchange-CrossTenant-Network-Message-Id: a2d7fe9a-0664-4006-853d-08d576922e1d
X-MS-Exchange-CrossTenant-originalarrivaltime: 18 Feb 2018 05:40:55.2063 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR03MB3128
X-MC-Unique: Rwi37nvuPFaoJc6MM4VPTw-1
Content-Type: multipart/alternative; boundary="_000_CY4PR03MB316039CC07807621C64AFE39A5C90CY4PR03MB3160namp_"
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/Siv9YneIMNfFqbN_1C7sDXnCEcE>
Subject: [tram] draft-ietf-tram-stun-pmtud-06 review
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.22
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: Sun, 18 Feb 2018 05:41:05 -0000
Marc, Gonzalo, Some comments/questions for draft-ietf-tram-stun-pmtud-06: i- 4. Implementations supporting this specification MUST implement the server side of both the Simple Probing mechanism (Section 4.1) and the Complete Probing mechanism (Section 4.2). Implementations supporting this specification MUST implement the client side of the Complete Probing mechanism. They MAY implement the client side of the Simple Probing mechanism. I don't see the rationale behind mandating this behavior. Such semantics in general are taken care of in the context of a capability negotiation mechanism, which this document does not specify. As it stands right now, I think this is best left to local policy and bilateral agreements and I would suggest not to use anything stronger than "RECOMMEND". ii- 4.1 DF bit set over UDP. ==> DF bit in IP Header. Right? (the same in 4.2) iii- 4.1.1 A client MUST NOT send a probe if it does not have knowledge that the server supports this specification. This is done either by external signalling or by a mechanism specific to the UDP protocol to which PMTUD capabilities are added or by one of the mechanisms specified in Section 5. I suggest adding text for possible use of local policy/bilateral agreements for this purpose. iv- 4.2 Some 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. What is meant here as "some protocols"? Are you referring to what is carried as payload of UDP or what is used below UDP? v- 4.2 In the first packet identification mechanism, the server computes a checksum over each packet received and sends back to the sender the list of checksums ordered chronologically. The client compares this list to its own list of checksums. What if there are two probes with the same checksum right after each other and one of them is lost? How can client disambiguate such a case in the response? v- 7 The Simple Probing mechanism may be used without authentication because this usage by itself cannot trigger an amplification attack because the Probe Response is smaller than the Probe Request. Isn't the same true for Sum(Probe Requests) > (Report Response)? vii- nit == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 1, 2017) is 169 days in the past. Is this intentional? Thanks, Tolga
- [tram] draft-ietf-tram-stun-pmtud-06 review Asveren, Tolga
- Re: [tram] draft-ietf-tram-stun-pmtud-06 review Marc Petit-Huguenin
- Re: [tram] draft-ietf-tram-stun-pmtud-06 review Asveren, Tolga
- Re: [tram] draft-ietf-tram-stun-pmtud-06 review Marc Petit-Huguenin
- Re: [tram] draft-ietf-tram-stun-pmtud-06 review Asveren, Tolga