Using TLS in the first hop - Bug in RFC 5630

[Iñaki Baz Castillo]

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:***@biloxi.com SIP/2.0
Via: SIP/2.0/TLS 1.2.3.4
From: sip:***@atlanta.com
Contact: sip:***@1.2.3.4;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:***@biloxi.com SIP/2.0
Via: SIP/2.0/TLS 1.2.3.4
From: sip:***@atlanta.com
Contact: sips:***@1.2.3.4;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
<***@aliax.net>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP speci

[Olle E. Johansson]

15 sep 2011 kl. 15:01 skrev Iñaki Baz Castillo:

> 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:***@biloxi.com SIP/2.0
> Via: SIP/2.0/TLS 1.2.3.4
> From: sip:***@atlanta.com
> Contact: sip:***@1.2.3.4;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:***@biloxi.com SIP/2.0
> Via: SIP/2.0/TLS 1.2.3.4
> From: sip:***@atlanta.com
> Contact: sips:***@1.2.3.4;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.
>
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

_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Iñaki Baz Castillo]

2011/9/15 Olle E. Johansson <***@edvina.net>:
>> 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.
>>
> 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:***@atlanta.com;transport=tcp" and
"sips:***@atlanta.com;transport=sctp" are both valid (although
note that UDP is not a valid transport for SIPS). The use of
"transport=tls" has consequently been deprecated, partly because
it was specific to a single hop of the request. This is a change
since RFC 2543.

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

INVITE sip:***@biloxi.com SIP/2.0
Via: SIP/2.0/TLS 1.2.3.4
From: sip:***@atlanta.com
Contact: sips:***@1.2.3.4;transport=tcp

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
<***@aliax.net>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications

[Olle E. Johansson]

15 sep 2011 kl. 15:38 skrev Iñaki Baz Castillo:

> 2011/9/15 Olle E. Johansson <***@edvina.net>:
>>> 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.
>>>
>> 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:***@atlanta.com;transport=tcp" and
> "sips:***@atlanta.com;transport=sctp" are both valid (although
> note that UDP is not a valid transport for SIPS). The use of
> "transport=tls" has consequently been deprecated, partly because
> it was specific to a single hop of the request. This is a change
> since RFC 2543.
>
> "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:
>
> INVITE sip:***@biloxi.com SIP/2.0
> Via: SIP/2.0/TLS 1.2.3.4
> From: sip:***@atlanta.com
> Contact: sips:***@1.2.3.4;transport=tcp
>
> 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.

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
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Iñaki Baz Castillo]

2011/9/15 Olle E. Johansson <***@edvina.net>:
> 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.

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:***@atlanta.com SIP/2.0
Via: SIP/2.0/TLS 93.12.40.105:20565;branch=z9hG4bK56sdasks
From: sip:***@atlanta.com;tag=asdyka899
To: sip:***@atlanta.com
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sips:***@93.12.40.105: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:***@atlanta.com;tag=asdyka899
To: sip:***@atlanta.com
Call-ID: asidkj3ss
CSeq: 1 INVITE


F3 INVITE SIP Proxy -> Carol (transport UDP)

INVITE sip:***@77.123.45.23: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:***@atlanta.com;tag=asdyka899
To: sip:***@atlanta.com
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 69
Contact: <sips:***@93.12.40.105: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:***@atlanta.com;tag=asdyka899
To: sip:***@atlanta.com;tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 69
Contact: <sip:***@77.123.45.23: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:***@atlanta.com;tag=asdyka899
To: sip:***@atlanta.com;tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 69
Contact: <sip:***@77.123.45.23:5060;transport=udp>
Content-Type: application/sdp


F6 ACK Alice -> SIP Proxy (transport TLS)

ACK sip:***@77.123.45.23: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:***@atlanta.com;tag=asdyka899
To: sip:***@atlanta.com;tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 ACK
Max-Forwards: 70


F7 ACK SIP Proxy -> Carol (transport UDP)

