Subject: [Sip] some comments on draft-ietf-sip-sips

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 20 Mar 2007 20:52:26 -0400

In a separate thread, we've been discussing whether we can make this 
draft normative and finally go about 'fixing' the things that make SIPS 
broken. Besides the last hop exception problem, there is another bit 
which is very problematic:

>  The presence of a SIPS Request-URI does not necessarily indicate that
>    the request was sent securely on each hop.  As described in
>    [RFC3261]/26.4.4, a proxy may legitimately retarget a request from
>    SIP to SIPS.  Therefore, a UAS MUST NOT assume on the basis of the
>    Request-URI alone that SIPS was used for the entire request path.

Retargeting from sips to sip is a lot like the last hop exception rule, 
and it really ruins the ability for the UAS to verify the main security 
property provided by SIPS. Instead of the ad-hoc algorithms suggested as 
ways to actually verify this, can we change this rule? Proxy MUST NOT 
retarget a sips URI to sip. I think I've suggested tihs in the past that 
I think we need to outright forbid up and downgrades.

Section 4.2 - does this evaporate if we can make this change to not 
change sip to sips?

Indeed I think this document becomes oodles simpler when we eliminate 
these two exceptions. I think the doc is still pretty complicated since 
there are so many exceptions and variations. I want it to be, you ar 
eeither sips, in which case EVERYTHING is sips, or you are sip, in which 
case NOTHING is sips. Really easy that way, and it gives us the security 
property we need.

>  The USC registers either a SIPS or a SIP AOR.  From a routing
>    perspective, it does not matter which one is used for registration as
>    they identify the same resource.
> 
>    If all the Contacts are SIPS, a SIPS AOR MUST also be used by the
>    UAC.  If at least one of the Contacts is SIP or is neither SIP nor
>    SIPS (e.g., mailto, tel, http, https), a SIP AOR MUST also be used by
>    the UAC.

isn't this a contradiction? The first paragraph says that it doesn't 
matter whether you use sip or sips. Then the next says why you pick a 
sip or sips aor.

Also I tihnk the text should be restructured a bit to say that, a UA can 
operate in one of three modes - sips only, sip only or either. And then 
based on that, how do you set each of the parameters in the REGISTER 
(To, from, contact, r-uri). The current text is inverted and you have to 
work backwards in some places to sort it out.

I don't really see why the AOR in the To is relevant at all (sip vs. sips).

>  A registrar MUST only accept a binding to a SIPS Contact if all the
>    appropriate URIs are of the SIPS scheme: i.e., the Request-URI, the
>    AOR (i.e., To header), the From header, the Contacts and all the Path
>    headers.  If the URIs are not of the proper SIPS scheme, it must
>    reject the REGISTER with a 403 "Forbidden".

I don't see why the To and From are relevant. Indeed I think a sips 
contact can be accepted as long as the r-uri was sips. For path, its 
really a double check since they should have been sips based on other 
rules, should probably make that clear.

>   SIPS in a Dialog
> 
>    There MUST be only one Contact in any request resulting in the
>    establishment of a dialog (e.g., INVITE, SUBSCRIBE, REFER).

This is a basic 3261 requirement having nothing to do with sips; might 
want to merely state this as fact.

> As mandated by [RFC3261]/8.1.1.8, in a request, if the Request-URI or
>    top Route header field value contains a SIPS URI, the Contact header
>    field MUST contain a SIPS URI as well.  Furthermore, as mandated by
>    [RFC3261]/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 f

There are three statemenets in the or condition. However, if the first 
is true, and we eliminate the last hop exception and retarget exception, 
unless there is a protocol error the others will be true too. This is 
one of many places where sips is just way simpler if we do that.

> be careful about what to use in the Contact (in case Record-Route is
>    not used for this hop).  If the Contact was a SIPS URI, it would mean
>    that it would only accept mid-dialog requests that are over secure
>    transport end-to-end.  Since the Request-URI is in this case a SIP
>    URI, it is quite possible that the UA sending a request to that URI
>    may not be able to send requests to SIPS URIs.  It is therefore
>    RECOMMENDED that in this case, the Contact be a SIP URI, 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
>    [I-D.ietf-sip-outbound]).

