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

From: The IESG <[email-masked]>
Date: Fri, 18 Jul 2014 07:21:51 -0700

The IESG has received a request from the TURN Revised and Modernized WG
(tram) to consider the following document:
- 'Problems with STUN long-term Authentication for TURN'
  <draft-ietf-tram-auth-problems-02.txt> as Informational RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
[email-masked] mailing lists by 2014-08-08. Exceptionally, comments may be
sent to [email-masked] instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document discusses some of the issues with STUN authentication
   for TURN messages.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-tram-auth-problems/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-tram-auth-problems/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Spencer Dawkins at IETF <[email-masked]>
Date: Sun, 20 Jul 2014 11:11:14 -0500

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".

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 23 Jul 2014 08:30:00 +0000

Hi Spencer,

Thanks for your comments. I have taken care of all of them except the
first one.

>defined in section 2.7 of [RFC5128]).  TURN ensures that a connection

There is a typo above. It is section 2.8 and not 2.7 RFC 5128 is the
closest definition of P2P that we can find. We can remove this reference
if needed and just say "P2P applications like SIP, webRTC Peer Stream
Protocol e.t.c". We tried to see if we can refer to RFC 5694 as the
definition of that specification does not allow WebRTC, SIP to be
categorised as P2P.

Let me know your comments on this.

Regards,
Ram
>
>
>From: Spencer Dawkins at IETF <[email-masked]>
>Date: Sunday, 20 July 2014 9:41 pm
>To: "[email-masked]" <[email-masked]>
>Cc: "[email-masked]" <[email-masked]>
>Subject: Re: [tram] Last Call: <draft-ietf-tram-auth-problems-02.txt>
>(Problems with STUN long-term Authentication for TURN) to Informational
>RFC
>
>
>This might be clearer as "An Allocate request is more likely than a
>Binding request to ..."
>...

---

From: Muthu Arul <[email-masked]>
Date: Wed, 23 Jul 2014 15:08:05 +0530

I think Spencer's questions is whether is is right to use the word
"ensures". I think "allows" is more appropriate:

    TURN allows a connection to be established through a relay when one or
both sides
    is incapable of a direct P2P connection.

On the other hand, TURN can't do anything if the connection is
administratively blocked by someone somewhere (and thus can't ensure it).

Muthu

On Wed, Jul 23, 2014 at 2:00 PM, Ram Mohan R (rmohanr) <[email-masked]>
wrote:

> _______________________________________________
> tram mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tram
>

---

From: Brandon Williams <[email-masked]>
Date: Wed, 23 Jul 2014 05:54:11 -0400

Hi Ram,

Did you address the point that Spencer made about the quoted text?

--Brandon

PS: Also, to your questions, section 2.7 does indeed define "P2P 
Application". Section 2.8 defines "NAT-Friendly P2P Application". Either 
is an appropriate reference here, I think.

(resent from the correct address for the list, sorry for the dup Spencer)

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

-- 
Brandon Williams; Senior Principal Software Engineer
Emerging Products Engineering; Akamai Technologies Inc.

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 23 Jul 2014 10:11:33 +0000

Hi Brandon,

I suppose you meant the same point I had put below.

>Is this the right word? ("Does it work every time?")

As muthu said we can change the wording from ³ensures" to ³allows².

So it will be:

"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 a connection to be established
through a relay when one or both sides    is incapable of a direct P2P
connection.²

I will stick with the current reference only.

Let me know if you have any other comments in the draft.

Thanks,
Ram

-----Original Message-----
From: Brandon Williams <[email-masked]>
Date: Wednesday, 23 July 2014 3:24 pm
To: Ram Mohan Ravindranath <[email-masked]>,
"[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [tram] Last Call: <draft-ietf-tram-auth-problems-02.txt>
(Problems with STUN long-term Authentication for TURN) to Informational RFC

---

From: "Ram Mohan R (rmohanr)" <[email-masked]>
Date: Wed, 23 Jul 2014 10:34:41 +0000

Sorry there was some issue in my text in below email. The modified text
will be :

“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 allows a connection
to be established even when one or both sides is incapable of a
   direct P2P connection."

Sorry for multiple emails.

Regards,
Ram

-----Original Message-----
From: Ram Mohan Ravindranath <[email-masked]>
Date: Wednesday, 23 July 2014 3:41 pm
To: Brandon Williams <[email-masked]>,
"[email-masked]" <[email-masked]>,
"[email-masked]" <[email-masked]>
Subject: Re: [tram] Last Call: <draft-ietf-tram-auth-problems-02.txt>
(Problems with STUN long-term Authentication for TURN) to Informational RFC