Subject: [Sip] Using TLS in the first hop - Bug in RFC 5630

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 15 Sep 2011 15:01:22 +0200

Hi, there is a general confusion about the usage of TLS transport and
SIPS schema. Even more when the RFC 5630 (which tries to clarify it)
contains an important bug:

RFC 5630 states:

-------------------------------------------------------------------
3.1.3.  Using TLS with SIP Instead of SIPS

   [...]

   If one wants to use "best-effort TLS" for SIP, one just needs to use
   a SIP URI, and send the request over TLS.

   Using SIP over TLS is very simple.  A UA opens a TLS connection and
   uses SIP URIs instead of SIPS URIs for all the header fields in a SIP
   message (From, To, Request-URI, Contact header field, Route, etc.).
   When TLS is used, the Via header field indicates TLS.
-------------------------------------------------------------------

So an example of INVITE sent via TLS just for the first hop would be:

  INVITE sip:[email-masked] SIP/2.0
  Via: SIP/2.0/TLS 1.2.3.4
  From: sip:[email-masked]
  Contact: sip:[email-masked];transport=tcp

Note that I've set "sip" schema in the Contact URI (as the spec says)
so incoming in-dialog request would be received by the caller (alice)
via TCP rather than TLS !!!

This is wrong, it should be:

  INVITE sip:[email-masked] SIP/2.0
  Via: SIP/2.0/TLS 1.2.3.4
  From: sip:[email-masked]
  Contact: sips:[email-masked];transport=tcp

Now Contact URI has "sips" schema so the proxy (assuming it does
loose-routing) would route any in-dialog request via TLS-over-TCP to
reach alice.

The fact that the Contact URI has "sips" schema is not a problem for
the called (regardless it speaks TLS or not) as in-dialog request to
be sent from Bob to Alice would contain Route headers, and those Route
headers could have "sip" schema (in case the latest proxy contacted
Bob using UDP or TCP). So a BYE from Bob would be sent via UDP/TCP
based on the top most Route.

As a personal comment, I would like to say that nobody understands the
usage of "sips" schema, just nobody. And the specs do not help.

Best regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 15 Sep 2011 15:23:41 +0200

> contains an important bug:
With the deprecation of "transport=tls" it becomes even more strange. 
We should really spend some time on a "hitch hikers guide to SIP with TLS" and write an RFC to reinstate transtport=tls, which is what we all use.

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 15 Sep 2011 15:38:44 +0200

> With the deprecation of "transport=tls" it becomes even more strange.

AFAIK "transport=tls" has never been deprecated. Instead, it has never
been an standard. Note for example that RFC 3261 says:

      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.

"A change since RFC 2543"?? transport=tls has never been defined in
RFC 2543. Check yourself:

  http://tools.ietf.org/html/rfc2543

> We should really spend some time on a "hitch hikers guide to SIP with TLS" and write an RFC to reinstate transtport=tls, which is what we all use.

Or spend some time in a new draft that *correctly* explains how to use
TLS in the first hop (without requiring security in the whole path).
This is *very* easy:

As I've explained in my first mail:

That's all. Just:
- Set TLS in Via transport.
- Use "sip" schema in every URI.
- But use "sips" schema in Contact URI.

And it works.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 15 Sep 2011 15:46:52 +0200

> - But use "sips" schema in Contact URI.

This means thet the request URI of the ACK will be using SIPS, and then section 8.1.1.8 comes into play
and requires the other side to also use a SIPS uri in their contact.

In this case, both UAs need a TLS certificate.

Interesting.

/O

---

From: "Horvath, Ernst" <[email-masked]>
Date: Thu, 15 Sep 2011 15:58:59 +0200

Comment at the end...

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Iñaki Baz Castillo
> Sent: Donnerstag, 15. September 2011 15:39
> To: Olle E. Johansson
> Cc: [email-masked]
> Subject: Re: [Sip] Using TLS in the first hop - Bug in RFC 5630
> 
> > We should really spend some time on a "hitch hikers guide 
> to SIP with TLS" and write an RFC to reinstate 
> transtport=tls, which is what we all use.
> 
It may work for the 1st request. But in a subsequent mid-dialog request in the reverse direction the contact URI becomes the Request-URI, which is now SIPS, and therefore the Contact in this request must also become SIPS, and you end up in an all-SIPS case.

Ernst Horvath

> 
> 
> -- 
> Iñaki Baz Castillo
> <[email-masked]>
> _______________________________________________
> Sip mailing list  https://www.ietf.org/mailman/listinfo/sip
> This list is essentially closed and only used for finishing 
> old business.
> Use [email-masked] for questions on how to 
> develop a SIP implementation.
> Use [email-masked] for new developments on the application of sip.
> Use [email-masked] for issues related to maintenance of the 
> core SIP specifications.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 15 Sep 2011 16:08:53 +0200

> It may work for the 1st request. But in a subsequent mid-dialog request in the reverse direction the contact URI becomes the Request-URI, which is now SIPS, and therefore the Contact in this reques…

Not true. Let me explain it in other mail soon.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 15 Sep 2011 16:25:24 +0200

> In this case, both UAs need a TLS certificate.

No, that's incorrect. I show two call flows in which TLS is just used
by one of the enpoints.

CASE 1)
- Alice uses TLS.
- Bob uses UDP.
- Proxy/registrar does loose-routing.
- Alice calls Bob, Bob answers and later Bob hangs up.

F1 INVITE Alice -> SIP Proxy (transport TLS)

INVITE sip:[email-masked] SIP/2.0
Via: SIP/2.0/TLS 93.12.40.105:20565;branch=z9hG4bK56sdasks
From: sip:[email-masked];tag=asdyka899
To: sip:[email-masked]
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sips:[email-masked]:20565;transport=tcp>
Content-Type: application/sdp

F2 100 Trying SIP Proxy -> Alice (transport TLS)

SIP/2.0 100 Trying
Via: SIP/2.0/TLS 93.12.40.105:20565;branch=z9hG4bK56sdasks
From: sip:[email-masked];tag=asdyka899
To: sip:[email-masked]
Call-ID: asidkj3ss
CSeq: 1 INVITE

F3 INVITE SIP Proxy -> Carol (transport UDP)

INVITE sip:[email-masked]:5060 SIP/2.0
Via: SIP/2.0/UDP 100.100.100.100;branch=z9hG4bKhjhjqw32c
Via: SIP/2.0/TLS 93.12.40.105:20565;branch=z9hG4bK56sdasks
Record-Route: <sip:100.100.100.100;transport=udp>,
  <sips:100.100.100.100;transport=tcp>
From: sip:[email-masked];tag=asdyka899
To: sip:[email-masked]
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 69
Contact: <sips:[email-masked]:20565;transport=tcp>
Content-Type: application/sdp

F4 200 OK Carol -> SIP Proxy (transport UDP)

SIP/2.0 200 OK
Via: SIP/2.0/UDP 100.100.100.100;branch=z9hG4bKhjhjqw32c
Via: SIP/2.0/TLS 93.12.40.105:20565;branch=z9hG4bK56sdasks
Record-Route: <sip:100.100.100.100;transport=udp>,
  <sips:100.100.100.100;transport=tcp>
From: sip:[email-masked];tag=asdyka899
To: sip:[email-masked];tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 69
Contact: <sip:[email-masked]:5060;transport=udp>
Content-Type: application/sdp

F5 200 OK SIP Proxy -> Alice (transport TLS)

SIP/2.0 200 OK
Via: SIP/2.0/TLS 93.12.40.105:20565;branch=z9hG4bK56sdasks
Record-Route: <sip:100.100.100.100;transport=udp>,
  <sips:100.100.100.100;transport=tcp>
From: sip:[email-masked];tag=asdyka899
To: sip:[email-masked];tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 69
Contact: <sip:[email-masked]:5060;transport=udp>
Content-Type: application/sdp

F6 ACK Alice -> SIP Proxy (transport TLS)

ACK sip:[email-masked]:5060;transport=udp SIP/2.0
Via: SIP/2.0/TLS 93.12.40.105:20565;branch=z9hG4bKhgqqp090
Route: <sips:100.100.100.100;transport=tcp>,
  <sip:100.100.100.100;transport=udp>
From: sip:[email-masked];tag=asdyka899
To: sip:[email-masked];tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 ACK
Max-Forwards: 70

F7 ACK SIP Proxy -> Carol (transport UDP)

ACK sip:[email-masked]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 100.100.100.100;branch=z9hG4bKhwpoc80zzx
Via: SIP/2.0/TLS 93.12.40.105:20565;branch=z9hG4bKhgqqp090
From: sip:[email-masked];tag=asdyka899
To: sip:[email-masked];tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 ACK
Max-Forwards: 69

F8 BYE Carol -> SIP Proxy (transport UDP)

BYE sips:[email-masked]:20565;transport=tcp SIP/2.0
Via: SIP/2.0/UDP 77.123.45.23;branch=z9hG4bKbiuiansd001
Route: <sip:100.100.100.100;transport=udp>,
  <sips:100.100.100.100;transport=tcp>
From: sip:[email-masked];tag=bmqkjhsd
To: sip:[email-masked];tag=asdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE
Max-Forwards: 70

F9 BYE SIP Proxy -> Alice (transport TLS)

BYE sips:[email-masked]:20565;transport=tcp SIP/2.0
Via: SIP/2.0/TLS 100.100.100.100;branch=z9hG4bKmma01m3r5
Via: SIP/2.0/UDP 77.123.45.23;branch=z9hG4bKbiuiansd001
From: sip:[email-masked];tag=bmqkjhsd
To: sip:[email-masked];tag=asdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE
Max-Forwards: 69

F10 200 OK Alice -> SIP Proxy (transport TLS)

SIP/2.0 200 OK
Via: SIP/2.0/TLS 100.100.100.100;branch=z9hG4bKmma01m3r5
Via: SIP/2.0/UDP 77.123.45.23;branch=z9hG4bKbiuiansd001
From: sip:[email-masked];tag=bmqkjhsd
To: sip:[email-masked];tag=asdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE

F11 200 OK SIP Proxy -> Carol (transport UDP)

SIP/2.0 200 OK
Via: SIP/2.0/UDP 77.123.45.23;branch=z9hG4bKbiuiansd001
From: sip:[email-masked];tag=bmqkjhsd
To: sip:[email-masked];tag=asdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE

CASE 2)
- Alice uses TLS.
- Bob uses UDP.
- Proxy/registrar does loose-routing.
- Bob calls Alice, Alice answers and later Alice hangs up.

F1 INVITE Bob -> SIP Proxy (transport UDP)

INVITE sip:[email-masked] SIP/2.0
Via: SIP/2.0/UDP 77.123.45.23:5060;branch=z9hG4bK56sdasks
From: sip:[email-masked];tag=asdyka899
To: sip:[email-masked]
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:[email-masked]:5060;transport=udp>
Content-Type: application/sdp

F2 100 Trying SIP Proxy -> Bob (transport TLS)

SIP/2.0 100 Trying
Via: SIP/2.0/UDP 77.123.45.23:5060;branch=z9hG4bK56sdasks
From: sip:[email-masked];tag=asdyka899
To: sip:[email-masked]
Call-ID: asidkj3ss
CSeq: 1 INVITE

F3 INVITE SIP Proxy -> Alice (transport TLS)

INVITE sips:[email-masked]:20565 SIP/2.0
Via: SIP/2.0/TLS 100.100.100.100;branch=z9hG4bKhjhjqw32c
Via: SIP/2.0/UDP 77.123.45.23:5060;branch=z9hG4bK56sdasks
Record-Route: <sips:100.100.100.100;transport=tcp>,
  <sip:100.100.100.100;transport=udp>
From: sip:[email-masked];tag=asdyka899
To: sip:[email-masked]
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 69
Contact: <sip:[email-masked]:5060;transport=udp>
Content-Type: application/sdp

F4 200 OK Alice -> SIP Proxy (transport TLS)

SIP/2.0 200 OK
Via: SIP/2.0/TLS 100.100.100.100;branch=z9hG4bKhjhjqw32c
Via: SIP/2.0/UDP 77.123.45.23:5060;branch=z9hG4bK56sdasks
Record-Route: <sips:100.100.100.100;transport=tcp>,
  <sip:100.100.100.100;transport=udp>
From: sip:[email-masked];tag=asdyka899
To: sip:[email-masked];tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 69
Contact: <sips:[email-masked]:20565;transport=tcp>
Content-Type: application/sdp

F5 200 OK SIP Proxy -> Bob (transport UDP)

SIP/2.0 200 OK
Via: SIP/2.0/UDP 77.123.45.23:5060;branch=z9hG4bK56sdasks
Record-Route: <sips:100.100.100.100;transport=tcp>,
  <sip:100.100.100.100;transport=udp>
From: sip:[email-masked];tag=asdyka899
To: sip:[email-masked];tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 69
Contact: <sips:[email-masked]:20565;transport=tcp>
Content-Type: application/sdp

F6 ACK Bob -> SIP Proxy (transport UDP)

ACK sips:[email-masked]:20565;transport=tcp SIP/2.0
Via: SIP/2.0/TLS 77.123.45.23:5060;branch=z9hG4bKhgqqp090
Route: <sip:100.100.100.100;transport=udp>,
  <sips:100.100.100.100;transport=tcp>
From: sip:[email-masked];tag=asdyka899
To: sip:[email-masked];tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 ACK
Max-Forwards: 70

F7 ACK SIP Proxy -> Alice (transport TLS)

ACK sips:[email-masked]:20565;transport=tcp SIP/2.0
Via: SIP/2.0/TLS 100.100.100.100;branch=z9hG4bKhwpoc80zzx
Via: SIP/2.0/UDP 77.123.45.23:5060;branch=z9hG4bKhgqqp090
From: sip:[email-masked];tag=asdyka899
To: sip:[email-masked];tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 ACK
Max-Forwards: 69

F8 BYE Alice -> SIP Proxy (transport TLS)

BYE sip:[email-masked]:5060;transport=udp SIP/2.0
Via: SIP/2.0/TLS 77.123.45.23;branch=z9hG4bKbiuiansd001
Route: <sips:100.100.100.100;transport=tcp>,
  <sip:100.100.100.100;transport=udp>
From: sip:[email-masked];tag=bmqkjhsd
To: sip:[email-masked];tag=asdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE
Max-Forwards: 70

F9 BYE SIP Proxy -> Bob (transport UDP)

BYE sip:[email-masked]:5060;transport=udp SIP/2.0
Via: SIP/2.0/UDP 100.100.100.100;branch=z9hG4bKmma01m3r5
Via: SIP/2.0/TLS 77.123.45.23;branch=z9hG4bKbiuiansd001
From: sip:[email-masked];tag=bmqkjhsd
To: sip:[email-masked];tag=asdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE
Max-Forwards: 69

F10 200 OK Bob -> SIP Proxy (transport UDP)

SIP/2.0 200 OK
Via: SIP/2.0/UDP 100.100.100.100;branch=z9hG4bKmma01m3r5
Via: SIP/2.0/TLS 77.123.45.23;branch=z9hG4bKbiuiansd001
From: sip:[email-masked];tag=bmqkjhsd
To: sip:[email-masked];tag=asdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE

F11 200 OK SIP Proxy -> Alice (transport TLS)

SIP/2.0 200 OK
Via: SIP/2.0/TLS 77.123.45.23;branch=z9hG4bKbiuiansd001
From: sip:[email-masked];tag=bmqkjhsd
To: sip:[email-masked];tag=asdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE

These flows are inspired in real scenarios, so both are real and working flows.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 15 Sep 2011 16:30:52 +0200

>> It may work for the 1st request. But in a subsequent mid-dialog request in the reverse direction the contact URI becomes the Request-URI, which is now SIPS, and therefore the Contact in this reque…

This is not true. The in-dialog request will have, indeed, a RURI with
SIPS schema, but it will also contain a top Route with SIP schema, so
it takes preference and there is no need at all to set a SIPS Contact
URI.

RFC 5630:

5.1.2.  UAS Behavior

   When presented with a SIPS URI, a UAS MUST NOT change it to a SIP
   URI.

   As mandated by [RFC3261], Section 12.1.1:

      If the request that initiated the dialog contained a SIPS URI in
      the Request-URI or in the top Record-Route header field value, if
      there was any, or the Contact header field if there was no Record-
      Route header field, the Contact header field in the response MUST
      be a SIPS URI.

In our case *there is* a Record-Route in the INVITE arriving to the
UAS and it does contain a SIP URI, so the Contact in the response from
the UAS does not need to be a SIPS URI.

Anyhow I insist: SIPS and TLS usage is a pain. Nobody understands it
(it's clear given any mail thread about this topic) and everybody does
wrong assumptions. I think SIP authors should worry about this reality
and react.

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Olle E. Johansson" <[email-masked]>
Date: Thu, 15 Sep 2011 16:44:17 +0200

> wrong assumptions. I think SIP authors should worry about this reality

Proven by this confusing discussion.

/O

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 15 Sep 2011 15:22:29 +0000

But that's not the only use-case for Contact - the Contact URI of Alice can be used at any time later for an out-of-dialog request to Alice, and at that point it suddenly needs a full sips path to Alice.  For example in a REFER case.

-hadriel

On Sep 15, 2011, at 10:25 AM, Iñaki Baz Castillo wrote:

> This list is essentially closed and only used for finishing old business.
> Use [email-masked] for questions on how to develop a SIP implementation.
> Use [email-masked] for issues related to maintenance of the core SIP specifications.

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 15 Sep 2011 17:27:27 +0200

> But that's not the only use-case for Contact - the Contact URI of Alice can be used at any time later for an out-of-dialog request to Alice, and at that point it suddenly needs a full sips path to…

If Alice wants to refer Bob to Carol, Alice would do better by sending
a REFER with "Refer-To: <sip:[email-masked]>" rather than using
SIPS. Not sure if you meant this.

Anyhow, what do you mean then? the section 3.1.3 in RFC 5630 is buggy
as I told in my first mail, am I wrong? By setting a Contact with SIP
rather than SIPS, that means that in-dialog requests would be sent to
the caller using UDP/TCP rather than TLS, so they would fail
(assumming that the caller is just reachable using TLS, let's imagine
NAT and so).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 15 Sep 2011 17:33:44 +0200

> SIPS. Not sure if you meant this.

Ok, you meant the "attended transfer" case in which Alice sends a
REFER to Carol containing the Contact URI of Bob (while Alice is still
in a dialog with Bob).

Interesting case, right. What I think is that all this stuff is
unclear, confusing, badly designed and error prune.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 15 Sep 2011 15:41:41 +0000

No I mean if Bob wants to Refer Carol to Alice, or Alice to Carol (since that Refer can be sent out of dialog to Alice's contact).

I dunno about if it's an error or not - I remember there was a discussion about it, but it was a long time ago. :(

-hadriel
Sent from my iPhone

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 15 Sep 2011 18:03:31 +0200

> No I mean if Bob wants to Refer Carol to Alice, or Alice to Carol (since that Refer can be sent out of dialog to Alice's contact).

Initial requests sent to a Contact address rather than being sent to
an AoR are always problematic. The same occurs in attended trasfer
when the REFER is sent within the dialog and contains a Refer-To with
the endpoint Contact URI. Such URI could be no reachable if it's
between some kind of NAT's (regardless the user used STUN).

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 15 Sep 2011 18:04:52 +0200

2011/9/15 Iñaki Baz Castillo <[email-masked]>:
> Such URI could be no reachable if it's

s/between/behind/

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 15 Sep 2011 16:31:14 +0000

Oh I'm well aware of that. :)
I assumed this whole discussion was theoretical.
In *practice* using sips is tough.  Some systems don't support it and will choke on the scheme, while some systems seem to ignore the extra "s".  And there are real problems with it even if you do everything by the book.  For example, it's not like Alice's UA will actually have a TLS cert to be able to be a TLS server/listen-socket, so you can't open a TLS connection to her UA regardless, ever.  And with TCP in general you have to treat her Registered Contact connection as an outbound-style flow (ie, like an alias'ed connection-reuse), even if the UAC doesn't indicate RFC 5626 nor 5923.  Once you do that, using "sip" instead of "sips" contact works, or has so far for us.  YMMV.

-hadriel

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Thu, 15 Sep 2011 19:05:49 +0200

Addressing the thread in general rather than Hadriel in particular.

Please remember that RFC 5630 did not set out to create a complete solution to secure communication. That was left to separate work and noone at the time seemed interested in doing that next step, so it was abandoned.

What RFC 5630 set out to do was to define what occurred if you followed the RFC 3261 mechanisms, and to correct some of RFC 3261 that was known to be wrong and to attempt to make sure that if SIPS was used in the Request-URI, then TLS was used end to end. I do not believe there was ever an intent to try and control what happened hop by hop. If you know that TLS is being used on the local hop, but have absolutely no knowledge of whether it is being used anywhere else, how useful is that?

While section 5, the normative section appears somewhat long, if you look at the impact of RFC 5630 in the way it changed RFC 3261 as stated in appendix A, it actually did very little in terms of change to the original RFC 3261 material.

I'm not actually sure that the issue you point out in 3.1.3 actually impacts the above drastically.

Do note however that if you want to perform new work, you probably need to take it to the SIPCORE list.

Keith

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Hadriel Kaplan
> Sent: 15 September 2011 17:31
> To: Iñaki Baz Castillo
> Cc: <[email-masked]>; Olle E. Johansson
> In *practice* using sips is tough.  Some systems don't support it and will
> choke on the scheme, while some systems seem to ignore the extra "s".  And
> there are real problems with it even if you do everything by the book.
> For example, it's not like Alice's UA will actually have a TLS cert to be
> able to be a TLS server/listen-socket, so you can't open a TLS connection
> to her UA regardless, ever.  And with TCP in general you have to treat her
> Registered Contact connection as an outbound-style flow (ie, like an
> alias'ed connection-reuse), even if the UAC doesn't indicate RFC 5626 nor
> 5923.  Once you do that, using "sip" instead of "sips" contact works, or
> has so far for us.  YMMV.
> 
> -hadriel
> 
> 
> >> No I mean if Bob wants to Refer Carol to Alice, or Alice to Carol
> (since that Refer can be sent out of dialog to Alice's contact).
> >

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Thu, 15 Sep 2011 19:50:44 +0200

2011/9/15 DRAGE, Keith (Keith) <[email-masked]>:
> If you know that TLS is being used on the local hop, but have absolutely no knowledge of whether it is being used anywhere else, how useful is that?

Typical case:

- Clients connected to a proxy using TLS (to secure communication in
private networks and untrusted Internet access as most ADSL's).
- The provider proxy uses UDP to contact the PSTN gateways of the
provider (which don't support TLS), or other SIP carriers in the
world.

This is the most common SIP scenario AFAIK, and here using SIP over
TLS between clients and their proxy is a good choice.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Horvath, Ernst" <[email-masked]>
Date: Fri, 16 Sep 2011 12:12:57 +0200

inline 

> From: Iñaki Baz Castillo [mailto:[email-masked]] 
> Sent: Donnerstag, 15. September 2011 16:31
> To: Horvath, Ernst
> Cc: [email-masked]
> >> It may work for the 1st request. But in a subsequent 
> mid-dialog request in the reverse direction the contact URI 
> becomes the Request-URI, which is now SIPS, and therefore the 
> Contact in this request must also become SIPS, and you end up 
> in an all-SIPS case.
> 

Well, I read RFC 3261 differently. 8.1.2 says:

   Otherwise, the procedures are applied to the first Route header field
   value in the request (if one exists), or to the request's Request-URI
   if there is no Route header field present.  These procedures yield an
   ordered set of address, port, and transports to attempt.  Independent
   of which URI is used as input to the procedures of [4], if the
   Request-URI specifies a SIPS resource, the UAC MUST follow the
   procedures of [4] as if the input URI were a SIPS URI.

This behaviour overrides the transport indicated in the Route header if 
the Request-URI is SIPS. And it applies to mid-dialog requests as well.
BTW, RFC 5630 has some text on your original point:

5.1.1.2.  SIPS in a Dialog

   If the Request-URI in a request that initiates a dialog is a SIP URI,
   then the UAC needs to be careful about what to use in the Contact
   header field (in case Record-Route is not used for this hop).  If the
   Contact header field was a SIPS URI, it would mean that the UAS would
   only accept mid-dialog requests that are sent over secure transport
   on each hop.  Since the Request-URI in this case is a SIP URI, it is
   quite possible that the UA sending a request to that URI might not be
   able to send requests to SIPS URIs.  If the top Route header field
   does not contain a SIPS URI, the UAC MUST use a SIP URI in the
   Contact header field, even if the request is sent over a secure
   transport (e.g., the first hop could be re-using a TLS connection to
   the proxy as would be the case with [RFC5626]).

Regards,
Ernst

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 16 Sep 2011 13:08:10 +0200

>   the proxy as would be the case with [RFC5626]).

Hi, this definitely tells me that SIPS and TLS is impossible, but just
in the case of full TLS in the whole path.

I insist on the bug I've reported for RFC 5630: If the client sets a
SIP Contact URI and sends the request using TLS, then it would receive
incoming in-dialog requests via UDP or TCP, but not TLS. This does not
make sense as the caller could use just SIP over TLS, and in case of
NAT this would never work as the proxy/server could never send a TCP
or UDP request to the client.

So IMHO SIPS and TLS is broken and it can only work when the full path
is secure (which is unfeasible in most of the environments). This
needs a rework, or maybe Olle is right and we should use
;transport=tls (with SIP schema), ;transport=tls-sctp and so on.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 16 Sep 2011 14:18:41 +0200

> needs a rework ...

This conclusion is nothing new - it was essentially the conclusion of those working on RFC 5630. But it is not RFC 5630 that needs the rework; that document is pretty much correct within the constraints we gave it, which is to define what happens with the existing protocol and make minimum fixes to the existing protocol (indeed the original charter item was only the first half of this). 

There was a recognition that more could be achieved with a new mechanism (for example there was a draft from Vijay Gurbani), but that would have been a separate charter item, and noone seemed to have the enthusiasm at the time to work on it. That doesn't mean that that situation still persists and I'm sure you understand the process for bringing new work into IETF if you want to do something. But that is what it is, new work.

Keith

> Sent: 16 September 2011 12:08
> To: Horvath, Ernst
> Cc: [email-masked]

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 16 Sep 2011 14:46:16 +0200

> There was a recognition that more could be achieved with a new mechanism (for example there was a draft from Vijay Gurbani), but that would have been a separate charter item, and noone seemed to ha…

Thanks, I understand what you mean.

IMHO the main problem is "mixing" the transport for a specific node in
the path with the requirement of a secure transport for the whole
path. Given this thread is clear that there are errors in the design
making it unusable.

Another "error" (IMHO) is the aim of RFC 3261 in considering TLS (over
TCP) not a transport, but a secure layer over TCP. But that is ironic
since that just applies to URI ;transport param, but in Via transport
field we do have "TLS" and "TCP" as separate values.

Things would be much easier as follows (just an initial idea):

- Consider TLS-over-TCP as a real transport (the same for TLS over
SCTP) so we have ;transport=tls / tls-sctp.

- Completely remove SIPS schema (the real pain here).

- Create any new mechanism for requiring a whole secure path. For
example, by adding a ;sec param to the Request URI and Contact URI. In
this way, the UAS MUST also add ;sec to the Contact header in the
response, so all the in-dialog requests would have ;sec in the Request
URI.  Proxies should add ;sec to Record-Route headers in this case.
If an UAC or proxy has to route a request whose top Route (or RURI if
no Route is present) has ;sec param, then it MUST use a secure
transport. If such URI contains a ;transport param with values "udp",
"tcp" or "sctp" then that's an error and the request should be
rejected.
And that's all.

Of course this idea must be improved (a lot) :)

Regards.

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 16 Sep 2011 08:25:54 -0500

On 09/16/2011 07:18 AM, DRAGE, Keith (Keith) wrote:
[...]
> There was a recognition that more could be achieved with a new
> mechanism (for example there was a draft from Vijay Gurbani), but
> that would have been a separate charter item, and noone seemed to
> have the enthusiasm at the time to work on it. That doesn't mean that
> that situation still persists and I'm sure you understand the process
> for bringing new work into IETF if you want to do something. But that
> is what it is, new work.

The draft Keith is referring to here, if you are interested, is:
"The SIPSEC Uniform Resource Identifier (URI)" [1].

There was a follow-up paper [2] that used the idea in the sipsec URI
draft to benchmark TLS per-hop and TLS end-to-end, treating the
intermediary proxies as a blind byte forwarder.  If you are interested
in the paper, drop me a private message and I can send you the PDF.

[1] http://tools.ietf.org/html/draft-gurbani-sip-sipsec-01
[2] Gurbani, V.K., Willis, D., and Audet, F., "Cryptographically
  Transparent Session Initiation Protocol (SIP) Proxies," Proceedings of
  the 2007 IEEE International Conference on Communications (ICC), pp.
  1185-1190, June 2007, Glasgow, UK.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: "Olle E. Johansson" <[email-masked]>
Date: Fri, 16 Sep 2011 15:26:26 +0200

> There was a recognition that more could be achieved with a new mechanism (for example there was a draft from Vijay Gurbani), but that would have been a separate charter item, and noone seemed to ha…

Thank you very much Keith for this clarification, which gives us the background we need.

Time to allocate resources to be able to work on this then.

/O

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 16 Sep 2011 16:21:50 +0200

> in the paper, drop me a private message and I can send you the PDF.

Hi Vijay, the PDF is already accesible in the link below :)

> [1] http://tools.ietf.org/html/draft-gurbani-sip-sipsec-01

I would like to comment about this draft, is it the appropriate maillist for it?

-- 
Iñaki Baz Castillo
<[email-masked]>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 16 Sep 2011 16:23:10 +0200

I would suggest moving the discussion to either SIPCORE or DISPATCH.

Keith

> Sent: 16 September 2011 15:22
> To: Gurbani, Vijay K (Vijay)
> Cc: DRAGE, Keith (Keith); Horvath, Ernst; [email-masked]

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Fri, 16 Sep 2011 16:35:19 +0200

And just to clarify, the SIP list is addressed at the remaining work that existed in the SIP WG at the time it closed. Indeed many SIP experts have left this list, or are newcomers and were never on it.

As this is potential new work, it should follow the rules for introducing new work into the RAI area. This would ultimately end up in the SIPCORE WG. Whether the SIPCORE chairs would feel it needed to be DISPATCHed first I will leave you to consult on.

Of course what you do with it prior to the request to charter the work is entirely up to you as authors and collaborators, but at some point you need to bring other experts up to speed with what you would like IETF to do.

Regards

Keith

> DRAGE, Keith (Keith)
> Sent: 16 September 2011 15:23
> To: Iñaki Baz Castillo; Gurbani, Vijay K (Vijay)
> Cc: [email-masked]; Horvath, Ernst

---

From: Iñaki Baz Castillo <[email-masked]>
Date: Fri, 16 Sep 2011 16:40:02 +0200

> I would suggest moving the discussion to either SIPCORE or DISPATCH.

I've started a thread in SIPCORE.

Thanks a lot.

-- 
Iñaki Baz Castillo
<[email-masked]>