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

From: Robert Sparks <[email-masked]>
Date: Mon, 4 Jun 2007 10:00:29 -0500

Well, here are a couple of situations that people have repeatedly  
brought up at SIPits. (Keep in mind that I'm
passing this along, not championing any points).

1) Some still have to operate in an environment that has no DNS, even  
in the core.
      Their customers are demanding transport=tls to control the use  
of tls over one hop in this situation.

2) Some have indicated they operate in large enterprise-like  
networks, where the endpoint has an ephemeral address,
      one for which there's no way to populate NAPTR/SRVs to indicate  
a use of TLS when reaching that endpoint.
      Additionally, the endpoint has a cert (!).  They are required  
to register a contact that causes them to be reached
      with TLS, and are using transport=tls to do so.

RjS

On May 31, 2007, at 10:58 AM, Dean Willis wrote:

>
> A new version of the SIPS draft has been posted:
>
> http://www.ietf.org/internet-drafts/draft-ietf-sip-sips-04.txt
>
> The author thinks this is ready for last call. I think that, given  
> the below discussion, it probably is too. But there is one issue  
> I'm worried about.
>
> We know it doesn't fix everything, we're not sure it is possible to  
> fix everything with SIPS, but we are committed to fixing what we  
> can. So please don't bother to say it isn't worth the effort since  
> it doesn't make SIPS perfect -- you might be right, but that alone  
> is insufficient reason to block things. One step at a time. I'm  
> sure we'll be taking further steps in this space.
>
> Now, for te issue I'm worried about:
>
> I have received some personal feedback from more than one credible  
> source that the draft's direction on transport=tls is inconsistent  
> with the real world and possibly not optimal. But so far, Juha has  
> been the only one I've noticed trying to explain this issue "on the  
> record", and one voice does not overbalance a quiet consensus. So  
> I'd like to ask the rest of you (if any) who actually feel this way  
> to step up to the plate and explain what you're talking about,  
> because I don't get it and it looks like a bunch of the WG doesn't  
> get it. Please! If you don't step up now, I'm probably going to  
> make rude "raspberry" noises if you bring it up someplace like  
> Chicago.
>
>
> --
> Dean (chair hat stapled to head so it doesn't blow off in the  
> coming storm)
>
>
> _______________________________________________
> 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

_______________________________________________
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: "Francois Audet" <[email-masked]>
Date: Mon, 4 Jun 2007 11:00:36 -0500

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]] 
> Sent: Thursday, May 31, 2007 08:59
> To: SIP IETF
> Subject: [Sip] Ready for WGLC on SIPS draft? Any last 
> thoughts on transport=tls?
>
> I have received some personal feedback from more than one 
> credible source that the draft's direction on transport=tls 
> is inconsistent with the real world and possibly not optimal. 
> But so far, Juha has been the only one I've noticed trying to 
> explain this issue "on the record", and one voice does not 
> overbalance a quiet consensus. So I'd like to ask the rest of 
> you (if any) who actually feel this way to step up to the 
> plate and explain what you're talking about, because I don't 
> get it and it looks like a bunch of the WG doesn't get it.  
> Please! If you don't step up now, I'm probably going to make 
> rude "raspberry" noises if you bring it up someplace like Chicago.

2 comments and a request...

Comment: Indeed, the use of transport=tls seems fairly widespread.
   1     However, it is not clear at all to me that it is use
         consistently accross different implementations. In fact, I'm
         pretty sure it's not.

Comment: The concept of "one hop" with transport=tls is tricky. The
presence
   2     of transport=tls in a URI would presumably apply to the hop
         identifying that resource (i.e., the last hop), as opposed to
         the first hop. Latest draft (-04) discusses this.

Request: If people make comments on the use of transport=tls, please
         be very specific on where you are envisioning it's usage, e.g.,
         Request-URI, Contact in Register, Contact in dialog-creating
         request, Record-Route, etc. It makes a big difference.

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 4 Jun 2007 19:39:29 +0300

>          request, Record-Route, etc. It makes a big difference.

cases where we use transport=tls is in request uri.

-- juha

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 4 Jun 2007 12:28:05 -0500

> 1) Some still have to operate in an environment that has no 
> DNS, even in the core.
>       Their customers are demanding transport=tls to control 
> the use of tls over one hop in this situation.

Which hop???

UAC -----> Proxy 1  ------> Proxy 2 ------> UAS

If you put Request-URI of sip:[email-masked];transport=tls, to me, it
means the link between Proxy 2 and UAS would use TLS. I.e., the
parameter would apply to the
resource identified in the URI.   (I'm assuming Record-Routing is used
here).

The first hop (between UAC and Proxy 1) is basically what you would
select before sending the message (or if a Route header was used, it
would be in the Route
header). To me, it's self-evident in the actual transport anyways.

Everytime I run into this issue, it seems to me that basically what
people
are asking for is just a way to select TLS for the first hop. We don't
need
protocol on the wire for this: just a config option in the UAC.

>       one for which there's no way to populate NAPTR/SRVs to 
> indicate a use of TLS when reaching that endpoint.
>       Additionally, the endpoint has a cert (!).  They are 
> required to register a contact that causes them to be reached

Surely they need to register with TLS for this to be secure. 
The transport could be self-evident again, from the one used
while performing the registration.

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 4 Jun 2007 21:05:16 +0300

> UAC -----> Proxy 1  ------> Proxy 2 ------> UAS

for example, lets say that UAS is pstn gw that needs to be contacted
over tls.  proxy 1 makes a decision to use this particular pstn gw,
rewrites r-uri so that it among other things contains transport=tls
parameter, and then forwards the request to proxy 2 that is a "dumb"
proxy whose purpose is to front end the gw.

i don't know another way to do this because sip uri scheme cannot be
upgraded to sips and sips scheme cannot be downgraded to sip.

-- juha

---

From: Robert Sparks <[email-masked]>
Date: Mon, 4 Jun 2007 13:08:15 -0500

>> the use of tls over one hop in this situation.

Any of them - Be sure to notice the lack of DNS there.

> UAC -----> Proxy 1  ------> Proxy 2 ------> UAS

How (if they don't have DNS) do they specify the use of TLS between  
Proxy1 and 2?
   More specifically - if Proxy1 retargets an initial request to  
Proxy2 based on either
    configuration or a registered contact, what's the RURI of the  
emitted request going to be?
   Then, what should it record route with?
> header). To me, it's self-evident in the actual transport anyways.

I don't understand the last sentence - especially in the record-route/ 
route case.

> protocol on the wire for this: just a config option in the UAC.

