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

Adam Roach <> Wed, 25 September 2019 00:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1ACC312084D; Tue, 24 Sep 2019 17:07:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.28
X-Spam-Status: No, score=-1.28 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, KHOP_HELO_FCRDNS=0.399, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=no autolearn_force=no
Authentication-Results: (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)"
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id C3yaqCiqTy-M; Tue, 24 Sep 2019 17:07:05 -0700 (PDT)
Received: from ( [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 6A3B012084B; Tue, 24 Sep 2019 17:07:05 -0700 (PDT)
Received: from Svantevit.local ( []) (authenticated bits=0) by (8.15.2/8.15.2) with ESMTPSA id x8P06xYC089774 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 24 Sep 2019 19:07:01 -0500 (CDT) (envelope-from
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=default; t=1569370022; bh=wfNrZqaWO93IEarjqDaxxy2/fl0zENvrTlBcV2UbzRA=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=u9fAuD+bs7e3mzXyLSQwn58MpLzGMuWimKqMBaGo5df86Pswdf301zV27jJSCBpJx kj7yltqtxKFP/Uk4hL/3yb6MoVH1NQTSCw/b+07xy3B9oqdUS2Wi0dcIMRKGJosg/j g5lS80DMsau77ADccy8INogiHymm4vYosOObTIZI=
X-Authentication-Warning: Host [] claimed to be Svantevit.local
To: "Felipe Garrido (fegarrid)" <>
Cc: "" <>, "" <>, "" <>, "" <>, "" <>
References: <> <> <>
From: Adam Roach <>
Message-ID: <>
Date: Tue, 24 Sep 2019 19:06:53 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------7EEA01F1D5358954BA79CC70"
Content-Language: en-US
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: Wed, 25 Sep 2019 00:07:07 -0000

On 9/10/19 6:01 PM, Felipe Garrido (fegarrid) wrote:
> Hi Adam,
> Please see responses, labeled with an [FG], inline with DISCUSS and 
> COMMENTS. We’ve published a new version (-13) with the proposed changes.

Thanks. Responses inline.

> [FG] We went through the different options available to handle the 
> Standards Track vs Experimental debate and following guidance offered 
> by Ben Campbell, we’ve decided to pull the padding attribute 
> definition into the document and remove the references to RFC5780 in 
> the latest draft.

This seems fine to me.

> ----------------------------------------------------------------------
> ----------------------------------------------------------------------
> 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.
> ---------------------------------------------------------------------------
> [FG]: I’m not sure I understand completely the point you’re trying to 
> make but this draft does not propose a new protocol and therefore the 
> TURN server does not need to be aware. The data will be tunneled 
> within the STUN data stream. If I’m missing your point then please 
> clarify.

It's not that this draft proposes a new protocol; it's the implications 
of the passage that I quote above.

Perhaps I'm misreading it. But what I see is a (SHOULD-strength) 
requirement that Report Response identifiers need to be set to the same 
identifiers used by the application that is being tunneled through TURN 
to identify their own packets.

Minimally, this is a layer violation.

It also implies that the TURN implementation, to meet this 
SHOULD-strength requirement, has to (a) somehow detect which protocol is 
being tunneled, (b) parse out the protocol being tunneled, and (c) 
understand its semantics well enough to extract a protocol-level packet 
identifier. Right? That seems fragile, subject to false positives, and 
computationally expensive. And the reason for doing so seems completely 
unmotivated by this document.

Again, I might be confused here; but, if that's the case, it's pretty 
likely that someone else will be similarly confused by this text. Please 
help me understand why this requirement exists, and explain what 
implications it has for TURN servers.