why is this just RECOMMENDED and not MUST?

> When a target refresh occurs within a dialog (e.g., re-INVITE,
>    UPDATE), unless there is a need to change it, the UAC SHOULD include
>    a Contact header with a SIPS URI if the original request used a SIPS
>    Request-URI.

why not MUST?

>  Sessions, dialogs and transactions may be "derived" from existings
>    ones.
> 
>    As a general principle, derived dialogs and transactions SHOULD NOT
>    result in an effective downgrading of SIPS to SIP, without the
>    explicit authorization of the entities involved.

unless you formally define 'derived' this is a meaningless requirement.

>  However, for backward compatibility, if a "transport=tls" parameter
>    is received, it should be interpreted as per the following
>    guidelines:
> 
>    o  [RFC3261]/16.7 states the transport parameter (e.g., with tcp or
>       udp) SHOULD NOT be used in Record-Route unless it has knowledge
>       that the next upstream element that will be in the path of
>       subsequent supports this transport.  Generally, it is recommended
>       that the transport parameter never be used in a Record-Route,
>       Route or Path header.  Since the transport=tls URI parameter has
>       been deprecated, it MUST NOT be used in Route, Record-Route or
>       Path headers, and MUST be ignored.
>    o  In a Contact in a dialog, it MAY be interpreted as a request to
>       send incoming mid-dialog requests using TLS.  Note that this would
>       only have a significance if [I-D.ietf-sip-outbound] and Record-
>       Route are not used, and if that URI is nevertheless reachable with
>       TLS which is extremely unlikely.  If it was the case that it was
>       reachable with TLS, say because there is an active TLS connection,

the first paragraph says that what follows will be what to do if you 
receive transport=tls, but the first bullet is about sending it. In that 
paragraph you say its 'recommneded' not to be used in RR, Route or Path, 
and then next sentence is MUST NOT. So which is it?

If this is normative do we need to carry forward text on transport=tls 
beyond saying don't send and ignore on receive?

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[email-masked]                              FAX:   (973) 952-5050
http://www.jdrosen.net                         PHONE: (973) 952-5000
http://www.cisco.com

_______________________________________________
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: [email-masked] (Juha Heinanen)
Date: Wed, 21 Mar 2007 07:42:33 +0200

Jonathan Rosenberg writes:

 > Proxy MUST NOT 

yes, this was discussed before and i support the proposal.

-- juha

---

From: Dean Willis <[email-masked]>
Date: Wed, 21 Mar 2007 10:07:29 +0100

On Mar 21, 2007, at 1:52 AM, Jonathan Rosenberg wrote:

> In a separate thread, we've been discussing whether we can make  
> this draft normative and finally go about 'fixing' the things that  
> make SIPS broken. Besides the last hop exception problem, there is  
> another bit which is very problematic:
>
> Retargeting from sips to sip is a lot like the last hop exception  
> rule, and it really ruins the ability for the UAS to verify the  
> main security property provided by SIPS. Instead of the ad-hoc  
> algorithms suggested as ways to actually verify this, can we change  
> this rule? Proxy MUST NOT retarget a sips URI to sip. I think I've  
> suggested tihs in the past that I think we need to outright forbid  
> up and downgrades.

There is NO WAY for the UAS to verify the main security property  
provided by SIPS, since any two upstream nodes could collude and  
violate the security principle of SIPS even with your proposed rule  
change in place.

We either stop thinking that use of SIPS tells us ANYTHING about  
security -- It's just a request that may or may not have been  
honored, OR we fix SIPS so that it has the verification property  
you're asking for. And fixing it requires substantially changing the  
way it works, which is probably outside the scope of this document.

--
Dean

---

