Re: [tram] I-D Action: draft-ietf-tram-turnbis-17.txt

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
> 