This is not what I'm pointing at.
> while performing the registration.

So the unusual case here is that it _is possible_  (and even
meaningful) for the proxy to open a new connection to the UA
if the old one is gone. Are you saying that you would like the
proxy/registrar to remember that it should use TLS when it did so
as a side-effect of the registration arriving over TLS?

That would be a way we could go (and we should go all the way
and ignore what's in contact altogether if we go here), but you will
have to explicitly make 3rd party registration and any registration
that installs state that doesn't point exactly to the registering  
instance
illegal. (I know several people think this is a good idea, but I  
don't think
we've made that the official position of the working group yet have we?)

RjS

---

From: "Bob Penfield" <[email-masked]>
Date: Mon, 4 Jun 2007 14:09:57 -0400

I have seen cases where transport=tls appears in the Record-Route where one 
hop between proxies uses TLS. For example:

  UAC--<TCP>-->Proxy1---<TLS>--->Proxy2--<TCP>--->Proxy3---<TCP>-->UAS

This is done using a SIP URI (not SIPS).

I have not been able to keep up with this discussion, but the question I 
have is: without transport=tls, how would you express the desire/need to do 
TLS for a SIP URI in a Record-Route or Route header? I am talking about a 
case where the proxy (Proxy2 above) supports TCP and TLS, but the selection 
of transport is made for the initial INVITE, and that same transport needs 
to be used for in-dialog requests?

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
71 Third Avenue
Burlington, MA 01803
[email-masked]

----- Original Message ----- 
From: "Francois Audet" <[email-masked]>
To: "Robert Sparks" <[email-masked]>; "Dean Willis" 
<[email-masked]>
Cc: "SIP IETF" <[email-masked]>
Sent: Monday, June 04, 2007 1:28 PM
Subject: RE: [Sip] Ready for WGLC on SIPS draft? Any last thoughts 
ontransport=tls?

Which hop???

---

From: Robert Sparks <[email-masked]>
Date: Mon, 4 Jun 2007 13:13:39 -0500

Juha -

The classic answer for this is that the gateway should have a DNS  
name with its NAPTR and SRV
records configured to specify exactly TLS. Do you agree that if you  
have DNS available, that's good
enough?

I think you're pointing to specifically the case where you don't have  
DNS records pointing to UAS,
is that correct?

RjS

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 4 Jun 2007 21:30:13 +0300

> have DNS available, that's good

it would be good enough if we had client and server srv records
separately, but unfortunately we don't.  currently there is no dns way
to tell "i want my proxy to be contacted by other proxies using tls and
by UAs using udp or whatever else.  so proxies have to use all kinds
configured information to figure out the transport protocol to their
peers.

-- juha

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 4 Jun 2007 13:46:59 -0500

> From: Bob Penfield [mailto:[email-masked]] 
> Sent: Monday, June 04, 2007 11:10
> To: Audet, Francois (SC100:3055); Robert Sparks; Dean Willis
> Cc: SIP IETF
> Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last 
> thoughts ontransport=tls?
> 
> I have seen cases where transport=tls appears in the 
> Record-Route where one hop between proxies uses TLS. For example:
> 
> I have not been able to keep up with this discussion, but the 
> question I have is: without transport=tls, how would you 
> express the desire/need to do TLS for a SIP URI in a 
> Record-Route or Route header? I am talking about a case where 
> the proxy (Proxy2 above) supports TCP and TLS, but the 
> selection of transport is made for the initial INVITE, and 
> that same transport needs to be used for in-dialog requests?

I'd say you use no transport parameter in the Record-Route and you
do what 3261 recommends, which is to reuse the same TCP connection
(TLS on this case) for in-dialog requests.

Also, I'd like to point out that since Record-Route is by definition
hop by hop, in that case sips would mean exactly the same as 
transport=tls.

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 4 Jun 2007 14:16:16 -0500

> From: Robert Sparks [mailto:[email-masked]] 
> Sent: Monday, June 04, 2007 11:08
> To: Audet, Francois (SC100:3055)
> Cc: Dean Willis; SIP IETF

>     configuration or a registered contact, what's the RURI of 
> the emitted request going to be?

I'm not sure I understand what we are trying to achieve here.

Say UAC sends initial INVITE.

It chooses TLS for transport. No transport parameter. UAC does not
use SIPS and therefore does not expect TLS on each hop.

Proxy 1 forwards the request to proxy 2. If may or may not
use TLS (although it should use TLS if possible). It inserts
a Record-Route (or modifies Request-URI). In either cases, it does
not need to put a transport parameter.

Later, in-dialog request will be sent on each hop reusing the existing
established connections (TLS or TCP) as per current RFC 3261 
procedures.

Or are we talking pass each other?

> > If you put Request-URI of 
> sip:[email-masked];transport=tls, to me, it 
> > would be in the Route header). To me, it's self-evident in 
> the actual 
> > transport anyways.
> 
> I don't understand the last sentence - especially in the 
> record-route/ route case.

I'm just saying the first hop is whatever is selected when you
sent the message. Since it's the first hop, there the parameter would
be useless.

> > people are asking for is just a way to select TLS for the 
> first hop. 
> > We don't need protocol on the wire for this: just a config 
> option in 
> > the UAC.
> 

I'm trying to understand what you are pointing at. Is it 
in-dialog requests? Is it forcing a specific hop (not the first or
last one) to be TLS, but not all the hops?

I think I'm missing something...

> required 
> > The transport could be self-evident again, from the one used while 
> > performing the registration.
> 
> if the old one is gone. Are you saying that you would like 
> the proxy/registrar to remember that it should use TLS when 
> it did so as a side-effect of the registration arriving over TLS?
>
>
> and ignore what's in contact altogether if we go here), but 
> you will have to explicitly make 3rd party registration and 
> any registration that installs state that doesn't point 
> exactly to the registering instance illegal. (I know several 
> people think this is a good idea, but I don't think we've 
> made that the official position of the working group yet have we?)

I was not thinking specifically of the Mutual-TLS case which is what
you are pointing to.

In the server-provided certificate case, the client would be responsible
to re-establish the TLS connection. The way to do this for
server-provided
certificate environments is using sip-outbound which does exactly what
you said (i.e., ignore the contact). The the registrar doesn't 
"remember" anything: it just uses existing connections.

I tought that was agreed (in Montreal). I don't see any other way to be
honest.

Now, you do bring up a really good point for environments where people
use Mutual-TLS between a proxy and a UA. I guess we could still use an
outbound
model for this case. Or we could use some indication in the protocol.
Not sure it's worth it to add a transport parameter for that. Seems to
me to
be overly complex, and it wouldn't allow you to indicate that you 
support many different transport.

The third party registration case with the transport parameter is weird
to
me. It would allow a UA to send a Registration unseculily (over TCP or
UDP), and
create a binding for a third party using TLS. Seems like it would make
the TLS
connection pointless (unless somehow the first party is secure some
other way).

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 4 Jun 2007 22:41:38 +0300

> established connections (TLS or TCP) as per current RFC 3261 

what if established connection breaks for one reason or another and
needs to be re-established for routing in-dialog request?  if there is
no transport info in request route, how does the proxy know which
transport to use?

-- juha

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 4 Jun 2007 14:53:26 -0500

If it uses Outbound, then connection gets re-established by 
client automatically (based on keep-alives).

Otherwise, correct, you don't know.

I guess the real question is "do we need to solve this case"?

I guess to me it means that it would be useful only for 
mutual TLS cases. Is this big enough of a problem to justify
the expense of having to deal with the parameter?

That's a question for the group. I don't have a strong opinion
on it (just a preference for using Outbound for this).

> From: Juha Heinanen [mailto:[email-masked]] 
> Sent: Monday, June 04, 2007 12:42
> Cc: Robert Sparks; SIP IETF; Dean Willis
> Subject: RE: [Sip] Ready for WGLC on SIPS draft? Any last 
>  > Later, in-dialog request will be sent on each hop reusing 
> the existing  > established connections (TLS or TCP) as per 
> current RFC 3261  > procedures.
> 
> what if established connection breaks for one reason or 
> another and needs to be re-established for routing in-dialog 
> request?  if there is no transport info in request route, how 
> does the proxy know which transport to use?
> 
> -- juha
>

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 4 Jun 2007 23:03:28 +0300

> the expense of having to deal with the parameter?

proxy-to-proxy communication is important enough case to justify the
transport=tls parameter.

-- juha

---

From: Robert Sparks <[email-masked]>
Date: Mon, 4 Jun 2007 15:09:23 -0500

What's missing from this, Francois, is how the proxy knows to set up  
the RR with tls in the first place.
i.e. when it retargets how does it _know_ it's retargetting to  
something over tls vs tcp.
I disagree that implementation specific configuration is a good  
enough answer.
I'm happy with the answer "you set this information in DNS" when you  
have DNS.
What I'm not seeing is how you set this when you don't have DNS.

RjS

On Jun 4, 2007, at 1:46 PM, Francois Audet wrote:

>>   UAC--<TCP>-->Proxy1---<TLS>--->Proxy2--<TCP>--->Proxy3---<TCP>-- 
>> >UAS
>>

---

From: Robert Sparks <[email-masked]>
Date: Mon, 4 Jun 2007 15:12:22 -0500

> not need to put a transport parameter.

This is exactly where we are disagreeing.

How do you _tell_ P1 that you want to reach P2 using TLS in the first  
place.
As I said elsewhere in the thread, I don't think leaving this  
unspecified ("you just do this
with the configuration of the proxy") is the right answer. If you  
have DNS, you tell P1
about P2 using DNS. If you don't have DNS, using the transport  
parameter in the URI
you hand it seems pretty natural. That's how you're going to tell it  
to use udp or tcp...

> Or are we talking pass each other?
Almost certainly. I hope the above helps us get to a common question.

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 4 Jun 2007 15:13:16 -0500

But for that, you can use SIPS in Record-Route, no?

It would be semantically identical, no?

> Sent: Monday, June 04, 2007 13:03
>  > I guess to me it means that it would be useful only for  > 
> proxy-to-proxy communication is important enough case to 
> justify the transport=tls parameter.
> 
> -- juha
>

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 4 Jun 2007 23:15:29 +0300

> I disagree that implementation specific configuration is a good  

as i wrote earlier, the problem is lack of server srv records, which
forces proxy operators to configure (usually in db or radius) what to do
with their peers.

please first fix server srv records and then you can disagree.

-- juha

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 4 Jun 2007 23:19:13 +0300

> 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

---

From: Robert Sparks <[email-masked]>
Date: Mon, 4 Jun 2007 15:19:31 -0500

I don't know what you mean by server srv records.

Any name can have SRV records. What distinguishes a server srv record  
from any other srv record to you?

RjS

---

From: [email-masked] (Juha Heinanen)
Date: Mon, 4 Jun 2007 23:40:17 +0300

> from any other srv record to you?

xmpp client to server communication uses name
_xmpp-client._tcp.example.com and server to server communication nane
_xmpp-server._tcp.example.com.  this allows different proxies to be used
for client-to-server and server-to-server communication.

-- juha

---

From: Robert Sparks <[email-masked]>
Date: Mon, 4 Jun 2007 15:44:42 -0500

Ah - that doesn't make sense for SIP in general.

You can make it make sense for certain deployments, and what you can  
do in those cases
is give your client facing interface one name and your server facing  
interface another.

Something like
_sip._tcp.client-interface.example.com
_sip._tcp.server-interface.example.com

So, what else are you missing?

RjS

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 5 Jun 2007 00:04:46 +0300

> _sip._tcp.server-interface.example.com

how do you tell your sip client to use the former name its srv queries?
in xmpp it is specified that in client srv query, a prefix _xmpp-client
prefix is always added to the name.

-- juha

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Mon, 4 Jun 2007 23:02:57 +0200

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:
> 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
>
>

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Mon, 4 Jun 2007 23:20:43 +0200

Juha,

For clients one would distribute "client-interface.example.com" as the 
outbound proxy FQDN to use, and upstream proxies would be given 
"server-interface.example.com" (by using that as domain in AORs).

For R-R, the proxy would use "client-interface.example.com" if it performed 
a location service lookup (i.e. assuming that next hop is then an endpoint), 
or "server-interface.example.com" otherwise.

Nevertheless, in the R-R it would probably be better to be explicit about 
the transport to use, and not rely on DNS SRV. Then there is no need to 
worry about client vs server interface protocol preferences, or proxies that 
use dynamic registration, or DNS SRV misconfiguration or lack of support for 
it.

Regards,
Jeroen

Juha Heinanen wrote:
> how do you tell your sip client to use the former name its srv
> queries? in xmpp it is specified that in client srv query, a prefix
> _xmpp-client prefix is always added to the name.
>
> -- juha
>
>

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 5 Jun 2007 00:25:26 +0300

> "sips:host[:port];transport=tcp", there is no implication of transport in 

jeroen,

i agree with the above, but it only solves the r-r case.  i cannot use
sips + transport=tls as a substitute of transport=tls[/tcp] in request uri
because of sips upgrade/downgrade implication.

-- juha

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 4 Jun 2007 16:30:24 -0500

> How do you _tell_ P1 that you want to reach P2 using TLS in 
> the first place.
> unspecified ("you just do this with the configuration of the 
> proxy") is the right answer. If you have DNS, you tell P1 
> about P2 using DNS. If you don't have DNS, using the 
> transport parameter in the URI you hand it seems pretty 
> natural. That's how you're going to tell it to use udp or tcp...

I think I finally understand what you are saying...

Say UAC sends request to Request-URI uas@p2;transport=tls.

The transport parameter indicates that the resource in the
request URI (uas@p2) is the one that needs to be contacted with
TLS. Therefore, it would be the P1 -> P2 link that would use
TLS in this case (since P2 owns that domain). And P2 could use whatever 
it wants for P2 -> [email-masked]. And similarly, uac -> P1 (or P1 to any
other
proxy between P1 and P2) could use whatever they want.

The use case would be where the UAC "trust" it own domain and does not
feel it necessary to use TLS, and/or the UAC "trusts" the target domain
for being responsible of that happens inside the target domain. And
finally,
the UAC does not really care if there are other types of proxies in the
middle (not responsible for a specific domain), that may not use
TLS.

While I understand that this is in theory something that could be
solvable, I'm not sure why it is such an interesting case. Seems to me
it is only of value if the only "vulnerable" hop is the one between the
source and target domains, and if there are no other proxies between
them
(e.g., no "Service provider").

In fact, it pretty much describes to me why you should be using SIPS in
the first place.

Do we *really* want to reintroduce transport=tls for this case?

Side note: I just want to point out that RFC 2543 did NOT allow the 
presence of the transport parameter at all in a Request-URI and 2543
servers would ignore it or remove it.

---

From: Robert Sparks <[email-masked]>
Date: Mon, 4 Jun 2007 16:55:01 -0500

Ok - we're closer, but not quite together yet.

Lets start with a different message from the UAC where the RURI is  
simply
sip:something@P1

The authority for something@P1 (the person that might send a register  
request
with that in the To: header) wants requests to go to  
sip:someapplication@P2
and they want it to go over TLS. What they'd _like_ to do is send a  
register
request with a contact that says to use TLS, or at most, send a  
single URI
to the operators of P1 that describes where to send requests that  
show up
for something@P1.

What tools do we give them to make the statement they want to make?

RjS

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 4 Jun 2007 17:34:59 -0500

Ok, so it has nothing to do with Request-URI then (which is what I
tought
we were talking about).

I don't believe that using transport=tls in Contact for
Registration will generally work.

There are 2 cases:

>From == To in REGISTER (First Party Registration)
-------------------------------------------------

	In this case, if we use SIP-Outbound, we DO already
	have a solution.

	With SIP-outbound, the connection used by the registration
	process is kept alive and reused for both incoming and 
	outgoing requests.

	It has the advantage that it will support environments 
	where server-provided certificates are used since
	the TLS connection will only be establishable by the
 	client.

	A a bonus, SIP-outbound also solves NAT and FW traversal, if 
	there happens to be one.

	Their proposed solution of using a transport parameter
	will not work for server-provided certificates as the 
	server will not be able to establish a connection with
	the client. Since server-provided certificates is by far
	the most commone deployment scenario (as opposed to 
	Mutual TLS) for UAs, this is a big problem.

	Their proposed solution wouldn't work either if there is
	a NAT or Firewall. Again, big problem.

	Their proposed solution would therefore ONLY be 
	suitable for environments where Mutual TLS is used, and
	where there are no NATs or Firewall.

	The SIP-outbound mechanism also works with Mutual TLS.

	Therefore, for this case, I do not believe that their
	mechanism is general enough to be standardized.

	This is described at lenght in the draft.

>From != To in REGISTER (Third Party Registration)
-------------------------------------------------

	Third party registration is problematic for both their
	proposed solution, as well as for SIP-outbound.

	For SIP-outbound, well, it plainly doesn't work.

	For their proposed solution, it is a security problem
	since it effectively allows a non-secure user (the "authority"
	as you call it), to request that session be delivered securily.
	Dr, Evil person could hijack the "authority" role and redirects
	all sessions to wherever it wants, and the sessions would be
	"secured" with Dr. Evil.

	Furthermore, their proposed solution would not work in this 
	case either with server-provided certificates, or if there
	is a NAT or Firewall. Again, big problem.

	To me, it means that Third Party Registration is just plain
	bad in a secure environment. 

	In fact, I don't like the idea of allowing third party 
	registration to allow a UAC with AOR in p1 domain to 
	register a contact in a different domain (p2 in this case).
	That contact is effectively an AOR. 

	How would I solve the problem? 

	I would expect the other UA (sip:someapplication@P2) to do it's 
	own registration in it's own domain P2, according to the rules
of it's
	own domain. If P2 is using server-provided certificates, it
would
	work (with Outbound). If a NAT is present, it would works as
well.

      Then, I would allow user "something@P1" to log in securily 
	on the Proxy (with HTTPS for example), and request routing to 
	be done to another address (in this case,
sip:someapplication@P@).
	To ensure that P1 would use TLS to P2 (as they want), I'd just
put
	a "User TLS" checkbox.

	That seems to me to be a lot less broken that trying to squeeze
it
	into third-party REGISTER.

> Sent: Monday, June 04, 2007 14:55
> Lets start with a different message from the UAC where the 
> RURI is simply
> sip:something@P1
> 
> The authority for something@P1 (the person that might send a 
> register request with that in the To: header) wants requests to go to
> sip:someapplication@P2
> and they want it to go over TLS. What they'd _like_ to do is 
> send a register request with a contact that says to use TLS, 
> or at most, send a single URI to the operators of P1 that 
> describes where to send requests that show up for something@P1.
> 
> >> proxy") is the right answer. If you have DNS, you tell P1 about P2 
> >> using DNS. If you don't have DNS, using the transport parameter in 
> >> the URI you hand it seems pretty natural. That's how 
> you're going to 
> >> tell it to use udp or tcp...
> >
> >
> request URI 
> > (uas@p2) is the one that needs to be contacted with TLS. 
> Therefore, it 
> > would be the P1 -> P2 link that would use TLS in this case 
> (since P2 
> > owns that domain). And P2 could use whatever it wants for P2 -> 
> > [email-masked]. And similarly, uac -> P1 (or P1 to any other proxy 
> > between P1 and P2) could use whatever they want.
> >
> > feel it necessary to use TLS, and/or the UAC "trusts" the target 
> > domain for being responsible of that happens inside the 
> target domain. 
> > And finally, the UAC does not really care if there are 
> other types of 
> > proxies in the middle (not responsible for a specific domain), that 
> > may not use TLS.
> >
> > it is only of value if the only "vulnerable" hop is the one between 
> > the source and target domains, and if there are no other proxies 
> > between them (e.g., no "Service provider").
> >
> > In fact, it pretty much describes to me why you should be 
> using SIPS 
> > in the first place.
> >

---

From: Robert Sparks <[email-masked]>
Date: Mon, 4 Jun 2007 17:52:26 -0500

> Ok, so it has nothing to do with Request-URI then (which is what I

Well, we're still not connecting quite yet.

It has _EVERYTHING_ to do with Request-URI.

It is coincidence that I'm populating what the RURI will
be after retargetting with a REGISTER. It could have been
any other mechanism. The important part is what comes
out into the Request-URI of the P1->P2 link.

> Registration will generally work.
(as you read my inline responses below, ask yourself what
  =tls has to do with what you wrote - I think I can substitute =tcp,
    which we _do_ allow, and everything but the comments about
    mutual or server auth still stand)
> From == To in REGISTER (First Party Registration)
Surely you're not suggesting proxies do outbound between them.
You're latching onto the endpoint case. I'm talking about a server to  
server case.

> From != To in REGISTER (Third Party Registration)

This is getting closer to the P1->P2 hop, but its a bit of a herring  
that
you've separated 1st and 3rd party registration. I could have  
something@P1
in both to: and from: and still point it at application@P2.

I understand where you are going with "make that a checkbox on  
somebody's GUI" and
that's exactly what I'm saying isn't good enough. The preference  
needs to be reflected in the URI.

For the registration case, binding things between P1 and P2, let me  
try yet another way to say this.

It's in the field.
People are USING it.
We are trying to say "Don't do that" without giving an alternative  
that works in that scenario.
We will be ignored unless we can present a clear and compelling  
reason why someone
is putting life or limb at risk to do this (and I suspect we'll be  
ignored even then).

I'm not sure I can make any such argument around just this transport  
parameter. If we're
going to allow someone to say "udp" or "tcp" in this case, its rather  
pointless to not let them
say tls (with the appropriate caveats around not having the anchor in  
DNS to verify who
you're talking to).

I _can_ make an argument around the notion of putting state in that  
doesn't point directly to you,
but that goes way way beyond just the transport parameter, and if  
we're going to go there, we
need to start an entirely different conversation that will take the  
transport parameter completely
off the table for _any_ transport.

RjS

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 5 Jun 2007 00:55:38 +0200

Juha (and Francois),

What I miss in the discussion and draft is the reason why transport=tls was 
deprecated, namely that TLS by itself is not a transport. The transport is 
either TCP or SCTP, TLS is the security layer on top of that

The "TLS" value for Via transport in RFC3261 should really be read as 
"TLS-TCP", just like there is now TLS-SCTP defined in RFC4168. The latter 
does *not* define a "tls-sctp" value for the 'transport' parameter (i.e. 
does not extend the definition for 'transport-param'), because it is not 
needed: the use of TLS is solely determined by the URI scheme

"sip"  ==> you MAY use TLS (but then upgrade the scheme to "sips:" in the 
request sent out)
"sips"==> you MUST use TLS (with possible exception for last hop, i.e. sips 
request URI rewritten by proxy to a sip URI obtained from a registered 
Contact)

RFC3261 also implicitly discusses the possibility of a "first hop 
exception", i.e. a UAC using a "sips:" scheme but not TLS (16.6 point 4). 
Note that it does not consider the reverse case of using TLS without "sips:" 
as scheme. Some implementations may use 'transport=tls' for this case, but 
it is - and should remain - deprecated (i.e. ignored if received, never 
generated).

For received Contact and Record-Route headers, it should be mandatory to 
maintain state information regarding the transport that was used towards 
that hop, and whether TLS was used or not. These are 2 separate items. The 
latter is covered by the "secure" flag in RFC3261, for proxies RFC3261 
assumes that "sips <==> use TLS" holds, so there is no need for separate 
state for proxies regarding the use of TLS.

Regards,
Jeroen

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 4 Jun 2007 19:14:47 -0500

Hi Robert,

I understand what you are saying. And you are right: my point about
Third 
party registration was a red herring: it's really the Contact being 
different than the source of the REGISTER that is a problem).

But frankly, the transport parameter in general IMHO is a problem. The
fact that SIP isn't layered properly on top of TCP (or UDP) is the 
issue frankly.

In a world where there are no NATs, no FW and every Joe has it's own
user certificate, we could make the transport parameter work.

If we re-introduce transport=tls, then we'll have to explain when it
will
work. We will have to write big caveats that it won't work unless you
have no NAT, no Firewall, and you are using Mutual-TLS with User 
certificates for the UAs. In general, it won't work.

In my mind, we would be doing a disservice to the industry by writing
protocol to do something that almost never works. The "But I can do it 
today in the field (but just for TCP)" doesn't hold water, because TLS
is not TCP. 

Furthermore, this "transport=tls" stuff is not documented anywhere in
any RFC. So we would be writing from scratch broken procedures to
"document" broken practices in the field. Seems insane to me. 

The clear and compelling reason to not use "transport=tls" is that it
won't generally work, except for very contrived scenarios.

PS: "Transport=tls" was "deprecated" in RFC 3261, but it didn't exist 
     either in its predecessor RFC 2543. It was only defined in the
     the draft-ietf-sip-rfc2543bis-00. So the implementations that use
     it today do not conform to any RCF, obsolete or otherwise.

> Sent: Monday, June 04, 2007 15:52
> > tought we were talking about).
> 
> It is coincidence that I'm populating what the RURI will be 
> after retargetting with a REGISTER. It could have been any 
> other mechanism. The important part is what comes out into 
> the Request-URI of the P1->P2 link.
> 
> >
> You're latching onto the endpoint case. I'm talking about a 
> server to server case.
> 
> >

---

From: Thomas Froment <[email-masked]>
Date: Tue, 05 Jun 2007 11:27:18 +0200

Jeroen van Bemmel wrote:
> For R-R, the proxy would use "client-interface.example.com" if it 
> performed a location service lookup (i.e. assuming that next hop is 
> then an endpoint), or "server-interface.example.com" otherwise.
>
> Nevertheless, in the R-R it would probably be better to be explicit 
> about the transport to use, and not rely on DNS SRV. Then there is no 
> need to worry about client vs server interface protocol preferences, 
> or proxies that use dynamic registration, or DNS SRV misconfiguration 
> or lack of support for it. 
I agree with the last point, but does everybody agree?
I would really like to know because this exactly the type of scenario I 
would like to see clarified in draft-froment-sip-record-route-fix-00...

Thomas

---

From: Aki Niemi <[email-masked]>
Date: Tue, 05 Jun 2007 12:39:05 +0300

> Ah - that doesn't make sense for SIP in general.

I rather think it makes perfect sense. With sip-outbound we have what in 
practical terms are two different SIP interfaces already; a 
client-server interface for UAs that REGISTER to the domain, and a 
server-server interface for outside-in traffic like INVITEs from other 
UAs (read: servers by whom other UAs send their sip-identity signed 
traffic).

> You can make it make sense for certain deployments, and what you can do 
> in those cases

A standard mechanism to configure the UAs of your domain to use 
_sip._tcp.client-interface.example.com, while the rest of the world uses 
  _sip._tcp.server-interface.example.com.

Cheers,
Aki

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 5 Jun 2007 16:45:32 +0300

> "server-interface.example.com" (by using that as domain in AORs).

i don't get this.  the domain of SIP UAs' SIP uris is example.com for
which the queries are done, not something else.  clients would need to
prefix that with _sip-client and servers with _sip-server.  currently
there is no standard for that.

-- juha

---

From: Robert Sparks <[email-masked]>
Date: Tue, 5 Jun 2007 08:48:49 -0500

> certificates for the UAs. In general, it won't work.

So I understand your position on how this affects devices we expect to
be behind transport-destroying elements and that we don't expect to
generally have certificates.

What about the proxy->proxy (or some stable network server) hop, where
we expect there _isn't_ a transport-destroying intermediary (hah) and  
that
we expect they _do_ have certificates? This is the case where I think we
have a real constituency (with real applications) that we're harming.

Consider the routing decision that P1 needs to make. The tools we have
allow P1 to choose among the protocols it knows how to use by  
administrative
configuration. They let P2 express policy about which protocols P1  
should use
(through DNS). What they don't do is let P1 choose between protocols  
based
on a user's (or application's) input.

We've got this concept of a location service that you access using  
REGISTER.
The spec talks about running it separately from a proxy - so consider  
the case
where  a proxy either does query REGISTERs or sends a request to a  
redirect
server to figure out where it's supposed to go. What it gets back is  
URIs in
Contact header fields. How can the location service tell the proxy  
that's asking
for a routing decision that "for this input URI, goto this output URI  
and use TLS"?

RjS

---

From: "Steve Langstaff" <[email-masked]>
Date: Tue, 5 Jun 2007 06:53:53 -0700

>  > For clients one would distribute 
> "client-interface.example.com" as the  > outbound proxy FQDN 
> to use, and upstream proxies would be given  > 
> i don't get this.  the domain of SIP UAs' SIP uris is 
> example.com for which the queries are done, not something 
> else.  clients would need to prefix that with _sip-client and 
> servers with _sip-server.  currently there is no standard for that.

When you say "clients" and "servers", do you mean UACs and UASs, or some
other use of the words?

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 5 Jun 2007 17:37:45 +0300

> When you say "clients" and "servers", do you mean UACs and UASs, or some

client is sip ua and server is a sip proxy.  see sections 14.3 and 14.4
of rfc 3920.

-- juha

---

From: "Gilad Shaham" <[email-masked]>
Date: Tue, 5 Jun 2007 15:46:04 +0100

I can add even more complications (even though it seems complicated
enough, but what the heck).
What if we want to specify the encryption level (e.g. 40 bits or 128
bits)? What if we want to specify IPSec?

It seems to me that transport=tls in the request URI causes a lot of
historical issues. Maybe there is a need for a feature tag/header that
defines the allowed secure methods for examples:
Unencrypted, tls, ipsec
The proxy would then be free to do whatever lookup method it wants (via
DNS, according to outbound or any policy) and it will forward the
request only if there is an option within one of the possible values it
received on the request.

Just a thought, I hope it helps.

> Sent: Tuesday, June 05, 2007 4:49 PM
> To: Francois Audet
> Cc: SIP IETF; Dean Willis
> Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last thoughts
> ontransport=tls?
> 
>

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 5 Jun 2007 18:37:00 +0200

Juha,

In that case "example.com" would be the server interface (and configured as 
such in DNS SRV). Clients would be given "x.example.com", where x can be 
anything you like (or "x.y.z", as long as you control the y.z domain in DNS 
SRV)

It's not exactly the same as for XMPP, where you say each element uses a 
prefix based on its role. But it would have a similar effect of separating 
preferred protocols (and other SRV attributes) per client 
(registration/outbound) versus other elements (e.g. proxies)

Regards,
Jeroen

Juha Heinanen wrote:
>> For clients one would distribute "client-interface.example.com" as
>> the outbound proxy FQDN to use, and upstream proxies would be given

---

From: [email-masked] (Juha Heinanen)
Date: Tue, 5 Jun 2007 19:52:42 +0300

Jeroen van Bemmel writes:

 > SRV).

jeroen,

clients are existing standard sip clients that not given anything else
but aor, username and password.  then they automatically make srv query
on example.com, not on x.example.com.  

of course by manual configuration of outbound proxy you can accomplish
whatever, but that is not what users want.  they want as little
configuration as possible and configuring outbound proxy manually is out
of question.

-- juha

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 5 Jun 2007 13:28:20 -0500

Thanks Robert.

See below. Make sure you reach the end before replying back.

> Sent: Tuesday, June 05, 2007 06:49
> What about the proxy->proxy (or some stable network server) 
> hop, where we expect there _isn't_ a transport-destroying 
> intermediary (hah) and that we expect they _do_ have 
> certificates? This is the case where I think we have a real 
> constituency (with real applications) that we're harming.
> 
> Consider the routing decision that P1 needs to make. The 
> tools we have allow P1 to choose among the protocols it knows 
> how to use by administrative configuration. They let P2 
> express policy about which protocols P1 should use (through 
> DNS). What they don't do is let P1 choose between protocols 
> based on a user's (or application's) input.

