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

From: "Price, Richard" <[email-masked]>
Date: Thu, 14 Mar 2002 12:38:06 -0000

> > >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.
> 
> 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.

Hi Carsten,

The above scenario is technically possible with the current SigComp framework
(although I can't think of a situation where it would be useful).

State creation requests currently pass through two stages before they are
allowed to succeed:

Stage 1: Verify the identity of the sending endpoint

Stage 2: Check the amount of memory allocated for the sending endpoint

Announcement requests are automatically discarded if the state creation
request fails at either stage. This might initially seem inefficient - why
discard the announcement data due to insufficient state memory? However,
an important part of the SigComp design is that the compressor always knows
a-priori whether Stage 2 will succeed or not (by tracking the application-
defined parameter maximum_state_size). The receiving endpoint is welcome to
set this value to 0, but the compressor always knows that this is the case
and hence can avoid making state creation requests that will automatically
be rejected.

This means that in practice a state creation request never fails at Stage 2
(unless the compressor is malfunctioning!), so it isn't possible to set the
'b' bit in sigcomp-extended to 0.

Regarding the "multiple levels of authentication" scenario, if necessary
the maximum_state_size can vary depending on the level of authentication
(as long as this is agreed in advance by both endpoints). The decision on
whether to do this or not is left to particular signalling applications.

Regards,

Richard