From: [email-masked] (Juha Heinanen)
Date: Wed, 21 Mar 2007 11:18:11 +0200

> way it works, which is probably outside the scope of this document.

i agree with this too and have proposed many times that while this
substantial work is being done, we depreciate current version of sips as
useless.  people can and are using tls transport without sips for
hop-by-hop security.

-- juha

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 21 Mar 2007 04:45:40 -0500

See below. 

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Tuesday, March 20, 2007 17:52
> To: IETF SIP List
> Subject: [Sip] some comments on draft-ietf-sip-sips
> 
> In a separate thread, we've been discussing whether we can 
> make this draft normative and finally go about 'fixing' the 
> things that make SIPS broken. Besides the last hop exception 
> problem, there is another bit which is very problematic:
> 
> Retargeting from sips to sip is a lot like the last hop 
> exception rule, and it really ruins the ability for the UAS 
> to verify the main security property provided by SIPS. 
> Instead of the ad-hoc algorithms suggested as ways to 
> actually verify this, can we change this rule? Proxy MUST NOT 
> retarget a sips URI to sip. I think I've suggested tihs in 
> the past that I think we need to outright forbid up and downgrades.

I agree. It's bad to retarget from SIPS to SIP. It's also bad to
retarget from SIP to SIPS.

I would personally support such a change.

You might want to bring it up during the presentation.

> Section 4.2 - does this evaporate if we can make this change 
> to not change sip to sips?

Yes, it would evaporate, but only if we forbid both retargeting from
SIPS to SIP and from SIP to SIPS.

> Indeed I think this document becomes oodles simpler when we 
> eliminate these two exceptions. I think the doc is still 
> pretty complicated since there are so many exceptions and 
> variations. I want it to be, you ar eeither sips, in which 
> case EVERYTHING is sips, or you are sip, in which case 
> NOTHING is sips. Really easy that way, and it gives us the 
> security property we need.

I agree. Life would be easier.

> isn't this a contradiction? The first paragraph says that it 
> doesn't matter whether you use sip or sips. Then the next 
> says why you pick a sip or sips aor.
> 
> Also I tihnk the text should be restructured a bit to say 
> that, a UA can operate in one of three modes - sips only, sip 
> only or either. And then based on that, how do you set each 
> of the parameters in the REGISTER (To, from, contact, r-uri). 
> The current text is inverted and you have to work backwards 
> in some places to sort it out.
> 

That's what the text is trying to say. It doesn't matter what the
AOR says.

I will look at clarifying the text. I understand what you are saying.

> I don't see why the To and From are relevant. Indeed I think 
> a sips contact can be accepted as long as the r-uri was sips. 
> For path, its really a double check since they should have 
> been sips based on other rules, should probably make that clear.

I can certainly change that.

> This is a basic 3261 requirement having nothing to do with 
> sips; might want to merely state this as fact.

Yes, correct. I'll fix.

> There are three statemenets in the or condition. However, if 
> the first is true, and we eliminate the last hop exception 
> and retarget exception, unless there is a protocol error the 
> others will be true too. This is one of many places where 
> sips is just way simpler if we do that.

Agreed.

> why is this just RECOMMENDED and not MUST?

The reason was that I was trying to avoid making mandatory additions
to RFC 3261.

But personally, I agree with you that ambiguity is bad. I certainly
would support making changes the make things clearer, even if they
are mandatory requirements.

> >    a Contact header with a SIPS URI if the original request 

Same as above.

> unless you formally define 'derived' this is a meaningless 

Ok, I will clarify.
 
> the first paragraph says that what follows will be what to do 
> if you receive transport=tls, but the first bullet is about 
> sending it. In that paragraph you say its 'recommneded' not 
> to be used in RR, Route or Path, and then next sentence is 
> MUST NOT. So which is it?

The first statement is about transport parameter in general
(i.e., transport=tcp, transport=udp), and the second one
is about TLS specifically (transport=tls). 

> If this is normative do we need to carry forward text on 
> transport=tls beyond saying don't send and ignore on receive?

