Subject: [MMUSIC] Confusion regarding ICE username fragment

From: Jon Ringle <[email-masked]>
Date: Tue, 19 Oct 2004 16:46:14 -0400

I'm a little confused regarding the use of username fragments in ICE. The 
following statement is in draft-ietf-mmusic-ice-02, Section 5.3.2:

   For each local transport address where a STUN server is running, the
   client MUST choose a username fragment and a password.  The username
   fragment created by the client will be concatenated with the fragment
   created by its peer.  The result will serve as the username provided
   by its peer in STUN requests.  By creating the username as a
   combination of information from each side of a call, it allows a
   client to correlate the source of the request with a candidate
   transport address.  This is discussed further below.

   The username fragment MUST be globally unique, so that no other host
   will select a username with the same value.  This username fragment
   and password will be passed to its peer in an initiate or accept
   message.  As such, the process described in this section will
   associate, with each local transport address, a username fragment and
   password.  The client also associates this same username fragment and
   password with any transport addresses derived from the local
   transport address.

Suppose phone-A has only one local transport address on eth0 and derives a 
STUN and TURN address from the eth0 local transport address. From what I read 
above, it seems like only a username fragment and password is chosen only for 
the eth0 address, and that the derived STUN/TURN addresses use this same 
username/password. So, this would result in alt's in SDP in the initiate 
message from phone-A to phone-B like this:

a=alt:1 1.0 : PhoneAeth0user password 172.16.1.102 1234
a=alt:2 0.8 : PhoneAeth0user password 1.1.1.4 8801
a=alt:3 0.4 : PhoneAeth0user password 1.1.1.5 3002

This seems to go against the examples that are shown in 
draft-rosenberg-sipping-nat-scenarios-03, where a separate username fragment 
is shown for each local and derived addresses.

It seems to me that separate username fragments would be needed for each 
gathered address for correlation to the candidate table.

I feel like I am missing a key concept here. Could someone please explain.

Thanks,

Jon

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 26 Oct 2004 01:35:54 -0400

Jon,

Good question. Basically, this was a bug in ICE.

Each local transport address has to have its own username and password. 
Now, in -03, each local transport address is either used in the 
initiate/accept mesage, or else is associated with a single derived 
transport address. This means that if I have a single local interface 
and can use TURN and STUN unilateral allocations, I'll bind to *three* 
local interfaces. One of them gets sent directly to the peer. One is 
used for the STUN allocations. One is used for the TURN allocations. A 
stun server is set to run locally on all three sockets, and each of the 
three has a unique username/password.

If you don't do this, you run into a nasty problem which is there is no 
way to reliably know that your peer has suceeded in its connectivity 
checks. That is needed to allow you to turn off the stun server and 
accept only media packets. This also simplified the protocol in several 
places.

The drawback (compared to having multiple derived transport addresses 
from a single local transport address) is that it increases your port 
usage. I was hesitatnt to go this route at first because of this, but 
the alternative (not being able to turn off the stun servers) seemed 
worse based on group consensus on this point.

The problem is probably only a big deal in servers like gateways and 
conference bridges. However, if those do ICE, I wouldn't expect them to 
do turn or stun, in which case there is no additional cost in terms of 
socket resources.

HTH,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Director, Service Provider VoIP Architecture   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                        FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com