Network Working Group M. Boucadair
Internet-Draft C. Jacquenet
Intended status: Experimental Orange
Expires: September 5, 2016 March 4, 2016

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

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 | 
 +-------....------+--------+--------+

Figure 1

Section 5).

"Kindi" carries the code point of an option that a TCP endpoint supports and which it would like to negotiate with the remote peer. One or multiple "Kindi" fields may be included.

An endpoint that wishes to enable the capabilities associated with one or multiple TCP options must include the corresponding "Kind" codes in a TCP Capability option, which is included in the initial SYN. If the remote peer supports at least one of the options carried in the TCP Capability option, it replies with a SYN/ACK that includes the TCP Capability option and which only carries the code points of the options it supports. These values are then echoed in the ACK message the originating peer sends back to the remote peer.

When replying to a SYN message that includes a TCP Capability option, the remote peer should preserve the same order of the "Kindi" fields (of course, those that are not supported won't be included).

3. Security Considerations

The security considerations are to be completed.

4. Acknowledgements

Particular thanks to xxx

5. IANA Considerations

Authors of this document request IANA to assign a new TCP "kind" for the TCP Capability option.

6. References

6.1. Normative References

[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC6994] Touch, J., "Shared Use of Experimental TCP Options", RFC 6994, DOI 10.17487/RFC6994, August 2013.

6.2. Informative References

[I-D.boucadair-mptcp-natfwfree-profile] Boucadair, M., Jacquenet, C., Seite, P., Bonaventure, O. and D. Lingli, "An MPTCP Profile for NAT- and Firewall-Free Networks: Network-Assisted MPTCP Deployments", Internet-Draft draft-boucadair-mptcp-natfwfree-profile-00, July 2015.
[I-D.ietf-tcpm-tcp-edo] Touch, J. and W. Eddy, "TCP Extended Data Offset Option", Internet-Draft draft-ietf-tcpm-tcp-edo-04, November 2015.
[I-D.touch-tcpm-tcp-syn-ext-opt] Touch, J. and T. Faber, "TCP SYN Extended Option Space Using an Out-of-Band Segment", Internet-Draft draft-touch-tcpm-tcp-syn-ext-opt-03, October 2015.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S. and A. Romanow, "TCP Selective Acknowledgment Options", RFC 2018, DOI 10.17487/RFC2018, October 1996.
[RFC6824] Ford, A., Raiciu, C., Handley, M. and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013.

Authors' Addresses

Mohamed Boucadair Orange Rennes, 35000 France EMail: mohamed.boucadair@orange.com
Christian Jacquenet Orange Rennes, 35000 France EMail: christian.jacquenet@orange.com