Subject: [MMUSIC] draft-macdonald-mmusic-ice-lite-00 -- ice for open internet devices

From: [email-masked]
Date: Mon, 16 Oct 2006 06:42:49 -0400 (EDT)

I submitted a small draft which outlines the proposed mechanism for simplifying ICE for open internet devices and describes some of the open issues. Hopefully this will allow those that not been in the calls or closely following the relevant email threads to get caught up on the debate. 

This document may eventually be subsumed into core ice; there are arguements for and against this which are outlined in the draft.

Until it shows up in the repository it can be found at:

https://scm.sipfoundry.org/rep/ietf-drafts/derek/draft-macdonald-mmusic-ice-lite-00.txt

-Derek

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 16 Oct 2006 15:46:37 -0400

Thanks for writing this up. I think there are two main issues in here.

The first issue is whether description of a lightweight ICE 
implementation belongs in ICE or elsewhere. At this point, I buy 
Philip's arguments that we can't progress ICE till we're sure that 
works, and in that case, it makes more sense to include the description 
in an annex in the ICE spec. I think we all agree that the noramtive 
rules, like this active/passive thing, belong in the core protocol 
document once we agree on them.

On the main technical issue, on the active/passive negotiation. You make 
a good point on the v4/v6 case. This won't work with my proposed 
heuristic. I don't object to negotiating in principle, I'm just trying 
to keep it simple. Perhaps it is easier to just negotiate this with the 
flag.

The question then remains in my mind, what happens when both sides are 
passive. I think that you still want to do your own check and not just a 
triggered check. The reason is that sending a check is still necesary 
for avoiding the voice hammer attack. If a gateway never sends a check, 
a malicious caller will send an INVITE with the passive attribute set, 
and then gateway responds in kind. No checks are done, and the gateway 
floods the target.

So, what do you think about an algorithm whereby we use the 
active/passive flag. If both sides are passive, the done flags are never 
set, neither side will send a re-invite for ICE reasons, but both sides 
will generate checks, respond to checks with a triggered check, and not 
send media until a check validates.

So, the main complication for large gateways is not sending the check 
IMHO, but receiving the username and password for it. That is signaled 
through SIP. In distributed gateway implementation, it requires an MGCP 
extension to convey the username/password. If there were a way to avoid 
THAT it would be really good for gateways. I cannot see a way how that 
is not seriously flawed from a security perspective.

Thanks,
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

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Tue, 17 Oct 2006 14:48:06 +0200

Hi,

You say that the most common use of this would be PSTN gateways.

Would it be good to say that terminals that support "full" ICE can also
use the lite behavior, in case they detect that they are not located
behind a NAT?

Regards,

Christer

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: 16. lokakuuta 2006 13:43
> To: [email-masked]
> Subject: [MMUSIC] draft-macdonald-mmusic-ice-lite-00 -- ice 
> for openinternet devices
> 
> I submitted a small draft which outlines the proposed 
> mechanism for simplifying ICE for open internet devices and 
> describes some of the open issues. Hopefully this will allow 
> those that not been in the calls or closely following the 
> relevant email threads to get caught up on the debate. 
> 
> This document may eventually be subsumed into core ice; there 
> are arguements for and against this which are outlined in the draft.
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 17 Oct 2006 11:33:28 -0400

NO.

The difficulty in detecting this in a normal end-user device is the 
reason we moved away from the old STUN mechanism to ICE.

-Jonathan R.

Christer Holmberg (JO/LMF) wrote:

>>https://scm.sipfoundry.org/rep/ietf-drafts/derek/draft-macdona
> 
> ld-mmusic-ice-lite-00.txt
> 
>>-Derek
>>
>>

---

From: "Christer Holmberg \(JO/LMF\)" <[email-masked]>
Date: Wed, 18 Oct 2006 09:58:30 +0200

Hi,

Ok. What about "mid-network" devices, then, like media servers etc? They
may not be located behind a NAT.

Regards,

Christer

> > Would it be good to say that terminals that support "full" ICE can 
> > also use the lite behavior, in case they detect that they are not 
> > located behind a NAT?
> > 
> > Regards,
> > 
> > Christer
> > 
> >  
> > 
> > 
> >>Subject: [MMUSIC] draft-macdonald-mmusic-ice-lite-00 -- ice for 
> >>openinternet devices
> >>
> >>I submitted a small draft which outlines the proposed mechanism for 
> >>simplifying ICE for open internet devices and describes some of the 
> >>open issues. Hopefully this will allow those that not been in the 
> >>calls or closely following the relevant email threads to 
> get caught up 
> >>on the debate.
> >>
> >>This document may eventually be subsumed into core ice; there are 
> >>arguements for and against this which are outlined in the draft.
> >>