Hi Robert, yes, I think it is a good summary.

I'm not sure that we are "harming" anything by not having transport=tls
because P1 can use static configuration or DNS to determine
the transport to use between P1 and P2.

The only thing that not having a transport=tls parameter implies is
that P1 (as you put it) will not be able to determine that TLS
should be used between P1 and P2 based on User (UAC) input (on that
hop only).

Transport=tls would allow the user to insist on the transport being
tls for the last hop before the target domain (but says nothing
about other hops).

I'm still not convinced that this particular behavior is required or
even 
desired. Remember that the UAC does have the means to enforce TLS
accross
ALL the hops using SIPS. 

Nevertheless, if people want to re-instate transport=tls, we can do
it. It would have to include lots of text to explain the limitations,
but
it can certainly be done.

> We've got this concept of a location service that you access 
> using REGISTER.
> The spec talks about running it separately from a proxy - so 
> consider the case where  a proxy either does query REGISTERs 
> or sends a request to a redirect server to figure out where 
> it's supposed to go. What it gets back is URIs in Contact 
> header fields. How can the location service tell the proxy 
> that's asking for a routing decision that "for this input 
> URI, goto this output URI and use TLS"?

Yes, that is certainly a more concrete use case. Both for 
the location service you mention, or for redirect servers in
general (when used for routing).

