tcpm M. HAWARI Internet-Draft Ecole Polytechnique / Cisco Systems Intended status: Experimental July 3, 2015 Expires: January 4, 2016 TCP Fast Open Cookie for IPv6 prefixes draft-hawari-tcpm-tfo-ipv6-prefixes-00 Abstract In order to support applications that require a large number of addresses or address space, a host may be assigned an aggregate IPv6 prefix rather than one or more discrete IPv6 addresses. This document briefly describes cases where this may occur, and specifies an extension to TCP Fast Open [RFC7413] to allow a client to use a single TCP Fast Open cookie for an IPv6 prefix. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on January 4, 2016. Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of HAWARI Expires January 4, 2016 [Page 1] Internet-Draft TFO IPv6 Prefixes July 2015 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 1.2. Motivation . . . . . . . . . . . . . . . . . . . . . . . 2 2. Proposed extension to TCP Fast Open . . . . . . . . . . . . . 3 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. The TCP Fast Open Prefix Length option (TFOPL). . . . . . 3 2.3. Behaviour of the client . . . . . . . . . . . . . . . . . 3 2.4. Behaviour of the server . . . . . . . . . . . . . . . . . 3 3. TCP Fast Open Prefix Length Option Format . . . . . . . . . . 4 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 7. Normative References . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction 1.1. Terminology 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 [RFC2119] . 1.2. Motivation TCP Fast Open(TFO) [RFC7413] provides applications with a mechanism allowing them to send data in the TCP SYN packet. It relies on a TFO cookie which is delivered by the server to the client. This cookie is then used by the client for all further TFO transactions to the server's IP address. Unlike IPv4, IPv6 provides the applications with the ability to leverage a great number of addresses. A single server may be associated to a whole IP prefix from which each of the IP addresses may be mapped to various application layer concepts. For example an IPv6 address can identify a service, a process, or even a chunk of data. Consequently, it is convenient to make a TFO cookie valid for a whole prefix instead of a single network address as this prefix may be hosted on a single server. That is the reason why this document proposes an extension to TFO to achieve this goal. HAWARI Expires January 4, 2016 [Page 2] Internet-Draft TFO IPv6 Prefixes July 2015 Another application of this extension appears in the context of a DNS-load-balanced cluster of servers. In this case, one server of the cluster will provide the client with a TFO cookie which is valid for the whole cluster, thus reducing the number of three way handshakes. 2. Proposed extension to TCP Fast Open 2.1. Overview When a server receives a TCP SYN packet asking for a TFO cookie, it generates a TFO cookie and sends a TCP SYN+ACK with the TFO cookie and the prefix length for which the TFO cookie is valid, thus allowing the client to reuse the cookie for the whole prefix containing the server. 2.2. The TCP Fast Open Prefix Length option (TFOPL). A new TCP Option named TCP Fast Open Prefix Length (TFOPL) is specified here. The value of this option is the prefix length (in bits) which a TCP Fast Open (TFO) cookie is valid for. 2.3. Behaviour of the client When the client requests a TFO cookie, it MUST include in the TCP SYN packet a TFOPL Option containing the value zero and an empty TFO cookie. When the client receives a TCP SYN+ACK packet including a TFO cookie and a TFOPL Option containing the value N, it MAY use this cookie for all further transactions with a host whose IP address belongs to the prefix of length N associated to the server. When the client receives a TCP SYN+ACK packet including a TFO cookie without any TFOPL Option, it MUST assume that the received prefix length is 128 (i.e, a single address). 2.4. Behaviour of the server When the server receives a TCP SYN packet including a TFO cookie and a TFOPL Option, it MUST generate a TFO cookie and reply with a SYN+ACK packet including the TFO cookie and the TFOPL option containing the prefix length in bits for which the TFO cookie is valid. When the server receives a TCP SYN packet including a TFO cookie but without any TFOPL Option, it MUST have the same behaviour as a regular TFO-enabled server as described in [RFC7413]. HAWARI Expires January 4, 2016 [Page 3] Internet-Draft TFO IPv6 Prefixes July 2015 If a TFO cookie is delivered by the server for a prefix of length N, all the servers belonging to this prefix MUST consider it as a valid TFO cookie, until its potential invalidation for the whole prefix. They MUST also deliver TFO cookies with a TFOPL option containing the value N. 3. TCP Fast Open Prefix Length Option Format The TFOPL option has a TLV structure: +------------+------------+-----------+ | TCP Option | Length | Prefix | | Kind Number| | Length | | (1 BYTE) | (1 BYTE) | (1 BYTE) | +------------+------------+-----------+ The length field MUST be equal to 0x3. The Prefix Length field MUST contain a value between 0 and 128. Any out of bounds Prefix Length Value MUST be considered as an absence of TFOPL option. 4. IANA Considerations IANA is kindly asked to allocate a value in the "TCP Option Kind Numbers" registry for the TCP Fast Open Prefix Length Option. The length of this new TCP option is 3. 5. Security Considerations A rogue TFO server can send a TFOPL option containing an arbitrary small value, thus endangering all the TFO cookies saved by the client prior to this transaction. The client may implement the following strategy in order to mitigate this issue: The client has a parameter N between 0 and 128. This parameter is a lower bound for the received prefix lengths. When the client receives a SYN+ACK packet with a TFOPL containing a value N', it acts as if it has received min(N,N'). This strategy prevents the server from erasing the cookies of the client outside the own prefix of length N of the server. A typical value for N may be 64. 6. Acknowledgements The author would like to thank Pierre Pfister, Mark Townsley and Andrew Yourtchencko for their contributions to this draft. HAWARI Expires January 4, 2016 [Page 4] Internet-Draft TFO IPv6 Prefixes July 2015 7. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP Fast Open", RFC 7413, December 2014. Author's Address Mohammed HAWARI Ecole Polytechnique / Cisco Systems Email: mohammed@hawari.fr HAWARI Expires January 4, 2016 [Page 5]