6 Jul
2011
6 Jul
'11
11:23 a.m.
2011/7/6 Olle E. Johansson <oej(a)edvina.net>et>:
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.
--
Iñaki Baz Castillo
<ibc(a)aliax.net>