Subject: [Sipping] new draft on ICE for opening SIP dialogs: draft-lowekamp-sipping-ice-for-sip-00

From: "Bruce Lowekamp" <[email-masked]>
Date: Wed, 14 Nov 2007 07:56:38 -0500

Title:             Using ICE to establish SIP Dialogs

Abstract:
This draft explores a way SIP can be extended to allow a new dialog
directly between the endpoints to replace an initial dialog that had
one or more proxies in the signalling path.  This technique relies on
ICE to perform hole punching that allows a direct connection to be
used in deployments where a sip-outbound proxy or SBC is used to
establish SIP connections across NAT or firewall boundaries.  It can
also be used to replace such a dialog with a secure connection
directly between the endpoints.  This technique can be applied to
traditional proxy-based SIP routing as well as to emerging P2PSIP
deployments that lack centrally located proxies.

This draft describes early work that evolved from ideas initially
developed for P2PSIP that are no longer being pursued.  We are
interested in feedback on whether there is broader interest in these
techniques.

Author(s):
Bruce Lowekamp, [email-masked]
David Bryan, [email-masked]

The automatic submission tool failed on this draft, but it's currently
located at
http://www3.ietf.org/proceedings/staging/draft-lowekamp-sipping-ice-for-sip-00.txt

Bruce

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Sat, 17 Nov 2007 01:50:14 -0500

Bruce,

Interesting draft.

My biggest concern is that in practice this would never be utilized in a 
regular SIP proxy chain since it requires every proxy along the path to 
support the mechanism. I wonder if there are intermediate solutions that 
allow path optimization along subsets of the path. Not obvious how to do 
that, but a thought.

It was entirely unclear to me how the e2e TLS connection is 
authenticated. What certificate does each endpoint use? It seems like we 
need something like DTLS-SRTP that exchanges a fingerprint of a 
self-signed cert in the SDP routed through the proxy chain, and that is 
used to drive the e2e TLS connection.

Seems like a big part of the motivation here is in p2psip, to find a way 
to route the initial INVITE tunneled through the DHT, and then later on 
do ICE to optimize this out. The purported reason for this is that call 
setups are faster when the INVITE is tunneled through the DHT. That may 
be true, but I think the difference is irrelevant. In a consumer DHT, 
you'll have nodes all over the world. So each hop through the DHT can be 
pretty long, 100ms+ perhaps. If it takes log hops to get through, for 
any reasonable sized DHT this is between 10 and 20 hops. So you are 
already in the 1-2 second delay range to cross the DHT. ICE itself will 
ideally complete in a few RTT between caller and called party, and thus 
is a small percentage of the overall penalty you already paid traversing 
the DHT. Given that the mechanism in here is a big change in SIP and 
probably ONLY usfeul in the p2psip case (given the comment above on 
limited applicability because each hop needs to support it), I think we 
better understand the real delay improvements associated with it.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   499 Thornall St.
Cisco Fellow                                   Edison, NJ 08837
Cisco, Voice Technology Group
[email-masked]
http://www.jdrosen.net                         PHONE: (408) 902-3084
http://www.cisco.com

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 17 Nov 2007 09:15:19 -0500

I'll also note that tunneling, without SIP ICE, one of the solutions  
mentioned in the draft, would essentially reduce the additional  
latency beyond DHT lookup to zero for the initial INVITE. Re-INVITE  
and BYE would still suffer the penalty, but they are typically less  
time-critical.

I admit that I'm rather worried about the additional complexity  
implied by the approach, given the various interactions of this  
mechanism with, say, outbound. We seem to have difficulties achieving  
interoperability of basic SIP functionality, including TCP and TLS, so  
adding yet more complexity and alternate mechanisms would seem to  
require a fairly careful consideration.

Henning

On Nov 17, 2007, at 1:50 AM, Jonathan Rosenberg wrote:

> Bruce,
>
> Interesting draft.
>
> My biggest concern is that in practice this would never be utilized  
> in a regular SIP proxy chain since it requires every proxy along the  
> path to support the mechanism. I wonder if there are intermediate  
> solutions that allow path optimization along subsets of the path.  
> Not obvious how to do that, but a thought.
>
> authenticated. What certificate does each endpoint use? It seems  
> like we need something like DTLS-SRTP that exchanges a fingerprint  
> of a self-signed cert in the SDP routed through the proxy chain, and  
> that is used to drive the e2e TLS connection.
>
> Seems like a big part of the motivation here is in p2psip, to find a  
> way to route the initial INVITE tunneled through the DHT, and then  
> later on do ICE to optimize this out. The purported reason for this  
> is that call setups are faster when the INVITE is tunneled through  
> the DHT. That may be true, but I think the difference is irrelevant.  
> In a consumer DHT, you'll have nodes all over the world. So each hop  
> through the DHT can be pretty long, 100ms+ perhaps. If it takes log  
> hops to get through, for any reasonable sized DHT this is between 10  
> and 20 hops. So you are already in the 1-2 second delay range to  
> cross the DHT. ICE itself will ideally complete in a few RTT between  
> caller and called party, and thus is a small percentage of the  
> overall penalty you already paid traversing the DHT. Given that the  
> mechanism in here is a big change in SIP and probably ONLY usfeul in  
> the p2psip case (given the comment above on limited applicability  
> because each hop needs to support it), I think we better understand  
> the real delay improvements associated with it.
>
> Thanks,
> Jonathan R.
>
>
> Bruce Lowekamp wrote:

