Re: [tram] Review of draft-ietf-tram-stun-pmtud-03
Brandon Williams <brandon.williams@akamai.com> Mon, 20 February 2017 22:59 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 B03E112940A for <tram@ietfa.amsl.com>; Mon, 20 Feb 2017 14:59:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.702
X-Spam-Level:
X-Spam-Status: No, score=-2.702 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=-0.001, 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 rThfNbcBJhN4 for <tram@ietfa.amsl.com>; Mon, 20 Feb 2017 14:59:26 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (prod-mail-xrelay07.akamai.com [23.79.238.175]) by ietfa.amsl.com (Postfix) with ESMTP id BC653129415 for <tram@ietf.org>; Mon, 20 Feb 2017 14:59:25 -0800 (PST)
Received: from prod-mail-xrelay07.akamai.com (localhost.localdomain [127.0.0.1]) by postfix.imss70 (Postfix) with ESMTP id 0E0BC433404; Mon, 20 Feb 2017 22:59:25 +0000 (GMT)
Received: from prod-mail-relay11.akamai.com (prod-mail-relay11.akamai.com [172.27.118.250]) by prod-mail-xrelay07.akamai.com (Postfix) with ESMTP id EB164433403; Mon, 20 Feb 2017 22:59:24 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; s=a1; t=1487631564; bh=tImD3ydFz93wecwuz5/WMnQTrrqgG0z9X2ErCs2+nL4=; l=14169; h=To:References:Cc:From:Date:In-Reply-To:From; b=CXBLvkE4FGGNbklSZZCitwIbxOoJkI0gh/9Wx82wDKs14ki0hWiUv2P9E1kKPLEJR y94tCBAo4hon0Qx1riIKIQgFD9i+AWHbhbqI1eGwrbvNwUTghvwzMtSTBOjZwrfJaS SnzApzOqw9MiFqCFJA+PHkS9E9oMinDeJed+9RvU=
Received: from [172.28.118.196] (bowill.kendall.corp.akamai.com [172.28.118.196]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id E43011FC88; Mon, 20 Feb 2017 22:59:24 +0000 (GMT)
To: "Gonzalo Salgueiro (gsalguei)" <gsalguei@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> <8E88169F-1BF3-4B31-872B-F12C4CFB7A9A@cisco.com>
From: Brandon Williams <brandon.williams@akamai.com>
Message-ID: <81b2148e-7afc-3325-4cab-3d7eefc35e4a@akamai.com>
Date: Mon, 20 Feb 2017 17:59:24 -0500
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <8E88169F-1BF3-4B31-872B-F12C4CFB7A9A@cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/3A-IhHzap6J5s6t2o5X6YhEseLE>
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 22:59:29 -0000
Looks good to me. --Brandon On 02/20/2017 02:17 PM, Gonzalo Salgueiro (gsalguei) wrote: > 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 >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_tram&d=DwMGaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=bwZ-nnRGWmcGKRIuadq6-NSnsgwbBVUJa4mZfmEIBXg&m=119_atpYkoATgcaHTtCqVlTio6bj6SnMszldKzR78W4&s=LfZktBcJfpC7O9e21qX1vopnfrr_5MJVbDd2qRo9wfE&e=> > -- Brandon Williams; Chief Architect Cloud Networking; Akamai Technologies Inc.
- [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