Obtaining and Using Globally Routable User Agent URIs (GRUUs) in the Session Initiation Protocol (SIP)
draft-ietf-sip-gruu-15

[Ballot comment]
Extremely small nits:

3.2

  explicit de-registration or timeout, all of the temporary GRUUs be
  invalidated. 

Should be "temporary GRUUs will be invalidated."

6.1

  If the Request-URI contains a the "gr" URI parameter and is

"a the" requests consolidation into a single article.

[Ballot comment]
From the Gen-ART Review by Christian Vogt.

  Section 1, 5th paragraph:  s/the the/the/

  The initialism "UA" is used for "user agent" in the beginning of the
  document, but at the end of the document, "user agent" is spelled out.
  I personally prefer the spelled-out variant and would recommend to use
  that consistently throughout the document.

[Ballot discuss]
The security considerations section of this draft addresses three
  areas of concern: outside attacks, inside attacks, and privacy.
  Steve Kent in his SecDir Review raised a concern about the discussion
  of inside attacks.  Steve said:
  >
  > The discussion of inside attacks focuses on the potential for a
  > correspondent to pass an erroneous GRUU to a third party UA or to
  > a server, e.g., a presence server, as part of a DoS attack.  The
  > analysis presented in the document says that this sort of attacks
  > is avoided if an outbound proxy is employed by the attacker.
  > However, SIP does not mandate use of an outbound proxy, so there
  > is still an opportunity for this sort of attack to take place.  The
  > discussion here should be expanded to address the fact that outbound
  > proxy use if not a requirement in SIP, and thus there is a residual
  > vulnerability introduced by use of GRUUs.
  >
  Please expand the discussion of inside attacks to cover the
  vulnerability introduced by use of GRUUs when an outbound proxy is
  not employed.

IANA Last Call Comments:

*** IANA has questions: Do the pub-gruu and temp-gruu
have predefined values?

***

Action 1:

Upon approval of this document, the IANA will make
the following assignments in the "Session Initiation
Protocol (SIP) Parameters" registry located at

http://www.iana.org/assignments/sip-parameters

sub-registry "Header Field Parameters and Parameter
Values - per [RFC3968]"

Predefined
Header Field Parameter Name Values Reference
---------------------------- --------------- --------- ---------
Contact pub-gruu ??? [RFC-sip-gruu-14]
Contact temp-gruu ??? [RFC-sip-gruu-14]


Action 2:

Upon approval of this document, the IANA will make
the following assignments in the "Session Initiation
Protocol (SIP) Parameters" registry located at

http://www.iana.org/assignments/sip-parameters

sub-registry "SIP/SIPS URI Parameters - per [RFC3969]"

Parameter Name Predefined Values Reference
-------------- ----------------- ---------
gr No [RFC-sip-gruu-14]


Action 3:

Upon approval of this document, the IANA will make
the following assignments in the "Session Initiation
Protocol (SIP) Parameters" registry located at

http://www.iana.org/assignments/sip-parameters

sub-registry "Option Tags - per [RFC3261] Section 27.1"

Name Description Reference
----------- ------------------------------------------ ---------
gruu This option tag is used to identify the [RFC-sip-gruu-14]
Globally Routable User Agent URI (GRUU)
extension. When used in a Supported header,
it indicates that a User Agent understands
the extension. When used in a Require
header field of a REGISTER request, it
indicates that the registrar is not expected
to process the registration unless it supports
the GRUU extension.

We understand the above to be the only IANA Actions
for this document.

PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Keith Drage

The document has been reviewed and is ready for forwarding to IESG for
publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

Document history:
* draft-rosenberg-sipping-gruu-reqs-00 was submitted 29th July 2003 and
expired 27th January 2004.
* draft-rosenberg-sipping-gruu-reqs-01 was submitted 20th October 2003
and expired 19th April 2004.
* draft-rosenberg-sip-gruu-00 was submitted 20th October 2003 and
expired 19th April 2004.
* draft-rosenberg-sip-gruu-01 was submitted 5th December 2003 and
expired 4th June 2004.
* draft-ietf-sip-gruu-00 was submitted 6th January 2004 and expired 6th
July 2004.
* draft-ietf-sip-gruu-01 was submitted 15th February 2004 and expired
15th August 2004.
* draft-ietf-sip-gruu-02 was submitted 2nd July 2004 and expired 31st
December 2004.
* draft-ietf-sip-gruu-03 was submitted 21st February 2005 and expired
22nd August 2005.
* draft-ietf-sip-gruu-04 was submitted 14th July 2005 and expired 15th
January 2006.
* draft-ietf-sip-gruu-05 was submitted 28th September 2005 and expired
1st April 2006.
* draft-ietf-sip-gruu-06 was submitted 20th October 2005 and expired 23rd
April 2006.
* draft-ietf-sip-gruu-07 was submitted 6th March 2006 and expired 7th
September 2006.
* draft-ietf-sip-gruu-08 was submitted 14th June 2006 and expired 16th
December 2006.
* draft-ietf-sip-gruu-09 was submitted 19th June 2006 and expired 21st
December 2006.
* draft-ietf-sip-gruu-10 was submitted 31st July 2006 and expired 1st
February 2007.
* draft-ietf-sip-gruu-11 was submitted 23rd October 2006 and expired 26th
April 2007.
* draft-ietf-sip-gruu-12 was submitted 5th March 2007 and expires 6th
September 2007.
* draft-ietf-sip-gruu-13 was submitted 9th April 2007 and expires 11th
October 2007.
* draft-ietf-sip-gruu-14 was submitted 25th June 2007 and expires 27th
December 2007.

WGLC was initiated in the SIP WG on draft-ietf-sip-gruu-00 on 13th January
2004 with comments requested by 28th January 2004. A second WGLC was
announced on draft-ietf-sip-gruu-03 on 5th July 2004 with comments requested
by 17th July 2004. A third WGLC was announced on draft-ietf-sip-gruu-06 on
26th October 2005 with comments requested by 6th November 2005. A fourth WGLC
was announced on draft-ietf-sip-gruu-10 on 5th August 2006 with comments
requested by 21st August 2006. A fifth WGLC was announced on draft-ietf-sip-
gruu-11 on 13th November 2006 with comments requested by 27th November 2006.

