5 Jul
2011
5 Jul
'11
9:23 p.m.
5 jul 2011 kl. 20.01 skrev Martin Hoffmann:
Juha Heinanen wrote:
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
Martin Hoffmann writes:
If I understand things correctly, the above is the intent of the
standardization body in charge of SIP.
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.
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.