This may be the main technical reason for re-instating transport=tls.
I'd be willing to go along with that.

There is also another reason, this time practical, for re-instating
transport=tls. It is the fact that most implementations that support
TLS today seem to use it. I've attempted to mitigate this problem in
the current draft by writing up rules on how to deal with transport=tls
in a backward compatible way, but I'm not convinced that it's enough.
Perhaps formally recognizing transport=tls, and describing it's
limitations
(e.g., it doesn't solve NAT/FW, doesn't work with server-provided certs,
etc.).

Let's wait to see if anybody else chimes in on the idea of re-instating
transport=tls.

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Tue, 5 Jun 2007 21:54:48 +0200

Francois, Robert,

see below

Regards,
Jeroen

> I'd be willing to go along with that.

To me, the way it should work is that TLS would be used if the returned URI 
was a "sips:" URI, or if the returned URI was a "sip:" URI and the proxy 
decides to upgrade it to "sips:" (i.e. due to local policy). I don't see the 
need for transport=tls in this case

Regards,
Jeroen

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Jun 2007 19:17:01 -0400

Jumping in. I just happened to pick Gilad's message to respond to.

I've only been loosely following this discussion. But it seems to me 
that this transport=tls issue is a distraction from finishing the sips 
draft. Why does the sips draft have any responsibility for addressing 
this issue?