Review was made and comments were received during the last call identified
above from: Andrew Allen, Jeroen van Bemmel, Vijay Gurbani, Paul Kyzivat,
Xavier Marjo, Eric Rescorla, Robert Sparks, Dale Worley, (with an indication
that all had performed a full review of the draft. During the course of the
work comments have also been made by at least the following: Jesus Javier
Arauz, Francois Audet, Darshan Bildikar, Spencer Dawkins, John Elwell,
Miguel Garcia, Michael Hammer, Juha Heinanen, Christer Holmberg, Cullen
Jennings, Erkki Koivusalo, Jiri Kuthan, Scott Lawrence, Rohan Mahy, Peter
Musgrave, Kasturi Narayanan, Aki Niemi, Klaus Nieminen, Sean Olsen, Michael
Proctor, Adam Roach, Brian Stucker, Dean Willis (in addition to the above).
See also the acknowledgements list in the document. See
http://www.softarmor.com/sipwg/reviews/gruu/index.html for documentation of
the final extensive review.

There have been key issues in the discussion that have been resolved to the
satisfaction of the SIP working group, but which are worth mentioning here:

* A grid parameter existed as part of the earlier drafts up to draft-
ietf-sip-gruu-10. The GRID parameter was removed from GRUU in response
to comments received. Instead, loose routing is proposed to provide
the ability of 'end-instance switching'. The gr URI parameter
(formerly gruu URI parameter) now takes a value, replacing opaque as
the server-side 'switch'.
* Up to and including draft-ietf-sip-gruu-10, GRUU did not provide any
anonymity functions at all. Indeed, the recommendations for
construction of gruus were such that they would contain the users AOR.
The point was raised that there were many places, such as Europe,
where anonymous calls are the norm. This is because privacy laws
require that caller ID be given out as an opt-in feature, and the
default is privacy. Conclusion in -11 was that serial pseudonymity is
provided. A user is given lots of anonymous GRUU, allowing it to use a
different one for each call. Each remain valid the entire duration of
the registration.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

Whilst not specifically a security related document, the document has been
reviewed by Eric Rescorla (the security adviser to the SIP working group),
and there are no remaining unresolved issues.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

The document defines a new SIP protocol extension for a particular purpose
in a form that has been used for many other extensions. The document
shepherd has no concerns with the document.

There is one patent disclosure against this document from Microsoft
Corporation. They have indicated they are prepared to license any rights on
the basis of "Reasonable and Non-Discriminatory License to All Implementers
with Possible Royalty/Fee". This has been brought to the attention of the
working group and no concerns were expressed.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

The document has been well discussed and extensively reviewed by a
significant number of members of the working group (see answer in 1(b)).

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

None indicated.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type, and URI type reviews? If the document
does not already indicate its intended status at the top of
the first page, please indicate the intended status here.

The document has been reviewed against the guidelines in RFC 4485 and it is
believed that the document is conformant with those guidelines.

While the document defines a new SIP option tag, these have been performed
as a SIP working group item, and therefore this draft is in conformance with
RFC 3427.

The document passes ID-NITS (idnits 2.04.09) with the exception of the
following:

** There are 4 instances of too long lines in the document, the longest
one being 6 characters in excess of 72.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

The document has split its references into normative and informative
references. All the normative references are appropriate normative
references. All the normative references are published except:

* reference [13] to draft-ietf-sip-outbound which is still in the final
stages of development within the SIP working group.

All the normative references are standards track documents except:

* reference [4] to RFC 2119 which is a BCP.
* reference [8] to RFC 3968 which is a BCP.
* reference [9] to RFC 3969 which is a BCP.

All the informative references are also published except:

* reference [18] to draft-ietf-sipping-cc-transfer which is still in
progress in the SIPPING WG.
* reference [27] to draft-ietf-sipping-gruu-reg-event for which
publication has been requested by the SIPPING WG.
* reference [28] to draft-rosenberg-sip-ua-loose-route for which a
charter milestone exists in the SIP WG, and for which this is a
candidate.

(1.i) Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process, has the Document
Shepherd conferred with the Responsible Area Director so that
the IESG can appoint the needed Expert during IESG Evaluation?

Section 11.1 of the document registers two new header field parameters. This
registration is consistent with RFC 3968 which defines the registry and is
also consistent with the current format of the registry.

Section 11.2 of the document registers a new SIP URI parameter. This
registration is consistent with RFC 3969 which defines the registry and is
also consistent with the current format of the registry.

Section 11.3 of the document registers a new option-tag; the new option-tag
is defined elsewhere in the document. This registration is consistent with
RFC 3261 which defines the registry and is also consistent with the current
format of the registry.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

The ABNF within the document passes the checks in Bill Fenner's ABNF parsing
web service.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Writeup? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

Several applications of the Session Initiation Protocol (SIP) require a user
agent (UA) to construct and distribute a URI that can be used by anyone on
the Internet to route a call to that specific UA instance. A URI that
routes to a specific UA instance is called a Globally Routable UA URI (GRUU).
This document describes an extension to SIP for obtaining a GRUU from a
registrar and for communicating a GRUU to a peer within a dialog.

Working Group Summary

The document complements work already performed in RFC 4474 for
authenticated request identity, and forms an integral part of the chartered
work in this area. There is consensus in the working group to publish this
document.

Document Quality

The document has been well discussed by a significant number of members of
the working group.

Personnel

The document shepherd for this document was Keith Drage. The responsible
Area Director was Cullen Jennings. 'The IANA Expert(s) for the registries in
this document are .

[Note]: 'Many SIP documents depend on GRUU. High priority. Few open issues. Current AD/Editor issue to sort out status of UUID URN, which is recommended instance ID, but has stalled in Discuss.' added by Cullen Jennings

[Note]: 'Many SIP documents depend on GRUU.  High priority.  Few open
issues.  Current AD/Editor issue to sort out status of UUID
URN, which is recommended instance ID, but has stalled in Discuss.' added by Allison Mankin