INTERNET-DRAFT Michael Welzl draft-welzl-tcp-corruption-00.txt University of Innsbruck Institute of Computer Science June 2004 TCP Corruption Notification Options Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC 2026. 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 Abstract This memo specifies options that enable TCP to detect corruption in the presence of link layers which hand over known-corrupt data to upper layers. The receiver notifies the sender of an erroneous segment that would otherwise be lost and assumed to be a sign of congestion. The sender uses this ACK to drive its RTO calculation, retransmit the segment and react to congestion earlier if ECE=1. In addition, this feedback could be used to realize a more appropriate rate change in response to such lost segments. Table of Contents Status of this Memo ....................................... 1 1. Definitions ....................................... 2 2. Introduction ...................................... 2 3. Specification ..................................... 3 Michael Welzl Expires: December 2004 [Page 1] Internet Draft draft-welzl-tcp-corruption-00.txt June 2004 3.1 Corruption Detection Option ..................... 3 3.2 Corruption Notification Option .................. 4 4. Lower Layer Considerations ........................ 4 5. Usage Discussion .................................. 5 6. Design Rationale .................................. 6 8. Security Considerations ........................... 7 9. IANA Considerations ............................... 8 10. Normative References .............................. 8 11. Informative References ............................ 8 12. Acknowledgments ................................... 9 13. Author's Address .................................. 10 14. Full Copyright Statement .......................... 11 1. Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2. Introduction If the TCP checksum fails, corruption has occurred somewhere in the packet; it is impossible to tell the exact location of the bit errors that caused the problem. Since this includes port and sequence numbers, the sender can normally not be informed of such loss. This memo specifies two TCP options that are used to notify a TCP sender of known-corrupt segments in the case of link layers that hand over such data. The first option, "Corruption Detection", realizes the concept of a separate header checksum -- it covers all the fields in the header that are necessary to recover the relevant information about a segment if the regular TCP checksum fails. The second option, "Corruption Notification", is used to convey this information to the sender. Using Corruption Detection and Notification has a number of potential advantages: the RTO value can be updated more accurately by incorporating this feedback, a corrupted segment can be retransmitted earlier, and a sender can react more promptly to congestion if ECE=1. In some cases, it may be possible to detect that only the ACK (not the ACKed segment) shows corruption and thereby avoid an unnecessary retransmission. Moreover, certain control information (e.g., SYN or FIN) may stay intact in the face of corruption when this mechanism is used. Finally, it could help to alleviate the long-standing problem of TCP misinterpreting packet loss as a sign of congestion when it was in fact caused by corruption. Michael Welzl Expires: December 2004 [Page 2] Internet Draft draft-welzl-tcp-corruption-00.txt June 2004 3. Specification 3.1. Corruption Detection Option The Corruption Detection option for TCP holds a 32-bit CRC-32c cyclic redundancy-check code of a special pseudo header that is a subset of the TCP header and the pseudo header used by the regular TCP checksum. +--------+--------+--------+--------+--------+--------+ |00011011|00000110| CRC-32c | +--------+--------+--------+--------+--------+--------+ Type=27 Length=6 The CRC-32c algorithm used for Corruption Detection is the same as that used for SCTP [RFC3309]; note that the CRC-32c of zero bytes of data equals zero. The standard TCP checksum will cover the Corruption Detection option, so this checksum must be computed before the standard checksum. The pseudo header to be covered by this checksum contains the ECN Field [RFC3168], Source Address and Destination Address from the IP header and the Source Port, Destination Port, Sequence Number and Acknowledgment Number fields as well as the CWR, ECE, ACK, RST, SYN and FIN control bits from the TCP header. In addition, the checksum covers all TCP options that are contained in the packet. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+ |ECN| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Sequence Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Acknowledgment Number | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |C|E|A|R|S|F| |W|C|C|S|Y|I| |R|E|K|T|N|N| +-+-+-+-+-+-+ A TCP sender MAY include this option at any time in order to detect Michael Welzl Expires: December 2004 [Page 3] Internet Draft draft-welzl-tcp-corruption-00.txt June 2004 corruption; a discussion of its usage can be found in the following sections. A receiver ignores this option unless an error occurs in the standard TCP checksum. In this case, the checksum embedded in this option is verified. If it also fails, the receiver proceeds as if this option would not be present and the packet is dropped. If it succeeds, the packet contains erroneous data, but all the information contained in the pseudo header covered by the checksum can be used as if the problem had not occurred. Fields outside of the pseudo header must be ignored as they can have bit errors. If the packet is not itself an ACK, the receiver sends an ACK to the sender which contains a Corruption Notification option. Except for this option, this ACK looks as if the segment had been dropped (i.e. it carries the sequence number of the erroneous segment in the Acknowledgment Number field). 3.2. Corruption Notification Option The Corruption Notification TCP option MUST be included in an ACK by a TCP receiver that notices an error in the standard TCP checksum but not in the Corruption Detection option checksum. +--------+--------+ |00011100|00000010| +--------+--------+ Type=28 Length=2 A TCP that receives an ACK carrying this option generally carries out all the tasks that it would normally do if the ACK did not contain this option. This includes, for example, retransmitting the segment identified by the Acknowledgment Number, updating the state variables associated with RTO calculation (SRTT and RTTVAR) as specified in [RFC2988], and interpreting flags. As an exception to this rule, this memo does not attempt to specify the congestion control response to an ACK carrying the Corruption Notification option. A discussion can be found in the following sections. An ACK packet may carry both the Corruption Detection option and the Corruption Notification option at the same time. 4. Lower Layer Considerations Lower layer considerations for the Corruption Detection option are similar to UDPLite [UDPLITE] and DCCP [DCCP], and what follows was adapted from the corresponding text in their specifications: Michael Welzl Expires: December 2004 [Page 4] Internet Draft draft-welzl-tcp-corruption-00.txt June 2004 Since TCP packets with damaged data may remain useful if this option is included, frames carrying such TCP packets need not be discarded by lower layer protocols when there are errors only in the insensitive part. For a link that supports partial error detection, the pseudo header used by the Corruption Detection option MAY be used as a hint of where errors do not need to be detected. Lower layers MUST use a strong error detection mechanism [LINK BCP] to detect at least errors that occur in the sensitive part of the packet, and discard damaged packets. The sensitive part consists of the IP header and the octets covered by the pseudo header that is used for calculating the checksum embedded in the Corruption Detection option. The sensitive part would thus be treated in exactly the same way as for a standard TCP packet. Link layers that do not support partial error detection suitable for TCP packets carrying this option, as described above, MUST detect errors in the entire TCP packet, and MUST discard damaged packets [LINK]. The whole TCP packet is thus treated in exactly the same way as a TCP packet that does not carry this option. It should be noted that this option would only make a difference to an application if partial error detection is implemented also by link layers, as discussed above. Partial error detection at the link layer would only make a difference when implemented over error-prone links. 5. Usage Discussion o When is the Corruption Detection option used? A TCP sender MAY include the Corruption Detection option in any segment. Since it leads to processing and, like any other option, header size overhead, it should however only be used in the presence of link noise and across links that support partial error detection. One possibility is to use it in dedicated environments where a link is known to show such behavior. Another possibility is to monitor the connection for indications of corruption (e.g., excessive packet loss). o When is the Corruption Detection option used with ACKs? The discussion above obviously also applies in this case. The use of the option with ACKs, however, has an advantage -- a known- corrupt ACK can be used locally without having to send a Corruption Notification option to the other end of a connection -- and disadvantages -- since ACKs are typically small, the chances Michael Welzl Expires: December 2004 [Page 5] Internet Draft draft-welzl-tcp-corruption-00.txt June 2004 for corruption to occur in the sensitive part of the header (the pseudo header used for the checksum in the Corruption Detection option) are high, and so is the relative header overhead of including the option. o What is the congestion control response to Corruption Notification? The mechanism described in this memo enables a sender to be informed about loss that is due to corruption in the presence of link layers that hand over erroneous data. This means that, other than the usual case for TCP, reported loss is not necessarily a sign of congestion. In addition to the possibility to distinguish between these types of errors, corruption along the backward path may also be separately detected by including the Corruption Detection option in ACKs. There is an immense amount of research on TCP improvements for wireless links, most of which is based on the assumption that the rate update response of a TCP sender to corruption should be less conservative than the reaction to congestion. An overview and classification of a large number of these proposals can be found in [ETEN] along with a study of the maximum achievable benefit with such schemes. While a less conservative behavior seems attractive, unresponsively sending at a very high data rate in the presence of a high bit error ratio does also not appear to be a reasonable choice [DCCP-note]. One possible implementation of a sender's congestion control behavior is to react similarly to corruption and congestion. Even with such a conservative choice, several benefits (earlier retransmission, retained control information, ..) remain. In particular, as pointed out by the authors of [ETEN], the possibility to properly update the RTO in the presence of link noise is valuable. 6. Design Rationale This section explains some of the design choices that were made. o Checksum: CRC-32c was used because, after long discussions, there now seems to be rough IETF consensus to generally favor this checksum over Adler-32 (as indicated by the choices made in [RFC3309] and [DCCP]). However, since the checksum introduced in this memo only covers a small amount of data, it might be possible to afford slightly higher computation costs and use a checksum Michael Welzl Expires: December 2004 [Page 6] Internet Draft draft-welzl-tcp-corruption-00.txt June 2004 that can correct bit errors. At this point, this variant was not given further consideration for the sake of simplicity. o Feedback format: the format of the Corruption Notification TCP option was largely dictated by the goal of staying simple. We see two potentially useful alternatives: o Using a bit in the Reserved field of the TCP header: a flag suffices to convey the information contained in the Corruption Notification option. We believe that reserving a bit may be justified because this mechanism is likely to be used in wireless environments, where it is often the case that both directions of a connection traverse a noisy link. In such environments, it would make sense to include the Corruption Detection option in an ACK. Since the portion of a standard ACK that must be checked is relatively high, it is very important to keep this amount of data as small as possible. o Using a format similar to the SACK option [RFC2018]: this was proposed in [AdaptiveTCP] as an enhancement to the mechanism in [TCPHACK], which closely resembles the mechanism specified in this memo. The advantage of this format is that, by repeating notifications, lost ACKs carrying Corruption Notification may be compensated for. On the other hand, it is larger, and, as explained above, it is important for the format to be as small as possible. Other than an ACK in response to congestion, Corruption Notification always precisely identifies a lost segment -- thus, the advantages of this larger format are limited, and it is questionable whether they outweigh the cost. 8. Security Considerations Security considerations for this option are similar to UDPLite [UDPLITE] and DCCP [DCCP], and what follows was adapted from the corresponding text in their specifications: The security impact of the Corruption Detection option is related to its interaction with authentication mechanisms. When a packet carries this option, the insensitive portion of a packet may change in transit. This is contrary to the idea behind most authentication mechanisms: authentication succeeds if the packet has not changed in transit. Unless authentication mechanisms that operate only on the sensitive part of packets are developed and used, authentication will always fail for TCP packets with a Corruption Detection option where the insensitive part has been damaged. The IPSec integrity check (Encapsulation Security Protocol, ESP, or Michael Welzl Expires: December 2004 [Page 7] Internet Draft draft-welzl-tcp-corruption-00.txt June 2004 Authentication Header, AH) is applied (at least) to the entire IP packet payload. Corruption of any bit within the protected area will then result in the IP receiver discarding the TCP packet. When IPSEC is used with ESP payload encryption, there is no visibility of the transport header, and therefore a link can not determine which transport layer protocol is used, and would not be able to determine the value of the checksum in the Corruption Detection option. The option provides no benefit in this case, and the link MUST provide a standard integrity check. 9. IANA Considerations This specification introduces two new TCP options, "Corruption Detection" and "Corruption Notification". 10. Normative References [RFC3309] Stone, J., Stewart, R., and Otis, D., "Stream Control Transmission Protocol (SCTP) Checksum Change", RFC 3309. [RFC2988] Paxson, V., and Allman, M., "Computing TCP's Retransmission Timer", RFC 2988, November 2000. [RFC3168] Ramakrishnan, K., Floyd, S., and Black, D., "The Addition of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 2001. 11. Informative References [LINK BCP] Karn, P. (ed.), "Advice for Internet Subnetwork Designers", Internet-draft draft-ietf-pilc-link-design-13.txt, work in progress, February 2003. [UDPLITE] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and Fairhurst, G. (ed.), "The UDP-Lite Protocol", Internet-draft draft- ietf-tsvwg-udp-lite-02.txt, work in progress, August 2003. Approved by the IESG for publication as Proposed Standard RFC. [DCCP] Kohler, E., Handley, M., and Floyd, S., "Datagram Congestion Control Protocol (DCCP)", Internet-draft draft-ietf-dccp-spec-06.txt, work in progress, February 2004. Michael Welzl Expires: December 2004 [Page 8] Internet Draft draft-welzl-tcp-corruption-00.txt June 2004 [ETEN] Krishnan, R., Sterbenz, J., Eddy, W., Partridge, C., and Allman, M., "Explicit Transport Error Notification (ETEN) for Error- Prone Wireless and Satellite Networks", pre-print accepted for publication in Elsevier Computer Networks, available from http://www.ir.bbn.com/projects/pace/eten/index.html. [DCCP-note] Floyd, S., "DCCP and UDP Lite", note in the IETF DCCP WG discussion list, March 3, 2003. [RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and Romanow, A., "TCP Selective Acknowledgment Options", RFC 2018, October 1996. [AdaptiveTCP] Hong., C-S., Niu, Y-X., Lee, J-J., "An Adaptive TCP Protocol for Lossy Mobile Environment", Proceedings of The First Eurasian Conference on Advances in Information and Communication Technology, Shiraz, Iran, October 2002. [TCPHACK] Balan, R. K., Lee, B.P., Kumar, K.R.R., Jacob, L., Seah, W.K.G., Ananda, A.L., "TCP HACK: TCP Header Checksum Option to Improve Performance over Lossy Links", Proceedings of IEEE Infocom, Anchorage, Alaska, April 2001. [Bell98] Bellovin, S.M., "Cryptography and the Internet", Proceedings of CRYPTO88, August, 1988. [BB01] Bellovin, S.M., and Blaze, M., "Cryptographic Modes of Operation for the Internet", 2nd NIST Workshop on Modes of Operation, August 2001. 12. Acknowledgments The author would like to thank everybody who directly or indirectly contributed to this document via helpful discussions, including the discussions that led to the DCCP Data Checksum Option. In particular, this includes: Mark Allman, Gorry Fairhurst, Aaron Falk, Sally Floyd, Eddie Kohler, Max Muehlhaeuser, Craig Partridge (who suggested using a pseudo header) and Colin Perkins. Michael Welzl Expires: December 2004 [Page 9] Internet Draft draft-welzl-tcp-corruption-00.txt June 2004 13. Author's Address Michael Welzl University of Innsbruck Institute fuer Informatik Technikerstr. 25 A-6020 Innsbruck, Austria Phone: +43 (512) 507-6110 Fax: +43 (512) 507-2977 Email: michael.welzl@uibk.ac.at Web: http://www.welzl.at Michael Welzl Expires: December 2004 [Page 10] Internet Draft draft-welzl-tcp-corruption-00.txt June 2004 14. Full Copyright Statement Copyright (C) The Internet Society (1997). 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." Michael Welzl Expires: December 2004 [Page 11]