draft-ietf-mptcp-rfc6824bis-16.txt   draft-ietf-mptcp-rfc6824bis-17.txt 
Internet Engineering Task Force A. Ford Internet Engineering Task Force A. Ford
Internet-Draft Pexip Internet-Draft Pexip
Obsoletes: 6824 (if approved) C. Raiciu Obsoletes: 6824 (if approved) C. Raiciu
Intended status: Standards Track U. Politechnica of Bucharest Intended status: Standards Track U. Politechnica of Bucharest
Expires: November 23, 2019 M. Handley Expires: December 1, 2019 M. Handley
U. College London U. College London
O. Bonaventure O. Bonaventure
U. catholique de Louvain U. catholique de Louvain
C. Paasch C. Paasch
Apple, Inc. Apple, Inc.
May 22, 2019 May 30, 2019
TCP Extensions for Multipath Operation with Multiple Addresses TCP Extensions for Multipath Operation with Multiple Addresses
draft-ietf-mptcp-rfc6824bis-16 draft-ietf-mptcp-rfc6824bis-17
Abstract Abstract
TCP/IP communication is currently restricted to a single path per TCP/IP communication is currently restricted to a single path per
connection, yet multiple paths often exist between peers. The connection, yet multiple paths often exist between peers. The
simultaneous use of these multiple paths for a TCP/IP session would simultaneous use of these multiple paths for a TCP/IP session would
improve resource usage within the network and, thus, improve user improve resource usage within the network and, thus, improve user
experience through higher throughput and improved resilience to experience through higher throughput and improved resilience to
network failure. network failure.
skipping to change at page 2, line 7 skipping to change at page 2, line 7
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 23, 2019. This Internet-Draft will expire on December 1, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 8, line 27 skipping to change at page 8, line 27
| | | | | | | |
| | | | | | | |
Figure 2: Example MPTCP Usage Scenario Figure 2: Example MPTCP Usage Scenario
1.5. Requirements Language 1.5. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
BCP 14 RFC 2119 [RFC2119] RFC 8174 [RFC8174] when, and only when, BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
they appear in all capitals, as shown here. capitals, as shown here.
2. Operation Overview 2. Operation Overview
This section presents a single description of common MPTCP operation, This section presents a single description of common MPTCP operation,
with reference to the protocol operation. This is a high-level with reference to the protocol operation. This is a high-level
overview of the key functions; the full specification follows in overview of the key functions; the full specification follows in
Section 3. Extensibility and negotiated features are not discussed Section 3. Extensibility and negotiated features are not discussed
here. Considerable reference is made to symbolic names of MPTCP here. Considerable reference is made to symbolic names of MPTCP
options throughout this section -- these are subtypes of the IANA- options throughout this section -- these are subtypes of the IANA-
assigned MPTCP option (see Section 8), and their formats are defined assigned MPTCP option (see Section 8), and their formats are defined
skipping to change at page 58, line 31 skipping to change at page 58, line 31
the HMAC will never be the same on two handshakes. Guidance on the HMAC will never be the same on two handshakes. Guidance on
generating random numbers suitable for use as keys is given in generating random numbers suitable for use as keys is given in
[RFC4086] and discussed in Section 3.1. HMAC is also used to secure [RFC4086] and discussed in Section 3.1. HMAC is also used to secure
the ADD_ADDR option, due to the threats identified in [RFC7430]. the ADD_ADDR option, due to the threats identified in [RFC7430].
The use of crypto capability bits in the initial connection handshake The use of crypto capability bits in the initial connection handshake
to negotiate use of a particular algorithm allows the deployment of to negotiate use of a particular algorithm allows the deployment of
additional crypto mechanisms in the future. Note that this additional crypto mechanisms in the future. Note that this
negotiation would be susceptible to a bid-down attack by an on-path negotiation would be susceptible to a bid-down attack by an on-path
active attacker who could modify the crypto capability bits response active attacker who could modify the crypto capability bits response
from the receiver to use a less secure crypto mechanism. However, an from the receiver to use a less secure crypto mechanism. The
on-path attacker would be able to man-in-the-middle the data anyway, security mechanism presented in this document should therefore
so the risk here is minimal. The security mechanism presented in protect against all forms of flooding and hijacking attacks discussed
this document should therefore protect against all forms of flooding in [RFC6181].
and hijacking attacks discussed in [RFC6181].
The version negotiation specified in Section 3.1, if differing MPTCP The version negotiation specified in Section 3.1, if differing MPTCP
versions shared a common negotiation format, would allow an on-path versions shared a common negotiation format, would allow an on-path
attacker to apply a theoretical bid-down attack. Since the v1 and v0 attacker to apply a theoretical bid-down attack. Since the v1 and v0
protocols have a different handshake, such an attack would require protocols have a different handshake, such an attack would require
the client to re-establish the connection using v0, and this being the client to re-establish the connection using v0, and this being
supported by the server. Note that an on-path attacker would have supported by the server. Note that an on-path attacker would have
access to the raw data, negating any other TCP-level security access to the raw data, negating any other TCP-level security
mechanisms. Also a change from RFC6824 has removed the subflow mechanisms. Also a change from RFC6824 has removed the subflow
identifier from the MP_PRIO option (Section 3.3.8), to remove the identifier from the MP_PRIO option (Section 3.3.8), to remove the
 End of changes. 6 change blocks. 
11 lines changed or deleted 10 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/