Subject: [Sip] Updated GRUU spec - big changes

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 24 Oct 2006 01:21:55 -0400

I've submitted an update to the GRUU spec. Until it appears in the 
archives, you can pick it up at:

http://www.jdrosen.net/papers/draft-ietf-sip-gruu-11.txt

This document represents some very major changes from -10. A design team 
has been working extensively over the last month or so, and this 
represents the current output of that work. Besides being more or less a 
rewrite, the changes include:

* Top-down rewrite of the document. New introduction from
   EKR. Normative text moved around to be clearer. Redundant stuff
   removed. Sections combined. Removed arcane discussion on URI
   properties. Removed the arcane UML model and replaced it with a more
   intuitive diagram on relationships.

* added "anonymous gruu", known as temporary gruu. A temporary GRUU is
   assigned when you first register a contact, and an additional one is
   created on each refresh. All of the ones accumulated over the
   lifetime of the registration remain valid. Each of them obfuscate
   the AOR and instance ID. Added a description of a stateless
   algorithm for computing these. Lengthy discussion on the privacy
   implications of using them.

* removed completely the grid concept and associated processing. The
   plan is to instead use loose routing or an alternative like it which
   would allow a UA to add params to an AOR or a GRUU and get them back
   in a request it receives.

* changed name of 'gruu' URI parameter to 'gr'. This parameter can now
   take a value, folding in the functionality of 'opaque'. Removed the
   opaque parameter.

* removed SIPS related processing rules

* introduced this concept of self-made GRUU, which was there before
   but kind of vague. This is to address Robert's concern about always
   having proxies in the loop. A self-made GRUU is one constructed by a
   UA using its IP address or hostname as the domain part of a SIP
   URI.

* added a check in an originating proxy to make sure that the GRUU in
   the INVITE matches the identity of the requestor. THis prevents an
   attack whereby a malicious user could cause mid-dialog requests sent
   by their peer to be targeted to a DoS target.

* softened requirements around record-routing for home proxies. The
   final algorithm differs for the originating and terminating
   sides. On originating, if the request has a GRUU in the contact the
   home proxy record routes. On terminating, it record routes if the
   URI in the request URI is bound to a contact that has a GRUU. Other
   proxies in the domain can do what they want. Some guidance is given
   on what a proxy would see if it does or doesnt record route.

* added rules for tel URI handling

* removed bit about registering different contacts to each AOR when a
   UA has multiple AOR; will leave that to the UA loose route spec

* added requirement that contact cannot be weakly equivalent to AOR;
   this deals with the GRUU loop problem (where a UA registers its own
   GRUU as a contact with the instance ID associated with the GRUU,
   causing the GRUU to resolve to itself). Previously, this was solved
   by prohibiting the contact from being a GRUU. However, there are
   valid cases for this when registering a instance in one domain to
   another domain. This new rule allows this.

* Further clarifications on outbound proxies and gruu interactions

-- 
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: "Rohan Mahy" <[email-masked]>
Date: Tue, 24 Oct 2006 16:30:09 -0700

Hi,

I'm not especially thrilled with several of these changes. We had a
set of requirements that were reviewed carefully and represented a
cohesive set of functionality.  I don't see why we are changing the
requirements now.

More comments inline.

>    intuitive diagram on relationships.

I think these changes definitely improved readability.

>    implications of using them.

I just reviewed the extremely lengthy thread on GRUU privacy and have
yet to see anything resembling consensus on which privacy or
limited-user requirements we are trying to add here.  Furthermore I
expect that the mechanism provided could be abused by UAs that want a
private per call for example, creating a lot of registration thrash,
jeopardizing the avalanche restart prevention work in outbound.

>    in a request it receives.

We had a requirement in the GRUU draft to be able to manufacture a
whole family of GRUU. Grid satisfied this requirement.  I STRONGLY
object to any attempt to make this functionality depend on an untried,
substantially risky new mechanism.  I will take this to a process
appeal if necessary.

>    take a value, folding in the functionality of 'opaque'. Removed the

I like this.

>    UA using its IP address or hostname as the domain part of a SIP

I like this.

>    UA has multiple AOR; will leave that to the UA loose route spec

Again, I object to making this document depend on the UA loose routing
spec.  If you want to tone down the language, I propose something like
this:

"Note a User Agent with multiple AORs needs to insure that it can
distinguish requests to each AOR. One way to insure this property is
to use a unique Contact URI per AOR."

thanks,
-rohan

---

