headers
Iñaki Baz Castillo | 15 Sep 2011 15:01
Gravatar

Using TLS in the first hop - Bug in RFC 5630

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:bob <at> biloxi.com SIP/2.0
  Via: SIP/2.0/TLS 1.2.3.4
  From: sip:alice <at> atlanta.com
  Contact: sip:alice <at> 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 !!!
(Continue reading)

Permalink | Reply |
headers
Olle E. Johansson | 15 Sep 2011 15:23
Gravatar

Re: Using TLS in the first hop - Bug in RFC 5630


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:bob <at> biloxi.com SIP/2.0
>  Via: SIP/2.0/TLS 1.2.3.4
(Continue reading)

Permalink | Reply |
headers
Iñaki Baz Castillo | 15 Sep 2011 15:38
Gravatar

Re: Using TLS in the first hop - Bug in RFC 5630

2011/9/15 Olle E. Johansson <oej <at> 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:alice <at> atlanta.com;transport=tcp" and
      "sips:alice <at> 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:
(Continue reading)

Permalink | Reply |
headers
Olle E. Johansson | 15 Sep 2011 15:46
Gravatar

Re: Using TLS in the first hop - Bug in RFC 5630


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

> 2011/9/15 Olle E. Johansson <oej <at> 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:alice <at> atlanta.com;transport=tcp" and
>      "sips:alice <at> 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
(Continue reading)

Permalink | Reply |
headers
Iñaki Baz Castillo | 15 Sep 2011 16:25
Gravatar

Re: Using TLS in the first hop - Bug in RFC 5630

2011/9/15 Olle E. Johansson <oej <at> 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:bob <at> atlanta.com SIP/2.0
Via: SIP/2.0/TLS 93.12.40.105:20565;branch=z9hG4bK56sdasks
From: sip:alice <at> atlanta.com;tag=asdyka899
To: sip:bob <at> atlanta.com
Call-ID: asidkj3ss
CSeq: 1 INVITE
Max-Forwards: 70
Contact: <sips:alice <at> 93.12.40.105:20565;transport=tcp>
Content-Type: application/sdp

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

SIP/2.0 100 Trying
(Continue reading)

Permalink | Reply |
headers
Hadriel Kaplan | 15 Sep 2011 17:22
Favicon

Re: Using TLS in the first hop - Bug in RFC 5630


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 <oej <at> 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:bob <at> atlanta.com SIP/2.0
(Continue reading)

Permalink | Reply |
headers
Iñaki Baz Castillo | 15 Sep 2011 17:27
Gravatar

Re: Using TLS in the first hop - Bug in RFC 5630

2011/9/15 Hadriel Kaplan <HKaplan <at> 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:carol <at> 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
<ibc <at> 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-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.
Permalink | Reply |
headers
Iñaki Baz Castillo | 15 Sep 2011 17:33
Gravatar

Re: Using TLS in the first hop - Bug in RFC 5630

2011/9/15 Iñaki Baz Castillo <ibc <at> 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:carol <at> 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
<ibc <at> 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-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.
Permalink | Reply |
headers
Hadriel Kaplan | 15 Sep 2011 17:41
Favicon

Re: Using TLS in the first hop - Bug in RFC 5630

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" <ibc <at> aliax.net> wrote:

> 2011/9/15 Hadriel Kaplan <HKaplan <at> 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:carol <at> 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
> <ibc <at> aliax.net>
_______________________________________________
(Continue reading)

Permalink | Reply |
headers
Iñaki Baz Castillo | 15 Sep 2011 18:03
Gravatar

Re: Using TLS in the first hop - Bug in RFC 5630

2011/9/15 Hadriel Kaplan <HKaplan <at> 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
<ibc <at> 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-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.
Permalink | Reply |
headers
Iñaki Baz Castillo | 15 Sep 2011 18:04
Gravatar

Re: Using TLS in the first hop - Bug in RFC 5630

2011/9/15 Iñaki Baz Castillo <ibc <at> 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
<ibc <at> 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-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.
Permalink | Reply |
headers
Hadriel Kaplan | 15 Sep 2011 18:31
Favicon

Re: 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 <HKaplan <at> 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
> <ibc <at> aliax.net>

_______________________________________________
(Continue reading)