ACK sip:***@77.123.45.23: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:***@atlanta.com;tag=asdyka899
To: sip:***@atlanta.com;tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 ACK
Max-Forwards: 69


F8 BYE Carol -> SIP Proxy (transport UDP)

BYE sips:***@93.12.40.105: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:***@atlanta.com;tag=bmqkjhsd
To: sip:***@atlanta.com;tag=asdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE
Max-Forwards: 70


F9 BYE SIP Proxy -> Alice (transport TLS)

BYE sips:***@93.12.40.105: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:***@atlanta.com;tag=bmqkjhsd
To: sip:***@atlanta.com;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:***@atlanta.com;tag=bmqkjhsd
To: sip:***@atlanta.com;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:***@atlanta.com;tag=bmqkjhsd
To: sip:***@atlanta.com;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:***@atlanta.com SIP/2.0
Via: SIP/2.0/UDP 77.123.45.23:5060;branch=z9hG4bK56sdasks
From: sip:***@atlanta.com;tag=asdyka899
To: sip:***@atlanta.com
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sip:***@77.123.45.23: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:***@atlanta.com;tag=asdyka899
To: sip:***@atlanta.com
Call-ID: asidkj3ss
CSeq: 1 INVITE


F3 INVITE SIP Proxy -> Alice (transport TLS)

INVITE sips:***@93.12.40.105: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:***@atlanta.com;tag=asdyka899
To: sip:***@atlanta.com
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 69
Contact: <sip:***@77.123.45.23: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:***@atlanta.com;tag=asdyka899
To: sip:***@atlanta.com;tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 69
Contact: <sips:***@93.12.40.105: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:***@atlanta.com;tag=asdyka899
To: sip:***@atlanta.com;tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 69
Contact: <sips:***@93.12.40.105:20565;transport=tcp>
Content-Type: application/sdp


F6 ACK Bob -> SIP Proxy (transport UDP)

ACK sips:***@93.12.40.105: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:***@atlanta.com;tag=asdyka899
To: sip:***@atlanta.com;tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 ACK
Max-Forwards: 70


F7 ACK SIP Proxy -> Alice (transport TLS)

ACK sips:***@93.12.40.105: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:***@atlanta.com;tag=asdyka899
To: sip:***@atlanta.com;tag=bmqkjhsd
Call-ID: asidkj3ss
CSeq: 1 ACK
Max-Forwards: 69


F8 BYE Alice -> SIP Proxy (transport TLS)

BYE sip:***@77.123.45.23: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:***@atlanta.com;tag=bmqkjhsd
To: sip:***@atlanta.com;tag=asdyka899
Call-ID: asidkj3ss
CSeq: 1201 BYE
Max-Forwards: 70


F9 BYE SIP Proxy -> Bob (transport UDP)

BYE sip:***@77.123.45.23: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:***@atlanta.com;tag=bmqkjhsd
To: sip:***@atlanta.com;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:***@atlanta.com;tag=bmqkjhsd
To: sip:***@atlanta.com;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:***@atlanta.com;tag=bmqkjhsd
To: sip:***@atlanta.com;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
<***@aliax.net>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the

[Hadriel Kaplan]

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:

