Subject: Re: [sipcore] sipcore Digest, Vol 84, Issue 5

From: Roman Shpount <[email-masked]>
Date: Fri, 4 Mar 2016 17:02:33 -0500

On Thu, 3 Mar 2016 17:11:53 -0500, Paul Kyzivat <[email-masked]
> wrote:

> On 3/3/16 3:28 PM, Roman Shpount wrote:
> > 2. Fail-over is much harder: For TLS/Outbound you either need to put
> > edge proxy on VM that you can migrate to a different server (still had
> > to deal with software failure). To deal with software failures, you need
> > to design the mechanism for the client to recover the connection to a
> > different edge proxy. If call is in progress this involves for the
> > client detecting the flow failure based on keep alive failure,
> > re-registering to get the gruu, and re-INVITE with new gruu in the
> > contact. If server needs to send a message on the client call while this
> > is happening, it needs to queue this message or implement some sort of
> > non-standard re-transmit timer. This typically means call gets dropped.
> > There is no mechanism at all to recover the transaction which is in
> > progress while outbound proxy fails. For UDP you can move the IP address
> > for the edge proxy to a different server. If registration and flow state
> > is in some sort of shared DB, the fail-over occurs naturally for both
> > the client and server.
>
> Isn't that the point of multiple flows in outbound?
> (Of course that multiplies the number of registrations and TLS
> connections.)
>

Multiple flows somewhat mitigate the problem of edge proxy failure at the
cost of multiplying the cost of connection management. There is still and
issue of temporary network failure between the end point and the proxy. In
case of TLS this terminates all flows from the client to all proxies and
typically terminates the call. And then there is a use case of end point
migrating from one IP to another. Here the quicker flow recovery with UDP
increases the chances of keeping the call running vs 7 or 8 round trips
required to recover the TLS flow (TCP connection setup, TLS connection
setup, registration with response and then re-invite with new GRUU). And
then there is a use case when client used a temporary GRUU which was flow
specific. And there is still no way to recover the transaction since, I
believe, transactions are flow bound.

> > I went through couple of large scale deployments of Outbound with SIPS
> > for large number of consumer devices. In all of them SIP registrations
> > were scrapped and replaced with something proprietary.
> >
> > So, if we are talking about SIP for server to server communications,
> > SIPS is great but it does not need Happy Eyeballs since everything can
> > be provisioned in advance.
>
> If we assume every end device has an outbound proxy, does that mean you
> are saying there is no problem for SIP Happy Eyeballs to solve?
>

I meant that if SIP is used for server to server interconnects. These are
interconnects between devices with capabilities well known in advance
located on well known addresses. When you are interconnecting two service
providers you typically know in advance if IPv6 is used, so there is no
need for Happy Eyeballs.

> If we are dealing with deployments that deal with large end user devices
> > (which is where you need Happy Eyeballs) then a lot of things need to be
> > fixed in SIP Outbound before UDP can be discarded.
>
> What do you mean by "large end user devices"? Do you mean enterprise SIP
> servers, such as for IVR or call center? Or enterprise SIP PBXs?
>

It was a typing mistake. I meant "deployments that deal with large numbers
of end user devices"

Happy Eyeballs is needed to address situation where you have large number
of end user devices located on multiple customer networks with different
capabilities trying to connect to a central public service which is
accessible over both IPv4 and IPv6. The point I am trying to make that all
of such SIP services primarily use UDP so it is too early to discard it.

_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 7 Mar 2016 12:32:00 -0500

Inline.

On 3/4/16 5:02 PM, Roman Shpount wrote:
> <mailto:[email-masked]>> wrote:
>
> Multiple flows somewhat mitigate the problem of edge proxy failure at
> the cost of multiplying the cost of connection management. There is
> still and issue of temporary network failure between the end point and
> the proxy. In case of TLS this terminates all flows from the client to
> all proxies and typically terminates the call. And then there is a use
> case of end point migrating from one IP to another. Here the quicker
> flow recovery with UDP increases the chances of keeping the call running
> vs 7 or 8 round trips required to recover the TLS flow (TCP connection
> setup, TLS connection setup, registration with response and then
> re-invite with new GRUU). And then there is a use case when client used
> a temporary GRUU which was flow specific. And there is still no way to
> recover the transaction since, I believe, transactions are flow bound.
>
> I meant that if SIP is used for server to server interconnects. These
> are interconnects between devices with capabilities well known in
> advance located on well known addresses. When you are interconnecting
> two service providers you typically know in advance if IPv6 is used, so
> there is no need for Happy Eyeballs.

Do you mean interconnect of service providers that have individual 
peering relationships?

What about interconnections between arbitrary enterprises? (Possibly big 
ones.) It seems like there are likely cases there they won't have 
individual agreements.

> It was a typing mistake. I meant "deployments that deal with large
> numbers of end user devices"
>
> Happy Eyeballs is needed to address situation where you have large
> number of end user devices located on multiple customer networks with
> different capabilities trying to connect to a central public service
> which is accessible over both IPv4 and IPv6. The point I am trying to
> make that all of such SIP services primarily use UDP so it is too early
> to discard it.

