Subject: [Sip] notes on draft-ietf-sip-sips-02

From: Dean Willis <[email-masked]>
Date: Fri, 16 Mar 2007 09:45:18 -0500

I did a full read through, not counting the examples that I never get  
right anyhow.

general note: Keith tells me the standard is to write '200 (OK)  
response' instead of '200 "Ok" response'.

Specific points of consideration:

abstract:
> "This document providing clarifications"

The above doesn't parse. Maybe "This document clarifies" or "attempts  
to clarify", depending on what you believe about declaring victory.

Section 3 paragraph 3 says:

> "Contrary to what many believe erroneously, the last-hop exception  
> was not created to allow for using a SIPS URI to address a UAS that  
> does not support TLS : the last-hop exception was an attempt to  
> allow for incoming requests TLS when a SIPS URI is used, and it  
> does not apply to outgoing requests.

Given that the last-hop-exception was to a great extent my fault, I  
have to say that the specific use case I argued for was so that I  
could advertise a SIPS: URI that would be terminated on a record- 
routing proxy at my desk and translate to a SIP: URI that would end  
up on an experimental 3Com SIP phone that did not support SIPS:. I  
might have been wrong, but that's what I wanted to do. And given the  
fundamental design flaw of SIPS: (you can't tell when somebody's  
cheating), it works just fine if the proxy is smart enough to  
"upgrade" outbound requests.

Next paragraph says:

> It is therefore RECOMMENDED that implementations do not use the  
> last hop exception rule and use TLS all the way up to the remote  
> target."

Since we've already said that outbound provides a superior solution,  
why don't we just say something like "Note: outbound [xxxx] provides  
a solution that works better than the last hop exception. Use it when  
possible."

Next para includes:

> "The SIPS scheme implies transitive trust.  Obviously, there is  
> nothing that prevents a proxy to cheat"

Classic SIP error. We have our To: and From: reversed. Perhaps "from  
cheating" instead of "to cheat".

First para of section 3.1.  Scope of SIPS says:

> "SIPS means that the SIP resource designated by the target SIPS URI  
> be contacted securily, using TLS, on each SIP hop (last-hop  
> exception nothwistanding)."

This doesn't quite pass my in-head English parser. Perhaps:

SIPS means that the SIP resource designated by the target SIPS URI is  
to be contacted securely, using TLS on each hop between the UAC and  
the proxy responsible for the request URI, and using TLS between the  
proxy responsible for the request URI and the UAS if possible.

Just before Section 4, we have '

> "Some proxies may have local policies that enforces TLS on all"

There's a pluralization mismatch in there. Perhaps "local policy that  
enforces" or "local policies that enforce".

The last para in "Section 4: Routing" before 4.1 says"

   " o  Reject the call with a 403 "Forbidden"."

I'm not sure I believe that. It seems much more like a 404 case.  
Since there's no sips: URI available, the contact was not found. If  
we use 403, then we need to give a reason phrase that might help the  
caller figure out what went wrong.

Section 5 Registration, Para  2 says:

> "The USC registers either a SIPS or a SIP AOR"

We probably mean UAC instead of USC in the preceding. On the other  
hand, you can never tell about those guys at the University of  
Southern California. Maybe they speak SIP now.

The following 3rd paragraph says:

> "Those are mechanical rules with no influence on routing."

The "Those" should perhaps be "These".

The 6th or so paragraph of section 5 says:

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

The MUST here needs some backing. Where does the authority for it  
come from?  The same caveat applies to the last statement of Section 5:

> "However, a registrar MUST record the scheme of the Contact."

Why? Is that in an RFC somewhere  explicitly or implicitly? What  
happens if it doesn't?

A similar question applies to the first para in "Section 6; 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)."

Section 6 Para 3 says:

> "If a UAS (or proxy acting on behalf of a UAS) does not support  
> SIPS, it MUST reject a request to a SIPS Request-URI with response  
> code 416 "Unsupported URI scheme".  Upon receiving a 416 a UAC  
> SHOULD NOT re-attempt the request by automatically replacing the  
> SIPS scheme with a SIP scheme.  If the UAC does re-attempt the call  
> with a SIP URI, it SHOULD inform to the user that the security  
> level is downgraded."

The first MUST of the above is, I believe, a restatement of some part  
of 3261, which could be called out as the source of authority. The  
rationale for the SHOULD might need support. I seem to recall  
discussing this or something like it on-list.

Section 7, first para, says:

> "Sessions, dialogs and transactions may be "derived" from existings  
> ones."

The "existings" might be better as "existing".

The "Must be rejected" in para 3 of section 7 requires some support.

Keith would suggest indenting the Note: paragraph (4) of section 8.

The following discussion of RFC326`/16.7:

> "will be in the path of subsequent supports this transport"

is probably missing the word "requests" between "subsequent" and  
"support".

Section 9, discussion of GRUU, p 2 says:

> "If the wrong scheme is received in the GRUU (which would be an  
> error in the registrar), the UAC MUST treat it as if the proper  
> scheme was used (i.e., it MUST replace the scheme with the proper  
> scheme before using the GRUU)."

I'm not currently sure this is supportable in this document. I don't  
suppose we could move this text into GRUU? Jonathan?

In 11. Conclusion, para 3, the 2nd sentence probably needs a cap:

> "... how SIPS may be used. "server-side authentication" (where the  
> server"

The following "it's" should probably be the possessive, "its".

_______________________________________________
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: Fri, 16 Mar 2007 10:08:49 -0500

OK. I'll integrate all of those comments. 

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]] 
> Sent: Friday, March 16, 2007 07:45
> To: Audet, Francois (SC100:3055)
> Cc: SIP IETF
> Subject: notes on draft-ietf-sip-sips-02
> 
> I did a full read through, not counting the examples that I 
> never get right anyhow.
> 
> 
> general note: Keith tells me the standard is to write '200 
> (OK) response' instead of '200 "Ok" response'.
> 
> The above doesn't parse. Maybe "This document clarifies" or 
> "attempts to clarify", depending on what you believe about 
> declaring victory.
> 
> 
> 
> > "Contrary to what many believe erroneously, the last-hop 
> exception was 
> > not created to allow for using a SIPS URI to address a UAS 
> that does 
> > not support TLS : the last-hop exception was an attempt to 
> allow for 
> > incoming requests TLS when a SIPS URI is used, and it does 
> not apply 
> > to outgoing requests.
> 
> Given that the last-hop-exception was to a great extent my 
> fault, I have to say that the specific use case I argued for 
> was so that I could advertise a SIPS: URI that would be 
> terminated on a record- routing proxy at my desk and 
> translate to a SIP: URI that would end up on an experimental 
> 3Com SIP phone that did not support SIPS:. I might have been 
> wrong, but that's what I wanted to do. And given the 
> fundamental design flaw of SIPS: (you can't tell when 
> somebody's cheating), it works just fine if the proxy is 
> smart enough to "upgrade" outbound requests.
> 
> Next paragraph says:
> 
> > It is therefore RECOMMENDED that implementations do not use 
> the last 
> > hop exception rule and use TLS all the way up to the remote target."
> 
> Since we've already said that outbound provides a superior 
> solution, why don't we just say something like "Note: 
> outbound [xxxx] provides a solution that works better than 
> the last hop exception. Use it when possible."
> 
> 
> Next para includes:
> 
> Classic SIP error. We have our To: and From: reversed. 
> Perhaps "from cheating" instead of "to cheat".
> 
> 
> > "SIPS means that the SIP resource designated by the target 
> SIPS URI be 
> > contacted securily, using TLS, on each SIP hop (last-hop exception 
> > nothwistanding)."
> 
> 
> SIPS means that the SIP resource designated by the target 
> SIPS URI is to be contacted securely, using TLS on each hop 
> between the UAC and the proxy responsible for the request 
> URI, and using TLS between the proxy responsible for the 
> request URI and the UAS if possible.
> 
> 
> There's a pluralization mismatch in there. Perhaps "local 
> policy that enforces" or "local policies that enforce".
> 
> 
> Since there's no sips: URI available, the contact was not 
> found. If we use 403, then we need to give a reason phrase 
> that might help the caller figure out what went wrong.
> 
> We probably mean UAC instead of USC in the preceding. On the 
> other hand, you can never tell about those guys at the 
> University of Southern California. Maybe they speak SIP now.
> 
> > "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"."
> 
> 
> The MUST here needs some backing. Where does the authority 
> for it come from?  The same caveat applies to the last 
> statement of Section 5:
> 
> Why? Is that in an RFC somewhere  explicitly or implicitly? 
> What happens if it doesn't?
> 
>

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 16 Mar 2007 12:44:42 -0500

Ok, I have done all these changes (plus a whole bunch of editorial
ones). I am keeping 
a "draft" draft-ietf-sip-sips-03 at the following location:
https://svn.resiprocate.org/rep/ietf-drafts/audet/draft-ietf-sip-sips-03
.txt

On the GRUU comment however: Jonathan has expressed his preference for
having
the SIPS-related discussion be included in the sips draft as opposed to
the
GRUU draft. That's why it's here.

---

From: Dean Willis <[email-masked]>
Date: Sat, 17 Mar 2007 19:41:12 -0500

can you find text in any std doc that supports the MUST relative to  
GRUU?

--
Dean

---

From: "Drage, Keith \(Keith\)" <[email-masked]>
Date: Sun, 18 Mar 2007 02:02:05 +0100

I think we need to go through all these RFC 2119 entries with a fine
toothcomb.

On the plane I came up with at least the following:

-	RFC 2119 language in quotes from RFC 3261. Probably need to put
quites round all these extracts to make them clear.

-	RFC 2119 language used as RFC 3261 says MUST A and MUST B
therefore we link these together to mean MUST C in our document

-	RFC 2119 language of BCP strength

-	RFC 2119 language that in view actually updates RFC 3261.

I have a number of other comments to put but I'm going to bed now.

Keith

> Sent: Sunday, March 18, 2007 12:41 AM
> To: Francois Audet
> Cc: SIP IETF
> Subject: [Sip] Re: notes on draft-ietf-sip-sips-02
> 
> 
> can you find text in any std doc that supports the MUST 
> relative to GRUU?
> 
> --
> Dean
> 
> > ones). I am keeping a "draft" draft-ietf-sip-sips-03 at the 
> following 
> > location:
> > having the SIPS-related discussion be included in the sips draft as 
> > opposed to the GRUU draft. That's why it's here.
> >
> fault, I 
> solution, 
> >> why don't we just say something like "Note:
> >> hop exception. Use it when possible."
> >>
> >>
> >> Next para includes:
> >>
> SIPS URI is 
> policy that 
> found. If 
> >> come from?  The same caveat applies to the last statement 
> of Section 
> >> 5:
> >>
> >>> with a SIP URI, it SHOULD inform to the user that the 
> security level 
> >>> is downgraded."
> >>
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip

---

From: "Francois Audet" <[email-masked]>
Date: Sun, 18 Mar 2007 06:54:30 -0500

No, I can't.

> Sent: Saturday, March 17, 2007 17:41
> Subject: Re: notes on draft-ietf-sip-sips-02
> 
>

---

From: Dean Willis <[email-masked]>
Date: Sun, 18 Mar 2007 19:19:08 -0500

Then to say this, I think we're going to need to make sips a  
standards-track document.

--
Dean

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 19 Mar 2007 03:08:28 -0500

Yes, that is also what I think. 

If I 'had' to write a reason, I'd say that the reason it is a MUST is
that since
it means that the Registrar screwed up and returned the wrong scheme,
and there
really nothing the phone can do besides 'rebooting', then treating the
scheme as if
it was the proper scheme is the best solution. It will not cause all the
phones
to reboot, or re-register or whatever bad solution would be available.
It causes
no harm, and does not introcude instability in the system. 

> Sent: Sunday, March 18, 2007 17:19
> relative to

---

From: Jonathan Rosenberg <[email-masked]>
Date: Mon, 19 Mar 2007 04:14:03 -0400

I think it should have been standards track to begin with. I don't 
understand why we were going for this 'informational clarification on 
what RFC 3261 said' when we knew what it said is wrong....

-Jonathan R.

Dean Willis wrote:

>>>> On the GRUU comment however: Jonathan has expressed his
>>>
>>> preference for
>>>
>>>>> I did a full read through, not counting the examples that
>>>
>>> I never get
>>>
>>>>> right anyhow.
>>>>>
>>>>>
>>>>> The above doesn't parse. Maybe "This document clarifies"
>>>
>>> or "attempts
>>>
>>>>> routing proxy at my desk and translate to a SIP: URI that
>>>
>>> would end
>>>
>>>>> might have been wrong, but that's what I wanted to do. And
>>>
>>> given the
>>>
>>>>>> hop exception rule and use TLS all the way up to the
>>>
>>> remote target."
>>>
>>>>>
>>>>>> contacted securily, using TLS, on each SIP hop (last-hop
>>>
>>> exception
>>>
>>>>>> nothwistanding)."
>>>>>
>>>>>
>>>>>
>>>>> to be contacted securely, using TLS on each hop between
>>>
>>> the UAC and
>>>
>>>>> the proxy responsible for the request URI, and using TLS
>>>
>>> between the
>>>
>>>>> we use 403, then we need to give a reason phrase that
>>>
>>> might help the
>>>
>>>>>> appropriate URIs are of the SIPS scheme: i.e., the
>>>
>>> Request-URI, the
>>>
>>>>> A similar question applies to the first para in "Section
>>>
>>> 6; SIPS in a
>>>
>>>>> Dialog":
>>>>>
>>>>>> SIPS, it MUST reject a request to a SIPS Request-URI with
>>>
>>> response
>>>
>>>>>> SIPS scheme with a SIP scheme.  If the UAC does re-attempt
>>>>>
>>>>> the call
>>>>>
>>>>> The first MUST of the above is, I believe, a restatement
>>>
>>> of some part
>>>
>>>>>> "Sessions, dialogs and transactions may be "derived" from
>>>>>
>>>>> existings
>>>>>
>>>>>> ones."
>>>>>
>>>>>
>>>>> The "Must be rejected" in para 3 of section 7 requires
>>>
>>> some support.
>>>
>>>>>
>>>>>
>>>>> I'm not currently sure this is supportable in this
>>>
>>> document. I don't
>>>
>>>>>> "... how SIPS may be used. "server-side authentication"
>>>
>>> (where the
>>>
>>>>>> server"
>>>>>
>>>>>

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