2011/7/5 Jan Janak <jan(a)ryngle.com>om>: Hi Jan, the Route header will be removed by each proxy in the path, so there is no restriction for in-dialog requests. Example: A P1 P2 B -----INV TLS-----> ----- INV UDP ----> RR: sips:P1;tcp ----- INV UDP ----> RR: sip:P2;udp RR: sips:P1;tcp The 200 arriving to A would contain: SIP/2.0 200 OK Record-Route: sip:P2;transport=udp Record-Route: sips:P1;transport=tcp Contact: sip:B;transport=udp So A would generate an ACK as follows: ACK sip:B;transport=udp SIP/2.0 Route: sips:P1;transport=tcp Route: sip:P2;transport=udp then A would route the ACK to P1 using TLS (as topmost Route has sips). P1 would remove the topmost Route (loose-routing) so the ACK would become: ACK sip:B;transport=udp SIP/2.0 Route: sip:P2;transport=udp then P1 would route the ACK to P2 using UDP (as topmost Route is sip with udp). And so on. So a sips scheme in a Route header is just hop-by-hop information, and not end-to-end. However a sips schema in a request URI mandates all the path to be secure, but that is not the case of a sips in a Record-Route header. RFC 3261 deprecates the usage of transport=tls in section 26.2.2 SIPS URI Scheme: Note that in the SIPS URI scheme, transport is independent of TLS, and thus "sips:alice@atlanta.com;transport=tcp" and "sips:alice@atlanta.com;transport=sctp" are both valid (although note that UDP is not a valid transport for SIPS). The use of "transport=tls" has consequently been deprecated, partly because it was specific to a single hop of the request. This is a change since RFC 2543. But anyway, in other thread in sip-implementors I got the conclussion that RFC 3261 deprecates sips schema with transport=tls, but says nothing about sip schema with transport=tls (in fact, "tls" is still a valid transport according to the BNF grammar). So, I don't say that current sip-router behavior is wrong, but I think it would be more "ellegant" if it would use sips URI and ;transport=tcp. NOTE: In fact, some existing clients (as the widely extended PJSIP) would fail if the Record-Route contains sips+transport=tcp as I've reported today: http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2011-July/013102.html This is because PJSIP does not understand at all the meaning of a sips schema (ugly in a so widely deployed SIP stack). Cheers. -- Iñaki Baz Castillo <ibc(a)aliax.net>

2011/7/5 Jan Janak <jan(a)ryngle.com>om>: No, the only difference is that transport=tls is deprecated and """"maybe"""" some devices don't understand ;transport=tls. Within a hop, sip:IP;transport=tls and sips:IP;transport=tcp seems to mean exactly the same. It just occurs that sips is preferred by RFC's and "tls" seems to be deprecated. Yes, I'm not suggesting to change it, just wanted to open a discussion about it :) I agree. sips schema is a pain. There is a RFC (5630) trying to clarify it (as 3261 says nothing clear) and still here are a lot of doubts about it. Maybe it's just better to continue with sip and transport=tls in Record-Route, but another approach could be sips and transport=tls (it would satisfy devices expecting sips and devices expecting tls transport). Cheers. -- Iñaki Baz Castillo <ibc(a)aliax.net>

Klaus Darilion wrote: I wonder why it exists at all in the standard. Ole's quote shows that it only ever showed up in an RFC as deprecated. Why not just leave it out? There is far too many people who defer the workings of a protocol from reading the ABNF only and don't bother with the pesky prose. 3261 specifically mentions TLS over TCP a couple of times. Before SCTP and DTLS came along, sips meant TLS, stat. Regards, Martin

Am 05.07.2011 18:42, schrieb Iñaki Baz Castillo: Maybe pjsip is the only one who make it right. ;-) IMO "sips:" is totally broken and should be deprecated. With "sips:" a client relies that all intermediate hops are standard conform and do forwarding with encryption. If you really need encryption end2end this is a wrong approach - so it is broken by design. regards Klaus

6 jul 2011 kl. 10.09 skrev Klaus Darilion: Yes. SIPS: doesn't really help anyone and showing a padlock on the phone is a broken model here. /O