I think it would be better to let the sips draft be finished and then 
move on to addressing all of the (many) important security issues that 
sips doesn't solve, as a separate effort.

	Paul

---

From: "Francois Audet" <[email-masked]>
Date: Tue, 5 Jun 2007 18:50:25 -0500

Normally, I would agree with you. But transport=tls is so 
intertwined with SIPS that I'd rather fix both at the same time.

What I haven't heard is any voice strongly being against the 
re-instatement of transport=tls (except perhaps myself, but I don't 
care anymore: just want to move on).

> From: Paul Kyzivat [mailto:[email-masked]] 
> Sent: Tuesday, June 05, 2007 16:17
> To: Gilad Shaham
> Cc: Robert Sparks; Audet, Francois (SC100:3055); SIP IETF; Dean Willis
> I've only been loosely following this discussion. But it 
> seems to me that this transport=tls issue is a distraction 
> from finishing the sips draft. Why does the sips draft have 
> any responsibility for addressing this issue?
> 
> I think it would be better to let the sips draft be finished 
> and then move on to addressing all of the (many) important 
> security issues that sips doesn't solve, as a separate effort.

---

From: "Jeroen van Bemmel" <[email-masked]>
Date: Wed, 6 Jun 2007 08:27:01 +0200

I am strongly against it. If there are any issues that are currently being 
solved using transport=tls (in practice), they should be solved in a 
different way.

