Subject: [sipcore] ;transport=tls

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 12 Feb 2015 08:02:16 +0100

I just wanted to forward an issue discovered at SIPit 31 that I don't think has been discussed here recently. Correct me if I'm wrong. 

From the summary at https://www.sipit.net/SIPit31_summary

"TLS focused testing showed that the use of 'transport=tls' in Route,
Record-Route, and Contact header fields is still pervasive, if not universal.
The arguments against it in RFC5630 (was draft-ietf-sip-sips) are not
compelling to implementers and deployers. Several participants pointed to the
inconsistency of those arguments with the tokens that appear in Via headers
registered at
<http://www.iana.org/assignments/sip-parameters/sip-parameters.xml#sip-transport>.
SIPCORE should consider whether to re-instate transport=tls or provide stronger
documentation for how to indicate TLS over TCP in those header fields when it
is necessary to do so. "

In addition, many implementors added ";transport=tls" to their contact at registration.
They did not understand that if they do, the SIP URI in the contact has to match a certificate provided
when the server connects to their UA. For registrations both me and Robert pointed
with all our available hands to SIP Outbound.

I guess that before we can deprecate SIPS: we need to go through this and clarify
a bit.

In the networks I build we frequently use ;transport=tls to tell the software used (Kamailio)
to select a TLS transport for the next hop. SIPS: is not an alternative here as it
affects headers. We have not found any other option.

/O

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 19 Feb 2015 10:44:36 +0100

Hello friends,
One week ago I sent this message and have seen no comments. I still may be wrong, but if not, I think this is an issue that requires further thought.

One of the reasons for bringing this up was a note in the SIPconnect 2.0 specification about MUST NOT use ;transport=tls that caught my eye. This requirement doesn't work well with the implementations we tested at SIPit and there
was a lot of discussions around it. While SIP Outbound may solve the first hop, it doesn't tell me how I can use a URI in a route set or configuration that implies TLS as a transport without using SIPS:

/O

Begin forwarded message:

> From: "Olle E. Johansson" <[email-masked]>
> Subject: ;transport=tls
> Date: 12 Feb 2015 08:02:16 GMT+1
> To: SIPCORE <[email-masked]>
> Cc: Olle E Johansson <[email-masked]>
>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 26 Feb 2015 12:13:46 +1100

I really don't know what there is to comment on. How about you try and explain what problem you are trying to solve and why the existing mechanism don't solve that problem. 

You email sort of of comes across as "our software uses stuff that was deprecated 10 years ago and we are sad". 

> On Feb 19, 2015, at 8:44 PM, Olle E. Johansson <[email-masked]> wrote:
> 
> Hello friends,
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 26 Feb 2015 07:52:53 +0100

Like I said in my mail, we frequently use ";transport=TLS" to indicate tls for the next hop in Kamailio.
It's a transport in via, but no longer approved in route headers.

How would you indicate a need for TLS in Path/Route and similar headers that needs a SIP URI?

I think we may need to produce a draft that 
- finally kills SIPS:
- solves the problem how to indicate a requirement for TLS in a SIP URI. RFC 5630 avoided this issue.

We may also need to produce a BCP covering how to do TLS in the SIP protocol, since
there are many documents, some quite contradicting and some underspecified that
talk about TLS and SIP. It's a maze of twisting passages you easily get lost in, which
was clearly indicated at SIPit. A hitchhiker's guide to TLS and SIP if you like.

If there is a solution, that you produced 10 years ago, implementations show that you did a lousy
job of telling people, Cullen :-)

/O

---

From: Robert Sparks <[email-masked]>
Date: Wed, 25 Feb 2015 23:09:07 -0800

So, there really _is_ tension between specification and implementation 
here - it's not just Kamailio - there is a lot of ;transport=tls showing 
up on the wire.

I _think_ we can break it down into two classes of use:

1) The first (or last) hop - where outbound is the the standardized 
answer (but there are things that really want to say they can use TLS 
over that hop, but aren't able to speak of themselves with DNS names).

2) middle-to-middle hops. IIRC, the standardized answer is using RR with 
sips:, but the notion of using sips: as a hop-hop indication without 
forcing sips' e-e behavior is really not well understood in 
implementation. There is some tension here still with things that can't 
speak of themselves with a DNS name, but it's a much smaller part of the 
population.

Olle's question is rooted in 2) more than 1).

Olle - what else am I forgetting?

RjS