Re: [tram] Benjamin Kaduk's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT)

"Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com> Thu, 11 July 2019 15:47 UTC

Return-Path: <tirumaleswarreddy_konda@mcafee.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 B3D06120353 for <tram@ietfa.amsl.com>; Thu, 11 Jul 2019 08:47:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=mcafee.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 7Ukey14r4RO5 for <tram@ietfa.amsl.com>; Thu, 11 Jul 2019 08:47:32 -0700 (PDT)
Received: from us-smtp-delivery-210.mimecast.com (us-smtp-delivery-210.mimecast.com [216.205.24.210]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4ABEF120359 for <tram@ietf.org>; Thu, 11 Jul 2019 08:47:32 -0700 (PDT)
X-NAI-Header: Modified by McAfee Email Gateway (5500)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mcafee.com; s=s_mcafee; t=1562859410; h=From: To:CC:Subject:Thread-Topic:Thread-Index:Date: Message-ID:References:In-Reply-To:Accept-Language: Content-Language:X-MS-Has-Attach:X-MS-TNEF-Correlator: dlp-product:dlp-version:dlp-reaction:authentication-results: x-originating-ip:x-ms-publictraffictype:x-ms-office365-filtering-correlation-id: x-microsoft-antispam:x-ms-traffictypediagnostic: x-ms-exchange-purlcount:x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers:x-forefront-prvs: x-forefront-antispam-report:received-spf:x-ms-exchange-senderadcheck: x-microsoft-antispam-message-info:Content-Type: Content-Transfer-Encoding:MIME-Version:X-MS-Exchange-CrossTenant-Network-Message-Id: X-MS-Exchange-CrossTenant-originalarrivaltime: X-MS-Exchange-CrossTenant-fromentityheader: X-MS-Exchange-CrossTenant-id:X-MS-Exchange-CrossTenant-mailboxtype: X-MS-Exchange-CrossTenant-userprincipalname: X-MS-Exchange-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Level: X-NAI-Spam-Threshold:X-NAI-Spam-Score:X-NAI-Spam-Version; bh=7/BVi+53woHBZfwsI8ne/dcxXdqPdew+GMc5jc 58HEg=; b=or6vxD/Snxw5aCQYMpgJ0UQCZswgjDcgdLT3MZbd /gLywnFu+KEDQLN1U+9+EIUhux0szkamoNUGtnzy4fUfeSPFRv tJNZdZvi0ktA623l5s/d1npygYc1cKlLxMYUgL+Ororz/12K8X z0h7/WPye0hbqhYJwSVTFlZlSxqXKSo=
Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-15-tyYx_XQNOMGBx9NNw14NFQ-1; Thu, 11 Jul 2019 11:47:25 -0400
Received: from DNVEXAPP1N06.corpzone.internalzone.com (DNVEXAPP1N06.corpzone.internalzone.com [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp (TLS: TLSv1/SSLv3,256bits,ECDHE-RSA-AES256-SHA384) id 1e7f_4861_404f1205_0f7f_41ad_8c35_e9aa16d2c2d2; Thu, 11 Jul 2019 09:36:50 -0600
Received: from DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 11 Jul 2019 09:47:21 -0600
Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1395.4 via Frontend Transport; Thu, 11 Jul 2019 09:47:21 -0600
Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.44.176.240) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1395.4; Thu, 11 Jul 2019 09:47:18 -0600
Received: from DM5PR16MB1705.namprd16.prod.outlook.com (10.172.44.147) by DM5PR16MB1721.namprd16.prod.outlook.com (10.172.47.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2052.19; Thu, 11 Jul 2019 15:47:19 +0000
Received: from DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17]) by DM5PR16MB1705.namprd16.prod.outlook.com ([fe80::570:2208:75c2:5f17%8]) with mapi id 15.20.2052.019; Thu, 11 Jul 2019 15:47:19 +0000
From: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: "tram-chairs@ietf.org" <tram-chairs@ietf.org>, "draft-ietf-tram-turnbis@ietf.org" <draft-ietf-tram-turnbis@ietf.org>, "tram@ietf.org" <tram@ietf.org>, "brandon.williams@akamai.com" <brandon.williams@akamai.com>
Thread-Topic: [tram] Benjamin Kaduk's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT)
Thread-Index: AQHVN6sj5hqeZIdQXEa8/G2g6Mwv66bFIQEg
Date: Thu, 11 Jul 2019 15:47:19 +0000
Message-ID: <DM5PR16MB170591028C0B2CF13325137CEAF30@DM5PR16MB1705.namprd16.prod.outlook.com>
References: <156282359426.15056.17118634579091500165.idtracker@ietfa.amsl.com>
In-Reply-To: <156282359426.15056.17118634579091500165.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
dlp-product: dlpe-windows
dlp-version: 11.3.0.16
dlp-reaction: no-action
x-originating-ip: [49.37.206.28]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: cb6fdbfe-6a6a-4578-b476-08d706170e88
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(2017052603328)(7193020); SRVR:DM5PR16MB1721;
x-ms-traffictypediagnostic: DM5PR16MB1721:
x-ms-exchange-purlcount: 6
x-microsoft-antispam-prvs: <DM5PR16MB17214C7DFD99D59ADDC317D7EAF30@DM5PR16MB1721.namprd16.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:10000;
x-forefront-prvs: 0095BCF226
x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(4636009)(346002)(366004)(376002)(39860400002)(136003)(396003)(189003)(199004)(54094003)(51914003)(32952001)(52014003)(13464003)(76176011)(71200400001)(3846002)(71190400001)(80792005)(6506007)(478600001)(53546011)(2906002)(186003)(966005)(102836004)(6116002)(33656002)(26005)(4326008)(99286004)(486006)(74316002)(11346002)(229853002)(476003)(7696005)(446003)(6436002)(66476007)(66946007)(110136005)(66556008)(64756008)(66446008)(81166006)(66066001)(316002)(7736002)(81156014)(14444005)(256004)(86362001)(53946003)(14454004)(8676002)(52536014)(30864003)(53936002)(55016002)(6306002)(9686003)(2171002)(5660300002)(6246003)(76116006)(68736007)(8936002)(25786009)(54906003)(305945005)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1721; H:DM5PR16MB1705.namprd16.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: 4F23BtgDOsNmmDCE0ZMq4xcNzGF/EesE7/saY4ZlGBL7RnoX87IQ22JPfSmUUv9vJwd29pd4UzuHoxdxPYnJQX3bcXYFpgRf+v/qhDwkgSH2XHprDgdDpWfAXpVpMO9hQ6Mnz61v7VxMwLGbJlc2OZMGAFXVWBzgAkWstMamqUtBDROaFhwSuHstv8pLaO8XPH2LL+ULy9BileeOWbfLn1K8RowSQT3dqyKXy6A7pKVowR6nf+Pox+T0A8ddYlenSgAhseygB6f3QgYnq/dNo0z+zLv8XRKB1wHwyTJLMPque81Rdp3xc9Q3XYaQs6OS+q9vVv6Jk5azWO7jfBGih9nu5B9XuirvKftrrYl4aWViQjmM6PkEmlNZY+gbs+nv0R5OtxHXXqSTSvAL0w7PeBtz1Dcs+RhxCDrlpR85/ng=
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: cb6fdbfe-6a6a-4578-b476-08d706170e88
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jul 2019 15:47:19.2027 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: TirumaleswarReddy_Konda@McAfee.com
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1721
X-OriginatorOrg: mcafee.com
X-NAI-Spam-Flag: NO
X-NAI-Spam-Level:
X-NAI-Spam-Threshold: 15
X-NAI-Spam-Score: 0.3
X-NAI-Spam-Version: 2.3.0.9418 : core <6588> : inlines <7117> : streams <1827054> : uri <2866375>
X-MC-Unique: tyYx_XQNOMGBx9NNw14NFQ-1
X-Mimecast-Spam-Score: 0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/BnDowXNoX-r4X1OIaZN7BXkmV1I>
Subject: Re: [tram] Benjamin Kaduk's Discuss on draft-ietf-tram-turnbis-27: (with DISCUSS and COMMENT)
X-BeenThere: tram@ietf.org
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." <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: Thu, 11 Jul 2019 15:47:37 -0000

Hi Ben,

Thanks for the detailed review. Please see inline 

> -----Original Message-----
> From: tram <tram-bounces@ietf.org>; On Behalf Of Benjamin Kaduk via
> Datatracker
> Sent: Thursday, July 11, 2019 11:10 AM
> To: The IESG <iesg@ietf.org>;
> Cc: tram-chairs@ietf.org; draft-ietf-tram-turnbis@ietf.org; tram@ietf.org;
> brandon.williams@akamai.com
> Subject: [tram] Benjamin Kaduk's Discuss on draft-ietf-tram-turnbis-27: (with
> DISCUSS and COMMENT)
> 
> 
> 
> Benjamin Kaduk has entered the following ballot position for
> draft-ietf-tram-turnbis-27: 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 https://www.ietf.org/iesg/statement/discuss-criteria.html
> for more information about IESG DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/
> 
> 
> 
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
> 
> I support Roman's Discuss.

