Subject: [sipcore] "Roman's problem"

From: [email-masked] (Dale R. Worley)
Date: Wed, 16 Mar 2016 13:40:15 -0400

Going over Roman's messages regarding hosted PBX systems, I want to
isolate that usage situation from the rest of Happy Eyeballs.  It seems
like the problems there are seperable from what Happy Eyeballs needs to
solve.  No doubt SIP endpoints in a hosted PBX situation need Happy
Eyeballs also, but rapid failover does not involve the endpoint trying
alternative transport destinations.  (Happy Eyeballs is involved in the
endpoint selecting a transport destination to contact initially, but
presumably H.E. will allow the endpoint to continue to use that one
destination as long as it is responding.)

I've extracted parts of a number of messages that characterize the
situation and put them at the end of this message.  The summary of the
situation seems to be:

----------
Failover is done by moving the edge-proxy IP address to the backup endge
proxy and using a protocol without connection state, i.e., UDP
without DTLS.

The registration state is stored in a database shared by all edge
proxy instances.  There need be no dialog state in the edge proxies,
and transaction failure during failover is acceptable.

Digest authentication nonces can be constructed to be verifiable by
any edge proxy.

NAT traversal is handled by NAT compensation done by the edge proxy
rather than ICE (thus keeping messages small enough for UDP).

The unsolved problem is security:
- message integrity
- message privacy
without requiring connection state.
----------

Nonces can be constructed by the edge proxies in a way that doesn't
require connection state to check their validity.  E.g.,

    nonce = T || R || H(T || R || PK)

where

    T = timestamp
    R = random value
    PK = private key known by all the edge proxies

Security seems to be more of a problem in that all of the security
protocols I know of require connection state.  However, it shouldn't be
difficult to construct an adequate security protocol.  E.g., assuming
the phone and the proxies have a shared key SK for a user identity U,
one could encrypt a message via:

    encrypted message = "@" || U || MD || E(MK, message)

where

    message digest (MD) = H(message)
    message key (MK) = H(U || MD || SK)
    U = fixed-length user identity
    "@" is chosen as a flag because no SIP message can begin with "@"

That should provide sufficient message integrity and privacy.  Or more
likely, a considerably better scheme could be devised by someone who
knows encryption algorithms.  But we only need a stateless security
mechanism that's much better than Digest authentication.

Dale
----------------------------------------------------------------------
I know a lot of implementations for UDP which handle 1M+ of concurrent
registrations.

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.

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

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.

---

From: Roman Shpount <[email-masked]>
Date: Wed, 16 Mar 2016 14:08:47 -0400

This looks correct. The reason I brought this scenario up in relationship
with Happy Eyeballs is to make sure that Happy Eyeballs works with UDP for
initial call setup. There was a discussion of dropping UDP support in Happy
Eyeballs compliant end points. You are correct, that once the initial
registration is established, Happy Eyeballs does not need to be involved,
but this entire scenario relies on using UDP based SIP.

One small correction: In such a setup scenario, if edge proxies are
stateless and proxy fail-over takes less then 32 sec (Timer B), event SIP
transactions would normally survive an edge-proxy fail-over.

Regards,
_____________
Roman Shpount

On Wed, Mar 16, 2016 at 1:40 PM, Dale R. Worley <[email-masked]> wrote:

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Roman Shpount <[email-masked]>
Date: Wed, 16 Mar 2016 14:48:09 -0400

>> situation and put them at the end of this message.  The summary of the
As far as encryption is concerned, do you expect it to replace Digest or to
be used concurrently with it? i would assume there is no reason to run
digest in parallel with encryption.

If you want to use it to replace Digest (there is no reason why it should
not), encrypted message should include nonce. Presence of nonce will allow
to prevent message replay.

How would responses or messages from the server to the client going to be
encrypted?

My suggestion would be a bit more complex:

1. Client starts by sending a setup message with crypto capabilities

2. Server sends a response with server crypto capabilities, nonce and
connection specific server public key (nonce can contain information
regarding which specific server key is used for this connection). This
message should be signed using server public certificate

