Subject: [rohc] sigcomp issue rp-8

From: "Hans Hannu (EPL)" <[email-masked]>
Date: Tue, 16 Apr 2002 19:08:22 +0200

Hi,

My thoughts on the STATE-CREATE instruction.

> I'm not so sure. Allowing to create a few small states is sometime 
> convenient for a compressor to avoid overlapping between large 
> states. It also gives the compressor more control on the memory
> management.

You could avoid overlapping between states already with the current set of instructions namely the END-MESSAGE instruction and the STATE-ACCESS instruction. 
- You have the possibility to instruct on what data to create a state (END-MESSAGE instruction). 
- With the STATE-ACCESS instruction it is possible to access any octet string from different states. 

On the other hand this instruction fits very well with the state_retention_priority as parts of the UDVM memory saved as states can be assigned different deletion priorities, which may give the compressor more control on the memory management.

On the third hand after reading the emails regarding sigcomp issue lejo-8 the STATE-CREATE instruction may imply additional efforts as the UDVM may hold several pending state creation requests instead of just a maximum of one.

BR
/Hans H

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

---

From: [email-masked]
Date: Tue, 16 Apr 2002 23:15:10 -0500

> -----Original Message-----
> From: ext Hans Hannu (EPL) [mailto:[email-masked]]
> Sent: April 16, 2002 12:08 PM
> To: [email-masked]'
> Subject: [rohc] sigcomp issue rp-8
> 
> 
> Hi,
> 
> You could avoid overlapping between states already with the 
> current set of instructions namely the END-MESSAGE 
> instruction and the STATE-ACCESS instruction. 

Right.

> On the other hand this instruction fits very well with the 
> state_retention_priority as parts of the UDVM memory saved as 
> states can be assigned different deletion priorities, which 
> may give the compressor more control on the memory management.

Smaller states give you finer granularity.

> On the third hand after reading the emails regarding sigcomp 
> issue lejo-8 the STATE-CREATE instruction may imply 
> additional efforts as the UDVM may hold several pending state 
> creation requests instead of just a maximum of one.

We can have say 3 or 4 as the maximum # of state creation requests 
per message. That gives enough flexibility and yet won't create trouble: 
you still authenticate the decompressed message only once. 

Zhigang

---

From: "Price, Richard" <[email-masked]>
Date: Wed, 17 Apr 2002 17:28:08 +0100

Hi,

Another benefit of the STATE-CREATE instruction is that you can save
an important item of state with a high minimum_access_length, at the
same time as saving a less important state item with a low
minimum_access_length.

> you still authenticate the decompressed message only once. 

This is where the STATE-CREATE instruction may cause additional security
concerns. The problem is that if we allow each message to create 4 items
of state rather than just one, a malicious sender who is attempting to
cause a hash collision can fill up the state identifier space 4 times more
quickly. It may be necessary to redo the security considerations to take
this into account.

If it turns out that STATE-CREATE introduces only a negligible additional
security risk then I'd like to see the functionality added to SigComp-06.

Regards,

Richard

---

From: "Hans Hannu (EPL)" <[email-masked]>
Date: Mon, 22 Apr 2002 23:30:49 +0200

Hi,

I'm not sure if I add anything new to this discussion but, I still like to say in order to try closing this issue:

Proposed action: Add STATE-CREATE instruction if time limit allows for security consideration redo
Limit the number of created states by one compressed message to a maximum of 4.

BR
/Hans H

> From: Price, Richard [mailto:[email-masked]]
> Sent: den 17 april 2002 18:28
> To: [email-masked]'; [email-masked]; 
> [email-masked]
> Subject: RE: [rohc] sigcomp issue rp-8
> 
...
> security risk then I'd like to see the functionality added to 
...

---

From: "Hans Hannu (EPL)" <[email-masked]>
Date: Tue, 23 Apr 2002 15:59:40 +0200

> One final question on this issue: if we determine that a
> STATE-CREATE instruction is OK from a security perspective
> then should we delete the ability to create a state item from
> the END-MESSAGE instruction? This will simplify the draft
> somewhat, but on the other hand the UDVM bytecode for a
> typical decompression algorithm will cost 1 additional octet.

Hi Richard,

I kind of like the END-MESSAGE instruction as it is today. So my suggestion is to leave the END-MESSAGE instruction as it is in the current editor's working document. 

However, the question still exist whether STATE-CREATE with a limit of 4 (or even fewer) state creates is OK from a security perspective or not. I do not have the answer and it seems that nobody are convinced either way (myself included). Anybody?

BR,
/Hans H