Re: [Sip] Ready for WGLC on SIPS draft? Any last thoughts ontransport=tls?

["Jeroen van Bemmel" <jbemmel at zonnet.nl>]

Juha,

I believe the issue you are implicitly identifying is the following: it 
should always be possible to deterministically determine the transport to 
use towards a next hop learned from a Record-Route header. For a SIPS URI 
that implies that the 'transport' parameter MUST be present, because (in 
theory) it could be both TCP and SCTP (ref RFC3261 section 18, where it says 
"[...] transport protocols like TCP and SCTP, or TLS over those [...]".). It 
is true that RFC3263 states that TCP SHOULD be used for SIPS in case there 
is either an explicit port or a numeric IP address, but that does not mean 
that it _was_ indeed used. And there is nothing in RFC3261 that says proxies 
MUST support TLS over TCP (it just says TLS and TCP).

A stateful proxy/endpoint could maintain state about which transport was 
used. For these connection oriented transports the connection itself can be 
used as such, but as you mentioned it may get closed at one point and then 
the state would be lost. In any case, stateless proxies must be able to 
determine the transport based on only the URI provided.

The use of transport=tls was deprecated for the above reason (SCTP can also 
go over TLS). So in your case you should be using 
"sips:host[:port];transport=tcp", there is no implication of transport in 
that.

And RFC3261 should be updated to say that proxies "MUST support TLS over 
TCP", along with some inconsistencies (e.g. 18.1.1 says "It is 5060 for UDP, 
TCP and SCTP, 5061 for TLS." while 18.2.1 says "(5060 for TCP and UDP, 5061 
for TLS over TCP)"

Regards,
Jeroen


Juha Heinanen wrote:
> Francois Audet writes:
>
> > But for that, you can use SIPS in Record-Route, no?
>
> > It would be semantically identical, no?
>
> i don't know and don't care, because i don't use sips uri scheme for
> anything.  it is artificial to imply transport protocol from uri
> scheme, when there is a way to tell it straight.  perhaps someone
> will later invent some other secure transport protocol to be used
> with sips when then implication will fail.
>
> -- juha
>
>
> _______________________________________________
> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP Protocol
> Use sip-implementors at cs.columbia.edu for questions on current sip
> Use sipping at ietf.org for new developments on the application of sip 



_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip