Request For Comments - RFC4465

Network Working Group A. Surtees
Request for Comments: 4465 M. West
Category: Informational Siemens/Roke Manor Research
June 2006
Signaling Compression (SigComp) Torture Tests
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document provides a set of "torture tests" for implementers of
the Signaling Compression (SigComp) protocol. The torture tests
check each of the SigComp Universal Decompressor Virtual Machine
instructions in turn, focusing in particular on the boundary and
error cases that are not generally encountered when running
well-behaved compression algorithms. Tests are also provided for
other SigComp entities such as the dispatcher and the state handler.
Surtees & West Informational [Page 1]

RFC 4465 SigComp Torture Tests June 2006
A.1.12. INPUT-BYTES .......................................58
A.1.13. Stack Manipulation ................................58
A.1.14. Program Flow ......................................59
A.1.15. State Creation ....................................59
A.1.16. STATE-ACCESS ......................................60
A.2. Dispatcher Tests ..........................................61
A.2.1. Useful Values ......................................61
A.2.2. Cycles Checking ...................................62
A.2.3. Message-based Transport ............................62
A.2.4. Stream-based Transport .............................62
A.2.5. Input Past the End of a Message ....................63
A.3. State Handler Tests .......................................64
A.3.1. SigComp Feedback Mechanism .........................64
A.3.2. State Memory Management ............................64
A.3.3. Multiple Compartments ..............................65
A.3.4. Accessing RFC 3485 State ...........................66
A.3.5. Bytecode State Creation ............................661. Introduction
This document provides a set of "torture tests" for implementers of
the SigComp protocol, RFC 3320 [2]. The idea behind SigComp is to
standardize a Universal Decompressor Virtual Machine (UDVM) that can
be programmed to understand the output of many well-known compressors
including DEFLATE and LZW. The bytecode for the chosen decompressor
is uploaded to the UDVM as part of the SigComp message flow.
The SigComp User's Guide [1] gives examples of a number of different
algorithms that can be used by the SigComp protocol. However, the
bytecode for the corresponding decompressors is relatively well
behaved and does not test the boundary and error cases that may
potentially be exploited by malicious SigComp messages.
This document is divided into a number of sections, each containing a
piece of code designed to test a particular function of one of the
SigComp entities (UDVM, dispatcher, and state handler). The specific
boundary and error cases tested by the bytecode are also listed, as
are the output the code should produce and the number of UDVM cycles
that should be used.
Each test runs in the SigComp minimum decompression memory size (that
is, 2K), within the minimum number of cycles per bit (that is, 16)
and in tests where state is stored 2K state memory size is needed.
Surtees & West Informational [Page 3]

RFC 4465 SigComp Torture Tests June 2006
2. Torture Tests for UDVM
The following sections each provide code to test one or more UDVM
instructions. In the interests of readability, the code is given
using the SigComp assembly language: a description of how to convert
this assembly code into UDVM bytecode can be found in the SigComp
User's Guide [1].
The raw UDVM bytecode for each torture test is given in Appendix A.
Each section also lists the number of UDVM cycles required to execute
the code. Note that this figure only takes into account the cost of
executing each UDVM instruction (in particular, it ignores the fact
that the UDVM can gain extra cycles as a result of inputting more
data).
2.1. Bit Manipulation
This section gives assembly code to test the AND, OR, NOT, LSHIFT,
and RSHIFT instructions. When the instructions have a multitype
operand, the code tests the case where the multitype contains a fixed
integer value, and the case where it contains a memory address at
which the 2-byte operand value can be found. In addition, the code
is designed to test that the following boundary cases have been
correctly implemented:
1. The instructions overwrite themselves with the result of the bit
manipulation operation, in which case execution continues
normally.
2. The LSHIFT or RSHIFT instructions shift bits beyond the 2-byte
boundary, in which case the bits must be discarded.
3. The UDVM registers byte_copy_left and byte_copy_right are used to
store the results of the bit manipulation operations. Since no
byte copying is taking place, these registers should behave in
exactly the same manner as ordinary UDVM memory addresses.
Surtees & West Informational [Page 4]

