Subject: Re: [BEHAVE] DISCUSS: draft-ietf-behave-turn

From: Philip Matthews <[email-masked]>
Date: Wed, 8 Apr 2009 00:01:38 -0400

On Sat, 4-Apr-09, at 16:09 , Russ Housley wrote:

> Discuss:
>
>  The IAB Considerations in RFC 3424 have not been changed, and it
>  is clear to me that TURN has an indefinite lifetime.  So, the first
>  two IAB UNSAF criteria cannot realistically be satisfied.  I do not
>  want to delay the document, but I do think it should include a
>  recognition of this conflict.  I'm happy with an IESG note or text
>  in the body of the document.
>

Actually, RFC 3424 only very tangentially applies to TURN, since TURN  
is just a protocol for controlling a relay. RFC 3424  applies to STUN  
and ICE much more directly.

Consideration 1 simply asks for a precise definition of the problem  
that TURN fixes, so I don't see what else can be said here.

However, Consideration 2 asks for an exit strategy or transition plan.  
Here I have changed the text of the response to Consideration 2 to read:

     Response: TURN will no longer be needed once there are no longer
     any NATs.  Unfortunately, as of the date of publication of this
     document, it no longer seems very likely that NATs will go away
     any time soon. However, the need for TURN will also decrease as
     the number of NATs with the mapping property of Endpoint- 
Independent
     Mapping [RFC4787] increases.

- Philip

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 09 Apr 2009 10:20:09 +1200

I was the Gen-ART reviewer whoes review led to Russ's comment.
So...

On 2009-04-08 16:01, Philip Matthews wrote:
> Actually, RFC 3424 only very tangentially applies to TURN, since TURN is
> just a protocol for controlling a relay. RFC 3424  applies to STUN and
> ICE much more directly.
> 
> Consideration 1 simply asks for a precise definition of the problem that
> TURN fixes, so I don't see what else can be said here.

Actually it specifically says "A short term fix should not be generalized
to solve other problems." and the TURN draft says

>    ...However, care has been taken to
>    make sure that TURN is suitable for other types of applications

Reading those two statements gave me a little cognitive dissonance.
Maybe you can add something like

Note that although TURN can be applied beyond the domain of SIP
usage, it can only satisfy these limited purposes.

However, this isn't a big deal IMHO.

>     the number of NATs with the mapping property of Endpoint-Independent

Works for me.

    Brian

---

From: Philip Matthews <[email-masked]>
Date: Sat, 11 Apr 2009 20:46:58 -0400

On Wed, 8-Apr-09, at 18:20 , Brian E Carpenter wrote:

>> that

Speaking for myself, I think that STUN/TURN/ICE is a general approach  
to NAT traversal, and not something just usable by SIP. In this  
regard, I will note that both RELOAD (the peer-to-peer protocol being  
developed in P2PSIP) and HIP now use STUN/TURN/ICE for NAT traversal.

So I am uncomfortable with adding your suggested sentence, since it  
seems to suggest that TURN can be used only for SIP-related purposes.

The problem I feel we are wrestling with is that the UNSAF document  
was hoping that either (a) NATs would go away soon, or (b) a better  
NAT traversal solution would soon emerge. Unfortunately, neither of  
these have happened in the years since it was published and neither  
seem likely to happen in the near future.

Finally, I will note that the only aspect of TURN which can be  
considered "Unilateral Self-Address Fixing" is the inclusion of the  
XOR-MAPPED-ADDRESS in the Allocate response. The value returned in  
this attribute is not used later in the protocol at all -- it is  
included only as a convenience to the client, who would otherwise have  
to do a Binding transaction with a STUN server.

- Philip

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 12 Apr 2009 17:04:54 +1200

Philip,

I have a lot of sympathy with your position; I just wanted
to be sure that the IESG knows about the issue, to avoid
any later complaints.

    Brian

On 2009-04-12 12:46, Philip Matthews wrote:
> Speaking for myself, I think that STUN/TURN/ICE is a general approach to
> NAT traversal, and not something just usable by SIP. In this regard, I
> will note that both RELOAD (the peer-to-peer protocol being developed in
> P2PSIP) and HIP now use STUN/TURN/ICE for NAT traversal.
> 
> The problem I feel we are wrestling with is that the UNSAF document was
> hoping that either (a) NATs would go away soon, or (b) a better NAT
> traversal solution would soon emerge. Unfortunately, neither of these
> have happened in the years since it was published and neither seem
> likely to happen in the near future.
> 
> XOR-MAPPED-ADDRESS in the Allocate response. The value returned in this
> attribute is not used later in the protocol at all -- it is included
> only as a convenience to the client, who would otherwise have to do a
> Binding transaction with a STUN server.
> 
> - Philip
> 
>