Hi, when sip-router (master branch) receives a request via TLS (but with a "sip:" scheme URI in the Request Line) and routes the request using other transport (as UDP) it appends a Record-Route as follows:
Record-Route: sip:IP_PROXY:PORT;transport=tls
According to RFC 3261 and RFC 5630 (which explains better sips schema usage) the correct Record-Route should be:
Record-Route: sips:IP_PROXY:PORT or: Record-Route: sips:IP_PROXY:PORT;transport=tcp
However Sip-Router behaves a bit deprecated by using ;transport=tls, which is clearly deprecated even in RFC 3261.
Why would you want to use sips in the Route header in this particular case and not sip with the transport=tls parameter? I tried to make sense out of rfc 5630 but failed, so if you could present any more evidence why this is a good idea, that would be great.
The way I understand sips is that by using this scheme in a URI, you are indicating that you want to be contacted securely and if that is not possible (for whatever reason), you would rather want the request to fail than to be forwarded insecurely. I can see how this could make sense from end-point's (phone) point of view.
But why would anyone want to use this in the Route header? By using sips instead of sip;transport=tls in a Route header the proxy server is enforcing that it is to be contacted securely during the dialog, even if the original request (that established the dialog) may not have been subject to such a restriction. In other words request path that was fine for the INVITE is no longer fine for the re-INVITE or BYE.
Also, what is the real difference between using sip;transport=tls and sips in Route headers? In both cases the server sending the request will fail to deliver it if it cannot contact the downstream server over TLS. Or is it supposed to fallback to UDP when the parameter is used and reject the request when sips is used?
-Jan
On Tue, Jul 5, 2011 at 09:03, Iñaki Baz Castillo ibc@aliax.net wrote:
Hi, when sip-router (master branch) receives a request via TLS (but with a "sip:" scheme URI in the Request Line) and routes the request using other transport (as UDP) it appends a Record-Route as follows:
Record-Route: sip:IP_PROXY:PORT;transport=tls
According to RFC 3261 and RFC 5630 (which explains better sips schema usage) the correct Record-Route should be:
Record-Route: sips:IP_PROXY:PORT or: Record-Route: sips:IP_PROXY:PORT;transport=tcp
However Sip-Router behaves a bit deprecated by using ;transport=tls, which is clearly deprecated even in RFC 3261.
-- Iñaki Baz Castillo ibc@aliax.net
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
2011/7/5 Jan Janak jan@ryngle.com:
But why would anyone want to use this in the Route header? By using sips instead of sip;transport=tls in a Route header the proxy server is enforcing that it is to be contacted securely during the dialog, even if the original request (that established the dialog) may not have been subject to such a restriction. In other words request path that was fine for the INVITE is no longer fine for the re-INVITE or BYE.
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.
Also, what is the real difference between using sip;transport=tls and sips in Route headers? In both cases the server sending the request will fail to deliver it if it cannot contact the downstream server over TLS. Or is it supposed to fallback to UDP when the parameter is used and reject the request when sips is used?
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.
On Tue, Jul 5, 2011 at 12:42, Iñaki Baz Castillo ibc@aliax.net wrote:
2011/7/5 Jan Janak jan@ryngle.com:
But why would anyone want to use this in the Route header? By using sips instead of sip;transport=tls in a Route header the proxy server is enforcing that it is to be contacted securely during the dialog, even if the original request (that established the dialog) may not have been subject to such a restriction. In other words request path that was fine for the INVITE is no longer fine for the re-INVITE or BYE.
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.
So what is the difference then? How is a Route header with sips scheme different from a Route header with the transport=tls parameter? Is the proxy server supposed to treat Route headers with sips differently than Route headers with sip;transport=tls?
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.
Also, what is the real difference between using sip;transport=tls and sips in Route headers? In both cases the server sending the request will fail to deliver it if it cannot contact the downstream server over TLS. Or is it supposed to fallback to UDP when the parameter is used and reject the request when sips is used?
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.
Yeah, I understand this paragraph. I think the motivation for this was to make sips independent of the particular transport mechanism (tls).
But my original question was related to the Route/Record-Route header. There the proxy records the particular transport mechanism that was used when the dialog was being established. So if the INVITE was received over TLS, it would contain ;transport=tls in the Route header.
You mentioned that the Route header should rather contain sips scheme if the scheme of the Request-URI was sips. And I don't understand why. Maybe you're right, but I don't see what difference that would make at the moment.
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.
Elegant is a subjective and it hardly justifies such change, we need more hard evidence supporting such change.
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).
One can hardly blame them, I don't understand sips either ;-).
-Jan
Cheers.
-- Iñaki Baz Castillo ibc@aliax.net
2011/7/5 Jan Janak jan@ryngle.com:
So what is the difference then? How is a Route header with sips scheme different from a Route header with the transport=tls parameter? Is the proxy server supposed to treat Route headers with sips differently than Route headers with sip;transport=tls?
No, the only difference is that transport=tls is deprecated and """"maybe"""" some devices don't understand ;transport=tls.
But my original question was related to the Route/Record-Route header. There the proxy records the particular transport mechanism that was used when the dialog was being established. So if the INVITE was received over TLS, it would contain ;transport=tls in the Route header.
You mentioned that the Route header should rather contain sips scheme if the scheme of the Request-URI was sips. And I don't understand why. Maybe you're right, but I don't see what difference that would make at the moment.
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.
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.
Elegant is a subjective and it hardly justifies such change, we need more hard evidence supporting such change.
Yes, I'm not suggesting to change it, just wanted to open a discussion about it :)
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).
One can hardly blame them, I don't understand sips either ;-).
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.
Am 05.07.2011 19:04, schrieb Iñaki Baz Castillo:
2011/7/5 Jan Janak jan@ryngle.com:
So what is the difference then? How is a Route header with sips scheme different from a Route header with the transport=tls parameter? Is the proxy server supposed to treat Route headers with sips differently than Route headers with sip;transport=tls?
No, the only difference is that transport=tls is deprecated and """"maybe"""" some devices don't understand ;transport=tls.
I just wonder why it is deprecated at all? IIRC "sips:" does not mandate any protocol, just that encryption must be used. Thus, plain TCP over IPsec would also fulfill "sips:", but for sure is different than TLS+TCP.
regards Klaus
Klaus Darilion wrote:
Am 05.07.2011 19:04, schrieb Iñaki Baz Castillo:
2011/7/5 Jan Janak jan@ryngle.com:
So what is the difference then? How is a Route header with sips scheme different from a Route header with the transport=tls parameter? Is the proxy server supposed to treat Route headers with sips differently than Route headers with sip;transport=tls?
No, the only difference is that transport=tls is deprecated and """"maybe"""" some devices don't understand ;transport=tls.
I just wonder why it is deprecated at all?
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.
IIRC "sips:" does not mandate any protocol, just that encryption must be used. Thus, plain TCP over IPsec would also fulfill "sips:", but for sure is different than TLS+TCP.
3261 specifically mentions TLS over TCP a couple of times. Before SCTP and DTLS came along, sips meant TLS, stat.
Regards, Martin
Am 06.07.2011 10:30, schrieb Martin Hoffmann:
IIRC "sips:" does not mandate
any protocol, just that encryption must be used. Thus, plain TCP over IPsec would also fulfill "sips:", but for sure is different than TLS+TCP.
3261 specifically mentions TLS over TCP a couple of times. Before SCTP and DTLS came along, sips meant TLS, stat.
This confirms that sips is broken :-)
Am 05.07.2011 18:42, schrieb Iñaki Baz Castillo:
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).
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
2011/7/6 Klaus Darilion klaus.mailinglists@pernau.at:
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.
Don't say that to loud or IETF will say you "then use S/MIME" XDDD
6 jul 2011 kl. 10.09 skrev Klaus Darilion:
Am 05.07.2011 18:42, schrieb Iñaki Baz Castillo:
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).
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.
Yes. SIPS: doesn't really help anyone and showing a padlock on the phone is a broken model here.
/O
2011/7/6 Olle E. Johansson oej@edvina.net:
Yes. SIPS: doesn't really help anyone and showing a padlock on the phone is a broken model here.
I agree that SIPS is a pain. But that's is the standard.
6 jul 2011 kl. 13.12 skrev Iñaki Baz Castillo:
2011/7/6 Olle E. Johansson oej@edvina.net:
Yes. SIPS: doesn't really help anyone and showing a padlock on the phone is a broken model here.
I agree that SIPS is a pain. But that's is the standard.
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
2011/7/6 Olle E. Johansson oej@edvina.net:
I agree that SIPS is a pain. But that's is the standard.
The question: for what? :-)
I agree that SIPS is useful,
I don't agree, it's clearly a pain :)
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" ?
The only secure-secure-secure stuff would be encrypting the message itself, using some stupid and unfeasible stuff like S/MIME. If a message goes across intermediary nodes, you can never expect not to find a node breaking security.
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.
Yes, time to time :) This thread could be a good start point :)
I will go deeper into this stuff in the next days/weeks/months. Maybe we should start a section in the wiki documenting current sips/TLS status in Kamailio. Let me some time and I will start it.
Cheers.
6 jul 2011 kl. 13.50 skrev Iñaki Baz Castillo:
2011/7/6 Olle E. Johansson oej@edvina.net:
I agree that SIPS is a pain. But that's is the standard.
The question: for what? :-)
I agree that SIPS is useful,
I don't agree, it's clearly a pain :)
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" ?
The only secure-secure-secure stuff would be encrypting the message itself, using some stupid and unfeasible stuff like S/MIME. If a message goes across intermediary nodes, you can never expect not to find a node breaking security.
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.
Yes, time to time :) This thread could be a good start point :)
I will go deeper into this stuff in the next days/weeks/months. Maybe we should start a section in the wiki documenting current sips/TLS status in Kamailio. Let me some time and I will start it.
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
Jan Janak wrote:
Also, what is the real difference between using sip;transport=tls and sips in Route headers? In both cases the server sending the request will fail to deliver it if it cannot contact the downstream server over TLS. Or is it supposed to fallback to UDP when the parameter is used and reject the request when sips is used?
I think the upshot of it all is that there is no more transport=tls. If you want TLS, you have to do use the sips scheme with transport=tcp; if you want DTLS, you do sips with transport=udp.
This is somewhat consistent with SRV, where for SIP over TLS you would use the prefix _sips._tcp.
Regards, Martin
Martin Hoffmann writes:
I think the upshot of it all is that there is no more transport=tls. If you want TLS, you have to do use the sips scheme with transport=tcp; if you want DTLS, you do sips with transport=udp.
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
Juha Heinanen wrote:
Martin Hoffmann writes:
I think the upshot of it all is that there is no more transport=tls. If you want TLS, you have to do use the sips scheme with transport=tcp; if you want DTLS, you do sips with transport=udp.
i don't agree with the above.
If I understand things correctly, the above is the intent of the standardization body in charge of SIP.
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.
Well, you shouldn't. You should use transport=tcp, because that is the transport protocol you are using. That you want this encrypted is indicated by the sips scheme of your SIP URI. Also, if you next hop is only reachable via TLS and, yet the transport parameter and schema indicate unencrypted TCP, what stops you from using the TLS connection you have?
Only the opposite is a problem because you would degenerate the security status of your transmission and that is prohibited by the sips scheme.
Regards, Martin
5 jul 2011 kl. 20.01 skrev Martin Hoffmann:
Juha Heinanen wrote:
Martin Hoffmann writes:
I think the upshot of it all is that there is no more transport=tls. If you want TLS, you have to do use the sips scheme with transport=tcp; if you want DTLS, you do sips with transport=udp.
i don't agree with the above.
If I understand things correctly, the above is the intent of the standardization body in charge of SIP.
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.
Well, you shouldn't. You should use transport=tcp, because that is the transport protocol you are using. That you want this encrypted is indicated by the sips scheme of your SIP URI. Also, if you next hop is only reachable via TLS and, yet the transport parameter and schema indicate unencrypted TCP, what stops you from using the TLS connection you have?
Only the opposite is a problem because you would degenerate the security status of your transmission and that is prohibited by the sips scheme.
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
2011/7/5 Martin Hoffmann martin.hoffmann@telio.ch:
Well, you shouldn't. You should use transport=tcp, because that is the transport protocol you are using. That you want this encrypted is indicated by the sips scheme of your SIP URI.
It's like in HTTP world:
- http:// means HTTP over TCP. - https:// means HTTP over TLS over TCP.
Since HTTP just works over TCP, there is no reason for a ;transport param. But SIP protocol can work over different transport layers (TLS is not a transport layer).
Regards.
6 jul 2011 kl. 00.35 skrev Iñaki Baz Castillo:
2011/7/5 Martin Hoffmann martin.hoffmann@telio.ch:
Well, you shouldn't. You should use transport=tcp, because that is the transport protocol you are using. That you want this encrypted is indicated by the sips scheme of your SIP URI.
It's like in HTTP world:
- http:// means HTTP over TCP.
- https:// means HTTP over TLS over TCP.
Since HTTP just works over TCP, there is no reason for a ;transport param. But SIP protocol can work over different transport layers (TLS is not a transport layer).
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
Am 06.07.2011 08:28, schrieb Olle E. Johansson:
6 jul 2011 kl. 00.35 skrev Iñaki Baz Castillo:
2011/7/5 Martin Hoffmann martin.hoffmann@telio.ch:
Well, you shouldn't. You should use transport=tcp, because that is the transport protocol you are using. That you want this encrypted is indicated by the sips scheme of your SIP URI.
It's like in HTTP world:
- http:// means HTTP over TCP. - https:// means HTTP over TLS over
TCP.
Since HTTP just works over TCP, there is no reason for a ;transport param. But SIP protocol can work over different transport layers (TLS is not a transport layer).
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".
If you do not change the RURI but add a Route header with "sips:" then it would influence only the next hop.
Anyway, I still vote for transport=tls as it is unambiguous.
klaus
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 _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
2011/7/6 Klaus Darilion klaus.mailinglists@pernau.at:
If you do not change the RURI but add a Route header with "sips:" then it would influence only the next hop.
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
Am 06.07.2011 10:32, schrieb Iñaki Baz Castillo:
If you do not change the RURI but add a Route header with "sips:" then
it would influence only the next hop.
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).
If a client uses different protocols in contact and when sending messages the client is just broken.
regards Klaus
2011/7/6 Klaus Darilion klaus.mailinglists@pernau.at:
If a client uses different protocols in contact and when sending messages the client is just broken.
There is no need of sending requests and receiving responses using the same transport, neither using the same TCP connection.
Am 06.07.2011 12:45, schrieb Iñaki Baz Castillo:
2011/7/6 Klaus Darilion klaus.mailinglists@pernau.at:
If a client uses different protocols in contact and when sending messages the client is just broken.
There is no need of sending requests and receiving responses using the same transport, neither using the same TCP connection.
Except that it will fail in real life (with NAT, FWs ...)
klaus
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:
2011/7/6 Klaus Darilion klaus.mailinglists@pernau.at:
If you do not change the RURI but add a Route header with "sips:" then it would influence only the next hop.
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
2011/7/6 Klaus Darilion klaus.mailinglists@pernau.at:
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
The Route can be removed, the only important header would be:
Via: SIP/2.0/TLS...
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?
No, because the re-INVITE will contain some Route headers, the first one with sips schema (leg client<->proxy), which is removed by the proxy (it's ifself). The second one with sip schema (leg proxy<->gw), which would also be removed (double Record-Route mechanism as there is transport change).
More explained:
Initial INVITE Client -> Proxy (TLS) -----------------------------------------
INVITE sip:12345@domain Contact: sips:1.2.3.4:5678;transport=tcp Via: SIP/2.0/TLS...
Initial INVITE Proxy -> GW (UDP) ----------------------------------------- INVITE sip:12345@GW Contact: sips:1.2.3.4:5678;transport=tcp Via: SIP/2.0/TLS... Record-Route: sip:PROXY;transport=udp Record-Route: sips:PROXY;transport=tcp
200 from GW -> Proxy (UDP) ----------------------------------------
SIP/2.0 200 OK Contact: sip:12345@GW;transport=udp
BYE from GW -> Proxy (UDP) ------------------------------------------
BYE sips:1.2.3.4:5678;transport=tcp SIP/2.0 Via: SIP/2.0/UDP... Route: sip:PROXY;transport=udp Route: sips:PROXY;transport=tcp
The proxy removes both Route headers, so just the RURI remains. It contains sips with ;transport=tcp, so uses TLS over TCP.
BYE from Proxy -> Client (TLS) -----------------------------------------
BYE sips:1.2.3.4:5678;transport=tcp SIP/2.0 Via: SIP/2.0/TLS...
or BYE from Client -> Proxy (TLS) ---------------------------------------- BYE sip:12345@GW;transport=udp SIP/2.0 Via: SIP/2.0/TLS... Route: sips:PROXY;transport=tcp Route: sip:PROXY;transport=udp
Proxy removes both Route headers so inspects RURI which uses "udp":
BYE from Proxy -> GW (UDP) ---------------------------------------- BYE sip:12345@GW;transport=udp SIP/2.0 Via: SIP/2.0/UDP...
So, there is no need at all for ;transport=tls, which in fact, does NOT exist.
Cheers.
Am 06.07.2011 12:56, schrieb Iñaki Baz Castillo:
So, there is no need at all for ;transport=tls, which in fact, does NOT exist.
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
2011/7/6 Klaus Darilion klaus.mailinglists@pernau.at:
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)
And that is a bug in the current devices, not in the protocol. For example the so "great" PJSIP stack fails:
http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/2011-July/013102.html
Olle E. Johansson wrote:
6 jul 2011 kl. 00.35 skrev Iñaki Baz Castillo:
It's like in HTTP world:
- http:// means HTTP over TCP.
- https:// means HTTP over TLS over TCP.
Since HTTP just works over TCP, there is no reason for a ;transport param. But SIP protocol can work over different transport layers (TLS is not a transport layer).
You can not compare sips with https. Sorry.
https puts a requirement for TLS all the way.
SIPS: in RFC3261 did not.
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.
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".
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.
Yes, SIPS: is really messy and hard to understand.
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.
How would you guys handle a Contact: with SIPS: ?
In a dialog or in a registration?
Can you reuse a connection like outbound? I guess not, since you have to verify the endpoint certificate.
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
2011/7/6 Martin Hoffmann martin.hoffmann@telio.ch:
Yes, SIPS: is really messy and hard to understand.
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.
Main cause of the confussion ever after RFC 5630, is the fact that such RFC does not want to cover the ;transport=tls case in deep (which exists anyway as RFC 2543 and RFC 3261 mention it).
Iñaki Baz Castillo wrote:
2011/7/6 Martin Hoffmann martin.hoffmann@telio.ch:
Yes, SIPS: is really messy and hard to understand.
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.
Main cause of the confussion ever after RFC 5630, is the fact that such RFC does not want to cover the ;transport=tls case in deep (which exists anyway as RFC 2543 and RFC 3261 mention it).
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
2011/7/6 Martin Hoffmann martin.hoffmann@telio.ch:
Main cause of the confussion ever after RFC 5630, is the fact that such RFC does not want to cover the ;transport=tls case in deep (which exists anyway as RFC 2543 and RFC 3261 mention it).
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
After re-checking RFC 2543 and RFC 3261:
- In RFC 2543 "sips" schema does not exist, neither ";transport=tls". The only it says is that a request can be sent via TLS by setting "TLS" as Via transport:
RFC 2543 - 13.1.4 Hop-by-Hop Encryption
SIP requests and responses MAY also be protected by security mechanisms at the transport or network layer. No particular mechanism is defined or recommended here. Two possibilities are IPSEC [34] or TLS [35].
- In RFC 3261 "sips" schema is defined and mandates SIP over TLS over TCP (as neither SCTP over TLS or DTLS were defined in 2002, but leaves the door open for using new secure mechanism when schema is "sips").
- RFC 3261 shows *NO* example of ";transport=tls", not al all, and it clearly states that "sips" must be used.
- RFC 3261 just talks about "tls" in ;transport param in the BNF section: transport-param = "transport=" ( "udp" / "tcp" / "sctp" / "tls" / other-transport )
and this is becase, as RFC 5630 explains:
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].
- And RFC 3261 says:
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 in RFC 2543 there is no mention AT ALL to ";transport=tls", neither "tls" is mentioned as a valid value for the URI transport param. In fact, BNF in RFC 2543 says:
transport-param = "transport=" ( "udp" | "tcp" )
So after "re-reading" all the specifications (RFC 2543, RFC 3261 and RFC 5630) it's fully CLEAR for me that using ;transport=tls is *incorrect*. It seems that such value has been used in some draft between RFC 2543 and RFC 3261 (without including them!!). But since RFC 3261 (which is what we use) there is no ;transport=tls at all. So implementations should leave using it (because they are using something that does not exist).
Now it somebody still thinks that ;transport=tls is valid, he should at least point to any alive specification showing it :)
Am 06.07.2011 11:05, schrieb Iñaki Baz Castillo:
And RFC 3261 says:
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.
I could interpret this as "if I want encryption to a specific single hop then I could do this by using transport=tls" :-)
2011/7/6 Klaus Darilion klaus.mailinglists@pernau.at:
Am 06.07.2011 11:05, schrieb Iñaki Baz Castillo:
- And RFC 3261 says:
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.
I could interpret this as "if I want encryption to a specific single hop then I could do this by using transport=tls" :-)
Klaus, you are trying to argue in favour if ;transport=tls when we have already explained in this thread that such param has been never specified and SIP RFC's mandate the usage of sips schema for there topics.
Also, when you say "if I want encryption to a specific single hop then I could do this by using transport=tls", so you wouls require TLS over TCP, what about if you want TLS over SCTP?
Am 06.07.2011 12:46, schrieb Iñaki Baz Castillo:
2011/7/6 Klaus Darilion klaus.mailinglists@pernau.at:
Am 06.07.2011 11:05, schrieb Iñaki Baz Castillo:
And RFC 3261 says:
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.I could interpret this as "if I want encryption to a specific single hop then I could do this by using transport=tls" :-)
Klaus, you are trying to argue in favour if ;transport=tls when we have already explained in this thread that such param has been never specified and SIP RFC's mandate the usage of sips schema for there topics.
Also, when you say "if I want encryption to a specific single hop then I could do this by using transport=tls", so you wouls require TLS over TCP, what about if you want TLS over SCTP?
IMO, transport=sctp-tls could be used (although it is not defined)
klaus
2011/7/6 Klaus Darilion klaus.mailinglists@pernau.at:
Also, when you say "if I want encryption to a specific single hop then I could do this by using transport=tls", so you wouls require TLS over TCP, what about if you want TLS over SCTP?
IMO, transport=sctp-tls could be used (although it is not defined)
So Klaus, you are proposing something that does not exist and is not defined anywhere, but there IS a real standarized mechanism for this stuff. So...
Iñaki Baz Castillo writes:
2011/7/6 Klaus Darilion klaus.mailinglists@pernau.at:
Also, when you say "if I want encryption to a specific single hop then I could do this by using transport=tls", so you wouls require TLS over TCP, what about if you want TLS over SCTP?
IMO, transport=sctp-tls could be used (although it is not defined)
So Klaus, you are proposing something that does not exist and is not defined anywhere, but there IS a real standarized mechanism for this stuff. So...
tell me how you achieve what klaus in above and i in another message want using "a real standarized mechanism"?
-- juha
2011/7/6 Juha Heinanen jh@tutpro.com:
tell me how you achieve what klaus in above and i in another message want using "a real standarized mechanism"?
Hi Juha, what exactly you mean? could you specify please? Anyhow during the whole thread I think I've already given flow examples of how to use sips for end-to-end and for hop-by-hop communication.
Olle E. Johansson wrote:
Now it somebody still thinks that ;transport=tls is valid, he should at least point to any alive specification showing it :)
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.
Since I am currently rather frustrated from debugging some other SIP stuff: Maybe we should try Jingle?
Regards, Martin
6 jul 2011 kl. 13.30 skrev Martin Hoffmann:
Olle E. Johansson wrote:
Now it somebody still thinks that ;transport=tls is valid, he should at least point to any alive specification showing it :)
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.
Since I am currently rather frustrated from debugging some other SIP stuff: Maybe we should try Jingle?
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
Iñaki Baz Castillo writes:
Now it somebody still thinks that ;transport=tls is valid, he should at least point to any alive specification showing it :)
if i want my proxy to use tls on the next hop, i can set $du with ;transport=tls and it happens. how can i do it if you make ;transport=tls illegal?
-- juha
2011/7/6 Juha Heinanen jh@tutpro.com:
Now it somebody still thinks that ;transport=tls is valid, he should at least point to any alive specification showing it :)
if i want my proxy to use tls on the next hop, i can set $du with ;transport=tls and it happens. how can i do it if you make ;transport=tls illegal?
There should/could be a function t_relay_tls().
2011/7/6 Juha Heinanen jh@tutpro.com:
There should/could be a function t_relay_tls().
i want to set $du and call t_relay(), not call different t_relay_x() functions.
$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.
Am 06.07.2011 17:54, schrieb Juha Heinanen:
Iñaki Baz Castillo writes:
Now it somebody still thinks that ;transport=tls is valid, he should at least point to any alive specification showing it :)
if i want my proxy to use tls on the next hop, i can set $du with ;transport=tls and it happens. how can i do it if you make ;transport=tls illegal?
You can write whatever you want to $du. $du is a Kamailio legacy thing and the content will not appear in the message.
klaus
2011/7/12 Klaus Darilion klaus.mailinglists@pernau.at:
Am 06.07.2011 17:54, schrieb Juha Heinanen:
Iñaki Baz Castillo writes:
Now it somebody still thinks that ;transport=tls is valid, he should at least point to any alive specification showing it :)
if i want my proxy to use tls on the next hop, i can set $du with ;transport=tls and it happens. how can i do it if you make ;transport=tls illegal?
You can write whatever you want to $du. $du is a Kamailio legacy thing and the content will not appear in the message.
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.
6 jul 2011 kl. 10.23 skrev Martin Hoffmann:
Olle E. Johansson wrote:
6 jul 2011 kl. 00.35 skrev Iñaki Baz Castillo:
It's like in HTTP world:
- http:// means HTTP over TCP.
- https:// means HTTP over TLS over TCP.
Since HTTP just works over TCP, there is no reason for a ;transport param. But SIP protocol can work over different transport layers (TLS is not a transport layer).
You can not compare sips with https. Sorry.
https puts a requirement for TLS all the way.
SIPS: in RFC3261 did not.
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.
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".
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.
Because RFC 5630 says that if a Route header has SIPS the contact also has to be SIPS.
As mandated by [RFC3261], Section 12.1.1:
If the request that initiated the dialog contained a SIPS URI in the Request-URI or in the top Record-Route header field value, if there was any, or the Contact header field if there was no Record- Route header field, the Contact header field in the response MUST be a SIPS URI.
Yes, SIPS: is really messy and hard to understand.
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.
Agree. It's not complete.
How would you guys handle a Contact: with SIPS: ?
In a dialog or in a registration?
Both.
Can you reuse a connection like outbound? I guess not, since you have to verify the endpoint certificate.
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.
If the client initiated the connection without a client certificate, you can't reuse that one. If you requested a client cert and that matches the Contact the client provided you with, you are allowed to use it.
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.)
Exactly. And when testing at SIPit (Nils, Daniel and I) we found that most phones doesn't bother with verification of the server cert anyway. Just put a padlock on the screen and be happy - WE ARE SECURE!
/O
2011/7/6 Olle E. Johansson oej@edvina.net:
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.
Because RFC 5630 says that if a Route header has SIPS the contact also has to be SIPS.
As mandated by [RFC3261], Section 12.1.1:
If the request that initiated the dialog contained a SIPS URI in the Request-URI or in the top Record-Route header field value, if there was any, or the Contact header field if there was no Record- Route header field, the Contact header field in the response MUST be a SIPS URI.
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.
2011/7/6 Iñaki Baz Castillo ibc@aliax.net:
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.
...in all the path.
2011/7/6 Olle E. Johansson oej@edvina.net:
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".
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".
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.
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.
6 jul 2011 kl. 10.23 skrev Iñaki Baz Castillo:
2011/7/6 Olle E. Johansson oej@edvina.net:
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".
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?
Right. That is a problem. But I personally don't think it's one you solve by using SIPS.
The most important part of RFC 5630 is this: This document specifies that SIPS means that the SIP resource designated by the target SIPS URI is to be contacted securely, using TLS on each hop between the UAC and the remote UAS (as opposed to only to the proxy responsible for the target domain of the Request- URI).
Which means - IPsec and other VPNs are no longer valid - We need TLS to the UAS - the last hop also needs security now.
Unfortunately ( I think) it also says: To emphasize what is already defined in [RFC3261], UAs MUST NOT use the "transport=tls" parameter.
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".
THis is defined according to RFC5630: For Via header fields, the following transport protocols are defined in [RFC3261]: "UDP", "TCP", "TLS", "SCTP", and in [RFC4168]: "TLS- SCTP".
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.
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
Me too. And if people like us on this list can't figure this out, it's broken.
/O
2011/7/6 Olle E. Johansson oej@edvina.net:
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".
THis is defined according to RFC5630: For Via header fields, the following transport protocols are defined in [RFC3261]: "UDP", "TCP", "TLS", "SCTP", and in [RFC4168]: "TLS- SCTP".
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.
6 jul 2011 kl. 13.39 skrev Iñaki Baz Castillo:
2011/7/6 Olle E. Johansson oej@edvina.net:
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".
THis is defined according to RFC5630: For Via header fields, the following transport protocols are defined in [RFC3261]: "UDP", "TCP", "TLS", "SCTP", and in [RFC4168]: "TLS- SCTP".
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 missed that we ahve two different name spaces. Ouch.
Wonder if anyone has tried using this. Seems like you either build a non-tls network or a TLS-network where you implement TLS by mandate and don't bother with SIP or SIPS uri's.
So what does Kamailio say if I have SIPS target URI and my NAPTR doesn't have any entries for TLS?
/O
2011/7/6 Olle E. Johansson oej@edvina.net:
So what does Kamailio say if I have SIPS target URI and my NAPTR doesn't have any entries for TLS?
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).
6 jul 2011 kl. 13.54 skrev Iñaki Baz Castillo:
2011/7/6 Olle E. Johansson oej@edvina.net:
So what does Kamailio say if I have SIPS target URI and my NAPTR doesn't have any entries for TLS?
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).
And what's the response code if there's no target found?
/O
2011/7/6 Olle E. Johansson oej@edvina.net:
2011/7/6 Olle E. Johansson oej@edvina.net:
So what does Kamailio say if I have SIPS target URI and my NAPTR doesn't have any entries for TLS?
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).
And what's the response code if there's no target found?
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
6 jul 2011 kl. 14.03 skrev Iñaki Baz Castillo:
2011/7/6 Olle E. Johansson oej@edvina.net:
2011/7/6 Olle E. Johansson oej@edvina.net:
So what does Kamailio say if I have SIPS target URI and my NAPTR doesn't have any entries for TLS?
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).
And what's the response code if there's no target found?
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
That's interesting.
There are two warning codes registred with IANA that touches SIPS:
380 SIPS Not Allowed: The UAS or proxy cannot process [RFC5630] the request because the SIPS scheme is not allowed (e.g., because there are currently no registered SIPS Contacts).
381 SIPS Required: The UAS or proxy cannot process the [RFC5630] request because the SIPS scheme is required.
In this case, warning: 381 might be a good one. Now, how should we do if we forward a response and the certificate doesn't match? Just drop the response?
There's a new RFC with SIp security call flows, Gotta check that one for reference as well.
/O
6 jul 2011 kl. 14.24 skrev Olle E. Johansson:
6 jul 2011 kl. 14.03 skrev Iñaki Baz Castillo:
2011/7/6 Olle E. Johansson oej@edvina.net:
2011/7/6 Olle E. Johansson oej@edvina.net:
So what does Kamailio say if I have SIPS target URI and my NAPTR doesn't have any entries for TLS?
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).
And what's the response code if there's no target found?
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
That's interesting.
There are two warning codes registred with IANA that touches SIPS:
380 SIPS Not Allowed: The UAS or proxy cannot process [RFC5630] the request because the SIPS scheme is not allowed (e.g., because there are currently no registered SIPS Contacts).
381 SIPS Required: The UAS or proxy cannot process the [RFC5630] request because the SIPS scheme is required.
In this case, warning: 381 might be a good one. Now, how should we do if we forward a response and the certificate doesn't match? Just drop the response?
There's a new RFC with SIp security call flows, Gotta check that one for reference as well.
http://tools.ietf.org/html/rfc6216
/O
Interesting and helpful implementation guideline in RFC 6216:
"If a client is trying to set up a TLS connection to good.example.com and it gets a TLS connection set up with a server that presents a valid certificate but with the name evil.example.com, it will typically generate an error or warning of some type. "
No, if the client is a SIP proxy configured as an outbound proxy. What are the exact SIP return codes and Warnings we should send?
/O
2011/7/6 Olle E. Johansson oej@edvina.net:
Good point, I will take a look to it.
2011/7/6 Iñaki Baz Castillo ibc@aliax.net:
2011/7/6 Olle E. Johansson oej@edvina.net:
So what does Kamailio say if I have SIPS target URI and my NAPTR doesn't have any entries for TLS?
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).
And this is what Kamailio 3.X does (if NAPTR and so is enabled).
2011/7/5 Martin Hoffmann martin.hoffmann@telio.ch:
I think the upshot of it all is that there is no more transport=tls. If you want TLS, you have to do use the sips scheme with transport=tcp; if you want DTLS, you do sips with transport=udp.
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.
This is somewhat consistent with SRV, where for SIP over TLS you would use the prefix _sips._tcp.
And for SCTP over TLS you would use _sips._sctp.
Cheers.
-
Iñaki Baz Castillo -
Jan Janak -
Juha Heinanen -
Klaus Darilion -
Martin Hoffmann -
Olle E. Johansson