RFC 4465 SigComp Torture Tests June 2006
Consequently, execution of the 2nd MULTILOAD (and any remaining code)
gives the following:
Input Outcome
0x00 MULTILOAD reads and writes operand by operand. The output is
0x0084 0084 0086 0086 002a 0080 002a 002a, and the cost of
executing the code is 36 UDVM cycles.
0x01 The first write of the MULTILOAD instruction would overwrite
the last byte of the final MULTILOAD operand, so
decompression failure occurs.
0x02 The last write of the MULTILOAD would overwrite the MULTILOAD
opcode, so decompression failure occurs.
2.6. COPY
This section gives assembly code to test the COPY instruction. The
code is designed to test that the following boundary cases have been
correctly implemented:
1. The COPY instruction copies data from both outside the circular
buffer and inside the circular buffer within the same operation.
2. The COPY instruction performs byte-by-byte copying (i.e., some of
the later bytes to be copied are themselves written into the UDVM
memory by the COPY instruction currently being executed).
3. The COPY instruction overwrites itself and continues executing.
4. The COPY instruction overwrites the UDVM registers byte_copy_left
and byte_copy_right.
5. The COPY instruction writes to and reads from the right of the
buffer beginning at byte_copy_right.
6. The COPY instruction implements byte copying rules when the
destination wraps around the buffer.
at (64)
:byte_copy_left pad (2)
:byte_copy_right pad (2)
Surtees & West Informational [Page 11]

RFC 4465 SigComp Torture Tests June 2006
at (128)
; Set up buffer between addresses 64 & 128
LOAD (32, 16384)
LOAD (byte_copy_left, 64)
LOAD (byte_copy_right, 128)
COPY (32, 128, 33) ; Copy byte by byte starting to the left of
; the buffer, into the buffer and wrapping
; the buffer (inc overwriting the
; boundaries)
LOAD (64, 16640) ; Change the start of the buffer to be
; beyond bytecode
COPY (64, 85, 65) ; Copy to the left of the buffer,
; overwriting this instruction
OUTPUT (32, 119) ; Output 32 * 0x40 + 86 * 0x41 + 0x55,
; which is 32 * '@' + 86 'A' + 'U'
; Set a new small buffer
LOAD (byte_copy_left, 32)
LOAD (byte_copy_right, 48)
MEMSET (32, 4, 65, 1) ; Set first 4 bytes of the buffer to be
; 'ABCD'
COPY (32, 4, 48) ; Copy from byte_copy_right (i.e., not
; in buffer)
OUTPUT (48, 4) ; Output 0x4142 4344, which is 'ABCD'
COPY (48, 4, 46) ; Copy from two before byte_copy_right to
; wrap around the buffer
OUTPUT (32, 2) ; Output 0x4344, which is 'CD'
END-MESSAGE (0, 0, 0, 0, 0, 0, 0)
The output is above, and executing the code costs a total of 365 UDVM
cycles.
2.7. COPY-LITERAL and COPY-OFFSET
This section gives assembly code to test the COPY-LITERAL and COPY-
OFFSET instructions. The code is designed to test similar boundary
cases to the code for the COPY instruction, as well as the following
condition specific to COPY-LITERAL and COPY-OFFSET:
Surtees & West Informational [Page 12]

RFC 4465 SigComp Torture Tests June 2006
CRC ($crc_value, crc_string_a, 44, decompression_failure)
; computes the CRC value of the
; byte string crc_string_a
; concatenated with byte string
; crc_string_b (with a total
; length of 44 bytes).
; if the computed value does
; not match the 2-byte value read
; previously, the program ends
; with DECOMPRESSION-FAILURE.
END-MESSAGE (0, 0, 0, 0, 0, 0, 0)
:decompression_failure
DECOMPRESSION-FAILURE
If the compressed message is 0x62cb, then the code should
successfully terminate with no output, and with a total execution
cost of 95 UDVM cycles. For different 2-byte compressed messages,
the code should terminate with a decompression failure.
2.10. INPUT-BITS
This section gives assembly code to test the INPUT-BITS instruction.
The code is designed to test that the following boundary cases have
been correctly implemented:
1. The INPUT-BITS instruction changes between any of the four
possible bit orderings defined by the input_bit_order register.
2. The INPUT-BITS instruction inputs 0 bits.
3. The INPUT-BITS instruction requests data that lies beyond the end
of the compressed message.
at (64)
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:input_bit_order pad (2)
:result pad (2)
Surtees & West Informational [Page 16]

RFC 4465 SigComp Torture Tests June 2006
at (128)
:start
INPUT-BITS ($input_bit_order, result, end_of_message) ; reads in
; exactly as many bits as the 2-byte
; value written in the input_bit_order
; register, get out of the loop when
; no more bits are available at input.
OUTPUT (result, 2) ; outputs as a 2-byte integer
; the previously read bits
ADD ($input_bit_order, 1) ; if at the beginning of this loop the
; register input_bit_order is 0,
REMAINDER ($input_bit_order, 7) ; then its value varies periodically
; like this: 2, 4, 6, 1, 3, 5, 7.
ADD ($input_bit_order, 1) ; that gives for the FHP bits: 010,
; 100, 110, 001, 011, 101, 111
JUMP (start) ; run the loop once more
:end_of_message
END-MESSAGE (0, 0, 0, 0, 0, 0, 0)
An example of a compressed message is 0x932e ac71, which decompresses
to give the output 0x0000 0002 0002 0013 0000 0003 001a 0038.
Executing the code costs 66 UDVM cycles.
2.11. INPUT-HUFFMAN
This section gives assembly code to test the INPUT-HUFFMAN
instruction. The code is designed to test that the following
boundary cases have been correctly implemented:
1. The INPUT-HUFFMAN instruction changes between any of the four
possible bit orderings defined by the input_bit_order register.
2. The INPUT-HUFFMAN instruction inputs 0 bits.
3. The INPUT-HUFFMAN instruction requests data that lies beyond the
end of the compressed message.
Surtees & West Informational [Page 17]

RFC 4465 SigComp Torture Tests June 2006
create state_a2, which has a different identifier, but the first 6
bytes are the same as those of identifier1.
Message: Effect: # state items: #cycles:
0x01 create state_b 1 23
0x02 free (id1, 6) = state_b 0 14
0x03 free (id1, 6) = state_b; create state_b 1 24
0x0405 free (id1, 5) Decompression failure
0x0415 free (id1, 21) Decompression failure
0x0406 free (id1, 6) = state_b 0 23
0x09 create state_a; create state_b 1 34
0x1e06 create state_a2; create state_a;
free (id1, 6) = matches both so no free;
free (id1, 6) = matches both so no free; 2 46
0x1e07 create state_a2; create state_a;
free (id1, 7) = state_a;
free (id1, 6) = state_a2 0 47
0x1e14 create state_a2; create state_a;
free (id1, 20) = state_a;
free (id1, 6) = state_a2 0 60
2.16. STATE-ACCESS
This section gives assembly code to test the STATE-ACCESS
instruction. The code is designed to test that the following
boundary cases have been correctly implemented:
1. A subset of the bytes contained in a state item is copied to the
UDVM memory.
2. Bytes are copied from beyond the end of the state value.
3. The state_instruction operand is set to 0.
4. The state cannot be accessed because the partial state identifier
is too short.
5. The state identifier is overwritten by the state item being
accessed.
The following bytecode needs to be run first to set up the state for
the rest of the test.
Surtees & West Informational [Page 26]

RFC 4465 SigComp Torture Tests June 2006
COMPARE ($type, 3, state_not_found, id_too_short, state_too_short)
:state_not_found
STATE-ACCESS (128, 20, 0, 0, 0, 0)
JUMP (end)
:id_too_short
STATE-ACCESS (state_identifier, 19, 6, 4, state_value, 0)
JUMP (end)
:state_too_short
STATE-ACCESS (state_identifier, 20, 12, 5, state_value, 0)
JUMP (end)
at (484)
:end
END-MESSAGE (0, 0, 0, 0, 0, 0, 0)
at (512)
:state_identifier
byte (0x5d, 0xf8, 0xbc, 0x3e, 0x20, 0x93, 0xb5, 0xab, 0xe1, 0xf1,
0x70, 0x13, 0x42, 0x4c, 0xe7, 0xfe, 0x05, 0xe0, 0x69, 0x39)
If the compressed message is 0x00, then the output of the code is
0x7465 7374, and a total of 26 UDVM cycles are used. If the
compressed message is 0x01, then the output of the code is also
0x7465 7374 but in this case using a total of 15 UDVM cycles. If the
compressed message is 0x02, 0x03, or 0x04, then decompression failure
occurs.
3. Torture Tests for Dispatcher
The following sections give code to test the various functions of the
SigComp dispatcher.
3.1. Useful Values
This section gives assembly code to test that the SigComp "Useful
Values" are correctly initialized in the UDVM memory. It also tests
that the UDVM is correctly terminated if the bytecode uses too many
UDVM cycles or tries to write beyond the end of the available memory.
Surtees & West Informational [Page 28]

