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

["Konda, Tirumaleswar Reddy" <[e-mail]>]

Thanks Brandon for the review. Updated draft to incorporate the proposed changes.

Cheers,
-Tiru

> -----Original Message-----
> From: Brandon Williams [mailto:[e-mail]]
> Sent: Monday, May 14, 2018 10:26 PM
> To: Konda, Tirumaleswar Reddy <[e-mail]>;
> [e-mail]
> Subject: Re: [tram] I-D Action: draft-ietf-tram-turnbis-17.txt
> 
> This email originated from outside of the organization. Do not click links or
> open attachments unless you recognize the sender and know the content is safe.
> 
> 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:[e-mail]] On Behalf Of internet-
> >> [e-mail]
> >> Sent: Monday, April 23, 2018 7:51 PM
> >> To: [e-mail]
> >> Cc: [e-mail]
> >> 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
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/tram
> >
> > _______________________________________________
> > tram mailing list
> > [e-mail]
> > https://www.ietf.org/mailman/listinfo/tram
> >