Subject: [rohc] RE: The 'b'-bit

From: "Price, Richard" <[email-masked]>
Date: Thu, 14 Mar 2002 10:37:09 -0000

> Hi Richard,
> you state in your posting  
> https://www1.ietf.org/mail-archive/working-groups/rohc/current
> /msg00119.html that there is no possibility for the 'b' bit 
> to be set to zero. You motivate it as follows:
> 
> > However the current
> > SigComp draft bans this possibility: if the state creation 
> > request fails then the announcement request MUST fail also.
> > 
> 
> I've looked through the draft but have been unable to find 
> it. Could you direct me?

Hi Jan,

The relevant text is as follows (taken from Section 6.1):

"Upon receiving a decompressed message, the application may supply
the state handler with the identity of the sending endpoint.
Supplying this identity grants permission for the state handler to
do the following:

*    An item of state can be saved using the memory reserved for the
     specified endpoint.

*    Announcement information can be taken into account
     when sending SigComp messages to the specified endpoint."

In particular, this means that the announcement information is treated
with exactly the same care security-wise as the state creation request.
If one fails due to security then both must fail.

> Next question: why should it be like this? Why should the 
> announcement message be linked to a succesful state creation 
> request? Is it not enough that the message is successfully 
> decompressed to allow the announcement message to be passed 
> to the dispatcher?

The announcement information may appear innocuous, but it can overwrite
the application-defined parameters at an endpoint and therefore must
be treated as a kind of state information. It would be dangerous to
allow announcement requests to succeed without the permission of the
application because they could be used by malicious users to perform a
nasty DoS attack on SigComp.

> The reason I'm concerned about this is that I can imagine 
> situations where it's possible to save the state used for 
> shared compression but not any other state. This would mean 
> that you should be able to use the shared state for 
> compression (but not the state that couldn't be saved).

From a security perspective it isn't possible for an announcement
request to succeed unless the state creation request succeeds also.
This is important so that DoS attacks using false announcement data
can be prevented.

Another reason that the state creation request might fail is lack of
memory, but since the maximum_state_size is known by the compressor
this situation can never arise in practice (as the compressor wouldn't
make the state creation request in the first place). The only reason
that state creation can fail without the sender knowing about it is
because the application can't authenticate the sending endpoint, in
which case the announcement request must fail also.

Hope this helps!

Regards,

Richard

---

From: "Dr. Carsten Bormann" <[email-masked]>
Date: Thu, 14 Mar 2002 12:35:02 +0100

> This is important so that DoS attacks using false announcement data

While I agree with the general sentiment, I'm not sure that is true in the
absolute.
The endpoint may be authenticated well enough to believe its announcements,
but just not authorized yet to actually establish state (which might then
lead to a 401 reply requesting more powerful authentication).
Not very likely in most security policies, but possible.

Gruesse, Carsten

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