Re: [tram] draft-ietf-tram-stun-pmtud-06 review

"Asveren, Tolga" <tasveren@rbbn.com> Sun, 11 March 2018 13:40 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 F38CA126D05 for <tram@ietfa.amsl.com>; Sun, 11 Mar 2018 06:40:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.491
X-Spam-Level:
X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, 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 (message 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 37usmCNdvI9I for <tram@ietfa.amsl.com>; Sun, 11 Mar 2018 06:40:34 -0700 (PDT)
Received: from us-smtp-delivery-181.mimecast.com (us-smtp-delivery-181.mimecast.com [216.205.24.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 E1F361201FA for <tram@ietf.org>; Sun, 11 Mar 2018 06:40:33 -0700 (PDT)
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=wQnVsAt1nqAMxwWvlCxYa3tNEL1WlqyR3eiTgqq9ma0=; b=hjEX2KZh4wBFHKQJSvRs514j6H2dUYbEk2DecdDxw0iwQexz32tyeo/I4ZGvRQN1X6M2ExB+ifRYeEvmAZqFTa5JNrnIS3+4m+lB3j33QUlWwghUHeCgE815iw9iHPgMtzeRS7RGf887uPLacCVP/UvybLmdTzpPgXBDFZcqCNI=
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03lp0017.outbound.protection.outlook.com [216.32.181.17]) (Using TLS) by us-smtp-1.mimecast.com with ESMTP id us-mta-201-Thlaci7NPLu1n4vOod0nug-1; Sun, 11 Mar 2018 09:40:30 -0400
Received: from CY4PR03MB3160.namprd03.prod.outlook.com (10.171.245.165) by CY4PR03MB2487.namprd03.prod.outlook.com (10.168.165.11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.548.13; Sun, 11 Mar 2018 13:40:24 +0000
Received: from CY4PR03MB3160.namprd03.prod.outlook.com ([fe80::34a3:3001:f444:3072]) by CY4PR03MB3160.namprd03.prod.outlook.com ([fe80::34a3:3001:f444:3072%13]) with mapi id 15.20.0548.021; Sun, 11 Mar 2018 13:40:24 +0000
From: "Asveren, Tolga" <tasveren@rbbn.com>
To: Marc Petit-Huguenin <petithug@acm.org>, "Gonzalo Salgueiro (gsalguei@cisco.com)" <gsalguei@cisco.com>, "tram@ietf.org" <tram@ietf.org>
Thread-Topic: [tram] draft-ietf-tram-stun-pmtud-06 review
Thread-Index: AdOoeuWqoyIVbPnJTkKqVXoa0q8HIQKi1NCAACzPOKABXvt2AAACPF6Q
Date: Sun, 11 Mar 2018 13:40:24 +0000
Message-ID: <CY4PR03MB316053DB4B75FCF6A9619233A5DC0@CY4PR03MB3160.namprd03.prod.outlook.com>
References: <CY4PR03MB316039CC07807621C64AFE39A5C90@CY4PR03MB3160.namprd03.prod.outlook.com> <10ce3dde-2401-dc4f-e231-13678f6494d1@acm.org> <CY4PR03MB3160D0E46134CF10AE7CBAF4A5DB0@CY4PR03MB3160.namprd03.prod.outlook.com> <a7726725-5c60-c284-9249-29e67b6a8d7f@acm.org>
In-Reply-To: <a7726725-5c60-c284-9249-29e67b6a8d7f@acm.org>
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; CY4PR03MB2487; 7:MqV2U+c0a6UO7jolDPwjZgQPQrV9lMawEFqzqE0junboXOH9JTVD8hMwFI8l8RzGSsgIUqcpzdVQyaeC/IVSgMYPc3JiX+0bcmSDMw/bicw/VA3zd7CezT4T3+9yokYoJLSuwbQjZjlxbCbKv5wTFxAU/nvvBGWh5ZVtwe+ExFZjLe6T/bSn3sgLE44IDt6L/Mr82oAdxD0TSp/GbO/bLxgzOq3U8GTMfbsp13B5qyKY4ep9e/TIMi29tqlK/06/; 20:tO81a7QgpsY2n70Ije6moXshBy6CW/Rp3x8shYH3T86iQzNRXp7Dz/ryvTli0xw+qaa2olwZxQALYE7oJUD6kaF/lAjTQa6Bo6d9Enm+qlxf7AkCXVKNBjLXOnzBBv4nz5XvX/RE5l7Xkh3HzESwqXnAlIrVugyEpygy0Ywsoj0=
x-ms-office365-filtering-correlation-id: 7735767e-77a5-441f-dc23-08d58755a4c7
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603328)(7153060)(7193020); SRVR:CY4PR03MB2487;
x-ms-traffictypediagnostic: CY4PR03MB2487:
x-microsoft-antispam-prvs: <CY4PR03MB2487711D0447679116A60EC0A5DC0@CY4PR03MB2487.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(158342451672863)(192374486261705)(128460861657000)(95692535739014)(213716511872227)(81160342030619);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040522)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231220)(944501244)(52105095)(6041310)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:CY4PR03MB2487; BCL:0; PCL:0; RULEID:; SRVR:CY4PR03MB2487;
x-forefront-prvs: 0608DEDB67
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(39850400004)(366004)(396003)(376002)(39380400002)(346002)(189003)(199004)(51444003)(252514010)(13464003)(51914003)(478600001)(966005)(5660300001)(229853002)(45080400002)(102836004)(74316002)(68736007)(186003)(26005)(8936002)(93886005)(3660700001)(59450400001)(106356001)(33656002)(81156014)(305945005)(8676002)(81166006)(2950100002)(6506007)(53546011)(7736002)(2906002)(6116002)(3846002)(86362001)(99286004)(66066001)(97736004)(3280700002)(2900100001)(7696005)(76176011)(110136005)(6246003)(2501003)(105586002)(316002)(5250100002)(6436002)(6306002)(55016002)(9686003)(25786009)(14454004)(53936002); DIR:OUT; SFP:1101; SCL:1; SRVR:CY4PR03MB2487; H:CY4PR03MB3160.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
x-microsoft-antispam-message-info: M14oe7cuf+lqLyQAdKplrpyUhThGvi6eQmNkzg3bGJMPdS9ipg5mRVC/zvfPd5ZCZ+jIoAo+xLCcCY94KMmMcOL0pMKlJdOdJ8sOUvayLl9pdIcqetFVcSuFs+UxlxvoCZQ6jSomFc+xE1rtvOxnNa3tUDWDRSr58j3AGfbDubDR2tZXrHue2hR9thczdf7nHaqriLzCllUcQUp5zGOq/FovM6w54qj+t9LnssqRTV36KPBdP3NwxWeW47Ayg8BzkMvu/uigHhaEiOt9HRwTCslZsMJ1ZvZYnVhpTQLNP306dddUl5h+SJ+PHl6B8Sw8rVseHQ984Y2uO2QeDkr6CQ==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
MIME-Version: 1.0
X-OriginatorOrg: rbbn.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 7735767e-77a5-441f-dc23-08d58755a4c7
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2018 13:40:24.8387 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 29a671dc-ed7e-4a54-b1e5-8da1eb495dc3
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR03MB2487
X-MC-Unique: Thlaci7NPLu1n4vOod0nug-1
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: base64
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/_jYAfaFIBUWGc1W53Y8SiePvcWs>
Subject: Re: [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, 11 Mar 2018 13:40:38 -0000

Marc,

Thanks for the explanations/answers. I am happy with the current version based these. I don’t think any changes are needed and I don’t have further comments.

Thanks,
Tolga

-----Original Message-----
From: Marc Petit-Huguenin <petithug@acm.org> 
Sent: Sunday, March 11, 2018 8:35 AM
To: Asveren, Tolga <tasveren@rbbn.com>; Gonzalo Salgueiro (gsalguei@cisco.com) <gsalguei@cisco.com>; tram@ietf.org
Subject: Re: [tram] draft-ietf-tram-stun-pmtud-06 review

See inline.

On 03/04/2018 07:03 AM, Asveren, Tolga wrote:
> Hi Marc,
> 
> Please see inline for comments/answers/questions.
> 
> Thanks,
> Tolga
> 
> -----Original Message-----
> From: Marc Petit-Huguenin <petithug@acm.org> 
> Sent: Saturday, March 3, 2018 10:42 AM
> To: Asveren, Tolga <tasveren@rbbn.com>; Gonzalo Salgueiro (gsalguei@cisco.com) <gsalguei@cisco.com>; tram@ietf.org
> Subject: Re: [tram] draft-ietf-tram-stun-pmtud-06 review
> 
> Thanks for the review, please see inline.
> 
> As the cutoff is Monday afternoon, I'll publish -07 just after sending this email.
> 
> On 02/17/2018 09:40 PM, Asveren, Tolga wrote:
>> 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".
> 
> It took me some time to remember why that was the case.  IIRC, one of the reasons of doing this is because of the implicit probe support in section 5.2.  Because there is no explicit signaling there, we need the server side (which was previously the client side) to be ready to respond to both Simple and Complete Probing.  Hence the "server must do both, client choose what they want to do" rule.
> 
> The other reason is that if we let implementers choose, then Complete Probing - which is the correct way of doing probing - will never be used.
> [TOLGA] If client does not get replies for a mechanism it SHOULD try the other one. Honestly I don’t see a compelling reason to mandate anything on the server side. There is no negotiation mechanism and that can’t be enforced on protocol level anyhow. I suggest to use RECOMMNED for server and add a sentence for client behavior that it SHOULD try the other mechanism if one does not get any replies at all.

No, not making the Complete Probing mandatory in the server removes the compliance with RFC 4821, which is the whole point of this document.  If people do not want compliance with RFC 4821, they just have to not implement that RFC-to-be.

After Complete Probing is implemented on the server side, it's easy to add Simple Probing, so making it mandatory too does not add much burden on the implementer.

But if you insist of making the server support as RECOMMEND, then I'll split the RFC-to-be in two RFCs, one for Complete Probing and compliance with RFC 4821, and the other for Simple Probing.

> 
>>
>> ii- 4.1
>> DF bit set over UDP.
>> ==>
>> DF bit in IP Header.
>> Right?  (the same in 4.2)
> 
> Not really, the Probe Request is still sent over UDP, so I changed the text to that (twice):
> 
>  The Simple Probing mechanism is implemented by sending a Probe  Request with a PADDING [RFC5780] attribute over UDP with the DF bit  set in the IP header.  A router on the path to the server can reject  this request with an ICMP message or drop it.
> 
>  The Complete Probing mechanism is implemented by sending one or more  Probe Indications with a PADDING attribute over UDP with the DF bit  set in the IP header followed by a Report Request to the same server.
> [TOLGA] Looks good, I just wanted to make sure about the "DF bit in IP header" part.
> 
>>
>> 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.
> 
> I am not sure what to add to what is said.  Do you have text to suggest?
> [TOLGA] Maybe by just adding something like:
> "Information about client/server support for this specification, for example, could be based on local policy and bilateral agreements among relevant organizations."

See above.

> 
>>
>> 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?
> 
> The former.  I changed the text to "application layer protocols:"
> [TOLGA] Thanks.
> 
>>
>> 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?
> 
> I am not sure to get the problem here.  The sender keeps a chronologically ordered list of the checksums of the sent packets (data and probes), so in that case there is a sequence of two identical checksums in that list.  The server sends back a list of checksums, but with only one of that value (or even 0).  The loss can be detected.
> [TOLGA] Loss can be detected but which one is lost?
> 
> Probe-n  (checksum-A)
> Probe-n+1 (checksum-A)
> 
> Only a single reply for (checksum-A) is received.

Replies are only for the Simple Probing mechanism, a mechanism that does not need to identify UDP packets.

> 
> Is Probe-n or Probe-n+1 lost?

If the same probe is sent multiple times but some are dropped then we know that, we just do not know exactly which one.

The whole point of this is to separate the packets drops because of a network condition (which should not affect the PMTU) from the the packets drops because of an oversized packet, which does not require to know exactly which packet was dropped, as they are all dropped.  Note that two probes with different lengths will have different checksum, so we can isolate exactly what probe was rejected and why.

That said, RFC 4821 leaves the client free to implement whatever algorithm it want, so there may be some future algorithm that could use the knowledge of exactly which packet was dropped.  IN that case the future RFC that will describe how to recognize the UDP packets for a specific protocol will just have to choose a method that permits to differentiate individual packets in the Report 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)?
> 
> I think that mechanism was set following a review that was worried about amplification attack.  We have the simple probe mechanism without authentication to keep the barrier to entry very low, i.e. the minimum required implementation possible.
> 
> Security expert can chime in.
> [TOLGA] I think that would be good. Who would be that?
> 
>>
>> 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?
> 
> Will be upgraded with the next publication.
> [TOLGA] Thanks.
> 

-- 
Marc Petit-Huguenin
Email: marc@petit-huguenin.org
Blog: https://marc.petit-huguenin.org
Profile: https://www.linkedin.com/in/petithug