3. Send the registration message from the client to the server encrypted
with server public key. Include user identity, nonce, client public key and
message digest signed with user shared key.

4. On the proxy side store connection specific server private key, client
public key and crypto capabilities in the same DB as registration
information.

This protocol should provide sufficient security including server
certificate validation, replay protection, forward secrecy one registration
is torn down. On the other hand it will have the same connection recovery
properties.

Regards,
_____________
Roman Shpount

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 17 Mar 2016 12:11:22 -0400

> public key and crypto capabilities in the same DB as registration

It struck me that the central problem was encryption without maintaining
connection-specific encryption information.  If we're willing to
maintain that, presumably DTLS would work.  I don't know much about
DTLS, though -- do you think that UDP/DTLS would be a sufficient
solution to the use cases we are discussing?

Dale

---

From: [email-masked] (Dale R. Worley)
Date: Thu, 17 Mar 2016 12:18:30 -0400

> transactions would normally survive an edge-proxy fail-over.

My concern about transaction failure is this:

UAC sends request
edge-proxy 1 forwards request to UAS, retaining transaction state
edge-proxy 1 fails
edge-proxy 2 replaces edge-proxy 1
UAS sends response to edge-proxy 2
edge-proxy 2 has no transaction state to match the response and discards it
UAS resends response to edge-proxy 2
...

I'm sure that the real scenario is more complicated than that, but
there's a general problem if the edge-proxy, or any proxy in the chain,
is transaction-stateful, and you generally want proxies to be
transaction-stateful.

But I think we're OK in practice, in that real UAs are resistant to
transaction failure, transaction failures degrade the user experience
but the user can easily recover from it.  And transaction failure will
be quite uncommon.

Dale

---

From: Roman Shpount <[email-masked]>
Date: Thu, 17 Mar 2016 12:22:47 -0400

> is transaction-stateful, and you generally want proxies to be

It is quite common (especially when solutions are designed for scale) that
entire proxy stack is stateless or carries relevant state in via or route
headers.

> but the user can easily recover from it.  And transaction failure will

The main transaction failure recovery issue is recovery of initial INVITE
transaction. This transaction is often long (waiting for remote party to
pick up) and user experience can be inconvenient (call was picked up and
dropped), especially if early media is used (started to talk to the person
and got dropped).
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Thu, 17 Mar 2016 12:28:36 -0400

> solution to the use cases we are discussing?

There is some shared state which would be inherently present and shared
between the edge-proxies. Typically it is client user ID and specific
IP:port on which they are registered. As long as client specific state is
clearly identified and can be easily shared without too many shared DB
updates (you do want to avoid updating shared DB on each UDP message sent
or received), UDP based solution can be implemented. I think DTLS
definitely needs to be investigated regarding state sharing. Part of the
problem is that DTLS is fairly complex all inclusive protocol with multiple
key negotiation, encryption and handshake schemes. It might need to be
restricted to allow state sharing. Also, none of the common DTLS
implementations, such as OpenSSL, provide support for such state sharing.

Also, the amount of stored state can be reduced if signed nonce is used
with each transaction. For instance server can provide client with
encryption key ID in the nonce and sign it, instead of keeping this ID in
the per connection storage. This is something not supported with DTLS.

This is definitely something that requires further investigation, but I
think the right way to do this is to start with DTLS and see if it can be
adapted or improved for connection fail-over scenario.
_____________
Roman Shpount

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 18 Mar 2016 16:23:38 -0400

> adapted or improved for connection fail-over scenario.

I agree that the things you've suggested for SIP/DTLS could be quite
useful.  And in my brief study of RFC 5246 I've spotted some items that
need to be addressed.

I looked at draft-jennings-sip-dtls-05, but it is very brief and does
not address any of the concerns.  I know that it did not progress to an
RFC, but I don't know why.  I wonder if we should organize an effort to
construct SIP/DTLS to be used in these situations (UA to edge proxy),
with identification of the requirements, usage scenarios, etc.

Dale