6 jul 2011 kl. 13.12 skrev Iñaki Baz Castillo: The question: for what? :-) I agree that SIPS is useful, but when and for whom? - is this something we only use in infrastructure? - or is this something a client can use to set up a "secure call" ? You can clearly mandate yourself that anything using SIP: should run over TLS. You can implement SIPS in outbound proxys and stuff. Do we have good documentation on how Kamailio handles SIPS uri's in - request uri's - contacts for registration - route headers - via headers etc etc... Which error codes are used if I have a via header with SIPS and kamailio can't set up a secure connection to the upstream SIP server? In the kamailio team, we should at least have one policy for how to support it and how to handle TLS certificate verification. /O

6 jul 2011 kl. 13.50 skrev Iñaki Baz Castillo: Right. And I will have to update some stuff in my SIP TLS presentation... Mail out when you start a wiki page and we'll try to dig through the source code and file bug reports if needed. I think Kamailio has to shine in this area. /O

Martin Hoffmann writes: i don't agree with the above. for example, no matter which transport a request arrives to a proxy, the next hop proxy may be only reachable over tls, in which case i would use ;transport=tls. -- juha

5 jul 2011 kl. 20.01 skrev Martin Hoffmann: I disagree. SIPS and SIP with "transport=tls" are two different things. RFC 3261 deprecated "transport=tls" but it is widely agreed on SIPit testings that we have no other way to handle some situations. Quoting RFC 5630: in the SIPS URI scheme, transport is independent of TLS, and thus "sips:alice@atlanta.com;transport=TCP" and "sips:alice@atlanta.com;transport=sctp" are both valid (although note that UDP is not a valid transport for SIPS). The use of "transport=tls" has consequently been deprecated, partly because it was specific to a single hop of the request. This is a change since RFC 2543. The "tls" parameter has not been eliminated from the ABNF in [RFC3261], Section 25, since the parameter needs to remain in the ABNF for backward compatibility in order for parsers to be able to process the parameter correctly. The transport=tls parameter has never been defined in an RFC, but only in some of the Internet drafts between [RFC2543] and [RFC3261]. This specification does not make use of the transport=tls parameter. The reinstatement of the transport=tls parameter, or an alternative mechanism for indicating the use of the TLS on a single hop in a URI, is outside the scope of this specification. For Via header fields, the following transport protocols are defined in [RFC3261]: "UDP", "TCP", "TLS", "SCTP", and in [RFC4168]: "TLS- SCTP". So "transport=tls" is still in need of clarification... /O

6 jul 2011 kl. 00.35 skrev Iñaki Baz Castillo: You can not compare sips with https. Sorry. https puts a requirement for TLS all the way. SIPS: in RFC3261 did not. It's simply a request, a proposal. Now if you don't want to change the properties of the original request, but still require your infrastructure to use TLS for the next hop you do not want to change to a SIPS: uri, which will put a new requirement for the rest of the signalling. You want to add an attribute like ";transport=tls". Yes, SIPS: is really messy and hard to understand. How would you guys handle a Contact: with SIPS: ? Can you reuse a connection like outbound? I guess not, since you have to verify the endpoint certificate. /O

2011/7/6 Klaus Darilion &lt;klaus.mailinglists(a)pernau.at&gt;at>: Mmmm, imagine this INVITE sent by a UA via TLS: INVITE sip:bob@domain.com Via: SIP/2.0/TLS Route: <sips:myproxy> Contact: <sip:alice@1.2.3.4> In this case, the UA would send the INVITE via TCP but in-dialog request from the remote would be delivered by the proxy to alice via UDP (the Contact header). AFAIK RFC 5630 states that, in order to send a request via TLS (without requiring security in all the path) the UAC must use: INVITE sip:bob@domain.com Via: SIP/2.0/TLS Contact: <sips:alice@1.2.3.4> -- Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt;

2011/7/6 Klaus Darilion &lt;klaus.mailinglists(a)pernau.at&gt;at>: There is no need of sending requests and receiving responses using the same transport, neither using the same TCP connection. -- Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt;

