Subject: [Sip] Re: I-D ACTION:draft-audet-sip-sips-guidelines-00.txt

From: Paul Kyzivat <[email-masked]>
Date: Mon, 10 Apr 2006 16:52:35 -0400

Francois,

Its good that there is now work on this, since it is a very 
underspecified subject.

I have a number of comments. These aren't complete answers to anything, 
but are a start at discussion of some issues.

	Paul

> 3.  Upgrading and dowgrading between SIP and SIPS

This is complicated because the scheme name was used to signify this 
property. Given that is the way it is, IMO both upgrading and 
downgrading should be permitted, with the understanding that either 
change may fail if the called party doesn't support it.

Note, I don't mean downgrading in mid-call. I mean that that someone in 
possession of a sip URI may derive and use the corresponding sips URI to 
send a request, and visa versa. A given request would have to be all-sip 
or all-sips end-to-end.

>    Upgrading a SIP to a SIPS URI AOR is very useful when registering.
>    It allows for a UAC to register both SIP and SIPS contacts in a
>    single registration (with multiple contacts) against a single SIP AOR
>    (registrations only allows for single AOR, but multiple contacts).
>    The registrar, upon seeing both a SIP and SIPS contact (potentially
>    prioritized with a proper q-value), and a single SIP AOR MUST infer
>    that the user is reachabe with a SIPS AOR consisting of the same AOR
>    as the SIP URI, but with the scheme changed from "sip" to "sips". 

I agree with the goal to eliminate the need for separately registering 
to a SIP and SIPS AOR. I also agree that there should be one way to 
register for support of both sip and sips - you shouldn't have to guess 
how the registrar does it. This may require the use of an option tag.

But it seems entirely redundant to register two different contacts in 
order to support both secure and insecure calls. It also may be 
impossible to do both in a single REGISTER if a NAT is involved and 
-outbound- is required to resolve that.

The trick is how to indicate what is intended. It seems to me the 
following should do the trick:

- If you want the possibility of security, then the R-URI of the
   REGISTER must be SIPS.

- if you support only SIPS, then the Contact address in the register
   needs to be SIPS.

- if you support either SIP or SIPS, then the Contact address in the
   REGISTER needs to be SIP with transport=tls. (I don't think this has
   been deprecated. More on this later.)

   (The SIP contact with transport=tls can be safely upgraded to a
   SIPS contact with transport=tcp. There is however a problem with
   SCTP - TBD.)

- if you only want to support SIP, then the contact address can be
   SIP without transport=tls.

- I'm not sure about requirements on To (or From) in the REGISTER.
   With above it doesn't seem to matter.

- There need to be some rules about Path and Service-Route.
   I'm not sure about those yet.

>    OPEN ISSUE: RFC 3261 is not very clear what a UAS is to do if it
>       doesn't support SIPS and TLS, in which case the previous paragraph
>       obviously can not apply.  Shoud we state that the UAS MUST reject
>       the request with response code 416?  In that case, should we say
>       that the UAC MUST NOT re-attempt the request with a SIP URI by
>       automatically replacing the SIPS scheme with a SIP scheme?

The 416 seems right to me.

But I see no reason to forbid the UAC from retrying with SIP. This 
should be a policy issue for it. What is essential is that it indicate 
to its user if the connection is secure or not. (This could get complex, 
since security of signaling and media are separate things. So you might 
have multiple lock icons in the UI.)

>    When a target refresh occurs within a dialog (e.g., re-INVITE,
>    UPDATE), the UAC SHOULD include a Contact header with a SIPS URI if
>    the original request creating the dialog was sent over TLS, and the
>    Request-URI contained a SIPS URI.

I don't see why this should be forbidden in a *request*, where it may be 
refused. It is problematic in a response, where it can't be refused. 
Changing the level of security mid-dialog could be useful, at least in 
the case of 3pcc. It may reflect a transfer where the new partner 
doesn't have the same capabilities or requirements. OTOH, making the 
change in a response is also needed for many useful 3pcc flows.

>    OPEN ISSUE: Handling of annomalies are not very well defined in RFC
>       3261.  For example, what if the request contains a SIPS contact
>       but the response contains a SIP contact?  What if a UAS receives a
>       SIP Contact replacing a SIPS contact in a target refresh?

I guess the same options are available as when there is an unacceptable 
offer in a response: either cope with the undesired change, or else tear 
down the dialog if you can't live with it.

>    RFC 3261 makes it clear that the use of the "transport=tls" URI
>    transport parameter in SIPS or SIP URIs has been deprecated.
>    However, it has not been eliminated from the ABNF in section 25 of
>    RFC 3261.

That isn't so clear to me. It seems to clearly ban this parameter in a 
SIPS URI, but I don't see the words as banning it in a SIP URI.

The value in using it, as mentioned above, is that it means a TLS hop 
can be used for either insecure requests, but that the URI could also be 
upgraded to SIPS in order that it be permissible in a transaction that 
is using SIPS. This seems necessary to avoid two separate connections 
when using -outbound- for nat traversal.

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

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 17 Apr 2006 15:56:26 -0500

> have multiple lock icons in the UI.)

OK. I agree.

I'll change the text accordingly.

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 17 Apr 2006 16:13:44 -0500

> change in a response is also needed for many useful 3pcc flows.

OK. I'll align the wording with RFC 3261 section 12.2.1.1 which 
acknowledges that there might be reasons to change it.