Internet Engineering Task Force Eddie Kohler INTERNET-DRAFT UCLA/ICIR draft-ietf-dccp-ccid3-thin-00.txt 19 October 2003 Expires: April 2004 DCCP CCID 3-Thin 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 Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document describes the Thin variant of the Datagram Congestion Control Protocol (DCCP) Congestion Control Identifier 3, TCP- Friendly Rate Control (TFRC). The Thin variant is more restricted than CCID 3; it limits allowable options, acceptable feature values, and so forth. CCID 3-Thin packets are still valid DCCP CCID 3 packets. CCID 3-Thin was designed for small clients where a full DCCP implementation would be too expensive. Kohler [Page 1] INTERNET-DRAFT Expires: April 2004 October 2003 Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. The CCID 3-Thin Option. . . . . . . . . . . . . . . . . . . . 3 4. CCID 3-Thin Restrictions. . . . . . . . . . . . . . . . . . . 4 5. Connection Establishment. . . . . . . . . . . . . . . . . . . 6 5.1. Thin Client Initiates Connection . . . . . . . . . . . . 6 5.2. Server Responds to Thin Client . . . . . . . . . . . . . 6 5.3. Thin Server Responds to Fat Client . . . . . . . . . . . 7 5.4. Fat Client Responds to Thin Server's Response. . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 8. Thanks. . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Normative References . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Kohler [Page 2] INTERNET-DRAFT Expires: April 2004 October 2003 1. Introduction The Datagram Congestion Control Protocol (DCCP) [DCCP] implements a congestion-controlled stream of unreliable unicast datagrams. DCCP uses Congestion Control Identifiers, or CCIDs, to determine the congestion control mechanism in use on a half-connection. (A half- connection might consist of data packets sent from DCCP A to DCCP B, plus acknowledgements sent from DCCP B to DCCP A. DCCP A is the HC- Sender, and DCCP B the HC-Receiver, for this half-connection. In this document, I abbreviate HC-Sender and HC-Receiver as "sender" and "receiver", respectively. These terms are defined more fully in [DCCP].) DCCP CCID 3, TCP-Friendly Rate Control (TFRC) [CCID 3 PROFILE], defines a receiver-based congestion control mechanism that provides a TCP-friendly send rate, while minimizing abrupt rate changes [RFC 3448]. This document describes the Thin variant of DCCP CCID 3. All CCID 3-Thin packets are valid CCID 3 packets, but the converse is not true: the Thin variant restricts the options that may be sent, the values that features may take, and so forth. CCID 3-Thin was designed for small clients and servers where a full DCCP implementation would be too expensive. Note that this version of this document is more a proof-of-concept than a final proposal. The right set of restrictions for CCID 3-Thin should be subject to further discussion. For example, a final CCID 3-Thin might support ECN. This document assumes familiarity with both DCCP proper [DCCP] and the CCID 3 profile [CCID 3 PROFILE]. 2. Conventions 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]. 3. The CCID 3-Thin Option +--------+--------+ |11000001|00000010| +--------+--------+ Type=193 Len=2 The CCID 3-Thin option is sent on the initial packets in a CCID 3 connection to indicate that the endpoints agree to be bound by the CCID 3-Thin restrictions. It is a CCID-specific option, which means Kohler Section 3. [Page 3] INTERNET-DRAFT Expires: April 2004 October 2003 that the CCID feature must be set to 3 before the CCID 3-Thin option is processed; this may happen simply by sending CCID 3-Thin after the options that negotiate the CCID. CCID 3-Thin options will generally be preceded by a Mandatory option (Type 1). This will force the receiving DCCP to reset the connection if it cannot abide by the CCID 3-Thin restrictions, below. 4. CCID 3-Thin Restrictions A CCID 3-Thin connection agrees to follow these restrictions. o Both half-connections use CCID 3 (their CCID features have value 3). o All features are fixed to the values listed below, whether or not their values are negotiated. No feature negotiation options will be sent after the CCID 3-Thin handshake completes. o Both ECN Capable features have value 0 (ECN incapable). All packets are sent as ECN-incapable. o Both Use Ack Vector features have value 0 (do not send Ack Vectors; the default). No Ack Vector options will be sent. CCID 3-Thin applications that want information about which packets have arrived will have to send application-level acknowledgements. o Both Mobility Capable features have value 0 (mobility incapable; the default). Neither endpoint will send a DCCP-Move packet. o Both Loss Window features have value 1000 (the default). o Both ID Regime features have value 0 (the Null Regime). This makes it impossible for CCID 3-Thin connections to get back into sync after large bursts of loss. Neither endpoint will ever send a Challenge or Identification option. o Both Use Loss Event Rate features have value 1 (send Loss Event Rate options; the default). o Both Use Loss Intervals features have value 0 (do not send Loss Intervals options; the default). No Loss Intervals options will be sent. o Only the following types of packets can be sent: Kohler Section 4. [Page 4] INTERNET-DRAFT Expires: April 2004 October 2003 (1) DCCP-Request packets without data. (2) DCCP-Response packets without data and without an Init Cookie option. (3) DCCP-Data packets with no options (Data Offset = 3). (4a) DCCP-Ack packets with no options (Data Offset = 4). (4b) DCCP-Ack packets with 20 bytes of option (Data Offset = 9). The options MUST be exactly as follows: Elapsed Time with length 4; Padding; Padding; Receive Rate with length 6; Padding; Padding; and Loss Event Rate with length 6. (4c) A fat client responding to a thin server may follow a DCCP- Response with a DCCP-Ack that contains other options; see Section 5.4. (5) DCCP-Close packets with no options (Data Offset = 4). (6) DCCP-Reset packets with no options (Data Offset = 5). o Packets that would normally be reported with Data Dropped are instead treated as network losses (they increase the reported Loss Event Rate). o Following from the earlier restrictions, neither DCCP will ever send Slow Receiver, Init Cookie, Ack Vector, Data Dropped (except on a DCCP-Response), Timestamp, Timestamp Echo, Identification, Challenge, Payload Checksum, or Loss Intervals options, or DCCP- Move, DCCP-DataAck, or DCCP-CloseReq packets. o The connection speed must be sufficiently small that sequence number wrapping will not become a problem, and extended sequence numbers will never be sent. A CCID 3-Lite connection is a normal DCCP connection, and MUST follow the DCCP [DCCP] and CCID 3 [CCID 3 PROFILE] specifications, except that if any of the above restrictions is violated, the receiving DCCP SHOULD reset the connection with Reason 193, Thin Violation. Kohler Section 4. [Page 5] INTERNET-DRAFT Expires: April 2004 October 2003 5. Connection Establishment This section describes how CCID 3-Thin connections are initiated. The terminology "thin" means that a client or server can only communicate with CCID 3-Thin restricted partners, and agrees to abide by those restrictions itself. "Fat" clients and/or servers, however, can communicate with any DCCP. 5.1. Thin Client Initiates Connection A thin client initiating a connection to any server MUST send a DCCP-Request packet containing only the following options in this exact order: Change L(CCID, 3), Change R(CCID, 3), Mandatory, CCID 3-Thin, and Padding. +--------+--------+--------+--------+ |00100001|00000100|00000001|00000011| |Change L| Len=4 | CCID | TFRC | +--------+--------+--------+--------+ |00100011|00000100|00000001|00000011| |Change R| Len=4 | CCID | TFRC | +--------+--------+--------+--------+ |00000001|11000001|00000010|00000000| |Mand'ory| 3-Thin | Len=2 |Padding | +--------+--------+--------+--------+ The DCCP-Request MUST NOT contain data. 5.2. Server Responds to Thin Client A server responding to this packet sequence will first change both CCID features to 3 (TFRC). If TFRC is not acceptable to the server, it MUST reset the connection with Reset Reason set to Fruitless Negotiation (since CCID is a server-priority feature). The server will then process the Mandatory CCID 3-Thin option. If the server agrees to the CCID 3-Thin restrictions above, it MUST send a DCCP- Response packet containing only the following options, in this order: Confirm R(CCID 3), Confirm L(CCID, 3), Mandatory, CCID 3-Thin, and Padding. Kohler Section 5.2. [Page 6] INTERNET-DRAFT Expires: April 2004 October 2003 +--------+--------+--------+--------+ |00100100|00000100|00000001|00000011| |ConfirmR| Len=4 | CCID | TFRC | +--------+--------+--------+--------+ |00100010|00000100|00000001|00000011| |ConfirmL| Len=4 | CCID | TFRC | +--------+--------+--------+--------+ |00000001|11000001|00000010|00000000| |Mand'ory| 3-Thin | Len=2 |Padding | +--------+--------+--------+--------+ The server SHOULD reset the connection if the DCCP-Request does not follow the CCID 3-Thin restrictions---for example, if the CCID 3-Thin option is followed by other options. If the server does not understand the CCID 3-Thin option, or does not agree to the Thin restrictions, it MUST reset the connection with Reason set to Option Error (because of the Mandatory option). 5.3. Thin Server Responds to Fat Client A thin server might be contacted by a fat client, which might send options and feature values on its DCCP-Request that do not follow the CCID 3-Thin restrictions. The server MUST process these options, but not necessarily as a conventional DCCP would. In particular: o The server MUST process options immediately preceded by a Mandatory option. If a Mandatory option does not fit the CCID 3-Thin restrictions, the server MUST reset the connection with Reason set to Option Error. If a Mandatory option does fit the restrictions, the server SHOULD respond as required; for example, when sent a Mandatory Change option with acceptable values, the server SHOULD respond with the appropriate Confirm option. An extremely restricted server MAY instead choose to reset the connection (with Reason set to Option Error) whenever any Mandatory option is received. o The server SHOULD process non-Mandatory options as well. For example, when sent a Change L(CCID, 2) option, the server SHOULD reset the connection with Reason set to Fruitless Negotiation; but when sent a Change L(CCID, 1 2 3) option, the server SHOULD respond with a Confirm R(CCID, 3) option. An extremely restricted server MAY instead ignore all non-mandatory options; the fat client will perform the necessary settings (or reset the connection) when it receives the server's Mandatory CCID 3-Thin option. Kohler Section 5.3. [Page 7] INTERNET-DRAFT Expires: April 2004 October 2003 o If the DCCP-Request contains data, the server's DCCP-Response MUST contain a Data Dropped option with Drop Code 0 (data dropped due to protocol constraints). o Any DCCP-Response MUST contain feature negotiation options that set both CCIDs to 3, followed by a Mandatory CCID 3-Thin option. The feature negotation options might be Change L(CCID, 3) and Change R(CCID, 3) options, as in the thin-client case; or if the server processed one or more Change(CCID) options on the DCCP- Request, they might be Confirm options. 5.4. Fat Client Responds to Thin Server's Response A fat client receiving a DCCP-Response containing a Mandatory CCID 3-Thin option MUST either reset the connection, if it cannot abide by the CCID 3-Thin restrictions, or respond with a DCCP-Ack. This DCCP-Ack MUST complete any feature negotiations initiated by the DCCP-Response, and MUST also contain a CCID 3-Thin option (either Mandatory or not). The thin server MUST be prepared to handle such a DCCP-Ack, but it MAY ignore the feature negotiation options on that Ack. Because the server sent a Mandatory CCID 3-Thin option on its DCCP-Response, it can assume that any ensuing DCCP-Ack abides by the CCID 3-Thin restrictions. 6. Security Considerations Security considerations for DCCP have been discussed in [DCCP]; security considerations for TFRC have been discussed in [RFC 3448]; and security considerations for DCCP CCID 3 have been discussed in [CCID 3 PROFILE]. CCID 3-Thin is not as secure against spoofed feedback, misbehaving receivers, and DOS attacks as straight DCCP with CCID 3. In particular, CCID 3-Thin does not support ECN, so the ECN Nonce-based verification mechanisms of CCID 3 are not available to it. Also, the lack of an Identification mechanism means that an attacker can cause a connection to stop by inducing a long burst of loss. 7. IANA Considerations The CCID 3-Thin specification allocates two values from IANA- administered registries: o The CCID 3-specific option 193, for CCID 3-Thin. o The CCID 3-specific Reset Reason 193, for Thin Violation. Kohler Section 7. [Page 8] INTERNET-DRAFT Expires: April 2004 October 2003 8. Thanks Thanks to Tom Phelan for his DCCP-Lite draft, which showed what he thought could be elided from full CCID 3. Normative References [CCID 2 PROFILE] S. Floyd and E. Kohler. Profile for DCCP Congestion Control ID 2: TCP-like Congestion Control, draft-ietf-dccp- ccid2-03.txt, work in progress, June 2003. [CCID 3 PROFILE] S. Floyd, E. Kohler, and J. Padhye. Profile for DCCP Congestion Control ID 3: TCP-Friendly Rate Control, draft- ietf-dccp-ccid3-03.txt, work in progress, June 2003. [DCCP] E. Kohler, M. Handley, S. Floyd, and J. Padhye. Datagram Congestion Control Protocol, draft-ietf-dccp-spec-04.txt, work in progress, June 2003. [RFC 2119] S. Bradner. Key Words For Use in RFCs to Indicate Requirement Levels. RFC 2119. [RFC 3448] M. Handley, S. Floyd, J. Padhye, and J. Widmer, TCP Friendly Rate Control (TFRC): Protocol Specification, RFC 3448, Proposed Standard, January 2003. Authors' Addresses Eddie Kohler ICSI Center for Internet Research 1947 Center Street, Suite 600 Berkeley, CA 94704 USA 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 Kohler [Page 9] INTERNET-DRAFT Expires: April 2004 October 2003 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. Kohler [Page 10]