Subject: RE: [Sip] new Register DoS attack

From: "James Undery" <[email-masked]>
Date: Wed, 30 Jan 2002 09:19:46 -0000

> -----Original Message-----
> From: Jonathan Rosenberg [mailto:[email-masked]]

> James Undery wrote:
> > 
> > Hi,
> > 
> > The recent (non normative) change to Registrar behaviour 
> introduces a
> > new DoS attack against the registering UAC. There are a number of
> > variations of this attack, the attacker must be able to 
> observe the UAC
> > REGISTER and send a re-REGISTER with an incremented CSeq. 
> Next time the
> > UAC sends a REGISTER it will fail to update the bindings. 
> The obvious
> > and lazy extension to this attack is to increment the CSeq 
> by a larger
> > value (just within whatever a registrar will tolerate, 
> bearing in mind
> > Proxy-Authentication may increase the CSeq legitimately in 
> steps larger
> > than 1).
> 
> Obviously the front-line defense here is request authentication with
> replay prevention, using something like nonce-count. I think 
> this would
> solve the problem for a passive attacker. Thus, to launch this attack,
> you'd need to be a MITM, and that is a much harder attack to launch.
> Assuming you are a MITM, you could simply discard all 
> registrations you
> receive, which has the same effect. 

The problem is basically a non-issue but there are subtleties to this,
i.e. to defeat this attack using a nonce-count requires the registrar to
store state allowing state loading DoS attacks.

James

_______________________________________________
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: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 30 Jan 2002 10:57:11 -0500

> store state allowing state loading DoS attacks.

Also, the state here is bounded by the number of registrations. Thus,
the effect is different than, say, in a general server system. If each
registration takes N bytes of memory, the worst-case effect is N+C,
where C is the nonce counter. Since C << N, this is not likely to be a
major problem. (This is slightly simplified, due to having multiple UA
for registration, but that tends to be a small scale factor.)
-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs