Subject: [Sip] RE: [BEHAVE] Re: ICE deployment data before LC for RFC

From: [email-masked] (Juha Heinanen)
Date: Thu, 19 Jul 2007 09:14:29 +0300

a while back i read ice tutorial slides and my impression was that the
protocol was very complex (pity implementers) and provided only a bit
better nat traversal capability than what [open]ser/rtpproxy/mediaproxy
have been offering to lots of users for years already.

because of this (complexity, little added value), i doubt that full ice
will be widely implemented or used.  i don't have any opinion on if ietf
should publish the spec or not though, because there are already so many
irrelevant rfcs out there that one more doesn't make any difference.

-- juha

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Thu, 19 Jul 2007 09:43:17 +0300

[As Cullen pointed out, this is better located on MMUSIC. Thanks.]

> have been offering to lots of users for years already.

Media proxying is totally broken for a bunch of different reasons:

1/ Like many SIP ALGs - it screws the signaling when it does not understand 
something. Last time I tried OpenSER media proxying, TCP/COMEDIA sessions did 
not work at all (even with public unfirewalled IPs on both endpoints).

2/ At least mediaproxy implementation does not scale at all. It might be good 
if one's business consists of selling relay boxes. That's an implementation 
issue however.

3/ It is totally fatally insecure by design. It is trivial to DoS, or worse, 
hijack, a media flow by sending fake RTP probe packets to the relay.

> irrelevant rfcs out there that one more doesn't make any difference.

3/ ICE is secure: no voice hammer, no media hijacking.

2/ ICE scales well as it puts the hard work on the endpoints (and usage of 
TURN may be limited to worst cases).

1/ ICE does not screw up the SIP signaling, and you do not need to buy a SIP 
server upgrade to support the next SDP extension.

In all due fairness, simple hole punching also has advantages 1 and 2 over 
media relaying. And it is about as secure as SIP without any traversal 
mechanism, which is to say, less secure than ICE, but much more secure than 
media relaying.

Regards,

-- 
Rémi Denis-Courmont

---

From: Jan Janak <[email-masked]>
Date: Thu, 19 Jul 2007 14:29:25 +0200

> have been offering to lots of users for years already.

 The NAT traversal algorithm implemented in [open]ser, rtpproxy, and
 mediaproxy had been developed long before the first version of the ICE
 draft; at that time no other solution existed (except for preliminary
 STUN and TURN drafts), and we needed something to make it work; in
 addition to that NAT traversal support in UA was virtually non-existent
 back then.

 Having said that, it is true that the algorithm implemented in
 [open]ser is simpler than ICE, but I believe that these two cannot
 be directly compared. Even the NAT traversal logic in SER can get
 pretty complex if none of the end-points is a PSTN gateway in the
 public internet (especially if you want to handle re-INVITEs and
 serial forking properly).

   Jan.

---

From: Jiri Kuthan <[email-masked]>
Date: Thu, 19 Jul 2007 16:45:59 +0200

> serial forking properly).

I don't think it is a question whether ICE is complex or not. The question
is if the complexity is worth it. An argumentation line one can choose is
the e2e principle which justifies the load of software loaded in the
end-devices (think for example of TCP) to gain reliability.

If ICE can accomplish the reliability promise, it also helps to migrate away 
from media relays (which is what SER does using rtpproxy) , which is a good thing.

So I think that the right course of action is that folks doubting ICE reliability
make their case (by that I mean specific arguments rather than emotional debates 
about red-colored nails and other hardware).

-jiri

--
Jiri Kuthan            http://iptel.org/~jiri/

---

From: "David Barrett" <[email-masked]>
Date: Thu, 19 Jul 2007 11:05:57 -0700

> -----Original Message-----
> From: Jiri Kuthan [mailto:[email-masked]]
> Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE deployment databefore
> LC for RFC
> 

Er, my "specific argument" is "until it's been proven to work, it hasn't
been proven to work".  It's tautological, but no less true for it.

Indeed, if you're *not* doubting ICE, why aren't you?

-david

---

From: Jiri Kuthan <[email-masked]>
Date: Sat, 21 Jul 2007 16:47:52 +0200

>Indeed, if you're *not* doubting ICE, why aren't you?

Hi David,

I'm not entirely sure what is the step you are suggesting?

I think ICE is architecturally right answer to the right problem.
Notwithstanding that, there are certainly some things I prefer
differently (e.g., the infamous debate about proactive hole punching)
or may turn out to be bugs. I think though that the key problem at
this point is of institutional nature. In the IETF language, "hasn't
been proven to work" is adequate to "lacking running code" and this
appears to be a phenomen which is indeed occuring in the IETF and
is not unique to ICE.

The question is how to get this fixed?

Some other standardization bodies enjoying the amount of contributions
and complexity as the IETF is enjoying now (S in SIP does not really
stand for Simple), proceed with 'after-fact filters', in that they
produce the initial specs faster and later produce 'profiles' which
separate what has proved and what less. Plus -bis versions are produced
for whatever appears worth puttting effort in it (i.e., for which there
is running code and field evidence of improvement need).This could be 
an approach  which may be more feasible in today's IETF's dimension than 
trying to get back to historical roots.

-jiri

---

From: "Henry Sinnreich" <[email-masked]>
Date: Sat, 21 Jul 2007 10:10:10 -0700

I fully agree with Jiri that this is an IETF problem and not an ICE
problem.
ICE-17 is a great document, no doubt about it.

What happens however of someone finds an innovative approach that may
work better? Will it be rejected because it will not be RFC standards
compliant?

What could an innovator tell customers about a solution that works
better but is not IETF ICE RFC standards compliant?

Henry

-----Original Message-----
From: Jiri Kuthan [mailto:[email-masked]] 
Sent: Saturday, July 21, 2007 9:48 AM
To: David Barrett; 'Jan Janak'; 'Juha Heinanen'
Cc: [email-masked]; [email-masked]
Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE
deploymentdatabefore LC for RFC

At 20:05 19/07/2007, David Barrett wrote:
>> make their case (by that I mean specific arguments rather than
emotional
>> debates

Hi David,

-jiri

---

From: Jiri Kuthan <[email-masked]>
Date: Mon, 23 Jul 2007 22:37:31 +0200

>work better? Will it be rejected because it will not be RFC standards

I don't think so, IETF is having a history of working on competing standards,
jabber and simple being a prominent and recent example thereof. I think that's
actually with current IETF's size and dynamics a fairly good strategy to
eliminate single points of failure. 

-jiri

---

From: "Henry Sinnreich" <[email-masked]>
Date: Tue, 24 Jul 2007 13:48:34 -0700

Adam,

I fully agree with your positive assessment of the ICE-17 document.

Do you by any chance plan to also develop a test tool for testing the
NAT environment and the success/failure cases, connection times, etc.,
to measure results?

Or maybe you know someone who does?

Thanks, Henry

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam
Fisk
Sent: Tuesday, July 24, 2007 3:08 PM
To: Jiri Kuthan
Cc: Henry Sinnreich; David Barrett; Jan Janak; Juha Heinanen;
[email-masked]; [email-masked]
Subject: Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE
deploymentdatabefore LC for RFC

I've followed ICE development on the sidelines for years now, and I'm
currently implementing ICE 17.  I've implemented what will be open
source implementations of STUN and TURN, both client and server.  Here
are the key points I've taken away from that experience: 

1) The patience of Jonathan and everyone else in meticulously getting to
the current draft is astonishing.
2) ICE is complex as hell and a pain in the ^#* to implement.  I was
surprised at how hard it was, particularly for a draft that's so close
to becoming an RFC. 
3) ICE is solving a very tricky problem.

I like Phillip's earlier suggestion that the draft stay in the "almost
done" state like used to happen in the Routing group.  I realize that's
asking a lot given how much work has gone into it and how eager everyone
is to finalize it.  I think the problem is that standardizing NAT
traversal is just hard, and hard problems are difficult to make simpler.
In my implementation of ICE, I do think it could be done more simply,
but I don't have concrete suggestions right now because I'm still
pulling my hair out with the implementation.  I'm not talking about
drastic changes anywhere, but all the checklist fiddling sure takes a
lot of patience to write.  Simplifications might just be in the
description and not necessarily the algorithm. 

I think it's a hard enough and important enough problem that we owe it
to ourselves to be even more patient with an "almost done" state that
adds the final touches based on real-world feedback.  I don't doubt for
a second that ICE works, but it's so complex that I worry no one outside
huge companies will ever implement it.  That would be a huge hindrance
to ICE's adoption and power. 

-Adam

---

From: "Adam Fisk" <[email-masked]>
Date: Tue, 24 Jul 2007 16:07:32 -0400

I've followed ICE development on the sidelines for years now, and I'm
currently implementing ICE 17.  I've implemented what will be open source
implementations of STUN and TURN, both client and server.  Here are the key
points I've taken away from that experience:

1) The patience of Jonathan and everyone else in meticulously getting to the
current draft is astonishing.
2) ICE is complex as hell and a pain in the ^#* to implement.  I was
surprised at how hard it was, particularly for a draft that's so close to
becoming an RFC.
3) ICE is solving a very tricky problem.