I have updated the draft to address Roman's Discuss. 

> 
> I think I'm confused about whether REQUESTED-ADDRESS-FAMILY and
> ADDITIONAL-ADDRESS-FAMILY are mutually exclusive.  

Yes, both attributes are mutually exclusive. It is discussed in Section 7.1, Clients MUST NOT include REQUESTED-ADDRESS-FAMILY and ADDITIONAL-ADDRESS-FAMILY attributes in the same request.

> Does sending just the
> "additional" one secretly mean that you want both v4 and v6?

Yes, ADDITIONAL-ADDRESS-FAMILY is used for allocation of both IPv4 and IPv6.

> 
> Section 5
> 
> I see that the secdir reviewer asked about why it is a "SHOULD" to send
> SOFTWARE, and only got a response that it is defined in stunbis, but not
> about why it is recommended.  There remain some privacy/security
> considerations with it, and we should either point to the stunbis security
> considerations or not recommend using it.  (FINGERPRINT is, IIRC, less
> interesting from a security perspective as it's just about confirming that given
> traffic is in fact STUN and not something else.)

This "SHOULD" to send SOFTWARE attribute is defined in RFC5766 (As you may know, TURN is used in the field for several years) and turnbis does not modify the behavior for backward compatibility, and to address the possible threat added the following lines:

