Subject: [Sip] Review of draft-ietf-sip-gruu-09

From: Paul Kyzivat <[email-masked]>
Date: Thu, 27 Jul 2006 17:19:47 -0400

I did a reasonably careful review of draft-ietf-sip-gruu-09. I was 
mostly looking for remaining technical issues rather than formatting 
nits. For awhile now I have mostly be looking at diffs as new versions 
come out and reading selected sections at need. It was good to read the 
whole thing again to see how it all hangs together.

I found nothing really major, but some stuff that is more than 
editorial. Some of it is a judgment call about whether something is 
clear or not. I won't feel bad to have a number of these comments rejected.

	Paul

General comment:

SIPS is mentioned in many places in this draft. Given the current 
ongoing issues wrt SIPS, the language here for dealing with it may prove 
to be prescient, or may turn out to just be wrong. Can this be dodged 
somehow? Maybe this whole draft should only be defined for SIP, with 
SIPS left for a separate draft. (I will still comment on some places 
containing SIPS, when there are other points than the above.)

Section 5:

    ...  The "opaque" parameter is added by the owner
    of the domain to correlate the GRUU to its instance ID, and to easily
    recognize that the URI has the GRUU property.

I think this isn't quite right. The "gruu" parameter may be used to 
recognize the GRUU property. How about:

    ...  The "opaque" parameter is added by the owner
    of the domain to correlate the GRUU to its instance ID, and
    potentially to help verify that the GRUU has not been forged.

Figure 1:

Its unfortunate that pictures such as this lead to many questions, often 
irrelevant ones. I know we have discussed nuances of this one before.

- as shown, a contact is bound to 1 AOR, at most one Instance ID and at 
most one GRUU. In practice is is possible to bind the same contact to 
multiple AORs if one doesn't need to distinguish between them or has 
some other means to do so. (And section 7.1.1.1 allows it, since 
restriction to a single AOR is only RECOMMENDED.)  It is also possible 
that the same contact will be associated with more than one Instance ID. 
(Ideally there is only one such association at any one time, but over 
time it may change.}

- the figure doesn't show what is in the text:

    A GRUU is associated, in a many-to-one fashion, with the combination
    of an instance ID and an AOR.  This combination is referred to as an
    instance ID/AOR pair.  For each GRUU, there is one instance ID/AOR
    pair, and for each instance ID/AOR pair, there can be one or more
    GRUU.

