diff options
Diffstat (limited to 'doc/rfc/rfc4465.txt')
-rw-r--r-- | doc/rfc/rfc4465.txt | 3811 |
1 files changed, 3811 insertions, 0 deletions
diff --git a/doc/rfc/rfc4465.txt b/doc/rfc/rfc4465.txt new file mode 100644 index 0000000..1ec31bb --- /dev/null +++ b/doc/rfc/rfc4465.txt @@ -0,0 +1,3811 @@ + + + + + + +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 + + +Table of Contents + + 1. Introduction ....................................................3 + 2. Torture Tests for UDVM ..........................................4 + 2.1. Bit Manipulation ...........................................4 + 2.2. Arithmetic .................................................5 + 2.3. Sorting ....................................................7 + 2.4. SHA-1 ......................................................8 + 2.5. LOAD and MULTILOAD .........................................9 + 2.6. COPY ......................................................11 + 2.7. COPY-LITERAL and COPY-OFFSET ..............................12 + 2.8. MEMSET ....................................................14 + 2.9. CRC .......................................................15 + 2.10. INPUT-BITS ...............................................16 + 2.11. INPUT-HUFFMAN ............................................17 + 2.12. INPUT-BYTES ..............................................19 + 2.13. Stack Manipulation .......................................20 + 2.14. Program Flow .............................................22 + 2.15. State Creation ...........................................23 + 2.16. STATE-ACCESS .............................................26 + 3. Torture Tests for Dispatcher ...................................28 + 3.1. Useful Values .............................................28 + 3.2. Cycles Checking ...........................................31 + 3.3. Message-based Transport ...................................32 + 3.4. Stream-based Transport ....................................34 + 3.5. Input Past the End of a Message ...........................36 + 4. Torture Tests for State Handler ................................38 + 4.1. SigComp Feedback Mechanism ................................38 + 4.2. State Memory Management ...................................41 + 4.3. Multiple Compartments .....................................44 + 4.4. Accessing RFC 3485 State ..................................49 + 4.5. Bytecode State Creation ...................................50 + 5. Security Considerations ........................................53 + 6. Acknowledgements ...............................................53 + 7. Normative References ...........................................53 + Appendix A. UDVM Bytecode for the Torture Tests ..................54 + A.1. Instructions ..............................................54 + A.1.1. Bit Manipulation ...................................54 + A.1.2. Arithmetic .........................................55 + A.1.3. Sorting ............................................55 + A.1.4. SHA-1 ..............................................56 + A.1.5. LOAD and MULTILOAD .................................56 + A.1.6. COPY ...............................................56 + A.1.7. COPY-LITERAL and COPY-OFFSET .......................57 + A.1.8. MEMSET .............................................57 + A.1.9. CRC ................................................57 + A.1.10. INPUT-BITS ........................................57 + A.1.11. INPUT-HUFFMAN .....................................58 + + + +Surtees & West Informational [Page 2] + +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 ............................66 + +1. 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 + + + at (64) + + :a pad (2) + :b pad (2) + + at (128) + + JUMP (start) ; Jump to address 255 + + at (255) + + :start + + ; The multitypes are values + ; $start = 448 (first 2 bytes of AND instr) + AND ($start, 21845) ; 448 & 21845 = 320 = 0x0140 + OR ($a, 42) ; 0 | 42 = 42 = 0x002a + NOT ($b) ; ~0 = 65535 = 0xffff + LSHIFT ($a, 3) ; 42 << 3 = 336 = 0x0150 + RSHIFT ($b, 65535) ; 65535 >> 65535 = 0 = 0x0000 + + OUTPUT (64, 4) ; Output 0x0150 0000 + + ; The multitypes are references + + AND ($a, $start) ; 336 & 320 = 320 = 0x0140 + OR ($a, $a) ; 320 | 320 = 320 = 0x0140 + NOT ($a) ; ~320 = 65215 = 0xfebf + LSHIFT ($b, $a) ; 0 << 65215 = 0 = 0x0000 + RSHIFT ($a, $b) ; 65215 >> 0 = 65215 = 0xfebf + + OUTPUT (64, 4) ; Output 0xfebf 0000 + + END-MESSAGE (0, 0, 0, 0, 0, 0, 0) + + The output of the code is 0x0150 0000 febf 0000. Executing the code + costs a total of 22 UDVM cycles. + +2.2. Arithmetic + + This section gives assembly code to test the ADD, SUBTRACT, MULTIPLY, + DIVIDE, and REMAINDER instructions. 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 + arithmetic operation, resulting in continuation as if the bytes + were not bytecode. + + + + +Surtees & West Informational [Page 5] + +RFC 4465 SigComp Torture Tests June 2006 + + + 2. The result does not lie between 0 and 2^16 - 1 inclusive, in + which case it must be taken modulo 2^16. + + 3. The divisor in the DIVIDE or REMAINDER instructions is 0 (in + which case decompression failure must occur). + + at (64) + + :a pad (2) + :b pad (2) + :type pad (1) + :type_lsb pad (1) + + at (128) + + INPUT-BYTES (1, type_lsb, decomp_failure) + SUBTRACT ($type, 1) + JUMP (start) + :decomp_failure + DECOMPRESSION-FAILURE + + ; Now the value in $type should be 0xffff, 0x0000, or 0x0001 + ; according to whether the input was 0x00, 0x01, or 0x02. + + at (255) + + :start + + ; The multitypes are values + ; For all three messages + ; $start = 1728 (first 2 bytes of ADD instr) + ADD ($start, 63809) ; 1728 + 63809 = 1 = 0x0001 + SUBTRACT ($a, 1) ; 0 - 1 = 65535 = 0xffff + MULTIPLY ($a, 1001) ; 65535 * 1001 = 64535 = 0xfc17 + DIVIDE ($a, 101) ; 64535 / 101 = 638 = 0x027e + REMAINDER ($a, 11) ; 638 % 11 = 0 = 0x0000 + + OUTPUT (64, 4) ; output 0x0000 0000 + + ; The multitypes are references + ADD ($b, $start) ; 0 + 1 = 1 = 0x0001 + ; If the message is 0x00 + SUBTRACT ($b, $type) ; 1 - 65535 = 2 = 0x0002 + MULTIPLY ($b, $b) ; 2 * 2 = 4 = 0x0004 + DIVIDE ($a, $b) ; 0 / 4 = 0 = 0x0000 + REMAINDER ($b, $type) ; 4 % 65535 = 4 = 0x0004 + + + + + +Surtees & West Informational [Page 6] + +RFC 4465 SigComp Torture Tests June 2006 + + + OUTPUT (64, 4) ; output 0x0000 0004 + + ; If the message is 0x01, $type = 0 + ; so decompression failure occurs at + ; REMAINDER ($b, $type) + + ; If the message is 0x02, $type = 1 so + ; $b becomes 0 and decompression failure + ; occurs at DIVIDE ($a, $b) + + END-MESSAGE (0, 0, 0, 0, 0, 0, 0) + + If the compressed message is 0x00, then the output of the code is + 0x0000 0000 0000 0004 and the execution cost should be 25 UDVM + cycles. However, if the compressed message is 0x01 or 0x02, then + decompression failure occurs. + +2.3. Sorting + + This section gives assembly code to test the SORT-ASCENDING and SORT- + DESCENDING instructions. The code is designed to test that the + following boundary cases have been correctly implemented: + + 1. The sorting instructions sort integers with the same value, in + which case the original ordering of the integers must be + preserved. + + at (128) + + SORT-DESCENDING (256, 2, 23) + SORT-ASCENDING (256, 2, 23) + + OUTPUT (302, 45) + END-MESSAGE (0, 0, 0, 0, 0, 0, 0) + + at (256) + + word (10, 10, 17, 7, 22, 3, 3, 3, 19, 1, 16, 14, 8, 2, 13, 20, 18, + 23, 15, 21, 12, 6, 9) + + word (28263, 8297, 30057, 8308, 26996, 11296, 31087, 29991, 8275, + 18031, 28263, 24864, 30066, 29284, 28448, 29807, 28206, 11776, 28773, + 28704, 28276, 29285, 28265) + + The output of the code is 0x466f 7264 2c20 796f 7527 7265 2074 7572 + 6e69 6e67 2069 6e74 6f20 6120 7065 6e67 7569 6e2e 2053 746f 7020 6974 + 2e, and the number of cycles required is 371. + + + + +Surtees & West Informational [Page 7] + +RFC 4465 SigComp Torture Tests June 2006 + + +2.4. SHA-1 + + This section gives assembly code to test the SHA-1 instruction. The + code performs four tests on the SHA-1 algorithm itself and, in + addition, checks the following boundary cases specific to the UDVM: + + 1. The input string for the SHA-1 hash is obtained by byte copying + over an area of the UDVM memory. + + 2. The SHA-1 hash overwrites its own input string. + + at (64) + + :byte_copy_left pad (2) + :byte_copy_right pad (2) + :hash_value pad (20) + + at (128) + + SHA-1 (test_one, 3, hash_value) + OUTPUT (hash_value, 20) + + SHA-1 (test_two, 56, hash_value) + OUTPUT (hash_value, 20) + + ; Set up a 1-byte buffer + LOAD (byte_copy_left, test_three) + LOAD (byte_copy_right, test_four) + + ; Perform SHA-1 over 16384 bytes in a 1-byte buffer + SHA-1 (test_three, 16384, hash_value) + OUTPUT (hash_value, 20) + + ; Set up an 8-byte buffer + LOAD (byte_copy_left, test_four) + LOAD (byte_copy_right, test_end) + + ; Perform SHA-1 over 640 bytes in an 8-byte buffer + SHA-1 (test_four, 640, test_four) + OUTPUT (test_four, 20) + + END-MESSAGE (0, 0, 0, 0, 0, 0, 0) + + :test_one + + byte (97, 98, 99) + + :test_two + + + +Surtees & West Informational [Page 8] + +RFC 4465 SigComp Torture Tests June 2006 + + + byte (97, 98, 99, 100, 98, 99, 100, 101, 99, 100, 101, 102, 100, 101, + 102, 103, 101, 102, 103, 104, 102, 103, 104, 105, 103, 104, 105, 106, + 104, 105, 106, 107, 105, 106, 107, 108, 106, 107, 108, 109, 107, 108, + 109, 110, 108, 109, 110, 111, 109, 110, 111, 112, 110, 111, 112, 113) + + :test_three + + byte (97) + + :test_four + + byte (48, 49, 50, 51, 52, 53, 54, 55) + + :test_end + + The output of the code is as follows: + + 0xa999 3e36 4706 816a ba3e 2571 7850 c26c 9cd0 d89d + 0x8498 3e44 1c3b d26e baae 4aa1 f951 29e5 e546 70f1 + 0x12ff 347b 4f27 d69e 1f32 8e6f 4b55 73e3 666e 122f + 0x4f46 0452 ebb5 6393 4f46 0452 ebb5 6393 4f46 0452 + + Executing the code costs a total of 17176 UDVM cycles. + +2.5. LOAD and MULTILOAD + + This section gives assembly code to test the LOAD and MULTILOAD + instructions. The code is designed to test the following boundary + cases: + + 1. The MULTILOAD instruction overwrites itself or any of its + operands, in which case decompression failure occurs. + + 2. The memory references of MULTILOAD instruction operands are + evaluated step-by-step rather than all at once before starting to + copy data. + + at (64) + + :start pad (1) + :start_lsb pad (1) + + at (128) + + set (location_a, 128) + set (location_b, 132) + + + + + +Surtees & West Informational [Page 9] + +RFC 4465 SigComp Torture Tests June 2006 + + + LOAD (128, 132) ; address 128 contains 132 = 0x0084 + LOAD (130, $location_a) ; address 130 contains 132 = 0x0084 + LOAD ($location_a, 134) ; address 132 contains 134 = 0x0086 + LOAD ($location_b, $location_b) ; address 134 contains 134 = 0x0086 + OUTPUT (128, 8) ; output 0x0084 0084 0086 0086 + + INPUT-BYTES (1, start_lsb, decompression_failure) + MULTIPLY ($start, 2) + ADD ($start, 60) + MULTILOAD ($start, 3, overlap_start, overlap_end, 128) + + :position + + set (overlap_start, (position - 7)) + + MULTILOAD ($start, 4, 42, 128, $location_a, $location_b) + + :end + + set (overlap_end, (end - 1)) + + OUTPUT (128, 8) + END-MESSAGE (0, 0, 0, 0, 0, 0, 0) + + :decompression_failure + DECOMPRESSION-FAILURE + + The INPUT-BYTES, MULTIPLY, and ADD instructions give the following + values for $start = $64 just before the MULTILOADs begin: + + Input $start before 1st MULTILOAD + 0x00 60 + 0x01 62 + 0x02 64 + + Consequently, after the first MULTILOAD the values of $start are the + following: + + Input $start before 2nd MULTILOAD + 0x00 128 + 0x01 overlap_end = 177 = last byte of 2nd MULTILOAD instruction + 0x02 overlap_start = 162 = 7 bytes before 2nd MULTILOAD + instruction + + + + + + + + +Surtees & West Informational [Page 10] + +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 + + + 1. The COPY-LITERAL or COPY-OFFSET instruction overwrites the value + of its destination. + + 2. The COPY-OFFSET instruction reads from an offset that wraps + around the buffer (i.e., the offset is larger than the distance + between byte_copy_left and the destination). + + at (64) + + :byte_copy_left pad (2) + :byte_copy_right pad (2) + :destination pad (2) + :offset pad (2) + + at (128) + ; Set up circular buffer, source, and + ; destination + LOAD (32, 16640) + LOAD (byte_copy_left, 64) + LOAD (byte_copy_right, 128) + LOAD (destination, 33) + + COPY-LITERAL (32, 128, $destination) ; Copy from the left of the + ; buffer overwriting bcl, bcr, and + ; destination wrapping around the buffer + OUTPUT (64, 8) ; Check destination has been updated + ; Output 0x4141 4141 0061 4141 + + LOAD (destination, copy) + + :copy ; Overwrite the copy instruction + COPY-LITERAL (32, 2, $destination) + OUTPUT (copy, 2) ; Output 0x4141 + + LOAD (byte_copy_left, 72) ; Set up new circular buffer + LOAD (byte_copy_right, 82) + LOAD (destination, 82) ; Set destination to byte_copy_right + + MEMSET (72, 10, 65, 1) ; Fill the buffer with 0x41 - 4A + + COPY-OFFSET (2, 6, $destination) ; Copy from within circular + ; buffer to outside buffer + + LOAD (offset, 6) + COPY-OFFSET ($offset, 4, $destination) + ; Copy from byte_copy_right + ; so reading outside buffer + + + + +Surtees & West Informational [Page 13] + +RFC 4465 SigComp Torture Tests June 2006 + + + OUTPUT ($byte_copy_right, 10) ; Output 0x494A 4142 4344 494A 4142, + ; which is 'IJABCDIJAB' + LOAD (destination, 80) ; Put destination within the + ; buffer + COPY-OFFSET (4, 4, $destination) ; Copy where destination wraps + OUTPUT (destination, 2) ; Output 0x004A + + COPY-OFFSET (5, 4, $destination) ; Copy where offset wraps from + ; left back around to the right + OUTPUT (destination, 2) ; Output 0x004E + OUTPUT ($byte_copy_left, 10) ; Output the circular buffer + ; 0x4748 4845 4647 4748 4546, + ; which is 'GHHEFGGHEF' + + END-MESSAGE (0, 0, 0, 0, 0, 0, 0) + + The output of the code is above, and the cost of execution is 216 + UDVM cycles. + +2.8. MEMSET + + This section gives assembly code to test the MEMSET instruction. The + code is designed to test that the following boundary cases have been + correctly implemented: + + 1. The MEMSET instruction overwrites the registers byte_copy_left + and byte_copy_right. + + 2. The output values of the MEMSET instruction do not lie between 0 + and 255 inclusive (in which case they must be taken modulo 2^8). + + at (64) + + :byte_copy_left pad (2) + :byte_copy_right pad (2) + + at (128) + + LOAD (byte_copy_left, 128) ; sets up a circular buffer + LOAD (byte_copy_right, 129) ; of 1 byte between 0x0080 and 0x0081 + + MEMSET (64, 129, 0, 1) ; fills up the memory in the range + ; 0x0040-0x007f with 0x00, ... 0x3f; + ; then it writes successively at + ; 0x0080 the following values 0x40, ... 0x80 + ; as a side effect, the values of + ; bcl and bcr are modified. + + + + +Surtees & West Informational [Page 14] + +RFC 4465 SigComp Torture Tests June 2006 + + + ; before and during the MEMSET: + ; byte_copy_left: 0x0080 byte_copy_right: 0x0081 + ; after the MEMSET: + ; byte_copy_left: 0x0001 byte_copy_right: 0x0203 + + MEMSET (129, 15, 64, 15) ; fills the memory range 0x0080-0x008f + ; with values 0x40, 0x4f, ... 0xf4, 0x03, 0x12. + ; as a side effect, it overwrites a + ; part of the code including itself + + OUTPUT (128, 16) ; outputs 0x8040 4f5e 6d7c 8b9a + ; a9b8 c7d6 e5f4 0312 + + END-MESSAGE (0, 0, 0, 0, 0, 0, 0) + + The output of the code is 0x8040 4f5e 6d7c 8b9a a9b8 c7d6 e5f4 0312. + Executing the code costs 166 UDVM cycles. + +2.9. CRC + + This section gives assembly code to test the CRC instruction. The + code does not test any specific boundary cases (as there do not + appear to be any) but focuses instead on verifying the CRC algorithm. + + at (64) + + :byte_copy_left pad (2) + :byte_copy_right pad (2) + :crc_value pad (2) + :crc_string_a pad (24) + :crc_string_b pad (20) + + at (128) + + MEMSET (crc_string_a, 24, 1, 1) ; sets up between 0x0046 and 0x005d + ; a byte string containing 0x01, + ; 0x02, ... 0x18 + + MEMSET (crc_string_b, 20, 128, 1) ; sets up between 0x005e and 0x0071 + ; a byte string containing 0x80, + ; 0x81, ... 0x93 + + INPUT-BYTES (2, crc_value, decompression_failure) + ; reads in 2 bytes representing + ; the CRC value of the byte string + ; of 44 bytes starting at 0x0046 + + + + + +Surtees & West Informational [Page 15] + +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 + + + at (64) + + :byte_copy_left pad (2) + :byte_copy_right pad (2) + :input_bit_order pad (2) + :result pad (2) + + at (128) + + :start + + INPUT-HUFFMAN (result, end_of_message, 2, $input_bit_order, 0, + $input_bit_order, $input_bit_order, $input_bit_order, 0, 65535, 0) + OUTPUT (result, 2) + + ADD ($input_bit_order, 1) + REMAINDER ($input_bit_order, 7) + ADD ($input_bit_order, 1) + + JUMP (start) + + :end_of_message + + END-MESSAGE (0, 0, 0, 0, 0, 0, 0) + + An example of a compressed message is 0x932e ac71 66d8 6f, which + decompresses to give the output 0x0000 0003 0008 04d7 0002 0003 0399 + 30fe. Executing the code costs 84 UDVM cycles. + + As the code is run, the input_bit_order changes through all possible + values to check usage of the H and P bits. The number of bits to + input each time is taken from the value of input_bit_order. The + sequence is the following: + + Input_bit_order (bin) Total bits input by Huffman Value + 000 0 0 + 010 2 3 + 100 4 8 + 110 12 1239 + 001 + P-bit changed, throw away 6 bits + 001 1 2 + 011 3 3 + 101 10 921 + 111 14 12542 + 010 + P-bit changed, throw away 4 bits + 010 0 - not enough bits so terminate + + + +Surtees & West Informational [Page 18] + +RFC 4465 SigComp Torture Tests June 2006 + + +2.12. INPUT-BYTES + + This section gives assembly code to test the INPUT-BYTES instruction. + The code is designed to test that the following boundary cases have + been correctly implemented: + + 1. The INPUT-BYTES instruction inputs 0 bytes. + + 2. The INPUT-BYTES instruction requests data that lies beyond the + end of the compressed message. + + 3. The INPUT-BYTES instruction is used after part of a byte has been + input (e.g., by the INPUT-BITS instruction). + + at (64) + + :byte_copy_left pad (2) + :byte_copy_right pad (2) + :input_bit_order pad (2) + :result pad (2) + :output_start pad (4) + :output_end + + at (128) + + LOAD (byte_copy_left, output_start) + LOAD (byte_copy_right, output_end) + + :start + + INPUT-BITS ($input_bit_order, result, end_of_message) + OUTPUT (result, 2) + + ADD ($input_bit_order, 2) + REMAINDER ($input_bit_order, 7) + + INPUT-BYTES ($input_bit_order, output_start, end_of_message) + OUTPUT (output_start, $input_bit_order) + + ADD ($input_bit_order, 1) + JUMP (start) + + :end_of_message + + END-MESSAGE (0, 0, 0, 0, 0, 0, 0) + + + + + + +Surtees & West Informational [Page 19] + +RFC 4465 SigComp Torture Tests June 2006 + + + An example of a compressed message is 0x932e ac71 66d8 6fb1 592b dc9a + 9734 d847 a733 874e 1bcb cd51 b5dc 9659 9d6a, which decompresses to + give the output 0x0000 932e 0001 b166 d86f b100 1a2b 0003 9a97 34d8 + 0007 0001 3387 4e00 08dc 9651 b5dc 9600 599d 6a. Executing the code + costs 130 UDVM cycles. + + As the code is run, the input_bit_order changes through all possible + values to check usage of the F and P bits. The number of bits or + bytes to input each time is taken from the value of input_bit_order. + For each INPUT-BYTES instruction, the remaining bits of the byte are + thrown away. The P-bit always changes on the byte boundary so no + bits are thrown away. The sequence is the following: + + Input_bit_order (bin) Input bits Input bytes Output + 000 0 0x0000 + 010 2 0x932e + 011 3 0x0001 + 101 5 0xb166 d866 b1 + 110 6 0x001a + 001 1 0x2b + 010 2 0x0003 + 100 4 0x9a97 34d8 + 101 5 0x0007 + 000 0 + 001 1 0x0001 + 011 3 0x3384 4e + 100 4 0x0008 + 110 6 0xdc96 51b5 dc96 + 111 7 0x0059 + 010 2 0x9d6a + 011 3 - no bits left so terminate + +2.13. Stack Manipulation + + This section gives assembly code to test the PUSH, POP, CALL, and + RETURN instructions. The code is designed to test that the following + boundary cases have been correctly implemented: + + 1. The stack manipulation instructions overwrite the UDVM register + stack_location. + + 2. The CALL instruction specifies a reference operand rather than an + absolute value. + + 3. The PUSH instruction pushes the value contained in stack_fill + onto the stack. + + 4. The stack_location register contains an odd integer. + + + +Surtees & West Informational [Page 20] + +RFC 4465 SigComp Torture Tests June 2006 + + + at (64) + + :byte_copy_left pad (2) + :byte_copy_right pad (2) + :input_bit_order pad (2) + :stack_location pad (2) + :next_address pad (2) + + at (128) + + LOAD (stack_location, 64) + PUSH (2) + PUSH ($64) + PUSH (66) ; Stack now contains 2, 1, 66 + ; so $stack_location = 66 + + OUTPUT (64, 8) ; Output 0x0003 0002 0001 0042 + + POP (64) ; Pop value 66 from address 70 to address 64 + POP ($stack_location) ; Pop value 1 from address 68 to address 66 + ; so stack_fill is overwritten to be 1 + POP (stack_location) ; Pop value 1 from address 68 to address 70 + + OUTPUT (64, 8) ; Output 0x0042 0000 0001 0001 + JUMP (address_a) + + at (192) + + :address_a + + LOAD (stack_location, 32) + LOAD (next_address, address_c) + SUBTRACT ($next_address, address_b) ; next_address = 64 + CALL (address_b) ; push 204 on stack + + at (256) + + :address_b + + CALL ($next_address) ; push 256 on stack + + at (320) + + :address_c + + LOAD (stack_location, 383) + LOAD (383, 26) ; overwrite $stack_location with 26 + MULTILOAD (432, 3, 1, 49153, 32768) + + + +Surtees & West Informational [Page 21] + +RFC 4465 SigComp Torture Tests June 2006 + + + ; write bytes so that 433 and 434 + ; contain 0x01c0 = 448 and + ; 435 and 436 contain 0x0180 = 384 + + RETURN ; pop 383 from the stack and jump + ; there = 384, which is lsb of + ; stack_fill, which now contains 25, + ; which is UDVM instruction RETURN + ; pop 448 from the stack and jump + ; there + at (448) + + END-MESSAGE (0, 0, 0, 0, 0, 0, 0) + + The output of the code is 0x0003 0002 0001 0042 0042 0000 0001 0001, + and a total of 40 UDVM cycles are used. + +2.14. Program Flow + + This section gives assembly code to test the JUMP, COMPARE, and + SWITCH instructions. The code is designed to test that the following + boundary cases have been correctly implemented: + + 1. The address operands are specified as references to memory + addresses rather than as absolute values. + + at (64) + + :next_address pad (2) + :counter pad (1) + :counter_lsb pad (1) + :switch_counter pad (2) + + at (128) + + LOAD (switch_counter, 4) + + :address_a + + LOAD (next_address, address_c) + SUBTRACT ($next_address, address_b) ; address_c - address_b + OUTPUT (counter_lsb, 1) + + :address_b + + JUMP ($next_address) ; Jump to address_c + + :address_c + + + +Surtees & West Informational [Page 22] + +RFC 4465 SigComp Torture Tests June 2006 + + + ADD ($counter, 1) + LOAD (next_address, address_a) + SUBTRACT ($next_address, address_d) ; address_a - address_d + OUTPUT (counter_lsb, 1) + + :address_d + + COMPARE ($counter, 6, $next_address, address_c, address_e) + ; counter < 6, $next_address gives + ; jump to address_a + + :address_e + + SUBTRACT ($switch_counter, 1) ; switch_counter = 3 + LOAD (next_address, address_a) + SUBTRACT ($next_address, address_f) ; address_a - address_f + OUTPUT (counter_lsb, 1) + + :address_f + + SWITCH (4, $switch_counter, address_g, $next_address, address_c, + address_e) + ; when $switch_counter = 1, + ; $next_address gives jump to + ; address_a + + :address_g + + END-MESSAGE (0, 0, 0, 0, 0, 0, 0) + + The output of the code is 0x0001 0102 0203 0304 0405 0506 0707 0708 + 0808 0909, and a total of 131 UDVM cycles are used. + +2.15. State Creation + + This section gives assembly code to test the STATE-CREATE and STATE- + FREE instructions. The code is designed to test that the following + boundary cases have been correctly implemented: + + 1. An item of state is created that duplicates an existing state + item. + + 2. An item of state is freed when the state has not been created. + + 3. An item of state is created and then freed by the same message. + + 4. The STATE-FREE instruction frees a state item by sending fewer + bytes of the state_identifier than the minimum_access_length. + + + +Surtees & West Informational [Page 23] + +RFC 4465 SigComp Torture Tests June 2006 + + + 5. The STATE-FREE instruction has partial_identifier_length operand + shorter than 6 or longer than 20. + + 6. The STATE-FREE instruction specifies a partial_identifier that + matches with two state items in the compartment. + + 7. The bytes of the identifier are written to the position specified + in the STATE-FREE instruction after the STATE-FREE instruction + has been run (and before END-MESSAGE). + + at (64) + + :byte_copy_left pad (2) + :byte_copy_right pad (2) + :states pad (1) + :states_lsb pad (1) + :min_len pad (1) + :min_len_lsb pad (1) + + :state_identifier pad (20) + + set (state_length, 10) + + at (127) + :decompression_failure + at (128) + + INPUT-BYTES (1, states_lsb, decompression_failure) + + :test_one + LSHIFT ($states, 11) + COMPARE ($states, 32768, test_two, create_state_a2, create_state_a2) + + :create_state_a2 + STATE-CREATE (state_length, state_address2, 0, 20, 0) + + :test_two + LSHIFT ($states, 1) + COMPARE ($states, 32768, test_three, create_state_a, create_state_a) + + :create_state_a + STATE-CREATE (state_length, state_address, 0, 20, 0) + + :test_three + LSHIFT ($states, 1) + COMPARE ($states, 32768, test_four, free_state, free_state) + + + + + +Surtees & West Informational [Page 24] + +RFC 4465 SigComp Torture Tests June 2006 + + + :free_state + INPUT-BYTES (1, min_len_lsb, decompression_failure) + STATE-FREE (state_identifier, $min_len) + COPY (identifier1, $min_len, state_identifier) + + :test_four + + LSHIFT ($states, 1) + COMPARE ($states, 32768, test_five, free_state2, free_state2) + + :free_state2 + STATE-FREE (identifier1, 6) + + :test_five + 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) + + :identifier1 + byte (67, 122, 232, 10, 15, 220, 30, 106, 135, 193, 182, 42, 118, + 118, 185, 115, 49, 140, 14, 245) + + at (256) + :state_address + byte (192, 204, 63, 238, 121, 188, 252, 143, 209, 8) + + :state_address2 + byte (101, 232, 3, 82, 238, 41, 119, 23, 223, 87) + + Upon reaching the END-MESSAGE instruction, the UDVM does not output + any decompressed data, but instead may make one or more state + creation or state free requests to the state handler. Assuming that + the application does not veto the state creation request (and that + sufficient state memory is available) the code results in 0, 1, or 2 + state items being present in the compartment. + + The following table lists ten different compressed messages, the + states created and freed by each, the number of states left after + each message, and the number of UDVM cycles used. There are 3 state + creation instructions: + + create state_a, which has hash identifier1 + create state_b (in END-MESSAGE), which is identical to state_a + + + +Surtees & West Informational [Page 25] + +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 + + + at (128) + + END-MESSAGE (0, 0, state_length, state_start, 0, 20, 0) + + ; The bytes between state_start and state_end are derived from + ; translation of the following mnemonic code: + ; + ; at (512) + ; OUTPUT (data, 4) + ; END-MESSAGE (0,0,0,0,0,0,0) + ; :data + ; byte (116, 101, 115, 116) + + at (512) + :state_start + byte (34, 162, 12,4, 35, 0, 0, 0, 0, 0, 0, 0, 116, 101, 115, 116) + :state_end + + set (state_length, (state_end - state_start)) + + This is the bytecode for the rest of the test. + + at (64) + + :byte_copy_left pad (2) + :byte_copy_right pad (2) + :type pad (1) + :type_lsb pad (1) + :state_value pad (4) + + at (127) + :decompression_failure + at (128) + + INPUT-BYTES (1, type_lsb, decompression_failure) + COMPARE ($type, 1, execute_state, extract_state, error_conditions) + + :execute_state + + STATE-ACCESS (state_identifier, 20, 0, 0, 0, 512) + + :extract_state + + STATE-ACCESS (state_identifier, 20, 12, 4, state_value, 0) + OUTPUT (state_value, 4) + JUMP (end) + + :error_conditions + + + +Surtees & West Informational [Page 27] + +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 + + + :test_state_access + + COMPARE ($partial_state_id_length, 0, decompression_failure, + test_length_equals_zero, test_state_length) + + :test_length_equals_zero + ; No state was accessed so state_length + ; should be zero (first message) + COMPARE ($state_length, 0, decompression_failure, end, + decompression_failure) + + :test_state_length + ; State was accessed so state_length + ; should be 960 + COMPARE ($state_length, 960, decompression_failure, test_udvm_memory, + decompression_failure) + + :test_udvm_memory + ; Copy one byte to + ; udvm_memory_size + input - 1 + ; Succeed when input byte is 0x00 + ; Fail when input byte is 0x01 + + INPUT-BYTES (1, check_memory_lsb, decompression_failure) + ADD ($check_memory, $udvm_memory_size) + SUBTRACT ($check_memory, 1) + COPY (32, 1, $check_memory) + + :test_udvm_cycles + + INPUT-BYTES (1, check_cycles_lsb, decompression_failure) + + ; Work out the total number of cycles available to the UDVM + ; total_UDVM_cycles = cycles_per_bit * (8 * message_size + 1000) + ; + ; = cycles_per_bit * (8 * (partial_state_id_length + 3) + 1000) + + LOAD (remaining_cycles, $partial_state_id_length) + ADD ($remaining_cycles, 3) + MULTIPLY ($remaining_cycles, 8) + ADD ($remaining_cycles, 1000) + + MULTIPLY ($remaining_cycles, $cycles_per_bit) + + ADD ($remaining_cycles, $check_cycles) + + set (cycles_used_by_bytecode, 856) + + + + +Surtees & West Informational [Page 30] + +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 + + + :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) + + :code_start + + ; udvm_memory_size for message-based transport + ; = DMS - total_message_size + + ADD ($udvm_memory_size, total_message_size) + OUTPUT (udvm_memory_size, 2) + END-MESSAGE (0, 0, 0, 0, 0, 0, 1) + + :code_end + + set (header_size, 3) + set (code_size, (code_end - code_start)) + set (total_message_size, (header_size + code_size)) + + A number of complete SigComp messages are given below, each + containing some or all of the above code. In each case, it is + indicated whether the message will successfully output the + decompression memory size or whether it will cause a decompression + failure to occur (together with the reason for the failure): + + SigComp message: Effect: + + 0xf8 Fails (message too short) + + 0xf800 Fails (message too short) + + 0xf800 e106 0011 2200 0223 Outputs the decompression_memory_size + 0x0000 0000 0000 01 + + 0xf800 f106 0011 2200 0223 Fails (message too short) + 0x0000 0000 0000 01 + + 0xf800 e006 0011 2200 0223 Fails (invalid destination address) + 0x0000 0000 0000 01 + + 0xf800 ee06 0011 2200 0223 Outputs the decompression_memory_size + 0x0000 0000 0000 01 + + + + + +Surtees & West Informational [Page 33] + +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 + + + The above assembly code has been compiled and used to generate the + following byte stream: + + 0xffff f801 7108 0002 2200 0222 a092 0523 0000 0000 0000 00ff 00ff + 0x03ff ffff ffff ffff f801 7e08 0002 2200 0222 a3d2 0523 0000 0000 + 0x0000 00ff 04ff ffff ffff ffff ffff ff + + Note that this byte stream can be divided into five distinct portions + (two SigComp messages and three sets of delimiters) as illustrated + below: + + Portion of byte stream: Meaning: + + 0xffff Delimiter + + 0xf801 7108 0002 2200 0222 a092 0523 First message + 0x0000 0000 0000 00ff 00ff 03ff ffff + + 0xffff ffff Delimiter + + 0xf801 7e08 0002 2200 0222 a3d2 0523 Second message + 0x0000 0000 0000 00ff 04ff ffff ff + + 0xffff ffff ffff Delimiter + + When the complete byte stream is supplied to the decompressor + dispatcher, the record marking scheme must use the delimiters to + partition the stream into two distinct SigComp messages. Both of + these messages successfully output the decompression memory size (as + a 2-byte value), followed by 5 consecutive 0xff bytes to test that + the record marking scheme is working correctly. A total of 11 UDVM + cycles are used in each case. + + It must also be checked that the dispatcher can handle the same error + cases as covered in Section 3.2. Each of the following byte streams + should cause a decompression failure to occur for the reason stated: + + Byte stream: Reason for failure: + + 0xf8ff ff Message too short + + 0xf800 ffff Message too short + + 0xf801 8108 0002 2200 0222 a092 0523 ffff Message too short + 0x0000 0000 0000 00ff 00ff 03ff ffff + + 0xf801 7008 0002 2200 0222 a092 0523 ffff Invalid destination + 0x0000 0000 0000 00ff 04ff ffff ff + + + +Surtees & West Informational [Page 35] + +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 + + + INPUT-BYTES (7, result, next_bytes) ; This should fail, throw away + ; 7 bits with value Ox7a and + ; jump to next_bytes + + :decompression_failure1 + DECOMPRESSION-FAILURE ; This instruction is never + ; executed but is used to + ; separate success and failure + ; to input bytes. + + :next_bytes + + ; Read 7 bits - this removes the byte alignment of the message + + ; If the bits have not been thrown away where they should be, then + ; the message will be 1 byte longer than necessary and the output + ; will be incorrect. + + INPUT-BITS (7, result, decompression_failure1) ; Input 0x00 (7 bits) + + ; Read 2 bytes + + INPUT-BYTES (2, result, decompression_failure1) + ; Throw away 1 bit value 0 + ; Input 0x6869 + OUTPUT (result, 2) ; Output 0x6869 + + ; Attempt to read more bits than + INPUT-BITS (16, result, bits) ; there are to ensure they + ; remain available + + :decompression_failure2 + DECOMPRESSION-FAILURE ; This instruction is never + ; executed but is used to + ; separate success and failure + ; to input bits. + + :bits + + ; Read 8 bits + + INPUT-BITS (8, result, decompression_failure2) ; Input 0x21 or fail + OUTPUT (result_lsb, 1) ; Output 0x21 + + :end_message + + END-MESSAGE (0, 0, 0, 0, 0, 0, 0) + + + + +Surtees & West Informational [Page 37] + +RFC 4465 SigComp Torture Tests June 2006 + + + If the compressed message is 0xfffa 0068 6921, then the code + terminates successfully with the output 0x6869 21, and a total of 23 + UDVM cycles are used. However, if the compressed message is 0xfffa + 0068 69, then decompression failure occurs (at the final INPUT-BITS). + +4. Torture Tests for State Handler + + The following sections give code to test the various functions of the + SigComp state handler. + +4.1. SigComp Feedback Mechanism + + This section gives assembly code to test the SigComp feedback + mechanism. The code is designed to test that the following boundary + cases have been correctly implemented: + + 1. Both the short and the long versions of the SigComp feedback item + are used. + + 2. The chain of returned SigComp parameters is terminated by a non- + zero value. + + at (64) + + :type pad (1) + :type_lsb pad (1) + + :requested_feedback_location pad (1) + :requested_feedback_length pad (1) + :requested_feedback_bytes pad (127) + + :returned_parameters_location pad (2) + :length_of_partial_state_id_a pad (1) + :partial_state_identifier_a pad (6) + :length_of_partial_state_id_b pad (1) + :partial_state_identifier_b pad (12) + :length_of_partial_state_id_c pad (1) + :partial_state_identifier_c pad (20) + :terminate_returned_parameters pad (1) + + align (128) + + set (q_bit, 1) + set (s_bit, 0) + set (i_bit, 0) + set (flags, (((4 * q_bit) + (2 * s_bit)) + i_bit)) + + INPUT-BYTES (1, type_lsb, decompression_failure) + + + +Surtees & West Informational [Page 38] + +RFC 4465 SigComp Torture Tests June 2006 + + + COMPARE ($type, 1, short_feedback_item, long_feedback_item, + decompression_failure) + + :short_feedback_item + + set (requested_feedback_data, 127) + set (short_feedback_value, ((flags * 256) + requested_feedback_data)) + + LOAD (requested_feedback_location, short_feedback_value) + JUMP (return_sigcomp_parameters) + + :long_feedback_item + + set (requested_feedback_field, 255) + set (long_feedback_value, ((flags * 256) + requested_feedback_field)) + + LOAD (requested_feedback_location, long_feedback_value) + MEMSET (requested_feedback_bytes, 127, 1, 1) + + :return_sigcomp_parameters + + set (cpb, 0) + set (dms, 1) + set (sms, 0) + set (sigcomp_version, 1) + + set (parameters_msb, (((64 * cpb) + (8 * dms)) + sms)) + set (sigcomp_parameters, ((256 * parameters_msb) + sigcomp_version)) + + LOAD (returned_parameters_location, sigcomp_parameters) + + LOAD (length_of_partial_state_id_a, 1536) ; length 6 first byte 0 + LOAD (length_of_partial_state_id_b, 3072) ; length 12 first byte 0 + LOAD (length_of_partial_state_id_c, 5120) ; length 20 first byte 0 + LOAD (terminate_returned_parameters, 5376) ; length 21 + ; used to terminate the + ; returned parameters + MEMSET (partial_state_identifier_a, 6, 0, 1) + MEMSET (partial_state_identifier_b, 12, 0, 1) + MEMSET (partial_state_identifier_c, 20, 0, 1) + + END-MESSAGE (requested_feedback_location, + returned_parameters_location, 0, 0, 0, 0, 0) + :decompression_failure + DECOMPRESSION-FAILURE + + + + + + +Surtees & West Informational [Page 39] + +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 + + + at(127) + :decompression_failure + at (128) + + MULTILOAD (byte_copy_left, 2, state_start, order_data) + + INPUT-BYTES (1, type_lsb, decompression_failure) + COMPARE ($type, 5, general_test, large_state, verify_state) + + :general_test + + COMPARE ($type, 3, start, state_present, state_not_present) + + :start + + MULTIPLY ($type, 6) + ADD ($type, order_data) + LOAD (order, $type) + ADD ($type, 6) + + ; Finish with the value (order_data + 6*n) in order where + ; n is the input value 0x00, 0x01, or 0x02 + ; type = order + 6 + ; These values are used to index into the 'order_data' + ; that is used to work out state retention priorities and lengths + + :loop + + COPY ($order, 2, state_retention_priority) + COMPARE ($order, $type, continue, end, decompression_failure) + + :continue + + ; Set up a state creation each time through the loop + + LOAD (state_length, $state_retention_priority) + MULTIPLY ($state_length, 256) + STATE-CREATE ($state_length, state_start, 0, 6, + $state_retention_priority) + + ADD ($order, 2) + JUMP (loop) + + :state_present + + ; Access the states that should be present + STATE-ACCESS (state_identifier_a, 6, 0, 0, 0, 0) + STATE-ACCESS (state_identifier_b, 6, 0, 0, 0, 0) + + + +Surtees & West Informational [Page 42] + +RFC 4465 SigComp Torture Tests June 2006 + + + STATE-ACCESS (state_identifier_c, 6, 0, 0, 0, 0) + STATE-ACCESS (state_identifier_e, 6, 0, 0, 0, 0) + JUMP (end) + + :state_not_present + + ; Check that the state that shouldn't be present is not present. + STATE-ACCESS (state_identifier_d, 6, 0, 0, 0, 0) + JUMP (end) + + :large_state + + STATE-CREATE (2048, state_start, 0, 6, 0) + JUMP (end) + + :verify_state + + STATE-ACCESS (large_state_identifier, 6, 0, 0, 0, 0) + JUMP (end) + + :end + + END-MESSAGE (0, 0, 0, 0, 0, 0, 0) + + at (512) + + :state_start + + byte (116, 101, 115, 116) + + :order_data + ; This data is used to generate the retention priority + ; and state length of each state creation. + + word (0, 1, 2, 3, 4, 3, 2, 1, 0) + + :state_identifier_a + + byte (142, 234, 75, 67, 167, 135) + + :state_identifier_b + + byte (249, 1, 14, 239, 86, 123) + + :state_identifier_c + + byte (35, 154, 52, 107, 21, 166) + + + + +Surtees & West Informational [Page 43] + +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 + + + ; $type 515 516 517 + + ADD ($type, 3) + STATE-CREATE (448, $type, 0, 6, 0) + + ; create a third time beginning in different place again + ; starting byte identified by $type according to input: + ; Input 0x00 0x01 0x02 + ; $type 516 517 515 + + SUBTRACT ($type, temp_one) + REMAINDER ($type, 3) + ADD ($type, temp_two) + STATE-CREATE (448, $type, 0, 6, 0) + + :common_state + + STATE-CREATE (448, temp_three, 0, 6, $type) + JUMP (end) + + :overwrite_state + + STATE-CREATE (1984, 32, 0, 6, 0) + JUMP (end) + + :access_state + + STATE-ACCESS (state_identifier_c, 6, 0, 0, 0, 0) + STATE-ACCESS (state_identifier_d, 6, 0, 0, 0, 0) + STATE-ACCESS (state_identifier_f, 6, 0, 0, 0, 0) + STATE-ACCESS (state_identifier_g, 6, 0, 0, 0, 0) + + :end + + END-MESSAGE (0, 0, 0, 0, 0, 0, 0) + + :error_conditions + + COMPARE ($type, 7, access_a, access_b, access_e) + + :access_a + + STATE-ACCESS (state_identifier_a, 6, 0, 0, 0, 0) + JUMP (end) + + :access_b + + + + + +Surtees & West Informational [Page 46] + +RFC 4465 SigComp Torture Tests June 2006 + + + STATE-ACCESS (state_identifier_b, 6, 0, 0, 0, 0) + JUMP (end) + + :access_e + + STATE-ACCESS (state_identifier_e, 6, 0, 0, 0, 0) + JUMP (end) + + at (512) + + :state_start + + byte (0, 1, 2, 3, 4, 5, 6) + + :state_end + + set (temp_one, (state_start + 2)) ; = 514 + set (temp_two, (state_start + 3)) ; = 515 + set (temp_three, (state_end - 1)) ; = 518 + + :state_identifier_a ; start state at 512 + + byte (172, 166, 11, 142, 178, 131) + + :state_identifier_b ; start state at 513 + + byte (157, 191, 175, 198, 61, 210) + + :state_identifier_c ; start state at 514 + + byte (52, 197, 217, 29, 83, 97) + + :state_identifier_d ; start state at 515 + + byte (189, 214, 186, 42, 198, 90) + + :state_identifier_e ; start state at 516 + + byte (71, 194, 24, 20, 238, 7) + + :state_identifier_f ; start state at 517 + + byte (194, 117, 148, 29, 215, 161) + + :state_identifier_g ; start state at 518 + + byte (72, 135, 156, 141, 233, 14) + + + + +Surtees & West Informational [Page 47] + +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 + + + +-----------------------------+ + | Compartment 0 | + | | + | | + | State a | + | | + | +-------------------+---------+ + | | | | + | | | | + | | State d | | + | | | | + | | | | + +---------+---------+---------+ | | + | | | | | | + | | | | | | + | | State e | State g | | State c | + | | | | | | + | | | | | | + | +---------+---------+---------+ | + | | | | + | | | | + | State b | State f | | + | | | | + | | | Compartment 2 | + | +---------+-------------------+ + | | + | | + | | + | | + | Compartment 1 | + +-----------------------------+ + + Figure 1: States created in the three compartments + +4.4. Accessing RFC 3485 State + + This section gives assembly code to test accessing SIP-SDP static + dictionary state [3]. The code first accesses the state and then + outputs the result. + + at (32) + + :input pad (1) + :input2 pad (1) + :input3 pad (1) + + + + + + +Surtees & West Informational [Page 49] + +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 + + + at (30) + :save_area1 + set (saved_instr1, (save_area1 + (code_start2 - start_saved))) ; = 33 + + at (80) + :save_area2 + set (saved_instr2, (save_area2 + (code_start2 - start_saved))) ; = 83 + + at (128) + :code_start + + COPY (start_saved, saved_len, save_area1) + ; copy 'ok2', OUTPUT (save_area2,3) END-MESSAGE + ; to position 30 and create as state + STATE-CREATE (saved_len, save_area1, saved_instr1, 6, 10) + + + set (modify1, (save_area1 + 5)) ; = 35 + LOAD (modify1, 0x1e03) + ; modify save_area2 to be save_area1 in the + ; created state + + COPY (start_saved, saved_len, save_area2) + STATE-CREATE (saved_len, save_area2, saved_instr2, 20, 10) + STATE-CREATE (saved_len, save_area2, saved_instr2, 12, 10) + ; copy 'ok2', OUTPUT (save_area2,3) END-MESSAGE + ; to position 80 and create as state twice with + ; min access len 20 and 12 + + JUMP (modify) + + :ok1 + byte (0x4f, 0x4b, 0x31) + + set (after_output_minus1, (after_output - 1)) + + :modify + INPUT-BYTES (1, after_output_minus1, decompression_failure) + ; Input overwrites the next instruction + OUTPUT (ok1, 3) ; Now is OUTPUT (ok1, 2) so output is 0x4f4b + + :after_output + + ; Save from ok1 to the opcode of END-MESSAGE + + set (modify_len, ((after_output + 1) - ok1)) ; = 13 + + + + + +Surtees & West Informational [Page 51] + +RFC 4465 SigComp Torture Tests June 2006 + + + END-MESSAGE (0, 0, modify_len, ok1, modify, 6, 10) + ; Save 'ok1', INPUT-BYTES, OUTPUT as state + + set (saved_len, (end_saved - start_saved)) ; = 8 + + :start_saved + byte (0x4f, 0x4b, 0x32) + + :code_start2 + + ; Translated bytecode for OUTPUT (save_area2, 3) + byte (0x22, 0xa0, 0x50, 0x03) + + ; Translated bytecode for END-MESSAGE (0, 0, 0, 0, 0, 0, 0) + ; The zeros do not need to be sent because UDVM is initialised to 0 + byte (0x23) + + :end_saved + :decompression_failure + + The outputs and cycle usages are: + + Message Output Cycles + 1 0x4f4b 66 + 2 0x4f4b 31 7 + 3 0x4f4b 32 5 + 4 0x0000 32 5 + 5 None Decompression failure + + First message: mnemonic code annotated above + + 0xf804 6112 a0be 081e 2008 1e21 060a 0e23 be03 12a0 be08 a050 2008 + 0xa050 a053 140a 2008 a050 a053 0c0a 1606 004f 4b31 1c01 a0b3 fc22 + 0xa0a8 0323 0000 0da0 a8a0 ab06 0a4f 4b32 22a0 5003 2302 + + Second message: access and run last state saved by previous message - + 'ok1', INPUT-BYTES, OUTPUT, END-MESSAGE. + + 0xf905 b88c e72c 9103 + + Third message: access and run state from save_area2 with 12 bytes of + state identifier - 'ok2', INPUT-BYTES, OUTPUT, END-MESSAGE. + + 0xfb24 63cd ff5c f8c7 6df6 a289 ff + + Fourth message: access and run state from save_area1. The state is + 'ok2', INPUT-BYTES, OUTPUT, END-MESSAGE but the first two bytes + should be overwritten when initialising UDVM memory. + + + +Surtees & West Informational [Page 52] + +RFC 4465 SigComp Torture Tests June 2006 + + + 0xf95b 4b43 d567 83 + + Fifth message: attempt to access state from save_area2 with fewer + than 20 bytes of state identifier. + + 0xf9de 8126 1199 1f + +5. Security Considerations + + This document describes torture tests for the SigComp protocol RFC + 3320 [2]. Consequently, the security considerations for this + document match those of SigComp. + + In addition, the torture tests include tests for a significant number + of "boundary and error cases" for execution of the UDVM bytecode. + Boundary and error problems are common vectors for security attacks, + so ensuring that a UDVM implementation executes this set of torture + tests correctly should contribute to the security of the + implementation. + +6. Acknowledgements + + Thanks to Richard Price and Pekka Pessi for test contributions and to + Pekka Pessi and Cristian Constantin, who served as committed working + group document reviewers. + +7. Normative References + + [1] Surtees, A. and M. West, "Signaling Compression (SigComp) Users' + Guide", RFC 4464, May 2006. + + [2] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z., + and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, + January 2003. + + [3] Garcia-Martin, M., Bormann, C., Ott, J., Price, R., and A.B. + Roach, "The Session Initiation Protocol (SIP) and Session + Description Protocol (SDP) Static Dictionary for Signaling + Compression (SigComp)", RFC 3485, February 2003. + + [4] Roach, A.B., "A Negative Acknowledgement Mechanism for Signaling + Compression", RFC 4077, May 2005. + + + + + + + + + +Surtees & West Informational [Page 53] + +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 + + +A.1.2. Arithmetic + + 0xf80a a11c 01a0 450b 0722 0116 a077 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 + 0x06c0 00ff 9941 0720 0108 20a3 e909 20a0 650a 200b 2286 0406 21c0 + 0xff07 2162 0821 6109 2061 0a21 6222 8604 23 + + Input: 0x00 + Output: 0x0000 0000 0000 0004 + Cycles: 25 + + Input: 0x01 + DECOMPRESSION-FAILURE DIV_BY_ZERO + + Input: 0x02 + DECOMPRESSION-FAILURE DIV_BY_ZERO + +A.1.3. Sorting + + 0xf80d c10c 8802 170b 8802 1722 a12e 2d23 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 + 0x0000 0a00 0a00 1100 0700 1600 0300 0300 0300 1300 0100 1000 0e00 + 0x0800 0200 0d00 1400 1200 1700 0f00 1500 0c00 0600 096e 6720 6975 + 0x6920 7469 742c 2079 6f75 2720 5346 6f6e 6761 2075 7272 646f 2074 + 0x6f6e 2e2e 0070 6570 206e 7472 656e 69 + + Input: None + Output: 0x466f 7264 2c20 796f 7527 7265 2074 7572 6e69 6e67 + 0x2069 6e74 6f20 6120 7065 6e67 7569 6e2e 2053 746f + 0x7020 6974 2e + Cycles: 371 + + + + + + + + + + + + + + +Surtees & West Informational [Page 55] + +RFC 4465 SigComp Torture Tests June 2006 + + +A.1.4. SHA-1 + + 0xf808 710d a0c3 03a0 4422 a044 140d a0c6 38a0 4422 a044 140e 86a0 + 0xfe0e a042 a0ff 0da0 fe8e a044 22a0 4414 0e86 a0ff 0ea0 42a1 070d + 0xa0ff a280 a0ff 22a0 ff14 2300 0000 0000 0000 6162 6361 6263 6462 + 0x6364 6563 6465 6664 6566 6765 6667 6866 6768 6967 6869 6a68 696a + 0x6b69 6a6b 6c6a 6b6c 6d6b 6c6d 6e6c 6d6e 6f6d 6e6f 706e 6f70 7161 + 0x3031 3233 3435 3637 + + Input: None + Output: 0xa999 3e36 4706 816a ba3e 2571 7850 c26c 9cd0 d89d + 0x8498 3e44 1c3b d26e baae 4aa1 f951 29e5 e546 70f1 + 0x12ff 347b 4f27 d69e 1f32 8e6f 4b55 73e3 666e 122f + 0x4f46 0452 ebb5 6393 4f46 0452 ebb5 6393 4f46 0452 + Cycles: 17176 + +A.1.5. LOAD and MULTILOAD + + 0xf803 610e 87a0 840e a082 c080 0ec0 80a0 860e c084 c084 2287 081c + 0x01a0 4127 0820 0206 203c 0f60 03a0 a2a0 b187 0f60 042a 87c0 80c0 + 0x8422 8708 23 + + Input: 0x00 + Output: 0x0084 0084 0086 0086 002a 0080 002a 002a + Cycles: 36 + + Input: 0x01 + DECOMPRESSION-FAILURE MULTILOAD_OVERWRITTEN + + Input: 0x02 + DECOMPRESSION-FAILURE MULTILOAD_OVERWRITTEN + +A.1.6. COPY + + 0xf803 910e 208e 0e86 860e a042 8712 2087 210e 8680 4100 1286 a055 + 0xa041 2220 a077 0e86 200e a042 3015 2004 a041 0112 2004 3022 3004 + 0x1230 042e 2220 0223 + + Input: None + Output: 0x4040 4040 4040 4040 4040 4040 4040 4040 4040 4040 + 0x4040 4040 4040 4040 4040 4040 4141 4141 4141 4141 + 0x4141 4141 4141 4141 4141 4141 4141 4141 4141 4141 + 0x4141 4141 4141 4141 4141 4141 4141 4141 4141 4141 + 0x4141 4141 4141 4141 4141 4141 4141 4141 4141 4141 + 0x4141 4141 4141 4141 4141 4141 4141 4141 4141 5541 + 0x4243 4443 44 + Cycles: 365 + + + + +Surtees & West Informational [Page 56] + +RFC 4465 SigComp Torture Tests June 2006 + + +A.1.7. COPY-LITERAL and COPY-OFFSET + + 0xf806 110e 2080 4100 0e86 860e a042 870e a044 2113 2087 2222 8608 + 0x0ea0 44a0 9c13 2002 2222 a09c 020e 86a0 480e a042 a052 0ea0 44a0 + 0x5215 a048 0aa0 4101 1402 0622 0ea0 4606 1463 0422 2261 0a0e a044 + 0xa050 1404 0422 22a0 4402 1405 0422 22a0 4402 2260 0a23 + + Input: None + Output: 0x4141 4141 0061 4141 4141 494A 4142 4344 494A 4142 + 0x004A 004E 4748 4845 4647 4748 4546 + Cycles: 216 + +A.1.8. MEMSET + + 0xf801 810e 8687 0ea0 42a0 8115 86a0 8100 0115 a081 0f86 0f22 8710 + 0x23 + + Input: None + Output: 0x8040 4f5e 6d7c 8b9a a9b8 c7d6 e5f4 0312 + Cycles: 166 + +A.1.9. CRC + + 0xf801 8115 a046 1801 0115 a05e 1487 011c 02a0 4413 1b62 a046 2c0e + 0x23 + + Input: 0x62cb + Output: None + Cycles: 95 + + Input: 0xabcd + DECOMPRESSION FAILURE USER_REQUESTED (CRC mismatch) + +A.1.10. INPUT-BITS + + 0xf801 511d 62a0 4614 22a0 4602 0622 010a 2207 0622 0116 ee23 + + Input: 0x932e ac71 + Output: 0x0000 0002 0002 0013 0000 0003 001a 0038 + Cycles: 66 + + + + + + + + + + + +Surtees & West Informational [Page 57] + +RFC 4465 SigComp Torture Tests June 2006 + + +A.1.11. INPUT-HUFFMAN + + 0xf801 d11e a046 1c02 6200 6262 6200 ff00 22a0 4602 0622 010a 2207 + 0x0622 0116 e623 + + Input: 0x932e ac71 66d8 6f + Output: 0x0000 0003 0008 04d7 0002 0003 0399 30fe + Cycles: 84 + +A.1.12. INPUT-BYTES + + 0xf802 710e 86a0 480e a042 a04c 1d62 a046 1d22 a046 0206 2202 0a22 + 0x071c 62a0 480e 22a0 4862 0622 0116 e523 + + Input: 0x932e ac71 66d8 6fb1 592b dc9a 9734 d847 a733 874e + 0x1bcb cd51 b5dc 9659 9d6a + Output: 0x0000 932e 0001 b166 d86f b100 1a2b 0003 9a97 34d8 + 0x0007 0001 3387 4e00 08dc 9651 b5dc 9600 599d 6a + Cycles: 130 + +A.1.13. Stack Manipulation + + 0xf814 110e a046 8610 0210 6010 a042 2286 0811 8611 6311 a046 2286 + 0x0816 2800 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 + 0x0000 0000 0000 0000 0000 0000 0000 000e a046 200e a048 a140 0724 + 0x8818 3400 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 + 0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 + 0x0018 6400 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 000e a046 a17f 0ea1 7f1a 0fa1 b003 + 0x0180 c001 8f19 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 0023 + + Input: None + Output: 0x0003 0002 0001 0042 0042 0000 0001 0001 + Cycles: 40 + + + + + + + + + + + + +Surtees & West Informational [Page 58] + +RFC 4465 SigComp Torture Tests June 2006 + + +A.1.14. Program Flow + + 0xf803 f10e a044 040e 86a0 9207 20a0 9022 a043 0116 6006 2101 0e86 + 0xa084 0720 a0a1 22a0 4301 1761 0660 f106 0722 010e 86a0 8407 20a0 + 0xb622 a043 011a 0462 0860 9fdc f123 + + Input: None + Output: 0x0001 0102 0203 0304 0405 0506 0707 0708 0808 0909 + Cycles: 131 + +A.1.15. State Creation + + 0xf809 411c 01a0 45ff 0422 0b17 628f 0d06 0620 0aa1 0a00 1400 0422 + 0x0117 628f 0c06 0620 0a88 0014 0004 2201 1762 8f16 0606 1c01 a047 + 0x9fd2 21a0 4863 12a0 e363 a048 0422 0117 628f 0a06 0621 a0e3 0604 + 0x2201 1762 8f0e 0606 2300 000a 8800 1400 2300 0000 0000 0000 437a + 0xe80a 0fdc 1e6a 87c1 b62a 7676 b973 318c 0ef5 0000 0000 0000 0000 + 0x00c0 cc3f ee79 bcfc 8fd1 0865 e803 52ee 2977 17df 57 + + Input: 0x01 + Output: None + Cycles: 23 + + Input: 0x02 + Output: None + Cycles: 14 + + Input: 0x03 + Output: None + Cycles: 24 + + Input: 0x0405 + DECOMPRESSION-FAILURE INVALID_STATE_ID_LENGTH + + Input: 0x0415 + DECOMPRESSION-FAILURE INVALID_STATE_ID_LENGTH + + Input: 0x0406 + Output: None + Cycles: 23 + + Input: 0x09 + Output: None + Cycles: 34 + + Input: 0x1e06 + Output: None + Cycles: 46 + + + +Surtees & West Informational [Page 59] + +RFC 4465 SigComp Torture Tests June 2006 + + + Input: 0x1e07 + Output: None + Cycles: 47 + + Input: 0x1e14 + Output: None + Cycles: 60 + +A.1.16. STATE-ACCESS + + Set up bytecode: + 0xf819 0123 0000 1089 0014 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 + 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 + 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 + 0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 + 0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0022 a20c + 0x0423 0000 0000 0000 0074 6573 74 + + Input: None + + 0xf819 411c 01a0 45ff 1762 0106 0d1c 1f89 1400 0000 891f 8914 0c04 + 0xa046 0022 a046 0416 a146 1762 0306 101b 1f87 1400 0000 0016 a136 + 0x1f89 1306 04a0 4600 16a1 2b1f 8914 0c05 a046 0016 a120 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 + 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 + 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 0023 0000 0000 + 0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 005d f8bc + 0x3e20 93b5 abe1 f170 1342 4ce7 fe05 e069 39 + + + + + +Surtees & West Informational [Page 60] + +RFC 4465 SigComp Torture Tests June 2006 + + + Input: 0x00 + Output: 0x7465 7374 + Cycles: 26 + + Input: 0x01 + Output: 0x7465 7374 + Cycles: 15 + + Input: 0x02 + DECOMPRESSION-FAILURE STATE_NOT_FOUND + + Input: 0x03 + DECOMPRESSION-FAILURE STATE_NOT_FOUND (len < min_acc_len) + + Input: 0x04 + DECOMPRESSION-FAILURE STATE_TOO_SHORT + +A.2. Dispatcher Tests + +A.2.1. Useful Values + + 0xf805 f10e 8620 0ea0 4221 1c01 a047 f817 4263 f306 f317 4300 ed06 + 0x0c17 4400 e73f e717 44a3 c0e1 07e1 1c01 a047 9fda 0623 4007 2301 + 0x1220 0163 1c01 a049 9fca 0ea0 4443 0622 0308 2208 0622 a3e8 0822 + 0x4106 2264 0722 a358 1220 6220 2300 00a3 c086 8706 + + Input: 1 byte of SigComp version + Output: None + Cycles: 968 + + 0xf93a db1d 3d20 aa + + Input: 1 byte of SigComp version then 0x0000 + Output: None + Cycles: cycles_per_bit * 1080 + + Input: 1 byte of SigComp version then 0x0001 + DECOMPRESSION-FAILURE CYCLES_EXHAUSTED + + Input: 1 byte of SigComp version then 0x0100 + DECOMPRESSION-FAILURE SEGFAULT + + + + + + + + + + +Surtees & West Informational [Page 61] + +RFC 4465 SigComp Torture Tests June 2006 + + +A.2.2. Cycles Checking + + 0xf801 a10f 8604 2029 0022 12a0 4402 6014 02a0 6423 22a0 4402 0622 + 0x0116 ef + + Input: None + DECOMPRESSION-FAILURE CYCLES_EXHAUSTED + +A.2.3. Message-based Transport + + 0xf8 + + Input: None + DECOMPRESSION-FAILURE MESSAGE_TOO_SHORT + + 0xf800 + + Input: None + DECOMPRESSION-FAILURE MESSAGE_TOO_SHORT + + 0xf800 e106 0011 2200 0223 0000 0000 0000 01 + + Input: None + Output: decompression_memory_size + Cycles: 5 + + 0xf800 f106 0011 2200 0223 0000 0000 0000 01 + + Input: None + DECOMPRESSION-FAILURE MESSAGE_TOO_SHORT + + 0xf800 e006 0011 2200 0223 0000 0000 0000 01 + + Input: None + DECOMPRESSION-FAILURE INVALID_CODE_LOCATION + + 0xf800 ee06 0011 2200 0223 0000 0000 0000 01 + + Input: None + Output: decompression_memory_size + Cycles: 5 + +A.2.4. Stream-based Transport + + 0xffff f801 7108 0002 2200 0222 a092 0523 0000 0000 0000 00ff 00ff + 0x03ff ffff ffff ffff f801 7e08 0002 2200 0222 a3d2 0523 0000 0000 + 0x0000 00ff 04ff ffff ffff ffff ffff ff + + + + +Surtees & West Informational [Page 62] + +RFC 4465 SigComp Torture Tests June 2006 + + + The above stream contains two messages: + + Output: decompression_memory_size + Cycles: 11 + + Output: decompression_memory_size + Cycles: 11 + + 0xf8ff ff + + Input: None + DECOMPRESSION-FAILURE MESSAGE_TOO_SHORT + + 0xf800 ffff + + Input: None + DECOMPRESSION-FAILURE MESSAGE_TOO_SHORT + + 0xf801 8108 0002 2200 0222 a092 0523 ffff 0000 0000 0000 00ff 00ff + 0x03ff ffff + + Input: None + DECOMPRESSION-FAILURE MESSAGE_TOO_SHORT + + 0xf801 7008 0002 2200 0222 a092 0523 ffff 0000 0000 0000 00ff 04ff + 0xffff ff + + Input: None + DECOMPRESSION-FAILURE INVALID_CODE_LOCATION + +A.2.5. Input Past the End of a Message + + 0xf803 210e 86a0 460e a042 a04d 1d09 a046 0a1c 07a0 4606 001d 07a0 + 0x46ff 1c02 a046 fa22 a046 021d 10a0 4606 001d 08a0 46ff 22a0 4701 + 0x23 + + Input: 0xfffa 0068 6921 + Output: 0x6869 21 + Cycles: 23 + + Input: 0xfffa 0068 69 + DECOMPRESSION-FAILURE USER_REQUESTED (not enough bits) + + + + + + + + + +Surtees & West Informational [Page 63] + +RFC 4465 SigComp Torture Tests June 2006 + + +A.3. State Handler Tests + +A.3.1. SigComp Feedback Mechanism + + 0xf805 031c 01a0 41a0 5517 6001 070e a04f 0ea0 42a4 7f16 0e0e a042 + 0xa4ff 15a0 44a0 7f01 010e a0c3 a801 0ea0 c5a6 000e a0cc ac00 0ea0 + 0xd9b4 000e a0ee b500 15a0 c606 0001 15a0 cd0c 0001 15a0 da14 0001 + 0x23a0 42a0 c3 + + Input: 0x00 + Output: None + Cycles: 52 + + Input: 0x01 + Output: None + Cycles: 179 + +A.3.2. State Memory Management + + 0xf81b a10f 8602 89a2 041c 01a0 47f9 1763 0508 a068 a070 1763 0307 + 0x34a0 5608 2306 0623 a204 0ea0 4463 0623 0612 6202 a04a 1762 6308 + 0xa058 9fd2 0ea0 4865 0824 8820 6489 0006 6506 2202 16e3 1fa2 1606 + 0x0000 0000 1fa2 1c06 0000 0000 1fa2 2206 0000 0000 1fa2 2e06 0000 + 0x0000 161e 1fa2 2806 0000 0000 1614 208b 8900 0600 160c 1fa2 3406 + 0x0000 0000 1602 2300 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 + 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 + 0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0074 6573 + 0x7400 0000 0100 0200 0300 0400 0300 0200 0100 008e ea4b 43a7 87f9 + 0x010e ef56 7b23 9a34 6b15 a6b4 0fc0 e44d 2cd4 a221 47e6 0aef f2bc + 0x0fb6 af + + Input: 0x00 + Output: None + Cycles: 811 + + Input: 0x01 + Output: None + Cycles: 2603 + + + + + + +Surtees & West Informational [Page 64] + +RFC 4465 SigComp Torture Tests June 2006 + + + Input: 0x02 + Output: None + Cycles: 811 + + Input: 0x03 + Output: None + Cycles: 1805 + + Input: 0x04 + DECOMPRESSION-FAILURE STATE_NOT_FOUND + + Input: 0x05 + Output: None + Cycles: 2057 + + Input: 0x06 + Output: None + Cycles: 1993 + +A.3.3. Multiple Compartments + + 0xf81b 110f 8602 89a2 071c 01a0 45f9 1762 030d 3d06 1762 0537 86a0 + 0x6806 2289 20a1 c062 0006 0006 2203 20a1 c062 0006 0007 22a2 020a + 0x2203 0622 a203 20a1 c062 0006 0020 a1c0 a206 0006 6216 2b20 a7c0 + 0x2000 0600 1622 1fa2 1306 0000 0000 1fa2 1906 0000 0000 1fa2 2506 + 0x0000 0000 1fa2 2b06 0000 0000 2300 0000 0000 0000 1762 0706 101a + 0x1fa2 0706 0000 0000 16ea 1fa2 0d06 0000 0000 16e0 1fa2 1f06 0000 + 0x0000 169f d600 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 + 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 0102 + 0x0304 0506 aca6 0b8e b283 9dbf afc6 3dd2 34c5 d91d 5361 bdd6 ba2a + 0xc65a 47c2 1814 ee07 c275 941d d7a1 4887 9c8d e90e + + Input: 0x00 + Output: None + Cycles: 1809 + + Input: 0x01 + Output: None + Cycles: 1809 + + + + + +Surtees & West Informational [Page 65] + +RFC 4465 SigComp Torture Tests June 2006 + + + Input: 0x02 + Output: None + Cycles: 1809 + + Input: 0x03 + Output: None + Cycles: 1993 + + Input: 0x04 + Output: None + Cycles: 1994 + + Input: 0x05 + Output: None + Cycles: 1804 + + Input: 0x06 + DECOMPRESSION-FAILURE STATE_NOT_FOUND + + Input: 0x07 + DECOMPRESSION-FAILURE STATE_NOT_FOUND + + Input: 0x08 + DECOMPRESSION-FAILURE STATE_NOT_FOUND + +A.3.4. Accessing RFC 3485 State + + 0xf803 a11f a0a6 14ac fe01 2000 1fa0 a606 acff 0121 001f a0a6 0cad + 0x0001 2200 2220 0323 0000 0000 0000 00fb e507 dfe5 e6aa 5af2 abb9 + 0x14ce aa05 f99c e61b a5 + + Input: None + Output: 0x5349 50 + Cycles: 11 + +A.3.5. Bytecode State Creation + + 0xf804 6112 a0be 081e 2008 1e21 060a 0e23 be03 12a0 be08 a050 2008 + 0xa050 a053 140a 2008 a050 a053 0c0a 1606 004f 4b31 1c01 a0b3 fc22 + 0xa0a8 0323 0000 0da0 a8a0 ab06 0a4f 4b32 22a0 5003 2302 + + Input: None + Output: 0x4f4b + Cycles: 66 + + 0xf905 b88c e72c 9103 + + + + + +Surtees & West Informational [Page 66] + +RFC 4465 SigComp Torture Tests June 2006 + + + Input: None + Output: 0x4f4b 31 + Cycles: 7 + + 0xfb24 63cd ff5c f8c7 6df6 a289 ff + + Input: None + Output: 0x4f4b 32 + Cycles: 5 + + 0xf95b 4b43 d567 83 + + Input: None + Output: 0x0000 32 + Cycles: 5 + + 0xf9de 8126 1199 1f + + Input: None + DECOMPRESSION-FAILURE STATE_NOT_FOUND + +Authors' Addresses + + Abigail Surtees + Siemens/Roke Manor Research + Roke Manor Research Ltd. + Romsey, Hants SO51 0ZN + UK + + Phone: +44 (0)1794 833131 + EMail: abigail.surtees@roke.co.uk + URI: http://www.roke.co.uk + + + Mark A. West + Siemens/Roke Manor Research + Roke Manor Research Ltd. + Romsey, Hants SO51 0ZN + UK + + Phone: +44 (0)1794 833311 + EMail: mark.a.west@roke.co.uk + URI: http://www.roke.co.uk + + + + + + + + +Surtees & West Informational [Page 67] + +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] + |