Subject: RE: [MMUSIC] ICE and private addresses

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 4 Jul 2006 16:09:49 +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.
 
>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.
 
[CHH] Correct, so from an ICE perspective it may not be a problem (it's of course not nice to have data being sent to the wrong client, but that's a separate issue). It's a bigger problem if C receives the media that B is sending towards A (which would happen IF the c/m line contains the local address of client A).
 
Regards,
 
Christer

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

---

From: Philip Matthews <[email-masked]>
Date: Wed, 5 Jul 2006 13:23:16 -0400

On 4-Jul-06, at 10:09 , 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.
>
>> 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
>> 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.
> [CHH] Correct, so from an ICE perspective it may not be a problem  
> (it's of course not nice to have data being sent to the wrong  
> client, but that's a separate issue). It's a bigger problem if C  
> receives the media that B is sending towards A (which would happen  
> IF the c/m line contains the local address of client A).
>

This won't happen, because A and B tell each other (via signaling)  
that they both speak ICE, and thus B will not send media to A along  
some transmission path T until after B verifies (via a Binding  
Request/Response exchange) that that path T goes from B to A.

This exact situation (with the roles of A and B reversed) is  
discussed in two paragraphs towards the end of section 7.3 of the new  
ICE-09 spec.

- Philip

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Thu, 6 Jul 2006 10:08:43 +0200

Hi,

>Request/Response exchange) that that path T goes from B to A.

[CHH] Correct, IF there will be a connectivity check (see discussion on what to do if there are no candidates for c/m)
 
Regards,
 
Christer