(The picture doesn't show anything associated with an AOR/Instance ID pair.)

I think it is too hard to make a picture that expresses these 
relationships accurately, and this should be done with text, without the 
figure.

Section 6:

    o  For each GRUU, both the SIP and Session Initiation Protocol Secure
       (SIPS) versions MUST exist.  The SIPS URI may not always work,
       particularly if the proxy cannot establish a secure connection to
       the client.  However, the SIPS URI always exists.

The use of "always" seems problematic. The lifetime of the gruu itself 
is not "always". It is no longer than the associated AOR. Also, this 
goes into the previous discussion of relationships. Are the SIP and SIPS 
forms *separate* AORs, or the same AOR? I'm struggling here to come up 
with something that threads the needle. How about:

    o  When both SIP and SIPS AORs identify the same resource, and the
       AORs differ only in the scheme name, then when a GRUU is assigned
       to the resource, both SIP and SIPS GRUUs will be assigned. Only
       one will be returned, but both will exist.  The SIPS URI may not
       always work, particularly if the proxy cannot establish a secure
       connection to the client.

Section 7.1.1.1:

    Specifically, the contact in the REGISTER request SHOULD
    NOT contain the gruu Contact header field parameter, and the contact
    URI itself SHOULD NOT contain the "grid" URI parameter defined below.
    Any such parameters are ignored by the registrar, as the UA cannot
    propose a GRUU for usage with the contact.

Nit: the last sentence is a little weird, because the "as" clause only 
applies to gruu, not grid. Perhaps:

    Any such parameters are ignored by the registrar and not stored.
    (The UA cannot propose a GRUU for usage with the contact, and
    the grid parameter is populated from the GRUU, not the registered
    contact.)

BUT, later I instead suggest treating the presence of grid as an error 
rather than ignoring it. That requires different wording here.

Later in the section:

    ... However, it is
    permitted for a UA to register any kind of contact it wishes,
    including a GRUU.  A typical use case for registering a GRUU is if a
    user wanted calls to one AOR to be delivered to a specific UA
    instance associated with another AOR.

I just realized this presents a problem wrt grid processing. If the 
contact is a gruu associated with a different AOR, then it could also 
contain a grid parameter, and if so, that parameter might be important. 
One wouldn't want to lose it, or override it.

Perhaps it should be an *error* to register a contact that contains a 
grid URI parameter. That would prevent any confusion.

Section 7.1.1.2:

    ...  The URI will be a SIP URI if the To header
    field in the REGISTER request contained a SIP URI, else (if the To
    header field in the REGISTER request contained a SIPS URI) it will be
    a SIPS URI.

(more sips stuff)

    ... Normally, the GRUU will
    not change in subsequent 2xx responses to REGISTER.  Indeed, even if
    the UA lets the contact expire, when it re-registers it at any later
    time, the registrar will normally provide the same GRUU for the same
    address-of-record and instance ID.  However, as discussed above, this
    property cannot be completely guaranteed, as network failures may
    make it impossible to provide an identifier that persists for all
    time.  As a result, a UA MUST be prepared to receive a different GRUU
    for the same instance ID/AOR pair in a subsequent registration
    response.

As written, this puts a burden on a UA. Any time it refreshes a 
registration a previously assigned gruu may change. That gruu may be in 
use in a dialog. Then the UA would have to to a target refresh to fix 
it. That is a lot to ask, and has potential race conditions if the prior 
gruu has become invalid.

IMO it would be better to put the burden on the registrar to keep the 
gruu the same for as long as a registration remains active.

I think it might also be good to insert a note into this section:

     NOTE: the 2xx response to REGISTER returns all the contacts
     bound to the AOR. This may include contacts bound by other
     UAs. Any or all of these may include a "gruu" Contact header field
     parameter. The UA is responsible for extracting and saving the
     GRUU assigned to the contact(s) it has registered.

Section 7.1.2:

    A registrar MUST create both the SIP and SIPS versions of the GRUU,
    such that if the GRUU exists, both URI exist.

(more sips stuff)

Section 7.1.2.1:

Nothing is mentioned in this section about handling of a "grid" URI 
parameter in the contact. If this is present it can screw things up in a 
variety of ways. This is sufficiently severe that it probably isn't wise 
to just ignore it if present. Instead, should probably reject the 
request. (403 again?) The problems that can result:

- regular calls to the AOR will look (to the UE) like calls to a gruu
- if the contact was itself a GRUU, and had a particular grid value
   for some purpose, then when calls are made to the gruu assigned as
   part of this registration, the grid value will be messed up.

(Note that forbidding grid values here doesn't fully solve the problem. 
Using a gruu as a contact in another registration has unresolvable 
problems about the namespace for grid values. It can only work right if 
the two share a common namespace for the values.)

Same section:

    ... If the To
    header field in the REGISTER request contains a SIP URI, the SIP
    version of the GRUU is returned.  If the To header field in the
    REGISTER request contains a SIPS URI, the SIPS version of the GRUU is
    returned.

(more sips stuff)

Section 8.1.1:

    When using a GRUU as a remote target, a UA MAY add the "grid" URI

Maybe its just me, but here and elsewhere I am confused by use of the 
term "remote target". In a dialog, I think of the "remote target" as the 
R-URI I use to reference the *other* end of the dialog. I would then 
expect the term "local target" to refer to the URI I expect the other 
end to use in the R-URI of requests addressed to me. But I think you are 
using it differently.

In the above, I am left wondering if others who receive my GRUU will be 
filling in the grid parameter. Of course this is wrong, but I can read 
it that way.

If you agree this is an issue, I guess it will require a careful 
laundering of all the places that use the term "remote target".

Section 8.2.1:

First, I think it would be worthwhile to add a statement at the 
beginning of this section stating that this only applies when there are 
no Route headers. Maybe this is obvious, but maybe not. Stating this 
removes any ambiguity about how a Path header interacts with existing 
Route headers.

The first paragraph could be interpreted as an *alternative* to the 
cases mentioned in the 2nd and 3rd paragraphs. I believe it is not 
intended that way, and is instead just a modifier that applies 
regardless of which of the other cases are followed. I'm not sure that 
this paragraph even needs to be here. It places a dependency from this 
draft on -outbound behavior over and above the definition of instance 
id. The third paragraph already has language that covers the interaction 
case when both drafts are mucking with the same behavior.

Later in the section

    ... If the grid was already present
    in the contact bound to the GRUU, it is overwritten in this process.

As I noted earlier, this seems dangerous to me, so I think it should be 
prevented earlier.

Section 8.2.2:

    The proxy that accesses the location service (called the home proxy
    here) MUST record-route under two circumstances.  Firstly, if the
    home proxy receives a dialog forming request from a UA in its own
    domain (an originating request) whose Contact header field contains a
    GRUU (indicated by the presence of the "gruu" URI parameter), the
    proxy MUST record-route.

This really only applies if the proxy is responsible for the GRUU.

================

That's all!

_______________________________________________
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: Jonathan Rosenberg <[email-masked]>
Date: Mon, 31 Jul 2006 16:14:53 -0400

Thanks for the detailed review, Paul. Responses below.

> containing SIPS, when there are other points than the above.)

