[sipcore] Outline of a SIP-DTLS document

[[e-mail] (Dale R. Worley)]

I've written a draft that would be the start of the process of producing
a version of DTLS for edge access in SIP, assembling a set of
requirements.

Do people think this is worth pursuing?  If so, please speak up.  We can
do a preliminary job of assembling requirements, and then send this to
Dispatch for consideration there.

Dale
----------------------------------------------------------------------
[version of 27 March 2016]

A lightweight, secure, scalable edge access protocol for SIP

Introduction

This document describes the requirements for a lightweight, secure,
scalable edge access protocol for SIP.  It is intended for large-scale
SIP networks, where a constellation of redundant edge proxies
maintains flows with hundreds of thousands or millions of user agents.

"Edge access" means that the protocol is a transport protocol intended
primarily for use between user agents and edge proxies.  "Lightweight"
means that the protocol maintains minimal state for each flow between
a user agent and a proxy, thus easing the load on the edge proxies and
minimizing the amount of state that needs to transferred upon proxy
failover.  "Secure" means a level of security similar to that provided
by TLS.

In addition, we require logical structure of the protocol to be fairly
simple, so that it will be broadly implemented.

It is expected that these requirements will be used to design an
adaptation of DTLS for use as a transport for SIP.

Terminology:

Client:  the role of one endpoint of the transport connection,
typically a SIP user agent

Server:  the role of the other endpoint of the transport connection,
typically a SIP edge proxy for a SIP domain

Flow:  an logically-associated series of SIP messages (requests and
responses) between a client and a server

Requirements and non-requirements

REQ:  The protocol is a transport protocol for use in the hop between
a client and server.

Non-REQ:  The protocol need not be symmetric between the client and
server roles.

REQ:  The protocol must have a fairly simple logical structure.

REQ:  The protocol must allow over 1 million flows to be supported by
a single server with current commercial technology.

REQ:  The amount of state the server must maintain for a single flow
must be small, of the size of the state that must be maintained for a
SIP registration.

This allows the flow state for a server to be held in a failover
database of reasonable size.

REQ:  Once a flow is established, passing messages in either direction
must typically require no update to the flow state.

This keeps the update rate of the database proportionate to the rate
of creating and destroying flows, rather than proportional to the
message volume.

Non-REQ:  If a client loses its flow state, reestablishing the flow
may require multiple round trip times.

We assume that if a client loses its flow state, it will also lose any
current dialogs and sessions.  Thus, it does not need to recover flow
state quickly in order to keep current calls alive.

REQ:  The protocol must provide message privacy and integrity.

Non-REQ:  The protocol does not need to provide replay protection.

The use of SIP digest authentication with time-stamped nonces can
provide a substantial degree of replay protection.

REQ:  The protocol must allow authentication of the client to the
server and/or authentication of the server to the client.

REQ:  Authentication credentials (in a single direction) can be either
a certificate or a realm, username, and shared secret.

REQ:  The protocol must allow the client to present a SIP domain to
the server, so that the server can select an appropriate realm to
present to the client.

REQ:  The protocol must allow the server to present a realm to the
client, so that the client can select appropriate credentials to
present to the server, and which the client can use to validate the
credentials presented by the server.

These requirements mirror the dataflow of digest authentication.

REQ:  The protocol's security mechanism must be independent of any SIP
authentication (other than that SIP credentials can be reused for
realm/username/secret authentication, if the devices are configured to
do so).

Non-REQ:  A flow's protocol state may be bound to the client's
transport address as seen by the server (inter alia).

REQ:  If a client's flow becomes invalidated at the server (e.g., due
to a change in the client's public address), the client must be able
to detect this fact quickly (within a few RTTs), so that it can
reestablish a flow quickly to prevent outstanding transactions from
failing.

*** Is this needed?  Is this possible?

REQ:  If a client's flow becomes invalidated at the server due to a
change in the client's public address, the client must be able to
recover in a way that does not invalidate the route set of existing
dialogs.

*** Presumably this requires using GRUUs, which would be specified in
the document.  Is it possible to make this work?

Motivations

In the most recent SIPit interoperability event, SIPit 31 of October
2014, 86% of user agents supported TCP, and 81% supported TLS.  This
is 12 years after RFC 3261 envisioned universal support for both TCP
and TLS in SIP devices.

>From draft-jennings-sip-dtls-01

   There has been considerable discussion of why SIP needs DTLS when we
   have TLS.  This is the wrong question.  The right question is why SIP
   has UDP and TCP (not to mention SCTP).  There are two reasons for
   believing that UDP is likely to be an important protocol in SIP for
   the foreseeable future.

   o  In theory, there is no problem building systems that terminate a
      million TCP connections on a single host.  In practice, the common
      operating systems used for building SIP aggregation devices make
      this impossible.  To date, no one has demonstrated terminating
      over 100k SIP TCP connections to a single host.  Doing that many
      connections with UDP has not been difficult.
   o  If we want to talk about "running code" for SIP, it's UDP.  Unless
      UDP is deprecated for SIP, it is important to provide a reasonable
      level of security for it.

>From Roman Shpount <[e-mail]>
http://mailarchive.ietf.org/arch/msg/sipcore/jjALFjeefA1WjwmVSkv_jAsqsNQ

    Since everyone is talking about how desirable TLS is and how easy it is to
    deprecate UDP, can anybody point me to large scale implementations of
    TLS+Outbound? I know a lot of implementations for UDP which handle 1M+ of
    concurrent registrations. When someone tries to implement the same using
    TLS and Outbound it much harder:

    1. Maintaining large number of TLS connections is resource intensive. If
    you have 1M concurrent registrations you need edge proxies which will
    terminate 1M concurrent TLS connections and respond to keep alive messages.
    This requires 10x number the servers then UDP registrations. This also
    exposes you to more risk of DOS attacks

    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.

    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.

>From Roman Shpount:
http://mailarchive.ietf.org/arch/msg/sipcore/y4E8MTU4tUVHjw7MlZnaMAzuRK8

    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.

>From Roman Shpount:
http://mailarchive.ietf.org/arch/msg/sipcore/Oq5xEUlOJ5eM3Mn9HeHxNUUJX5Y

    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.

References

draft-jennings-sip-dtls-01, "Using DTLS as a Transport for SIP",
C. Jennings, N. Modadugu

Messages from Roman Shpount to the Sipcore mailing list.

RFC 3261

[END]