Subject: Re: [MMUSIC] Do We Need an ICE Alternative ?

From: <[email-masked]>
Date: Thu, 1 Dec 2011 15:05:14 +0100

Dear Flemming, all,

As an input to this discussion, I just submitted an I-D identifying some IPv6 use cases which motivate the need to define a new SDP attribute. These use cases cover both multicast and unicast.

The I-D is available at: http://tools.ietf.org/html/draft-boucadair-mmusic-ipv6-use-cases-00.

Comments and questions are welcome.

Cheers,
Med

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] 
> De la part de Flemming Andreasen
> Envoyé : mardi 15 novembre 2011 13:49
> À : mmusic
> Objet : [MMUSIC] Do We Need an ICE Alternative ?
> 
> Greetings
> 
> Over the past several years, the MMUSIC WG has developed and 
> standardized ICE (RFC 5245) as the mechanism to enable NAT 
> traversal and 
> IPv4/IPv6 transition for Offer/Answer based protocols (such as SIP). 
> Alternative NAT traversal mechanisms exist, and others have been 
> proposed, however they have either been limited to specific 
> deployment 
> topologies (e.g. symmetric RTP or STUN by itself) or required 
> some level 
> of network support (e.g. an ALG of some sort). Similarly, for 
> IPv4/IPv6 
> transition, RFC 4091/4092 (ANAT) defined an alternative solution that 
> was deprecated following MMUSIC and SIPPING WG discssion and 
> consensus 
> at IETF68 (in 2007):
> 
>      http://www.ietf.org/proceedings/68/minutes/mmusic.txt
>      http://www.ietf.org/proceedings/68/minutes/sipping.txt
> 
> Several years have passed and we have been getting more 
> implementation 
> and deployment experience with ICE. However, we have also seen 
> suggestions for alternative solutions, with recent examples including 
> the ALTC draft for IPv4/IPv6 transition and the latching 
> mechanism for 
> NAT traversal:
> 
>      Link to ALTC draft:
>      https://datatracker.ietf.org/doc/draft-boucadair-mmusic-altc/
> 
>      Link to latching mechanism (Section 5.7 in old version 
> of loopback 
> draft):
>      http://tools.ietf.org/id/draft-ietf-mmusic-media-loopback-15.txt
> 
> 
> Alternatives, that generally have a more limited scope than ICE, keep 
> popping up every now and then, and it seems that at least some set of 
> people are not happy with the current ICE solution. So, we 
> would like to 
> understand from the working group if there are issues with 
> ICE and if we 
> need to explore alternative solutions for NAT traversal and/or for 
> IPv4/IPv6 transition.
> 
> Our goal as a standards organization is to enable interoperable 
> products, and having multiple different standards for the 
> same problem 
> or multiple different standards for specific instances of a general 
> problem is not conducive to that. If we have to revisit one of the 
> standards for a given problem space, we ought to be careful and 
> understand what are the issues that we have with that standard. 
> Furthermore, if we are to come with alternative solutions for that 
> problem space, we have to ensure a clear understanding of what has 
> changed since the last time we created the standard, what are the new 
> set of requirements to satisfy, and which of the old requirements no 
> longer apply.
> 
> So, we would like to sense the WG for opinions in this matter
> 
> Thanks
> 
>      Flemming and Miguel (MMUSIC chairs)
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Simon Perreault <[email-masked]>
Date: Thu, 01 Dec 2011 13:18:01 -0500

On 2011-12-01 09:05, [email-masked] wrote:
> As an input to this discussion, I just submitted an I-D identifying some IPv6
> use cases which motivate the need to define a new SDP attribute. These use
> cases cover both multicast and unicast.
>
> The I-D is available at:
> http://tools.ietf.org/html/draft-boucadair-mmusic-ipv6-use-cases-00.

VERY interesting read, thank you.

I think one important thing missing is one small paragraph for each use case 
starting with "ICE(-lite) does not solve the problem because ..."

This information is necessary to conclude that an ICE alternative would be needed.

Thanks,
Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: <[email-masked]>
Date: Thu, 1 Dec 2011 20:00:11 +0100

Hi Simon,

Thank you for reading the draft.

For sure, I can add some text for that purpose: the main argument is ICE-lite MUST respond  to STUN messages. Would it be sufficient to add a pointer to http://tools.ietf.org/html/draft-hutton-mmusic-icemicrolite-02 which explains why a lite "ICE-lite" is needed? 

I will need then to add some text to explain why micro-lite is not sufficient:
* There is no need to adopt the ICE synthax since there is no plan to have ICE in those deployments
* micro -lite uses some dummy values ufrag and password but this is not compliant with RFC5245 (The ice-ufrag and ice-pwd attributes MUST be chosen randomly)
* the SDP offer is lengthy: risk for fragmented SIP packets

Cheers,
Med

________________________________________
De : Simon Perreault [[email-masked]]
Date d'envoi : jeudi 1 décembre 2011 19:18
À : BOUCADAIR Mohamed OLNC/NAD/TIP
Cc : Flemming Andreasen; mmusic
Objet : Re: [MMUSIC] Do We Need an ICE Alternative ?

Thanks,
Simon

---

From: Simon Perreault <[email-masked]>
Date: Thu, 01 Dec 2011 14:14:59 -0500

On 2011-12-01 14:00, [email-masked] wrote:
> the main argument is ICE-lite
> MUST respond  to STUN messages.

Right, this is what I expected.

Why is it a problem that ICE-lite MUST respond to STUN messages?

It has been stated before that the SHA-1 computation is too heavy. Is this the 
problem you're facing?

> Would it be sufficient to add a pointer to
> http://tools.ietf.org/html/draft-hutton-mmusic-icemicrolite-02 which explains
> why a lite "ICE-lite" is needed?

Well, it doesn't exactly answer the question. It says:

    However support for ICE or ICE-
    Lite, which is a subset of ICE, is over complex for scenarios in
    which a transition mechanism is needed without the need to use ICE
    for NAT traversal and connectivity checking.

ICE-Lite too complex? Really? What part is complex?

ICE-Lite is basically ANAT++ bundled with a STUN server.

Simon

---

From: <[email-masked]>
Date: Fri, 2 Dec 2011 09:13:01 +0100

Re-,

What is needed for the use cases described in the I-D is an ANAT++ which is simple, backward compatible, does not increase the length of SDP bodies and does not require connectivity checks at all (some implementers already reported performance issues related to SHA-1 computation, issues with timers, issue with some services such as Fax, interaction between RTP and ICE, etc.). This mechanism must avoid session failure when legacy service elements are involved.

BTW, for the multicast case, if more than one receiver are ICE-enabled, what would be their behaviour?

Cheers,
Med 

> De : Simon Perreault [mailto:[email-masked]] 
> Envoyé : jeudi 1 décembre 2011 20:15
> Objet : Re: RE : [MMUSIC] Do We Need an ICE Alternative ?
>