Well, it used to say nothing about sips and I think you complained it 
needed to a long time back ;)

I'm not awful inclined to hold the draft up for us to figure all of that 
out, and I'm also not inclined to say nothing. My preference is to 
address it as best we can based on the current mechanism, and the 
in-progress sips update will need to tackle gruu.

>    potentially to help verify that the GRUU has not been forged.

Dale flagged this one too.  I'll use your text.

> restriction to a single AOR is only RECOMMENDED.) 

Fair point. The cardinality in this direction isn't particularly useful. 
Rather than changing to 'n' and then needing to explain, I just removed 
the cardinality entirely. The main thing to show here is that there are 
0..n contacts bound to the AOR and GRUU.

> It is also possible 

One at a time is what is meant to be captured here. Changing this to 'n' 
I think will be very confusing.

> (The picture doesn't show anything associated with an AOR/Instance ID 

Right. In earlier versions of GRUU I used to have an object called 
instance ID/AOR pair. It cluttered the picture way too much and made it 
even harder to understand.

> relationships accurately, and this should be done with text, without the 

It is in the text. Are you suggesting removing the figure entirely?

>       connection to the client.

I think the first bit of this is not needed. It makes it sound like its 
OK for a SIP and SIPS AOR to not identify the same resource. I think 
we've concluded all along (and in the sipsec adhoc in Montreal) that 
they always do.

How about:

	    <t>When a GRUU is assigned to an instance ID/AOR pair,
	    both SIP and SIPS GRUUs will be assigned. Only one will be
	    returned, but both will exist.  The SIPS URI may not
	    always work, particularly if the proxy cannot establish a
	    secure connection to the client.
	    </t>

>    the grid parameter is populated from the GRUU, not the registered

I just removed the 'as' bit entirely.

> rather than ignoring it. That requires different wording here.

No, I think its OK. See below.

> One wouldn't want to lose it, or override it.

Right.

> grid URI parameter. That would prevent any confusion.

I think we need to prevent it. The current spec is wrong in this regard; 
it appears to allow it, but it would cause overriding which is wrong.

So, here is my proposal. I think there are two cases here. One, where 
the contact is a 'plain old contact' and is not bound to a gruu at all. 
In such a case, the contact would not contain the instance ID and can 
contain gruu and grid params if the contact happens to be a gruu. No 
gruu gets bound to this contact. If the contact is a specific instance, 
then it contains the instance ID, in which case it cannot contain a gruu 
or grid. With this change, btw, you can register a GRUU to its own AOR, 
and it works as expected. I changed the text to reflect this. It now reads:

			<t>Besides the procedures discussed above, the
		REGISTER request is constructed as it is in the case
		where this extension was not understood. Specifically,
		if a contact contains an instance ID parameter, then
		it SHOULD NOT contain the gruu Contact header field
		parameter, and the contact URI itself SHOULD NOT
		contain the "grid" or "gruu" URI parameters defined below. Any
		such parameters are ignored by the registrar and not
		stored.  Typically, the contact URI is not itself a
		GRUU and will not contain
		these URI parameters. There are use cases where a
		contact can contain a GRUU, however. A typical
		use case is when a user wanted calls to one AOR to be
		delivered to a specific UA instance associated with
		another AOR. If a client does include a contact which
		contains a GRUU, it MUST NOT contain the
		instance ID parameter. This will ensure that the
		contact URI does not get bound to any GRUU, avoiding
		an infinite loop which might otherwise occur.
		</t>

I made updates in a few other places too; most notably where it talks 
about overriding the grid in the contact. That can never happen with the 
change here.

>    header field in the REGISTER request contained a SIPS URI) it will be