From: EKR <[email-masked]>
Date: Tue, 24 Oct 2006 17:03:40 -0700

"Rohan Mahy" <[email-masked]> writes:
> limited-user requirements we are trying to add here.

I'm not sure I agree with this assertion, but I certainly
don't think there was consensus on *not* including some
privacy mechanisms.

>  Furthermore I

I don't understand what the security problem you're concerned with
is. Can you describe the scenario in more detail?

-Ekr

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 25 Oct 2006 13:59:15 -0700

"Rohan Mahy" <[email-masked]> writes:

> On 10/24/06, EKR <[email-masked]> wrote:
> Actually there was such a consensus when we took the requirements and
> formally handed them to SIP.

Maybe so, but there's not now, and now is what's important for
assessing WG consensus on moving a document forward.

> Its not a security problem.  It is an operational problem. A user
> agent that fetches new gruu for every new call would add a substantial
> amount of additional load on a registrar, especially if that registrar
> was also doing outbound processing.

I don't see that. Why?

-Ekr

---

From: "Rohan Mahy" <[email-masked]>
Date: Wed, 25 Oct 2006 17:05:06 -0700

> assessing WG consensus on moving a document forward.

I do not see any consensus around privacy requirements.  I'm not
saying that one does not exist, or one cannot be forged.  However, we
consciously decided to postpone additional privacy work when we
started GRUU.  I don't see what has suddenly changed so that we have
to cram a possibly half-assed mechanism into the GRUU spec.

> > was also doing outbound processing.

A registrar sized to handle x UAs with an average of just over 2
registrations per hour suddenly finds a non-trivial number of its UAs
registering 10, 20, or 50 times during the busiest period.

thx,
-r

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 25 Oct 2006 18:07:07 -0700

> to cram a possibly half-assed mechanism into the GRUU spec.

What's changed is that a lot of people came to the conclusion that
GRUU as-was represented a serious privacy threat. 

> registering 10, 20, or 50 times during the busiest period.

I'm having a little trouble understanding your arrival model here.  In
what environment, exactly, are people having to get 50 anonymous GRUUs
in a short period of time? 

-Ekr

---

From: "Rohan Mahy" <[email-masked]>
Date: Wed, 25 Oct 2006 13:00:23 -0700

thanks,
-rohan

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 26 Oct 2006 10:59:04 -0400

inline.

> to cram a possibly half-assed mechanism into the GRUU spec.

There is a difference between adding new privacy features, and releasing 
a draft which worsens substantially the privacy of the system prior to 
the specification. GRUU is meant to be a spec that basically always gets 
used; its a 'core' SIP spec for that reason.

So, this was raised as a bug and I think it can legitimately be 
qualified as such.

> registering 10, 20, or 50 times during the busiest period.

Indeed if a UA did this, it would be a problem.

This is why the mechanism was purposefully designed so that users would 
get new temporary gruu as part of their 'normal' refresh. There is 
virtually no reason why a UA would perform extra registrations. Its only 
if a UA wants to invalidate a temporary GRUU ahead of its removal. 
However, we already have standards based mechanisms for achieving that 
goal (via consent framework) that are far less onerous.

The GRUU spec also recommends against these extra registrations for the 
same reasons you are raising.

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 26 Oct 2006 11:19:59 -0400

inline.

> limited-user requirements we are trying to add here. 

Well we had consensus I think on trying to do as good as rfc3261 alone. 
There was some debate on whether this would in fact require you to 
change Contact URI on a call by call basis (since you could do that with 
rfc3261). But there was consensus on that requirement I thought.

  Furthermore I
> jeopardizing the avalanche restart prevention work in outbound.

Per my other note, getting a different gruu per call does not require 
extra registrations.

A UA with an objective of being malicious, and placing load on the 
server, can re-register a lot with or without the gruu spec.

> substantially risky new mechanism.  I will take this to a process

During his review, ekr raised the issue that this was really a general 
issue and that the proposed solution was highly specific to gruu, and 
that a better, more general purpose solution was reqiured (one that 
allowed you to manufacture identities against your AOR too). This was a 
good point and there was consensus to do a more general solution. Thus, 
the functionality was pulled from GRUU, and I submitted an individual 
I-D proposing a solution. You are welcome to submit a draft with your 
solution.

Are you objecting to the proposed mechanism, or objecting to making it 
more general purpose and in a separate spec?

> to use a unique Contact URI per AOR."

