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_INPUT_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 13 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-BITS or INPUT-HUFFMAN instruction was encountered that
attempted to input more than 16 bits.
14. INVALID_OPERAND
An operand for an instruction could not be resolved to an
integer value (e.g., a literal or reference operand beginning
with 11111111).
15. HUFFMAN_NO_MATCH
The input string does not match any of the bitcodes in the
INPUT-HUFFMAN opcode.
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.
20. INVALID_STATE_PROBE
When attempting to retrieve state, the state_length operand is
set to 0 but the state_begin operand is non-zero.
21. ID_NOT_UNIQUE
A partial state identifier that was used to access state matched
more than one state item. Note that this error might be
returned as the result of executing a STATE-ACCESS instruction
or attempting to locate a unique piece of state as identified by
the "partial state identifier" in a SigComp message. The
"details" field contains the partial state identifier that was
requested.
22. MULTILOAD_OVERWRITTEN
A MULTILOAD instruction attempted to overwrite itself.
23. STATE_TOO_SHORT
A STATE-ACCESS instruction has attempted to copy more bytes from
a state item than the state item actually contains. The
"details" field contains the partial state identifier that was
requested. Implementors are cautioned to return only the
partial state identifier that was requested; if the NACK
contains any state identifier in addition to what was requested,
attackers may be able to use that additional information to
access the state.
24. INTERNAL_ERROR
The UDVM encountered an unexpected condition that prevented it
from decompressing the message.
25. FRAMING_ERROR
The UDVM encountered a framing error (unquoted 0xFF 80 .. 0xFF
FE in an input stream.) This error is applicable only to
messages received on a stream transport. In the case of a
framing error, a SHA-1 hash for a unique message cannot be
determined. Consequently, when a FRAMING_ERROR NACK is sent,
the "SHA-1 Hash of failed message" field should be set to all
zeros.
4. Security Considerations
4.1. Reflector Attacks
Because SigComp NACK messages are by necessity sent in response to
other messages, 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.
Further, 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 messages 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.
5. IANA Considerations
This document defines a new value for the IANA registered attribute
SigComp_version.
Value (in hex): 02
Description: SigComp version 2 (NACK support)
Reference: [RFC4077]
6. Acknowledgements
Thanks to Carsten Bormann, Zhigang Liu, Pekka Pessi, and Robert Sugar
for their comments and suggestions. Special thanks to Abigail
Surtees and Richard Price for several very detailed reviews and
suggestions.
7. References
7.1. Normative References
[1] Price, R., Bormann, C., Christoffersson, J., Hannu, H., Liu, Z.,
and J. Rosenberg, "Signaling Compression (SigComp)", RFC 3320,
January 2003.
[2] Hannu, H., Christoffersson, J., Forsgren, S., Leung, K.-C., Liu,
Z., and R. Price, "Signaling Compression (SigComp) - Extended
Operations", RFC 3321, January 2003.
7.2. Informative References
[3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
Author’s Address
Adam Roach
Estacado Systems
17210 Campbell Road
Suite 250
Dallas, TX 75252
US
EMail: adam@estacado.net
Full 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.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.