Inaki, how can we deal with this scenario: Client uses TLS to the proxy. Between proxy and gateway UDP is used. In a deprecated way I would use: INVITE sip:12345@domain Route: sip:domain;transport=tls Contact: sip:1.2.3.4:5678;transport=tls In the standardized way I think I have to use: INVITE sip:12345@domain Route: sips:domain;transport=tcp Contact: sips:1.2.3.4:5678;transport=tcp Thus, reINVITE would have RURI with "sips". Wouldn't this imply that all the way TLS must be used and reINVITE fail as the gateway only supports UDP? regards Klaus Am 06.07.2011 10:32, schrieb Iñaki Baz Castillo:

Am 06.07.2011 12:56, schrieb Iñaki Baz Castillo: Ok. The last problem will be, that many SIP devices will fail to parse the sips URI in the RR headers (even if they are not needed for them) regards Klaus

Olle E. Johansson wrote: RFC 3261, section 4: | A call made to a SIPS URI guarantees that secure, encrypted transport | (namely TLS) is used to carry all SIP messages from the caller to the | domain of the callee. From there, the request is sent securely to | the callee, but with security mechanisms that depend on the policy of | the domain of the callee. Why? We are talking about the URI in the (Record-) Route header here, which _only_ indicates how to get to the next hop. If you put a SIPS URI in there, this has no consequence whatsoever for the complete path. I'd argue it's completely broken like so many things in SIP. IETF went out to publish a document to fix it. After much argueing, this became RFC 5630 and people are confused as ever. In a dialog or in a registration? If you reuse a connection you'd have done that already earlier. Most likely, the client opened the conneciton to you in the first place. One final word: What Iñaki and me are argueing here is what the standards say. What we probably don't agree on is what this means in practice. For me as someone who regularly has to bring different SIP implementations together, it means pretty much nothing. You'd never find SIPS URIs in the wild but plenty of transport=tls. (Or well, not really, nobody is using TLS in practice anyways.) Regards, Martin

Iñaki Baz Castillo wrote: Why would it need to. There is _no_ transport=tls in 2543 and 3261 says explicitely "don't use it; we just kept it in to stipulate long-winded future discussions" (already it doesn't say the latter bit). The purpose of 5630 was to explain the whole SIPS thing. Obviously, it failed. Just to repeat it once more (because this is fun): The use of the value "tls" for the transport URI parameter has never been mandated by any SIP standard. Regards, Martin

Am 06.07.2011 11:05, schrieb Iñaki Baz Castillo: I could interpret this as "if I want encryption to a specific single hop then I could do this by using transport=tls" :-)

Am 06.07.2011 12:46, schrieb Iñaki Baz Castillo: IMO, transport=sctp-tls could be used (although it is not defined) klaus

Iñaki Baz Castillo writes: tell me how you achieve what klaus in above and i in another message want using "a real standarized mechanism"? -- juha

There are certainly use cases for it, since upgrading from SIP to SIPS: means a lot of other implications. This is just way too messed up. /O

6 jul 2011 kl. 13.30 skrev Martin Hoffmann: Well, I hope that we can protect Jingle from all the strange PSTN stuff (PRACK, early media etc etc) Security-wise, since they only have client based connection management, things get easier. But they still have the same issues with end-2-end security. /O

2011/7/6 Juha Heinanen &lt;jh(a)tutpro.com&gt;om>: There should/could be a function t_relay_tls(). -- Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt;

2011/7/6 Juha Heinanen &lt;jh(a)tutpro.com&gt;om>: $du just means the destination URI, and it just affects to the request Via header added by Kamailio. So then, in order to be more compliant with SIPS spec, there should be a way to modify the schema of the destination URI (or just rewrite the entire $du by setting "sips:" schema). If Kamailio receives a request with RURI "sips:alice@1.2.3.4" or "sips:alice@1.2.3.4;transport=tcp" then it triesto open a TLS over TCP connection with 1.2.3.4:5061. So I expect that setting $du with a sips schema should also work. -- Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt;

2011/7/12 Klaus Darilion &lt;klaus.mailinglists(a)pernau.at&gt;at>: But you could also do the same by setting a sips scheme: $du = "sips:1.2.3.4" or $du = "sips:1.2.3.4;transport=tcp" Then Kamailio should open a TLS over TCP connection with 1.2.3.4:5061. -- Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt;

