Subject: [rohc] Sigcomp amplifier attacks

From: [email-masked]
Date: Wed, 11 Dec 2002 11:49:40 +0100

Hi all,

 I have a problem with the 07 draft regarding DoS attacks:

1. Output: it is limited to 64K independently of the incoming message size. It is a problem, because
	a) small SigComp messages (~50 bytes) could generate 64K output
	b) in case of TCP, uncompressed messages could be larger than that (MMS uses SIP bodies, and large XML attachments are also travelling via SIP in PMG)

2. Amplifier attack: Looping state access of a one-byte-long state. According to the draft it costs 1 + state_length (2), but in fact we have to make the whole lookup+communication stuff, which is quite costly. A small (~50 bytes) could make 8000-64000 of it in a looping code before decompression failure. I think the cost of state_access should be like 100 + state_length. It is also not clear what does it cost if we access a small part of a large state.

What is your opinion on that? How vulnerable do you think Sigcomp is to DoS attacks?

BR,
Robert
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 19 Dec 2002 09:04:24 +0100

> 2. Amplifier attack: Looping state access of a one-byte-long state. 
> According to the draft it costs 1 + state_length (2), but in fact we 
> have to make the whole lookup+communication stuff, which is quite 
> costly. A small (~50 bytes) could make 8000-64000 of it in a looping 
> code before decompression failure. I think the cost of state_access 
> should be like 100 + state_length. It is also not clear what does it 
> cost if we access a small part of a large state.

While I would not call this an amplifier attack, it definitely is 
interesting.
On the other hand, repeated access to the same state is a legitimate 
mechanism for avoiding having to load the entire state into (possibly 
rather limited) UDVM memory.  So 100 may be too high as well.

I think what should be expensive is an access to a state item that has 
not been accessed before in that message.
A legitimate decompressor should not have to do this more than a couple 
of times, because the identifiers are essentially random bits and 
therefore can't be computed unless you already have the state -- the 
identifiers would have to be carried in the message.

I'm not sure we can cover all possible resource drainer attacks in the 
UDVM cycles concept.  Implementations might have different ideas on how 
expensive something is (e.g., if you store state on disk it is way more 
expensive than if you have an in-core scheme).

Note that we have limited the number of states that can be created from 
one message.  I would not be too unhappy if the UDVM implementors guide 
would mention that accessing more than, say, 100 different states from 
one message is a clear indication that the message is rogue.

Gruesse, Carsten