Permalink | Reply |
headers
DRAGE, Keith (Keith | 15 Sep 2011 19:05
Favicon

Re: Using TLS in the first hop - Bug in RFC 5630

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-bounces <at> ietf.org [mailto:sip-bounces <at> ietf.org] On Behalf Of
> Hadriel Kaplan
> Sent: 15 September 2011 17:31
> To: Iñaki Baz Castillo
> Cc: <sip <at> ietf.org>; Olle E. Johansson
> Subject: Re: [Sip] Using TLS in the first hop - Bug in RFC 5630
> 
>
(Continue reading)

Permalink | Reply |
headers
Iñaki Baz Castillo | 15 Sep 2011 19:50
Gravatar

Re: Using TLS in the first hop - Bug in RFC 5630

2011/9/15 DRAGE, Keith (Keith) <keith.drage <at> 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
<ibc <at> 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-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.
Permalink | Reply |
headers
Samir Srivastava | 7 Oct 2011 21:33
Picon

Re: 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) <keith.drage <at> 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-bounces <at> ietf.org [mailto:sip-bounces <at> ietf.org] On Behalf Of
> Hadriel Kaplan
> Sent: 15 September 2011 17:31
> To: Iñaki Baz Castillo
> Cc: <sip <at> 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 <HKaplan <at> 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
> > <ibc <at> 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-implementors <at> cs.columbia.edu for questions on how to develop a SIP
> implementation.
> Use dispatch <at> ietf.org for new developments on the application of sip.
> Use sipcore <at> 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-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> 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-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.
Permalink | Reply |
headers
DRAGE, Keith (Keith | 8 Oct 2011 11:08
Favicon

Re: Using TLS in the first hop - Bug in RFC 5630

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:samirs.lists <at> gmail.com]
Sent: 07 October 2011 20:34
To: DRAGE, Keith (Keith)
Cc: Hadriel Kaplan; Iñaki Baz Castillo; <sip <at> 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) <keith.drage <at> 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-bounces <at> ietf.org [mailto:sip-bounces <at> ietf.org] On Behalf Of
> Hadriel Kaplan
> Sent: 15 September 2011 17:31
> To: Iñaki Baz Castillo
> Cc: <sip <at> 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 <HKaplan <at> 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
> > <ibc <at> 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-implementors <at> cs.columbia.edu for questions on how to develop a SIP
> implementation.
> Use dispatch <at> ietf.org for new developments on the application of sip.
> Use sipcore <at> 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-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> 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-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.
Permalink | Reply |
headers
Horvath, Ernst | 15 Sep 2011 15:58

Re: Using TLS in the first hop - Bug in RFC 5630

Comment at the end...

> -----Original Message-----
> From: sip-bounces <at> ietf.org [mailto:sip-bounces <at> ietf.org] On 
> Behalf Of Iñaki Baz Castillo
> Sent: Donnerstag, 15. September 2011 15:39
> To: Olle E. Johansson
> Cc: sip <at> ietf.org
> Subject: Re: [Sip] Using TLS in the first hop - Bug in RFC 5630
> 
> 2011/9/15 Olle E. Johansson <oej <at> 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:alice <at> atlanta.com;transport=tcp" and
>       "sips:alice <at> 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:bob <at> biloxi.com SIP/2.0
>   Via: SIP/2.0/TLS 1.2.3.4
>   From: sip:alice <at> atlanta.com
>   Contact: sips:alice <at> 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
> <ibc <at> 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-implementors <at> cs.columbia.edu for questions on how to 
> develop a SIP implementation.
> Use dispatch <at> ietf.org for new developments on the application of sip.
> Use sipcore <at> 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-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.
Permalink | Reply |
headers
Iñaki Baz Castillo | 15 Sep 2011 16:08
Gravatar

Re: Using TLS in the first hop - Bug in RFC 5630

2011/9/15 Horvath, Ernst <ernst.horvath <at> 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
<ibc <at> 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-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.
Permalink | Reply |
headers
Iñaki Baz Castillo | 15 Sep 2011 16:30
Gravatar

Re: Using TLS in the first hop - Bug in RFC 5630

2011/9/15 Iñaki Baz Castillo <ibc <at> 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
<ibc <at> 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-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.
Permalink | Reply |
headers
Olle E. Johansson | 15 Sep 2011 16:44
Gravatar

Re: Using TLS in the first hop - Bug in RFC 5630


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-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.
Permalink | Reply |
headers
Horvath, Ernst | 16 Sep 2011 12:12

Re: Using TLS in the first hop - Bug in RFC 5630

inline 

> -----Original Message-----
> From: Iñaki Baz Castillo [mailto:ibc <at> aliax.net] 
> Sent: Donnerstag, 15. September 2011 16:31
> To: Horvath, Ernst
> Cc: sip <at> ietf.org
> Subject: Re: [Sip] Using TLS in the first hop - Bug in RFC 5630
> 
> 2011/9/15 Iñaki Baz Castillo <ibc <at> 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
> <ibc <at> 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-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.
Permalink | Reply |
headers
Iñaki Baz Castillo | 16 Sep 2011 13:08
Gravatar

