[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Sip] Updated GRUU spec - big changes
On Tue, 2006-10-24 at 01:21 -0400, Jonathan Rosenberg wrote:
> * 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.
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:alice at example.com. 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:alice at example.com;gr=kjh29x97us97d' is equivalent to
'sip:alice at example.com'. 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:gruu~kjh29x97us97d at example.com;gr-aor=alice at example.com
> * 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
Those are improvements.
> * 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.
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?
> * 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.
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:slawrence at pingtel.com
sipXpbx project coordinator - SIPfoundry http://www.sipfoundry.org/sipX
Chief Technology Officer - Pingtel Corp. http://www.pingtel.com/
_______________________________________________
Sip mailing list https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors at cs.columbia.edu for questions on current sip
Use sipping at ietf.org for new developments on the application of sip