RFC 4465 SigComp Torture Tests June 2006
The code tests that the following boundary cases have been correctly
implemented:
1. The bytecode uses exactly as many UDVM cycles as are available
(in which case no problems should arise) or one cycle too many
(in which case decompression failure should occur). A liberal
implementation could allow more cycles to be used than are
strictly available, in which case decompression failure will not
occur. This is an implementation choice. If this choice is
made, the implementer must be sure that the cycles are checked
eventually and that decompression failure does occur when
bytecode uses an excessive number of cycles. This is tested in
Section 3.2.
2. The bytecode writes to the highest memory address available (in
which case no problems should arise) or to the memory address
immediately following the highest available address (in which
case decompression failure must occur).
:udvm_memory_size pad (2)
:cycles_per_bit pad (2)
:sigcomp_version pad (2)
:partial_state_id_length pad (2)
:state_length pad (2)
at (64)
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:remaining_cycles pad (2)
:check_memory pad (1)
:check_memory_lsb pad (1)
:check_cycles pad (1)
:check_cycles_lsb pad (1)
at (127)
:decompression_failure
at (128)
; Set up a 1-byte buffer
LOAD (byte_copy_left, 32)
LOAD (byte_copy_right, 33)
:test_version
; Input a byte containing the version of SigComp being run
INPUT-BYTES (1, check_memory_lsb, decompression_failure)
COMPARE ($sigcomp_version, $check_memory, decompression_failure,
test_state_access, decompression_failure)
Surtees & West Informational [Page 29]

RFC 4465 SigComp Torture Tests June 2006
SUBTRACT ($remaining_cycles, cycles_used_by_bytecode)
COPY (32, $remaining_cycles, 32)
; Copy to use up all cycles available + input byte
; Succeeds when input byte = 0x00
; Fail when input byte = 0x01
:end
; Create 960 bytes of state for future
; reference
END-MESSAGE (0, 0, 960, 64, 128, 6, 0)
The bytecode must be executed a total of four times in order to fully
test the SigComp Useful Values. In the first case, the bytecode is
uploaded as part of the SigComp message with a 1-byte compressed
message corresponding to the version of SigComp being run. This
causes the UDVM to request creation of a new state item and uses a
total of 968 UDVM cycles.
Subsequent tests access this state by uploading the state identifier
as part of the SigComp message. Note that the SigComp message should
not contain a returned feedback item (as this would cause the
bytecode to calculate the total number of available UDVM cycles
incorrectly).
A 3-byte compressed message is required for the second and subsequent
cases, the first byte of which is the version of SigComp in use,
0xnn. If the message is 0xnn0000, then the UDVM should successfully
terminate using exactly the number of available UDVM cycles.
However, if the message is 0xnn0001, then the UDVM should use too
many cycles and hence terminate with decompression failure.
Furthermore, if the message is 0xnn0100, then decompression failure
must occur because the UDVM attempts to write beyond its available
memory.
3.2. Cycles Checking
As discussed in Section 3.1, it is possible to write an
implementation that takes a liberal approach to checking the cycles
used and allows some extra cycles. The implementer must be sure that
decompression failure does not occur too early and that in the case
of excessive use of cycles, decompression failure does eventually
occur. This test checks that:
1. Decompression failure occurs eventually when there is an infinite
loop.
Surtees & West Informational [Page 31]

RFC 4465 SigComp Torture Tests June 2006
at (64)
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:value pad (2)
:copy_next pad (2)
at(128)
MULTILOAD (byte_copy_left, 4, 32, 41, 0, 34)
; Set up a 10-byte buffer
; Set the value to copy
; Copy it 100 times,
; output the value,
; increment the counter
:loop
COPY (value, 2, $byte_copy_left)
COPY-OFFSET (2, 100, $copy_next)
OUTPUT (value, 2)
ADD ($value, 1)
JUMP (loop)
If the cycles are counted exactly and cycles per bit (cpb) = 16, then
decompression failure will occur at COPY-OFFSET when value = 180 =
0xB4. If cpb = 32, then decompression failure will occur when value
= 361 = 0x0169. If they are not counted exactly, then decompression
failure MUST occur eventually.
3.3. Message-based Transport
This section provides a set of messages to test the SigComp header
over a message-based transport such as UDP. The messages test that
the following boundary cases have been correctly implemented:
1. The UDVM bytecode is copied to different areas of the UDVM
memory.
2. The decompression memory size is set to an incorrect value.
3. The SigComp message is too short.
4. The destination address is invalid.
The basic version of the code used in the test is given below. Note
that the code is designed to calculate the decompression memory size
based on the Useful Values provided to the UDVM:
Surtees & West Informational [Page 32]

