Subject: Re: [sipcore] ;transport=tls

From: Cullen Jennings <[email-masked]>
Date: Tue, 3 Mar 2015 10:27:32 -0700

> On Feb 25, 2015, at 11:52 PM, Olle E. Johansson <[email-masked]> wrote:
> 
> 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:

Why? It's dead and nothing the IETF can write on this will have any impact beyond what they have already said in RFC 5630. Perhaps sipit needs to tell people to read this but not clear anything we write will be read any more than 5630 is read. I have seen literally thousands or very real SIP deployments and I'm not seeing a single one of them use SIPS so I'm not seeing some huge problem here that somehow causing problems with the adoption IETF standards. 

> - solves the problem how to indicate a requirement for TLS in a SIP URI. RFC 5630 avoided this issue.

(Keep in mind I argued for keeping ";transport=TLS" but ignoring that) ... I think the way to make progress here is to state what the problem is that you think drives the needs for "how to indicate a requirement for TLS in a SIP URI". "how to indicate a requirement for TLS in a SIP URI" is more of a solution that requirement or use case. Last time this was looked at, some people felt that NAPTR or just policy config in proxy was enough and there was not a need to do it in a URI. 

So to try and help you, let me tell you what I suspect the problem is you are trying to solve. Proxies have dial plans that match some pattern on destination then suggest route to next hop. So you might say things that are going to a phone number of +1* get routed to sip.att.com as next hop. Some people wanted to be able to tell the proxy to send SIP traffic to att over TLS. Some people wanted to be able to tell the proxy to send over ipv6. So lets start with the obvious, that AT&T can control what they accept and what their preferences are using DNS (NAPTRY, SRV, A, AAAA). Here we are only talking about the proxies policy for what it wants to do assuming it will ignore att preferences. One solution would be to have the destination route URI have a flag in it saying use v6 such as "sip:sip.att.com;usev6=YES". Another solutions would be just have a flag in the internal data structure for the proxy that said that use_v6 is true. Similarly one can indicate TLS by either putting the flag in the destination URI or putting the flag in the same data structure that stores the destination URI. But here is the important point - this is an issue local to the proxy. Once the calls makes it to att, it will be over v6, or not, or tls and nothing about what the previous proxy policy matters. This whole thing is not really a matter of standardization - the proxy can implement it in the URI or not in the URI or whatever. People argued that trying to embed all possible proxy policy into a standardized URI just seemed like a bad plan. 

So is there a problem different from that which needs to be solve here ?

> 
> We may also need to produce a BCP covering how to do TLS in the SIP protocol, since
(just one note BCP are not really this - it would likely be an informational doc ) 
> there are many documents, some quite contradicting and some underspecified that

Could you point out some the the specific stuff where they are contradicting? That would be low hanging fruit to fix. 

> 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
> 
> On 26 Feb 2015, at 02:13, Cullen Jennings <[email-masked]> wrote:
> 
>> 
>> 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,
>>> 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]>
>>>> 
>>>> 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
>>> 
>>> _______________________________________________
>>> sipcore mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/sipcore
>>> 
>> 
> 
>

---

From: Robert Sparks <[email-masked]>
Date: Tue, 03 Mar 2015 11:51:08 -0600

On 3/3/15 11:27 AM, Cullen Jennings wrote:
> Why? It's dead and nothing the IETF can write on this will have any impact beyond what they have already said in RFC 5630.
Cullen -

Where in RFC 5630 do you derive "It's dead" from?

It's full of text talking about continuing to use sips:

Please skim section 5 right quick and note all the clarifying 
requirements on how to use sips:

But, assuming we can derive from this document how to behave if we 
_don't_ want to use sips:, it would help if you pointed to exactly where 
in 5630 you find the best answer for how to populate URIs in a Path or 
Service-Route header that you want to ensure use TLS.

The end of section 3.1.3 is (I think) relying on the proxy having 
existing state to refer to in order to remember that the sip: URI it 
provided is associated with a connection that happens to be using TLS. 
That won't help a proxy dealing with a Path or Service-Route.

Below you suggest people use DNS names and rely on NAPTR, but where in 
the document do we give this advice? The string NAPTR does not appear in 
the document afaict.

Note also that 3.1.4 still leaves transport=tls in an undefined state.

> Perhaps sipit needs to tell people to read this but not clear anything we write will be read any more than 5630 is read. I have seen literally thousands or very real SIP deployments and I'm not seeing a single one of them use SIPS so I'm not seeing some huge problem here that somehow causing problems with the adoption IETF standards.

> (Keep in mind I argued for keeping ";transport=TLS" but ignoring that) ... I think the way to make progress here is to state what the problem is that you think drives the needs for "how to indicate…
Lets try the Path and Service-Route part for that.
Ole - what breaks if you require people to put in DNS named URIs here 
that will use NAPTR to indicate TLS is the only thing that should be used.
(Also, please do reply to Cullen's question below)
>
> So to try and help you, let me tell you what I suspect the problem is you are trying to solve. Proxies have dial plans that match some pattern on destination then suggest route to next hop. So you might say things that are going to a phone number of +1* get routed to sip.att.com as next hop. Some people wanted to be able to tell the proxy to send SIP traffic to att over TLS. Some people wanted to be able to tell the proxy to send over ipv6. So lets start with the obvious, that AT&T can control what they accept and what their preferences are using DNS (NAPTRY, SRV, A, AAAA). Here we are only talking about the proxies policy for what it wants to do assuming it will ignore att preferences. One solution would be to have the destination route URI have a flag in it saying use v6 such as "sip:sip.att.com;usev6=YES". Another solutions would be just have a flag in the internal data structure for the proxy that said that use_v6 is true. Similarly one can indicate TLS by either putting the flag
>    in the destination URI or putting the flag in the same data structure that stores the destination URI. But here is the important point - this is an issue local to the proxy. Once the calls makes it to att, it will be over v6, or not, or tls and nothing about what the previous proxy policy matters. This whole thing is not really a matter of standardization - the proxy can implement it in the URI or not in the URI or whatever. People argued that trying to embed all possible proxy policy into a standardized URI just seemed like a bad plan.
>