Robust Header Compression A. Surtees Internet-Draft M. West Expires: August 15, 2005 Siemens/Roke Manor Research February 14, 2005 SigComp Torture Tests draft-price-rohc-sigcomp-torture-tests-02.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 15, 2005. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This document provides a set of "torture tests" for implementers of the 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 Expires August 15, 2005 [Page 1] Internet-Draft SigComp Torture Tests February 2005 Change history Changes relative to : 1. Changed name to draft-ietf-rohc-sigcomp-torture-tests-00.txt 2. Addition of test for state creation and self modifying code. 3. Addition of test for reference of static dictionary RFC-3485 [3]. Changes relative to : 1. Added a test for the SigComp dispatcher (covering the case where input is requested that lies beyond the end of a message). 2. Fixed a typo in the input for Section 2.16. Changes relative to : 1. Added tests for the SigComp dispatcher (covering the SigComp Useful Values, the SigComp header for message-based transports, and the record marking scheme for stream-based transports). 2. Added tests for the SigComp state handler (covering the SigComp feedback mechanism, the state memory management and the interaction between multiple compartments). 3. Updated the cost of the sorting instructions based on the new values used in SigComp RFC-3320 [2]. 4. Updated the stack manipulation test to work correctly when the decompression_memory_size is only 2048 bytes. Surtees & West Expires August 15, 2005 [Page 2] Internet-Draft SigComp Torture Tests February 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Torture tests for UDVM . . . . . . . . . . . . . . . . . . . 5 2.1 Bit manipulation . . . . . . . . . . . . . . . . . . . . . 5 2.2 Arithmetic . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3 Sorting . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4 SHA-1 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.5 LOAD and MULTILOAD . . . . . . . . . . . . . . . . . . . . 10 2.6 COPY . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 2.7 COPY-LITERAL and COPY-OFFSET . . . . . . . . . . . . . . . 12 2.8 MEMSET . . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.9 CRC . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.10 INPUT-BITS . . . . . . . . . . . . . . . . . . . . . . . 14 2.11 INPUT-HUFFMAN . . . . . . . . . . . . . . . . . . . . . 15 2.12 INPUT-BYTES . . . . . . . . . . . . . . . . . . . . . . 16 2.13 Stack manipulation . . . . . . . . . . . . . . . . . . . 17 2.14 Program flow . . . . . . . . . . . . . . . . . . . . . . 19 2.15 State creation . . . . . . . . . . . . . . . . . . . . . 20 2.16 STATE-ACCESS . . . . . . . . . . . . . . . . . . . . . . 22 3. Torture tests for dispatcher . . . . . . . . . . . . . . . . 24 3.1 Useful Values . . . . . . . . . . . . . . . . . . . . . . 24 3.2 Message-based transport . . . . . . . . . . . . . . . . . 26 3.3 Stream-based transport . . . . . . . . . . . . . . . . . . 28 3.4 Input past the end of a message . . . . . . . . . . . . . 30 4. Torture tests for state handler . . . . . . . . . . . . . . 32 4.1 SigComp feedback mechanism . . . . . . . . . . . . . . . . 32 4.2 State memory management . . . . . . . . . . . . . . . . . 35 4.3 Multiple compartments . . . . . . . . . . . . . . . . . . 38 4.4 Accessing RFC 3485 State . . . . . . . . . . . . . . . . . 42 4.5 Bytecode state creation . . . . . . . . . . . . . . . . . 43 5. Security considerations . . . . . . . . . . . . . . . . . . 45 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 46 A. UDVM bytecode for the torture tests . . . . . . . . . . . . 46 A.1 Instructions . . . . . . . . . . . . . . . . . . . . . . . 47 A.1.1 Bit manipulation . . . . . . . . . . . . . . . . . . . 47 A.1.2 Arithmetic . . . . . . . . . . . . . . . . . . . . . . 47 A.1.3 Sorting . . . . . . . . . . . . . . . . . . . . . . . 47 A.1.4 SHA-1 . . . . . . . . . . . . . . . . . . . . . . . . 47 A.1.5 LOAD and MULTILOAD . . . . . . . . . . . . . . . . . . 47 A.1.6 COPY . . . . . . . . . . . . . . . . . . . . . . . . . 48 A.1.7 COPY-LITERAL and COPY-OFFSET . . . . . . . . . . . . . 48 A.1.8 MEMSET . . . . . . . . . . . . . . . . . . . . . . . . 48 A.1.9 CRC . . . . . . . . . . . . . . . . . . . . . . . . . 48 A.1.10 INPUT-BITS . . . . . . . . . . . . . . . . . . . . . 48 A.1.11 INPUT-HUFFMAN . . . . . . . . . . . . . . . . . . . 48 Surtees & West Expires August 15, 2005 [Page 3] Internet-Draft SigComp Torture Tests February 2005 A.1.12 INPUT-BYTES . . . . . . . . . . . . . . . . . . . . 48 A.1.13 Stack Manipulation . . . . . . . . . . . . . . . . . 48 A.1.14 Program Flow . . . . . . . . . . . . . . . . . . . . 49 A.1.15 State creation . . . . . . . . . . . . . . . . . . . 49 A.1.16 STATE-ACCESS . . . . . . . . . . . . . . . . . . . . 49 A.2 Dispatcher tests . . . . . . . . . . . . . . . . . . . . . 50 A.2.1 Useful Values . . . . . . . . . . . . . . . . . . . . 50 A.2.2 Message-based transport . . . . . . . . . . . . . . . 50 A.2.3 Stream-based transport . . . . . . . . . . . . . . . . 50 A.2.4 Input past the end of a message . . . . . . . . . . . 50 A.3 State handler tests . . . . . . . . . . . . . . . . . . . 50 A.3.1 SigComp feedback mechanism . . . . . . . . . . . . . . 50 A.3.2 State memory management . . . . . . . . . . . . . . . 50 A.3.3 Multiple compartments . . . . . . . . . . . . . . . . 51 A.3.4 Accessing RFC 3485 State . . . . . . . . . . . . . . . 51 A.3.5 Bytecode state creation . . . . . . . . . . . . . . . 51 Intellectual Property and Copyright Statements . . . . . . . 52 Surtees & West Expires August 15, 2005 [Page 4] Internet-Draft SigComp Torture Tests February 2005 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 Guide [1] offers 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. The draft 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 is the expected output of the code. 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 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 Surtees & West Expires August 15, 2005 [Page 5] Internet-Draft SigComp Torture Tests February 2005 manipulation operation. 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. at (64) :a pad (2) :b pad (2) at (128) JUMP (start) at (255) :start AND ($start, 21845) OR ($a, 42) NOT ($b) LSHIFT ($a, 3) RSHIFT ($b, 65535) OUTPUT (64, 4) AND ($a, $start) OR ($a, $a) NOT ($a) LSHIFT ($b, $a) RSHIFT ($a, $b) OUTPUT (64, 4) END-MESSAGE (0, 0, 0, 0, 0, 0, 0) The expected output of the code is 0x0150 0000 febf 0000. Executing the code should cost a total of 22 UDVM cycles. 2.2 Arithmetic This section gives assembly code to test the ADD, SUBTRACT, MULTIPLY, Surtees & West Expires August 15, 2005 [Page 6] Internet-Draft SigComp Torture Tests February 2005 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. 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 should occur). at (64) :a pad (2) :b pad (2) :type pad (1) :type_lsb pad (1) at (128) INPUT-BYTES (1, type_lsb, !) SUBTRACT ($type, 1) JUMP (start) at (255) :start ADD ($start, 63809) SUBTRACT ($a, 1) MULTIPLY ($a, 1001) DIVIDE ($a, 101) REMAINDER ($a, 11) OUTPUT (64, 4) ADD ($b, $start) SUBTRACT ($b, $type) MULTIPLY ($b, $b) DIVIDE ($a, $b) REMAINDER ($b, $type) OUTPUT (64, 4) END-MESSAGE (0, 0, 0, 0, 0, 0, 0) Surtees & West Expires August 15, 2005 [Page 7] Internet-Draft SigComp Torture Tests February 2005 If the compressed message is 0x00 then the expected 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 should occur. 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 expected 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 expected number of cycles required is 371. N.B. This uses the corrected cost for the sorting instructions, which is 1 + k * (ceiling(log2(k)) + n) not 1 + k * ceiling(log2(k)). 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 additionally 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. Surtees & West Expires August 15, 2005 [Page 8] Internet-Draft SigComp Torture Tests February 2005 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) LOAD (byte_copy_left, test_three) LOAD (byte_copy_right, test_four) SHA-1 (test_three, 65535, hash_value) OUTPUT (hash_value, 20) LOAD (byte_copy_left, test_four) LOAD (byte_copy_right, test_end) 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 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 Surtees & West Expires August 15, 2005 [Page 9] Internet-Draft SigComp Torture Tests February 2005 byte (48, 49, 50, 51, 52, 53, 54, 55) :test_end The expected 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 0xe1d0 a18d 43d3 a689 af08 8e15 6bd0 434a a0c8 31fc 0x4f46 0452 ebb5 6393 4f46 0452 ebb5 6393 4f46 0452 Executing the code is expected to cost a total of 66327 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, any of its operands, or any memory addresses referenced by its operands (in which case decompression failure should occur). at (64) :start pad (1) :start_lsb pad (1) at (128) set (location_a, 128) set (location_b, 132) LOAD (128, 132) LOAD (130, $location_a) LOAD ($location_a, 134) LOAD ($location_b, $location_b) OUTPUT (128, 8) INPUT-BYTES (1, start_lsb, !) MULTIPLY ($start, 2) ADD ($start, 60) MULTILOAD ($start, 3, overlap_start, overlap_end, 128) Surtees & West Expires August 15, 2005 [Page 10] Internet-Draft SigComp Torture Tests February 2005 :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) If the compressed message is 0x00 then the expected output of the code is 0x0084 0084 0086 0086 002a 0080 002a 002a, and the expected cost of executing the code is 36 UDVM cycles. However, if the compressed message is 0x01 or 0x02 then decompression failure is expected to occur while executing the second MULTILOAD instruction. 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. 4. The COPY instruction overwrites the UDVM registers byte_copy_left and byte_copy_right. at (64) :byte_copy_left pad (2) :byte_copy_right pad (2) at (128) LOAD (32, 16384) LOAD (byte_copy_left, 64) Surtees & West Expires August 15, 2005 [Page 11] Internet-Draft SigComp Torture Tests February 2005 LOAD (byte_copy_right, 128) COPY (32, 128, 33) LOAD (64, 16640) COPY (64, 76, 65) OUTPUT (32, 109) END-MESSAGE (0, 0, 0, 0, 0, 0, 0) The expected output of the code is 32 consecutive instances of 0x40 (the ASCII character "@") followed by 77 consecutive instances of 0x41 (the ASCII character "A"). Executing the code should cost a total of 321 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: 1. The COPY-LITERAL or COPY-OFFSET instruction overwrites the value of its destination or offset operand. at (64) :byte_copy_left pad (2) :byte_copy_right pad (2) :destination pad (2) :offset pad (2) at (128) LOAD (32, 16384) LOAD (byte_copy_left, 64) LOAD (byte_copy_right, 128) LOAD (destination, 33) COPY-LITERAL (32, 128, $destination) COPY-LITERAL (68, 8, $destination) LOAD (byte_copy_left, 66) LOAD (byte_copy_right, 74) COPY-OFFSET (8, 6, $destination) Surtees & West Expires August 15, 2005 [Page 12] Internet-Draft SigComp Torture Tests February 2005 LOAD ($offset, 1) COPY-OFFSET ($offset, 5, $destination) OUTPUT (32, 48) END-MESSAGE (0, 0, 0, 0, 0, 0, 0) The expected output of the code is 32 instances of 0x40 followed by 0x0042 004a 0074 4040 4040 004a 0074 4040. The expected cost of executing the code is 208 UDVM cycles. N.B. This uses the corrected cost for COPY-OFFSET, which is 1 + length not 1 + length + offset. 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) LOAD (byte_copy_right, 129) MEMSET (64, 129, 0, 1) MEMSET (129, 15, 64, 15) OUTPUT (128, 16) END-MESSAGE (0, 0, 0, 0, 0, 0, 0) The expected output of the code is 0x8040 4f5e 6d7c 8b9a a9b8 c7d6 e5f4 0312. Executing the code is expected to cost 166 UDVM cycles. Surtees & West Expires August 15, 2005 [Page 13] Internet-Draft SigComp Torture Tests February 2005 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) MEMSET (crc_string_b, 20, 128, 1) INPUT-BYTES (2, crc_value, !) CRC ($crc_value, crc_string_a, 44, !) END-MESSAGE (0, 0, 0, 0, 0, 0, 0) 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) Surtees & West Expires August 15, 2005 [Page 14] Internet-Draft SigComp Torture Tests February 2005 :byte_copy_left pad (2) :byte_copy_right pad (2) :input_bit_order pad (2) :result pad (2) at (128) :start INPUT-BITS ($input_bit_order, result, end_of_message) 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 compressed message is 0x932e ac71, which decompresses to give the output 0x0000 0002 0002 0013 0000 0003 001a 0038. Executing the code should cost 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. at (64) :byte_copy_left pad (2) :byte_copy_right pad (2) :input_bit_order pad (2) :result pad (2) Surtees & West Expires August 15, 2005 [Page 15] Internet-Draft SigComp Torture Tests February 2005 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 compressed message is 0x932e ac71 66d8 6f, which decompresses to give the output 0x0000 0003 0008 04d7 0002 0003 0399 30fe. Executing the code should cost 84 UDVM cycles. 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 inputted (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) Surtees & West Expires August 15, 2005 [Page 16] Internet-Draft SigComp Torture Tests February 2005 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) An example 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 should cost 130 UDVM cycles. 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 stack manipulation instructions overwrite themselves. 3. The CALL instruction specifies a reference operand rather than an absolute value. 4. The PUSH instruction pushes the value contained in stack_fill onto the stack. 5. The stack_location register contains an odd integer. Surtees & West Expires August 15, 2005 [Page 17] Internet-Draft SigComp Torture Tests February 2005 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) OUTPUT (64, 8) POP (64) POP ($stack_location) POP (stack_location) OUTPUT (64, 8) JUMP (address_a) at (192) :address_a LOAD (stack_location, 32) LOAD (next_address, address_c) SUBTRACT ($next_address, address_b) CALL (address_b) at (256) :address_b CALL ($next_address) at (320) :address_c LOAD (stack_location, 383) LOAD (383, 26) MULTILOAD (432, 3, 1, 49153, 32768) RETURN Surtees & West Expires August 15, 2005 [Page 18] Internet-Draft SigComp Torture Tests February 2005 at (448) END-MESSAGE (0, 0, 0, 0, 0, 0, 0) The expected output of the code is 0x0003 0002 0001 0042 0042 0000 0001 0001, and a total of 40 UDVM cycles are expected to be 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) OUTPUT (counter_lsb, 1) :address_b JUMP ($next_address) :address_c ADD ($counter, 1) LOAD (next_address, address_a) SUBTRACT ($next_address, address_d) OUTPUT (counter_lsb, 1) :address_d Surtees & West Expires August 15, 2005 [Page 19] Internet-Draft SigComp Torture Tests February 2005 COMPARE ($counter, 6, $next_address, address_c, address_e) :address_e SUBTRACT ($switch_counter, 1) LOAD (next_address, address_a) SUBTRACT ($next_address, address_f) OUTPUT (counter_lsb, 1) :address_f SWITCH (4, $switch_counter, address_g, $next_address, address_c, address_e) :address_g END-MESSAGE (0, 0, 0, 0, 0, 0, 0) The expected output of the code is 0x0001 0102 0203 0304 0405 0506 0707 0708 0808 0909, and a total of 131 UDVM cycles are expected to be 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 state_identifier than the minimum_access_length. at (64) :byte_copy_left pad (2) :byte_copy_right pad (2) :states pad (1) :states_lsb pad (1) set (state_length, 10) Surtees & West Expires August 15, 2005 [Page 20] Internet-Draft SigComp Torture Tests February 2005 at (128) INPUT-BYTES (1, states_lsb, !) :test_one LSHIFT ($states, 13) COMPARE ($states, 32768, test_two, create_state_a, create_state_a) :create_state_a STATE-CREATE (state_length, state_address, 0, 20, 0) :test_two LSHIFT ($states, 1) COMPARE ($states, 32768, test_three, free_state, free_state) :free_state STATE-FREE (state_identifier, 6) :test_three LSHIFT ($states, 1) COMPARE ($states, 32768, end, create_state_b, create_state_b) :create_state_b END-MESSAGE (0, 0, state_length, state_address, 0, 20, 0) :end END-MESSAGE (0, 0, 0, 0, 0, 0, 0) at (512) :state_address byte (34, 162, 6, 4, 22, 224, 116, 101, 115, 116) :state_identifier byte (32, 84, 55, 65, 83, 248, 254, 122, 106, 151, 203, 121, 224, 24, 194, 221, 214, 143, 254, 155) Upon reaching the END-MESSAGE instruction the UDVM does not output Surtees & West Expires August 15, 2005 [Page 21] Internet-Draft SigComp Torture Tests February 2005 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 should result in either 0 or 1 new state items being created in the chosen compartment. The following table lists eight different 1-byte compressed messages and whether the message should cause a new state item to be created in the compartment. The number of UDVM cycles required to execute the code is also given: Compressed message: State item in compartment: UDVM cycles: 0x00 No 9 0x01 Yes 19 0x02 No 10 0x03 Yes 20 0x04 Yes 20 0x05 Yes 30 0x06 No 21 0x07 Yes 31 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 code assumes that the state item created in the previous section is available to the state handler. Surtees & West Expires August 15, 2005 [Page 22] Internet-Draft SigComp Torture Tests February 2005 at (64) :byte_copy_left pad (2) :byte_copy_right pad (2) :type pad (1) :type_lsb pad (1) :state_value pad (4) at (128) INPUT-BYTES (1, type_lsb, !) 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, 6, 4, state_value, 0) OUTPUT (state_value, 4) JUMP (end) :error_conditions 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, 6, 5, state_value, 0) JUMP (end) at (484) :end END-MESSAGE (0, 0, 0, 0, 0, 0, 0) Surtees & West Expires August 15, 2005 [Page 23] Internet-Draft SigComp Torture Tests February 2005 at (512) :state_identifier byte (32, 84, 55, 65, 83, 248, 254, 122, 106, 151, 203, 121, 224, 24, 194, 221, 214, 143, 254, 155) If the compressed message is 0x00 then the expected output of the code is 0x7465 7374 and a total of 21 UDVM cycles are expected to be used. If the compressed message is 0x01 then the code should also output 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 should occur. 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. 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). 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 should 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) Surtees & West Expires August 15, 2005 [Page 24] Internet-Draft SigComp Torture Tests February 2005 :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 (128) LOAD (byte_copy_left, 32) LOAD (byte_copy_right, 33) :test_version COMPARE ($sigcomp_version, 1, !, test_state_access, !) :test_state_access COMPARE ($partial_state_id_length, 0, !, test_length_equals_zero, test_state_length) :test_length_equals_zero COMPARE ($state_length, 0, !, end, !) :test_state_length COMPARE ($state_length, 960, !, test_udvm_memory, !) :test_udvm_memory INPUT-BYTES (1, check_memory_lsb, !) ADD ($check_memory, $udvm_memory_size) SUBTRACT ($check_memory, 1) COPY (32, 1, $check_memory) :test_udvm_cycles INPUT-BYTES (1, check_cycles_lsb, !) ; 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) Surtees & West Expires August 15, 2005 [Page 25] Internet-Draft SigComp Torture Tests February 2005 ADD ($remaining_cycles, 1000) MULTIPLY ($remaining_cycles, $cycles_per_bit) ADD ($remaining_cycles, $check_cycles) set (cycles_used_by_bytecode, 982) SUBTRACT ($remaining_cycles, cycles_used_by_bytecode) COPY (32, $remaining_cycles, 32) :end 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 should be uploaded as part of the SigComp message (no compressed data is required in this case). This should cause the UDVM to request creation of a new state item, and should use a total of 966 UDVM cycles. Subsequent tests should 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 2-byte compressed message is required for the second and subsequent cases: if the message is 0x0000 then the UDVM should successfully terminate using exactly the number of available UDVM cycles. However, if the message is 0x0001 then the UDVM should use too many cycles and hence terminate with decompression failure. Furthermore if the message is 0x0100 then decompression failure should occur because the UDVM attempts to write beyond its available memory. 3.2 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. Surtees & West Expires August 15, 2005 [Page 26] Internet-Draft SigComp Torture Tests February 2005 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: :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 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 should successfully output the decompression memory size or whether it should 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 Surtees & West Expires August 15, 2005 [Page 27] Internet-Draft SigComp Torture Tests February 2005 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 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 should each use a total of 5 UDVM cycles. 3.3 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) 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 Expires August 15, 2005 [Page 28] Internet-Draft SigComp Torture Tests February 2005 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 should use the delimiters to partition the stream into two distinct SigComp messages. Both of these messages should successfully output the decompression memory size (as a 2-byte value), followed by five consecutive 0xff bytes to test that the record marking scheme is working correctly. A total of 11 UDVM cycles should be 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 Surtees & West Expires August 15, 2005 [Page 29] Internet-Draft SigComp Torture Tests February 2005 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 Note that when a decompression failure occurs it is an implementation decision whether to close the entire stream or whether to ignore the error and attempt to decompress subsequent messages in the stream. 3.4 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 inputted (e.g. by the INPUT-BITS instruction). In this case the remaining partial byte should 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 Surtees & West Expires August 15, 2005 [Page 30] Internet-Draft SigComp Torture Tests February 2005 INPUT-BITS (9, result, !) ; Attempt to read 7 bytes INPUT-BYTES (7, result, next_bytes) OUTPUT (result, 7) JUMP (bits) :next_bytes ; Read 7 bits - this should remove the byte alignment of the message ; If the bits have not been thrown away where they should then the ; message will be 1 byte longer than necessary INPUT-BITS (7, result, !) ; Read 2 bytes INPUT-BYTES (2, result, !) OUTPUT (result, 2) :bits ; Attempt to read 16 bits INPUT-BITS (16, result, next_bits) OUTPUT (result, 2) JUMP (end_message) :next_bits ; Read 8 bits INPUT-BITS (8, result, !) OUTPUT (result_lsb, 1) :end_message END-MESSAGE (0, 0, 0, 0, 0, 0, 0) If the compressed message is 0xfffa 0068 6921 then the code is expected to terminate successfully with the output 0x6869 21, and a total of 23 UDVM cycles should be used. However, if the compressed message is 0xfffa 0068 69 then decompression failure is expected to occur (after outputting the message 0x6869). Surtees & West Expires August 15, 2005 [Page 31] Internet-Draft SigComp Torture Tests February 2005 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, !) COMPARE ($type, 1, short_feedback_item, long_feedback_item, !) :short_feedback_item Surtees & West Expires August 15, 2005 [Page 32] Internet-Draft SigComp Torture Tests February 2005 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) LOAD (length_of_partial_state_id_b, 3072) LOAD (length_of_partial_state_id_c, 5120) LOAD (terminate_returned_parameters, 5376) 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) 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. 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: +---+---+---+---+---+---+---+---+ Surtees & West Expires August 15, 2005 [Page 33] Internet-Draft SigComp Torture Tests February 2005 | 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). Executing the bytecode in this case should cost a total of 52 UDVM cycles. If the compressed message is 0x01 then the long version of the feedback item is used. In this case 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. Executing the bytecode in this case should cost a total of 179 UDVM cycles. 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). 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 Surtees & West Expires August 15, 2005 [Page 34] Internet-Draft SigComp Torture Tests February 2005 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) at (128) MULTILOAD (byte_copy_left, 2, state_start, order_data) INPUT-BYTES (1, type_lsb, !) COMPARE ($type, 5, general_test, large_state, verify_state) :general_test Surtees & West Expires August 15, 2005 [Page 35] Internet-Draft SigComp Torture Tests February 2005 COMPARE ($type, 3, start, state_present, state_not_present) :start MULTIPLY ($type, 6) ADD ($type, order_data) LOAD (order, $type) ADD ($type, 6) :loop COPY ($order, 2, state_retention_priority) COMPARE ($order, $type, continue, end, !) :continue 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 STATE-ACCESS (state_identifier_a, 6, 0, 0, 0, 0) STATE-ACCESS (state_identifier_b, 6, 0, 0, 0, 0) 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 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 Surtees & West Expires August 15, 2005 [Page 36] Internet-Draft SigComp Torture Tests February 2005 END-MESSAGE (0, 0, 0, 0, 0, 0, 0) at (512) :state_start byte (116, 101, 115, 116) :order_data 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) :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, taking the values 0x00 to 0x06 in ascending order (so the compressed message should be 0x00 the first time the code is run, 0x01 the second and so on). When the compressed message is 0x00, 0x01 or 0x02 the code makes three state creation requests per message, establishing a total of nine states in the compartment. Note however that as new states are created some of the existing states should be pushed out of the compartment due to lack of memory. Surtees & West Expires August 15, 2005 [Page 37] Internet-Draft SigComp Torture Tests February 2005 When the compressed message is 0x03 the code checks that the correct state items remain in the compartment. Decompression should successfully terminate in this case. When the compressed message is 0x04 the code attempts to access a state that has been pushed out of the compartment by states of higher priority. Decompression failure should occur in this case because the relevant state is no longer available. When the compressed message is 0x05 the code attempts to create a state that is larger than the entire compartment. In this case the state handler should save only the first part of the requested state. When the compressed message is 0x06 the code verifies that the first part of the large state item created by the previous message has been successfully saved. The cost in UDVM cycles for each compressed message is given below (except for message 0x04 where decompression failure should occur): Compressed message: 0x00 0x01 0x02 0x03 0x04 0x05 0x06 Cost in UDVM cycles: 811 2603 811 1805 N/A 2057 1993 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: 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: Surtees & West Expires August 15, 2005 [Page 38] Internet-Draft SigComp Torture Tests February 2005 at (64) :byte_copy_left pad (2) :byte_copy_right pad (2) :type pad (1) :type_lsb pad (1) at (128) MULTILOAD (byte_copy_left, 2, state_start, state_end) INPUT-BYTES (1, type_lsb, !) COMPARE ($type, 3, create_state, overwrite_state, temp) :temp COMPARE ($type, 5, overwrite_state, access_state, error_conditions) :create_state ADD ($type, state_start) STATE-CREATE (448, $type, 0, 6, 0) :duplicate_state ADD ($type, 3) STATE-CREATE (448, $type, 0, 6, 0) 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) Surtees & West Expires August 15, 2005 [Page 39] Internet-Draft SigComp Torture Tests February 2005 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 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)) set (temp_two, (state_start + 3)) set (temp_three, (state_end - 1)) :state_identifier_a byte (172, 166, 11, 142, 178, 131) :state_identifier_b byte (157, 191, 175, 198, 61, 210) :state_identifier_c byte (52, 197, 217, 29, 83, 97) Surtees & West Expires August 15, 2005 [Page 40] Internet-Draft SigComp Torture Tests February 2005 :state_identifier_d byte (189, 214, 186, 42, 198, 90) :state_identifier_e byte (71, 194, 24, 20, 238, 7) :state_identifier_f byte (194, 117, 148, 29, 215, 161) :state_identifier_g byte (72, 135, 156, 141, 233, 14) 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 to State G. The states should be distributed amongst 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 should 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 successfully terminate 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 Surtees & West Expires August 15, 2005 [Page 41] Internet-Draft SigComp Torture Tests February 2005 (except for messages 0x06, 0x07 and 0x08 where decompression failure is expected 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 +-----------------------------+ | 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 result. Surtees & West Expires August 15, 2005 [Page 42] Internet-Draft SigComp Torture Tests February 2005 at (32) :input pad (1) :input2 pad (1) :input3 pad (1) 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 expected output of the code is 0x5349 50, and a total of 11 UDVM cycles are expected to be used. 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 so that it includes testing self-modifying byte code, loading byte code in special memory areas, and correct initialization order of the UDVM. 1. Three items of bytecode state are created. 2. The bytecode is loaded using partial state identifier. 3. The bytecode is loaded using partial state identifier. Part of the loaded memory is reserved area, which is overwritten after loading the bytecode. 4. The byte loading fails because partial state identifier is too short. at (30) :save_area1 set (saved_instr1, (save_area1 + (code_start2 - start_saved))) Surtees & West Expires August 15, 2005 [Page 43] Internet-Draft SigComp Torture Tests February 2005 at (80) :save_area2 set (saved_instr2, (save_area2 + (code_start2 - start_saved))) at (128) :code_start COPY (start_saved, saved_len, save_area1) set (modify1, (save_area1 + 5)) LOAD (modify1, 0x1e03) STATE-CREATE (saved_len, save_area1, saved_instr1, 6, 10) COPY (start_saved, saved_len, save_area2) STATE-CREATE (saved_len, save_area2, saved_instr2, 20, 10) OUTPUT (ok1, 3) END-MESSAGE (0, 0, saved_len, save_area2, saved_instr2, 12, 10) :ok1 byte (0x4f, 0x4b, 0x31) set (saved_len, (end_saved - start_saved)) :start_saved byte (0x4f, 0x4b, 0x32) :code_start2 ; OUTPUT (save_area2, 3) byte (0x22, 0xa0, 0x50, 0x03) ; END-MESSAGE (0, 0, 0, 0, 0, 0, 0) byte (0x23) :end_saved The expected output of the first message is 0x4f4b 31, and a total of 50 UDVM cycles are expected to be used. The second message consists of SigComp header and partial state identifier: 0xfb24 63cd ff5c f8c7 6df6 a289 ff. The expected output from the second message is 0x4f4b 31, and a total of 5 UDVM cycles are expected to be used. The third message consists of SigComp header and partial state Surtees & West Expires August 15, 2005 [Page 44] Internet-Draft SigComp Torture Tests February 2005 identifier: 0xf95b 4b43 d567 83. The expected output from the third message is 0x0000 31, and a total of 5 UDVM cycles are expected to be used. The fourth message consists of SigComp header and partial state identifier: 0xf9de 8126 1199 1f. Loading of the bytecode should fail because the partial state ID length is too short (6, when 20 bytes is required). First message: 0xf803 6112 a0ae 081e 0e23 be03 2008 1e21 060a 12a0 ae08 a050 2008 0xa050 a053 140a 22a0 ab03 2300 0008 a050 a053 0c0a 4f4b 314f 4b32 0x22a0 5003 23 Second message: 0xfbf8 07bf 971e f697 c3e3 5894 86 Third message: 0xf95b 4b43 d567 83 Fourth message: 0xf9de 8126 1199 1f 5. Security considerations This draft describes torture tests for the SigComp protocol RFC-3320 [2]. Consequently the security considerations for this draft match those of SigComp. 6. Acknowledgements Thanks to Pekka Pessi and Richard Price for test contributions. 7 References [1] Surtees, A. and M. West, "SigComp User Guide", draft-ietf-rohc-sigcomp-userguide-01.txt (work in progress), February 2004. [2] Price, R., Borman, C., Christoffersson, J., Hannu, H., Liu, Z. and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, January 2003. [3] Garcia-Martin, M., Ott, J., Borman, C., Price, R. and A. Roach, Surtees & West Expires August 15, 2005 [Page 45] Internet-Draft SigComp Torture Tests February 2005 "The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp)", RFC 3485, February 2003. [4] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 3667, February 2004. [5] Bradner, S., "Intellectual Property Rights in IETF Technology", BCP 79, RFC 3668, February 2004. 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 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 and any compressed message required by the code. In some cases the test is designed to be run several times with different compressed messages appended to the code; for each of these tests the first compressed message is always supplied. 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 Surtees & West Expires August 15, 2005 [Page 46] Internet-Draft SigComp Torture Tests February 2005 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 A.1.2 Arithmetic 0xf80a a11c 01a0 459f 9f07 2201 16a0 7600 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 2300 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 A.1.4 SHA-1 0xf808 710d a0c3 03a0 4422 a044 140d a0c6 38a0 4422 a044 140e 86a0 0xfe0e a042 a0ff 0da0 feff 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 A.1.5 LOAD and MULTILOAD 0xf803 710e 87a0 840e a082 c080 0ec0 80a0 860e c084 c084 2287 081c Surtees & West Expires August 15, 2005 [Page 47] Internet-Draft SigComp Torture Tests February 2005 0x01a0 419f 8908 2002 0620 3c0f 6003 a0a3 a0b2 870f 6004 2a87 c080 0xc084 2287 0823 00 A.1.6 COPY 0xf801 e10e 208e 0e86 860e a042 8712 2087 210e 8680 4100 1286 a04c 0xa041 2220 a06d 23 A.1.7 COPY-LITERAL and COPY-OFFSET 0xf802 f10e 208e 0e86 860e a042 870e a044 2113 2087 2213 a044 0822 0x0e86 a042 0ea0 42a0 4a14 0806 220e 6301 1463 0522 2220 3023 A.1.8 MEMSET 0xf801 810e 8687 0ea0 42a0 8115 86a0 8100 0115 a081 0f86 0f22 8710 0x23 A.1.9 CRC 0xf801 a115 a046 1801 0115 a05e 1487 011c 02a0 449f 931b 62a0 462c 0x9f8d 2362 cb A.1.10 INPUT-BITS 0xf801 511d 62a0 4614 22a0 4602 0622 010a 2207 0622 0116 ee23 932e 0xac71 A.1.11 INPUT-HUFFMAN 0xf801 d11e a046 1c02 6200 6262 6200 ff00 22a0 4602 0622 010a 2207 0x0622 0116 e623 932e ac71 66d8 6f 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 932e ac71 66d8 6fb1 592b 0xdc9a 9734 d847 a733 874e 1bcb cd51 b5dc 9659 9d6a 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 Surtees & West Expires August 15, 2005 [Page 48] Internet-Draft SigComp Torture Tests February 2005 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 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 A.1.15 State creation 0xf819 e11c 01a0 459f 9f04 220d 1762 8f0c 0606 200a 8900 1400 0422 0x0117 628f 0a06 0621 a20a 0604 2201 1762 8f0e 0606 2300 000a 8900 0x1400 2300 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 a206 0x0416 e074 6573 7420 5437 4153 f8fe 7a6a 97cb 79e0 18c2 ddd6 8ffe 0x9b00 A.1.16 STATE-ACCESS 0xf819 411c 01a0 459f 9f17 6201 060d 1c1f 8914 0000 0089 1f89 1406 0x04a0 4600 22a0 4604 16a1 4517 6203 0610 1b1f 8714 0000 0000 16a1 0x351f 8913 0604 a046 0016 a12a 1f89 1406 05a0 4600 16a1 1f00 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 Surtees & West Expires August 15, 2005 [Page 49] Internet-Draft SigComp Torture Tests February 2005 0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0023 0000 0000 0x0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0020 5437 0x4153 f8fe 7a6a 97cb 79e0 18c2 ddd6 8ffe 9b00 A.2 Dispatcher tests A.2.1 Useful Values 0xf805 b10e 8620 0ea0 4221 1742 019f 9808 9f98 1743 009f 9007 0d17 0x4400 fb3d fb17 44a3 c0fc 07fc 1c01 a047 f506 2340 0723 0112 2001 0x631c 01a0 49e6 0ea0 4443 0622 0308 2208 0622 a3e8 0822 4106 2264 0x0722 a3d6 1220 6220 2300 00a3 c086 8706 0000 A.2.2 Message-based transport The bytecode for this test is given in Section 3.2. A.2.3 Stream-based transport The bytecode for this test is given in Section 3.3. A.2.4 Input past the end of a message 0xf804 010e 86a0 460e a042 a04d 1d09 a046 9f96 1c07 a046 0b22 a046 0x0716 121d 07a0 469f 851c 02a0 469f 7f22 a046 021d 10a0 460b 22a0 0x4602 160c 1d08 a046 9f6a 22a0 4701 23 A.3 State handler tests A.3.1 SigComp feedback mechanism 0xf805 031c 01a0 419f 1f17 6001 070e 9f19 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 c300 A.3.2 State memory management 0xf81b a10f 8602 89a2 041c 01a0 479f 9917 6305 08a0 68a0 7017 6303 0x0734 a056 0823 0606 23a2 040e a044 6306 2306 1262 02a0 4a17 6263 0x08a0 589f 710e a048 6508 2488 2064 8900 0665 0622 0216 e31f a216 0x0600 0000 001f a21c 0600 0000 001f a222 0600 0000 001f a22e 0600 0x0000 0016 1e1f a228 0600 0000 0016 1420 8b89 0006 0016 0c1f a234 0x0600 0000 0016 0223 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 Surtees & West Expires August 15, 2005 [Page 50] Internet-Draft SigComp Torture Tests February 2005 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 af00 A.3.3 Multiple compartments 0xf81b 110f 8602 89a2 071c 01a0 459f 9917 6203 0d3d 0617 6205 3786 0xa068 0622 8920 a1c0 6200 0600 0622 0320 a1c0 6200 0600 0722 a202 0x0a22 0306 22a2 0320 a1c0 6200 0600 20a1 c0a2 0600 0662 162b 20a7 0xc020 0006 0016 221f a213 0600 0000 001f a219 0600 0000 001f a225 0x0600 0000 001f a22b 0600 0000 0023 0000 0000 0000 0017 6207 0610 0x1a1f a207 0600 0000 0016 ea1f a20d 0600 0000 0016 e01f a21f 0600 0x0000 0016 9fd6 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 00 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 A.3.5 Bytecode state creation The bytecode for this test is given in Section 4.5. Surtees & West Expires August 15, 2005 [Page 51] Internet-Draft SigComp Torture Tests February 2005 Intellectual Property Statement 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2005). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. This Internet-Draft will expire on August 15, 2005. Surtees & West Expires August 15, 2005 [Page 52]