SOFTWARE attribute can reveal the specific software version of the TURN client and server to eavesdropper and it might possibly allow attacks against vulnerable software that is known to contain security holes. If it is important to prevent an eavesdropper from learning the software version, TURN can be run over (D)TLS.

> 
> Section 12
> 
> Do we need to say anything about backwards compatibility with RFC 5766
> peers that use a wider range of channel IDs?

Yes, added the following line:
Note that the channel number range is not backwards compatible with
[RFC5766], and cannot be used in environments where such
compatibility is required.

> 
> Section 12.7
> 
>    When the server receives an ICMP packet, the server processes it as
>    described in Section 11.5.  A Data indication MUST be sent regardless
>    of whether there is a channel bound to the peer that was the
>    destination of the UDP datagram that triggered the reception of the
>    ICMP packet.
> 
> This MUST seems potentially in conflict with the previous discussion about
> permissions checks in Section 11.5.

Good catch, removed conflicting text from Section 12.7.

> 
> Section 20
> 
> Looking at the
> new nonce in the example ("obMatJos2AAABadl7W7PeDU4hKE72jda"), and
> noting that it starts with the nonce cookie, help me decode the security
> feature bits.  The magic prefix is "obMatJos2" so the capability bits are
> encoded as "AAAB", which decodes to (hex) 00 00 01.  But stunbis says that
> the bits are ordered from 0 (MSB of first byte) to 23 (LSB of last byte), so this
> would have bit 23 set, which is in contrast to the registry marking bit 0 as the
> password-algorithms feature.  Where am I messing this up?