> 2011/9/15 Olle E. Johansson <***@edvina.net>:
>> 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.
>
> 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:***@atlanta.com SIP/2.0
> Via: SIP/2.0/TLS 93.12.40.105:20565;branch=z9hG4bK56sdasks
> From: sip:***@atlanta.com;tag=asdyka899
> To: sip:***@atlanta.com
> Call-ID: asidkj3ss
> CSeq: 1 INVITE
> Max-Forwards: 70
> Contact: <sips:***@93.12.40.105: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:***@atlanta.com;tag=asdyka899
> To: sip:***@atlanta.com
> Call-ID: asidkj3ss
> CSeq: 1 INVITE
>
>
> F3 INVITE SIP Proxy -> Carol (transport UDP)
>
> INVITE sip:***@77.123.45.23: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:***@atlanta.com;tag=asdyka899
> To: sip:***@atlanta.com
> Call-ID: asidkj3ss
> CSeq: 1 INVITE
> Max-Forwards: 69
> Contact: <sips:***@93.12.40.105: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:***@atlanta.com;tag=asdyka899
> To: sip:***@atlanta.com;tag=bmqkjhsd
> Call-ID: asidkj3ss
> CSeq: 1 INVITE
> Max-Forwards: 69
> Contact: <sip:***@77.123.45.23: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:***@atlanta.com;tag=asdyka899
> To: sip:***@atlanta.com;tag=bmqkjhsd
> Call-ID: asidkj3ss
> CSeq: 1 INVITE
> Max-Forwards: 69
> Contact: <sip:***@77.123.45.23:5060;transport=udp>
> Content-Type: application/sdp
>
>
> F6 ACK Alice -> SIP Proxy (transport TLS)
>
> ACK sip:***@77.123.45.23: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:***@atlanta.com;tag=asdyka899
> To: sip:***@atlanta.com;tag=bmqkjhsd
> Call-ID: asidkj3ss
> CSeq: 1 ACK
> Max-Forwards: 70
>
>
> F7 ACK SIP Proxy -> Carol (transport UDP)
>
> ACK sip:***@77.123.45.23: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:***@atlanta.com;tag=asdyka899
> To: sip:***@atlanta.com;tag=bmqkjhsd
> Call-ID: asidkj3ss
> CSeq: 1 ACK
> Max-Forwards: 69
>
>
> F8 BYE Carol -> SIP Proxy (transport UDP)
>
> BYE sips:***@93.12.40.105: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:***@atlanta.com;tag=bmqkjhsd
> To: sip:***@atlanta.com;tag=asdyka899
> Call-ID: asidkj3ss
> CSeq: 1201 BYE
> Max-Forwards: 70
>
>
> F9 BYE SIP Proxy -> Alice (transport TLS)
>
> BYE sips:***@93.12.40.105: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:***@atlanta.com;tag=bmqkjhsd
> To: sip:***@atlanta.com;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:***@atlanta.com;tag=bmqkjhsd
> To: sip:***@atlanta.com;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:***@atlanta.com;tag=bmqkjhsd
> To: sip:***@atlanta.com;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:***@atlanta.com SIP/2.0
> Via: SIP/2.0/UDP 77.123.45.23:5060;branch=z9hG4bK56sdasks
> From: sip:***@atlanta.com;tag=asdyka899
> To: sip:***@atlanta.com
> Call-ID: asidkj3ss
> CSeq: 1 INVITE
> Max-Forwards: 70
> Contact: <sip:***@77.123.45.23: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:***@atlanta.com;tag=asdyka899
> To: sip:***@atlanta.com
> Call-ID: asidkj3ss
> CSeq: 1 INVITE
>
>
> F3 INVITE SIP Proxy -> Alice (transport TLS)
>
> INVITE sips:***@93.12.40.105: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:***@atlanta.com;tag=asdyka899
> To: sip:***@atlanta.com
> Call-ID: asidkj3ss
> CSeq: 1 INVITE
> Max-Forwards: 69
> Contact: <sip:***@77.123.45.23: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:***@atlanta.com;tag=asdyka899
> To: sip:***@atlanta.com;tag=bmqkjhsd
> Call-ID: asidkj3ss
> CSeq: 1 INVITE
> Max-Forwards: 69
> Contact: <sips:***@93.12.40.105: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:***@atlanta.com;tag=asdyka899
> To: sip:***@atlanta.com;tag=bmqkjhsd
> Call-ID: asidkj3ss
> CSeq: 1 INVITE
> Max-Forwards: 69
> Contact: <sips:***@93.12.40.105:20565;transport=tcp>
> Content-Type: application/sdp
>
>
> F6 ACK Bob -> SIP Proxy (transport UDP)
>
> ACK sips:***@93.12.40.105: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:***@atlanta.com;tag=asdyka899
> To: sip:***@atlanta.com;tag=bmqkjhsd
> Call-ID: asidkj3ss
> CSeq: 1 ACK
> Max-Forwards: 70
>
>
> F7 ACK SIP Proxy -> Alice (transport TLS)
>
> ACK sips:***@93.12.40.105: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:***@atlanta.com;tag=asdyka899
> To: sip:***@atlanta.com;tag=bmqkjhsd
> Call-ID: asidkj3ss
> CSeq: 1 ACK
> Max-Forwards: 69
>
>
> F8 BYE Alice -> SIP Proxy (transport TLS)
>
> BYE sip:***@77.123.45.23: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:***@atlanta.com;tag=bmqkjhsd
> To: sip:***@atlanta.com;tag=asdyka899
> Call-ID: asidkj3ss
> CSeq: 1201 BYE
> Max-Forwards: 70
>
>
> F9 BYE SIP Proxy -> Bob (transport UDP)
>
> BYE sip:***@77.123.45.23: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:***@atlanta.com;tag=bmqkjhsd
> To: sip:***@atlanta.com;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:***@atlanta.com;tag=bmqkjhsd
> To: sip:***@atlanta.com;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:***@atlanta.com;tag=bmqkjhsd
> To: sip:***@atlanta.com;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
> <***@aliax.net>
> _______________________________________________
> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> This list is essentially closed and only used for finishing old business.
> Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
> Use ***@ietf.org for new developments on the application of sip.
> Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Iñaki Baz Castillo]

