Re: [tram] Last Call: <draft-ietf-tram-auth-problems-02.txt> (Problems with STUN long-term Authentication for TURN) to Informational RFC

[Spencer Dawkins at IETF <[e-mail]>]

I had a small number of nits that weren't worth holding up IETF Last Call
for. Please consider them along with other feedback you receive.

Thanks!

In this text:

1.  Introduction

   Traversal Using Relay NAT (TURN) [RFC5766] is a protocol that is
   often used to improve the connectivity of P2P applications (as
   defined in section 2.7 of [RFC5128]).  TURN ensures that a connection
                                               ^^^^^^^
Is this the right word? ("Does it work every time?")

   can be established even when one or both sides is incapable of a
   direct P2P connection.  The TURN server is also a a building block to
   support interactive, real-time communication using audio, video,
   collaboration, games, etc., between two peer web browsers using the
   Web Real-Time communication (WebRTC) [I-D.ietf-rtcweb-overview]
   framework.

...

   o  Enterprise networks deploy firewalls which typically block UDP
      traffic.  When SIP user agents or WebRTC endpoints are deployed
      behind such firewalls, media cannot be sent over UDP across the
      firewall, but must be sent using TCP (which causes a different
      user experience).  In such cases a TURN server deployed in the
      DeMilitarized Zone (DMZ) MAY be used to traverse firewalls.
                               ^^^
I'm thinking that's not an RFC 2119 MAY. I'm thinking that's "might".

   o  The use-case explained in "Simple Video Communication Service,
      enterprise aspects" (Section 3.2.5 of
      [I-D.ietf-rtcweb-use-cases-and-requirements]) refers to deploying
      a TURN server in the DMZ to audit all media sessions from inside
      an Enterprise premises to any external peer.

...

   o  ICE connectivity checks using server reflexive candidates could
      ^^^
      fail when the endpoint is behind NAT that performs Address-
                                                         ^^^^^^^^
      dependent mapping.  In such cases relayed candidate allocated from
      ^^^^^^^^^^^^^^^^^
      the TURN server is used for media.

I'm thinking references for ICE and for "Address-dependent mapping" would
be helpful. The next usage of ICE does have a reference, so that's just
moving the reference to first-use-of-term.

   Compared to a Binding request the Allocate request is more likely to
   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   be identified by a server administrator as needing client
   authentication and integrity protection of messages exchanged.
   Hence, the issues discussed here in STUN authentication are
   applicable mainly in the context of TURN messages.

This might be clearer as "An Allocate request is more likely than a Binding
request to ..."

...

4.  Problems with STUN long-term Authentication for TURN

   6.  Hosting multiple realms on a single IP address is challenging
       with TURN.  When a TURN server needs to send the REALM attribute
       in response to an unauthenticated request, it has no useful
       information for determining which realm it should send, except
                                                         ^^^^
       the source transport address of the TURN request.  Note this is a
       problem with multi-tenant scenarios only.  This may not be a
       problem when TURN server is located in enterprise premises.

This might be clearer as "it should send the response to".