Only the clarification above.

I can certainly clarify the text.

---

From: "Francois Audet" <[email-masked]>
Date: Wed, 21 Mar 2007 04:51:26 -0500

So, the open issue here "should we get rid of the ad-hoc
algorithm" for detecting if SIPS has been used end-to-end.

The reason it's there is that it is already in RFC 3261. What's
in here is clarifications on it.

I don't particularly like it, as it's not terribly useful. I'd
favor removing it and leaving the idea of "proving" SIPS was
used on every hop to future work.

> From: Dean Willis [mailto:[email-masked]] 
> Sent: Wednesday, March 21, 2007 02:07
> To: Jonathan Rosenberg
> Cc: IETF SIP List
> Subject: Re: [Sip] some comments on draft-ietf-sip-sips
> 
> 
> make this 
> > draft normative and finally go about 'fixing' the things that make 
> > SIPS broken. Besides the last hop exception problem, there 
> is another 
> > bit which is very problematic:
> >
> > rule, and it really ruins the ability for the UAS to verify 
> the main 
> > security property provided by SIPS. Instead of the ad-hoc 
> algorithms 
> > suggested as ways to actually verify this, can we change this rule? 
> > Proxy MUST NOT retarget a sips URI to sip. I think I've 
> suggested tihs 
> > in the past that I think we need to outright forbid up and 
> downgrades.
> 
> There is NO WAY for the UAS to verify the main security 
> property provided by SIPS, since any two upstream nodes could 
> collude and violate the security principle of SIPS even with 
> your proposed rule change in place.
> 
> We either stop thinking that use of SIPS tells us ANYTHING 
> about security -- It's just a request that may or may not 
> have been honored, OR we fix SIPS so that it has the 
> verification property you're asking for. And fixing it 
> requires substantially changing the way it works, which is 
> probably outside the scope of this document.
> 
> 
> --
> Dean
> 
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Peterson, Jon" <[email-masked]>
Date: Wed, 21 Mar 2007 06:21:07 -0400

Further on in RFC3261 26.4.4 after the text being cited about upgrading from SIP to SIPS, there is the following:

   To address these concerns, it is RECOMMENDED that recipients of a
   request whose Request-URI contains a SIP or SIPS URI inspect the To
   header field value to see if it contains a SIPS URI (though note that
   it does not constitute a breach of security if this URI has the same
   scheme but is not equivalent to the URI in the To header field).

On those grounds, I would argue that the absence of SIPS in the Request-URI of a request where the To header field uses the SIPS URI scheme is indeed informative. The UAS in this context can see that the UAC's request for hop-by-hop TLS has not been honored. So, I can't agree that we need to stop thinking that the use of SIPS tells us anything. While forms of collusion among intermediaries certainly might conceal hijinx from the UAS, this doesn't mean that some cases are not caught by this check.

Jon Peterson
NeuStar, Inc.

> From: Juha Heinanen [mailto:[email-masked]]
> Sent: Wednesday, March 21, 2007 2:18 AM
> To: Dean Willis
> Cc: IETF SIP List

---

From: Michael Thomas <[email-masked]>
Date: Wed, 21 Mar 2007 09:33:14 -0700

> On those grounds, I would argue that the absence of SIPS in the Request-URI of a request where the To header field uses the SIPS URI scheme is indeed informative. The UAS in this context can see th…

So let me get this straight: I'm just a dumb old proxy programmer and I
managed to figure out that somebody was misspelling SIP in the To:
headers so I fix it for them and viola, everything works. Am I a
colluding hijinxster or just a regular joe-lunchbox with a job to get
done?

       Mike

---

From: Dean Willis <[email-masked]>
Date: Wed, 21 Mar 2007 18:43:06 +0100

On Mar 21, 2007, at 11:21 AM, Peterson, Jon wrote:

>
>
> Further on in RFC3261 26.4.4 after the text being cited about  
> upgrading from SIP to SIPS, there is the following:
>
> On those grounds, I would argue that the absence of SIPS in the  
> Request-URI of a request where the To header field uses the SIPS  
> URI scheme is indeed informative. The UAS in this context can see  
> that the UAC's request for hop-by-hop TLS has not been honored. So,  
> I can't agree that we need to stop thinking that the use of SIPS  
> tells us anything. While forms of collusion among intermediaries  
> certainly might conceal hijinx from the UAS, this doesn't mean that  
> some cases are not caught by this check.
>

It would seem to me that one of the "evil proxies" here could easily  
change the URI in the To: to sip: and keep this heuristic from  
working. True, it has to patch it both directions, but unless we're  
running RFC 4474 or something similar, nobody will know.

Once again, SIPS tells us only that we asked the proxies to use  
comply, and that we can value the efficacy of this request only to  
the extent that we trust every one of those proxies.

The above heuristic might be useful for catching simple configuration  
errors.

--
Dean

---

From: Robert Sparks <[email-masked]>
Date: Thu, 29 Mar 2007 09:14:14 -0500

I also think disallowing upgrades is the better course.

I still have misgivings about how likely an implementation is to do  
the "right thing" WRT informing its user
when it receives an INVITE over TLS with a sips: RURI, but a sip: URI  
in the To: header. If it makes the mistake
of presenting this as a "secure" invitation, the UAS's user may make  
a very wrong choice in answering the call
(and possibly compound the error later with REFERs in that dialog).

If we do allow an upgrade retarget, we are sanctioning a downgrade in  
the reverse direction for subsequent requests
in the dialog that gets established. Thus the only "right thing" for  
the above implementation to do is to present this call
as a normal sip: call.

So the only benefit of allowing an upgrade I see is that some part of  
the signaling happens over TLS. But that can be
achieved by preferring hop-by-hop TLS anyhow. In a flow through the  
networks we anticipate, retargetting anywhere
but the (near) last hop will occur because of configuration, usually  
under the control of the operator of the retargetting element.
That same level of configuration effort can go into properly  
populating DNS to cause TLS to be used. The retargetting due
to registrations at the (near) last hop is likely to be mooted by  
outbound.

It appears to greatly simplify things if this kind of upgrade can't  
happen and we rely on redirection all the way to the endpoint.

RjS

On Mar 20, 2007, at 7:52 PM, Jonathan Rosenberg wrote:

> eliminate these two exceptions. I think the doc is still pretty  
> complicated since there are so many exceptions and variations. I  
> want it to be, you ar eeither sips, in which case EVERYTHING is  
> sips, or you are sip, in which case NOTHING is sips. Really easy  
> that way, and it gives us the security property we need.
>
> doesn't matter whether you use sip or sips. Then the next says why  
> you pick a sip or sips aor.
>
> Also I tihnk the text should be restructured a bit to say that, a  
> UA can operate in one of three modes - sips only, sip only or  
> either. And then based on that, how do you set each of the  
> parameters in the REGISTER (To, from, contact, r-uri). The current  
> text is inverted and you have to work backwards in some places to  
> sort it out.
>
> contact can be accepted as long as the r-uri was sips. For path,  
> its really a double check since they should have been sips based on  
> other rules, should probably make that clear.
>
>>   SIPS in a Dialog
> This is a basic 3261 requirement having nothing to do with sips;  
> might want to merely state this as fact.
>
> There are three statemenets in the or condition. However, if the  
> first is true, and we eliminate the last hop exception and retarget  
> exception, unless there is a protocol error the others will be true  
> too. This is one of many places where sips is just way simpler if  
> we do that.
>
> the first paragraph says that what follows will be what to do if  
> you receive transport=tls, but the first bullet is about sending  
> it. In that paragraph you say its 'recommneded' not to be used in  
> RR, Route or Path, and then next sentence is MUST NOT. So which is it?
>

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 29 Mar 2007 12:04:01 -0500

Thanks Robert.