Regards,
Jeroen

Francois Audet wrote:
>> Cc: Robert Sparks; Audet, Francois (SC100:3055); SIP IETF; Dean
>> Willis Subject: Re: [Sip] Ready for WGLC on SIPS draft? Any last

---

From: Dean Willis <[email-masked]>
Date: Wed, 06 Jun 2007 01:52:09 -0500

> no transport info in request route, how does the proxy know which

How about:

It always tries TLS first, and if that doesn't work it either 1) falls
back to something else or 2) gives up. The choice between 1 and 2 is
made based on local policy.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 06 Jun 2007 02:07:04 -0500

> on example.com, not on x.example.com.  

Most clients are configurable with AOR, default proxy, username, and
password. If they aren't configurable with this, they're broken, they've
always been broken, and you need new ones. Even web browsers can be
configured to use a proxy that is not related to the user's AOR.

Examples of clients configurable this way include my ancient 3Com phone,
ancient Pingtel phone, every version of a Cisco 79xx phone I can
remember using over the last seven years, Linksys PAP2, Linksys RTP31, etc.

Some phones even learn their default proxies via DHCP.

So to do what you want to do, configure two sets of SRV records, one
that will be exercised by phones as "default proxies" and one that
corresponds to the domain part of your AORs.

--
Dean

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 6 Jun 2007 10:11:17 +0300

