idnits 2.17.1 draft-pc-tcpm-tcp-seamless-mobility-option-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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The TCP-SMO discussed does introduce a security issue as anybody can hijack the existing TCP connection by changing the source IP address (Connection Hijacking). It is recommended to use security at IP (IPsec) or transport layer-Authentication Option (TCP-AO) [RFC5925] for securing the TCP connection including the TCP header. When [RFC5925] is used TCP-SMO size MUST not be exceeded more than 12 bytes to accommodate TCP-AO [RFC5925]. -- The document date (July 16, 2017) is 2474 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'NIST-SP800-38B' is mentioned on line 180, but not defined == Missing Reference: 'FIPS197' is mentioned on line 180, but not defined == Unused Reference: 'RFC2631' is defined on line 559, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) -- Obsolete informational reference (is this intentional?): RFC 6824 (Obsoleted by RFC 8684) -- Obsolete informational reference (is this intentional?): RFC 6830 (Obsoleted by RFC 9300, RFC 9301) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TCPM Working Group B. Pithawala 3 Internet-Draft U. Chunduri, Ed. 4 Intended status: Informational Huawei Technologies 5 Expires: January 17, 2018 July 16, 2017 7 TCP Mobility Option with Identifiers 8 draft-pc-tcpm-tcp-seamless-mobility-option-00 10 Abstract 12 This document specifies the TCP Seamless Mobility Option (TCP-SMO) 13 with variable length identifiers. TCP-SMO allows mobility with 14 session continuity, when either of the TCP endpoint change its IP 15 address. This is being done securely and without any additional 16 round trips during mobility event. 18 Requirements Language 20 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 21 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 22 document are to be interpreted as described in RFC2119 [RFC2119]. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on January 17, 2018. 41 Copyright Notice 43 Copyright (c) 2017 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Acronyms . . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. TCP Seamless Mobility Option with Identifiers . . . . . . . . 3 61 4. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 5 62 4.1. Flow of TCP Connection with SMO And IP Address Change . . 5 63 4.2. Security mechanisms during IP address change . . . . . . 7 64 4.2.1. Security Option-1 . . . . . . . . . . . . . . . . . . 7 65 4.2.2. Security Option-2 . . . . . . . . . . . . . . . . . . 7 66 4.3. Notifying IP Address Change Event . . . . . . . . . . . . 9 67 4.4. Buffering the In-flight data . . . . . . . . . . . . . . 9 68 4.5. TCP-SMO with Unsupported Destination . . . . . . . . . . 10 69 5. Unsupported Middleboxes . . . . . . . . . . . . . . . . . . . 10 70 6. Impact of NAT between Source and Destination . . . . . . . . 10 71 7. Changes to host TCP Stack and Backward Compatibility . . . . 10 72 8. Relationship with other Identifier Protocols . . . . . . . . 11 73 9. Previous and Related Efforts . . . . . . . . . . . . . . . . 11 74 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 75 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 76 12. Security Considerations . . . . . . . . . . . . . . . . . . . 12 77 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 13.1. Normative References . . . . . . . . . . . . . . . . . . 12 79 13.2. Informative References . . . . . . . . . . . . . . . . . 12 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 82 1. Introduction 84 When a TCP [RFC0793] connection is opened with a peer, it (TCP 85 Session or Socket) is identified by Source port, Destination port, 86 Source IP address and Destination IP address by both initiator and 87 responder of the connection. This connection is identified by the 88 socket parameters and stored in Transmission Control Block (TCB) at 89 TCP stack. Any of these connection identifier changes at one end 90 cause either TCP RST by peer or the session times out eventually. 92 The above is per [RFC0793], Section 2.7- "To identify the separate 93 data streams that a TCP may handle, the TCP provides a port 94 identifier. Since port identifiers are selected independently by 95 each TCP they might not be unique. To provide for unique addresses 96 within each TCP, we concatenate an internet address identifying the 97 TCP with a port identifier to create a socket which will be unique 98 throughout all networks connected together." 100 There are more mobile devices today than a decade earlier. Hence it 101 is imperative that we have a mechanism to provide Session or 102 Transport layer connectivity that is impervious to network layer 103 changes. Some of the Identifier/Location protocols which has 104 inherent support for seamless mobility and relationship to this work 105 is discussed in Section 8. 107 This document provides an option towards providing resilience in the 108 TCP transport layer as either end of the connection moves and changes 109 its location (and thereby its IP address). Some of the previous 110 efforts with TCP mobility have been discussed in Section 9 112 2. Acronyms 114 DH - Diffie-Hellman Key Agreement 116 HIP - Host Identity Protocol 118 LISP - The Locator/ID Separation Protocol 120 TCP - Transmission Control Protocol 122 3. TCP Seamless Mobility Option with Identifiers 124 For seamless mobility with an uninterrupted TCP connection, this 125 document proposes a TCP Seamless Mobility Option (TCP-SMO) as 126 described in Figure 1 . This new TCP option introduces connection 127 identifiers and proposes changes to TCP to use these identifiers for 128 TCB or connection identification. 130 0 1 2 3 131 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 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 | Kind | Length |DH |M|Flags | SL |DL | 134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 135 | Source Connection Identifier (variable length) | 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Destination Connection Identifier (variable Length) | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Optional data | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 Figure 1: TCP Seamless Mobility Option (TCP-SMO) 144 Kind - TBD (TCP IANA). 146 Length - Variable. Includes Kind and Length field in bytes. Minimum 147 value is 12 and a maximum value is 40 bytes. When the Length is less 148 than 12 TCP MUST discard the segment. 150 Flags 152 'D H' - (2 bits) When its non-zero Diffie-Helman value is being 153 exchanged 155 D H Bits in Flags 157 0 0 NO Diffie-Hellman values exchanged 159 0 1 1024-bit ModP Group (mandatory) 161 1 0 2048-bit ModP Group/elliptic curve groups which has 200bits 162 ModP 164 1 1 Reserved 166 Two tiers of identification are needed, with identifiers anchored 167 at the identity. 169 'M' - mobility event, optional data (4 bytes) contains the keyed 170 hash of the Source Connection Identifier concatenated with a fixed 171 12 byte String 0xFEFEFEFEABABABABDEDEDEDE. The fixed string will 172 help normalized the total data for the hash function as connection 173 identifiers length can be as low as 4 bytes. 175 In Case of Security Option-1 - the hash function is a simple 176 SHA1-96 hash of the above concatenated data. Optional 4 byte data 177 is the checksum of this hash data. 179 In Case of Security Option-2 Hash function MUST use AES-128-CMAC-6 180 [NIST-SP800-38B][FIPS197] and Optional 4 byte data is the checksum 181 of this "keyed" hash data. 183 Other flags are reserved and undefined. 185 SL - Source CID Length (4 bits) - Length of the source identifier in 186 bytes. Minimum is 4 bytes and a maximum of 16 bytes. 188 DL - Source CID Length (4 bits) - Length of the destination 189 identifier in bytes. Minimum is 4 bytes and a maximum of 16 bytes. 191 SCID: Source Connection identifier - Length minimum of 4 bytes as 192 indicated by CID length. It can be generated by TCP module or can be 193 supplied by application. 195 DCID: Destination Connection identifier - Length minimum of 4 bytes 196 as indicated by CID length. It can be generated by TCP module or can 197 be supplied by application. 199 Optional data (4 Bytes) - MUST be present only when M bit is set and 200 MUST contain the 4 bytes of Checksum of Generated hash of the Source 201 Connection Identifier + Fixed Data. 203 The Checksum and Hash is generated on the side of communication which 204 detected an IP address change and needs to provide seamless mobility. 206 Source CID (SCID) and Destination CID (DCID) can be provided to TCP 207 by an application or other protocol (LISP, HIP or any other ID 208 related protocol with in the constrains of this option) while opening 209 the TCP socket or TCP stack can generate unique pair of CIDs to be 210 used in this option. 212 4. Elements of Procedure 214 4.1. Flow of TCP Connection with SMO And IP Address Change 216 Consider IP address of Source is IP1 and Destination is IP2. TCP-SMO 217 can be explained with a sequence of TCP segments as specified below: 219 1. Source sends TCP-SYN message with TCP-SMO. In the Seamless 220 Mobility Option: If CID's (source and destination) are chosen by 221 application and given to TCP then both can be present in the TCP-SYN 222 segment. If TCP has to choose the CID's, source chooses the unique 223 (local to the TCP stack) connection Identifier and keeps the 224 destination connection identifier as 0x0 with minimum length 4 bytes 225 in the TCP-SYN segment. When destination receives this segment, it 226 allocates another unique identifier and this value would be kept in 227 the SYN-ACK segment sent to the source. 229 2. Destination receives the SYN segment and it supports this option. 230 It responds back with SYN-ACK with the mobility options. If 231 destination CID is 0x0, as specified above it Chooses a unique CID. 233 From this point TCB is looked-up by Source CID, Destination CID 234 instead of [RFC0793] Section 2.7. 236 3. Source sends Sync-Ack-Ack segment and at source side TCB is 237 established with look up parameters by Source CID, Destination CID, 238 Source Port and Destination port instead of [RFC0793] Section 2.7. 240 4. TCP data segments exchanged from both Source and destination and 241 these segments will have the TCP-SMO. 243 5. In the middle of the connection, a mobility event happened at the 244 source and IP address is changed from IP1 to IP11. When there is 245 data to be sent immediately by source, data segment will be sent with 246 the new Source IP address IP11 and TCB at both ends update the change 247 in the Source IP address. If there is no data segment to be sent by 248 source during mobility event either a TCP keep alive segment or empty 249 data packet needs to be sent with this new IP to allow TCB's at both 250 end to know the new Source IP address. 252 The security implications of continuing to use the same session after 253 an IP address change are discussed in Section 4.2. 255 0 1 2 3 256 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 257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 258 | Kind | Length |DH |1|Flags | SL |DL | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Source Connection Identifier (variable length) | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Destination Connection Identifier (variable Length) | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Checksum of the Generated Hash of SCID + fixed data(4 bytes) | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 Figure 2: TCP Seamless Mobility Option Sent at IP Change Event 269 6. Destination receives TCP-SMO segment. Verifies that IP1 sent the 270 data for change to IP11 thru the Generated Hash, updates its TCB for 271 IP1 connections with Mobility flag set and starts to receive packets 272 on source IP11 TCP segment sent by destination with new Source IP 273 address. If Destination cannot verify then it terminates the 274 session, which is the same as existing behavior. 276 7. Data sent by source but a mobility event happens at destination 277 before this event can be updated to source. In this case the data is 278 lost and would be retransmitted by source when changed IP address is 279 notified by destination. 281 8. Either end can terminate the session by sending the TCP-FIN 282 sequence which also uses TCP-SMO regardless who initiates the socket 283 close. 285 4.2. Security mechanisms during IP address change 287 4.2.1. Security Option-1 289 The TCP-SMO discussed does introduce a security issue as anybody can 290 hijack the existing TCP connection by changing the source IP address 291 (Connection Hijacking). It is recommended to use security at IP 292 (IPsec) or transport layer-Authentication Option (TCP-AO) [RFC5925] 293 for securing the TCP connection including the TCP header. When 294 [RFC5925] is used TCP-SMO size MUST not be exceeded more than 12 295 bytes to accommodate TCP-AO [RFC5925]. 297 Implication on Connection Identifiers: 299 With the TCP AO option for authentication of an IP Address change, 300 the Source and Destination connection Identifiers have to be fixed at 301 4 bytes each for a valid TCP-SMO. 303 4.2.2. Security Option-2 305 In this option, security for TCP-SMO is done in-line with in the 306 newly defined option by exchanging a DH public value and computing a 307 shared secret at both ends, which can be used as a key to generate a 308 hash value (pre-defined has algorithm) during mobility. DH groups 309 and the hash algorithms are pre-defined and MUST be implemented to 310 use this mechanism to avail the needed security. 312 This option relies on the "data" to be sent during 3 way handshake. 313 This data is not application data but the ModP (DH public value) for 314 selected DH group. As the size of this is anywhere from 1024 bits 315 (DH Group-1) to 2048 bits (DH Group-2)/200 bits (Elliptic curve DH 316 groups) sending this as part of option data is not possible (limited 317 option space in the TCP header). 319 Section 3.4 of [RFC0793] specifies and allows a mechanism to send 320 application data during TCP 3 way hand shake but this "data" should 321 not be sent to application until completion of handshake. The data 322 we send is not application data and will be consumed by TCP end host 323 stack until handshake completion. 325 The Sequence of data packet exchange: 327 1. The TCP-SMO DH flags will have non-zero value and particular DH 328 group used by source to generate the ModP value. This is sent as 329 part of the data in the TCP SYN-Segment. 331 2. When destination receives this data and generates the ModP value 332 of the destination and sends back in SYN-ACK segment data portion. 333 At this point destination can compute the DH shared secret (would be 334 used during mobility as a symmetric key for authentication 335 information). 337 3. SYN-ACK-ACK segment is sent and also source computes the DH 338 shared secret. 340 4. TCP data segments exchanged from both side with TCP-SMO. 342 5. Before this message mobility event happens at source and IP1 343 changes to IP11. 345 In this case source sends the data segment with TCP-SMO 'M' bit set 346 with the 4 byte optional data, which is the checksum of the hash 347 computed using the DH shared secret with data being the new IP 348 address. 350 Optional-data = Checksum (Hash((Source Connection Identifier + Fixed 351 data normalizer), DH-Shared-Secret)). 353 Fixed data Normalizer: 0xFEFEFEFEABABABABDEDEDEDE 355 Length of optional data: first 4 bytes of the checksum. 357 Hash algorithm to be used is AES-128-CMAC-96. 359 6. When the above segment arrives with M bit set, destination 360 computes the checksum of the hash for the new IP address received and 361 compares the same with the received value of "optional data" in the 362 TCP-mobility-option. If this matches, it ensures the mobility event 363 is received indeed from Source and IP11 indicated is correct. 365 It sends the TCP data segment to the newly received IP address from 366 Source. This time M bit will be cleared (only used for mobility). 368 4.3. Notifying IP Address Change Event 370 An IP address change in the local stack MUST be notified to the local 371 TCP layer. This is to ensure that the local TCP layer can adjust to 372 IP change and to indicate this change to the destination. There are 373 2 possibilities of change: 375 Delete: If any IP address (connected route) is deleted, TCP should 376 be notified of this change and TCP should find another source IP 377 address for this existing connection only if sockets that are 378 bound to the deleted IP address had their Mobility Flag ON. 380 Modify: If IP address is changes, then both the old and new 381 address should be updated to local TCP to identify the old 382 connection and also to enable TCP to find new source IP for that 383 connection (not necessarily the changed IP, but based on the route 384 lookup on the destination IP). 386 Once the above is done to intimate the destination about this change 387 there are 3 possible option and one of the option has to be fulfilled 388 by local TCP. 390 Pending data from application: in this case TCB should use the new 391 source IP address and send the segment with application data. 393 Sending a keep-alive: If keep-alive are enabled on the TCP 394 connection and asynchronous keep-alive can be sent to the 395 destination with the new IP address. 397 Sending zero-data segment: if the above 2 are not available, local 398 TCP stack can send a zero-data segment to the destination with the 399 new source IP address. 401 In all 3 cases, the packet is sent with the TCP-SMO as in 402 Section 4 step 6. 404 4.4. Buffering the In-flight data 406 During IP address change local host where the change happened can 407 have a handshake mechanism with TCP stack and during that time 408 received data can be buffered. Though this is an implementation 409 detail and it can be done many ways and this is out of scope for this 410 document. 412 4.5. TCP-SMO with Unsupported Destination 414 If a destination does not support the TCP-SMO then it MUST send a 415 regular SYN-ACK as per [RFC0793]. If SYN-ACK is received without any 416 TCP-SMO, source falls back to sending SYN segment without any option. 417 At this point this will be a regular TCP connection and seamless 418 mobility is not possible for this connection. 420 5. Unsupported Middleboxes 422 Any new TCP options are prone to be dropped by middle boxes and this 423 is generally applies to 5% of TCP connections per [RFC7413] section 424 7.1. To cater this case, after the initial time out of the SYN with 425 TCP-SMO, source MUST send SYN segment without this option, thus 426 resorting to native TCBs and hence not having seamless mobility. 428 6. Impact of NAT between Source and Destination 430 This solution does not have any impact of NAT/NAPT devices between 431 source and destination because: 433 o TCB uses only Source and destination connection identifiers 435 o During mobility the authentication data uses stable Source 436 identifier to verify the hash on both sides (does not include new 437 IP address or port). 439 So even in the face NAT/NAPT device with M bit set peer can securely 440 authenticate the change of IP address. 442 7. Changes to host TCP Stack and Backward Compatibility 444 This draft suggests changes to TCP host stack on both ends of the 445 connection. Main aspect of the change includes how TCB (Transmission 446 Control Block) as defined in TCP [RFC0793] Section 2.7 can be looked 447 up and subsequently used. TCB is created when OPEN call is done at 448 the host stack and it is a data structure which holds the state of 449 the connection. During connection OPEN time a flag can be indicated 450 which suggests to use TCP-SMO with additional parameters as required. 452 It is important to note, if the TCP option proposed in this document 453 is not present, TCP connection should continue to identify TCB with 454 connection identifiers as specified in TCP [RFC0793]. So, 455 implementations supporting this option will have both old way of 456 identifying the connection/TCB per [RFC0793] and with connection 457 identifiers in the TCP-SMO. How implementation can be done to have 458 both these methods is beyond the scope of the document, while one 459 could easily perceive my maintaining two separate TCBs or harmonizing 460 the keys to access the existing TCB with the proposal here. 462 When a device or User Equipment (UE) connects to a TCP server, in 463 majority of the cases TCP server will not change its location but to 464 support device or UE mobility server TCP stack also MUST be updated 465 to support this option. One way to mitigate this update at server 466 side is by using a TCP server proxy where this option is implemented. 468 8. Relationship with other Identifier Protocols 470 Proposal made in this document can be seen as a potential Data Plane 471 alternative to existing Location/Identifier based protocols LISP 472 [RFC6830] or HIP [RFC7401] with respective protocols control plane. 473 This option doesn't specify any changes to control plane for existing 474 identifier based protocols. However, existing Location/Identifier 475 based protocols will have some restrictions to use the data plane 476 proposed in this document for example, limitation on the length of 477 Identifier in TCP-SMO, which is variable and a maximum of 16 bytes. 479 The mechanism proposed in this document also can be used with new 480 Identity based common control plane protocol as specified in 481 [I-D.padma-ideas-problem-statement] and this provides a data plane 482 solution for applications using TCP transport. UDP based 483 applications can use mobility solution with QUIC protocol 484 [I-D.tsvwg-quic-protocol], which allows similar functionality with 485 respect to mobility. 487 9. Previous and Related Efforts 489 There were earlier efforts for TCP Mobility and one of those is 490 described in [I-D.eddy-tcp-mobility]. Two of the main differences in 491 this proposal is, how mobility event is notified to the peer (here 492 no-3-way-handshake) and the security mechanisms during that event 493 part from others. 495 Multipath TCP (MPTCP) [RFC6182] [RFC6824] was originally invented to 496 distribute TCP load across multiple TCP connections but later 497 mobility has been introduced by deleting the old connection. The 498 proposal in this draft can be seen as more simpler than the solution 499 proposed with MPTCP. Some of the other aspects, this proposal can be 500 seen as different from MPTCP are in the area of performance 501 [I-D.khalili-mptcp-performance-issues] and the host's ability to have 502 insight into network topology in order to create multiple paths in 503 some cases. 505 10. Acknowledgements 507 TBD. 509 11. IANA Considerations 511 As specified in Section 3, this document requests new value for 512 'kind' assignment from TCP IANA registry. 514 12. Security Considerations 516 Mechanisms to protect IP address change event is covered in 517 Section 4.2. Further security concerns TBD. 519 13. References 521 13.1. Normative References 523 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 524 RFC 793, DOI 10.17487/RFC0793, September 1981, 525 . 527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 528 Requirement Levels", BCP 14, RFC 2119, 529 DOI 10.17487/RFC2119, March 1997, 530 . 532 [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP 533 Authentication Option", RFC 5925, DOI 10.17487/RFC5925, 534 June 2010, . 536 13.2. Informative References 538 [I-D.eddy-tcp-mobility] 539 Eddy, W., "Mobility Support For TCP", draft-eddy-tcp- 540 mobility-00 (work in progress), April 2004. 542 [I-D.khalili-mptcp-performance-issues] 543 Khalili, R., Gast, N., Popovic, M., and J. Boudec, 544 "Performance Issues with MPTCP", draft-khalili-mptcp- 545 performance-issues-06 (work in progress), July 2014. 547 [I-D.padma-ideas-problem-statement] 548 Pillay-Esnault, P., Boucadair, M., Fioccola, G., 549 Jacquenet, C., and A. Nennker, "Problem Statement for 550 Identity Enabled Networks", draft-padma-ideas-problem- 551 statement-03 (work in progress), July 2017. 553 [I-D.tsvwg-quic-protocol] 554 Hamilton, R., Iyengar, J., Swett, I., and A. Wilk, "QUIC: 555 A UDP-Based Secure and Reliable Transport for HTTP/2", 556 draft-tsvwg-quic-protocol-02 (work in progress), January 557 2016. 559 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 560 RFC 2631, DOI 10.17487/RFC2631, June 1999, 561 . 563 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. 564 Iyengar, "Architectural Guidelines for Multipath TCP 565 Development", RFC 6182, DOI 10.17487/RFC6182, March 2011, 566 . 568 [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, 569 "TCP Extensions for Multipath Operation with Multiple 570 Addresses", RFC 6824, DOI 10.17487/RFC6824, January 2013, 571 . 573 [RFC6830] Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, "The 574 Locator/ID Separation Protocol (LISP)", RFC 6830, 575 DOI 10.17487/RFC6830, January 2013, 576 . 578 [RFC7401] Moskowitz, R., Ed., Heer, T., Jokela, P., and T. 579 Henderson, "Host Identity Protocol Version 2 (HIPv2)", 580 RFC 7401, DOI 10.17487/RFC7401, April 2015, 581 . 583 [RFC7413] Cheng, Y., Chu, J., Radhakrishnan, S., and A. Jain, "TCP 584 Fast Open", RFC 7413, DOI 10.17487/RFC7413, December 2014, 585 . 587 Authors' Addresses 589 Burjiz Pithawala 590 Huawei Technologies 591 2330 Central Expressway 592 Santa Clara, CA 95050 593 USA 595 Email: burjiz.pithawala1@huawei.com 596 Uma Chunduri (editor) 597 Huawei Technologies 598 2330 Central Expressway 599 Santa Clara, CA 95050 600 USA 602 Email: uma.chunduri@huawei.com