---

From: "Christer Holmberg" <[email-masked]>
Date: Mon, 19 Nov 2007 08:17:54 +0100

Hi,

Some questions.

First, it is true that there may be an intermediate which doesn't need
to be in the path once the call has been established. But, normally is a
reason why a proxy/intermediate insert a Record-Route. Why would they do
that if they at the same time say that it is ok to remove them from the
call path?

Second, in some environments user plane resources are reserved by some
intermediate, and/or gate type-of-functions are controlled by some
intermediate. These resources must be available during the whole call,
but if the resource controlling intermediates are removed from the path,
how will they know when to release the resources? Or, do you assume a
terminal will only once send a "normal" INVITE, resources will be
reserved, and then they will be available "forever"?

Third, you seem to assume that the media path will be end-to-end from
the beginning. But, a B2BUA may also control a media proxy. And, even if
the B2BUA is removed from the signalling path, the media may still
traverse it.

Regards,

Christer

> > Bruce Lowekamp, [email-masked] David Bryan, 
> > [email-masked]
> > 
> > This list is for NEW development of the application of SIP Use 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments of core SIP
> > 
> 
> -- 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Bruce Lowekamp" <[email-masked]>
Date: Thu, 29 Nov 2007 22:34:16 -0500

Thanks for all the feedback.  Sorry to take so long to reply.  I'm
going to reply to all three responses at once, inline.

> allow path optimization along subsets of the path. Not obvious how to do

I think if you had a sequence of proxies that all support this with
the tag in their header, it would be possible to do it; I would think
it should be a somewhat different mechanism where the proxies simply
collectively decide to start routing the same dialog over the direct
path.  But I am unsure how common such a long chain of proxies would
be and am concerned about the complexity of implementing it.  It would
be interesting to work out what would be involved, though.

> used to drive the e2e TLS connection.

I think that allowing the end-to-end encryption is a pretty
interesting use, but you're right, I completely ignored
authentication, primarily because I was hesitant to specify a
particular mechanism.  SRTP would be a great way of handling it, and
is probably the most implementable, but I didn't want to ignore
leap-of-faith or some central authority that the two endpointsb both
trust.

> better understand the real delay improvements associated with it.

We should probably move this to p2psip if we get into too much detail,
but I think my thoughts on the cost are along the lines of Henning's.
If you do ICE across the DHT to open the SIP dialog, then send an
INVITE and do ICE to establish the media, you have paid the around the
overlay latency for the SIP connection, ICE for the SIP connection,
and then the direct ICE for media.  If you route the INVITE around the
overlay first, you have media flowing after the around the overlay
latency and first ICE negotiation.  So  you have media in one ICE
negotiation latency shorter time if you do the INVITE tunneled across
the overlay.  Then you can pay the cost of moving the dialog in the
background where the user doesn't perceive it.

I think there are some optimizations that can be applied to both
approaches in terms of pre-advertising candidates, but there are a lot
of open issues there, so I'd rather stick with the straightforward
approach for now.

> require a fairly careful consideration.

I agree the complexity is an issue.  I think in terms of evaluating
the complexity, I'm willing to ignore the complexity of ICE because I
will assume implementors already have ICE for media.  The question is
of adding such negotiation for SIP.  I don't believe it's that
terribly complex (all the parts are already there, they just need to
be connected), and it has the virtue that the new dialog is being
created separately and the worst that will happen is that it won't be
established, so the replacement never occurs.  If it's just being
established as an optimization, nothing is lost and the UA doesn't
really have a particualr reason to notice or care.

Is the complexity that is there worth it?  The end-to-end security
scenario is, to me, one of the more convincing scenarios where it
achieves a benefit that is hard to achieve otherwise.  In terms of
removing proxies from dialogs as an optimization, I haven't done any
calculations or measurements, but I think it's an interesting question
how much load can be removed from proxies such as sip-outbound
deployments, especially in terms of offloading things such as
subscriptions that require periodic updates.

> that if they at the same time say that it is ok to remove them from the

I think the most important reason would be if the proxy is there for
NAT or firewall traversal, but not to accomplish a call-management,
policy, billing, etc roll that requires it to be on-path for the
dialogs.  I think the clearest example of this is a single
sip-outbound proxy, which is deployed solely to facilitate NAT
traversal, but really has no interest in monitoring ongoing dialogs,
just helping to establish them.

> reserved, and then they will be available "forever"?

It was important to us that we preserve the ability of a proxy to
remain in the route if it desires, although for maximum efficiency, it
seems like it's usually best to establish a direct end-to-end
connection.  I'm unsure about the "forever" aspect of this. We
deliberately left the concept of "use this new flow for future dialogs
between these two UAs" as an open issue.  That's a clear gain in
efficiency (especially for non-dialog exchanges such as MESSAGE), but
I think it would require all of the proxies on the route (not just the
record-route proxies) to agree to authorize it.

> the B2BUA is removed from the signalling path, the media may still

Sorry, certainly didn't mean to imply that.  Obviously if a b2bua
feels it needs to be on-path for media and there is no direct path, it
seems unlikely that the SIP connection could be direct.

Bruce