Subject: [Ietf-behave] TURN issue #1: MAPPED-ADDRESS reunification

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 5 Dec 2005 07:56:45 -0800 (PST)

As I mentioned during the IETF meeting, I am working on a revision of 
STUN that structures the protocol into a "framework" layer (though we 
agreed not to call it that per se), and various "usages" that can define 
extensions, define what messages and attributes get used, and define 
various security considerations. The plan is for TURN to become a STUn 
usage rather than a separate protocol. I think this is a good thing, 
since TURN repeats a lot of stun, and its relationship with it is unclear.

One of the things I mentioned as a side benefit of this unification is 
that the TURN Allocate request could perform a stun check as a side 
effect. The Allocate response can include the source IP/port of the 
Allocate request (equivalent to the MAPPED-ADDRESS in the STUn Binding 
Response). This way, an ICE endpoint, for example, can issue just a 
single Allocate request to a turn server, and get back its stun-derived 
AND turn-derived addresses in one operation. This will reduce the 
overhead of ICE and simplify things. There seemed to be good support for 
doing this when I proposed it in the meeting last month.

So, whats the issue? Syntax, unfortunately.

The IDEAL solution for doing this is that the MAPPED-ADDRESS attribute 
always indicate the source IP/port as seen by the server in the request, 
and that it be usable with the existing STUN Binding Response and the 
TURN Allocate Response. Unfortunately, TURN redefined MAPPED-ADDRESS, 
and the meaning of MAPPED-ADDRESS in a TURN Allocate Response is the 
address allocated by the TURN server itself.

So, there are several options:

1. break backwards compatibility with TURN, and define MAPPED-ADDRESS to 
 be the source IP/port of the request. Define a new attribute, say 
RELAY-ADDRESS, that contains the allocated address on the TURN server, 
and use that in the Allocate response.

2. retain backwards compatibility with TURN, and define a new attribute, 
ALLOC-SOURCE-ADDR, which indicates the source IP/port of the Allocate 
request. Thus, we'd have two attributes with the same definition, and 
you'd need to use one of them with one request type (MAPPED-ADDRESS with 
Binding Request) and the other with the other request type 
(ALLOC-SOURCE-ADDR with Allocate Request).

3. Do (1), but only if the client indicates it supports this capability. 
If not, MAPPED-ADDRESS retains its current meaning and there is no way 
to get the source IP/port from the Allocate request.

Technically speaking, in a greenfield environment, #1 is clearly the 
right solution. The problem is, there are now several deployments of 
TURN, some of them large in fact, and I want to be sensitive to 
backwards compatibility issues.

So, I'd like to hear from folks on this, especially ones with 
implementations or deployments.

Thanks,
Jonathan R.
--
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
jdrosen@xxxxxxxxx                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

---

From: Marc Petit-Huguenin <[email-masked]>
Date: Tue, 6 Dec 2005 08:21:49 -0800 (PST)

I vote for #1.

-- 
Marc Petit-Huguenin
Home: marc@xxxxxxxxxxxxxxxxxx
Professional: petithug@xxxxxxx
Work: marc@xxxxxxx

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 13 Dec 2005 20:36:38 -0800 (PST)

I'm not aware of any deployments that would find #1 difficult to migrate to,
so, #1 sounds best.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 19 Dec 2005 10:53:29 -0800 (PST)

OK, it sounds like there is general consensus for #1, so I will do that. 
 I'll call the new attribute RELAY-ADDRESS and use value 0x0016 for it.

-Jonathan R.

Cullen Jennings wrote:

I vote for #1.