You are right, replaced with "obMatJos2gAAAadl7W7PeDU4hKE72jda" (hex) 80 00 00

> 
> I'd prefer if the examples showed more usage of MESSAGE-INTEGRITY-
> SHA256 (especially, any from the server) and fewer MESSAGE-INTEGRITY.

Sure, updated examples. 

> 
> 
> ----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
> 
> Thanks for keeping the diff from RFC 5766 relatively contained!
> I only reviewed the diff due to time constraints, but in general support
> reviewing the full document for internal consistency and any remarks that
> have not aged well, especially with respect to IANA considerations.
> 
> Section 2
> 
> RFC 8174 has an updated version of the BCP 14 boilerplate text.

Fixed. 

> 
> Section 3.1
> 
> I appreciate the response to the secdir review, but even the linked stunbis
> section does not say much about which PKI's trust root is expected to be
> used.  I'm forced to assume the Web PKI but don't have much grounds for
> that assumption.

Yes, use pre-populated trust store on the endpoint to validate the certificate path. 

> 
> Section 3.2
> 
> The secdir reviewer's comments seem to have some relevance.
> It seems like even when the third-party authorization mechanism is used,
> the client is still limited to "the server is authenticated because it gives me
> the service I asked for", which is not really documented anywhere yet.  The
> long-term password mechanism at least generates an HMAC integrity tag on
> messages from server to client, which can provide some level of
> authentication via key confirmation.

