Network Working Group A. B. Roach Internet-Draft dynamicsoft Expires: April 1, 2003 October 1, 2002 A Negative Acknowledgement Mechanism for Signalling Compression draft-roach-sigcomp-nack-00 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. This Internet-Draft will expire on April 1, 2003. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes a mechanism that allows Signalling Compression (SigComp) implementations to report precise error information upon receipt of a message which cannot be decompressed. This negative feedback can be used by the recipient to make fine- grained adjustments to the compressed message before retransmitting it, allowing for rapid and efficient recovery from error situations. Roach Expires April 1, 2003 [Page 1] Internet-Draft SigComp NACK October 2002 1. Introduction Signalling Compression (see reference [1]), often called "SigComp", defines a protocol for transportation of compressed messages between two nodes. One of the key features of SigComp is the ability of the sending node to request that the receiving node store state objects for later retrieval. 1.1 The Problem While the "SigComp - Extended Operations" document (reference [2]) defines a mechanism that allows for confirmation of state creation, operational experience with the SigComp protocol has demonstrated that there are still several circumstances in which a sender's view of the shared state differs from the reciever's view. A non- exhaustive list of the circumstances in which such failures may occur are detailed below. 1.1.1 Compartment Disposal In SigComp, stored states are associated with compartments. Conceptually, the compartments represent one instance of a remote application. These compartments are used to limit the amount of state that each remote application is allowed to store. Compartments are created upon receipt of a valid SigComp message from a remote application. In the current protocol, applcations are expected to signal when they are finished with a compartment so that it can be deleted (by using the S-bit in requested feedback data). Unfortunately, expecting the applications to be well-behaved is not suffcient to prevent state from piling up. Unexpected client failures, reboots, and loss of connectivity can cause compartments to become "stuck" and never removed. To prevent this situation, it becomes necessary to implement a scheme by which compartments that appear disused may eventually be discarded. While the preceding facts make such a practice necessary, discarding compartments without explicit signalling can have the unfortunate side effect that active compartments are sometimes discarded. This leads to a different view of state between the server and the client. 1.1.2 Client Restart The prime motivation behind SigComp was compression of messages to be sent over a radio interface. Consequently, almost all deployments of SigComp will involve a mobile unit as one of the the endpoints. Such units are not generally highly available. Node restarts (due to e.g. a battery running out) will induce situations in which the network- Roach Expires April 1, 2003 [Page 2] Internet-Draft SigComp NACK October 2002 based server beleives that the client contains several states that are no longer actually available. 1.1.3 Server Failover Many high-availability schemes for IP servers involve load distribution through a set of redundant servers that appear to the sending user to be routers to the same destination IP address. In these systems, the traffic to a failed server is routed to an equivalently provisioned server. Although SigComp state can be replicated amongst such a cluster of servers, maintaining integrity of such states requires a two-phase commit process, which adds a great deal of complexity to the server, and can degrade performance significantly. 1.2 The Solution Although SigComp allows returned SigComp parameters to signal that all states have been lost (by setting "state_memory_size" to 0 for one message in the reverse direction), such an approach provides an incomplete solution to the problem. In addition to wiping out an entire compartment when only one state is corrupt or missing, this approach suffers from the unfortunate behavior that it requires a compressed application-level message in the reverse direction before recovery can occur. In many cases, such as SIP-based mobile terminals, such messages may be seldom; in others (pure client/server deployments), they won't ever happen. The proposed solution to this problem is a simple Negative Acknowledgement (NACK) mechanism which allows the recipient to communicate to the sender that a failure has occured. This NACK contains a reason code that communicates the nature of the failure. For certain types of failures, the NACK will also contain additional details that might be useful in recovering from the failure. Roach Expires April 1, 2003 [Page 3] Internet-Draft SigComp NACK October 2002 2. Node Behavior The following sections detail the behavior of nodes sending and receiving SigComp NACKs. The actual format and values are described in section Section 3. 2.1 Normal SigComp Message Transmission Although normal in all other respects, SigComp implementations that use the NACK mechanism need to calculate and store a SHA-1 hash for each SigComp message that they send. This must be stored in such a way that, given the SHA-1 hash, the implementation is able to locate the compartment with which the sent message was associated. Further, when a reliable transport is being used, the implementation must be able to retrieve the plain-text version of the original message. 2.2 Receiving a "Bad" SigComp Message When a received SigComp message causes a decompression failure, the recipient forms and sends a SigComp NACK message. This NACK message contains a SHA-1 hash of the received SigComp message that could not be decompressed. It also contains the exact reason decompression failed, as well as any additional details that might assist the NACK recipient to correct any problems. See section Section 3 for more information about formatting the NACK message and its fields. For a connection-oriented transport, such as TCP, the NACK message is sent back to the originator of the failed message over that same connection. For a stream-based transport, such as TCP, the standard SigComp delimiter of 0xFFFF is used to terminate the NACK message. For a connectionless transport, such as UDP, the NACK message is sent back to the originator of the failed message at the port and IP address from which the message was sent. Note that this may or may not be the same port to which the appliation would typically receive messages. 2.3 Receiving a SigComp NACK The first action taken upon receipt of a NACK is an attempt to find the message to which the NACK corresponds. This search is performed using the 20-byte SHA-1 hash contained in the NACK. Once the matching message is located, further operations are performed based on the compartment that was associated with the sent message. Further behavior of a node upon receiving a SigComp NACK depends on Roach Expires April 1, 2003 [Page 4] Internet-Draft SigComp NACK October 2002 whether a reliable or unreliable transport is being used. 2.3.1 Unreliable Transport When SigComp is used over an unreliable transport, the application has no reasonable expectation that the transport layer will deliver any particular message. It then becomes the application layer's responsibility to ensure that data is retransmitted as necessary. In these circumstances, the NACK mechanism relies on such behavior to ensure delivery of the message, and never performs retransmissions on the application's behalf. When a NACK is received for a message sent over an unreliable transport, the NACK recipient uses the contained information to make appropriate adjustments to the compressor associated with the proper compartment. The exact nature of these adjustments are specific to the compression scheme being used, and will vary from implementation to implementation. The only requirement on these adjustments is that they must have the effect of compensating for the error that has been indicated (e.g. by removing the state that the remote node indicates it cannot retreive). In particular, when an unreliable transport is used, the original message must not be retransmitted by the SigComp layer upon receipt of a NACK. Instead, the next application initiated transmission of a message will take advantage of the adjustments made as a result of processing the NACK. 2.3.2 Reliable Transport When a reliable transport is employed, the application makes a basic assumption that any message passed down the stack will be retransmitted as necessary to ensure that the remote node receives it. As such, many such application provide no application-level reliability mechanism. Because SigComp acts as a shim between the transport-layer and the application, it becomes the responsibility of the SigComp implementation to ensure such retransmission in the case of a detected failure. When a NACK is received for a message sent over a reliable transport, the NACK recipient uses the contained information to make appropriate adjustments to the compressor associated with the proper compartment. The exact nature of these adjustments are specific to the compression scheme being used, and will vary from implementation to implementation. The only requirement on these adjustments is that they must have the effect of compensating for the error that has been indicated (e.g. by removing the state that the remote node indicates it cannot retreive). Roach Expires April 1, 2003 [Page 5] Internet-Draft SigComp NACK October 2002 After such adjustments are made, the SigComp layer re-compresses the original message and re-sends it to the original recipient. Roach Expires April 1, 2003 [Page 6] Internet-Draft SigComp NACK October 2002 3. Message Format SigComp NACK packets are syntactically valid SigComp messages which have been specifically designed to be safely ignored by implementations that do not support the NACK mechanism. In particular, NACK messages are formatted as the second variant of a SigComp message (typically used for code upload) with a "code_len" field of zero and no input data. The NACK-specific information (message identifier, reason for failure, and error details) appears in the "returned feedback item" field. Further, the "destination" field is used as a version identifier to indicate which version of NACK is being employed. 3.1 Message Fields Although the format of NACK messages are the same as the second variant of normal SigComp messages, it is useful to demonstrate the specific fields as they appear inside the "returned feedback item" field. Roach Expires April 1, 2003 [Page 7] Internet-Draft SigComp NACK October 2002 --------------------------------------------------------------------- 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | 1 1 1 1 1 |T=1| 0 | 0 +---+---+---+---+---+---+---+---+ | 1 | NACK Length | 1 +---+---+---+---+---+---+---+---+ | Reason Code | 2 +---+---+---+---+---+---+---+---+ | | 3 : SHA-1 Hash of failed message : | | 22 +---+---+---+---+---+---+---+---+ | | 23 : Error Details : | | +---+---+---+---+---+---+---+---+ | code_len = 0 | detail_length + 23 +---+---+---+---+---+---+---+---+ | code_len = 0 | version = 1 | detail_length + 24 +---+---+---+---+---+---+---+---+ Figure 1: SigComp NACK Message Format --------------------------------------------------------------------- o "Reason Code" is a one-byte value that indicates the nature of the decompression failure. The specific codes are given in section Section 3.2 o "SHA-1 Hash of failed message" contains the full 20-byte SHA-1 hash of the SigComp message that could not be decompressed. This information allows the NACK recipient to locate the message that failed to decompress so that adjustments to the correct compartment can be performed. When performing this hash, the entire SigComp message is used, from the header byte (binary 11111xxx) to the end of the input. Any lower-level protocol headers (such as UDP or IP) and message delimiters (the 0xFFFF that marks message boundaries in stream protocols) are not included in the hash. When used over a stream based protocol, any 0xFFxx escape sequences are un-escaped before performing the hash operation. o "Error Details" provides any additional information that might be useful in correcting the problem that caused decompression failure. Its meaning is specific to the "Reason Code". See Roach Expires April 1, 2003 [Page 8] Internet-Draft SigComp NACK October 2002 section Section 3.2 for specific information on what appears in this field. o "Code_len" is the "code_len" field from a standard SigComp message. It is always set to "0" for NACK messages. o "Version" gives the version of the NACK mechanism being employed. This document defines version 1. 3.2 Reason Codes Note that many of the status codes are more useful in debugging interoperability problems than with on-the-fly correction of errors. The "STATE_NOT_FOUND" error is a notable exception: it will generally cause the NACK receipient to encode future messages so as to not use the indicated state. Upon receiving the other status messages, an implementation would typically be expected to either use a different set of bytecodes or, if that is not an option, to send that specific message uncompressed. Roach Expires April 1, 2003 [Page 9] Internet-Draft SigComp NACK October 2002 --------------------------------------------------------------------- Error Code Details -------------------------- ---- --------------------------- STATE_NOT_FOUND 1 State ID (6 - 20 bytes) CYCLES_EXHAUSTED 2 Cycles Per Bit (1 byte) USER_REQUESTED 3 SEGFAULT 4 TOO_MANY_STATE_REQUESTS 5 INVALID_STATE_ID_LENGTH 6 INVALID_STATE_PRIORITY 7 OUTPUT_OVERFLOW 8 STACK_UNDERFLOW 9 BAD_BITORDER 10 DIV_BY_ZERO 11 SWITCH_VALUE_TOO_HIGH 12 TOO_MANY_BITS_REQUESTED 13 HUFFMAN_INVALID_PARAMETER 14 HUFFMAN_NO_MATCH 15 MESSAGE_TOO_SHORT 16 INVALID_CODE_LOCATION 17 BYTECODES_TOO_LARGE 18 Memory size (2 bytes) INVALID_OPCODE 19 Only the three errors "STATE_NOT_FOUND", "CYCLES_EXHAUSTED", and "BYTECODES_TOO_LARGE" contain details; for all other error codes, the "Error Details" field has zero length. Figure 2: SigComp NACK Reason Codes --------------------------------------------------------------------- 1. STATE_NOT_FOUND A state that was referenced (either using STATE-ACCESS instruction or in the actual SigComp message itself) cannot be found. The "details" field contains the state identifier for the state that could not be found. 2. CYCLES_EXHAUSTED Decompression of the message has taken more cycles than were allocated to it. The "details" field contains a one-byte value that communicates the number of cycles per bit. The cycles per bit is represented as an unsigned 8-bit integer (i.e. not encoded). 3. USER_REQUESTED The DECOMPRESSON-FAILURE opcode has been executed. Roach Expires April 1, 2003 [Page 10] Internet-Draft SigComp NACK October 2002 4. SEGFAULT An attempt to read from or write to memory that is outside of the UDVM's memory space has been attempted. 5. TOO_MANY_STATE_REQUESTS More than four requests to store or delete state objects have been requested. 6. INVALID_STATE_ID_LENGTH A state id length less than 6 or greater than 20 has been specified. 7. INVALID_STATE_PRIORITY A state priority of 65535 has been specified when attempting to store a state. 8. OUTPUT_OVERFLOW The decompressed message is too large to be decoded by the receiving node. 9. STACK_UNDERFLOW An attempt to pop a value off the UDVM stack was made with a stack_fill value of 0. 10. BAD_BITORDER An INPUT-BITS or INPUT-HUFFMAN instruction was encountered with the "input_bit_order" register set to an invalid value (i.e. one of the upper five bits is set). 11. DIV_BY_ZERO A DIVIDE or REMAINDER opcode was encountered with a divisor of 0. 12. SWITCH_VALUE_TOO_HIGH The input to a SWITCH opcode exceeds the number of branches defined. 13. TOO_MANY_BITS_REQUESTED An INPUT instruction was encountered that attempted to input more than 16 bits. 14. HUFFMAN_INVALID_PARAMETER The first "number of bits" parameter to a INPUT-HUFFMAN opcode is zero. 15. HUFFMAN_NO_MATCH The input string does not match any of the bitcodes in the INPUT-HUFFMAN opcode. Roach Expires April 1, 2003 [Page 11] Internet-Draft SigComp NACK October 2002 16. MESSAGE_TOO_SHORT When attempting to decode a SigComp message, the recipient determined that there were not enough bytes in the message for it to be valid. 17. INVALID_CODE_LOCATION The "code location" field in the SigComp message was set to the invalid value of 0. 18. BYTECODES_TOO_LARGE The bytecodes that a SigComp message attempted to upload exceed the amount of memory available in the receiving UDVM. The details field is a two-byte expression of the DECOMPRESSION_MEMORY_SIZE of the receiving UDVM. This value is communicated most-significant-byte first. 19. INVALID_OPCODE The UDVM attempted to identify an undefined byte value as an instruction. Roach Expires April 1, 2003 [Page 12] Internet-Draft SigComp NACK October 2002 4. Security Considerations 4.1 Reflector Attacks Because SigComp NACK messages trigger responses, it is possible to trigger them by intentionally sending malformed messages to a SigComp implementation with a spoofed IP address. However, because such actions can only generate one message for each message sent, they don't serve as amplifier attacks. Futher, due to the reasonably small size of NACK packets, there cannot be a significant increase in the size of the packet generated. It is worth noting that nearly all deployed protocols exhibit this same behavior. 4.2 NACK Spoofing Although it is possible to forge NACK message as if they were generated by a different node, the damage that can be caused is minimal. Reporting a loss of state will typically result in nothing more than the re-transmission of that state in a subsequent message. Other failure codes would result in the next message being sent using an alternate compression mechanism, or possibly uncompressed. Although all of the above consequences result in slightly larger messages, none of them have particularly catastrophic implications for security. Roach Expires April 1, 2003 [Page 13] Internet-Draft SigComp NACK October 2002 References [1] Price, R., "Signaling Compression", draft-ietf-rohc-sigcomp-07 (work in progress), June 2002. [2] Hannu, H., "SigComp - Extended Operations", draft-ietf-rohc- sigcomp-extended-04 (work in progress), June 2002. Author's Address Adam Roach dynamicsoft 5100 Tennyson Pkwy Suite 1200 Plano, TX 75024 US EMail: adam@dynamicsoft.com Roach Expires April 1, 2003 [Page 14] Internet-Draft SigComp NACK October 2002 Appendix A. Comments and Feedback Editorial comments should be directed to the author at adam@dynamicsoft.com. Discussion of the mechanism described in this document should be directed to the ROHC mailing list (rohc@ietf.org). Roach Expires April 1, 2003 [Page 15] Internet-Draft SigComp NACK October 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). 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. Roach Expires April 1, 2003 [Page 16]