Internet DRAFT - draft-hewu-mptcp-trust
draft-hewu-mptcp-trust
Internet Engineering Task Force H. Li
Internet-Draft Q. Wu
Intended status: Informational B. Wu
Expires: May 1, 2020 Q. Zhang
J. Zhou
J. Liu
Tsinghua University
October 29, 2019
Trusted Multipath-TCP (MPTCP) extension
draft-hewu-mptcp-trust-00
Abstract
Multipath TCP (MPTCP) adds the capability of using multiple paths to
a regular TCP session and is being deployed extensively. Source
Address Validation (SAV) technologies are proposed to prevent network
nodes from spoofing others' IP addresses and thus improve the
accountability of networks. This document proposes a trusted MPTCP
extension based on SAV, which enables MPTCP to work with SAV and thus
improve the accountability of MPTCP connections. This extension
doesn't intend to replace the security solutions to resolving IP
forged attacks, like Hash-based Message Authentication Code (HMAC),
but to improve the accountability of them and the whole connection.
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 https://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 May 1, 2020.
Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved.
Li, et al. Expires May 1, 2020 [Page 1]
Internet-Draft Trusted MPTCP extension October 2019
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Operation Overview . . . . . . . . . . . . . . . . . . . . . 3
3.1. Trusted Address notification . . . . . . . . . . . . . . 3
3.2. Trusted Connection notification . . . . . . . . . . . . . 4
3.3. Control packets processing . . . . . . . . . . . . . . . 5
4. ADD_ADDR extension . . . . . . . . . . . . . . . . . . . . . 5
5. ADDR_TRUST option . . . . . . . . . . . . . . . . . . . . . . 6
6. Trusted Path Binding Table (TPBT) . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
9. Security Considerations . . . . . . . . . . . . . . . . . . . 7
10. Informative References . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
1. Introduction
Multipath TCP (MPTCP) [I-D.ietf-mptcp-rfc6824bis][RFC6824] adds the
capability of using multiple paths to a regular TCP session and is
being deployed extensively. The main threats of MPTCP are described
in [RFC6181], [RFC7430] and they are mainly caused by forged control
packets sent by malicious hosts with forged IP addresses. Source
Address Validation (SAV) methods like Source Address Validation
Architecture (SAVA) [RFC5210] and Source Address Validation
Improvement (SAVI) [RFC7039] are developed to prevent nodes from
spoofing others' IP addresses with finer-grained ingress filtering.
This document proposes a SAV based MPTCP enhancement, which enables
MPTCP to work with SAV and thus improve the accountability of MPTCP
connections.
2. 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].
Li, et al. Expires May 1, 2020 [Page 2]
Internet-Draft Trusted MPTCP extension October 2019
This document uses the MPTCP terminology introduced in
[I-D.ietf-mptcp-rfc6824bis] [RFC6824].
SAV: Source Address Validation.
SAVA: Source Address Validation Architecture, refer to [RFC5210].
SAVI: Source Address Validation Improvement, refer to [RFC7039].
Trusted Connection: A TCP connection which SAV is deployed on both
hosts.
HMAC: Hash-based Message Authentication Code, refer to [RFC2104].
Trusted Address: IP address protected by SAV which means it can't be
forged.
3. Operation Overview
This section specifies the behavior of source address validation
based MPTCP enhancement.
Note that this enhancement doesn't intend to replace the security
solutions to resolving IP forged attacks, like Hash-based Message
Authentication Code (HMAC), but to improve the accountability of them
and the whole connection. However, security-oriented operations
which protect control packets from being forged like HMAC MAY be
omitted if there is a trusted connection between the both hosts, for
the accountability of the connection is guaranteed by SAV. Other
packets and their processing which are not mentioned in this document
stay the same as related description in
[I-D.ietf-mptcp-rfc6824bis][RFC6824].
3.1. Trusted Address notification
A Trust Flag is set in ADD_ADDR option to indicate the IP address is
trusted or not. After Host B receives an ADD_ADDR option, it MUST
add the binding entry to Trusted Path Binding Table (TPBT, see
section 6) and send a packet to Host A to indicate it has
successfully received ADD_ADDR option.
Li, et al. Expires May 1, 2020 [Page 3]
Internet-Draft Trusted MPTCP extension October 2019
Host A Host B
------ ------
ADD_ADDR ->
[Echo-flag=0,
IP-A2,
IP-A2's Address ID,
Trust-flag,
HMAC of IP-A2 and TRUST FLAG]
<- ADD_ADDR
[Echo-flag=1,
IP-A2,
IP-A2's Address ID,
Trust-flag]
Figure 1
HMAC-A = HMAC(Key=(Key-A+Key-B), Msg=(IP-A2+TRUST Flag))
Note that if the ADD_ADDR option is transmitted through a trusted
connection, the HMAC-A MAY be omitted. If the HMAC is transmitted
and it's incorrect, the ADD_ADDR packet MUST be silently discarded.
3.2. Trusted Connection notification
When a MPTCP subflow or an initial MPTCP flow is established, the
trust flag of this flow MAY not be known by both hosts. Examples as
follows:
(1) There is no ADD_ADDR option sent by each other before the initial
MPTCP flow is established.
(2) Host B starts initializing a subflow after receiving the ADD_ADDR
option of Host A without sending its own ADD_ADDR option, when the
subflow is established, Host A does not know the trust flag about
this subflow if the Host A's address of this subflow is trusted.
An ADDR_TRUST option is proposed to notify hosts the trust flag.
After a subflow is established, if the host does not know the trust
flag of this subflow, it will add an entry (Trust=False) with peer
address to the TPBT, and send an ADDR_TRUST option to the peer to ask
for the trust flag of the peer's corresponding address. Once a host
receives a ADDR_TRUST (E=0) packet and the HMAC is correct, it adds
an entry(Trust=True) to the TPBT according the packet if it has not
ever received an ADD_ADDR packet from this address. Also, the host
checks the trust flag of the local address of the connection
corresponding to the peer address: if the address is trusted, the
host will send a ADDR_TRUST(E=1) packet with local address and HMAC
Li, et al. Expires May 1, 2020 [Page 4]
Internet-Draft Trusted MPTCP extension October 2019
of two address, otherwise it does nothing. The host sent the
ADDR_TRUST(E=0) packet will set the corresponding trust flag to True
if it receives the ADDR_TRUST(E=1) packet.
Host A Host B
------ ------
ADDR_TRUST ->
[Echo-flag=0,
IP-A,
IP-A's Address ID,
HMAC of IP-A]
<- ADDR_TRUST
[Echo-flag=1,
IP-B,
IP-B's Address ID,
HMAC of IP-A and IP-B]
Figure 2
HMAC-A = HMAC(Key=(Key-A+Key-B), Msg=(IP-A))
HMAC-B = HMAC(Key=(Key-A+Key-B), Msg=(IP-A+IP-B))
Note that if the ADDR_TRUST option is transmitted through a trusted
connection, the HMAC-A and HMAC-B MAY be omitted. If the HMAC is
transmitted and it's incorrect, the ADDR_TRUST packet MUST be
silently discarded.
3.3. Control packets processing
Before sending a control packet, the sender MUST check the TPBT: if
there is a Trusted Connection whose source address and destination
address are both trusted, it sends the control packet via the Trusted
Connection and other security-oriented operations are OPTIONAL; if
there is no Trusted Connection, the processing is the same as
[I-D.ietf-mptcp-rfc6824bis][RFC6824].
4. ADD_ADDR extension
The ADD_ADDR option on packets includes 4 bits of flags, 2 of which
are currently reserved and MUST be set to zero by the sender. The
third bit, labeled "T", indicates the IP address is trusted(T=1) or
not(T=0). The final bit, labeled "E", is used to Guarantee the
reliability: a receiver receiving a fresh ADD_ADDR option (where
E=0), will send the same option back to the sender, but not including
the HMAC, and with E=1.
Li, et al. Expires May 1, 2020 [Page 5]
Internet-Draft Trusted MPTCP extension October 2019
The format of ADD_ADDR option is shown in Figure 3.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+-------+---------------+
| Kind | Length |Subtype| |T|E| Address ID |
+---------------+---------------+-------+-------+---------------+
| Address (IPv4 - 4 octets / IPv6 - 16 octets) |
+-------------------------------+-------------------------------+
| Port (2 octets, optional) | |
+-------------------------------+ |
| Truncated HMAC (8 octets, if length > 10 octets) |
| +-------------------------------+
| |
+-------------------------------+
Figure 3: Add Address (ADD_ADDR) Option with HMAC
5. ADDR_TRUST option
The ADDR_TRUST option on packets includes 4 bits of flags, 3 of which
are currently reserved and MUST be set to zero by the sender. The
final bit, labeled "E", used to guarantee the reliability, a receiver
receiving a fresh ADDR_TRUST option (where E=0), will send the same
option back to the sender, but with HMAC of both Address, and with
E=1.
The format of ADDR_TRUST option is shown in Figure 4.
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+---------------+---------------+-------+-------+---------------+
| Kind | Length |Subtype| |E| Address ID |
+---------------+---------------+-------+-------+---------------+
| Address (IPv4 - 4 octets / IPv6 - 16 octets) |
+-------------------------------+-------------------------------+
| Truncated HMAC (8 octets, if length > 10 octets) |
| |
+-------------------------------+-------------------------------+
Figure 4: Address Trust (ADDR_TRUST) Option with HMAC
6. Trusted Path Binding Table (TPBT)
The Trusted Path Binding Table, which is implemented at the terminal,
is used to contain the bindings between the available sockets of peer
and their trust flags. This table uses "SubFlow" as the primary key
which contains a "Sip" meaning the source IP address of the subflow
Li, et al. Expires May 1, 2020 [Page 6]
Internet-Draft Trusted MPTCP extension October 2019
and a "Dip" for the destination IP address. Each entry in TPBT
contains a "SipTrust" field representing whether the "Sip" is trusted
and a "DipTrust" field for "Dip"; a Lifetime field is used to save
the state of the life cycle and when the life cycle expires, the
corresponding entry will be deleted; in addition, an Other field that
is used to store other information or further extensions in the
future.
The following table is an example of TPBT.
+---------------+----------+----------+----------+-------+
| SubFlow | SipTrust | DipTrust | Lifetime | Other |
+---------------+----------+----------+----------+-------+
| Sf(Sip1,Dip1) | True | True | 65535 | / |
| Sf(Sip1,Dip2) | True | False | 10000 | / |
| Sf(Sip2,Dip1) | False | True | 10000 | / |
| Sf(Sip2,Dip2) | False | False | 0 | / |
+---------------+----------+----------+----------+-------+
Table 1: An Example of TPBT
7. Acknowledgements
8. IANA Considerations
This memo includes no request to IANA.
9. Security Considerations
Some considerations on man-in-the-middle attacks may be raised for
this extension. SAV methods like SAVI and SAVA are proposed to
improve network accountability and thus defend attacks including man-
in-the-middle attacks. This document is proposed to allow MPTCP work
with SAV, so man-in-the-middle will not be a problem if SAV is
deployed extensively.
10. Informative References
[I-D.ietf-mptcp-rfc6824bis]
Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C.
Paasch, "TCP Extensions for Multipath Operation with
Multiple Addresses", June 2019,
<https://datatracker.ietf.org/doc/html/draft-ietf-mptcp-
rfc6824bis-18>.
Li, et al. Expires May 1, 2020 [Page 7]
Internet-Draft Trusted MPTCP extension October 2019
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-
Hashing for Message Authentication", RFC 2104,
DOI 10.17487/RFC2104, February 1997,
<https://www.rfc-editor.org/info/rfc2104>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC5210] Wu, J., Bi, J., Li, X., Ren, G., Xu, K., and M. Williams,
"A Source Address Validation Architecture (SAVA) Testbed
and Deployment Experience", RFC 5210,
DOI 10.17487/RFC5210, June 2008,
<https://www.rfc-editor.org/info/rfc5210>.
[RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for
Multipath Operation with Multiple Addresses", RFC 6181,
DOI 10.17487/RFC6181, March 2011,
<https://www.rfc-editor.org/info/rfc6181>.
[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,
<https://www.rfc-editor.org/info/rfc6824>.
[RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed.,
"Source Address Validation Improvement (SAVI) Framework",
RFC 7039, DOI 10.17487/RFC7039, October 2013,
<https://www.rfc-editor.org/info/rfc7039>.
[RFC7430] Bagnulo, M., Paasch, C., Gont, F., Bonaventure, O., and C.
Raiciu, "Analysis of Residual Threats and Possible Fixes
for Multipath TCP (MPTCP)", RFC 7430,
DOI 10.17487/RFC7430, July 2015,
<https://www.rfc-editor.org/info/rfc7430>.
Authors' Addresses
Hewu Li
Tsinghua University
Institute for Network Sciences and Cyberspace, Tsinghua University
Beijing 100084
China
Email: lihewu@cernet.edu.cn
Li, et al. Expires May 1, 2020 [Page 8]
Internet-Draft Trusted MPTCP extension October 2019
Qian Wu
Tsinghua University
Institute for Network Sciences and Cyberspace, Tsinghua University
Beijing 100084
China
Email: wuqian@cernet.edu.cn
Boyang Wu
Tsinghua University
Institute for Network Sciences and Cyberspace, Tsinghua University
Beijing 100084
China
Email: wuboyangyawn@hotmail.com
Qi Zhang
Tsinghua University
Institute for Network Sciences and Cyberspace, Tsinghua University
Beijing 100084
China
Email: qi-zhang19@mails.tsinghua.edu.cn
Jiang Zhou
Tsinghua University
Institute for Network Sciences and Cyberspace, Tsinghua University
Beijing 100084
China
Email: zhou-j17@mails.tsinghua.edu.cn
Jun Liu
Tsinghua University
Institute for Network Sciences and Cyberspace, Tsinghua University
Beijing 100084
China
Email: juneliu@tsinghua.edu.cn
Li, et al. Expires May 1, 2020 [Page 9]