RFC 4465 SigComp Torture Tests June 2006
The messages should be decompressed in the order given to check that
an error in one message does not interfere with the successful
decompression of subsequent messages.
The two messages that successfully decompress each use a total of 5
UDVM cycles.
3.4. Stream-based Transport
This section provides a byte stream to test the SigComp header and
delimiters over a stream-based transport such as TCP. The byte
stream tests all of the boundary cases covered in Section 3.2, as
well as the following cases specific to stream-based transports:
1. Quoted bytes are used by the record marking scheme.
2. Multiple delimiters are used between the same pair of messages.
3. Unnecessary delimiters are included at the start of the stream.
The basic version of the code used in the test is given below. Note
that the code is designed to calculate the decompression memory size
based on the Useful Values provided to the UDVM:
:udvm_memory_size pad (2)
:cycles_per_bit pad (2)
:sigcomp_version pad (2)
:partial_state_id_length pad (2)
:state_length pad (2)
at (128)
; udvm_memory_size for stream based transport = DMS / 2
MULTIPLY ($udvm_memory_size, 2)
OUTPUT (udvm_memory_size, 2)
OUTPUT (test_record_marking, 5)
END-MESSAGE (0, 0, 0, 0, 0, 0, 0)
:test_record_marking
byte (255, 255, 255, 255, 255)
Surtees & West Informational [Page 34]

RFC 4465 SigComp Torture Tests June 2006
3.5.Input Past the End of a Message
This section gives assembly code to test that the implementation
correctly handles input past the end of a SigComp message. The code
is designed to test that the following boundary cases have been
correctly implemented:
1. An INPUT instruction requests data that lies beyond the end of
the message. In this case, the dispatcher should not return any
data to the UDVM. Moreover, the message bytes held by the
dispatcher should still be available for retrieval by subsequent
INPUT instructions.
2. The INPUT-BYTES instruction is used after part of a byte has been
input (e.g., by the INPUT-BITS instruction). In this case, the
remaining partial byte must be discarded, even if the INPUT-BYTES
instruction requests data that lies beyond the end of the
message.
at (64)
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:input_bit_order pad (2)
:result pad (1)
:result_lsb pad (6)
:right
at (128)
LOAD (byte_copy_left, result)
LOAD (byte_copy_right, right)
:start
; Input bits to ensure that the remaining message is not byte aligned
INPUT-BITS (9, result, decompression_failure1) ; Input 0x1FF (9 bits)
; Attempt to read 7 bytes
Surtees & West Informational [Page 36]

RFC 4465 SigComp Torture Tests June 2006
When the above code is executed, it supplies a requested feedback
item to the state handler. If the compressed message is 0x00, then
the short (1-byte) version of the feedback is used. Executing the
bytecode in this case costs a total of 52 UDVM cycles. Assuming that
the feedback request is successful, the feedback item should be
returned in the first SigComp message to be sent in the reverse
direction. The SigComp message returning the feedback should begin
as follows:
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 | X | first header byte
+---+---+---+---+---+---+---+---+
| 0 | 127 | returned feedback field
+---+---+---+---+---+---+---+---+
So the first 2 bytes of the returning SigComp message should be
0xfn7f where n = c, d, e, or f (the choice of n is determined by the
compressor generating the returning SigComp message, which is not
under the control of the above code).
If the compressed message is 0x01, then the long version of the
feedback item is used. Executing the bytecode in this case costs a
total of 179 UDVM cycles and the SigComp message returning the
feedback should begin as follows:
+---+---+---+---+---+---+---+---+
| 1 1 1 1 1 1 | X | first header byte
+---+---+---+---+---+---+---+---+
| 1 | 127 | returned feedback length
+---+---+---+---+---+---+---+---+
| 1 | ^
+---+---+---+---+---+---+---+---+ |
| 2 | |
+---+---+---+---+---+---+---+---+
| 3 | returned feedback field
+---+---+---+---+---+---+---+---+
So the first 129 bytes of the SigComp message should be 0xfnff 0102
0304 ... 7e7f where n = c, d, e, or f as above.
As well as testing the requested and returned feedback items, the
above code also announces values for each of the SigComp parameters.
The supplied version of the code announces only the minimum possible
values for the cycles_per_bit, decompression_memory_size,
state_memory_size, and SigComp_version (although this can easily be
adjusted to test different values for these parameters).
Surtees & West Informational [Page 40]

RFC 4465 SigComp Torture Tests June 2006
The code should also announce the availability of state items with
the following partial state identifiers:
0x0001 0203 0405
0x0001 0203 0405 0607 0809 0a0b
0x0001 0203 0405 0607 0809 0a0b 0c0d 0e0f 1011 1213
Note that different implementations may make use of the announcement
information in different ways. It is a valid implementation choice
to simply ignore all of the announcement data and use only the
minimum resources that are guaranteed to be available to all
endpoints. However, the above code is useful for checking that an
endpoint interprets the announcement data correctly (in particular
ensuring that it does not mistakenly use resources that have not in
fact been announced).
4.2. State Memory Management
The following section gives assembly code to test the memory
management features of the state handler. The code checks that the
correct states are retained by the state handler when insufficient
memory is available to store all of the requested states.
The code is designed to test that the following boundary cases have
been correctly implemented:
1. A state item is created that exceeds the total state_memory_size
for the compartment.
2. States are created with a non-zero state_retention_priority.
3. A new state item is created that has a lower
state_retention_priority than existing state items in the
compartment.
For the duration of this test, it is assumed that all states will be
saved in a single compartment with a state_memory_size of 2048 bytes.
at (64)
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:order pad (2)
:type pad (1)
:type_lsb pad (1)
:state_length pad (2)
:state_retention_priority pad (2)
Surtees & West Informational [Page 41]

RFC 4465 SigComp Torture Tests June 2006
:state_identifier_d
byte (180, 15, 192, 228, 77, 44)
:state_identifier_e
byte (212, 162, 33, 71, 230, 10)
:large_state_identifier
byte (239, 242, 188, 15, 182, 175)
The above code must be executed a total of 7 times in order to
complete the test. Each time the code is executed, a 1-byte
compressed message should be provided as below. The effects of the
messages are given below. States are described in the form (name, x,
y) where name corresponds to the name of the identifier in the
mnemonic code, x is the length of the state, and y is the retention
priority of the state.
Message: Effect: #cycles:
0x00 create states: 811
(a,0,0),
(b,256,1),
(c,512,2)
0x01 create states: 2603
(d,768,3),
(e,1024,4) - deleting a, b, c
0x02 create states: 811
(c,512,2), - deleting d
(b,256,1),
(a,0,0)
0x03 access states a,b,c,e 1805
0x04 access state d - not present so decompression failure
0x05 create states: 2057
(large, 2048,0) - deleting a, b, c, e
0x06 access large state 1993
Note that as new states are created, some of the existing states will
be pushed out of the compartment due to lack of memory.
4.3. Multiple Compartments
This section gives assembly code to test the interaction between
multiple SigComp compartments. The code is designed to test that the
following boundary cases have been correctly implemented:
Surtees & West Informational [Page 44]

RFC 4465 SigComp Torture Tests June 2006
1. The same state item is saved in more than one compartment.
2. A state item stored in multiple compartments has the same state
identifier but a different state_retention_priority in each case.
3. A state item is deleted from one compartment but still belongs to
a different compartment.
4. A state item belonging to multiple compartments is deleted from
every compartment to which it belongs.
The test requires a total of three compartments to be available,
which will be referred to as Compartment 0, Compartment 1, and
Compartment 2. Each of the three compartments should have a
state_memory_size of 2048 bytes.
The assembly code for the test is given below:
at (64)
:byte_copy_left pad (2)
:byte_copy_right pad (2)
:type pad (1)
:type_lsb pad (1)
at (127)
:decompression_failure
at (128)
MULTILOAD (byte_copy_left, 2, state_start, state_end)
INPUT-BYTES (1, type_lsb, decompression_failure)
COMPARE ($type, 3, create_state, overwrite_state, temp)
:temp
COMPARE ($type, 5, overwrite_state, access_state, error_conditions)
:create_state
; starting byte identified by $type according to input:
; Input 0x00 0x01 0x02
; $type 512 513 514
ADD ($type, state_start)
STATE-CREATE (448, $type, 0, 6, 0)
; create state again, beginning in different place in buffer
; starting byte identified by $type according to input:
; Input 0x00 0x01 0x02
Surtees & West Informational [Page 45]

RFC 4465 SigComp Torture Tests June 2006
The above code must be executed a total of 9 times in order to
complete the test. Each time the code is executed, a 1-byte
compressed message N should be provided, taking the values 0x00 to
0x08 in ascending order (so the compressed message should be 0x00 the
first time the code is run, 0x01 the second, and so on).
If the code makes a state creation request, then the state must be
saved in Compartment (N modulo 3).
When the compressed message is 0x00, 0x01, or 0x02, the code makes
four state creation requests in compartments 0, 1, and 2,
respectively. This creates a total of seven distinct state items
referred to as State a through State g. The states should be
distributed among the three compartments as illustrated in Figure 1
(note that some states belong to more than one compartment).
When the compressed message is 0x03 or 0x04, the code overwrites all
of the states in Compartments 0 and 1, respectively. This means that
States a, b, and e will be unavailable because they are no longer
present in any of the three compartments.
When the compressed message is 0x05, the code checks that the States
c, d, f, and g are still available. Decompression should terminate
successfully in this case.
When the compressed message is 0x06, 0x07, or 0x08, the code attempts
to access States a, b, and e, respectively. Decompression failure
should occur in this case because the relevant states are no longer
available.
The cost in UDVM cycles for each compressed message is given below
(except for messages 0x06, 0x07, and 0x08 where decompression failure
should to occur):
Compressed message: 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08
Cost in UDVM cycles: 1809 1809 1809 1993 1994 1804 N/A N/A N/A
Surtees & West Informational [Page 48]

RFC 4465 SigComp Torture Tests June 2006
at (128)
STATE-ACCESS (sip_dictionary, 20, 0xcfe, 1, input, 0)
STATE-ACCESS (sip_dictionary, 6, 0xcff, 1, input2, 0)
STATE-ACCESS (sip_dictionary, 12, 0xd00, 1, input3, 0)
OUTPUT (input, 3)
END-MESSAGE (0, 0, 0, 0, 0, 0, 0)
:sip_dictionary
byte (0xfb, 0xe5, 0x07, 0xdf, 0xe5, 0xe6)
byte (0xaa, 0x5a, 0xf2, 0xab, 0xb9, 0x14)
byte (0xce, 0xaa, 0x05, 0xf9, 0x9c, 0xe6)
byte (0x1b, 0xa5)
The output of the code is 0x5349 50, and the cost is 11 UDVM cycles.
4.5. Bytecode State Creation
This section gives assembly code to test storing bytecode using
END-MESSAGE and later loading the bytecode using a partial state
identifier within the SigComp header. The assembly code is designed
to test the following cases:
1. The bytes to be saved are changed after the state create request
has been made.
2. The uploaded bytecode is modified before execution.
3. The bytecode is loaded using the partial state identifier and is
modified before execution.
4. The bytecode is loaded to an address lower than 128, using the
partial state identifier.
5. The bytecode is loaded using the partial state identifier. Part
of the loaded memory is reserved area, which is overwritten after
loading the bytecode.
6. The loading of the bytecode fails because the partial state
identifier is too short.
Surtees & West Informational [Page 50]

RFC 4465 SigComp Torture Tests June 2006
Appendix A. UDVM Bytecode for the Torture Tests
The following sections list the raw UDVM bytecode generated for each
test. The bytecode is presented in the form of a complete SigComp
message, including the appropriate header. It is followed by input
messages, the output they produce, and where the decompression
succeeds the number of cycles used.
In some cases, the test is designed to be run several times with
different compressed messages appended to the code. In the cases
where multiple whole messages are used for a test, e.g.,
Appendix A.2.3, these are supplied. In the case where decompression
failure occurs, the high-level reason for it is given as a reason
code defined in NACK [4].
Note that the different assemblers can output different bytecode for
the same piece of assembly code, so a valid assembler can produce
results different from those presented below. However, the following
bytecode should always generate the same results on any UDVM.
A.1. Instructions
A.1.1. Bit Manipulation
0xf80a 7116 a07f 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000
0x01c0 00ff 8055 5502 202a 0321 0420 0305 21ff 2286 0401 20c0 ff02
0x2060 0320 0421 6005 2061 2286 0423
Input: None
Output: 0x0150 0000 febf 0000
Cycles: 22
Surtees & West Informational [Page 54]

RFC 4465 SigComp Torture Tests June 2006
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
Surtees & West Informational [Page 68]