2011/9/15 Hadriel Kaplan <***@acmepacket.com>:
> 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.

If Alice wants to refer Bob to Carol, Alice would do better by sending
a REFER with "Refer-To: <sip:***@domain.org>" 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
<***@aliax.net>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance

[Iñaki Baz Castillo]

2011/9/15 Iñaki Baz Castillo <***@aliax.net>:
>> 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.
>
> If Alice wants to refer Bob to Carol, Alice would do better by sending
> a REFER with "Refer-To: <sip:***@domain.org>" rather than using
> 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
<***@aliax.net>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP

[Hadriel Kaplan]

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

On Sep 15, 2011, at 11:27 AM, "Iñaki Baz Castillo" <***@aliax.net> wrote:

> 2011/9/15 Hadriel Kaplan <***@acmepacket.com>:
>> 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.
>
> If Alice wants to refer Bob to Carol, Alice would do better by sending
> a REFER with "Refer-To: <sip:***@domain.org>" 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
> <***@aliax.net>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Iñaki Baz Castillo]

2011/9/15 Hadriel Kaplan <***@acmepacket.com>:
> 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
<***@aliax.net>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SI

[Iñaki Baz Castillo]

2011/9/15 Iñaki Baz Castillo <***@aliax.net>:
> Such URI could be no reachable if it's
> between some kind of NAT's (regardless the user used STUN).

s/between/behind/

--
Iñaki Baz Castillo
<***@aliax.net>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP spe

[Hadriel Kaplan]

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


On Sep 15, 2011, at 12:03 PM, Iñaki Baz Castillo wrote:

> 2011/9/15 Hadriel Kaplan <***@acmepacket.com>:
>> 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
> <***@aliax.net>

_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[DRAGE, Keith (Keith)]

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

> -----Original Message-----
> From: sip-***@ietf.org [mailto:sip-***@ietf.org] On Behalf Of
> Hadriel Kaplan
> Sent: 15 September 2011 17:31
> To: Iñaki Baz Castillo
> Cc: <***@ietf.org>; Olle E. Johansson
> Subject: Re: [Sip] Using TLS in the first hop - Bug in RFC 5630
>
>
> 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
>
>
> On Sep 15, 2011, at 12:03 PM, Iñaki Baz Castillo wrote:
>
> > 2011/9/15 Hadriel Kaplan <***@acmepacket.com>:
> >> 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
> > <***@aliax.net>
>
> _______________________________________________
> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> This list is essentially closed and only used for finishing old business.
> Use sip-***@cs.columbia.edu for questions on how to develop a SIP
> implementation.
> Use ***@ietf.org for new developments on the application of sip.
> Use ***@ietf.org for issues related to maintenance of the core SIP
> specifications.
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Iñaki Baz Castillo]

