idnits 2.17.1 draft-hewu-mptcp-trust-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (October 29, 2019) is 1639 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Li 3 Internet-Draft Q. Wu 4 Intended status: Informational B. Wu 5 Expires: May 1, 2020 Q. Zhang 6 J. Zhou 7 J. Liu 8 Tsinghua University 9 October 29, 2019 11 Trusted Multipath-TCP (MPTCP) extension 12 draft-hewu-mptcp-trust-00 14 Abstract 16 Multipath TCP (MPTCP) adds the capability of using multiple paths to 17 a regular TCP session and is being deployed extensively. Source 18 Address Validation (SAV) technologies are proposed to prevent network 19 nodes from spoofing others' IP addresses and thus improve the 20 accountability of networks. This document proposes a trusted MPTCP 21 extension based on SAV, which enables MPTCP to work with SAV and thus 22 improve the accountability of MPTCP connections. This extension 23 doesn't intend to replace the security solutions to resolving IP 24 forged attacks, like Hash-based Message Authentication Code (HMAC), 25 but to improve the accountability of them and the whole connection. 27 Status of This Memo 29 This Internet-Draft is submitted in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at https://datatracker.ietf.org/drafts/current/. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 This Internet-Draft will expire on May 1, 2020. 44 Copyright Notice 46 Copyright (c) 2019 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (https://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 63 3. Operation Overview . . . . . . . . . . . . . . . . . . . . . 3 64 3.1. Trusted Address notification . . . . . . . . . . . . . . 3 65 3.2. Trusted Connection notification . . . . . . . . . . . . . 4 66 3.3. Control packets processing . . . . . . . . . . . . . . . 5 67 4. ADD_ADDR extension . . . . . . . . . . . . . . . . . . . . . 5 68 5. ADDR_TRUST option . . . . . . . . . . . . . . . . . . . . . . 6 69 6. Trusted Path Binding Table (TPBT) . . . . . . . . . . . . . . 6 70 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 71 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 72 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 73 10. Informative References . . . . . . . . . . . . . . . . . . . 7 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 76 1. Introduction 78 Multipath TCP (MPTCP) [I-D.ietf-mptcp-rfc6824bis][RFC6824] adds the 79 capability of using multiple paths to a regular TCP session and is 80 being deployed extensively. The main threats of MPTCP are described 81 in [RFC6181], [RFC7430] and they are mainly caused by forged control 82 packets sent by malicious hosts with forged IP addresses. Source 83 Address Validation (SAV) methods like Source Address Validation 84 Architecture (SAVA) [RFC5210] and Source Address Validation 85 Improvement (SAVI) [RFC7039] are developed to prevent nodes from 86 spoofing others' IP addresses with finer-grained ingress filtering. 88 This document proposes a SAV based MPTCP enhancement, which enables 89 MPTCP to work with SAV and thus improve the accountability of MPTCP 90 connections. 92 2. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED","MAY", and "OPTIONAL" in this 96 document are to be interpreted as described in [RFC2119]. 98 This document uses the MPTCP terminology introduced in 99 [I-D.ietf-mptcp-rfc6824bis] [RFC6824]. 101 SAV: Source Address Validation. 103 SAVA: Source Address Validation Architecture, refer to [RFC5210]. 105 SAVI: Source Address Validation Improvement, refer to [RFC7039]. 107 Trusted Connection: A TCP connection which SAV is deployed on both 108 hosts. 110 HMAC: Hash-based Message Authentication Code, refer to [RFC2104]. 112 Trusted Address: IP address protected by SAV which means it can't be 113 forged. 115 3. Operation Overview 117 This section specifies the behavior of source address validation 118 based MPTCP enhancement. 120 Note that this enhancement doesn't intend to replace the security 121 solutions to resolving IP forged attacks, like Hash-based Message 122 Authentication Code (HMAC), but to improve the accountability of them 123 and the whole connection. However, security-oriented operations 124 which protect control packets from being forged like HMAC MAY be 125 omitted if there is a trusted connection between the both hosts, for 126 the accountability of the connection is guaranteed by SAV. Other 127 packets and their processing which are not mentioned in this document 128 stay the same as related description in 129 [I-D.ietf-mptcp-rfc6824bis][RFC6824]. 131 3.1. Trusted Address notification 133 A Trust Flag is set in ADD_ADDR option to indicate the IP address is 134 trusted or not. After Host B receives an ADD_ADDR option, it MUST 135 add the binding entry to Trusted Path Binding Table (TPBT, see 136 section 6) and send a packet to Host A to indicate it has 137 successfully received ADD_ADDR option. 139 Host A Host B 140 ------ ------ 141 ADD_ADDR -> 142 [Echo-flag=0, 143 IP-A2, 144 IP-A2's Address ID, 145 Trust-flag, 146 HMAC of IP-A2 and TRUST FLAG] 148 <- ADD_ADDR 149 [Echo-flag=1, 150 IP-A2, 151 IP-A2's Address ID, 152 Trust-flag] 154 Figure 1 156 HMAC-A = HMAC(Key=(Key-A+Key-B), Msg=(IP-A2+TRUST Flag)) 158 Note that if the ADD_ADDR option is transmitted through a trusted 159 connection, the HMAC-A MAY be omitted. If the HMAC is transmitted 160 and it's incorrect, the ADD_ADDR packet MUST be silently discarded. 162 3.2. Trusted Connection notification 164 When a MPTCP subflow or an initial MPTCP flow is established, the 165 trust flag of this flow MAY not be known by both hosts. Examples as 166 follows: 168 (1) There is no ADD_ADDR option sent by each other before the initial 169 MPTCP flow is established. 171 (2) Host B starts initializing a subflow after receiving the ADD_ADDR 172 option of Host A without sending its own ADD_ADDR option, when the 173 subflow is established, Host A does not know the trust flag about 174 this subflow if the Host A's address of this subflow is trusted. 176 An ADDR_TRUST option is proposed to notify hosts the trust flag. 177 After a subflow is established, if the host does not know the trust 178 flag of this subflow, it will add an entry (Trust=False) with peer 179 address to the TPBT, and send an ADDR_TRUST option to the peer to ask 180 for the trust flag of the peer's corresponding address. Once a host 181 receives a ADDR_TRUST (E=0) packet and the HMAC is correct, it adds 182 an entry(Trust=True) to the TPBT according the packet if it has not 183 ever received an ADD_ADDR packet from this address. Also, the host 184 checks the trust flag of the local address of the connection 185 corresponding to the peer address: if the address is trusted, the 186 host will send a ADDR_TRUST(E=1) packet with local address and HMAC 187 of two address, otherwise it does nothing. The host sent the 188 ADDR_TRUST(E=0) packet will set the corresponding trust flag to True 189 if it receives the ADDR_TRUST(E=1) packet. 191 Host A Host B 192 ------ ------ 193 ADDR_TRUST -> 194 [Echo-flag=0, 195 IP-A, 196 IP-A's Address ID, 197 HMAC of IP-A] 199 <- ADDR_TRUST 200 [Echo-flag=1, 201 IP-B, 202 IP-B's Address ID, 203 HMAC of IP-A and IP-B] 205 Figure 2 207 HMAC-A = HMAC(Key=(Key-A+Key-B), Msg=(IP-A)) 209 HMAC-B = HMAC(Key=(Key-A+Key-B), Msg=(IP-A+IP-B)) 211 Note that if the ADDR_TRUST option is transmitted through a trusted 212 connection, the HMAC-A and HMAC-B MAY be omitted. If the HMAC is 213 transmitted and it's incorrect, the ADDR_TRUST packet MUST be 214 silently discarded. 216 3.3. Control packets processing 218 Before sending a control packet, the sender MUST check the TPBT: if 219 there is a Trusted Connection whose source address and destination 220 address are both trusted, it sends the control packet via the Trusted 221 Connection and other security-oriented operations are OPTIONAL; if 222 there is no Trusted Connection, the processing is the same as 223 [I-D.ietf-mptcp-rfc6824bis][RFC6824]. 225 4. ADD_ADDR extension 227 The ADD_ADDR option on packets includes 4 bits of flags, 2 of which 228 are currently reserved and MUST be set to zero by the sender. The 229 third bit, labeled "T", indicates the IP address is trusted(T=1) or 230 not(T=0). The final bit, labeled "E", is used to Guarantee the 231 reliability: a receiver receiving a fresh ADD_ADDR option (where 232 E=0), will send the same option back to the sender, but not including 233 the HMAC, and with E=1. 235 The format of ADD_ADDR option is shown in Figure 3. 237 1 2 3 238 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 239 +---------------+---------------+-------+-------+---------------+ 240 | Kind | Length |Subtype| |T|E| Address ID | 241 +---------------+---------------+-------+-------+---------------+ 242 | Address (IPv4 - 4 octets / IPv6 - 16 octets) | 243 +-------------------------------+-------------------------------+ 244 | Port (2 octets, optional) | | 245 +-------------------------------+ | 246 | Truncated HMAC (8 octets, if length > 10 octets) | 247 | +-------------------------------+ 248 | | 249 +-------------------------------+ 251 Figure 3: Add Address (ADD_ADDR) Option with HMAC 253 5. ADDR_TRUST option 255 The ADDR_TRUST option on packets includes 4 bits of flags, 3 of which 256 are currently reserved and MUST be set to zero by the sender. The 257 final bit, labeled "E", used to guarantee the reliability, a receiver 258 receiving a fresh ADDR_TRUST option (where E=0), will send the same 259 option back to the sender, but with HMAC of both Address, and with 260 E=1. 262 The format of ADDR_TRUST option is shown in Figure 4. 264 1 2 3 265 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 266 +---------------+---------------+-------+-------+---------------+ 267 | Kind | Length |Subtype| |E| Address ID | 268 +---------------+---------------+-------+-------+---------------+ 269 | Address (IPv4 - 4 octets / IPv6 - 16 octets) | 270 +-------------------------------+-------------------------------+ 271 | Truncated HMAC (8 octets, if length > 10 octets) | 272 | | 273 +-------------------------------+-------------------------------+ 275 Figure 4: Address Trust (ADDR_TRUST) Option with HMAC 277 6. Trusted Path Binding Table (TPBT) 279 The Trusted Path Binding Table, which is implemented at the terminal, 280 is used to contain the bindings between the available sockets of peer 281 and their trust flags. This table uses "SubFlow" as the primary key 282 which contains a "Sip" meaning the source IP address of the subflow 283 and a "Dip" for the destination IP address. Each entry in TPBT 284 contains a "SipTrust" field representing whether the "Sip" is trusted 285 and a "DipTrust" field for "Dip"; a Lifetime field is used to save 286 the state of the life cycle and when the life cycle expires, the 287 corresponding entry will be deleted; in addition, an Other field that 288 is used to store other information or further extensions in the 289 future. 291 The following table is an example of TPBT. 293 +---------------+----------+----------+----------+-------+ 294 | SubFlow | SipTrust | DipTrust | Lifetime | Other | 295 +---------------+----------+----------+----------+-------+ 296 | Sf(Sip1,Dip1) | True | True | 65535 | / | 297 | Sf(Sip1,Dip2) | True | False | 10000 | / | 298 | Sf(Sip2,Dip1) | False | True | 10000 | / | 299 | Sf(Sip2,Dip2) | False | False | 0 | / | 300 +---------------+----------+----------+----------+-------+ 302 Table 1: An Example of TPBT 304 7. Acknowledgements 306 8. IANA Considerations 308 This memo includes no request to IANA. 310 9. Security Considerations 312 Some considerations on man-in-the-middle attacks may be raised for 313 this extension. SAV methods like SAVI and SAVA are proposed to 314 improve network accountability and thus defend attacks including man- 315 in-the-middle attacks. This document is proposed to allow MPTCP work 316 with SAV, so man-in-the-middle will not be a problem if SAV is 317 deployed extensively. 319 10. Informative References 321 [I-D.ietf-mptcp-rfc6824bis] 322 Ford, A., Raiciu, C., Handley, M., Bonaventure, O., and C. 323 Paasch, "TCP Extensions for Multipath Operation with 324 Multiple Addresses", June 2019, 325 . 328 [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- 329 Hashing for Message Authentication", RFC 2104, 330 DOI 10.17487/RFC2104, February 1997, 331 . 333 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 334 Requirement Levels", BCP 14, RFC 2119, 335 DOI 10.17487/RFC2119, March 1997, 336 . 338 [RFC5210] Wu, J., Bi, J., Li, X., Ren, G., Xu, K., and M. Williams, 339 "A Source Address Validation Architecture (SAVA) Testbed 340 and Deployment Experience", RFC 5210, 341 DOI 10.17487/RFC5210, June 2008, 342 . 344 [RFC6181] Bagnulo, M., "Threat Analysis for TCP Extensions for 345 Multipath Operation with Multiple Addresses", RFC 6181, 346 DOI 10.17487/RFC6181, March 2011, 347 . 349 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 350 "TCP Extensions for Multipath Operation with Multiple 351 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 352 . 354 [RFC7039] Wu, J., Bi, J., Bagnulo, M., Baker, F., and C. Vogt, Ed., 355 "Source Address Validation Improvement (SAVI) Framework", 356 RFC 7039, DOI 10.17487/RFC7039, October 2013, 357 . 359 [RFC7430] Bagnulo, M., Paasch, C., Gont, F., Bonaventure, O., and C. 360 Raiciu, "Analysis of Residual Threats and Possible Fixes 361 for Multipath TCP (MPTCP)", RFC 7430, 362 DOI 10.17487/RFC7430, July 2015, 363 . 365 Authors' Addresses 367 Hewu Li 368 Tsinghua University 369 Institute for Network Sciences and Cyberspace, Tsinghua University 370 Beijing 100084 371 China 373 Email: lihewu@cernet.edu.cn 374 Qian Wu 375 Tsinghua University 376 Institute for Network Sciences and Cyberspace, Tsinghua University 377 Beijing 100084 378 China 380 Email: wuqian@cernet.edu.cn 382 Boyang Wu 383 Tsinghua University 384 Institute for Network Sciences and Cyberspace, Tsinghua University 385 Beijing 100084 386 China 388 Email: wuboyangyawn@hotmail.com 390 Qi Zhang 391 Tsinghua University 392 Institute for Network Sciences and Cyberspace, Tsinghua University 393 Beijing 100084 394 China 396 Email: qi-zhang19@mails.tsinghua.edu.cn 398 Jiang Zhou 399 Tsinghua University 400 Institute for Network Sciences and Cyberspace, Tsinghua University 401 Beijing 100084 402 China 404 Email: zhou-j17@mails.tsinghua.edu.cn 406 Jun Liu 407 Tsinghua University 408 Institute for Network Sciences and Cyberspace, Tsinghua University 409 Beijing 100084 410 China 412 Email: juneliu@tsinghua.edu.cn