Subject: RE: [Sip] SCTP and TLS

From: Adam Roach <[email-masked]>
Date: Mon, 24 Nov 2003 10:50:22 -0600

Vijay K. Gurbani [mailto:[email-masked]] wrote:

> I seem to recall that "transport=tls" was deprecated in favor
> of the sips URI which implies it.

Yes, this is precisely the correct answer to Cullen's question.
Section 26.2.2 of RFC 3261 addresses this:

  Note that in the SIPS URI scheme, transport is independent of TLS,
  and thus "sips:[email-masked];transport=tcp" and
  "sips:[email-masked];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.

Personally, I couldn't be more pleased, since calling tls a transport
always puts my teeth on edge.

However, this leaves the issue of Via headers.

I can say:

  Via: SIP/2.0/SCTP pc33.example.com;branch=z9hG4bK776asdhds

Or:

  Via: SIP/2.0/TLS pc33.example.com;branch=z9hG4bK776asdhds

But there is no standardized syntax that allows me to say
both at the same time.

/a

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Cullen Jennings <[email-masked]>
Date: Mon, 24 Nov 2003 18:16:57 -0800

sips means every hop needs TLS, transport=tls is about one hop needing TLS.

transport=tls was deprecated in a SIPS uri (because it is redundant there)
but I don't believe it was deprecated in a SIP uri. I was taking about the
case of a sip uri.  Imagine A sends with a sip uri over UDP to B with a
preloaded route to C and A wishes to indicated that a TLS protected protocol
should be used from B to C. However C can send the message to D any way it
wants so we don't want to upgrade to a sips.

This is not an unreasonable scenario - A and D could be clients in an
enterprise network that is protected in some way and B and C could be
enterprise proxies that do TLS protection across the internet.

There is also the Via problem...

I see a few possibilities for this ... (yes and I agree with Adam on the
confounding of transport type and security type into one tag was not the
most elegant move but yet that is where we are)

We need to be able to indicate in the VIA what the protocol is and also if
TLS was used or not.

Solution A
- define SCTPS to be SCTP with TLS and UDPS to be UDP with TLS and let the
via look like

Via: SIP/2.0/SCTPS pc33.example.com;branch=z9hG4bK776asdhds

Solution B
- change the SIP in the via to be either SIP or SIPS and treat this to be
sort of like the SIP or SIPS in a NAPTR record

Via: SIPS/2.0/SCTP pc33.example.com;branch=z9hG4bK776asdhds

Solution C
- add a security tag that defines if security TLS is used or not
Via: SIP/2.0/SCTP pc33.example.com;branch=z9hG4bK776asdhds;security=TLS

There are backwards compatibility issues with all of these.

Next we need to be able to represent that we want security for a single hop
in a URI ( could be a request URI or route or others)

Solution 1
make the transport tag be one of UDP, TCP, SCTP, DCCP and add a security tag
that could be TLS
sip:[email-masked];transport=SCTP;security=TLS

Solution 2
define some more transports of udp+tls sctp+tls, dccp, dccp+tls. Note that
tls alone means tls over tcp.
sip:[email-masked];transport=SCTP+TLS
Also a URL with transport=+TLS would mean that any transport could be used
but it must include TLS.

Given we have two security protocols (nothing and tls) and a handful of
transports (UDP, TCP, SCTP, DCCP) - Solution A and 2 could work without an
explosion of labels. Solution 1 is tricky to make sure no one ever sends
transport=tcp;security=tls to someone expecting transport=tls. Solution B
will no doubt break someone who gets a "Via: SIPS/2.0/TCP" on a TLS
connection. Solution C would be the right things if we went with Solution 2
instead of Solution 1.

Sorry this is such a disorganized email. Thoughts?

Thanks, Cullen

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 25 Nov 2003 16:35:27 -0600

> enterprise proxies that do TLS protection across the internet.

At least this particular configuration is mitigated by loose-
routing the enterprise proxies.  The problem is, of course, how
does A know the URI of B's enterprise proxy in any authoritative
manner (outside of the 3GPP extensions)?  It could always guess
and construct a request of the form:

    INVITE sip:[email-masked] SIP/2.0
    Route: <sips:domain-b.com>
    ...

and send it using TLS to B's enterprise proxy, which then delivers
it to B.  At least the request transits the network in a secure
manner.

Alternatively, B can publish a URI of the form:
    sip:[email-masked]?Route=sips:domain-B.com

But I am unsure how many current UACs would form the correct
request given the above URI.  And furthermore, B has to be
cognizant enough to know that her UA does not support TLS but
her enterprise proxy does so she can leverage this knowledge
in publishing such a URI.

> There is also the Via problem...
[...]
> There are backwards compatibility issues with all of these.

Yes, although Solution C is probably the least intrusive.
Implementations that don't understand "security=TLS" parameter
will simply ignore it (and hopefully, re-generate it if they
are an intermediary).

> Next we need to be able to represent that we want security for a single 
> hop in a URI ( could be a request URI or route or others)
> 
> Solution 1
> make the transport tag be one of UDP, TCP, SCTP, DCCP and add a security 
> tag that could be TLS
> transport=tcp;security=tls to someone expecting transport=tls. 

For that reason I prefer Solution 2 since it specifies a transport
plus a security tag.  But, the biggest problem is that these are
not backwards compatible to deployed gear.  So, besides an
academic exercise in curiosity, what are the chances of
implementation?

It appears to me that the most ubiquitous and least intrusive
solution is to use some form of loose source routing to
protect the requests in portions of the network that are not
completely trustworthy.

- vijay
-- 
Vijay K. Gurbani  vkg@{lucent.com,research.bell-labs.com,acm.org}
Wireless Networks Group/Internet Software and Services
Lucent Technologies/Bell Labs Innovations, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216

---

From: Cullen Jennings <[email-masked]>
Date: Tue, 25 Nov 2003 17:14:27 -0800

> academic exercise in curiosity, what are the chances of

There is not really any SCTP or TLS over SCTP or UDP or DCCP deployed so I
think we could be backwards compatible with existing TLS stuff. I'm not
seeing a way to be backwards compatible with everything but the current
stuff looks broken so I think the odds of something other than what is
currently specified deploying are fairly high. This is not a "I don't like
the current thing issues" this is the current thing can't construct a usable
via for a stateless proxy using SCTP with TLS.