2011/9/15 DRAGE, Keith (Keith) <***@alcatel-lucent.com>:
> 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
<***@aliax.net>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP sp

[Samir Srivastava]

In line prefixed with SS>>

Regards
Samir

On Thu, Sep 15, 2011 at 10:05 AM, DRAGE, Keith (Keith) <
***@alcatel-lucent.com> wrote:

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

SS>> Refer the draft
http://datatracker.ietf.org/doc/draft-srivastava-dispatch-avoidance-of-threats/
submitted recently. And let me know your comments. What we intend to do in
future? As per my recollection Security Advisor was not in agreement with my
proposal. But it was told that there will be a day when this solution will
be needed,


>
> 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
>
> > -----Original Message-----
> > From: sip-***@ietf.org [mailto:sip-***@ietf.org] On Behalf Of
> > Hadriel Kaplan
> > Sent: 15 September 2011 17:31
> > To: Iñaki Baz Castillo
> > Cc: <***@ietf.org>; Olle E. Johansson
> > Subject: Re: [Sip] Using TLS in the first hop - Bug in RFC 5630
> >
> >
> > 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
> >
> >
> > On Sep 15, 2011, at 12:03 PM, Iñaki Baz Castillo wrote:
> >
> > > 2011/9/15 Hadriel Kaplan <***@acmepacket.com>:
> > >> 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
> > > <***@aliax.net>
> >
> > _______________________________________________
> > Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> > This list is essentially closed and only used for finishing old business.
> > Use sip-***@cs.columbia.edu for questions on how to develop a
> SIP
> > implementation.
> > Use ***@ietf.org for new developments on the application of sip.
> > Use ***@ietf.org for issues related to maintenance of the core SIP
> > specifications.
> _______________________________________________
> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> This list is essentially closed and only used for finishing old business.
> Use sip-***@cs.columbia.edu for questions on how to develop a SIP
> implementation.
> Use ***@ietf.org for new developments on the application of sip.
> Use ***@ietf.org for issues related to maintenance of the core SIP
> specifications.
>

[DRAGE, Keith (Keith)]

All drafts help things along, but please do have the discussion on DISPATCH or SIPCORE.

It doesn't belong here.

Keith

________________________________
From: Samir Srivastava [mailto:***@gmail.com]
Sent: 07 October 2011 20:34
To: DRAGE, Keith (Keith)
Cc: Hadriel Kaplan; Iñaki Baz Castillo; <***@ietf.org>; Olle E. Johansson
Subject: Re: [Sip] Using TLS in the first hop - Bug in RFC 5630

In line prefixed with SS>>

Regards
Samir

On Thu, Sep 15, 2011 at 10:05 AM, DRAGE, Keith (Keith) <***@alcatel-lucent.com<mailto:***@alcatel-lucent.com>> wrote:
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.

SS>> Refer the draft http://datatracker.ietf.org/doc/draft-srivastava-dispatch-avoidance-of-threats/ submitted recently. And let me know your comments. What we intend to do in future? As per my recollection Security Advisor was not in agreement with my proposal. But it was told that there will be a day when this solution will be needed,


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

> -----Original Message-----
> From: sip-***@ietf.org<mailto:sip-***@ietf.org> [mailto:sip-***@ietf.org<mailto:sip-***@ietf.org>] On Behalf Of
> Hadriel Kaplan
> Sent: 15 September 2011 17:31
> To: Iñaki Baz Castillo
> Cc: <***@ietf.org<mailto:***@ietf.org>>; Olle E. Johansson
> Subject: Re: [Sip] Using TLS in the first hop - Bug in RFC 5630
>
>
> 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
>
>
> On Sep 15, 2011, at 12:03 PM, Iñaki Baz Castillo wrote:
>
> > 2011/9/15 Hadriel Kaplan <***@acmepacket.com<mailto:***@acmepacket.com>>:
> >> 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
> > <***@aliax.net<mailto:***@aliax.net>>
>
> _______________________________________________
> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> This list is essentially closed and only used for finishing old business.
> Use sip-***@cs.columbia.edu<mailto:sip-***@cs.columbia.edu> for questions on how to develop a SIP
> implementation.
> Use ***@ietf.org<mailto:***@ietf.org> for new developments on the application of sip.
> Use ***@ietf.org<mailto:***@ietf.org> for issues related to maintenance of the core SIP
> specifications.
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu<mailto:sip-***@cs.columbia.edu> for questions on how to develop a SIP implementation.
Use ***@ietf.org<mailto:***@ietf.org> for new developments on the application of sip.
Use ***@ietf.org<mailto:***@ietf.org> for issues related to maintenance of the core SIP specifications.

[Horvath, Ernst]

Comment at the end...

> -----Original Message-----
> From: sip-***@ietf.org [mailto:sip-***@ietf.org] On
> Behalf Of Iñaki Baz Castillo
> Sent: Donnerstag, 15. September 2011 15:39
> To: Olle E. Johansson
> Cc: ***@ietf.org
> Subject: Re: [Sip] Using TLS in the first hop - Bug in RFC 5630
>
> 2011/9/15 Olle E. Johansson <***@edvina.net>:
> >> 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.
> >>
> > 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:***@atlanta.com;transport=tcp" and
> "sips:***@atlanta.com;transport=sctp" are both valid (although
> note that UDP is not a valid transport for SIPS). The use of
> "transport=tls" has consequently been deprecated, partly because
> it was specific to a single hop of the request. This
> is a change
> since RFC 2543.
>
> "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:
>
> INVITE sip:***@biloxi.com SIP/2.0
> Via: SIP/2.0/TLS 1.2.3.4
> From: sip:***@atlanta.com
> Contact: sips:***@1.2.3.4;transport=tcp
>
> 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.
>
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
> <***@aliax.net>
> _______________________________________________
> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> This list is essentially closed and only used for finishing
> old business.
> Use sip-***@cs.columbia.edu for questions on how to
> develop a SIP implementation.
> Use ***@ietf.org for new developments on the application of sip.
> Use ***@ietf.org for issues related to maintenance of the
> core SIP specifications.
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Iñaki Baz Castillo]

2011/9/15 Horvath, Ernst <***@siemens-enterprise.com>:
> 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.

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

Regards.

--
Iñaki Baz Castillo
<***@aliax.net>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issue

[Iñaki Baz Castillo]

2011/9/15 Iñaki Baz Castillo <***@aliax.net>:
>> 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.

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
<***@aliax.net>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues

[Olle E. Johansson]

15 sep 2011 kl. 16:30 skrev Iñaki Baz Castillo:

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

Proven by this confusing discussion.

/O
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Horvath, Ernst]

inline

> -----Original Message-----
> From: Iñaki Baz Castillo [mailto:***@aliax.net]
> Sent: Donnerstag, 15. September 2011 16:31
> To: Horvath, Ernst
> Cc: ***@ietf.org
> Subject: Re: [Sip] Using TLS in the first hop - Bug in RFC 5630
>
> 2011/9/15 Iñaki Baz Castillo <***@aliax.net>:
> >> 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.
>
> 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.

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

>
> 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
> <***@aliax.net>
>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Iñaki Baz Castillo]

2011/9/16 Horvath, Ernst <***@siemens-enterprise.com>:
> 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]).

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
<***@aliax.net>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of t

[DRAGE, Keith (Keith)]

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

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

