Re: [tram] Publication has been requested for draft-ietf-tram-stun-pmtud-07

Gonzalo Camarillo <> Mon, 14 May 2018 11:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2ED2B12DA13 for <>; Mon, 14 May 2018 04:05:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Status: No, score=-4.311 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_MED=-2.3, SPF_PASS=-0.001, T_DKIMWL_WL_HIGH=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yjK42mSVDWii for <>; Mon, 14 May 2018 04:05:49 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B9E9812DA14 for <>; Mon, 14 May 2018 04:05:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256;; s=mailgw201801; c=relaxed/simple; q=dns/txt;; t=1526295946; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:CC:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=53WfdODGraLZ8+q7zU+iqj3ewI+wTTPRbSZG27+Dl0Y=; b=NLubmd/C/wpiPnBjKTE0IOqNZUktw4CaABWmMuNIl7iedw03h5Y3ghi3zuq8kiCZ eUOf5/VOLiE8HEcfS5ptyFrphofucAfU8fOHc/8BWKDiYeqEGqG3FwA+taS1U307 PsZ87RBItq4LUbOlSLtLSmgMqOaAVHdNyXG2Umd1rIM=;
X-AuditID: c1b4fb2d-a6b079c00000050d-8a-5af96d8a0d78
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id A7.E4.01293.A8D69FA5; Mon, 14 May 2018 13:05:46 +0200 (CEST)
Received: from [] ( by ( with Microsoft SMTP Server id 14.3.382.0; Mon, 14 May 2018 13:04:43 +0200
To: Spencer Dawkins at IETF <>,
CC:,, Tolga Asveren <>
References: <> <>
From: Gonzalo Camarillo <>
Message-ID: <>
Date: Mon, 14 May 2018 13:04:43 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrHLMWRmVeSWpSXmKPExsUyM2K7mW5X7s8ogwkrJC0Oz1OwWDZlD7PF +uXf2C2W/1zJZvFh7QU2B1aPnbPusnssWfKTyWPPnEmMAcxRXDYpqTmZZalF+nYJXBnr5y1k Lmgyq5jW9Z2xgXGFdhcjJ4eEgInEuZ4Opi5GLg4hgSOMEh9XvWSEcFYzSvxccRrI4eAQFgiT +HmwFqRBRCBFYsqqW0wgNrOAn8Ty/UehmqcwSpw/1cIOkmATsJDYcus+C4jNK2AvsfrdZ0YQ m0VAVeLJzx5WEFtUIEbix9EuqBpBiZMzn4DZnAKBEn/27GAD2cssoCmxfpc+xC5xiVtP5kPt lZdo3jqbGcQWEtCWWP6shWUCo+AsJJNmIXTPQtI9C0n3AkaWVYyixanFxbnpRsZ6qUWZycXF +Xl6eaklmxiBoX5wy2/dHYyrXzseYhTgYFTi4T0f/jNKiDWxrLgy9xCjBAezkgjvbiOgEG9K YmVValF+fFFpTmrxIUZpDhYlcV69VXuihATSE0tSs1NTC1KLYLJMHJxSDYy953qLF69ZxNWf +v/DzvOmrx99jrWKUKrY+PDx453RYnfWn+K+tFurP7bjhrfb2iPRh86/u+06IWeCmwiHb1Zj aZ+I2fGmX+qN0tX8Omefe3Iz/Hm9VJBl+hzN8qK1v3Mnrp25aJLF6YPaqssNyjLZrHsTt+me FOoMWr1qlmlRdzv3lXNxVpuUWIozEg21mIuKEwHY/zc+cQIAAA==
Archived-At: <>
Subject: Re: [tram] Publication has been requested for draft-ietf-tram-stun-pmtud-07
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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 May 2018 11:05:51 -0000


could you please look at Spencer's AD review below and address his
comments? Thanks!



On 09/05/2018 5:31 AM, Spencer Dawkins at IETF wrote:
> Dear Authors,
> On Fri, Apr 20, 2018 at 4:32 AM, Gonzalo Camarillo
> < <>>
> wrote:
>     Gonzalo Camarillo has requested publication of
>     draft-ietf-tram-stun-pmtud-07 as Proposed Standard on behalf of the
>     TRAM working group.
>     Please verify the document's state at
>     <>
> This document was fairly clear to me. I did have some questions I'd like
> to work through before requesting Last Call, but none of them are
> showstoppers - they shouldn't even slow the show down much.
> Thanks,
> Spencer
> I've been wrong before, but I'm thinking that 
>   Not all UDP-based protocols implement the Path MTU discovery
>    mechanism described in [RFC4821]. 
> is an understatement - I'm thinking of several widely used UDP-based
> protocols that try to use heuristics including just pick a low MTU size,
> or switch to TCP transport, or some other workaround. This statement
> seems to say that most UDP-based protocols do RFC 4821. Is it fair to
> say that many UDP-based protocols don't do RFC 4821 PMTU discovery?
> For this section,
> 3.  Terminology
>    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
>    document are to be interpreted as described in [RFC2119].  When these
>    words are not in ALL CAPS (such as "must" or "Must"), they have their
>    usual English meanings, and are not to be interpreted as RFC 2119 key
>    words.
> you might consider replacing it with the corresponding paragraph in
> - I'm seeing an increasing number of
> comments on IESG ballots suggesting this, and it's likely that the new
> BCP text will more familiar to most readers over time.
> This may be a dumb question, but in this text, 
>    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.
> does this mean "Server implementations" and "Client implementations"? 
> I'm a bit confused about this text:
>    Some application layer 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.  While there are other possible packet identification
>    schemes, this document describes two different ways to identify a
>    specific packet.
>    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.
>    In the second packet identification mechanism, the client prepends
>    the UDP data with a header that provides a sequence number.  The
>    server sends back the chronologically ordered list of sequence
>    numbers received that the client then compares with its own list.
> It wasn't clear to me from this text whether these two packet
> identification mechanism are descriptions of what applications do if
> they DON'T already have a way of identifying packets. If that's what's
> intended, perhaps
>   Some application layer 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.  While there are other possible packet identification
>    schemes, this document describes two different ways to identify a
>    specific packet, when no application layer protocol-specific
> identification
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    mechanism is available. 
>    ^^^^^^^^^^^^^^^^^^^^^^
> ?
> When I read this text,
>   Then the client waits half the RTO, if it is known, or 250 ms after
>    sending the last Probe Indication and then sends the Report Request
>    to the server over UDP.
> I was confused - isn't there's a 500-ms default RTO value in 4.1.1? Is
> this different from 
>   Then the client waits half the RTO after
>    sending the last Probe Indication and then sends the Report Request
>    to the server over UDP.
> or am I missing your point?
> In this text, 
>   The algorithm used to calculate the checksum is similar to the
>    algorithm used for the FINGERPRINT attribute (i.e., the CRC-32 of the
>    payload XOR'ed with the 32-bit value 0x5354554e).
> is there a reference you could provide for the "algorithm used for the
> FINGERPRINT attribute" here? I'm pretty sure I could find the right one,
> but googling for "STUN FINGERPRINT checksum" is a lot less helpful than
> I expected, and making sure that you understand what something is
> "similar to" seems important if that's going to be helpful information
> for implementers.
> If using authentication in 
>   UDP-based protocols that want to use any of these mechanisms,
>    including the PMTUD-SUPPORTED attribute, to signal PMTUD capabilities
>    MUST ensure that it cannot be used to launch an amplification attack.
>    For example, using authentication can ensure this.
> is only one way to ensure prevention of amplification attacks, is there
> any guidance or reference you could point to that would help
> implementers evaluate other approaches? 
> Actually, after reading 
>   The Probe Request or Indication that are used to implicitly signal
>    probing support in the reverse direction MUST be authenticated to
>    prevent amplification attacks.
> I wonder why authentication isn't a MUST for UDP-based protocols using
> STUN-PMTUD, but that's just me wondering ...
> I was a bit confused by 
>   This specification defines two new STUN methods and two new STUN
>    attributes.  IANA added these new protocol elements to the "STUN
>    Parameters Registry" created by [RFC5389].
> because they haven't been added to the registry yet, right?