Per above I propose to keep this.

> gruu the same for as long as a registration remains active.

Well, registrations can last almost indefinitely (at least until there 
is a power failure). Thus, I'm not sure this changes much practically 
speaking.

I also think that the principle of robustness favors keeping the current 
text. By having endpoints prepare for this, the system works in various 
degrees of server reliability.

Actually, this got me thinking. I was about to write, "note also that a 
dialog can exist without a registration, so that you could have a dialog 
in place when a registration expires". This may be true *prior* to GRUU, 
but with GRUU, it is actually false! Because you are using a gruu as the 
remote contact, mid-dialog requests require the home proxy to have a 
valid registration in order to handle the request. Thus, gruu 
effectively requires registrations for sending or receiving a dialog 
forming request. This is similar to the 3gpp constraint, which many 
folks from IETF fought long and hard against. Funny that, between this 
and sip-outbound, we've basically arrived at the same place anyway.

It is worth pointing that out. I've added the following text in the 
front of 8.1.1.:

	      <t>
		A UA first obtains a GRUU using the procedures of
		<xref target="sec-reg"/>, or by other means outside the scope of this
		specification. If a UA is using registrations to
		obtain GRUUs, it MUST have an active registration
		prior to using a GRUU. It cannot simply reuse a
		previously cached GRUU, even if the URI itself doesn't
		ever change. This is because mid-dialog requests, which
		will be targeted at a GRUU, cannot be processed
		correctly at the home proxy unless a registration is
		active.
	      </t>

>     GRUU assigned to the contact(s) it has registered.

Yes, something like this needs to be said. I rather it not be a 'NOTE' 
since that tends to confuse folks about whether it is informational or 
normative behavior. In fact, you are pointing out an important normative 
thing. So, I put some normative text up front:

		<t>The 2xx response to REGISTER returns all the
		contacts bound to the AOR. This may include contacts
		bound by other UAs. The UA MUST extract the contacts
		it has just registered, and perform the processing on
		those contacts as described here. </t>

		<t> If the response is a 2xx, each Contact header
		field that contained the "+sip.instance" Contact

> the two share a common namespace for the values.)

You are right that the spec doesn't say what should happen. Per my above 
suggestion, I've specifide now that if there is an instance ID, you 
ignore and don't store the gruu and grid param.

> end to use in the R-URI of requests addressed to me. But I think you are 

I'm using it as defined in the intro (and in rfc3261):

	<t hangText="remote target:">The term "remote target" refers
	to a URI that a user agent uses to identify itself for receipt
	of both mid-dialog and out-of-dialog requests. A remote target
	is established by placing a URI in the Contact header field of
	a dialog-forming request or response and updated by target
	refresh requests.  </t>

> laundering of all the places that use the term "remote target".

In this particular paragraph I see how it can be confusing. I reworded to:

	      <t> When using a GRUU as a remote target (that is,
	      when populating the Contact header field of an INVITE or
	      200 OK response), the UA placing the GRUU into the
	      request or response MAY add the "grid" URI
	      parameter to the GRUU, and if one is added, MUST include a value for
	      it. This parameter MAY take any value permitted by the grammar 
defined

> removes any ambiguity about how a Path header interacts with existing 

This ties back into the much bigger issue about what to do with 
pre-loaded route headers in dialog forming requests. For now I think it 
suffices to say that this section is in fact not addressing what happens 
if the request also contains route headers. But if it does, its hard to 
say what the right hting is. In some cases there may be legitimate 
reasons for it that are not attacks.

For now I will merely clarify as you suggest. The specific words I used 
were:

	      <t> The processing in this section applies to
	      requests that are received outside of a dialog. These
	      requests are identified by their lack of a Route header
	      field when received by the proxy. </t>