Re: Using TLS in the first hop - Bug in RFC 5630

2011/9/16 Horvath, Ernst <ernst.horvath <at> 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
<ibc <at> 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-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.
Permalink | Reply |
headers
DRAGE, Keith (Keith | 16 Sep 2011 14:18
Favicon

Re: Using TLS in the first hop - Bug in RFC 5630

> 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-bounces <at> ietf.org [mailto:sip-bounces <at> ietf.org] On Behalf Of
> Iñaki Baz Castillo
> Sent: 16 September 2011 12:08
> To: Horvath, Ernst
> Cc: sip <at> ietf.org
> Subject: Re: [Sip] Using TLS in the first hop - Bug in RFC 5630
> 
> 2011/9/16 Horvath, Ernst <ernst.horvath <at> 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
> <ibc <at> 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-implementors <at> cs.columbia.edu for questions on how to develop a SIP
> implementation.
> Use dispatch <at> ietf.org for new developments on the application of sip.
> Use sipcore <at> 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-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.
Permalink | Reply |
headers
Iñaki Baz Castillo | 16 Sep 2011 14:46
Gravatar

Re: Using TLS in the first hop - Bug in RFC 5630

2011/9/16 DRAGE, Keith (Keith) <keith.drage <at> 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
<ibc <at> 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-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.
Permalink | Reply |
headers
Vijay K. Gurbani | 16 Sep 2011 15:25
Favicon

Re: Using TLS in the first hop - Bug in RFC 5630

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 <at> {bell-labs.com,acm.org} / vijay.gurbani <at> 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-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.
Permalink | Reply |
headers
Iñaki Baz Castillo | 16 Sep 2011 16:21
Gravatar

Re: Using TLS in the first hop - Bug in RFC 5630

2011/9/16 Vijay K. Gurbani <vkg <at> 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
<ibc <at> 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-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.
Permalink | Reply |
headers
DRAGE, Keith (Keith | 16 Sep 2011 16:23
Favicon

Re: 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:ibc <at> aliax.net]
> Sent: 16 September 2011 15:22
> To: Gurbani, Vijay K (Vijay)
> Cc: DRAGE, Keith (Keith); Horvath, Ernst; sip <at> ietf.org
> Subject: Re: [Sip] Using TLS in the first hop - Bug in RFC 5630
> 
> 2011/9/16 Vijay K. Gurbani <vkg <at> 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
> <ibc <at> 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-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.
Permalink | Reply |
headers
DRAGE, Keith (Keith | 16 Sep 2011 16:35
Favicon

Re: Using TLS in the first hop - Bug in RFC 5630

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-bounces <at> ietf.org [mailto:sip-bounces <at> ietf.org] On Behalf Of
> DRAGE, Keith (Keith)
> Sent: 16 September 2011 15:23
> To: Iñaki Baz Castillo; Gurbani, Vijay K (Vijay)
> Cc: sip <at> 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:ibc <at> aliax.net]
> > Sent: 16 September 2011 15:22
> > To: Gurbani, Vijay K (Vijay)
> > Cc: DRAGE, Keith (Keith); Horvath, Ernst; sip <at> ietf.org
> > Subject: Re: [Sip] Using TLS in the first hop - Bug in RFC 5630
> >
> > 2011/9/16 Vijay K. Gurbani <vkg <at> 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
> > <ibc <at> 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-implementors <at> cs.columbia.edu for questions on how to develop a SIP
> implementation.
> Use dispatch <at> ietf.org for new developments on the application of sip.
> Use sipcore <at> 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-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.
Permalink | Reply |
headers
Iñaki Baz Castillo | 16 Sep 2011 16:40
Gravatar

Re: Using TLS in the first hop - Bug in RFC 5630

2011/9/16 DRAGE, Keith (Keith) <keith.drage <at> 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
<ibc <at> 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-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.
Permalink | Reply |
headers
Olle E. Johansson | 16 Sep 2011 15:26
Gravatar

Re: Using TLS in the first hop - Bug in RFC 5630


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-implementors <at> cs.columbia.edu for questions on how to develop a SIP implementation.
Use dispatch <at> ietf.org for new developments on the application of sip.
Use sipcore <at> ietf.org for issues related to maintenance of the core SIP specifications.
Permalink | Reply |

Gmane