The obvious problems here are:

1) security
2) large sip messages and UDP message fragmentation

If only (1) were a problem, then maybe the answer would be SIP over DTLS.

But that has never happened. My impression is that it was deemed to not 
be worthwhile because of (2). That it people should jump right to TLS to 
solve both problems at once.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Mon, 7 Mar 2016 12:57:16 -0500

On Mon, Mar 7, 2016 at 12:32 PM, Paul Kyzivat <[email-masked]> wrote:

> Do you mean interconnect of service providers that have individual peering
> relationships?
>

I meant most of the federation type interconnects, including service
provider to service provider, SIP trunks from service provider to
enterprise, and SIP trunks between enterprises. These as well as SIP IP
phones in enterprise are the main deployment scenarios for SIP.

> But that has never happened. My impression is that it was deemed to not be
> worthwhile because of (2). That it people should jump right to TLS to solve
> both problems at once.
>

DTLS is not an answer either since encryption state will need to be failed
over with the edge proxy. What you need is a protocol where client can
recover a flow to the server, including encryption, using a single round
trip.

I think deployments of large numbers of SIP devices connected to the public
service (like SIP based Skype) never happened and will never happen because
of the complexity and design issues of SIP Outbound in combination with
TLS. I think this is why none of the large scale consumer VoIP applications
used SIP. The companies that built these products used RTP, ICE and media
components, but SIP was ignored. I do not think all these companies spent
all the design effort to build something completely new just because they
wanted to build something different. From my experience with couple of
similar projects the issues of scaling the deployment and handling
redundancy were the main driving factors.

Putting aside all the problems with SIP Outbound, there are still a lot of
companies which offer SIP over UDP to the end users. I am talking about all
the hosted PBX solutions. Most of these deployments do not use ICE and use
host based NAT traversal for signaling and media to keep the message size
small. This is not a solution you would design if you have started the
design from scratch, but these installations definitely need a migration
path from IPv4 to IPv6. Telling them to switch to SIPS with SIP Outbound is
unrealistic, so I believe Happy Eyeballs must provide the solution for UDP.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 8 Mar 2016 11:08:44 -0500

On 3/7/16 12:57 PM, Roman Shpount wrote:

> Putting aside all the problems with SIP Outbound, there are still a lot
> of companies which offer SIP over UDP to the end users. I am talking
> about all the hosted PBX solutions. Most of these deployments do not use
> ICE and use host based NAT traversal for signaling and media to keep the
> message size small. This is not a solution you would design if you have
> started the design from scratch, but these installations definitely need
> a migration path from IPv4 to IPv6. Telling them to switch to SIPS with
> SIP Outbound is unrealistic, so I believe Happy Eyeballs must provide
> the solution for UDP.

Then what is the solution for security. ISTM that people are finally 
realizing that it is important.

Is this for the stupid people market?

	Thanks,
	Paul

---

From: [email-masked] (Dale R. Worley)
Date: Tue, 08 Mar 2016 13:41:13 -0500

> redundancy were the main driving factors.

That sounds to me like the requirements for a useful work item.

Dale

---

From: Roman Shpount <[email-masked]>
Date: Tue, 8 Mar 2016 15:06:52 -0500

> realizing that it is important.

You would be surprised -- most of the hosted PBX users do not care or
understand the security related issues. Most of them run their IP phones
with default passwords.

> Is this for the stupid people market?

You might think that but I couldn't possibly comment. I would suggest you
lookup SIP configuration settings for any large Hosted PBX provider and
draw your own conclusion. I cannot think of one of them using SIPS.

The question we need to ask is should we help there providers to transition
to IPv6 or should we try to force them to solve their security issues
first? Keep in mind that current solutions for security related issues will
cost those providers substantial amounts of money and their customer do not
care enough about security to pay extra for it.
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 8 Mar 2016 16:52:05 -0500

On 3/8/16 3:06 PM, Roman Shpount wrote:
> On Tue, Mar 8, 2016 at 11:08 AM, Paul Kyzivat <[email-masked]

I can "sort of" understand doing this behind a corporate firewall.

I guess that would extend to hosted, if that was over a VPN.

Otherwise this is dubious at best.

> You might think that but I couldn't possibly comment. I would suggest
> you lookup SIP configuration settings for any large Hosted PBX provider
> and draw your own conclusion. I cannot think of one of them using SIPS.

Sorry for sounding disrespectful. (I didn't mean you. I was intending to 
pass comment on all who don't seem to care.)

SIPS is another story. It is kind of a mess. But TLS without SIPS is 
possible.

> The question we need to ask is should we help there providers to
> transition to IPv6 or should we try to force them to solve their
> security issues first? Keep in mind that current solutions for security
> related issues will cost those providers substantial amounts of money
> and their customer do not care enough about security to pay extra for it.

I suppose that is fair.

OTOH, we are losing an opportunity to bundle stuff that people should do 
if they weren't so cheap with other stuff they are more motivated to do.

A lot of work went into outbound. It is complicated, but was the best 
anybody could find that could provide security for the last hop for 
those who don't have a certificate. If we knew an easier way we would 
have specified it.

	Thanks,
	Paul