No, STURN third-party authorization provides message integrity for both request and response messages (please see https://tools.ietf.org/html/rfc7635#section-5).  The mac_key to compute the message integrity can change per call and this mechanism is better than the long-term password mechanism. Note that WebRTC uses third-party authorization mechanism.

> 
> Section  3.7
> 
>                                        If the TURN server carrying out
>    packet translation from IPv4-to-IPv6 cannot get the Don't Fragment
>    (DF) bit in the IPv4 header, it MUST reject the Allocate request with
>    DONT-FRAGMENT attribute.
> 
> nit: does "cannot get" mean something like "read the value as sent on the
> wire" (e.g., due to implementation/API limitations)?

Yes, cannot read the value as sent on wire. 

> 
> Section 6
> 
>    o  the relayed transport address or addresses;
>    [...]
> 
>    [...]
>    address.  The relayed transport address MUST be unique across all
>    allocations, so it can be used to uniquely identify the allocation.
> 
> nit: there's maybe a singular/plural mismatch going on here, but I don't have
> any good ideas.
> 
> Section 7.1
> 
>    If the client wishes to obtain one IPv6 and one IPv4 relayed
>    transport address then it includes an ADDITIONAL-ADDRESS-FAMILY
>    attribute in the request.  This attribute specifies that the server
>    must allocate both address types.  The attribute value in the
>    ADDITIONAL-ADDRESS-FAMILY MUST be set to 0x02 (IPv6 address family).
>    Clients MUST NOT include REQUESTED-ADDRESS-FAMILY and ADDITIONAL-
>    ADDRESS-FAMILY attributes in the same request.  [...]
> 
> This reads like setting REQUESTED-ADDRESS-FAMILY and ADDITIONAL-
> ADDRESS-FAMILY are mutually exclusive.  Is that the correct reading?

Yes.

> (Naively, one might expect that the thing named "additional"
> is applied on top of the base-level request, so I have to ask.)
> 
> Section 7.2
> 
> Why do we only have a SHOULD-level requirement for authentication of
> Allocate requests where 5766 had MUST?  Could we say "may allow
> unauthenticated requests in order to support [use case] but otherwise
> MUST require authentication" (with better wording)?  I suppose this has
> probably been discussed ad nauseum already, so feel free to point me at the
> archives before getting into an actual discussion.

You missed the next line, it says the authentication of the request is optional to allow TURN
servers provided by the local or access network to accept
Allocation requests from new and/or guest users in the network
who do not necessarily possess long term credentials for STUN
authentication and its security implications are discussed in
[RFC8155].

The WG spent several cycles discussing the downgrade of a MUST level requirement (please see https://tools.ietf.org/html/rfc8155#section-9). 

> 
>    7.   If the server does not support the address family requested by
>         the client in REQUESTED-ADDRESS-FAMILY or is disabled by local
>         policy, it MUST generate an Allocate error response, and it MUST
>         include an ERROR-CODE attribute with the 440 (Address Family not
>         Supported) response code.  [...]
> 
> nit: "or is disabled" needs a subject.

Fixed, updated text as follows:
If the server does not support the address family requested by the client in REQUESTED-ADDRESS-FAMILY or if the allocation of the requested address family is disabled by local policy, it MUST generate an Allocate error response, and it MUST include an ERROR-CODE attribute with the 440 (Address Family not Supported) response code.
> 
>    9.   The server checks if the request contains an ADDITIONAL-ADDRESS-
>         FAMILY attribute.  If yes, and the attribute value is 0x01 (IPv4
>         address family), then the server rejects the request with a 400
>         (Bad Request) error.  Otherwise, the server checks if it can
>         allocate relayed transport addresses of both address types.  If
>         the server cannot satisfy the request, then the server rejects
> 
> What are "both" address types?  

Both IPv4 and IPv6 address families.

> We only have the ADDITIONAL-ADDRESS-
> FAMILY (which contains one type) and no REQUESTED-ADDRESS-FAMILY.

If ADDITIONAL-ADDRESS-FAMILY is used, the server will allocate both IPv4 and IPv6 relayed transport addresses. 

> 
> Section 8.1
> 
>    When refreshing a dual allocation, the client includes REQUESTED-
>    ADDRESS-FAMILY attribute indicating the address family type that
>    should be refreshed.  If no REQUESTED-ADDRESS-FAMILY is included then
>    the request should be treated as applying to all current allocations.
>    The client MUST only include family types it previously allocated and
>    has not yet deleted.  [...]
> 
> I'm a bit confused about "only include family types" plural; I thought there
> could only be at most one REQUESTED-ADDRESS-FAMILY and that it would
> only indicate one family type.  So how could  there be multiple types getting
> included by the client?

Good catch, replaced "types" with "type"

> 
> Section 11.5
> 
> [check that "type and code" is valid in both ICMPv4 and v6]

Yes, it is valid.

> 
> Section 12
> 
>    Reserved values may be used in the future by other protocols.  When
>    the client uses channel binding, it MUST comply with the
>    demultiplexing scheme discussed above.
> 
> "channel binding" is a term of art in the security world; is this usage intended
> to roughly mean "channel multiplexing"?
> (I do see that the subsections are talking about the specific ChannelBind
> request, so I assume so; I just want to double check.)

Yes,  a channel binding is created or refreshed using a ChannelBind transaction (Please see Section 12.1).

> 
> 
> Section 13
> 
>    The descriptions below have two parts: a preferred behavior and an
>    alternate behavior.  The server SHOULD implement the preferred
>    behavior.  Otherwise, the server MUST implement the alternate
>    behavior and MUST NOT do anything else for the reasons detailed in
>    [RFC7915].  [...]
> 
> RFC 5766 had this split on a per-field basis, but this text suggests that if the
> preferred behavior is not possible for a given field, then the alternate
> behavior is used for the entire packet.
> I note that section 14 does retain the "for a particular field" language for
> UDP-to-UDP relaying, as do section 15 for TCP-to-UDP relaying and section 16
> for UDP-to-TCP relaying.

Good point, fixed text as follows:
Otherwise, if that is not possible for a particular field, the server MUST implement the alternate behavior and MUST NOT do anything else for the reasons detailed in [RFC7915]. 

> 
> Section 13.2
> 
> Is this flow label text consistent with both the inbound and outbound
> translation directions (specifically, using relayed/peer addresses in the 5-
> tuple to identify the flow)?
> 
>       If the incoming packet did not include a Fragment header and the
>       outgoing packet size exceeds the outgoing link's MTU, the TURN
>       server drops the outgoing packet and send an ICMP message of type
>       2 code 0 ("Packet too big") to the sender of the incoming packet.
>        If the packet is being sent to the peer, the TURN server reduces
>       the MTU reported in the ICMP message by 48 bytes to allow room for
>       the overhead of a Data indication.
> 
> (nit?) "If the packet is being send to the peer" seems to grammatically refer
> to the outgoing packet that would exceed link MTU, as opposed to the ICMP
> message being generated.  But I think it's supposed to refer to the ICMP
> message being generated, which has not yet been referred to as a "packet"
> in this text.

Suresh raised the same comment, fixed text as follows:
If the ICMPv6 packet ("Packet too big") is being sent to the peer, the TURN server reduces the MTU reported in the ICMP message by 48 bytes to allow room for the overhead of a Data indication.

> 
> Section 13.3
> 
> [Same comment about ICMP packet generation/grammar]

Fixed text as follows:
If the ICMPv4 packet (Destination Unreachable (Type 3) with Code 4) is being sent to the peer, the TURN server SHOULD reduce the MTU reported in the ICMP message by 48 bytes to allow room for the overhead of a Data indication.

> 
> Section 15
> 
> Maybe note that SIP and WebRTC are the primary consumers of TURN?

Yes, it is mentioned in several places in the document that WebRTC and SIP use TURN.

> 
>                                                         Even if both
>    TCP-AO and UDP authentication would be used between TURN client and
>    server, it would not change the end-to-end security properties of the
>    UDP payload being relayed.  [...]
> 
> I wonder if we even need to say "UDP" in "payload being relayed".

Replaced "UDP" with "application"

> 
> Section 16
> 
>    Fragmentation
> 
>       Preferred Behavior: Any fragmented packets are reassembled in the
>       server and then forwarded to the client over the TCP connection.
>       ICMP messages resulting from the UDP datagrams sent to the peer
>       MUST be forwarded to the client using TURN's mechanism for
>       relevant ICMP types and codes.
> 
> As in section 12.7, I wonder if this MUST could be seen as overriding other
> logic for ICMP handling.

Modified text for clarity as follows:

ICMP messages resulting from the UDP datagrams sent to the peer
are processed by the server as described in Section 11.5 and
forwarded to the client using TURN's mechanism for relevant ICMP
types and codes.

> 
> Section 21.16
> 
> I agree with the secdir reviewer that there is at least potential for username
> and realm to be sensitive.

I proposed to add the following text:

   If the TURN client and server use the STUN Extension for Third-Party
   Authorization [RFC7635] (for example it is used in WebRTC), the
   username does not reveal the real user's identity, the USERNAME
   attribute carries an ephemeral and unique key identifier.  If the
   TURN client and server use the STUN long-term credential mechanism
   and the username reveals the real user's identity, the client needs
   to use (D)TLS transport between the client and the server or use the
   USERHASH attribute instead of the USERNAME attribute to anonynmize
   the username.

   If the TURN client and server use the STUN long-term credential
   mechanism and realm information is privacy sensitive, TURN can be run
   over (D)TLS.  As a reminder, STUN Extension for Third-Party
   Authorization does not use realm.

> 
> Section 21.4
> 
> Do we need references for Teredo and/or 6to4?

https://tools.ietf.org/html/rfc6156 did not add references to Teredo and 6to4.

> 
> Section 22
> 
>    The codepoints for the STUN error codes defined in this specification
>    are listed in Section 19.  [IANA is requested to update the reference
>    from [RFC5766] to RFC-to-be for the STUN error codes listed in
>    Section 19.]
> 
> (I think some of them are from RFC 6156 as well as from 5766.)

Yes, added RFC6156. 

> 
> Section 23
> 
> It seems prudent to revisit these listed IAB Considerations for whether the
> situation has changed in the past ten years (though I don't have any specific
> points that I would change).
> 
> Section 25
> 
> (nit) are these really "updates" to RFC 6156 so much as incorporating its
> content wholesale into the core TURN specification?

Yes, several sections in RFC6156 are updated.

Cheers,
-Tiru

> 
> 
> _______________________________________________
> tram mailing list
> tram@ietf.org
> https://www.ietf.org/mailman/listinfo/tram