RE: [Sip] new open issue in session timer: NEEDS resolution now!

["Brett Tate" <brett@broadsoft.com>]

> We added the ability for a proxy to reject a request if the 
> session timer
> was too low. Consider the case of a UAC A, two proxies B and 
> C, and UAS D. A
> sends an INVITE, with Supported: timer. It lists a value of 1 
> hour. This
> hits proxy B. B feels this is too long, and wants the 30 
> minute minimum. So,
> it reduces it. That hits C. C feels this is too short, below 
> its 45 minute
> minimum. So, it rejects the request, and includes a 
> session-expires header
> with 45 minutes. 
> 
> So, A resends the request, with a session-expires of 45 
> minutes. This, once
> again, is too short for B, which reduces it to 30 minutes, 
> and passes it to
> C. C rejects it because its too long, and includes a 
> session-expires header
> with 45 minutes.
> 
> This will then continue ad-infinitum. Its also a nice DoS 
> attack in and of
> itself.
> 
> Dean raised this issue a while back. I had suggested the 
> ability of a proxy
> to increase the session-expires, and then include a header, say
> Minimum-Timer, which indicates its minimum value that no one 
> else can reduce
> it below. He pointed out that you have problems, then, if two 
> proxies have
> non-overlapping preferences. Well, we still have that 
> problem. The result of
> the 422 rejection response is that proxies can, effectively, 
> increase the
> value of the session timer, so the same problem arises.
> 
> The only sensible out that I see is to add back this 
> Minimum-Timer header. A
> UAC, when it gets a 422 Session Timer too small, remembers 
> the value of the
> Session-Expires in that response. It stores the largest value 
> returned in
> any 422 for the call leg in question. In any re-invites with 
> session timers,
> the UAC includes a Minimum-Timer header with this value. A 
> proxy MUSTNOT
> reduce the session timer below this value. 
>

Using the 422 and Minimum-Timer sounds fine with 
me.  It solves the problem while allowing for 
Session-Expires negotiation.

The header name is also ok since the option-tag 
for the draft is "timer".  Minimum-Session-Expires 
seems a little more precise, but it is little 
longer.

Intentional or not, the solution reduces the 
possibility of smaller Session-Expires values 
that might want to be used in pre-paid services 
through proxies.  However I guess that it is 
better than adding a parameter to
Session-Expires to indicate that the session 
will not or cannot be extended; thus please 
allow this small value.  The parameter would
also guarantee faster cleanup of sessions known 
to be of a predetermined short length.

> I welcome any other suggestions....
> 
> Another requirement for this to work is that, when a UA refreshes, it
> inserts a session-expres with the same timer as the previous 
> successful
> re-INVITE, unless it explicitly wishes to disable session 
> timers. Without
> that, the smurf attack is still possible! Thats because, if 
> each re-invite
> doesn't contain the last session timer, no request will actually ever
> contain a session-expires, and so there is no opportunity for 
> a proxy in
> front of the attacking proxy to reject the low values inserted by the
> attacking proxy!

I'm not sure that I understand your reasoning 
for requiring the same Session-Expires for 
re-INVITEs that were in the previous INVITE.  
Can't the whole renegotiation process take 
place again among the entities that stayed 
in the route?  This would force the smurf 
requesting small values to stay in the route.  
If you are suggesting the use of the same 
Minimum-Timer header to avoid the 422's, I agree.


_______________________________________________
Sip mailing list  http://www.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors@cs.columbia.edu for questions on current sip
Use sipping@ietf.org for new developments on the application of sip