Exactly my toughts as well. I think it would mean that the draft should
include some language about prefereing TLS transport anyhow (it was my
intention to add that in). 

> From: Robert Sparks [mailto:[email-masked]] 
> Sent: Thursday, March 29, 2007 07:14
> To: Jonathan Rosenberg
> Cc: IETF SIP List
> I still have misgivings about how likely an implementation is 
> to do the "right thing" WRT informing its user when it 
> receives an INVITE over TLS with a sips: RURI, but a sip: URI 
> in the To: header. If it makes the mistake of presenting this 
> as a "secure" invitation, the UAS's user may make a very 
> wrong choice in answering the call (and possibly compound the 
> error later with REFERs in that dialog).
> 
> If we do allow an upgrade retarget, we are sanctioning a 
> downgrade in the reverse direction for subsequent requests in 
> the dialog that gets established. Thus the only "right thing" 
> for the above implementation to do is to present this call as 
> a normal sip: call.
> 
> So the only benefit of allowing an upgrade I see is that some 
> part of the signaling happens over TLS. But that can be 
> achieved by preferring hop-by-hop TLS anyhow. In a flow 
> through the networks we anticipate, retargetting anywhere but 
> the (near) last hop will occur because of configuration, 
> usually under the control of the operator of the retargetting element.
> to registrations at the (near) last hop is likely to be 
> mooted by outbound.
> 
> It appears to greatly simplify things if this kind of upgrade 
> can't happen and we rely on redirection all the From [email-masked] Thu Mar 29 13:07:36 2007
Content-class: urn:content-classes:message
Subject: RE: [Sip] some comments on draft-ietf-sip-sips
Date: Thu, 29 Mar 2007 12:04:01 -0500
From: "Francois Audet" <[email-masked]>
To: "Robert Sparks" <[email-masked]>,
	"Jonathan Rosenberg" <[email-masked]>
Cc: IETF SIP List <[email-masked]>

Thanks Robert.

Exactly my toughts as well. I think it would mean that the draft should
include some language about prefereing TLS transport anyhow (it was my
intention to add that in). 

