requests and the state free requests to be interleaved.
The state creation requests are made by the STATE-CREATE instruction.
Note however that the END-MESSAGE can make one state creation request
itself using the supplied operands. If the specified
minimum_access_length does not lie between 6 and 20 inclusive, or if
the state_retention_priority is 65535 then the END-MESSAGE
instruction fails to make a state creation request of its own
(however decompression failure does not occur and the state creation
requests made by the STATE-CREATE instruction are still valid).
Note that there is a maximum limit of four state creation requests
per instance of the UDVM. Therefore, decompression failure occurs if
the END-MESSAGE instruction makes a state creation request and four
instances of the STATE-CREATE instruction have already been
encountered.
When creating a state item it is necessary to give the state_length,
state address, state_instruction and minimum_access_length; these are
supplied as operands in the STATE-CREATE instruction (or the END-
MESSAGE instruction). A complete item of state also requires a
state_value and a state_identifier, which are derived as follows:
The UDVM byte copies a string of state_length bytes from the UDVM
memory beginning at state_address (obeying the rules of Section 8.4).
This is the state_value.
The UDVM then calculates a 20-byte SHA-1 hash [RFC-3174] over the
byte string formed by concatenating the state_length, state_address,
state_instruction, minimum_access_length and state_value (in the
order given). This is the state_identifier.
The state_retention_priority is not part of the state item itself,
but instead determines the order in which state will be deleted when
the compartment exceeds its allocated state memory. The
state_retention_priority is supplied as an operand in the STATE-
CREATE or END-MESSAGE instruction and is passed to the state handler
as part of each state creation request.
The state free requests are made by the STATE-FREE instruction. Each
STATE-FREE instruction supplies the values partial_identifier_start
and partial_identifier_length; upon reaching the END-MESSAGE
instruction these values are used to byte copy a partial state
identifier from the UDVM memory. If no state item matching the
partial state identifier can be found or if more than one state item
in the compartment matches the partial state identifier, then the
state free request is ignored (this does not cause decompression
failure to occur). Otherwise, the state handler frees the matched
state item as specified in Section 6.2.
As well as forwarding the state creation and state free requests, the
END-MESSAGE instruction may also pass feedback data to the state
handler. Feedback data is used to inform the receiving endpoint
about the capabilities of the sending endpoint, which can help to
improve the overall compression ratio and to reduce the working
memory requirements of the endpoints.
Two types of feedback data are available: requested feedback and
returned feedback. The format of the requested feedback data is
given in Figure 12. As outlined in Section 3.2, the requested
feedback data can be used to influence the contents of the returned
feedback data in the reverse direction.
The returned feedback data is itself subdivided into a returned
feedback item and a list of returned SigComp parameters. The
returned feedback item is of sufficient importance to warrant its own
field in the SigComp header as described in Section 7.1. The
returned SigComp parameters are illustrated in Figure 13.
Note that the formats of Figure 12 and Figure 13 are only for local
presentation of the feedback data on the interface between the UDVM
and state handler. The formats do not mandate any bits on the wire;
the compressor can transmit the data in any form provided that it is
loaded into the UDVM memory at the correct addresses.
Moreover, the responsibility for ensuring that feedback data arrives
successfully over an unreliable transport lies with the sender. The
receiving endpoint always uses the last received value for each field
in the feedback data, even if the values are out of date due to
packet loss or misordering.
If the requested_feedback_location operand is set to 0, then no
feedback request is made; otherwise, it points to the starting memory
address of the requested feedback data as shown in Figure 12.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| reserved | Q | S | I | requested_feedback_location
+---+---+---+---+---+---+---+---+
| |
: requested feedback item : if Q = 1
| |
+---+---+---+---+---+---+---+---+
Figure 12: Format of requested feedback data
The reserved bits may be used in future versions of SigComp, and are
set to 0 in Version 0x01. Non-zero values should be ignored by the
receiving endpoint.
The Q-bit indicates whether a requested feedback item is present or
not. The compressor can set the requested feedback item to an
arbitrary value, which will then be transmitted unmodified in the
reverse direction as a returned feedback item. See Chapter 5 for
further details of how the requested feedback item is returned.
The format of the requested feedback item is identical to the format
of the returned feedback item illustrated in Figure 4.
The compressor sets the S-bit to 1 if it does not wish (or no longer
wishes) to save state information at the receiving endpoint and also
does not wish to access state information that it has previously
saved. Consequently, if the S-bit is set to 1 then the receiving
endpoint can reclaim the state memory allocated to the remote
compressor and set the state_memory_size for the compartment to 0.
The compressor may change its mind and switch the S-bit back to 0 in
a later message. However, the receiving endpoint is under no
obligation to use the original state_memory_size for the compartment;
it may choose to allocate less memory to the compartment or possibly
none at all.
Similarly the compressor sets the I-bit to 1 if it does not wish (or
no longer wishes) to access any of the locally available state items
offered by the receiving endpoint. This can help to conserve
bandwidth because the list of locally available state items no longer
needs to be returned in the reverse direction. It may also conserve
memory at the receiving endpoint, as the state handler can delete any
locally available state items that it determines are no longer
required by any remote endpoint. Note that the compressor can set
the I-bit back to 0 in a later message, but it cannot access any
locally available state items that were previously offered by the
receiving endpoint unless they are subsequently re-announced.
If the returned_parameters_location operand is set to 0, then no
SigComp parameters are returned; otherwise, it points to the starting
memory address of the returned parameters as shown in Figure 13.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| cpb | dms | sms | returned_parameters_location
+---+---+---+---+---+---+---+---+
| SigComp_version |
+---+---+---+---+---+---+---+---+
| length_of_partial_state_ID_1 |
+---+---+---+---+---+---+---+---+
| |
: partial_state_identifier_1 :
| |
+---+---+---+---+---+---+---+---+
: :
+---+---+---+---+---+---+---+---+
| length_of_partial_state_ID_n |
+---+---+---+---+---+---+---+---+
| |
: partial_state_identifier_n :
| |
+---+---+---+---+---+---+---+---+
Figure 13: Format of returned SigComp parameters
The first byte encodes the SigComp parameters cycles_per_bit,
decompression_memory_size and state_memory_size as per Section 3.3.1.
The byte can be set to 0 if the three parameters are not included in
the feedback data. (This may be useful to save bits in the
compressed message if the remote endpoint is already satisfied all
necessary information has reached the endpoint receiving the
message.)
The second byte encodes the SigComp_version as per Section 3.3.2.
Similar to the first byte, the second byte can be set to 0 if the
parameter is not included in the feedback data.
The remaining bytes encode a list of partial state identifiers for
the locally available state items offered by the sending endpoint.
Each state item is encoded as a 1-byte length field, followed by a
partial state identifier containing as many bytes as indicated in the
length field. The sender can choose to send as few as 6 bytes if it
believes that this is sufficient for the receiver to determine which
state item is being offered.
The list of state identifiers is terminated by a byte in the position
where the next length field would be expected that is set to a value
below 6 or above 20. Note that upgraded SigComp versions may append
additional items of data after the final length field.
10. Security Considerations
10.1. Security Goals
The overall security goal of the SigComp architecture is to not
create risks that are in addition to those already present in the
application protocols. There is no intention for SigComp to enhance
the security of the application, as it always can be circumvented by
not using compression. More specifically, the high-level security
goals can be described as:
1. Do not worsen security of existing application protocol
2. Do not create any new security issues
3. Do not hinder deployment of application security.
10.2. Security Risks and Mitigation
This section identifies the potential security risks associated with
SigComp, and explains how each risk is minimized by the scheme.
10.2.1. Confidentiality Risks
- Attacking SigComp by snooping into state of other users:
State is accessed by supplying a state identifier, which is a
cryptographic hash of the state being referenced. This implies that
the referencing message already needs knowledge about the state. To
enforce this, a state item cannot be accessed without supplying a
minimum of 48 bits from the hash. This also minimizes the
probability of an accidental state collision. A compressor can,
using the minimum_access_length operand of the STATE-CREATE and END-
MESSAGE instructions, increase the number of bits that need to be
supplied to access the state, increasing the protection against
attacks.
Generally, ways to obtain knowledge about the state identifier (e.g.,
passive attacks) will also easily provide knowledge about the
referenced state, so no new vulnerability results.
An endpoint needs to handle state identifiers with the same care it
would handle the state itself.
10.2.2. Integrity Risks
The SigComp approach assumes that there is appropriate integrity
protection below and/or above the SigComp layer. The state creation
mechanism provides some additional potential to compromise the
integrity of the messages; however, this would most likely be
detectable at the application layer.
- Attacking SigComp by faking state or making unauthorized changes to
state:
State cannot be destroyed by a malicious sender unless it can send
messages that the application identifies as belonging to the same
compartment the state was created under; this adds additional
security risks only when the application allows the installation of
SigComp state from a message where it would not have installed state
itself.
Faking or changing state is only possible if the hash allows
intentional collision.
10.2.3. Availability Risks (Avoiding DoS Vulnerabilities)
- Use of SigComp as a tool in a DoS attack to another target:
SigComp cannot easily be used as an amplifier in a reflection attack,
as it only generates one decompressed message per incoming compressed
message. This message is then handed to the application; the utility
as a reflection amplifier is therefore limited by the utility of the
application for this purpose.
However, it must be noted that SigComp can be used to generate larger
messages as input to the application than have to be sent from the
malicious sender; this therefore can send smaller messages (at a
lower bandwidth) than are delivered to the application. Depending on
the reflection characteristics of the application, this can be
considered a mild form of amplification. The application MUST limit
the number of packets reflected to a potential target - even if
SigComp is used to generate a large amount of information from a
small incoming attack packet.
- Attacking SigComp as the DoS target by filling it with state:
Excessive state can only be installed by a malicious sender (or a set
of malicious senders) with the consent of the application. The
system consisting of SigComp and application is thus approximately as
vulnerable as the application itself, unless it allows the
installation of SigComp state from a message where it would not have
installed application state itself.
If this is desirable to increase the compression ratio, the effect
can be mitigated by making use of feedback at the application level
that indicates whether the state requested was actually installed -
this allows a system under attack to gracefully degrade by no longer
installing compressor state that is not matched by application state.
Obviously, if a stream-based transport is used, the streams
themselves constitute state that has to be handled in the same way
that the application itself would handle a stream-based transport; if
an application is not equipped for stream-based transport, it should
not allow SigComp connections on a stream-based transport. For the
alternative SigComp usage described as "continuous mode" in Section
4.2.1, an attacker could create any number of active UDVMs unless
there is some DoS protection at a lower level (e.g., by using TLS in
appropriate configurations).
- Attacking the UDVM by faking state or making unauthorized changes
to state:
This is covered in Section 10.2.2.
- Attacking the UDVM by sending it looping code:
The application sets an upper limit to the number of "UDVM cycles"
that can be used per compressed message and per input bit in the
compressed message. The damage inflicted by sending packets with
looping code is therefore limited, although this may still be
substantial if a large number of UDVM cycles are offered by the UDVM.
However, this would be true for any decompressor that can receive
packets over an unsecured transport.
11. IANA Considerations
SigComp requires a 1-byte name space, the SigComp_version, which has
been created by the IANA. Upgraded versions of SigComp must be
backwards-compatible with Version 0x01, described in this document.
Adding additional UDVM instructions and assigning values to the
reserved UDVM memory addresses are two possible upgrades for which
this is the case.
Following the policies outlined in [RFC-2434], the IANA policy for
assigning a new value for the SigComp_version shall require a
Standards Action. Values are thus assigned only for Standards Track
RFCs approved by the IESG.
12. Acknowledgements
Thanks to
Abigail Surtees
Mark A West
Lawrence Conroy
Christian Schmidt
Max Riegel
Lars-Erik Jonsson
Stefan Forsgren
Krister Svanbro
Miguel Garcia
Christopher Clanton
Khiem Le
Ka Cheong Leung
Robert Sugar
for valuable input and review.
13. References
13.1. Normative References
[RFC-1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC
1662, July 1994.
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC2119, March 1997.
[RFC-3174] Eastlake, 3rd, D. and P. Jones, "US Secure Hash Algorithm
1 (SHA1)", RFC3174, September 2001.
13.2. Informative References
[RFC-1951] Deutsch, P., "DEFLATE Compressed Data Format
Specification version 1.3", RFC1951, May 1996.
[RFC-2026] Bradner, S., "The Internet Standards Process - Revision
3", BCP 9, RFC2026, October 1996.
[RFC-2279] Yergeau, F., "UTF-8, a transformation format of ISO
10646", RFC2279, January 1998.
[RFC-2326] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time
Streaming Protocol (RTSP)", RFC2326, April 1998.
[RFC-2434] Alvestrand, H. and T. Narten, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC2434,
October 1998.
[RFC-2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C.,
Schwartzbauer, H., Taylor, T., Rytina, I., Kalla, M.,
Zhang, L. and V. Paxson, "Stream Control Transmission
Protocol", RFC2960, October 2000.
[RFC-3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
A., Peterson, J., Sparks, R., Handley, M. and E.
Schooler, "SIP: Session Initiation Protocol", RFC3261,
June 2002.
[RFC-3321] Hannu, H., Christoffersson, J., Forsgren, S., Leung,
K.-C., Liu, Z. and R. Price, "Signaling Compression
(SigComp) - Extended Operations", RFC3321, January
2003.
14. Authors' Addresses
Richard Price
Roke Manor Research Ltd
Romsey, Hants, SO51 0ZN
United Kingdom
Phone: +44 1794 833681
EMail: richard.price@roke.co.uk
Carsten Bormann
Universitaet Bremen TZI
Postfach 330440
D-28334 Bremen, Germany
Phone: +49 421 218 7024
EMail: cabo@tzi.org
Jan Christoffersson
Box 920
Ericsson AB
SE-971 28 Lulea, Sweden
Phone: +46 920 20 28 40
EMail: jan.christoffersson@epl.ericsson.se
Hans Hannu
Box 920
Ericsson AB
SE-971 28 Lulea, Sweden
Phone: +46 920 20 21 84
EMail: hans.hannu@epl.ericsson.se
Zhigang Liu
Nokia Research Center
6000 Connection Drive
Irving, TX 75039
Phone: +1 972 894-5935
EMail: zhigang.c.liu@nokia.com
Jonathan Rosenberg
dynamicsoft
72 Eagle Rock Avenue
First Floor
East Hanover, NJ 07936
EMail: jdrosen@dynamicsoft.com
15. 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 RFCEditor function is currently provided by the
Internet Society.