The GRUU spec more or less talks about doing this, but not in a 
normative fashion as it did in -10. The following text appears in -11:

   When a UA receives a request, the GRUU placed into the Contact header
    field of a 2xx response SHOULD be the one associated with the AOR or
    GRUU to which the request was most recently targeted.  There are
    several ways to determine the AOR or GRUU to which a request was
    sent.  For example, if a UA registered a different contact to each
    AOR (by using a different user part of the URI), the Request-URI
    (which contains that contact) will indicate the AOR.

are you objecting to this?

-Jonathan R.

---

From: [email-masked] (Juha Heinanen)
Date: Thu, 26 Oct 2006 18:44:03 +0300

> rfc3261). But there was consensus on that requirement I thought.

yes, but i didn't get a clear answer to the issue regarding the host
part in the pseudo anonymous gruu.  does it need to reveal the actual
domain of the caller?  in rfc3261, only ip address is revealed.

-- juha

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 26 Oct 2006 12:49:18 -0400

> domain of the caller?  in rfc3261, only ip address is revealed.

It doesn't need to reveal the actual domain of the caller *directly*. 
But it does need to route back to the authoritative proxy for the AOR. 
If the registrar has a way to obscure the domain and still preserve the 
proper routing it is free to do so.

	Paul

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 26 Oct 2006 14:08:52 -0400

Right. Note that the domain part of the GRUU could be an IP address too; 
though this has issues. And while it is true that, prior to GRUU, the 
Contact doesn't even have to route back to the provider (it can be 
sip:[email-masked]), the Via header inserted by the last 
proxy in the SP network DOES have to route back to that provider. So, 
RFC 3261 is already telling someone the identity of my SIP provider.

-Jonathan R.

Paul Kyzivat wrote:

>>  > Well we had consensus I think on trying to do as good as rfc3261 
>> alone.  > There was some debate on whether this would in fact require 
>> you to  > change Contact URI on a call by call basis (since you could 
>> do that with  > rfc3261). But there was consensus on that requirement 
>> I thought.
>>

---

From: "Rohan Mahy" <[email-masked]>
Date: Thu, 26 Oct 2006 11:51:13 -0700

Jonathan,

In practice, I don't think GRUU "substantially worsens" the privacy of
SIP as it is deployed and will be deployed.  This does not worsen
privacy for UAs who are talking to PSTN gateways or UAs that are
already going through B2BUAs that insert media relays.  In any case
the security properties of GRUU were not considered a "bug" two years
ago.

I strongly suspect that folks that want any real privacy will want at
least "service-provider level" IP address anonymity.  The fact that we
do not even have a consistent vocabularly in this group to talk about
these privacy issues strongly hints that we need an explicit
requirements discussion, and an explicit mechanism, to enable GRUU
privacy.

thanks,
-rohan

---

From: "Rohan Mahy" <[email-masked]>
Date: Thu, 26 Oct 2006 12:01:34 -0700

Hi,

comments inline.

> rfc3261). But there was consensus on that requirement I thought.

Maybe you had a consenus on a phone call, but I could not find more
than a handful of people agreeing with this principle in the long
thread.

> server, can re-register a lot with or without the gruu spec.

My use case was separate a Contact URI per unrelated call, which as
you point out can be done in RFC3261.  I'm not considering the UA
being malicious.

> more general purpose and in a separate spec?

I am objecting to removing this functionality from GRUU.  I do not
object to renaming the grid parameter in the GRUU spec, making this
"passthru" behavior apply to AORs on supporting proxies, or even
putting this general functionality in a seperate section of GRUU.

If the WG agrees that the general solution is compelling enough to
move this to a separate WG draft and send it to WGLC at the same time,
I am OK with that too as long as the general purpose solution is
mandatory to implement if you implement GRUU.

> are you objecting to this?

I think this is a minor detail.  I prefer just saying that UAs need to
do this.  SHOULD implies wiggle room that I don't feel is appropriate.

thanks,
-rohan

---

From: Scott Lawrence <[email-masked]>
Date: Sun, 29 Oct 2006 16:16:57 -0500

>    implications of using them.

Several comments on this:

- I agree with EKR that calling the anonymous gruu a "temporary gruu" is
not clear.  The essential characteristic of it is not that it is
temporary - it is no more temporary than any other contact value, and
possibly no more temporary than the public gruu value.  

- I don't understand why it should be true that the 'temporary' gruu
should be both reissued at every refresh and be valid for the same
duration as the accompanying 'public' gruu.  Despite the inclusion of a
non-normative way to do this in the document, I don't think that
changing the normal rules for the expiration of registrations in that
way is needed, and it puts additional burden on registrars to implement
it.

