Subject: RE: [MMUSIC] ICE and private addresses

From: "Cooper, Eric \(Eric\)" <[email-masked]>
Date: Tue, 4 Jul 2006 12:30:24 -0400

Comment inline.

Best Regards,

Eric. 

-----Original Message-----
From: Christer Holmberg (JO/LMF) [mailto:[email-masked]]

Sent: Tuesday, July 04, 2006 10:10 AM
To: Philip Matthews
Cc: [email-masked]
Subject: RE: [MMUSIC] ICE and private addresses

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).
 
[EC] So it seems like a good idea to require ICE connectivity checks
before sending media to the address of the m/c line.  ICE does this in
regular scenarios, for just this reason, I assume.  The reasoning holds
true for cases when the m/c line doesn't contain a candidate (as is
being discussed in another thread).

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

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 07 Jul 2006 16:05:15 -0400

inline.

Cooper, Eric (Eric) wrote:

> regular scenarios, for just this reason, I assume. 

This and others. It also avoids this voice hammer attack that is 
discussed in security considerations section. That attack is really 
worrisome.

Of course, if A doesn't support ICE then this check is not made. Of 
course, this is no worse than the case today, where a client can point a 
local address in the m/c-line. Now ICE does say that the address in the 
m/c-line is one that is most likely to work, and it recommends the 
relayed address for that reason. Consequently, even for ICE-unaware 
endpoints you generally won't see this problem.

-Jonathan R.

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