[tram] Review of draft-ietf-tram-stun-pmtud-03
Brandon Williams <brandon.williams@akamai.com> Tue, 27 December 2016 19:27 UTC
Return-Path: <brandon.williams@akamai.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 DD2E9129B03 for <tram@ietfa.amsl.com>; Tue, 27 Dec 2016 11:27:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.801
X-Spam-Level:
X-Spam-Status: No, score=-5.801 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=akamai.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 e8sq_g8xxOp3 for <tram@ietfa.amsl.com>; Tue, 27 Dec 2016 11:27:33 -0800 (PST)
Received: from prod-mail-xrelay05.akamai.com (prod-mail-xrelay05.akamai.com [23.79.238.179]) by ietfa.amsl.com (Postfix) with ESMTP id 61C2E129B02 for <tram@ietf.org>; Tue, 27 Dec 2016 11:27:33 -0800 (PST)
Received: from prod-mail-xrelay05.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id A676D433421; Tue, 27 Dec 2016 19:27:32 +0000 (GMT)
Received: from prod-mail-relay10.akamai.com (prod-mail-relay10.akamai.com [172.27.118.251]) by prod-mail-xrelay05.akamai.com (Postfix) with ESMTP id 8FF1D433408; Tue, 27 Dec 2016 19:27:32 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1482866852; bh=RezEjp5rOEJAlQA+OgJLcImzVVul/RHE9ebi07cusPA=; l=6229; h=From:To:Date:From; b=B15KkRv8osmQUF1FJQsGai1nri8myj29NpFCgRY3iB+XOdG6KLRWE5NnDEyHxm9kb TvzsH8IV5bU24/+JB9yj/m3pjHelvC/I/qq6Q8U9RkqOv+RndBtpqoEfojdZP2RYKp rHZ99eO5fs79v6LsExFl5u5ajEkodPrmUv6F50sk=
Received: from [172.28.118.39] (bowill.kendall.corp.akamai.com [172.28.118.39]) by prod-mail-relay10.akamai.com (Postfix) with ESMTP id 8887A1FC86; Tue, 27 Dec 2016 19:27:32 +0000 (GMT)
From: Brandon Williams <brandon.williams@akamai.com>
To: "tram@ietf.org" <tram@ietf.org>, "draft-ietf-tram-stun-pmtud@tools.ietf.org" <draft-ietf-tram-stun-pmtud@tools.ietf.org>
Message-ID: <dfe9d46b-9fc4-22cd-b084-77c67e72ed9b@akamai.com>
Date: Tue, 27 Dec 2016 14:27:32 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/nkEElrfTGs9kkcMZlqiMLCp_7Zg>
Subject: [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: Tue, 27 Dec 2016 19:27:35 -0000
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]. 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]). 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, ... 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 ... 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. 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. 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. 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. 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. Regarding the FINGERPRINT attribute, why is it required? 4.1.2. Receiving a Probe Request Here again, why is the FINGERPRINT attribute required? 4.1.3. Receiving a Probe Response OLD: If the Probe transactions times out ... NEW: If the Probe transaction times out ... 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. Also, same question as above about FINGERPRINT here. This section should indicate the STUN method type used for a Report Request (prefered) or forward reference section 8.1. 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. 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. 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. 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. 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. 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.
- [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