> -----Original Message-----
> From: sip-***@ietf.org [mailto:sip-***@ietf.org] On Behalf Of
> Iñaki Baz Castillo
> Sent: 16 September 2011 12:08
> To: Horvath, Ernst
> Cc: ***@ietf.org
> Subject: Re: [Sip] Using TLS in the first hop - Bug in RFC 5630
>
> 2011/9/16 Horvath, Ernst <***@siemens-enterprise.com>:
> > 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]).
>
> 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
> <***@aliax.net>
> _______________________________________________
> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> This list is essentially closed and only used for finishing old business.
> Use sip-***@cs.columbia.edu for questions on how to develop a SIP
> implementation.
> Use ***@ietf.org for new developments on the application of sip.
> Use ***@ietf.org for issues related to maintenance of the core SIP
> specifications.
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Iñaki Baz Castillo]

2011/9/16 DRAGE, Keith (Keith) <***@alcatel-lucent.com>:
> 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.

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
<***@aliax.net>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the co

[Vijay K. Gurbani]

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} / ***@alcatel-lucent.com
Web: http://ect.bell-labs.com/who/vkg/
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Iñaki Baz Castillo]

2011/9/16 Vijay K. Gurbani <***@bell-labs.com>:
> 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.

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
<***@aliax.net>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related

[DRAGE, Keith (Keith)]

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

Keith

> -----Original Message-----
> From: Iñaki Baz Castillo [mailto:***@aliax.net]
> Sent: 16 September 2011 15:22
> To: Gurbani, Vijay K (Vijay)
> Cc: DRAGE, Keith (Keith); Horvath, Ernst; ***@ietf.org
> Subject: Re: [Sip] Using TLS in the first hop - Bug in RFC 5630
>
> 2011/9/16 Vijay K. Gurbani <***@bell-labs.com>:
> > 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.
>
> 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
> <***@aliax.net>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[DRAGE, Keith (Keith)]

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

> -----Original Message-----
> From: sip-***@ietf.org [mailto:sip-***@ietf.org] On Behalf Of
> DRAGE, Keith (Keith)
> Sent: 16 September 2011 15:23
> To: Iñaki Baz Castillo; Gurbani, Vijay K (Vijay)
> Cc: ***@ietf.org; Horvath, Ernst
> Subject: Re: [Sip] Using TLS in the first hop - Bug in RFC 5630
>
> I would suggest moving the discussion to either SIPCORE or DISPATCH.
>
> Keith
>
> > -----Original Message-----
> > From: Iñaki Baz Castillo [mailto:***@aliax.net]
> > Sent: 16 September 2011 15:22
> > To: Gurbani, Vijay K (Vijay)
> > Cc: DRAGE, Keith (Keith); Horvath, Ernst; ***@ietf.org
> > Subject: Re: [Sip] Using TLS in the first hop - Bug in RFC 5630
> >
> > 2011/9/16 Vijay K. Gurbani <***@bell-labs.com>:
> > > 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.
> >
> > 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
> > <***@aliax.net>
> _______________________________________________
> Sip mailing list https://www.ietf.org/mailman/listinfo/sip
> This list is essentially closed and only used for finishing old business.
> Use sip-***@cs.columbia.edu for questions on how to develop a SIP
> implementation.
> Use ***@ietf.org for new developments on the application of sip.
> Use ***@ietf.org for issues related to maintenance of the core SIP
> specifications.
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.

[Iñaki Baz Castillo]

2011/9/16 DRAGE, Keith (Keith) <***@alcatel-lucent.com>:
> 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
<***@aliax.net>
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of

[Olle E. Johansson]

16 sep 2011 kl. 14:18 skrev DRAGE, Keith (Keith):

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

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
_______________________________________________
Sip mailing list https://www.ietf.org/mailman/listinfo/sip
This list is essentially closed and only used for finishing old business.
Use sip-***@cs.columbia.edu for questions on how to develop a SIP implementation.
Use ***@ietf.org for new developments on the application of sip.
Use ***@ietf.org for issues related to maintenance of the core SIP specifications.