> configured to use a proxy that is not related to the user's AOR.

yes, clients are configurable, but if sip is trying to compete with
spype, xmpp, etc., configuration required by user must be minimal,
nothing in addition to aor, username and password.  all the rest must be
automatically learned from the network.

looks like you have lost totally touch of the real world, if you think
that it is feasible to ask users to manually configure outbound proxies.

-- juha

---

From: "Gilad Shaham" <[email-masked]>
Date: Wed, 6 Jun 2007 09:44:26 +0100

I tried to develop my point a little further.

I think there should be a way for the UA to specify the means of
communication. If we support transport=tls it resembles a little to the
transport parameter in the Via header. This is good as long as there
single preference. This is always the case in Via header, but the
transport parameter is not good enough in the following cases:
* Registrations where outbound is not used and user has more than one
preference on transport/security attributes.
* Outgoing communication and the user has more than one preference on
security attributes.

(There are probably other cases which I'm not aware of)

These preferences have some relationship with the transport. A UA might
want to indicate it supports TLS over TCP and not TLS over SCTP.

I think SIPS means - I want to communicate, possibly via trusted
proxies, in a manner that a third-party would not be able to intercept
or modify. If this definition is acceptable it does not rule out IPSec,
despite being out of RFC 3261 scope (I'll open a different thread on
that). My point is that this is also part of the possible preferences. A
UA might indicate that it can communicate either in IPSec or TLS. In the
transport parameter syntax the only option would be a single value such
as "transport=ipsec-udp".

Furthermore a UA might want to indicate it wants higher grade of
security 128 and not 40 bits.

I think the draft clarifies well the relationship between SIP and SIPS.
If there is a need to handle the cases above, it should be done by other
means.

Bottom line is that it's likely we'll regret allowing the use of
transport=tls. From my understanding the draft tries to add backward
compatibility and does not endorse it.

> From: Jeroen van Bemmel [mailto:[email-masked]]
> Sent: Wednesday, June 06, 2007 9:27 AM
> To: Francois Audet; Paul Kyzivat; Gilad Shaham
> thoughtsontransport=tls?

---

From: "Gilad Shaham" <[email-masked]>
Date: Wed, 6 Jun 2007 10:00:35 +0100

Hi Dean,

I have seen that the draft defines the relationship between SIP and SIPS
and indicates that "A SIPS URI specifies that the resource be contacted
securely."

I believe that IPSec can also achieve the same goal in terms of
security. My question is shouldn't this specification define this as an
acceptable possibility.

If 2 proxies have an IPSec tunnel between them, I believe it is
acceptable that they would pass SIPS communication just like TLS
communication. Naturally IPSec can also be used to pass SIP
communication. Basically almost any rule that applies to TLS in the SIPS
context, applies to IPSec.
The reason I think this is required is the fact that there are SIP and
IPSec implementations and SIPS is not defined for these cases.

If this is accepted, it would mean the draft should indicate "secure
transport" instead of "TLS" (except where TLS is specifically
discussed).

