Re: [Sip] Issue: Expiration of temp-gruu

[Paul Kyzivat <[e-mail]>]

Dean Willis wrote:
> 
> Would a third party observing multiple uses of temp-gruu be able to 
> correlate them from this time-stamp and therefore make a reasonable 
> deduction that all the temp-gruus were bound to the same Contact and 
> therefore used by the same user?

The timestamp is only in the response to REGISTER. It isn't embedded in 
the gruu itself and so isn't visible to those receiving the gruu as a 
remote target or whatever.

(There is likely a timestamp *in* the gruu as well (along with the AOR 
and instance id), used to determine its validity. But when using that 
technique to construct temp gruus it will be necessary to encrypt all 
that info so that only the registrar/proxy can extract it.

	Paul

> Would we care?
> 
> -- 
> Dean
> 
> 
> On Dec 4, 2006, at 8:54 AM, Miguel Garcia wrote:
> 
>> I just checked the latest SIPit report, and it seems that only 5 
>> implementations supported reg event, as opposed to 29 that supported 
>> refer, 23 message-summary, or 14 presence.
>>
>> Well, this probably indicates that reg-event is not widely deployed to 
>> justify a solution based on it. Therefore, I don't mind Jonathan's 
>> solution #2
>>
>> /Miguel
>>
>> Jonathan Rosenberg wrote:
>>> The main question is really to decide on one of two mechanisms:
>>> 1. use reg-event if you are worried about use cases where this race 
>>> condition can occur (4-6 in Paul's original email)
>>> 2. add a parameter to Contact in the register response. Specifically, 
>>> I'd recommend a Contact header field parameter which indicates the 
>>> time at which the first contact with a given instance ID was 
>>> registered to that AOR. This value gets linked with each temp gruu, 
>>> and when the value changes, all of those temp-gruu get invalidated.
>>> Solution (2) is much simpler, but not needed if you think you'll 
>>> always have reg-event anyway. I don't think there is widespread 
>>> support for reg-event on endpoints yet. It is required by IMS.
>>> I am somewhat on the fence on this one. I do worry that reg-event is 
>>> genreally a very heavy solution, and may not see much usage. Option 2 
>>> is really trivially done, either in gruu or elsewhere. The main issue 
>>> is that it is another late change.
>>> -JOnathan R.
>>> Paul Kyzivat wrote:
>>>> Miguel,
>>>>
>>>> So to summarize, it seems you are of the belief that the cases where 
>>>> these measures may be inadequate are sufficiently obscure to ignore, 
>>>> and that new measures to cover the obscure cases are unnecessary. Is 
>>>> that right?
>>>>
>>>>     Paul
>>>>
>>>> Miguel Garcia wrote:
>>>>
>>>>> For issue 3, I would say that the solution is to avoid the 
>>>>> situation, e.g., by registering way in advance before the 
>>>>> registration expires. Doesn't RFC 3261 recommends to re-register 
>>>>> half time before the registration timer expires.
>>>>>
>>>>> Issues 4, 5, and 6 are solved by the reg event. So, shouldn't the 
>>>>> GRUU draft have a recommendation on the usage of the reg event to 
>>>>> solve them?
>>>>>
>>>>> /Miguel
>>>>>
>>>>> Paul Kyzivat wrote:
>>>>>
>>>>>> After some study, I have encountered a potential difficulty in 
>>>>>> determining when temp-gruus expire. After discussing this with 
>>>>>> Jonathan we decided to bring it to the list for discussion.
>>>>>>
>>>>>> As now defined, when you first register you may get a temp-gruu, 
>>>>>> which will remain valid as long as the registration does not 
>>>>>> expire or be removed. (Removal is a special case of expiration.) 
>>>>>> Each time the UA refreshes the registration it may get a new 
>>>>>> temp-gruu which also remains valid for the life of the 
>>>>>> registration. The UA can accumulate all these temp-gruus and use 
>>>>>> them as it sees fit until they expire.
>>>>>>
>>>>>> The problem is: how does the UA know when the registration has 
>>>>>> ended and the temp-gruus associated with it rendered invalid?
>>>>>>
>>>>>> This seems like a simple question, and in some cases it is simple, 
>>>>>> but not in all cases. The following are at least some of the ways 
>>>>>> that the registration can be ended, causing the invalidation of 
>>>>>> temp-gruus:
>>>>>> 1) the UA that originally registered may explicitly deregister
>>>>>> 2) the UA the originally registered may simply permit the
>>>>>>    registration to expire without attempting to refresh it
>>>>>> 3) the UA may attempt to refresh the registration, but be too slow,
>>>>>>    so that the reregistration arrives after the prior one expires
>>>>>> 4) some other UA may deregister all the registrations, including
>>>>>>    the one by this UA. (When the UA decides it should refresh the
>>>>>>    registration it will actually create a new one.)
>>>>>> 5) the registrar may remove the registration administratively
>>>>>> 6) the registrar may crash and restart, losing all its registrations
>>>>>>
>>>>>> In each of these cases the previously assigned temp-gruus become 
>>>>>> invalid. If the UA continues to use them, bad things will happen. 
>>>>>> This is true both for calls that are active when the 
>>>>>> deregistration occurs, and calls that are established later. What 
>>>>>> kinds of bad things happen?
>>>>>> - requests addressed to the gruu, both in-dialog and out-of-dialog
>>>>>>   will be undeliverable. (For instance a reINVITE or BYE in an
>>>>>>   existing call, or an out-of-dialog INVITE/Replaces for a transfer.)
>>>>>>
>>>>>> - request originated by the UA using the invalid gruu will fail
>>>>>>   immediately because the gruu is invalid.
>>>>>>
>>>>>> - if the UA subsequently reregisters, receives an incoming call, and
>>>>>>   uses one of the old temp-gruus as its contact, then the call will
>>>>>>   be established, but subsequent in- and out-of-dialog requests to
>>>>>>   the contact will fail.
>>>>>>
>>>>>> So clearly it is important for the UA to stop using temp-gruus 
>>>>>> that have become invalid. How can it know to do that in all of the 
>>>>>> above cases?
>>>>>>
>>>>>> 1) is straightforward. The UA knows it is deregistering, and should
>>>>>>    discard any cached temp-gruus. If it has a dialog with one of the
>>>>>>    temp-gruus as a contact, then it should do a target refresh and
>>>>>>    supply some working contact. (It really should do this *before*
>>>>>>    deregistering, and for a pub-gruu as well.)
>>>>>>
>>>>>> 2) the UA should take all the actions mentioned for (1) at or before
>>>>>>    the expiration time. This should be done a bit early to guard
>>>>>>    against clock skew problems.
>>>>>>
>>>>>> 3) in this case, it may be impossible for the UA to know whether
>>>>>>    the REGISTER arrived in time to be a reREGISTER or if it arrived
>>>>>>    late and was treated as a new REGISTER after the expiration of
>>>>>>    the old one. (The response to the REGISTER includes nothing that
>>>>>>    distinguishes the two cases.) About the best that can be done in
>>>>>>    this case is to check the time at which the response to the
>>>>>>    REGISTER is received. If it falls after the expected expiration
>>>>>>    time for the registration, act as if the old registration had
>>>>>>    expired.
>>>>>>
>>>>>> 4) This is a major problem. Of course, regardless of GRUU, the UA
>>>>>>    won't be able to receive incoming calls until it decides it is
>>>>>>    time to refresh the registration. In addition, until the
>>>>>>    registration reestablished, calls originated with one of its
>>>>>>    existing gruus will fail. Once the registration is reestablished,
>>>>>>    it still won't know its old temp-gruus are invalid. The only
>>>>>>    remedy for this is to subscribe to the "reg" event package,
>>>>>>    and use the resulting notifications to identify when it has
>>>>>>    been unregistered. If it does that, it can invalidate all its
>>>>>>    old temp-gruus, and then presumably reregister.
>>>>>>
>>>>>> 5) this is functionally equivalent to (4), except that perhaps
>>>>>>    attempts to reregister may fail.
>>>>>>
>>>>>> 6) this is also functionally equivalent to (4).
>>>>>>
>>>>>> The "reg" event does provide a fairly complete solution to this 
>>>>>> problem, for those that are willing and able to use it. It is not 
>>>>>> however a 100% reliable solution. Consider case (3), where the UA 
>>>>>> has a reg event subscription. All is well if the registration 
>>>>>> expires and a notification is sent indicating that, and then the 
>>>>>> reregistration occurs and a notification is sent about that. But 
>>>>>> if they happen very closely in time, it may be that only one 
>>>>>> notification is sent, reflecting the result of the reregistration. 
>>>>>> In that case the UA will not be aware that it had been 
>>>>>> unregistered for a period of time.
>>>>>>
>>>>>> A *complete* solution would, IMO, involve changing REGISTER so 
>>>>>> that it returns an indication of whether this was a new 
>>>>>> registration, or a refresh. This could take many forms. For 
>>>>>> instance the timestamp of the initial registration could always be 
>>>>>> returned with each contact, as well as the expiration time.
>>>>>>
>>>>>> The big question is whether this is a big enough issue to require 
>>>>>> a solution now, as part of GRUU, or if it can be ignored as 
>>>>>> insignificant or postponed to future work.
>>>>>>
>>>>>> I'd appreciate hearing what others think about this. At the moment 
>>>>>> I am leaning toward doing nothing, at least for now.
>>>>>>
>>>>>>     Thanks,
>>>>>>     Paul
>>>>>>
>>>>>> _______________________________________________
>>>>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>>>>> This list is for NEW development of the core SIP Protocol
>>>>>> Use [e-mail] for questions on current sip
>>>>>> Use [e-mail] for new developments on the application of sip
>>>>>>
>>>>>
>>>>
>>>> _______________________________________________
>>>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>>>> This list is for NEW development of the core SIP Protocol
>>>> Use [e-mail] for questions on current sip
>>>> Use [e-mail] for new developments on the application of sip
>>>>
>>
>> --Miguel A. Garcia           tel:[phone]
>> sip:[e-mail]
>> Nokia Research Center      Helsinki, Finland
>>
>> _______________________________________________
>> Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
>> This list is for NEW development of the core SIP Protocol
>> Use [e-mail] for questions on current sip
>> Use [e-mail] for new developments on the application of sip
>>
> 

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip