Network Working Group A. Surtees Internet-Draft M. West Expires: December 25, 2003 Siemens/Roke Manor A. Roach dynamicsoft June 26, 2003 Implementer's Guide for SigComp draft-ietf-rohc-sigcomp-impl-guide-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes common misinterpretations and some ambiguities in the Signalling Compression Protocol (SigComp), and offers guidance to developers to clarify any resultant problems. SigComp defines a scheme for compressing messages generated by application protocols such as the Session Initiation Protocol (SIP). This document does not address compression specific issues such as different compressor types and bytecode. This information can be found in a separate document. Surtees, et al. Expires December 25, 2003 [Page 1] Internet-Draft Implementer's Guide for SigComp June 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Decompression Memory Size . . . . . . . . . . . . . . . . . . 3 2.1 Bytecode within Decompression Memory Size . . . . . . . . . . 3 2.2 Default Decompression Memory Size . . . . . . . . . . . . . . 3 3. UDVM Instructions . . . . . . . . . . . . . . . . . . . . . . 4 3.1 Data Input Instructions . . . . . . . . . . . . . . . . . . . 4 3.2 STATE-FREE . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4. Byte Copying Rules . . . . . . . . . . . . . . . . . . . . . . 5 5. State Retention Priority . . . . . . . . . . . . . . . . . . . 5 6. The I-bit in Requested Feedback . . . . . . . . . . . . . . . 5 7. Feedback when SMS is zero . . . . . . . . . . . . . . . . . . 6 8. Dynamic Update of Resources . . . . . . . . . . . . . . . . . 6 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 9 Surtees, et al. Expires December 25, 2003 [Page 2] Internet-Draft Implementer's Guide for SigComp June 2003 1. Introduction SigComp [1] defines the Universal Decompressor Virtual Machine (UDVM) for decompressing messages sent by a compliant compressor. SigComp further describes mechanisms to deal with state handling, message structure, and other details. While the behavior of the decompressor is specified in great detail, the behavior of the compressor is left as a choice for the implementer. During implementation and interoperability tests, some areas of SigComp that require clarification have been identified. The sections that follow enumerate the problem areas identified in the specification, and attempt to provide clarification. 2. Decompression Memory Size 2.1 Bytecode within Decompression Memory Size SigComp [1] states that the default Decompression Memory Size (DMS) is 2K. The UDVM memory size is defined in section 7 to be (DMS - sizeof (sigcomp_msg)) for messages transported over UDP and (DMS / 2) for those transported over TCP. This means that when the message contains the bytecode (as it will for at least the first message) there will actually be two copies of the bytecode within the decompressor memory (see Figure 1). It is correct that there are two copies of the bytecode within the decompressor memory, in this case. |<----------------------------DMS--------------------------------->| |<-----sigcomp message---->|<------------UDVM memory size--------->| +-+----------+-------------+-----+----------+----------------------+ | | bytecode | comp msg | | bytecode | circular buffer | +-+----------+-------------+-----+----------+----------------------+ ^ ^ | | Sigcomp header Low bytes of UDVM Figure 1 : Bytecode and UDVM memory size within DMS 2.2 Default Decompression Memory Size For many implementations, the length of decompression bytecode sent is in the range of three to four hundred bytes. Because SigComp specifies a default DMS of 2K, the described scheme seriously restricts the size of the circular buffer, and of the compressed message itself. In some cases, this set of circumstances has a damaging effect on the compression ratio; for others, it makes it Surtees, et al. Expires December 25, 2003 [Page 3] Internet-Draft Implementer's Guide for SigComp June 2003 completely impossible to send certain messages compressed. To address this problem, those mandating the use of Sigcomp should also provide further specification for their application that mandates the use of an appropriately sized DMS. 3. UDVM Instructions 3.1 Data Input Instructions When inputting data from the compressed message, the INPUT-BYTES (section 9.4.2) and INPUT-BITS (section 9.4.3) instructions both have the paragraph: "If the instruction requests data that lies beyond the end of the SigComp message, no data is returned. Instead the UDVM moves program execution to the address specified by the address operand." The intent is that if n bytes/bits are requested but only m are left in the message (where m < n) then no bytes/bits should be returned to the UDVM and the m bytes/bits that are there should remain in the message unchanged. For example, the remaining bytes of message are: 0x01 0x02 0x03 and the UDVM encounters an INPUT-BYTES (6, a, b) instruction. The decompressor dispatcher returns no bytes and jumps to the instruction specified by b. This contains an INPUT-BYTES (2, c, d) instruction so the decompressor dispatcher successfully returns the bytes 0x01 and 0x02. In the case where an INPUT-BYTES instruction follows an INPUT-BITS instruction that has left a partial byte in the message, the partial byte should still be thrown away even if there are not enough bytes to input. INPUT-BYTES (0, a, b) can be used to flush out a partial byte. 3.2 STATE-FREE The STATE-FREE instruction does not check the minimum_access_length. This is correct because the state cannot be freed until the application has authenticated the message. The lack of checking does not pose a security risk because, if the sender has enough information to create authenticated messages, then sending messages that save state can push previous state out of storage anyway. The STATE-FREE instruction can only free state in the compartment that corresponds to the message being decompressed. Attempting to Surtees, et al. Expires December 25, 2003 [Page 4] Internet-Draft Implementer's Guide for SigComp June 2003 free state either from another compartment or that is locally available has no effect. 4. Byte Copying Rules Section 8.4 specifies the byte copying rules and includes a list of the instructions that obey them. STATE-CREATE is not in this list but END-MESSAGE is. This caused confusion due to the fact that neither instruction actually does any byte copying, rather both instructions give information to the state-handler to create state. Logically both instructions should have the same information about byte copying. When state is created by the state-handler (whether the instruction was from END-MESSAGE or STATE-CREATE), the byte copying rules of section 8.4 apply. Note that if the contents of the UDVM changes between the occurrence of the STATE-CREATE instruction and the state being created the bytes that are stored are those in the buffer at the time of creation (i.e. when the message has been decompressed and authenticated). 5. State Retention Priority For state_retention_priority, 65535 < 0 < 1 < ... < 65534. This is slightly counter intuitive but is correct. 6. The I-bit in Requested Feedback The I-bit in requested feedback is a mechanism by which a compressor may tell a remote endpoint that it is not going to access any local state items. By doing so, it gives the remote endpoint the option of not advertising them in subsequent messages. Setting the I-bit does not obligate the remote endpoint to cease sending advertisements. The remote endpoint should still advertise its parameters such as DMS and state memory size (SMS). (This is particularly important; if the sender of the first message sets the I-bit, it will still want the advertisement of parameters from the receiver. If it doesn't receive these, it has to assume the default parameters which will affect compression efficiency.) The endpoint receiving an I-bit of 1 can reclaim the memory used to store the locally available state items. However, this has NO impact on any state that has been created by the sender using END-MESSAGE or STATE-CREATE instructions. Surtees, et al. Expires December 25, 2003 [Page 5] Internet-Draft Implementer's Guide for SigComp June 2003 7. Feedback when SMS is zero If an endpoint receives a request for feedback then it should return the feedback even if its SMS is zero. The storage overhead of the requested feedback is NOT part of the SMS. 8. Dynamic Update of Resources Decompressor resources such as SMS and DMS can be dynamically updated at the compressor by use of the SMS and DMS bits in returned parameters feedback (section 9.4.9). Changing resources dynamically (apart from initial advertisements for each compartment) is not expected to happen very often. If additional resources are advertised to a compressor then it is up to the implementation at the compressor whether or not to make use of these resources. For example, if the decompressor advertises 8k SMS but the compressor only has 4k SMS then the compressor may choose not to use the extra 4k (e.g. in order to monitor state saved at the decompressor). In this case, there is no synchronisation problem. The compressor must not use more than the most recently advertised resources. Note that the compressor SMS is unofficial (enables compressor to monitor decompressor state) and is separate from the SMS advertised by the decompressor. Reducing the resources has potential synchronisation issues and so should not be done unless absolutely necessary. If this is the case then the memory should not be reclaimed until the remote endpoint has acknowledged the message sent with the advertisement. If state must be deleted to accommodate a reduction in SMS then both endpoints should delete it according to the state retention priority (section 6.2). The compressor should use up to the amount of resources most recently advertised. 9. Security Considerations This document provides clarifications to SigComp [1] but does not change it. Consequently the security considerations are the same as those for SigComp [1]. 10. Acknowledgements Largely through being foolish enough to be authors of, or to have implemented, SigComp we would like to thank the following: Richard Price (richard.price@roke.co.uk) Lajos Zaccomer (lajos.zaccomer@eth.ericsson.se) Timo Forsman (timo.forsman@xt.etx.ericsson.se) Surtees, et al. Expires December 25, 2003 [Page 6] Internet-Draft Implementer's Guide for SigComp June 2003 Tor-Erik Malen (tor-erik.malen@lmf.ericsson.se) Jan Christoffersson (jan.christoffersson@epl.ericsson.se) Kwang Mien Chan (chankm@icr.a-star.edu.sg) William Kembery (wkember@lts.ncsc.mil) Pekka Pessi (pekka.pessi@nokia.com) for their confusion, suggestions and comments. References [1] Price, R., Borman, C., Christoffersson, J., Hannu, H., Liu, Z. and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320, January 2003. [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M. and E. Schooler, "Session Initiation Protocol (SIP)", RFC 3261, June 2002. [3] Bradner, S., "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. Authors' Addresses Abigail Surtees Siemens/Roke Manor 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 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, et al. Expires December 25, 2003 [Page 7] Internet-Draft Implementer's Guide for SigComp June 2003 Adam Roach dynamicsoft 5100 Tennyson Pkwy Suite 1200, Plano TX 75024 US Phone: +1 972 473 2233 EMail: adam@dynamicsoft.com URI: http://www.dynamicsoft.com Surtees, et al. Expires December 25, 2003 [Page 8] Internet-Draft Implementer's Guide for SigComp June 2003 Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. This Internet-Draft will expire on December 25, 2003. Surtees, et al. Expires December 25, 2003 [Page 9]