This doesn't say its wrong to receive a dialog-forming request without a 
route; it simply says that the rules here don't apply to that case.

> case when both drafts are mucking with the same behavior.

Agree that the first paragraph lends nothing. I deleted it.

> As I noted earlier, this seems dangerous to me, so I think it should be 

Yes, this was removed.

> This really only applies if the proxy is responsible for the GRUU.

The words already apply only in cases where the sending UA is in its own 
domain. So, the only case when this is true, but it wouldn't be 
responsible for the GRUU, is if the UA used a different GRUU. For 
example, I'm a customer of abc.com and I happen to get a gruu from 
xyz.com. I then send an INVITE with a contact of xyz.com. The rules in 
the UA processing section require that this request visit abc.com prior 
to being sent. Its still possible that xyz.com home proxy is on the path 
too. In such an odd case, I've clarified that the proxy checks the 
domain of the gruu too.

Thanks for your comments,
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

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 31 Jul 2006 17:44:37 -0500

I'm keeping my comments to sips-related issues. 

See below.

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]] 
> Sent: Monday, July 31, 2006 1:15 PM
> To: Paul Kyzivat
> Cc: SIP IETF
> Subject: [Sip] Re: Review of draft-ietf-sip-gruu-09
> 
> > ongoing issues wrt SIPS, the language here for dealing 
> with it may 
> > prove to be prescient, or may turn out to just be wrong. 
> Can this be 
> > dodged somehow? Maybe this whole draft should only be 
> defined for SIP, 
> > with SIPS left for a separate draft. (I will still 
> comment on some 
> > places containing SIPS, when there are other points than 
> the above.)
> 
> Well, it used to say nothing about sips and I think you 
> complained it needed to a long time back ;)
> 
> I'm not awful inclined to hold the draft up for us to 
> figure all of that out, and I'm also not inclined to say 
> nothing. My preference is to address it as best we can 
> based on the current mechanism, and the in-progress sips 
> update will need to tackle gruu.

Yeah, it's a fine line we are walking here... See below.

> we've concluded all along (and in the sipsec adhoc in 

I wouldn't say it was "all along", but it is definitively
what we concluded out of the Montréal sipsec BOF.

> 	    secure connection to the client.

That seems OK with me.

I guess one could argued that both are "reserved", as opposed to "assigned". 
You reserve both sip and sips, and only return one. Maybe I would say that
they may not be "usable" instead "working".

Something like:
 	    <t>When a GRUU is assigned to an instance ID/AOR pair,
 	    both SIP and SIPS GRUUs will be reserved. Only one will be
 	    returned, but both will exist.  The SIPS URI may not
 	    always be usable, particularly if the proxy cannot establish a
 	    secure connection to the client.
 	    </t>

But I'm fine either way.

Key is that there is one entry in the table for both shemes, as opposed to 2 entries.

> Per above I propose to keep this.

Like Paul, I am a little worried about the following statement:

      The URI will be a SIP URI if the To header
      field in the REGISTER request contained a SIP URI, else (if the To
      header field in the REGISTER request contained a SIPS URI) it will be
      a SIPS URI. 

First, it is not written as a SHOULD or MUST (but as a "will"). And more importantly,
this is where the parallel text concerning contacts and sips in RRFC 3261/10.2.1 is kind
of fuzzy. It says:

      If the address-of-record in the To header field of a REGISTER
      request is a SIPS URI, then any Contact header field values in the
      request SHOULD also be SIPS URIs.  Clients should only register
      non-SIPS URIs under a SIPS address-of-record when the security of
      the resource represented by the contact address is guaranteed by
      other means.  This may be applicable to URIs that invoke protocols
      other than SIP, or SIP devices secured by protocols other than
      TLS.

I think we have 3 choices:
(1) We clean up the language so that it matches the spirit of the same text in 3261
    (i.e., SHOULD with the fuzzy language).
(2) We have a statement that the same rule as for Contacts applies
(3) We remore the offending statement.

Personally, I believe options (2) and (3) are much better. I prefer (3).

> >    REGISTER request contains a SIPS URI, the SIPS version 

Same comment as above apply. I'm not sure we need this statement here. 
If we do decide to keep it, it is a MUST or a SHOULD? It shouldn't be this
passive form "is".