Regards,
Gilad

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 06 Jun 2007 08:09:15 -0500

> care anymore: just want to move on).

FWIW, and for the record, I am also against the re-instatement of
"transport=tls" for much the same reasons that you had mentioned
in a previous email (c.f. 
http://www1.ietf.org/mail-archive/web/sip/current/msg19371.html).
Plus, now that TLS is supported over other transports, we will
need to indicate the transport in the parameter as well.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
Email: vkg@{alcatel-lucent.com,bell-labs.com,acm.org}
WWW:   http://www.alcatel-lucent.com/bell-labs

---

From: Dean Willis <[email-masked]>
Date: Wed, 06 Jun 2007 11:42:36 -0500

> that it is feasible to ask users to manually configure outbound proxies.

My former employers shipped something like 50 million "configurable" SIP
devices to the real world, and email and http clients require comparable
configuration.

I also know that at many places one has to manually configure something
like a SOCKs proxy to make XMPP work.

The human-controlled policies around network operations require systems
to act in more complex ways than protocols can optimally support. This
isn't the protocol's fault.

--
Dean

---

From: Dean Willis <[email-masked]>
Date: Wed, 06 Jun 2007 11:45:12 -0500

> security. My question is shouldn't this specification define this as an

I initially supported this position, but the WG has stepped back from it
FOR THIS DRAFT in the interest of making SIPS as meaningful as we can
without heavy modification to the protocol (and with some realization
that SIPS alone doesn't mean all that much).

Your suggestion is slipping into "futures" work problems, much like the
cypher-suites draft.

--
Dean

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 6 Jun 2007 19:47:01 +0300

> isn't the protocol's fault.

i agree that there are always cases where auto-configuration does not
work, but it should be the default.  auto-learning of outbound proxies
should be a very basic requirement of outbound, but last time i checked,
no mechanism was included.  i suggest that a similar mechanism that
xmpp has, will be added.

-- juha

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 6 Jun 2007 15:14:17 -0500

Sounds appealing, until you realize that in an environment where TLS
support is the
exception and not the norm, you would degrade the performance of the
network
significantly by having lots of failed TLS connection attemps.

> Sent: Tuesday, June 05, 2007 23:52
> To: Juha Heinanen
> Cc: Audet, Francois (SC100:3055); SIP IETF
> >  > Later, in-dialog request will be sent on each hop reusing the 
> > existing  > established connections (TLS or TCP) as per current RFC 
> > 3261  > procedures.
> > 
> It always tries TLS first, and if that doesn't work it either 
> 1) falls back to something else or 2) gives up. The choice 
> between 1 and 2 is made based on local policy.
> 
> --
> Dean
> 
>

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 6 Jun 2007 17:57:58 -0500

Actually, now that I think of it, it may not be as bad as I tought.

If UAs are using sip-outbound with their proxies, it would handle the
vast majority of the links.

Between proxies, you would use DNS or static configuration normally.

Furthermore, between proxies, re-using of existing TCP/TLS may also be
done.

So maybe you are right.

> From: Audet, Francois (SC100:3055) 
> Sent: Wednesday, June 06, 2007 13:14
> To: Dean Willis; Juha Heinanen
> Cc: SIP IETF
> Sounds appealing, until you realize that in an environment 
> where TLS support is the exception and not the norm, you 
> would degrade the performance of the network significantly by 
> having lots of failed TLS connection attemps.
> 
> another and 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: Dean Willis <[email-masked]>
Date: Wed, 6 Jun 2007 23:25:41 -0500

Francois said:

> So maybe you are right
> Dean Said:

I think many of the assumptions we've been making seem to indicate  
that if you just don't know, the only reasonable thing to do is try  
TLS first. If there's nobody listening on the TLS port (but somebody  
at the IP address), you should get an ICMP response pretty quickly  
anyhow, then be able to decide on fallback.

If we hold the opposite true, and we try plain SIP/UDP first and only  
move to TLS when plain SIP fails, we're going to be in for a world of  
delay-hurt (waiting for that plain SIP/UDP transaction to time out)  
and never opportunistically using TLS anyhow.

Of course, it's better if you "know" up front, which is part of what  
the argument in favor of transport=tls is asking for. But given that  
we have ways for knowing in many of the other cases, this may not be  
critical.

Of course, if we'd started with a plain connection, discovered TLS  
capability in a greeting message (aka EHELO) and then done an upgrade  
to that connection using something like STARTTLS, we wouldn't be  
having this discussion. It would have just worked. Boy do I feel dumb.

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 8 Jun 2007 17:52:22 -0500

Based on the feedback from the mailing list from the last few days, 
I'm proposing the following:

- That we do not re-instate "transport=tls" at this point (i.e., in 
  the draft-ietf-sip-sips draft).

- As suggested by Paul Kyzivat, we would defer any work on transport=tls
  to later. As such, we would add this topic in Annex A "Future Steps in
  Specification". We would describe the uses cases that are currently
  not covered by this draft: URIs that need to specify TLS as a
transport,
  as per the Redirect server and Location server examples that were
described
  by Robert Sparks.