From nobody Fri Nov 10 02:41:09 2017 Return-Path: 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 C1F30129432 for ; Fri, 10 Nov 2017 02:41:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.442 X-Spam-Level: X-Spam-Status: No, score=-0.442 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RDNS_NONE=0.793, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no 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 XASk468RXIqk for ; Fri, 10 Nov 2017 02:41:01 -0800 (PST) Received: from implementers.org (unknown [92.243.22.217]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D3FCA1292AE for ; Fri, 10 Nov 2017 02:41:00 -0800 (PST) Received: from [IPv6:2601:648:8301:730f:a059:8fe1:a606:88c] (unknown [IPv6:2601:648:8301:730f:a059:8fe1:a606:88c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id B94C6AE80A; Fri, 10 Nov 2017 11:40:58 +0100 (CET) To: "Asveren, Tolga" , "tram@ietf.org" References: From: Marc Petit-Huguenin Message-ID: <3a280b4c-f780-4f96-d47a-08ea764f514b@acm.org> Date: Fri, 10 Nov 2017 02:40:45 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="d2257nfj2EGXfxGCM30LUJHll6xJb9jRM" Archived-At: Subject: Re: [tram] WGLC comments for draft-ietf-tram-stunbis-12 X-BeenThere: tram@ietf.org 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: Fri, 10 Nov 2017 10:41:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --d2257nfj2EGXfxGCM30LUJHll6xJb9jRM Content-Type: multipart/mixed; boundary="mNm0oF1MhsW9KuhaBLbj5T6KPdpXcpHIn"; protected-headers="v1" From: Marc Petit-Huguenin To: "Asveren, Tolga" , "tram@ietf.org" Message-ID: <3a280b4c-f780-4f96-d47a-08ea764f514b@acm.org> Subject: Re: [tram] WGLC comments for draft-ietf-tram-stunbis-12 References: In-Reply-To: --mNm0oF1MhsW9KuhaBLbj5T6KPdpXcpHIn Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: quoted-printable Hi Tolga, Thanks for the review. My main concern about most of your comments is that they are not relevant= to -stunbis, but to RFC 5389, i.e. that they want to revisit text that w= as already approved by the IESG back when RFC 5389 was published. Now there is nothing wrong about this, as the purpose of stunbis was to r= evisit the parts of RFC 5389 that needed an update. But what you are ask= ing is expanding the scope of stunbis, which means another round of revie= ws for the Working Group. The WG activity is very low, so I would like f= irst to ask the WG if they want us to take on these modifications. I annotated the comments below with "New work" to signal when this is the= case. I'll publish a new version of stunbis as soon the submission tool= reopen. On 09/30/2017 05:31 AM, Asveren, Tolga wrote: > Here are my comments for draft-ietf-tram-stunbis-12 WGLC: > (It could be easier for tracking purposes if authors reply in separate = > threads/bundle relevant ones into separate threads) > i- Please reference latest version of [I-D.ietf-ice-rfc5245bis], and in= dicate=20 > that it should be updated by RFC Editor with the latest version/RFC num= ber (if=20 > present) before publication of this document Done. Note that this is an informative reference, so it is not blocking = the document. Also there is no place to signal that to the RFC Editor, b= y they know how to do that. > ii- > STUN is intended to be used in context of one or more NAT traversal > solutions. These solutions are known as STUN usages. Each usage > describes how STUN is utilized to achieve the NAT traversal solutio= n. > I think there are use cases for non-NAT environments as well, e.g. RFC5= 626=20 > keep-alive for flows without NAT to detect Edge Proxy crash. Maybe addi= ng a=20 > sentence along the following lines could be good: > =E2=80=9CSTUN may also be used for cases where a NAT is not present, e.= g., to detect=20 > crash of an Edge Proxy based on procedures defined in RFC5626 .=E2=80=9D New work. > iii- > Both types of transactions include a transaction ID, which > is a randomly selected 96-bit number. > It may be useful to provide some guidance how this could be made (close= to)=20 > globally unique? New work. > iv- > The server also uses > the transaction ID as a key to identify each transaction uniquely > across all clients. As such, the transaction ID MUST be uniformly > and randomly chosen from the interval 0 .. 2**96-1, and SHOULD be > cryptographically random. > There still is the possibility of a clash. What are the implications if= that=20 > happens? A short clarification could be useful. New work. > v- Structurally, it would be better to specify =E2=80=9Cbinding=E2=80=9D= as a =E2=80=9Cmethod=E2=80=9D in its=20 > own/separate section rather than in the sections pertaining to general = message=20 > processing. New work. > vi- > Absent other limits to > the rate of new transactions (such as those specified by ICE for > connectivity checks or when STUN is run over TCP), a client SHOULD > limit itself to ten outstanding transactions to the same server. > What is the justification for this? New work. > vii- > Alternatively, a > client MAY be configured with a set of domains or IP addresses that= > are trusted; if a certificate is received that identifies one of > those domains or IP addresses, the client considers the identity of= > the server to be verified. > Isn=E2=80=99t this already covered by following from RFC6125 (at least = the =E2=80=9Cdomain=E2=80=9D) > 1. The client constructs a list of acceptable reference identifiers > based on the source domain and, optionally, the type of service= > to which the client is connecting. > ... > As previously mentioned, this document specifies that > a URI-ID always contains a "host" component (or its equivalent) > containing a "reg-name". (Matching only the "reg-name" rule fro= m > [_URI_ ] limits verificatio= n to DNS=20 > domain names, thereby > differentiating a URI-ID from a uniformResourceIdentifier entry > that contains an IP address or a mere host name, or that does no= t > contain a "host" component at all.) > It seems only =E2=80=9CIP=E2=80=9D is excluded. What modification are you suggesting? > viii- > It checks that the first two > bits are 0, that the magic cookie field has the correct value, that= > the message length is sensible, and that the method value is a > supported method. > What does =E2=80=9Csensible=E2=80=9D mean in this context? New work. > ix- > If the success response contains unknown comprehension-required > attributes, the response is discarded and the transaction is > considered to have failed. > When would such a response be generated? New work. > x- > If the error code is 500 through 599, the client MAY resend the > request; clients that do so MUST limit the number of times they = do > this. > It may be useful to provide some guidance/recommended values? New work. > xi- > If the part contains an IP address, then this IP address is > used directly to contact the server. A "stuns" URI containing an I= P > address MUST be rejected, unless the domain name is provided by the= > same mechanism that provided the STUN URI, and that domain name can= > be passed to the verification code. > Isn=E2=80=99t this in conflict with the statement > Alternatively, a > client MAY be configured with a set of domains or IP addresses that= > are trusted; if a certificate is received that identifies one of > those domains or IP addresses, the client considers the identity of= > the server to be verified. The first sentence could state that it is only for "stun" URI. I modifie= d that. I do not think that there is a conflict. The former states that if the S= TUN URI was received from an HTTPS request, then the IP address can be tr= usted. The latter states that there can be a configured list of IP addre= sses that are trusted. Now I agree that for the former, the text is not very good. I fixed that= =2E > xii- Would it be useful to define a DHCP option for STUN Servers simila= r to SIP=20 > in RFC3361? New work. > xiii- > If the request was sent over an unreliable transport, the response > MUST be discarded, as if it was never received. This means that > retransmits, if applicable, will continue. If all the reponses > received are discarded then instead of signalling a timeout after > ending the transaction the layer MUST signal that an attack took > place. > Why signal attack only if all retransmissions are problematic? Shouldn=E2= =80=99t this=20 > happen even if only one is discarded? No, one packet can get discarded because of a transmission error that was= not detected by a checksum. If all were modified, then it is an attack.= > xiv- =E2=80=9CBasic Server=E2=80=9D, what does it really refer to? What= are alternatives? Was=20 > the goal here to describe behavior of a =E2=80=9CSTUN Binding Server=E2= =80=9D? If so, shouldn=E2=80=99t=20 > it be renamed as such rather than as =E2=80=9CBasic Server=E2=80=9D? Or= are there procedures=20 > which pertain to =E2=80=9CBasic Servers in general=E2=80=9D (again what= ever a Basic Server is)?=20 > Is defining behavior for a =E2=80=9Cbackward compatible server=E2=80=9D= the real goal here? New work. > xv- > 10. ALTERNATE-SERVER Mechanism > What is raison d=E2=80=99etre for defining such a mechanism? Is there a= n already known=20 > use case? New work. > xvi- > It SHOULD NOT > utilize the short-term or long-term credential mechanism. This is > because the work involved in authenticating the request is more tha= n > the work in simply processing it. It SHOULD NOT utilize the > ALTERNATE-SERVER mechanism for the same reason. > Isn=E2=80=99t backward compatibility the real reason for not using cred= entials and=20 > ALTERTNATE-SERVER? Otherwise there could be reasons other than processi= ng cost=20 > which could make them applicable, e.g. for credentials, not wanting to = serve=20 > illegitimate users, and for ALTERNATE-SERVER getting ready for an upgra= de. New work. > xvii- From idnits: > ** Downref: Normative reference to an Informational RFC: RFC 1321 Same than RFC 5389. > ** Downref: Normative reference to an Informational RFC: RFC 2104 Same than RFC 5389. > ** Obsolete normative reference: RFC 2460 Updated. > ** Obsolete normative reference: RFC 2617 (Obsoleted by RFC 7235, RF= C 7615, > RFC 7616, RFC 7617) Updated. > =3D=3D Outdated reference: A later version (-12) exists of > draft-ietf-ice-rfc5245bis-01 Updated. > -- Obsolete informational reference (is this intentional?): RFC 2616= > (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, R= FC 7235) Updated. > -- Obsolete informational reference (is this intentional?): RFC 3489= > (Obsoleted by RFC 5389) Intensional. > -- Obsolete informational reference (is this intentional?): RFC 5226= Updated. --=20 Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: https://marc.petit-huguenin.org Profile: https://www.linkedin.com/in/petithug --mNm0oF1MhsW9KuhaBLbj5T6KPdpXcpHIn-- --d2257nfj2EGXfxGCM30LUJHll6xJb9jRM Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEBSI+IuCHU8MsI1GjKcRFldZqfsQFAloFgi4ACgkQKcRFldZq fsQ6og//docQFFfYPbAiXPy1cmuORkw6swZfrIFr5cGCx4DNTK+ByIgPiQu18/3t QIAmmju36p1fHyjj2RvLJ6etVoVBrihdq2nohbQrlyvVxeoY120PnepDMS3ZuY0I DmflF51qTCoolDSafPQnpfYCuddQxWZelXEa49/wHUEiL4Hm5uzHcT2P4wg0btO/ V/3X43cwYbBS+m0GqdNgVgBZjdeE1hfTKGz7zEG/FK4GqrHfIdXuKL/kCA6lGCJa 1YkD5jZplKGfzE8XwPgZSyosq13STL+BX+ZFWqml7FkALZctNa7CtA5PADrLmY0e mA4d4OwX5R22bHmDedsSxQSMJ0M5QEUZmlZChPwlwNKi2EGvn2lyNNCrzB6yAsp2 uq0BzE/J8PY8UP3GcR2HqOBQL3yy8Nfzo1g3yW1g59m2BxoMhZltMlrMtu7LXNii nLUza9NWLYEfMK5LyZ3VQ4GQ8DUlHK14Kpx7cQPpUMXhy0YZ/x13y3AzNSmcfwuT OObD+94lGxay5zN/cwkeyp13LFHRcGskm0ZNJVF+YtoeG1QRZjvTwNr56w2RvSGg C96zKzX+TaUbeuDvysDSL7GedJTDieIGvGOYqTX8Im08oM99KiYsKXA8PZCpHCp6 uFYaz2iNNmr/ZSmyTNHgEU9OxqFJVFAX8M5HzzyBqvWzP7LcaxU= =qz++ -----END PGP SIGNATURE----- --d2257nfj2EGXfxGCM30LUJHll6xJb9jRM-- From nobody Sun Nov 12 10:04:26 2017 Return-Path: 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 83234126B6D; Sun, 12 Nov 2017 10:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 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, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-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 BFtoYic_LrV1; Sun, 12 Nov 2017 10:04:22 -0800 (PST) Received: from mx0a-00190b01.pphosted.com (mx0a-00190b01.pphosted.com [IPv6:2620:100:9001:583::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24F7912008A; Sun, 12 Nov 2017 10:04:21 -0800 (PST) Received: from pps.filterd (m0050095.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.21/8.16.0.21) with SMTP id vACI4KhY013984; Sun, 12 Nov 2017 18:04:20 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type; s=jan2016.eng; bh=gmKz54/DmjwTADytelM5MCpUPFGfTeataO7HvSNaUVE=; b=dUztZzKdoYsjlW67NLNuCZIK4thJdSG3W+zeEKOYekwLQwGN7WGGcf1l5o4iu0gccJ/n 1QJg4nRTVdsmbTmwQOhlguAx1zzDEb3INdnX9zm1BZB3NYzbDfSpLAk056tRYX7R77qy CUHe8JvjriIykUBhWlf6vD+DruajrhzkoPVUEtY8wtpAT4xLk5jRQD56BYPZgGbI/8n7 92n3qH9qtD68vTZXWnmiY/fRzoAKp8u6olBNbWjbNTi+/GLsRxH0jyX3hH8y6CFFZxAc gd4iawT7U+30cxg5S4VY6fxAf6gR/N4FM/T9KbHuylVp8fnWT0hPzF88oS6Qf+zc35gw jw== Received: from prod-mail-ppoint3 ([96.6.114.86]) by m0050095.ppops.net-00190b01. with ESMTP id 2e5sm6btjf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 12 Nov 2017 18:04:20 +0000 Received: from pps.filterd (prod-mail-ppoint3.akamai.com [127.0.0.1]) by prod-mail-ppoint3.akamai.com (8.16.0.21/8.16.0.21) with SMTP id vACI1oFx004860; Sun, 12 Nov 2017 13:04:19 -0500 Received: from prod-mail-relay15.akamai.com ([172.27.17.40]) by prod-mail-ppoint3.akamai.com with ESMTP id 2e5we0kdff-1; Sun, 12 Nov 2017 13:04:19 -0500 Received: from [172.28.118.80] (bowill.kendall.corp.akamai.com [172.28.118.80]) by prod-mail-relay15.akamai.com (Postfix) with ESMTP id A596920064; Sun, 12 Nov 2017 11:04:18 -0700 (MST) To: "Konda, Tirumaleswar Reddy" , "tram@ietf.org" Cc: "draft-ietf-tram-turnbis@ietf.org" References: <150874106330.24567.10025213746592540332@ietfa.amsl.com> From: Brandon Williams Message-ID: <61866009-27d0-bdce-815f-7905d69cd661@akamai.com> Date: Sun, 12 Nov 2017 13:03:47 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------1D23D7C2C80C1FED03C5C7CA" Content-Language: en-US X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-12_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711120257 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-11-12_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 impostorscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1711120257 Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-12.txt X-BeenThere: tram@ietf.org 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: Sun, 12 Nov 2017 18:04:25 -0000 This is a multi-part message in MIME format. --------------1D23D7C2C80C1FED03C5C7CA Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Hi Tiru, I just finished a comprehensive review of the cumulative diffs against RFC5766. See attached (let me know if you prefer me to resend as e-mail body for list purposes). You indicate that you addressed Marc's dual allocation related comments, but this draft doesn't address his comprehensive review comments, right? Please let me know a target for addressing the rest of his comments and mine so I can try to stay on top of the shepherding work for the draft. Thanks, --Brandon ________________________________________ From: Konda, Tirumaleswar Reddy Sent: Monday, October 23, 2017 2:48 AM To: tram@ietf.org Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-12.txt This revision addresses comments from Brandon and dual allocation related comments from Mark. -Tiru > -----Original Message----- > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > drafts@ietf.org > Sent: Monday, October 23, 2017 12:14 PM > To: i-d-announce@ietf.org > Cc: tram@ietf.org > Subject: [tram] I-D Action: draft-ietf-tram-turnbis-12.txt > > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the TURN Revised and Modernized WG of the > IETF. > > Title : Traversal Using Relays around NAT (TURN): Relay Extensions > to Session Traversal Utilities for NAT (STUN) > Authors : Tirumaleswar Reddy > Alan Johnston > Philip Matthews > Jonathan Rosenberg > Filename : draft-ietf-tram-turnbis-12.txt > Pages : 83 > Date : 2017-10-22 > > Abstract: > If a host is located behind a NAT, then in certain situations it can > be impossible for that host to communicate directly with other hosts > (peers). In these situations, it is necessary for the host to use > the services of an intermediate node that acts as a communication > relay. This specification defines a protocol, called TURN (Traversal > Using Relays around NAT), that allows the host to control the > operation of the relay and to exchange packets with its peers using > the relay. TURN differs from some other relay control protocols in > that it allows a client to communicate with multiple peers using a > single relay address. > > The TURN protocol was designed to be used as part of the ICE > (Interactive Connectivity Establishment) approach to NAT traversal, > though it also can be used without ICE. > > This document obsoletes [RFC5766] and [RFC6156]. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-tram-turnbis-12 > https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-12 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-12 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram _______________________________________________ tram mailing list tram@ietf.org https://www.ietf.org/mailman/listinfo/tram -- Brandon Williams; Chief Architect Cloud Networking; Akamai Technologies Inc. --------------1D23D7C2C80C1FED03C5C7CA Content-Type: text/plain; charset=UTF-8; name="turnbis-12_review.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="turnbis-12_review.txt" Header Indicates that it "Updates" 5766 and 6156 but states that it "Obsoletes" them in the abstract text. Should state "Obsoletes" in the header. Also, 6156 should be a link, but it is only text. Abstract NIT: Should not contain references. Should just provide textual mentions. This is for the references added to indicate the obsoleted RFCs. Those RFC mentions should not expand to clickable links in the HTML version. Status of This Memo idnits throws a warning about BCP78 and the earlier RFCs originally being published at a point before BCP78, suggesting that it might be necessary to get the authors to assign BCP78 rights. This seems confusing to me, because the RFCs in question have already given BCP78 rights. I'm not sure whether additional approvals are required here or not. Section 1 NIT: misplaced space "connecton to the Internet . As a consequence" Section 2.4 "Data indications containing the XOR-PEER-ADDRESS and ICMP attribute are also sent when using the channel mechanism." I had to read that a couple of times to get the point. I suggest: "ICMP attribute forwarding always uses Data indications containing the XOR-PEER-ADDRESS and ICMP attributes, even when using the channel mechanism to forward UDP data." Section 2.5 NIT: remove/replace brackets around [0x4001], since they confuse idnits, making it think that 0x4001 is a reference. Section 2.7 "that is using STUN to discover the PMTUD, and so may be a suitable approach to be used in conjunction with a TURN server, together with the DONT-FRAGMENT attribute." I had to read that a couple of times to get the point. I suggest: "that uses STUN to discover the path MTU, and so might be a suitable approach to be used in conjunction with a TURN server that supports the DONT-FRAGMENT attribute." Section 2.9 "the syntax of the "turn" and "turn" URIs" This should say "turn" and "turns" I think. Section 2.10 In the first bullet, for clarity, I suggest: "For TCP or TLS-over-TCP, ..." NIT: In the third bullet, it states "on both IP addresses families." I think you want "on both IP address families." This correction applies twice within the paragraph. Section 3 This is a carry over comment from RFC5766. The description of a Nonce says "To prevent reply attacks, ...". Shouldn't this be "replay attacks"? Section 4 In the paragraph that introduces ADDITIONAL-ADDRESS-FAMILY, it might be good to introduce the related restriction on use of the EVEN-PORT attribute and explain the reason for it. When this is mentioned in section 6.1, it's not clear why this restriction is there. Section 4 seems like the better place to explain to me, but it would be OK in section 6.1 instead. Section 5 The old text states: "Both the relayed transport address and the 5-tuple MUST be unique across all allocations, so either one can ...". The new text removes the reference to the 5-tuple in this sentence. I can't remember why this change was made. Would you remind me please. Also, if the 5-tuple is no longer expected to be a unique key, it would be good for this text to state what the unique key is (i.e. what is added to the 5-tuple to get uniqueness). NIT: "which is an secure hash" should be "which is a secure hash" Section 6.1 "The client uses the procedures described in [RFC8155] to discover a TURN server and TURN server resolution mechanism defined in [RFC5928] to get a list of server transport addresses ..." I had to read that a couple times to get the point. I suggest: "The client uses one of the procedures described in [RFC8155] to discover a TURN server and uses the TURN server resolution mechanism defined in [RFC5928] to get a list of server transport addresses ..." NIT: "If the client whishes to obtain one IPv6 and one IPv4 relayed transport addresses ...". That should be "address", not "addresses". Section 6.2 bullet #6 "The server checks if the request contains both REQUESTED-ADDRESS-FAMILY and ADDITIONAL-ADDRESS-FAMILY attributes, then the server rejects ..." Use of "then" here is incorrect. I suggest: "The server checks if the request contains both REQUESTED-ADDRESS-FAMILY and ADDITIONAL-ADDRESS-FAMILY attributes. If yes, then the server rejects ..." bullet #7 Are all TURN servers required to support IPv4 relayed transport addresses? If not, then this bullet should indicate that 440 MUST be returned if there is no REQUESTED-ADDRESS-FAMILY attribute and the server does not support IPv4. bullet #9 NIT: "Otherwise, and the server checks ...". This should be "Otherwise, the server checks ...". "If all the checks pass, the server creates either the single or dual allocation." I don't think it's necessary or help to indicate "either the single or dual allocation" here. I would just state "creates the allocation". Due to differences in expiration times, a dual allocation could become a single allocation later, so in my opinion it's a false distinction to refer to them as if they are different things. NIT: "... section 6.3.1 of [I-D.ietf-tram-stunbis] requires ...". I would not refer to specific section numbers in an external as-yet-unpublished draft, since it's always possible that this section number will change. I would just state that stunbis requires this. Section 6.3 The previous section, 6.2, allows for an ADDRESS-ERROR-CODE attribute in an allocate success response. This section, 6.3, does not describe how the client is expected to handle this attribute. Section 7.2 NIT: "... it processes it ...". I suggest instead "... it processes the request ..." to avoid use of the same pronoun to refer to two different things. NIT: " ... an REQUESTED-ADDRESS-FAMILY ...", should be "a", not "an". Section 9.1 NIT: I would use normative text in a couple places here. "... attributes MAY appear in any order." "... the client MAY include ..." Section 9.2 NIT: "... not the same as that of the relayed transport address ...". I would use "a relayed", not "the relayed", since there can be multiple. Section 10.4 and 10.6 A Data indication is required to contain either a DATA attribute or an ICMP attribute, right? There should be some text in the doc (probably section 10.4) that indicates this. I would remove "with DATA attribute" from the title of section 10.4 and move the last sentence of paragraph one into the following paragraph to be inserted after the NOTE. If the XOR-PEER-ADDRESS is present and valid, the client checks that the Data indication contains either a DATA attribute or an ICMP attribute and discards the indication if it does not. Note that a DATA attribute is allowed to contain zero bytes of data. Processing of Data indications with ICMP attributes is described in section 10.6 below. Section 11.1 NIT: "... as that of the relayed transport address ...". I would use "a relayed", not "the relayed", since there can be multiple. Section 11.2 NIT: "... not the same as that of the relayed transport address ...". I would use "a relayed", not "the relayed", since there can be multiple. Section 11.7 NIT: "... sent regardless if there is a channel bound ...". I suggest "... sent regardless of whether there is a channel bound ...". Section 12 The section from RFC6156 is more clear about what specifically is described in the section than this section. I suggest that you add this introductory paragraph to the section. The text is mostly carried over from RFC6156. This section addresses IPv4-to-IPv6, IPv6-to-IPv4, and IPv6-to-IPv6 translations. Requirements for translation of the IP addresses and port numbers of the packets are described above. The following sections specify how to translate other header fields. The RFC references in this section have changed, with the references from RFC6156 now having been obsoleted. Has this section undergone another expert review from someone in v6ops to verify that none of the rest of the text should be updated? I expect that the RFC6156 text still stands, but it might be worth verification. Section 12.1 NIT: A reference to RFC6437 does not expand to a clickable link. NIT: "the relay sets the Flow label ...". Fix case: "The relay sets ..." Section 12.2 NIT: A reference to RFC6437 does not expand to a clickable link. Section 12.3 NIT: Misplaced space. " Additionally, when the outgoing ..." Indentation of this line looks wrong. Section 15.6 The first sentence states "... the allocation of a specific address type ...". It should probably state "... the allocation or refresh of a specific address type ...". The following sections of text copied from RFC6156 are probably not necessary in this section about REQUESTED-ADDRESS-FAMILY, since they have already been covered at a general level elsewhere. Note that TURN attributes are TLV (Type-Length-Value) encoded, with a 16-bit type, a 16-bit length, and a variable-length value. As specified in [I-D.ietf-tram-stunbis], attributes with values between 0x0000 and 0x7FFF are comprehension-required, which means that the client or server cannot successfully process the message unless it understand the attribute. Considering that the other attributes in this section don't include the Type and Length parts of the attribute format, this one should probably not include them either, so removing them from both the diagram and the description makes sense. Instead, this section can simply state: The value is 4 bytes with the following format: This would be in line with what other such sectionsin the I-D do. The last sentence in this section looks wrong to me, and I don't think that such normative text is required in this section. I suggest that you remove that sentence. The REQUESTED-ADDRESS-TYPE attribute MAY only be present in Allocate requests. Section 15.12 This section also does not need to include Type and Length in either the diagram or the descriptions. Instead, it can simply state: The value portion of this attribute is variable length. The last sentence in this section does not appear necessary to me, and the normative text in its current form is confusing. I suggest removing it entirely. The ADDRESS-ERROR-CODE attribute MAY only be present in Allocate responses. Section 18.4 Please double-check the use of addresses in the example text to ensure that it complies with the IPv6 documentation address range. --------------1D23D7C2C80C1FED03C5C7CA-- From nobody Mon Nov 13 03:02:37 2017 Return-Path: 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 E389D129485; Mon, 13 Nov 2017 03:02:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) 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 eLdcaSPc4-eN; Mon, 13 Nov 2017 03:02:33 -0800 (PST) Received: from DNVWSMAILOUT1.mcafee.com (dnvwsmailout1.mcafee.com [161.69.31.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E7DD124BFA; Mon, 13 Nov 2017 03:02:32 -0800 (PST) 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=1510570952; 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: authentication-results:x-originating-ip:x-ms-publictraffictype: x-microsoft-exchange-diagnostics:x-ms-exchange-antispam-srfa-diagnostics: x-ms-office365-filtering-correlation-id:x-microsoft-antispam: x-ms-traffictypediagnostic:x-microsoft-antispam-prvs: x-exchange-antispam-report-test:x-exchange-antispam-report-cfa-test: x-forefront-prvs:x-forefront-antispam-report: received-spf:spamdiagnosticoutput:spamdiagnosticmetadata: 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-Transport-CrossTenantHeadersStamped: X-OriginatorOrg:X-NAI-Spam-Flag:X-NAI-Spam-Threshold: X-NAI-Spam-Score:X-NAI-Spam-Version; bh=U 8fAZDVLNoiWeJNkFd+XGSPfN2Z/Tc4mObZ1j9IvIf 0=; b=Lxd/mBkCK0FLvu5/ERndAaMex83A1RVVLj01HUIEBf1o nqyvqN6P2B8RIRikdMsL7R+OcbPpguelKPBP87568QmbtUsOmA vAT0T3ybdSEGWVnBgJ4Y/Sh4vElxD2vobiMO5IGSH73r0AR0lz UaSuCV/JIJ8O9Bw38ikEeL735gM= Received: from DNVEXAPP1N06.corpzone.internalzone.com (unknown [10.44.48.90]) by DNVWSMAILOUT1.mcafee.com with smtp id 284a_a269_0949f866_88ef_4e7b_a435_cec44213309e; Mon, 13 Nov 2017 05:02:31 -0600 Received: from DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) by DNVEXAPP1N06.corpzone.internalzone.com (10.44.48.90) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 13 Nov 2017 04:01:45 -0700 Received: from DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) by DNVEXUSR1N08.corpzone.internalzone.com (10.44.48.81) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 13 Nov 2017 04:01:43 -0700 Received: from DNVO365EDGE1.corpzone.internalzone.com (10.44.176.66) by DNVEXUSR1N12.corpzone.internalzone.com (10.44.48.85) with Microsoft SMTP Server (TLS) id 15.0.1347.2 via Frontend Transport; Mon, 13 Nov 2017 04:01:44 -0700 Received: from NAM03-BY2-obe.outbound.protection.outlook.com (10.44.176.241) by edge.mcafee.com (10.44.176.66) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 13 Nov 2017 04:01:43 -0700 Received: from DM5PR16MB1788.namprd16.prod.outlook.com (10.172.44.144) by DM5PR16MB1785.namprd16.prod.outlook.com (10.172.44.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.20.218.12; Mon, 13 Nov 2017 11:01:42 +0000 Received: from DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) by DM5PR16MB1788.namprd16.prod.outlook.com ([10.172.44.144]) with mapi id 15.20.0218.015; Mon, 13 Nov 2017 11:01:42 +0000 From: "Konda, Tirumaleswar Reddy" To: Brandon Williams , "tram@ietf.org" CC: "draft-ietf-tram-turnbis@ietf.org" Thread-Topic: [tram] I-D Action: draft-ietf-tram-turnbis-12.txt Thread-Index: AQHTS8p5n4macCipKkK5ItbjZD/9kqLw/jXwgCArYYCAARubMA== Date: Mon, 13 Nov 2017 11:01:42 +0000 Message-ID: References: <150874106330.24567.10025213746592540332@ietfa.amsl.com> <61866009-27d0-bdce-815f-7905d69cd661@akamai.com> In-Reply-To: <61866009-27d0-bdce-815f-7905d69cd661@akamai.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=TirumaleswarReddy_Konda@McAfee.com; x-originating-ip: [103.245.47.20] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR16MB1785; 6:sIx7NLkRriIalTJW0kVGo9bEhJ3HUfYk/07AfG527U6ze8ExuGHWy+Z7mztQKpJm6/hpPNK8npEL/UyfyuKLNZhuDqYmHMAO2jWZm4spN3+NoAQEaLH5rge5JWFIRgYBTtfJ13yP5pOUC4iiSZH4BGQb3mtkUnRsH6nBJgr4sbhl+XiPml6aexVYAOuBSqZLD70WZ7psUGIsk3dsX372X8MaiVQi5P6nkksNvPWICuasPqcCgLQmjnq4czZ7FUN9HWcUOoMGMtoyfL1aShgxSVmHvv4bOo+meziMh1xr5X2ppA+pa393W1XawR/tu14pIIarpa1vRbG7C2guVlY8jVwEJ8JZsZ9Khp1V57lG15I=; 5:tc39v4KVDFQ/b7Flwm3WyDQQtoDlYswQ2YQx10B3eeP2uuO+Cdpv+GBUwvfBFO9B3XCWCIjEBqdurDpsiCMld5U8KnBEXGKM5JlzELL1llqIklqMWOwggcmK0unDHL7l28rnyTNCkU2/bFniay1rdIEq1TfzKmHKNlFvmOYRbHY=; 24:bZLmxJEicIS2vJkmtR+mEVm1guhVkEal/ojWuI8JhRRCHRIi7GrZ8c94GZRYQD9xqdUnda5NjjsaiyYOpKCfnF5Jh7IQupkgXAZnev8sKPc=; 7:i6OLmqP4so4ONlzFDuoRAelEJoOSrL82CvE3+V7fm1KQQZcWHuMUg1GOxBKJaneKb/kgBhLlnSzoYfnba9WbZoyuooN3FklFQyaK+TFgsby7bdQbIqFmFS6EBINozqTG/N68nqlw/Vz21NPRlttZefbJzuyzarUx0njidTInzKC29xn644YZYeQTXlD24/idxVwGkW99dEei0/5Y70AsLyUlB8sMWIa0V0rzs5LOg/s/a6jIVVeIrOyveR+pycSt x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-correlation-id: bd25e2a0-ea60-487e-6e3d-08d52a85ec37 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(4534020)(4602075)(4627115)(201703031133081)(201702281549075)(2017052603199); SRVR:DM5PR16MB1785; x-ms-traffictypediagnostic: DM5PR16MB1785: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(120809045254105)(123452027830198); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(100000700101)(100105000095)(100000701101)(100105300095)(100000702101)(100105100095)(6040450)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231022)(100000703101)(100105400095)(3002001)(6041248)(20161123558100)(20161123560025)(201703131423075)(201702281528075)(201703061421075)(201703061406153)(20161123562025)(20161123564025)(20161123555025)(6072148)(201708071742011)(100000704101)(100105200095)(100000705101)(100105500095); SRVR:DM5PR16MB1785; BCL:0; PCL:0; RULEID:(100000800101)(100110000095)(100000801101)(100110300095)(100000802101)(100110100095)(100000803101)(100110400095)(100000804101)(100110200095)(100000805101)(100110500095); SRVR:DM5PR16MB1785; x-forefront-prvs: 0490BBA1F0 x-forefront-antispam-report: SFV:NSPM; SFS:(10009020)(6009001)(39860400002)(376002)(346002)(377424004)(199003)(13464003)(51914003)(189002)(32952001)(80792005)(50986999)(54356999)(316002)(76176999)(53546010)(110136005)(101416001)(81166006)(81156014)(8676002)(6436002)(14454004)(7736002)(6506006)(305945005)(8936002)(2501003)(2906002)(189998001)(5890100001)(74316002)(55016002)(2900100001)(53936002)(4326008)(4001150100001)(68736007)(106356001)(99286004)(6116002)(3846002)(105586002)(25786009)(97736004)(6246003)(66066001)(229853002)(966005)(7696004)(33656002)(72206003)(77096006)(3280700002)(230783001)(5660300001)(6306002)(86362001)(3660700001)(9686003)(102836003)(478600001)(2950100002)(85282002); DIR:OUT; SFP:1101; SCL:1; SRVR:DM5PR16MB1785; H:DM5PR16MB1788.namprd16.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: McAfee.com does not designate permitted sender hosts) spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: bd25e2a0-ea60-487e-6e3d-08d52a85ec37 X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Nov 2017 11:01:42.3615 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4943e38c-6dd4-428c-886d-24932bc2d5de X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR16MB1785 X-OriginatorOrg: mcafee.com X-NAI-Spam-Flag: NO X-NAI-Spam-Threshold: 15 X-NAI-Spam-Score: 0 X-NAI-Spam-Version: 2.3.0.9418 : core <6157> : inlines <6171> : streams <1770160> : uri <2533142> Archived-At: Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-12.txt X-BeenThere: tram@ietf.org 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, 13 Nov 2017 11:02:35 -0000 > -----Original Message----- > From: Brandon Williams [mailto:brandon.williams@akamai.com] > Sent: Sunday, November 12, 2017 11:34 PM > To: Konda, Tirumaleswar Reddy ; > tram@ietf.org > Cc: draft-ietf-tram-turnbis@ietf.org > Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-12.txt >=20 > Hi Tiru, >=20 > I just finished a comprehensive review of the cumulative diffs against > RFC5766. See attached (let me know if you prefer me to resend as e-mail > body for list purposes). >=20 > You indicate that you addressed Marc's dual allocation related comments, > but this draft doesn't address his comprehensive review comments, right? >=20 > Please let me know a target for addressing the rest of his comments and > mine so I can try to stay on top of the shepherding work for the draft. Thanks for the review. I will try to address Marc's and your comments in th= e next 3 weeks. Cheers, -Tiru >=20 > Thanks, > --Brandon > ________________________________________ > From: Konda, Tirumaleswar Reddy > > Sent: Monday, October 23, 2017 2:48 AM > To: tram@ietf.org > Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-12.txt >=20 > This revision addresses comments from Brandon and dual allocation related > comments from Mark. >=20 > -Tiru >=20 > > -----Original Message----- > > From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- > > drafts@ietf.org > > Sent: Monday, October 23, 2017 12:14 PM > > To: i-d-announce@ietf.org > > Cc: tram@ietf.org > > Subject: [tram] I-D Action: draft-ietf-tram-turnbis-12.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > This draft is a work item of the TURN Revised and Modernized WG of the > > IETF. > > > > Title : Traversal Using Relays around NAT (TURN): Rel= ay > Extensions > > to Session Traversal Utilities for NAT (STUN) > > Authors : Tirumaleswar Reddy > > Alan Johnston > > Philip Matthews > > Jonathan Rosenberg > > Filename : draft-ietf-tram-turnbis-12.txt > > Pages : 83 > > Date : 2017-10-22 > > > > Abstract: > > If a host is located behind a NAT, then in certain situations it can > > be impossible for that host to communicate directly with other hosts > > (peers). In these situations, it is necessary for the host to use > > the services of an intermediate node that acts as a communication > > relay. This specification defines a protocol, called TURN (Traversa= l > > Using Relays around NAT), that allows the host to control the > > operation of the relay and to exchange packets with its peers using > > the relay. TURN differs from some other relay control protocols in > > that it allows a client to communicate with multiple peers using a > > single relay address. > > > > The TURN protocol was designed to be used as part of the ICE > > (Interactive Connectivity Establishment) approach to NAT traversal, > > though it also can be used without ICE. > > > > This document obsoletes [RFC5766] and [RFC6156]. > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-ietf-tram-turnbis/ > > > > There are also htmlized versions available at: > > https://tools.ietf.org/html/draft-ietf-tram-turnbis-12 > > https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-12 > > > > A diff from the previous version is available at: > > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-tram-turnbis-12 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at tools.i= etf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > tram mailing list > > tram@ietf.org > > https://www.ietf.org/mailman/listinfo/tram >=20 > _______________________________________________ > tram mailing list > tram@ietf.org > https://www.ietf.org/mailman/listinfo/tram >=20 >=20 > -- > Brandon Williams; Chief Architect > Cloud Networking; Akamai Technologies Inc. From kevin@retxt.com Thu Nov 30 08:30:27 2017 Return-Path: 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 2EA721200FC for ; Thu, 30 Nov 2017 08:30:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=retxt-com.20150623.gappssmtp.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 x_XyV60JUnlm for ; Thu, 30 Nov 2017 08:30:25 -0800 (PST) Received: from mail-pg0-x231.google.com (mail-pg0-x231.google.com [IPv6:2607:f8b0:400e:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 47CD2128B93 for ; Thu, 30 Nov 2017 08:30:25 -0800 (PST) Received: by mail-pg0-x231.google.com with SMTP id o2so3192557pgc.8 for ; Thu, 30 Nov 2017 08:30:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=retxt-com.20150623.gappssmtp.com; s=20150623; h=from:content-transfer-encoding:mime-version:subject:message-id:date :to; bh=9KOf4taUAYpzQ9G/+p25hX1E+Jl3aGi4KsZ+ceiAKCc=; b=ZActsKvUJVb+WuAXf1Ek2DW0DF9ptG3RiACM1dAIn8UDCedbUfXb9Yq86Wu7zmQqKw hgV3rUMY+7r8spqKXuF5klw4aH3wF64ijg45s/7O+jvRjIA7pPuUvVnBAanFS1JAJv4R 3CCM2hCj1acx/HYu+YrIc3fxGJhfECkNK15b9FdEptu8QU5KlitAVDY8I94SFmLs6xDZ PBawyrGdZ87vFpnucPpYU8ALzC691EVTEUpG8HkuBtain3rlWyZIKMPUC5E4kSoU0V5q VdnH9Qse5qs/34LbI0iVQm5K92IUDPwyf6rNPRdan2sCX9ud9ngFL4dbO51S4y+dVJ8r kCyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:message-id:date:to; bh=9KOf4taUAYpzQ9G/+p25hX1E+Jl3aGi4KsZ+ceiAKCc=; b=lP9j0CCDktnBSFu1bcf8HoYQoFG1lkCEzkJ6oK+8NY2LoVU29XipggAj1M4f7Zw/uw 7M6V7uzDbrPDsF9yOZGjCcqro3vSoFFQAcv7Gx5n46NqSqoQ0jGRZwRxUh+6vkt4UeXh mLc8rzItxZ3TUvH8mE9ycnyH030sNmOEPK6fNonsK4JZnVSDYXIgWPa3smZ714Hwobv1 lUcFoPFy67EM/CYtEnhHF6GKqcRyqgTSpG8mKiIBF6QPtdAs9hIbIxuS8JeMUgdcDuQ7 2eFPI5IHAltkpJhgJDyTyvdcf54ngSGnmPeIyPCY/gNXAtJtA1IMOgx9yGmhl5NObAqX vjMw== X-Gm-Message-State: AJaThX4tTKecCDMGlU4whf0QnuDEfxH+MGSM7e1GosdwwOemxqyyhPKP 9KUn/HkRIdmc0uX1gGANge35a83uD8w= X-Google-Smtp-Source: AGs4zMZlSZDZ4u3zzJBDKi3NhwlCPDBu1I/Uc3ts1aTS3OPrzgqlndiRA6uD8k8GkNfrCT+9EOGVHA== X-Received: by 10.98.150.26 with SMTP id c26mr7221971pfe.224.1512059424546; Thu, 30 Nov 2017 08:30:24 -0800 (PST) Received: from [10.0.1.4] ([199.204.20.35]) by smtp.gmail.com with ESMTPSA id l80sm8836750pfk.67.2017.11.30.08.30.23 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 30 Nov 2017 08:30:24 -0800 (PST) From: Kevin Wooten Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.0 \(3445.1.6\)) Message-Id: Date: Thu, 30 Nov 2017 09:30:22 -0700 To: tram@ietf.org X-Mailer: Apple Mail (2.3445.1.6) Archived-At: Subject: [tram] Possible inconsistency with RFC-7635 X-BeenThere: tram@ietf.org 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: Thu, 30 Nov 2017 16:32:37 -0000 All, We have just implemented a STUN/TURN server in Java/Kotlin using = Netty. It was originally done after examining =E2=80=9Ccoturn=E2=80=9D = as a possible solution and deciding we would roll our own for a number = of reasons and have completed a working version. One of the biggest = reasons for rolling our own server was to be able to implement proper = accounting, traffic shaping and statistics. During the implementation = we realized that we might have an issue with OAuth authentication. As we implemented RFC-7635 there seems to be an inconsistency we = cannot reconcile with the way credentials are required to be handled = throughout the spec and those provided by the OAuth spec. Specifically = that OAuth POP never provides the server an actual username (and = possibly realm) to the server. This has shown us what appears to be an = inconsistency with the original TURN spec (RFC-5766) and it happens to = be very limiting when implementing our accounting, shaping and = statistics. -- Inconsistency between RFC-7635 and RFC-5766 =E2=80=94 First I=E2=80=99ll inquire about the possible inconsistency... = In RFC-5766 section 17.3.3 titled ("Manipulating Other Allocations=E2=80=9D= ) it details an insider attack that is prevented by =E2=80=9Crequiring = that the credentials used in CreatePermission, Refresh, and ChannelBind = messages match those used to create the initial allocation=E2=80=9D. The = requirements for storing and comparing the credentials are mentioned = throughout 5766 spec and does not appear to be an =E2=80=9Coptional=E2=80=9D= part of the spec as Section 4 paragraph 5 details this as a = requirement. For long term credentials this is fairly easy as the USERNAME = uniquely identifies a specific user. When implementing OAuth we cannot = figure out how to do this reliably. The OAuth POP token, provided in = ACCESS-TOKEN, only provides the session/mac key, lifetime and timestamp; = it doesn=E2=80=99t identify a specific user. The USERNAME only = identifies the key id required to decrypt the ACCESS-TOKEN. We tried = using the session/mac key as the =E2=80=9Ccredentials=E2=80=9D but since = each call to the OAuth AS will produce a difference session/mac key (and = possibly even use a different key id) it causes subsequent requests = (e.g. REFRESH) to fail; this was proven when we ran interoperation tests = with coturn=E2=80=99s test client. This is especially prevalent when = the ACCESS-TOKEN expires and needs to be refreshed because it will = definitely generate a new session/mac key. Essentially, this means = anybody who was issued a token with the same key id (kid) is considered = to be the same user and therefore _could_ manipulate another=E2=80=99s = allocation; although the attack seems remote and requires spoofing it = nonetheless is detailed as a requirement. I=E2=80=99d like to know if our interpretation is wrong, if = we=E2=80=99re missing something or if this is a valid inconsistency in = specs. In any case, it does seem a proper username and possibly realm = should be retrievable _somewhere_ in an OAuth authenticated request; = whether in a new attribute, the original attribute (and key id moved = someplace else), in the ACCESS-TOKEN, or maybe it=E2=80=99s there and = we=E2=80=99ve missed exactly how to derive it. -- Impediment related to accounting and statistics =E2=80=94 This is basically a follow on to the previous.. One of our = stated goals was proper accounting, shaping, and statistics. This is not = easily done in the current form of RFC-7635 as we only have the key id = (in USERNAME) to identify clients. As you might imagine this is not = useful for out stated purposes. For example, trying to traffic shape = (e.g. bandwidth throttling) per user is pretty hard when the user = isn=E2=80=99t known.=20 The only work arounds we seem to have are using a unique long = term key per user or some form of communication between the TURN server = and the AS server to exchange a session/mac key for proper user = identification; we=E2=80=99d really love to avoid either of those as = they corrupt many of the advantages of using the OAuth mechanism. If we = are able to resolve the inconsistency stated in the previous section, = this issue resolves itself because we would have a proper = username/userid in the request. Thanks, Kevin Wooten=