Re: [tram] Review of draft-ietf-tram-stun-pmtud-03
"Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com> Mon, 20 February 2017 19:17 UTC
Return-Path: <gsalguei@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 CB4441296DC for <tram@ietfa.amsl.com>; Mon, 20 Feb 2017 11:17:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-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
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 I0wztV3KVLEk for <tram@ietfa.amsl.com>; Mon, 20 Feb 2017 11:17:18 -0800 (PST)
Received: from alln-iport-4.cisco.com (alln-iport-4.cisco.com [173.37.142.91]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7A3711296DA for <tram@ietf.org>; Mon, 20 Feb 2017 11:17:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=90536; q=dns/txt; s=iport; t=1487618238; x=1488827838; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=jWlMb7eH5ANdvgiwf0aT7uQpStCFn+tX08fg76CR2fA=; b=NWsDpjRGXYYYFTj4QzC19NWMzZRFfHiRqvUp+f9Vywxxw2SC2EcCSw71 ECp7C9MxLGVr1/80IAIDRvsDvs14DgyCqK4UU8FNS0Ji6R8WaFgUcWyxv tpbdmcxh5D9ob3rVVoTWUqL8/bQ2b47j7fNxz3h7rXLxMt4x/n5BJSRej k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0CaAQB/QKtY/5ldJa1eGQEBAQEBAQEBAQEBBwEBAQEBgm85KWGBCQeDVIoIp0qCCQMfAQqFeAIagjQ/GAECAQEBAQEBAWIohHECBAEBGAlLCxACAQg4AQYDAgICJQsUEQIEDgWJbw6teYImi1QBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYZMggWCaoQwDi2Cby6CMQWVXoYmAZIcgXuFF4NQhiiPB4QaAR84gQBTFT4RAYQ4HYFhdYhUgTCBDQEBAQ
X-IronPort-AV: E=Sophos;i="5.35,187,1484006400"; d="scan'208,217";a="387160721"
Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by alln-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 20 Feb 2017 19:17:17 +0000
Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id v1KJHGYg024201 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 20 Feb 2017 19:17:17 GMT
Received: from xch-aln-009.cisco.com (173.36.7.19) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Mon, 20 Feb 2017 13:17:16 -0600
Received: from xch-aln-009.cisco.com ([173.36.7.19]) by XCH-ALN-009.cisco.com ([173.36.7.19]) with mapi id 15.00.1210.000; Mon, 20 Feb 2017 13:17:16 -0600
From: "Gonzalo Salgueiro (gsalguei)" <gsalguei@cisco.com>
To: Brandon Williams <brandon.williams@akamai.com>
Thread-Topic: [tram] Review of draft-ietf-tram-stun-pmtud-03
Thread-Index: AQHSi562xm+h9eSKVEaps8DyETEBQaFyqTuA
Date: Mon, 20 Feb 2017 19:17:16 +0000
Message-ID: <8E88169F-1BF3-4B31-872B-F12C4CFB7A9A@cisco.com>
References: <dfe9d46b-9fc4-22cd-b084-77c67e72ed9b@akamai.com> <e21a1587-649b-fc0f-cf8d-245d0c7c85f5@petit-huguenin.org> <2a6ae451-739f-3d96-d371-0c92a693cfbd@akamai.com>
In-Reply-To: <2a6ae451-739f-3d96-d371-0c92a693cfbd@akamai.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.24.85.232]
Content-Type: multipart/alternative; boundary="_000_8E88169F1BF34B31872BF12C4CFB7A9Aciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/P-TfykOdK8R6KWQzEHMKY4KGXnE>
Cc: "draft-ietf-tram-stun-pmtud@tools.ietf.org" <draft-ietf-tram-stun-pmtud@tools.ietf.org>, "tram@ietf.org" <tram@ietf.org>
Subject: Re: [tram] Review of draft-ietf-tram-stun-pmtud-03
X-BeenThere: tram@ietf.org
X-Mailman-Version: 2.1.17
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: Mon, 20 Feb 2017 19:17:22 -0000
Thanks for the re-review, Brandon. We posted a new version (-05) that hopefully addresses all your points below. Please confirm. Responses inline... On Feb 20, 2017, at 12:27 PM, Brandon Williams <brandon.williams@akamai.com<mailto:brandon.williams@akamai.com>> wrote: Hi Marc, Thanks. It looks like most of my comments are resolved. After re-reading, I've still got a few comments, at least one of which I see that I missed on the previous pass. My new comments are below. Nothing is in-line. Let me know if anything is unclear. --Brandon Section 4 I suggest moving the first paragraph "A client MUST NOT ..." to section 4.1.1, since it's about forming/sending a message. Seems like it would be a good last paragraph in that section. Fixed. Section 4.1.1 para 2 s/transctaion/transaction/ Fixed. Section 4.1.1 para 3 My question about FINGERPRINT was meant to indicate that the text should say why it's needed. I see you've added that explanation elsewhere. Maybe add the same here too. Fixed. Section 4.2.1 para 1 s/The server/The client/ Fixed. Section 4.2.5 I still find "the same as" in para 1 confusing here since it's not applied to any header fields. Maybe "similar to”? Fixed. Also, I found para 2 a little difficult to read. How about: For each STUN Probe Indication or Request, the server retrieves the STUN FINGERPRINT value. For all other packets, the server calculates the checksum as described above. It puts these FINGERPRINT and checksum values in a chronologically ordered list that is sent back in the Report Response. Fixed. Section 5.2 I'm still uncertain about this section. The receiver behavior makes sense, but that's not really what I was questioning. It's not clear what you intend for the original probe sender whose support for PMTUD is being assumed by the receiver. How did that first machine know that it was safe to send its probe? This section seems to imply that it injects probes as a way to tell the receiver that it supports the protocol, though you're right, it doesn't actually say that so I think I just misunderstood your intention. So, how does a machine that doesn't know whether the receiver supports the PMTUD protocol know whether it's safe to send a probe when it hasn't received one from the other party? Is the idea that one side or the other must receive this information via signaling or some other means? We believe this is answered in Section 5.1. In fact, Section 5.1. states when the client can send the probe, whereas Section 5.2 states when the server can become a client and send to the original client. I see the paragraph in section 4 that I previously missed which states the client MUST NOT send if it doesn't know the other party supports it. Maybe section 5.2 could say something like "In cases where only one endpoint (the initial client) knows that its peer endpoint (the initial server) supports PMTUD, the initial client sends a Probe Request or Indication to the initial server." That seems a little clunky, but I think you'll get the point of my suggestion. We updated the text, not with your exact proposed text, but with text that blended a bit better with the existing text and (hopefully) addressed the source of your uncertainty. Section 6.1 para 2 Maybe you could indicate that section 4.2.5 and 4.2.6 describe two methods for acquiring and formatting the identifiers that could be used for this purpose. It's clear to me that this is the case, but the current text seems to imply that no options are provided by this document. Fixed. Cheers, Gonzalo On 02/16/2017 02:52 PM, Marc Petit-Huguenin wrote: Hi Brandon, Thanks again for the review, and sorry for the delay in responding. See my comments inline. A new version will be published in a few minutes, please have a look too. Thanks. On 12/27/2016 11:27 AM, Brandon Williams wrote: Hi all, Apologies for taking so long to complete a review of this one. Although my list of notes is long, there's nothing really substantive here. All of my comments are just suggestions to improve the document's clarity. Incorporate or discard as you see fit. Please let me know if any of the following is unclear. --Brandon 1. Introduction I find the second paragraph a tiny bit difficult to read. Here's a suggestion. OLD: This document only describes how probing mechanisms are implemented with Session Traversal Utilities for NAT (STUN). The algorithm to find the Path MTU is described in [RFC4821]. NEW: This document describes probing mechanisms for Session Traversal Utilities for NAT (STUN) for use in implementing the Path MTU Discovery algorithm described in [RFC4821]. Your text change a bit the meaning I was trying to convey in the original text. What about something like the following text: New: Not all UDP-based implement the Path MTU discovery mechanism described in [RFC4821]. These protocols can make use of the probing mechanisms described in this document instead of designing their own adhoc extension. These probing mechanisms are implemented with Session Traversal Utilities for NAT (STUN), but their usage is not limited to STUN-based protocols. I also find the fourth paragraph a tiny bit difficult to read. OLD: Additional network characteristics like the network path (using the STUN Traceroute mechanism described in [I-D.martinsen-tram-stuntrace]) and bandwidth availability (using the mechanism described in [I-D.martinsen-tram-turnbandwidthprobe]) can be discovered using complementary techniques. NEW: Complimentary techniques can be used to discover addition network characteristics, such as the network path (using the STUN Traceroute mechanism described in [I-D.martinsen-tram-stuntrace]) and bandwidth availability (using the mechanism described in [I-D.martinsen-tram-turnbandwidthprobe]). Done. 2. Overview of Operations In paragraph three, the first "it" in the paragraph should be expanded. OLD: ... then it initiates Probe transactions, ... NEW: ... then the Client initiates Probe transacations, ... Done. Same comment for the next paragraph. OLD: ... then it sends Probe Indications of various sizes ... NEW: ... then the Client sends Probe Indications of various sizes ... Done. 4. Probing Mechanisms In paragraph six, I think the SHOULD requirement about retransmissions belongs in section 4.1.1, which already describes this requirement in other terms ("the Rc parameter ... is set to 3."). This part of section 4 should stick to providing the MUST/MAY requirements for which of the mechanisms are to be implemented. Sentence removed. Additionally, I think that paragraph six could be moved to be text for the currently empty section 4.1. Simple Probing Mechanism. In that case, paragraphs 7-10 could be moved to be text for the currently empty section 4.2. Complete Probing Mechanism. I think moving the high-level descriptions of the two mechanisms into their respective sections improves the document flow. Done. Finally, in the last paragraph of the section, it states "... the client adds a sequence number in front of each UDP packet sent." I think you mean "... the client prepends the UDP data with a header that provides a sequence number." At least, this is what the description in the later section indicates to me. Done. 4.1.1. Sending a Probe Request This section should indicate the STUN method type used for a Probe Request (prefered) or forward reference section 8.1. Done, using your preference. Regarding authentication, why would an implementation authenticate the Probe transaction? Is doing so recommended? If so, why? This is discussed later in security considerations, but it was unclear to me at this point in the document. Rewrote the text with a bit more explanations. Regarding the FINGERPRINT attribute, why is it required? The STUN messages need to be sent together with the packets of the the other protocol, which can be anything, so the FINGERPRINT helps differentiate STUN packets. 4.1.2. Receiving a Probe Request Here again, why is the FINGERPRINT attribute required? See above. 4.1.3. Receiving a Probe Response OLD: If the Probe transactions times out ... NEW: If the Probe transaction times out ... Done. 4.2.1. Sending the Probe Indications and Report Request Why MUST the Probe Indication be authenticated, when this is not required (only allowed) for a Probe Request? Here again, it's discussed later, but was unclear to me here. Same than above, clarified the text. Also, same question as above about FINGERPRINT here. See above. This section should indicate the STUN method type used for a Report Request (prefered) or forward reference section 8.1. Done, using your preference. 4.2.3. Receiving a Probe Indication and Report Request I suggest that you forward reference the section that describes construction of the IDENTIFIERS attribute in the last paragraph. Done. 4.2.4. Receiving a Report Response The description of Probe Failure is a bit incomplete. It should include a little more detail. OLD: If the Probe Indication identifier cannot be found in the Report Response, this is interpreted as a Probe Failure, as defined in [RFC4821] Section 7.5. NEW: If the Probe Indication identifier cannot be found in the Report Response but identifiers for other packets sent before or after the Probe Indication can all be found, this is interpreted as a Probe Failure as defined in [RFC4821] Section 7.5. Done. 4.2.5. Using Checksums as Packet Identifiers The second paragraph states "The algorithm used to calculate the checksum is the same as the algorithm used for the FINGERPRINT attribute." I find this description a bit unclear, since the description of the FINGERPRINT calculation in RFC5389 discusses the STUN header fields, etc. Here, you're just talking about generating a CRC-32 value XORed with 0x5354554e. It might be more clear to just say that. Done. 5.2. Implicit Probe Support Signaling Mechanism I'm a little concerned about the idea of just injecting probes as a way to figure out whether the receiver supports them. It's hard to know for every possible protocol that this will work and will not break the protocol. Maybe add a cautionary note. No, the idea is not to inject probes to detect support. Here we know that the receiver will support receiving probes, because it acted as a probe sender. The sender of a probe implicitly signals that it can itself receive and process probes. Section 4 states that all implementations of this specification MUST implement the server side of both probing mechanisms, and this is how the implicit signaling mechanism can work. 6.1. IDENTIFIERS Sections 4.2.5. and 4.2.6. each describe 32 bit identifiers. I think section 6.1. should say a little more than just "contents are opaque". I suggest that you describe specifically what the attribute value will look like if one of the two 32 bit schemes is used and declare that other protocols may generate different values. All right, that was the difficult part. When trying to do what you suggested, I discovered that there was no mechanism to put the Probe packets in the list in the IDENTIFIERS attribute. So the text in both section was rewritten to add that possibility. The sections also contain the description of the content of the IDENTIFIERS attribute. 6.2. PMTUD-SUPPORTED For clarity, I suggest something a little more like the value description of DONT-FRAGMENT from RFC5766. OLD: This attribute is empty. NEW: This attribute has no value part and thus the attribute length field is 0. Done. -- Brandon Williams; Chief Architect Cloud Networking; Akamai Technologies Inc. _______________________________________________ tram mailing list tram@ietf.org<mailto:tram@ietf.org> https://www.ietf.org/mailman/listinfo/tram
- [tram] Review of draft-ietf-tram-stun-pmtud-03 Brandon Williams
- Re: [tram] Review of draft-ietf-tram-stun-pmtud-03 Marc Petit-Huguenin
- Re: [tram] Review of draft-ietf-tram-stun-pmtud-03 Marc Petit-Huguenin
- Re: [tram] Review of draft-ietf-tram-stun-pmtud-03 Brandon Williams
- Re: [tram] Review of draft-ietf-tram-stun-pmtud-03 Gonzalo Salgueiro (gsalguei)
- Re: [tram] Review of draft-ietf-tram-stun-pmtud-03 Brandon Williams