I like Phillip's earlier suggestion that the draft stay in the "almost done"
state like used to happen in the Routing group.  I realize that's asking a
lot given how much work has gone into it and how eager everyone is to
finalize it.  I think the problem is that standardizing NAT traversal is
just hard, and hard problems are difficult to make simpler.  In my
implementation of ICE, I do think it could be done more simply, but I don't
have concrete suggestions right now because I'm still pulling my hair out
with the implementation.  I'm not talking about drastic changes anywhere,
but all the checklist fiddling sure takes a lot of patience to write.
Simplifications might just be in the description and not necessarily the
algorithm.

I think it's a hard enough and important enough problem that we owe it to
ourselves to be even more patient with an "almost done" state that adds the
final touches based on real-world feedback.  I don't doubt for a second that
ICE works, but it's so complex that I worry no one outside huge companies
will ever implement it.  That would be a huge hindrance to ICE's adoption
and power.

-Adam

---

From: Jiri Kuthan <[email-masked]>
Date: Tue, 24 Jul 2007 23:25:04 +0200

At 22:07 24/07/2007, Adam Fisk wrote:
>I've followed ICE development on the sidelines for years now, and I'm currently implementing ICE 17.  I've implemented what will be open source implementations of STUN and TURN, both client and server.

That's marvellous news -- can you send me a pointer to that?

>  Here are the key points I've taken away from that experience: 
>
>1) The patience of Jonathan and everyone else in meticulously getting to the current draft is astonishing.
>2) ICE is complex as hell and a pain in the ^#* to implement.  I was surprised at how hard it was, particularly for a draft that's so close to becoming an RFC. 

All three points are wholeheartly easy to agree with. I would have added too
ICE is the "right" solution.

The question to me is whether Mr. Time and Mr. $ are not against us. That question
was asked couple of meetings ago by Spencer D. in an 'sbc bar bof' -- basically 
fingerpointing at the NAT experience, "right" solution (IPv6) and the outcome. 
The concern is that by time we have ICE, everyone will have the problem solved 
using media relays and mass economy will make it a more viable solution than anything 
else.

Future is generally hard to predict (that's why analysts like to predict past :-)),
so I think it would be at least a proper step to document current practices (media
relays) so that the IETF's picture stays grounded (whatever the risky comeout of work 
on "right" solutions may be.)

-jiri

---

From: "Adam Fisk" <[email-masked]>
Date: Wed, 25 Jul 2007 10:00:21 -0400

We do plan on doing that eventually, Henry, but it will be awhile.  We're a
2 coder shop, so these things take us forever, but we will definitely do
that at some point.  It just might not be in 2007, honestly, so it would
likely be too late to be useful for the WG.

-Adam

On 7/24/07, Henry Sinnreich <[email-masked]> wrote:
> Do you by any chance plan to also develop a test tool for testing the NAT
> environment and the success/failure cases, connection times, etc., to
> measure results?
>
>
>
>  ------------------------------
>
> *From:* [email-masked] [mailto:[email-masked]] *On Behalf Of *Adam
> Fisk
> *Sent:* Tuesday, July 24, 2007 3:08 PM
> *To:* Jiri Kuthan
> *Cc:* Henry Sinnreich; David Barrett; Jan Janak; Juha Heinanen; [email-masked];
> [email-masked]
> *Subject:* Re: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICE
> asking a lot given how much work has gone into it and how eager everyone is
> to finalize it.  I think the problem is that standardizing NAT traversal is

---

From: "Frank W. Miller" <[email-masked]>
Date: Wed, 25 Jul 2007 21:04:43 -0600

For those that may not know, another example of this is IAX2 which is
currently under review for publication by the IETF.  This protocol
clearly competes with SIP at least on some fronts.  It may be difficult
for new protocols to emerge, particularly with there is such huge
momentum behind one, but it can happen.

FM

-----Original Message-----
From: Jiri Kuthan [mailto:[email-masked]] 
Sent: Monday, July 23, 2007 2:38 PM
To: Henry Sinnreich; David Barrett; Jan Janak; Juha Heinanen
Cc: [email-masked]; [email-masked]
Subject: RE: [MMUSIC] Re: [Sip] RE: [BEHAVE] Re: ICEdeploymentdatabefore
LC for RFC

>work better? Will it be rejected because it will not be RFC standards

I don't think so, IETF is having a history of working on competing
standards,
jabber and simple being a prominent and recent example thereof. I think
that's
actually with current IETF's size and dynamics a fairly good strategy to
eliminate single points of failure. 

-jiri

>>> So I think that the right course of action is that folks doubting
ICE
>>> reliability

---

From: "Adam Fisk" <[email-masked]>
Date: Thu, 26 Jul 2007 16:51:58 -0400

On 7/24/07, Jiri Kuthan <[email-masked]> wrote:
> implementations of STUN and TURN, both client and server.
>

We're not quite public yet, Jiri.  I'll send a note to the list when we're
up, though.

-Adam