Subject: RE: [rohc] sigcomp - state_identifier matching an existing one at a STATE-CREATE

From: "Surtees, Abigail" <[email-masked]>
Date: Mon, 16 May 2005 16:21:36 +0100

Hi Cristian,

The behaviour of the STATE-CREATE instruction is dependent only in part
on whether or not the state is in the same compartment.

If the full 20 bytes of state identifier match another identifier (in
any compartment) but the state itself does not match, then the state
creation fails.

If the full 20 bytes match and the state itself matches then the
behaviour is dependent on the compartment.  If they are not in the same
compartment, a new piece of state is created; if they are in the same
compartment, then the old state is moved so that it is as if it has just
been newly created.

Otherwise the state is created in the compartment in which the request
has been made.

So the answer to your question (assuming that not all 20 bytes match) is
option 1 - create a new state.

The issue for the clash when minimum_access_length bytes are checked
does not arise until state is accessed (at which point the compartment
is unknown).

When the state is accessed, the number of pieces of state with the same
first n bytes of identifier is checked.  If this is greater than 1, then
the STATE-ACCESS fails.  Due to the fact that state is accessed from a
global list (because at the time of access the compartment identifier is
not known), the likelihood of this happening on a server with thousands
of pieces of state is actually greater than one might imagine and is
discussed in detail in section 7 of the implementer's guide
<http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-impl-guide-
04.txt>.  

I hope this clarifies the situation.

Best regards,

Abbie

> -----Original Message-----
> From: cristian CONSTANTIN [mailto:[email-masked]] 
> Sent: Saturday, May 14, 2005 11:43 PM
> To: [email-masked]
> Subject: [rohc] sigcomp - state_identifier matching an 
> existing one at a STATE-CREATE
> 
hi!

suppose that a STATE-CREATE tries to create a state with a
state_identifier that matches (taking into account the
minimum_access_length) another state which already exists in the same
compartment.

what should happen?

1. create a new state (even though the state_identifiers will overlap)
2. drop the old one?
3. drop the new one?

bye now!
cristian
-- 
 _          | There are many people who use UNIX or Linux  
(_'_        | who IMHO do not understand UNIX.
  (_'rist   |              --David Korn  
GPG public key at wwwkeys.de.pgp.net

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

---

From: Cristian CONSTANTIN <[email-masked]>
Date: Tue, 17 May 2005 01:07:48 +0200

> compartment, then the old state is moved so that it is as if it has just

cristian: thank you for the explanation.
just to make sure I've got it right; this movement has to do with
the following paragraph from the sigcomp rfc:

5. The order in which the existing state items are freed is
      determined by the state_retention_priority, which is set when the
      state items are created.  The state_retention_priority of 65535 is
      reserved for locally available states; these states must always be
      freed first.  Apart from this special case, states with the lowest
      state_retention_priority are always freed first.  In the event of
      a tie, then the state item created first in the compartment is
      also the first to be freed.

> <http://www.ietf.org/internet-drafts/draft-ietf-rohc-sigcomp-impl-guide-

cristian: as far as I understand it (I am just a novice in cryptography),
this discussion does not take into account an attack which "tries" to produce 
collisions, does it? just curios, in the light of the new weaknesses
discovered in SHA-1
(http://www.schneier.com/blog/archives/2005/02/sha1_broken.html), how
"vulnerable" (to faking/changing states) is now sigcomp?

---

From: Cristian CONSTANTIN <[email-masked]>
Date: Tue, 17 May 2005 15:03:51 +0200

> compartment, then the old state is moved so that it is as if it has just

cristian: sorry to bother you again, but...
what exactly do you mean by "a new piece of state is created" ?

1. a new state item is created and it will be pointed to from this
compartment. wouldn't this contradict the statement from 9.4.5.
STATE-ACCESS (sigcomp rfc) that says:

"Decompression failure also occurs [...] if more than one state item
matches the partial identifier [...]" ?

that is the first STATE-ACCESS trying to access this state will give a
decompression failure (if we suppose that none of 2 identic states has 
been freed already)

2. same state item is going to be pointed to by this compartment whose
state_retention_priority data structure and state_memory_size is 
updated to reflect the changes.

---

From: Pekka Pessi <[email-masked]>
Date: Thu, 26 May 2005 17:47:40 +0300

>decompression failure (if we suppose that none of 2 identic states has 

Yes. That is the problem of compressor, I'm afraid. It should
detect this thing in first place and use longer
minimum_access_length for the new state (which will also
incidentally change the state-ID).

--Pekka