Subject: RE: [rohc] SigComp torture tests

From: "Surtees, Abigail" <[email-masked]>
Date: Fri, 4 Mar 2005 09:51:36 -0000

Hi Herve,

This is exactly the right place for these comments :-)  

The STATE-FREE instruction does not check minimum access length so it's ok
for the partial id to have length 6.  This is explained in the following
text (from section 3.2 of the implementer's guide):

"The STATE-FREE instruction does not check the minimum_access_length.
   This is correct because the state cannot be freed until the
   application has authenticated the message.  The lack of checking does
   not pose a security risk because, if the sender has enough
   information to create authenticated messages, then sending messages
   that save state can push previous state out of storage anyway.
   The STATE-FREE instruction can only free state in the compartment
   that corresponds to the message being decompressed.  Attempting to
   free state either from another compartment or that is not associated
   with a compartment has no effect."

I hope that helps.

Best regards,

Abbie

> -----Original Message-----
> From: Herve Siegrist [mailto:[email-masked]] 
> Sent: Friday, March 04, 2005 9:02 AM
> To: [email-masked]
> Subject: [rohc] SigComp torture tests
> 
> 
> I am currently testing an UDVM implementation against the SigComp 
> torture tests (draft dated February 14, 2005) and I am 
> getting into some 
> trouble with the "State creation" tests, section 2.15.
> 
>  From the look of the code, it seems to me that all state creation 
> requests are issued with a minimum access length of 20 while 
> all state 
> free requests are done with a partial identifier length of 6. As a 
> result, I don't really see how a state free could actually occur...
> 
> Did I miss something big, or is that a real problem in the draft?
> 
> Thanks,
> Herve.
> 
> P.S.: Hope that's the right place for these comments, just got in...
> 
> 
> 
> _______________________________________________
> Rohc mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/rohc
> 

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

---

From: Pekka Pessi <[email-masked]>
Date: Mon, 07 Mar 2005 16:57:39 +0200

>for the partial id to have length 6.  

That is the corner case 4 in 2.15. However it looks like the code
does not actually test corner case 3, "An item of state is created
and then freed by the same message."

Perhaps the test should input partial_identifier_length, too. The
code below is designed to test yet another corner case, if the
STATE-FREE partial_identifier_length does not lie between 6 and 20
inclusive then decompression failure should occur.

at (64)

:byte_copy_left                 pad (2)
:byte_copy_right                pad (2)
:states                         pad (1)
:states_lsb                     pad (1)
:identifier_length              pad (1)
:identifier_length_lsb          pad (1)

set (state_length, 10)

at (128)

INPUT-BYTES (1, states_lsb, !)
INPUT-BYTES (1, identifier_length_lsb, !)

:test_one
LSHIFT ($states, 13)
COMPARE ($states, 32768, test_two, create_state_a, create_state_a)
:create_state_a
STATE-CREATE (state_length, state_address, 0, 20, 0)

:test_two
LSHIFT ($states, 1)
COMPARE ($states, 32768, test_three, free_state, free_state)
:free_state
STATE-FREE (state_identifier, $identifier_length)

:test_three
LSHIFT ($states, 1)
COMPARE ($states, 32768, end, create_state_b, create_state_b)
:create_state_b
END-MESSAGE (0, 0, state_length, state_address, 0, 20, 0)

:end
END-MESSAGE (0, 0, 0, 0, 0, 0, 0)

:state_identifier
byte (0x8e, 0x0b, 0x47, 0x38, 0x15, 0xee, 0xf8, 0x94, 0xa3, 0x02, 0x23, 0x42, 
	0x46, 0xd9, 0x6f, 0xd0, 0x68, 0x75, 0x77, 0xc6)

:state_address
byte (1, 2, 3, 4, 5, 6, 7, 8, 9, 10)

The bytecode is as follows:

0xf806 111c 01a0 459f 7f1c 01a0 479f 7904 220d 1762 8f0d 0606 200a
0xa0d7 0014 0004 2201 1762 8f0a 0606 21a0 c363 0422 0117 628f 0f06
0x0623 0000 0aa0 d700 1400 2300 0000 0000 0000 8e0b 4738 15ee f894
0xa302 2342 46d9 6fd0 6875 77c6 0102 0304 0506 0708 090a  

I expect following results:

   Compressed message:     State item in compartment:     UDVM cycles:
        0x0006                        No                       11
        0x0106                        Yes                      21
        0x0206                        No                       12
        0x0200                        No, decompression fails
        0x0220                        No, decompression fails
        0x0306                        Yes                      22
        0x0406                        Yes                      22
        0x0506                        Yes                      32
        0x0606                        Yes                      23
        0x0614                        No                       23 
        0x0706                        Yes                      33                      
        0x0714                        Yes                      33

--Pekka