Subject: [MMUSIC] ICE and private addresses

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 27 Jun 2006 12:05:36 +0200

Hi,

Assume client A and B are located in two separate private networks (with
a "public" network in between), which happen to have an overlapping
address space.

Now, when client A generates the candidate attributes the Local Candiate
is going to contain the local client A IP address/port.

When client B receives the candidate attributes is will initiate the
connectivity checks, as defined in ICE.

Now, due to the overlapping address space, the client A Local Candidate
address may actually point also to a third client (C), located in the
same network as client B, so the connectivity check messages will be
sent towards client C instead of client A.

I guess there, at least in theory, could also be a scenario where the
c/m line also contains the client A Local Candidate address, again also
pointing towards client C.

I am not sure whether the B2BUA issues discussed in another thread
(where the B2BUA modifies the c/m lines) have any impacts on this
scenario. Need to think about that...

Regards,

Christer

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

---

From: Philip Matthews <[email-masked]>
Date: Fri, 30 Jun 2006 17:41:21 -0400

On 27-Jun-06, at 06:05 , Christer Holmberg ((JO/LMF)) wrote:

>
> Hi,
>
> Assume client A and B are located in two separate private networks  
> (with a "public" network in between), which happen to have an  
> overlapping address space.
>
> Now, when client A generates the candidate attributes the Local  
> Candiate is going to contain the local client A IP address/port.
>
> When client B receives the candidate attributes is will initiate  
> the connectivity checks, as defined in ICE.
>
> Now, due to the overlapping address space, the client A Local  
> Candidate address may actually point also to a third client (C),  
> located in the same network as client B, so the connectivity check  
> messages will be sent towards client C instead of client A.
This is correct. Binding Requests sent by B to A's local candidate  
will actually be delivered to C.
This is a known problem with the "UDP hole punching" technique (used  
by ICE and others).
The ICE spec discusses this situation. There are two cases of interest:
a) If C does not support ICE, then C just has to deal with  
unsolicited packets arriving on random ports.
b) If C does support ICE, then the 24 bits of randomness in the  
candidate id is intended to ensure that C can distinguish these  
packets from other Binding Request which is IS expecting.
> I guess there, at least in theory, could also be a scenario where  
> the c/m line also contains the client A Local Candidate address,  
> again also pointing towards client C.
Yes, this would happen if the A considered its local candidate to be  
the most likely to work. In this case, A would put the local  
candidate into the c/m lines.
The comments above about C still apply.
> scenario. Need to think about that...
This is why it is important to assign a candidate id to the new  
transport address (= the new value in the c/m lines). In my last  
posting on that other thread, I had suggested including a "default"  
candidate id to use ("default" is not really the right term -- this  
candidate id would be used if and only if the c/m lines got modified).

- Philip