Re: [tram] I-D Action: draft-ietf-tram-turnbis-17.txt
Brandon Williams <brandon.williams@akamai.com> Mon, 14 May 2018 16:56 UTC
Return-Path: <brandon.williams@akamai.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 94DC912E895 for <tram@ietfa.amsl.com>; Mon, 14 May 2018 09:56:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.711
X-Spam-Level:
X-Spam-Status: No, score=-2.711 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, T_DKIMWL_WL_HIGH=-0.01] 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 WXkh3Qf-c6me for <tram@ietfa.amsl.com>; Mon, 14 May 2018 09:56:15 -0700 (PDT)
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 C29CA12E898 for <tram@ietf.org>; Mon, 14 May 2018 09:56:14 -0700 (PDT)
Received: from pps.filterd (m0122332.ppops.net [127.0.0.1]) by mx0a-00190b01.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w4EGlEBO015495; Mon, 14 May 2018 17:56:14 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=akamai.com; h=subject : to : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=jan2016.eng; bh=9uQrqD2wgUFc125fBI6TLVifSOWxhD/NEpXl1FCONkY=; b=dNVMXpNpoWuRrPuSfUSMSjZNYAiPn+PC0yDe3MIu350EJCE9PdUton8oSfo2JhZNG7fF REn0+4LQQU7s2FliVXB2rCKkSA0NQkFJje7WAH+F69Ku9Q1/UKAshvOPE4209LoWwwrW TYt4pIWTrheXVMFl4PTPVm9DJ9Ne5azBI4D9hbWPuAKyL4eG7+cSS2aJiJ3FhX5cejP/ 4OVXiYP5DnZLbO3glcD5UhVCh3d4OgMGzi/n4yNokTj5Dq9UEwtsdh+d0soObOGTFvKI +4XHjke9xt0Uuk0u7k7s1yiMVrw6NyWDqwl9tFPuGVhU6WJvndVxzP/SU3zGFI1gtN74 4A==
Received: from prod-mail-ppoint2 (prod-mail-ppoint2.akamai.com [184.51.33.19]) by mx0a-00190b01.pphosted.com with ESMTP id 2hwraewj3g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 14 May 2018 17:56:14 +0100
Received: from pps.filterd (prod-mail-ppoint2.akamai.com [127.0.0.1]) by prod-mail-ppoint2.akamai.com (8.16.0.21/8.16.0.21) with SMTP id w4EGjqAT023127; Mon, 14 May 2018 12:56:12 -0400
Received: from prod-mail-relay11.akamai.com ([172.27.118.250]) by prod-mail-ppoint2.akamai.com with ESMTP id 2hwukus87b-1; Mon, 14 May 2018 12:56:12 -0400
Received: from [172.28.116.218] (bowill.kendall.corp.akamai.com [172.28.116.218]) by prod-mail-relay11.akamai.com (Postfix) with ESMTP id BB3DE1FC11; Mon, 14 May 2018 16:56:11 +0000 (GMT)
To: "Konda, Tirumaleswar Reddy" <TirumaleswarReddy_Konda@McAfee.com>, "tram@ietf.org" <tram@ietf.org>
References: <152449325211.21886.16366690442756908271@ietfa.amsl.com> <BN6PR16MB1425426EB89F135FF50FCA5AEA890@BN6PR16MB1425.namprd16.prod.outlook.com>
From: Brandon Williams <brandon.williams@akamai.com>
Message-ID: <347de982-54c5-4156-e406-0aa13ed4446c@akamai.com>
Date: Mon, 14 May 2018 12:56:10 -0400
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <BN6PR16MB1425426EB89F135FF50FCA5AEA890@BN6PR16MB1425.namprd16.prod.outlook.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-14_04:, , signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805140171
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2018-05-14_04:, , 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 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805140171
Archived-At: <https://mailarchive.ietf.org/arch/msg/tram/zpVbyEJgDI2N3Wspd_iI-ks7pKA>
Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-17.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." <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: Mon, 14 May 2018 16:56:18 -0000
Hi Tiru, I've got a few editorial suggestions on the new content re: permissionless STUN relay. As these are all editorial, you can of course feel free to ignore any/all of them. They are simply highlighting some places where I had some trouble parsing the text and do not represent substantive changes to the proposed content. Please let me know if you have any questions about the following. --Brandon Section 2.3. Permissions * "... the UDP datagram is silently discarded. However, a TURN server can be configured to permit ..." The use of "However" here implies a more significant departure from the preceding sentence than you intend. I suggest dropping it. "... the UDP datagram is silently discarded. A TURN server can be configured to permit ..." * "... speeds up STUN connectivity checks, while the client creates permissions in the TURN server for the remote peer IP addresses, the remote peer can initiate connectivity checks to the client." The use of "while" after the comma makes it seem like a different use of the word than you intend. I suggest "... speeds up STUN connectivity checks, allowing the remote peer to initiate connectivity checks to the client while the client is creating permissions in the TURN server for the remote peer IP addresses." Section 9. Permissions * "... do not match the permissions installed, this configuration knob MUST ..." The "," makes this sentence seem like a run-on. I suggest "... do not match the permissions installed. This configuration knob MUST ..." * "... unless explicitly configured to do so otherwise." The "so" is confusing here. I suggest "... unless explicitly configured to do otherwise." * "If no match is found and the received datagram is not a STUN packet, relaying is not permitted, and the server silently discards the UDP datagram. If an exact match is found or the received datagram is a STUN packet, then the permission check is considered to have succeeded and the server continues to process the UDP datagram as specified elsewhere (Section 11.3)." Although the correct interpretation of this text is suggested by the preceding paragraph, as written it appears to imply that the non-default behavior is the normal expected behavior. I think it would be good to clarify. I suggest the following text. "If no match is found and the received datagram is not a STUN packet, the permission check is considered to have failed. If an exact match is found, the permission check is considered to have succeeded. If no match is found and the received datagram is a STUN packet, the permission check is considered to have failed unless the server is configured to allow STUN packets without explicit permission, in which case the permission check is considered to have succeeded. If the permission check fails, relaying is not permitted and the server silently discards the UDP datagram. If the permission check succeeds, the services continues to process the UDP datagram as specified elsewhere (Section 11.3)." If that text seems unwieldy, the section might be easier to parse if converted to a bullet list. Section 19.2. Firewall Considerations I find the new paragraph to be a little bit difficult to read. I suggest reorganizing the text. ====== When a TURN server is configured to permit inbound STUN packets on the allocation's relayed address even if the source IP addresses of the STUN packet's does not match the permissions installed, the TURN server MUST have a security policy for inbound STUN packets from IP addresses not matching the permissions installed in order to prevent an attacker from flooding the TURN client with STUN-like packets. The TURN server can limit forwarding to well-formed STUN connectivity check packets by looking for the STUN atrributes USERNAME and MESSAGE-INTEGRITY and verifying that the message does not exceed a specific configurable packet size. Additionally, the TURN server policy can be configured with maximum rate-limits for the number of STUN packets allowed in a TURN session, STUN packets allowed per second, and IP addresses allowed to send STUN packets. ===== On 04/23/2018 10:29 AM, Konda, Tirumaleswar Reddy wrote: > Updated draft allows the TURN server to forward inbound STUN connectivity checks without permissions and also addresses the comments from Noriyuki Torii. > > -Tiru > >> -----Original Message----- >> From: tram [mailto:tram-bounces@ietf.org] On Behalf Of internet- >> drafts@ietf.org >> Sent: Monday, April 23, 2018 7:51 PM >> To: i-d-announce@ietf.org >> Cc: tram@ietf.org >> Subject: [tram] I-D Action: draft-ietf-tram-turnbis-17.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-17.txt >> Pages : 84 >> Date : 2018-04-23 >> >> 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 RFC 5766 and RFC 6156. >> >> >> 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-17 >> https://datatracker.ietf.org/doc/html/draft-ietf-tram-turnbis-17 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-tram-turnbis-17 >> >> >> 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 >
- [tram] I-D Action: draft-ietf-tram-turnbis-17.txt internet-drafts
- Re: [tram] I-D Action: draft-ietf-tram-turnbis-17… Konda, Tirumaleswar Reddy
- Re: [tram] I-D Action: draft-ietf-tram-turnbis-17… Brandon Williams
- Re: [tram] I-D Action: draft-ietf-tram-turnbis-17… Konda, Tirumaleswar Reddy