January 1996.
[2] Jacobson, V., "TCP/IP Compression for Low-Speed Serial Links",
RFC1144, February 1990.
[3] Degermark, M., Nordgren, B. and S. Pink, "Header Compression for
IPv6", RFC2507, February 1999.
[4] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, RFC
1661, July 1994.
[5] Hoffman, D., Fernando, G., Goyal, V. and M. Civanlar, "RTP
Payload Format for MPEG1/MPEG2 Video", RFC2250, January 1998.
8. Security Considerations
Because encryption eliminates the redundancy that this compression
scheme tries to exploit, there is some inducement to forego
encryption in order to achieve operation over a low-bandwidth link.
However, for those cases where encryption of data and not headers is
satisfactory, RTP does specify an alternative encryption method in
which only the RTP payload is encrypted and the headers are left in
the clear. That would allow compression to still be applied.
A malfunctioning or malicious compressor could cause the decompressor
to reconstitute packets that do not match the original packets but
still have valid IP, UDP and RTP headers and possibly even valid UDP
check-sums. Such corruption may be detected with end-to-end
authentication and integrity mechanisms which will not be affected by
the compression. Constant portions of authentication headers will be
compressed as described in [3].
No authentication is performed on the CONTEXT_STATE control packet
sent by this protocol. An attacker with access to the link between
the decompressor and compressor could inject false CONTEXT_STATE
packets and cause compression efficiency to be reduced, probably
resulting in congestion on the link. However, an attacker with
access to the link could also disrupt the traffic in many other ways.
A potential denial-of-service threat exists when using compression
techniques that have non-uniform receiver-end computational load.
The attacker can inject pathological datagrams into the stream which
are complex to decompress and cause the receiver to be overloaded and
degrading processing of other streams. However, this compression
does not exhibit any significant non-uniformity.
A security review of this protocol found no additional security
considerations.
9. Authors' Addresses
Stephen L. Casner
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
United States
EMail: casner@cisco.com
Van Jacobson
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
United States
EMail: van@cisco.com
10. Full Copyright Statement
Copyright (C) The Internet Society (1999). 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.