Subject: Re: [Sip] Open Issue #290: Registrar increasing registration life time

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 03 Jan 2002 03:25:11 -0500

Ben Campbell wrote:

> Actually, I really hate letting a registrar increase the interval, for a
> few reasons:
> 
> 1) As you mention, Expires:0 would then require special case processing.
> 
> 2) The registering device should be the "owner" of its registration. It
> is the only thing that has any hope to know the lifetime that its
> registration is meaningful. If it sends a short Expires header, one must
> assume to some degree it knows what it's doing. If it's choice of
> Expires violates network _policy_, then a better solution would be to
> send some sort of error response, perhaps containing the minimum allowed
> expiration.

Its interesting to note that this would ALSO require special case 
handling of expires:0.

Really, the problem is not that expiration times are short, the problem 
is that the client may be trying to refresh too frequently. If the 
client does not plan to refresh, there is no problem with any duration 
expiration.

Perhaps, then, what is really needed is for a registrar that cares to 
keep track of the # of registrations over some time period for a 
particular contact, and if it exceeds a maximum, then generate some kind 
of error response.

> 3) Since there is no way to enforce that a client does not re-register
> well before the expiration time, forcing a larger expiration is a fairly
> weak solution to registration rate problems. Since older implementations
> had a reasonable expectation that the Expires value would not increase,
> they may not check for the condition.

The ONLY thing solved by the increasing-duration capability was to 
handle compliant, but "overly zealous" user agents. There is no 
disagreement that it doesn't help with dos attacks.

Perhaps the right solution, then, is to allow registrars to only 
decrease, and to provide an error response code to provide a general 
"you're sending too fast, slow down" capability, which would also be 
helpful for SUBSCRIBE, for example, which will suffer the same problem.

Comments?

-Jonathan R.

> 
> 
> On Thu, 2001-12-27 at 11:30, Jonathan Rosenberg wrote:
> 
>>The spec now says that the registrar can increase the registration 
>>interval.
>>This is done to protect the registrar from clients that want to
>>
> refresh too
> 
>>frequently. However, this introduces interesting complications:
>>
>>   a. it can't really increase Expires: 0, since we do need a way to 
>>terminate a
>>registration, so we would need to special case 0
>>   b. the client may choose to register an interval because they want
>>
> the
> 
>>information to die at a specific time (husband registering his phone
>>
> at his
> 
>>mistresses number for a brief period, REALLY wants it unregistered
>>
> when 
> 
>>he asks)
>>
>>So, do we really want to allow the registrar to increase the interval?
>>
>>
>>-Jonathan R.
>>-- 
>>Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
>>Chief Scientist                         First Floor
>>dynamicsoft                             East Hanover, NJ 07936
>>[email-masked]                 FAX: (973) 952-5050
>>http://www.jdrosen.net                  PH:  (973) 952-5000
>>http://www.dynamicsoft.com
>>
>>
>>_______________________________________________
>>Sip mailing list  http://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
>>
> 
> 

-- 
Jonathan D. Rosenberg, Ph.D.            72 Eagle Rock Avenue
Chief Scientist                         First Floor
dynamicsoft                             East Hanover, NJ 07936
[email-masked]                 FAX: (973) 952-5050
http://www.jdrosen.net                  PH:  (973) 952-5000
http://www.dynamicsoft.com

_______________________________________________
Sip mailing list  http://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: "Brett Tate" <[email-masked]>
Date: Thu, 3 Jan 2002 15:28:13 -0500

> The ONLY thing solved by the increasing-duration 
> capability was to handle compliant, but 
> "overly zealous" user agents. There is no 
> Perhaps the right solution, then, is to allow 
> registrars to only decrease, and to provide an 
> error response code to provide a general 
> "you're sending too fast, slow down" capability, 
> which would also be helpful for SUBSCRIBE, for 
> example, which will suffer the same problem.
> 
> Comments?

All of these same points were raised last summer
around the time we were also trying to address 
short Session-Expires.
(Sorry, I couldn't reach 
http://lists.bell-labs.com/pipermail/sip/
to link the thread).

At that time, the decision was that the REGISTER
was not intend to register services like temporary 
call forwarding through the use of the expires
header or parameter.  Nobody was overly opposed 
to the backward compatibility issue with rfc2543.
People didn't really think reallocation of a
contact to a different subscriber would really
be an issue.

The problem with returning an error response is
that non-bis compliant UAC's would reduce the
response to 400.  Thus it might actually produce
more registrations and restrict the user from 
receiving calls until customer support 
communicates what the timer should be.

The problem with UAS extending the timer is that
non-bis compliant UAC might continue to register
based upon original expires.  This isn't that
big a deal.  The registrar could kick off an
email, auto-call, or begin rejecting the REGISTER
to ensure the situation gets corrected.

Ultimately, I don't mind which solution is 
chosen, I would just like to see it closed 
for good.  If a vote is required, I'd prefer
allowing the registrar to modify the 
expires however it desires as long as it
gets communicated back to the UAC so it knows
when to refresh or cancel the registration.
This would help avoid the need for user 
reconfiguration since the UAC gives the
preference and the UAS gives the decision.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 10 Jan 2002 13:38:08 -0500

Brett makes some excellent points. Thanks for recapping
the old discussion.

Based on this, I would therefore propose to keep what
we have, and allow the registrar to increase the durations,
indicating that an exception should be made for 0, and
document that this means setting registrations with
expires is not the right way to get call services.

Let us resolve this issue finally.

-Jonathan R.

---

From: Ben Campbell <[email-masked]>
Date: 10 Jan 2002 13:15:18 -0600

Actually, I hated it back then, too--and probably missed the argument to
argue harder against it. 

At the risk of repeating myself, my complaint is that the client may
have good reason for wanting a particular expiration. I will not
speculate further on what the good reason might be, but I will be very
surprised if people don't fine one. If the REGISTER transaction had an
ACK where the client could say "sorry, that larger expires will not work
for me".

Without such a mechansim, the registrar should assume the client had a
reason for choosing the expiration. If that value violates some policy
of the registrar, the registrar should reject the request. It doesn't
matter if the policy is "Expires must be >X" or "Expires must be an odd
number", or "Expires must be not be in absolute form" or "the moon must
be full."

Why is this different than the complementary policy of "Expires must be
<=X?" Well, one assumes that, if a client needs to increase the
expiration time in the future, it will be around to do it. You cannot
make the same assumption for a client needing to de-register early.