Re: [tram] Adam Roach's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS and COMMENT)

Spencer Dawkins at IETF <> Mon, 19 November 2018 20:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 722A3128BCC; Mon, 19 Nov 2018 12:57:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PYSyM0XQg9n0; Mon, 19 Nov 2018 12:56:59 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 783AD130DD7; Mon, 19 Nov 2018 12:56:55 -0800 (PST)
Received: by with SMTP id v15-v6so27352355ljh.13; Mon, 19 Nov 2018 12:56:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LJgcTbn3IqYg/Yt4tumeue6eI5qXYXHOLxUT8LvzoFA=; b=TzX41q2BYWEpfYRuM5lFQdLzAxKrT7Y2bzdq8h/jF+xNg8HeK6WzICX5x5WzAgvq5I Ndu6p4UQ7vhz9OSy4J8RYAqCxbaXvTjz+9Ajtad767qkxW2p9+xp9nBmX9ZmBXJMXUnW TkJKOiLR79XeKtr1xUQcbQxwZlz8Gf//GsUqyY5hCK40xVa7xrtw6nRSj6vJgFGNWrod 1uBUfcYyByzGCh8yQFl3cEq+SHd4pUMFpy9yM9Js9x3WHLpdjyIjgnPmP4bcIG9sfhsG uxRM2A+DkSetK8Bu0zmOpYzqR7DvdkFmaGLQfTFBR3Tn2PoldaSSFgmdoNVwa/VL9Bq3 dvHA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LJgcTbn3IqYg/Yt4tumeue6eI5qXYXHOLxUT8LvzoFA=; b=o5DO9+bQSJWsyt8NGN9b54pL6s3dygW7nUXED2oeTlLUAAgbh7Uh96sk1NpEYo1OvN SSNFKt7TZmNrPC6p/z8aLRoY2iGwWYtLCSciXT2fpl3OOrUYLOpCV//7snA9udP8LEqH PoDyvkC0EskmFcKmYvbS+Yy53hq0qxXNGFWXXIMSGNONdL+w0xWcIkaDlXfM5jrphuhR rwOTEFfex9zKPsQCEu7xcECp1CWnvdlvr4nTN1kEJfmVFILj5+cdNE3ibeM7vPw/nvOm GlooIL1h1QPzl9C0rIRQ0l5OPweocNL4bxIN6jijZ7JrQrJfnbfqiqzamvUlIa1O6sVG srJg==
X-Gm-Message-State: AGRZ1gJR1artoRpIDfwy5vgdFAdTeQo6uOA4mazMg27Sjku5d2OnRiKn x3DoONi02cudsq4BpmEoDlS994EeCaSw6pKbwOwy2g==
X-Google-Smtp-Source: AJdET5fL2dGQXJRVODG3jiaRC26J05VLDP3Kb3/TLIkA44ZPu851h16iuz9EuS4AzSp7+CIZVhQjy7P67eepCivG3wU=
X-Received: by 2002:a2e:197:: with SMTP id f23-v6mr12546541lji.144.1542661012997; Mon, 19 Nov 2018 12:56:52 -0800 (PST)
MIME-Version: 1.0
References: <>
In-Reply-To: <>
From: Spencer Dawkins at IETF <>
Date: Mon, 19 Nov 2018 14:56:40 -0600
Message-ID: <>
To: Adam Roach <>
Cc: IESG <>,,, Gonzalo Camarillo <>, "Asveren, Tolga" <>,
Content-Type: multipart/alternative; boundary="000000000000b04c0d057b0ac11d"
Archived-At: <>
Subject: Re: [tram] Adam Roach's Discuss on draft-ietf-tram-stun-pmtud-10: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.29
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, 19 Nov 2018 20:57:02 -0000

So, having been nudged on this one ...

On Sun, Sep 30, 2018 at 4:19 PM Adam Roach <> wrote:

> Adam Roach has entered the following ballot position for
> draft-ietf-tram-stun-pmtud-10: Discuss
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> Please refer to
> for more information about IESG DISCUSS and COMMENT positions.
> The document, along with other ballot positions, can be found here:
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> This seems like an interesting technique that warrants collection of
> operational
> experience.
> >From a process perspective, I think we have a bit of an issue, unless I've
> overlooked something relevant. This is proposed as a Standards-Track
> document,
> but it relies on the use of the PADDING attribute defined in RFC 5780. RFC
> 5780 is Experimental, so this is a formal downref. And RFC 5780 does not
> appear in the downref registry [1], nor did the IETF last call [2] include
> a
> request that the IETF community consider allowing such a refernce.
> >From a practical perspective, the mechanism described in this document
> seems
> like the kind of thing that it would be useful to gather operational
> experience
> with prior to putting it on the standards track. I have some operational
> concerns (described below) that I think could be either proven out or
> dispelled
> by experimental deployment of the technology.
> My recommendation is to recategorize this mechanism as experimental,
> adding some
> text about the desire to gather operational experience.
> For avoidance of doubt: My DISCUSS is only on the process issue, and I'll
> happily clear regardless of how this issue is rationalized (e.g., either by
> running IETF last call again, by reclassifying this mechanism as
> experimental,
> or perhaps some novel solution that I may not have thought of). Everything
> else is merely a recommendation.

I don't think I've seen a specific response to Adam's point here, which I
believe is that one of (at least) three things should happen -

- a second Last Call, explicitly calling out this downref, OR

- approval as an Experimental RFC, which makes the downref issue go away, OR

- (and this didn't happen in this thread, but in some conversation, I
remember that) Adam wondered if reusing the PADDING attribute was the right
thing to do (and that was a question, not a concern, but relevant here,
since if this document defined its own attribute, the downref would also go

Any thoughts on this?



> ____
> [1]
> [2]
> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> In the general case, STUN servers aren't aware of the signaling protocol
> that is
> in use. For example, when a TURN server is use with RTP and RTCP with a
> session
> set up via SIP, there is no requirement that the TURN server itself have
> any
> inherent knowledge of SIP or RTP or RTCP. From that perspective, the
> following
> text in section 4.2 is a bit confusing and/or problematic:
>    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.
> It seems odd that I would have to teach my TURN server about the protocols
> I'm
> using it with just so that it can identify the packets.
> This behavior, combined with the requirement that all behavior be
> symmetrical
> ("As a result of the fact that all endpoints implementing this
> specification
> are both clients and servers") leads me to believe that perhaps the use
> cases
> that drove this mechanism are tightly scoped to direct peer-to-peer uses
> of ICE,
> while the other common uses of STUN (e.g., public TURN servers used for
> symmetric NAT traversal) were given no consideration. If that was
> intentional,
> then I think the abstract and introduction need to clearly describe the
> scenarios the mechanism was defined for; and, more importantly, clarify
> that it
> does not work for the general case, including STUN servers used for NAT
> traversal.
> I suspect that, once this mechanism begins to be deployed, the foregoing
> limitations will cause operational difficulties, which may in turn suggest
> changes to the mechanism that is currently defined, hence my suggestion
> above
> to recharacterize the mechanism as experimental.
> ---------------------------------------------------------------------------
> §4:
> >  The Probing mechanism is used to discover the Path MTU in one
> >  direction only, from the client to the server.
> Nit: "...only: from..."
> >  Two Probing mechanisms are described, a Simple Probing mechanism and
> Nit: "...described: a Simple..."
> >  a more complete mechanism that can converge quicker and find an
> Nit: "...converge more quickly..."
> >  appropriate PMTU in the presence of congestion.  Additionally, the
> Nit: Please expand "PMTU" on first use.
> ---------------------------------------------------------------------------
> §4.2.5:
> >  algorithm used for the FINGERPRINT attribute (i.e., the CRC-32 of the
> >  payload XOR'ed with the 32-bit value 0x5354554e [ITU.V42.2002]).
> The location of the citation in here implies that the XOR'ing described is
> part
> of V.42. Given that 0x53545554E is ASCII for "STUN," I'm pretty sure
> that's not
> part of the underlying CRC. Would suggest reworking as:
>    algorithm used for the FINGERPRINT attribute (i.e., the CRC-32
>    calculated per the algorithm defined in [ITU.V42.2002], such has
>    subsequently been XOR'ed with 32-bit value 0x5354554e).