Subject: RE: [rohc] sigcomp issue rp-8

From: "Price, Richard" <[email-masked]>
Date: Tue, 23 Apr 2002 14:41:11 +0100

Hi,

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.

Regards,

Richard

> -----Original Message-----
> From: Hans Hannu (EPL) [mailto:[email-masked]]
> Sent: Monday, April 22, 2002 10:31 PM
> To: [email-masked]
> Subject: RE: [rohc] sigcomp issue rp-8
> 
> 
> 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
> 
> > -----Original Message-----
> > 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
> > 
> ...
> > 
> > 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
> > 
> 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
>

---

From: [email-masked] (Dr. Carsten Bormann)
Date: 23 Apr 2002 16:25:43 +0200

> typical decompression algorithm will cost 1 additional octet.

One more question about STATE-CREATE:
What is the sequence of events with respect to the application
agreeing on the creation of the state?
In other words, how does STATE-CREATE consume buffer size
(decompression_memory_size)?
We can't really have it consume state_memory_size, because we don't
know the compartment ID yet at the time the UDVM still runs, so we
don't know how much of that is left (and where to delete old state).
Or is STATE-CREATE just leaving behind pointers into UDVM core that
will be processed at END-MESSAGE time?

(BTW, you might get back the byte at the time the last message in a
sequence gets compressed -- this may not have to create further state,
saving the space for the pertinent parameters of END-MESSAGE.)

Gruesse, Carsten