TCP Capability Option
draft-boucadair-tcpm-capability-option-00

Abstract

This document defines an experimental TCP option that can be used to negotiate a set of options that are supported by two TCP endpoints. The main motivation for designing this option is the optimization of the option space for SYN segments.

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 September 5, 2016.

Copyright Notice

Copyright (c) 2016 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 the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 1.1. Applicability
• 1.2. Requirements Language
• 2. TCP Capability Option
• 3. Security Considerations
• 4. Acknowledgements
• 5. IANA Considerations
• 6. References
• 6.1. Normative References
• 6.2. Informative References
• Authors' Addresses

1. Introduction

TCP ([RFC0793]) can be extended by defining new options. Because of the presence of NATs, firewalls, and other types of flow-aware service functions between two TCP endpoints, means to ensure that both endpoints support a given option, and that the paths used to forward traffic between them do not involve nodes that strip or alter the content of the options. This is actually achieved by negotiating the support of a given option during the 3WHS stage.

Typically, an option is included in the SYN message to inform the remote TCP peer that the originating TCP peer is "X"-capable (that is, it supports feature "X"). Upon receipt of the SYN message, and if no intermediary node has stripped that option, the remote peer will echo that option in a SYN/ACK if and only if it is also "X"-capable. Feature "X" can then be used if the SYN/ACK message that is received by the originating peer still carries the "X"-capable; the option must then be included in the ACK.

For example, several TCP extensions have been designed with this design rationale in mind, e.g., SYN-EOS [I-D.touch-tcpm-tcp-syn-ext-opt], EDO [I-D.ietf-tcpm-tcp-edo], SACK Permitted [RFC2018], MP_CAPABLE [RFC6824], etc. In the meantime, and given the limited TCP option space, it becomes more challenging to include all options in a single SYN message.

Several solutions have been proposed to solve that problem (e.g., [I-D.touch-tcpm-tcp-syn-ext-opt]) by means of generating a companion TCP message. This document proposes a solution that aims to optimize the required option space to facilitate the insertion of several "X"-capable options.

1.1. Applicability

The option is primarily designed for network configurations where the path between the TCP endpoints is managed (e.g., an MPTCP endpoint embedded in the CPE and the remote MPTCP endpoint is located in the network side; the paths between these endpoints are managed by the same administrative entity such as in [I-D.boucadair-mptcp-natfwfree-profile]).

A flow-aware device that removes the option will disable all the options that were included in the TCP Capability option. This is not supposed in the target deployment context for this option.

Some middleboxes may allow the TCP Capability option to pass through, but the individual options may be blocked. This is not supposed in the target deployment context for this option as those flow-aware functions are managed.

1.2. Requirements Language

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 [RFC2119].

2. TCP Capability Option

The format of the TCP Capability option is shown in Figure 1. The option follows the format defined in [RFC0793].

 +--------+--------+--------+--------+
 |  Kind  | Length |  Kind 1| Kind 2 |
 +--------+--------+--------+--------+
 :       ....      |Kind n-1| Kind n | 
 +-------....------+--------+--------+