Internet DRAFT - draft-boucadair-tcpm-capability-option
draft-boucadair-tcpm-capability-option
Network Working Group M. Boucadair
Internet-Draft C. Jacquenet
Intended status: Experimental Orange
Expires: June 11, 2017 December 8, 2016
TCP Capability Option
draft-boucadair-tcpm-capability-option-01
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 June 11, 2017.
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.
Boucadair & Jacquenet Expires June 11, 2017 [Page 1]
Internet-Draft TCP Capability Option December 2016
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Applicability . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. TCP Capability Option . . . . . . . . . . . . . . . . . . . . 3
3. Security Considerations . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4
5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4
5.1. Normative References . . . . . . . . . . . . . . . . . . 4
5.2. Informative References . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 5
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.
Boucadair & Jacquenet Expires June 11, 2017 [Page 2]
Internet-Draft TCP Capability Option December 2016
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
"Kind" is to be assigned by IANA (see Section 4).
In order to conduct experiments with this option, a format that
adheres to [RFC6994] is used (see Figure 2). ExID MUST be set to
0x0CA0 (3232).
Boucadair & Jacquenet Expires June 11, 2017 [Page 3]
Internet-Draft TCP Capability Option December 2016
+--------+--------+--------+--------+
| Kind | Length | ExID |
+--------+--------+--------+--------+
: Kind 1 | Kind 2 | ... :
+-------....------+-----------------+
Figure 2
"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. IANA Considerations
IANA is requested to record the following identifier in the "TCP
Experimental Option Experiment Identifiers (TCP ExIDs)" registry:
Value Description Reference
0x0CA0 TCP Capability Option [This document]
5. References
5.1. Normative References
[RFC0793] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, DOI 10.17487/RFC0793, September 1981,
<http://www.rfc-editor.org/info/rfc793>.
Boucadair & Jacquenet Expires June 11, 2017 [Page 4]
Internet-Draft TCP Capability Option December 2016
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[RFC6994] Touch, J., "Shared Use of Experimental TCP Options",
RFC 6994, DOI 10.17487/RFC6994, August 2013,
<http://www.rfc-editor.org/info/rfc6994>.
5.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", draft-
boucadair-mptcp-natfwfree-profile-00 (work in progress),
July 2015.
[I-D.ietf-tcpm-tcp-edo]
Touch, J. and W. Eddy, "TCP Extended Data Offset Option",
draft-ietf-tcpm-tcp-edo-06 (work in progress), June 2016.
[I-D.touch-tcpm-tcp-syn-ext-opt]
Touch, J. and T. Faber, "TCP SYN Extended Option Space
Using an Out-of-Band Segment", draft-touch-tcpm-tcp-syn-
ext-opt-05 (work in progress), October 2016.
[RFC2018] Mathis, M., Mahdavi, J., Floyd, S., and A. Romanow, "TCP
Selective Acknowledgment Options", RFC 2018,
DOI 10.17487/RFC2018, October 1996,
<http://www.rfc-editor.org/info/rfc2018>.
[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,
<http://www.rfc-editor.org/info/rfc6824>.
Authors' Addresses
Mohamed Boucadair
Orange
Rennes 35000
France
Email: mohamed.boucadair@orange.com
Boucadair & Jacquenet Expires June 11, 2017 [Page 5]
Internet-Draft TCP Capability Option December 2016
Christian Jacquenet
Orange
Rennes 35000
France
Email: christian.jacquenet@orange.com
Boucadair & Jacquenet Expires June 11, 2017 [Page 6]
