Trying to get a grip on what's needed for TLS UA-server connections in SIP. Version 1.1 (update)

1. The problem with SIP
outbound
Why we need a half-outbound
oej@edvina.net | 2016-06-10 | v1.1

2. SIP problem
• UAs move to TCP for TLS or for connection
handling over mobile networks
• UAs are behind NAT
• The server needs to reuse the connection to the
client for outbound requests - typically an INVITE to
the UA
• Connection reuse for clients is defined in SIP
Outbound

3. SIP Outbound
• Has a requirement of support of TWO flows
• SIP over websockets RFC ignores this silently
• Is a SIP extension, needs to be advertised
• Adds instance-ID and reg-ID and flow-token
handling
• Only solves initial transactions, doesn’t handle
connection changes during a dialog (not in scope)

4. SIP Outbound
• Presentation:
http://www.slideshare.net/oej/sip2012-outbound
• RFC 5626
https://tools.ietf.org/html/rfc5626

5. RFC 3261 18.1.1

6. What does this mean
• If the contact provided in a registration actually
matches the connection (the IP/port used to set up
the connection) the server can reuse the
connection
• The URI needs to match
• The client needs to keep the connection open

7. What about TLS?
• TLS adds a property to the matching of the URI -
verification of the other end.
• UA verify and validate connection to server
• But how does the server validate the connection to
the UA?

8. SIPit tests
• UAs provided contacts either with SIPS or with
“;transport=tls”
• UAs had no client cert
• Server can not reuse the connection
• “;transport=TLS” is deprecated in RFC 3261
• Only outbound can solve this

9. BUT DEVELOPERS
DOESN’T WANT TO DO
OUTBOUND.

10. Implementations
known to me
• Javascript SIP client libraries have half-outbound
(it’s a requirement for websocket transport)
• Kamailio.org has outbound support in the server
• At least one UA at SIPit claimed support, but it was
not tested
• Any others?

11. Ideas for half-outbound for
TLS
• UA (client) opens TLS connection to server and validates cert
• Client indicates support for “connreuse” as “Supported:” extension in
REGISTER request after connection is setup
• Server is allowed to ignore (as always)
• Client registers to AOR (and authenticates)
• If server answers 200 OK REGISTER with “Require: connreuse” the client is
supposed to manage an open connection
• Server is allowed to reuse connection for outbound SIP requests to the AOR or
associated GRUU (only after successful auth)
• Regardless of contact used in registration (maybe copy websockets
with .invalid)
IDEA

12. Server handling
• If client indicated connreuse and TLS connection
exist, reuse that for outbound requests
• If client close flow, delete registred contact and
connection identifiers from location database

13. Contact URI
• No “;transport=tls” any more
• Maybe re-use “.invalid” contact URI’s from RFC
7118 (SIP over websockets)
• Require GRUU, Record-route or OUTBOUND to
avoid peer-to-peer connection attempts

14. Differences compared to
Outbound
• Only one connection required
• No extra indicators in contact
• No flow identifiers in headers
• No reg-id
• No failover between flows
• New connection can be setup mid-call and used for
new in-dialog transactions
Simplification