> From: Robert Sparks [mailto:[email-masked]] 
> Sent: Thursday, March 29, 2007 07:14
> To: Jonathan Rosenberg
> Cc: IETF SIP List
> I still have misgivings about how likely an implementation is 
> to do the "right thing" WRT informing its user when it 
> receives an INVITE over TLS with a sips: RURI, but a sip: URI 
> in the To: header. If it makes the mistake of presenting this 
> as a "secure" invitation, the UAS's user may make a very 
> wrong choice in answering the call (and possibly compound the 
> error later with REFERs in that dialog).
> 
> If we do allow an upgrade retarget, we are sanctioning a 
> downgrade in the reverse direction for subsequent requests in 
> the dialog that gets established. Thus the only "right thing" 
> for the above implementation to do is to present this call as 
> a normal sip: call.
> 
> So the only benefit of allowing an upgrade I see is that some 
> part of the signaling happens over TLS. But that can be 
> achieved by preferring hop-by-hop TLS anyhow. In a flow 
> through the networks we anticipate, retargetting anywhere but 
> the (near) last hop will occur because of configuration, 
> usually under the control of the operator of the retargetting element.
> to registrations at the (near) last hop is likely to be 
> mooted by outbound.
> 
> It appears to greatly simplify things if this kind of upgrade 
> can't happen and we rely on redirection all the way to the endpoint.
> 
> RjS
> 
> eliminate 
> > these two exceptions. I think the doc is still pretty complicated 
> > since there are so many exceptions and variations. I want it to be, 
> > you ar eeither sips, in which case EVERYTHING is sips, or 
> you are sip, 
> > in which case NOTHING is sips. Really easy that way, and it 
> gives us 
> > the security property we need.
> >
> >>    perspective, it does not matter which one is used for 
> registration 
> >> as
> >>    SIPS (e.g., mailto, tel, http, https), a SIP AOR MUST 
> also be used 
> >> by
> >>    the UAC.
> >
> that, a UA 
> > can operate in one of three modes - sips only, sip only or 
> either. And 
> > then based on that, how do you set each of the parameters in the 
> > REGISTER (To, from, contact, r-uri). The current text is 
> inverted and 
> > you have to work backwards in some places to sort it out.
> >
> > I don't really see why the AOR in the To is relevant at all 
> (sip vs. 
> > sips).
> >
> >>    AOR (i.e., To header), the From header, the Contacts 
> and all the 
> >> Path
> >>    field MUST contain a SIPS URI as weway to the endpoint.
> 
> RjS
> 
> eliminate 
> > these two exceptions. I think the doc is still pretty complicated 
> > since there are so many exceptions and variations. I want it to be, 
> > you ar eeither sips, in which case EVERYTHING is sips, or 
> you are sip, 
> > in which case NOTHING is sips. Really easy that way, and it 
> gives us 
> > the security property we need.
> >
> >>    perspective, it does not matter which one is used for 
> registration 
> >> as
> >>    SIPS (e.g., mailto, tel, http, https), a SIP AOR MUST 
> also be used 
> >> by
> >>    the UAC.
> >
> that, a UA 
> > can operate in one of three modes - sips only, sip only or 
> either. And 
> > then based on that, how do you set each of the parameters in the 
> > REGISTER (To, from, contact, r-uri). The current text is 
> inverted and 
> > you have to work backwards in some places to sort it out.
> >
> > I don't really see why the AOR in the To is relevant at all 
> (sip vs. 
> > sips).
> >
> >>    AOR (i.e., To header), the From header, the Contacts 
> and all the 
> >> Path
> >>    field MUST contain a SIPS URI as well.  Furthermore, as 
> mandated 
> >> by
> >>    value, if there was any, or the Contact header field if 
> there was 
> >> no
> >>    Record-Route header f
> >
> > is true, and we eliminate the last hop exception and retarget 
> > too. This is one of many places where sips is just way 
> simpler if we 
> > do that.
> >
> >>    not used for this hop).  If the Contact was a SIPS URI, 
> it would 
> >> mean
> >>    RECOMMENDED that in this case, the Contact be a SIP 
> URI, even if 
> >> the
> >>    request is sent over a secure transport (e.g., the 
> first hop could 
> >> be
> >>    o  [RFC3261]/16.7 states the transport parameter (e.g., 
> with tcp 
> >> or
> >>       Route are not used, and if that URI is nevertheless 
> reachable 
> >> with
> > receive transport=tls, but the first bullet is about sending it. In 
> > that paragraph you say its 'recommneded' not to be used in 
> RR, Route 
> > or Path, and then next sentence is MUST NOT. So which is it?
> >
> transport=tls 
> > Cisco Fellow                                   ll.  Furthermore, as 
> mandated 
> >> by
> >>    value, if there was any, or the Contact header field if 
> there was 
> >> no
> >>    Record-Route header f
> >
> > is true, and we eliminate the last hop exception and retarget 
> > too. This is one of many places where sips is just way 
> simpler if we 
> > do that.
> >
> >>    not used for this hop).  If the Contact was a SIPS URI, 
> it would 
> >> mean
> >>    RECOMMENDED that in this case, the Contact be a SIP 
> URI, even if 
> >> the
> >>    request is sent over a secure transport (e.g., the 
> first hop could 
> >> be
> >>    o  [RFC3261]/16.7 states the transport parameter (e.g., 
> with tcp 
> >> or
> >>       Route are not used, and if that URI is nevertheless 
> reachable 
> >> with
> > receive transport=tls, but the first bullet is about sending it. In 
> > that paragraph you say its 'recommneded' not to be used in 
> RR, Route 
> > or Path, and then next sentence is MUST NOT. So which is it?
> >
> transport=tls 
> > [email-masked] for questions on current sip Use 
> > [email-masked] for new developments on the application of sip
> 
>