- I don't see the specific value in having the registrar always return
two gruu values.  If both sorts are needed, then I think it would be
better to have a request parameter that specifies which is wanted.  That
would allow the registrar to indicate that it can or cannot provide a
gruu with the requested properties.  The specification should just
describe the qualities of each sort of gruu, including how to tell one
from the other.

- The proposed construction of the 'public' gruu has the property that
it is also equivalent by 3261 URI rules to the same AOR without the 'gr'
parameter.  Doesn't this break the basic characteristic of the gruu -
that it addresses a specific instance?  Suppose that two UAs both
register sip:[email-masked].  The first supports gruu and provides an
instance identifier, so it is issued a public gruu; the second does not
support gruu, so the binding is just from the AOR to the contact it
provides.   The first UA communicates its GRUU to Bob somehow, and then
unregisters itself, destroying the gruu. Bob then sends a request to the
gruu - by 3261 rules, it should be routed to the second UA because
'sip:[email-masked];gr=kjh29x97us97d' is equivalent to
'sip:[email-masked]'.  I think that this, and the associated property
that the draft calls semi-permanence is actually undesirable - it blurs
the distinction between the specificity of the gruu value and the AOR.
I think that it would be better to use the reverse construction in which
the AOR is provided as a specific parameter to a locally unique value
selected by the registrar:
   sip:[email-masked];gr-aor=[email-masked]

> * removed SIPS related processing rules

Those are improvements.

>    by their peer to be targeted to a DoS target.

I assume that you are referring to this paragraph:
        
           If an originating authoritative proxy receives a dialog-forming
           request, and the Contact header field contains a GRUU in the domain
           of the proxy, and that GRUU is associated with the AOR matching the
           authenticated identity of the requestor (assuming such authentication
           has been performed), and the request contains Record-Route header
           fields, the authoritative proxy MUST record route.  If the request
           contained a GRUU in the domain of the proxy, but this GRUU had an AOR
           which did not match the authenticated identity of the requestor, it
           is RECOMMENDED that the proxy reject the request with a 403.

I'm pretty sure I don't understand that.  There seem to be two
requirements there that both apply only to dialog forming requests that
have a GRUU:

- one that requires that the proxy add a record-route for itself to any
such request that it does pass on.  Why?  Any request directed toward
that GRUU value will be sent to the proxies domain anyway eventually.
If this is an attempt to prevent an attacker from diverting in-dialog
requests by record-routing, I don't see how this helps: even if the
proxy adds itself in a record-route, it will still obey the attackers
record-route when it arrives, even if the request uri is a local gruu;
or were you suggesting that it should replace the record-routes in the
message?  

- the second requirement is vague in that it says "If the request
contained a GRUU in the domain of the proxy" - contained where?  in the
Contact header?  In the request URI?  Is the intent of this one simply
that the authoritative proxy should reject a dialog forming request that
has a GRUU for a Contact but cannot authenticate itself as coming from
the identity to which that GRUU is mapped?  Is this a sort of back-door
Identity mechanism, or is there something else intended?

>    another domain. This new rule allows this.

I don't understand what is really meant by this paragraph:

   If, however, the GRUU was a public GRUU, the registrar SHOULD
   continue to treat the GRUU as valid.  Consequently, subsequent
   requests targeted to the GRUU, prior to re-registration of a contact
   to the GRUU, SHOULD return a 480.  In addition, since the GRUU
   remains valid, the rules in Section 5.1 will cause it to be retained
   when a contact with that instance ID is once again registered to the
   AOR.

As described in this draft, a public gruu is just the AOR decorated with
a 'gr' parameter with a value.  If I'm not mistaken, that should be
treated as equivalent to any undecorated version of that AOR according
to 3261 URI equivalence rules, but not to any version of that AOR that
has some other version of the 'gr' parameter.   So wouldn't the same
effect be achieved by just making the value of the 'gr' parameter be
exactly the value of the +sip.instance value that was passed in the
REGISTER request that created the public gruu?  This would have the
additional nice property that the UA is in control of when a public gruu
is considered equivalent and when it is not, since it selects the
+sip.instance value.  

Why prohibit the registrar from putting 'gruu' in the Supported header?

-- 
Scott Lawrence  tel:+1-781-938-5306;ext=162 or sip:[email-masked]
  sipXpbx project coordinator - SIPfoundry    http://www.sipfoundry.org/sipX
  Chief Technology Officer    - Pingtel Corp. http://www.pingtel.com/