2011/7/6 Olle E. Johansson &lt;oej(a)edvina.net&gt;et>: Thanks for pointing it out. I can imagine the reason for this requeriment: ensure that both parts of the communications (requests from both sides) use a secure layer. -- Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt;

2011/7/6 Olle E. Johansson &lt;oej(a)edvina.net&gt;et>: I don't think so. If you add ";transport=tls" in the request RURI you are telling all the nodes in the path to use SIP over TLS over TCP. What about if there are two nodes in the patch which just can talk TLS over SCTP? In contrast, if you add "sips:" and no ;transport param in the RURI, you are telling all the nodes in the path to use TLS (over TCP, over SCTP, maybe DTLS...). With a "sips:" schema yuo are mandating all the communication to be secure, regardless the exact transport protocol used in each hop. As Klaus has pointed out in other mail, what about if a node in the path speaks SIP over UDP/TCP/SCTP over IPSEC? I expect it would also fullfil the requeriments of a "sips" request. Also, I've already make a question previously: you say that "transport=tls" is correct, so is "tls-sctp" also correct? RFC 4168 (SIP over SCTP) defines "SCTP" and "TLS-SCTP" for Via transport, similar to "TCP" and "TLS" (which means TCP over TLS). But RFC 4168 does not define "tls-sctp" for an URI transport param. Why not? because the correct way is "sips" schema and ";transport=sctp". I read RFC 5630 recently and I think I understood all the sips topic (there is there a response for your question, sure). However it's hard to remember and I must read it again XDD Cheese's. -- Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt;

2011/7/6 Olle E. Johansson &lt;oej(a)edvina.net&gt;et>: Transport in Via header and transport in SIP URI header are different things. In the RFC 3261 BNF they appear as different elements. The fact that some values match doesn't mean that are equivalent in both sides. Said that, this stuf becomes more and more complex due to this fact: this is: Via transport accepts "TLS" or "TLS-SCTP" while ;transport does not. -- Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt;

2011/7/6 Olle E. Johansson &lt;oej(a)edvina.net&gt;et>: Based on RFC 3263 (which I've studied recently in deep) Kamailio should discard NAPTR records whose "service" field has not SIPS+XXX. So at the end it's like if there are not NAPTR records. Then it should perform _sips._tcp SRV for the RURI domain. If there is, use its records. If not, the perform A/AAAA DNS resolution for the RURI domain and choose port 5061 (default por TLS). -- Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt;

2011/7/6 Olle E. Johansson &lt;oej(a)edvina.net&gt;et>: I asked fot this in sip.implementors. It would be the very same as if the domain does not exist (A record) which also is unclear which response deservers. Some people suggested 404, others 604... As I hate 6XX responses I would generate a 404. But in case the domain exists but does not listen TLS connections, then again it's not defined which exact response code to return by the proxy. Kamailio uses 478 custom response (maybe it's other code). Note however that due to a limitation in TCP/TLS async mode [*] Kamailio returns 408 after fr_timer. [*] http://sip-router.org/tracker/index.php?do=details&task_id=136 -- Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt;

6 jul 2011 kl. 14.24 skrev Olle E. Johansson: http://tools.ietf.org/html/rfc6216 /O

2011/7/6 Olle E. Johansson &lt;oej(a)edvina.net&gt;et>: Good point, I will take a look to it. -- Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt;

2011/7/5 Martin Hoffmann &lt;martin.hoffmann(a)telio.ch&gt;ch>: And if you want TLS over SCTP, you must use an URI with sips schema with ;transport=sctp (rather than ;transport=tls-sctp). In fact, RFC 4168 (SCTP for SIP) defines TLS-SCTP for the Via transport (which uses TLS meaning TLS over TCP). But in case of an URI transport param, "tls-sctp" is not defined. Instead sips schema and ;transport=sctp must be used. This would mean that the correct way to go is using sips schema. Just a question: For now SIP-Router does not implement SCTP over TLS. Think about how will look a Record-Route when the incoming INVITE arrives via STCP over TLS. And for SCTP over TLS you would use _sips._sctp. Cheers. -- Iñaki Baz Castillo &lt;ibc(a)aliax.net&gt;