QUIC WG L. Tan Internet-Draft Beijing Jiaotong University Intended status: Informational X. Gao Expires: April 18, 2021 China Unicom W. Su Beijing Jiaotong University N. Li CNCERT/SD W. Zhang Shandong Computing Science Center October 15, 2020 Connection Migration in QUIC draft-tan-quic-connection-migration-00 Abstract This document explores and classifies QUIC connection migration, and suggests possible improvements. 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 April 18, 2021. Copyright Notice Copyright (c) 2020 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 (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 Tan, et al. Expires April 18, 2021 [Page 1] Internet-Draft QUIC Connection Migration October 2020 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 2.1. Terms Used In This Document . . . . . . . . . . . . . . . 3 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 3 3. Connection Migration . . . . . . . . . . . . . . . . . . . . 4 3.1. Initiating Connection Migration . . . . . . . . . . . . . 5 3.2. Path Verification . . . . . . . . . . . . . . . . . . . . 5 3.3. Completing Connection Migration . . . . . . . . . . . . . 6 3.4. Special Cases . . . . . . . . . . . . . . . . . . . . . . 7 4. Classification of Connection Migration . . . . . . . . . . . 7 4.1. Active Connection Migration and Passive Connection Migration . . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Vertical Connection Migration and Horizontal Connection Migration . . . . . . . . . . . . . . . . . . . . . . . . 8 4.3. Client Connection Migration and Server Connection Migration . . . . . . . . . . . . . . . . . . . . . . . . 8 4.4. Single-path Connection Migration and Multi-path Connection Migration . . . . . . . . . . . . . . . . . . 8 5. Connection Migration Strategy . . . . . . . . . . . . . . . . 9 5.1. Failover Mode . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Standby Mode . . . . . . . . . . . . . . . . . . . . . . 9 5.3. Aggregation Mode . . . . . . . . . . . . . . . . . . . . 9 5.4. Load Balance Mode . . . . . . . . . . . . . . . . . . . . 9 6. Trigger Condition for Connection Migration . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 10. Normative references . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction This document explores and classifies QUIC connection migration in detail. 2. Terminology Tan, et al. Expires April 18, 2021 [Page 2] Internet-Draft QUIC Connection Migration October 2020 2.1. Terms Used In This Document This document uses the terminology and concepts established in [QUIC-TRANSPORT]. It is assumed that the reader is familiar with the above document and the terms defines there. The following terms used in this document: Endpoint An entity that can participate in a QUIC connection by generating, receiving, and processing QUIC packets. There are only two types of endpoint in QUIC: client and server. QUIC Client The endpoint that initiates a QUIC connection. QUIC Server The endpoint that accepts a QUIC connection. Connection ID An identifier that is used to identify a QUIC connection at an endpoint. Each endpoint selects one or more Connection IDs for its peer to include in packets sent towards the endpoint. This value is opaque to the peer. Connection migration The QUIC endpoint uses the connection ID to make connections to survive changes to endpoint addresses. Connection migration initiator The endpoint that initiated the connection migration. Connection migration responder The peer communicating with the connection migration initiator. Path validation Endpoints test reachability between a specific local address and a specific peer address. Probing frame A Frame with probing function, such as PATH_CHALLENGE, PATH_RESPONSE, NEW_CONNECTION_ID, and PADDING frame. Non-probing frame A frame except the probing frame. Probing packet A packet containing only probing frame. Non-probing packet A packet containing any other non-probing frame. Application An entity that uses QUIC to send and receive data. 2.2. Abbreviations The following abbreviations used in this document: CM Connection Migration. ACM Active Connection Migration. PCM Passive Connection Migration. VCM Vertical Connection Migration. HCM Horizontal Connection Migration. CCM Client Connection Migration. SCM Server Connection Migration. SPCM Single-path Connection Migration. MPCM Multi-path Connection Migration. Tan, et al. Expires April 18, 2021 [Page 3] Internet-Draft QUIC Connection Migration October 2020 3. Connection Migration QUIC connections are not strictly bound to a single network path. Connection migration is one of the important features of QUIC. The QUIC endpoint that initiates the connection migration is called the connection migration initiator (CM Initiator). The peer is the connection migration responder (CM Responder). Connection migration uses connection ID to allow connections to transfer to a new network path. The use of a connection ID allows connections to survive changes to endpoint addresses (IP address and port), such as those caused by an endpoint migrating to a new network, as shown in Figure Figure 1. The connection ID MUST be non-zero. Tan, et al. Expires April 18, 2021 [Page 4] Internet-Draft QUIC Connection Migration October 2020 (Before connection migration) +--------------+ Non-probing Packet +--------------+ | CM Initiator | -------------------> | | |(Source IP: 1)| <------------------- | | +--------------+ Non-probing Packet | | | | | | | | | | | v Probing Packet | | +--------------+ (PATH_CHALLENGE) | | | | -------------------> | | | | <------------------- | | | | Probing Packet | | | | (PATH_RESPONSE) | | | | | CM Responder | | | Probing Packet | | | | (PATH_CHALLENGE) | | | CM Initiator | <------------------- | | |(Source IP: 2)| -------------------> | | | | Probing Packet | | | | (PATH_RESPONSE) | | | | | | | | Non-probing Packet | | | | -------------------> | | | | <------------------- | | | | Non-probing Packet | | +--------------+ +--------------+ (After connection migration) Figure 1: The connection migration 3.1. Initiating Connection Migration An CM Initiator can migrate a connection to a new local address by sending packets containing non-probing frames from that address. 3.2. Path Verification The endpoint sends a PATH_CHALLENGE frame containing a random number to initialize path verification. Each endpoint validates its peer's address during connection establishment. Therefore, a migrating endpoint can send to its peer knowing that the peer is willing to receive at the peer's current address. Path verification MUST be performed for most connection migrations, unless the endpoints have verified the path, the reason is to verify the reachability and security of the path. But in some special Tan, et al. Expires April 18, 2021 [Page 5] Internet-Draft QUIC Connection Migration October 2020 cases, the connection migration initiator should be allowed to send data packets directly without path confirmation from the peer. The condition is to ensure that the packet received by connection migration responder does not carry a spoofed source address. Endpoints can use PATH_CHALLENGE frames (type=0x1a) to check reachability to the peer and for path validation during connection migration. PATH_CHALLENGE frames are formatted as shown in Figure Figure 2. A PATH_RESPONSE frame (type=0x1b) is sent in response to a PATH_CHALLENGE frame. PATH_RESPONSE frames are formatted as shown in Figure Figure 3. +-+-+-+-+-+-+-+-+ | 0x1a | +-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data (64) | +-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: PATH_CHALLENGE Frame Format +-+-+-+-+-+-+-+-+ | 0x1b | +-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data (64) | +-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3: PATH_RESPONSE Frame Format 3.3. Completing Connection Migration The endpoint receives a packet containing the new peer address of the non-probing frame from the peer, indicating that the connection migration initiator has migrated to this address. After the connection is migrated, the endpoints need to reset the congestion control parameters. Tan, et al. Expires April 18, 2021 [Page 6] Internet-Draft QUIC Connection Migration October 2020 3.4. Special Cases Some situations that do not allow connection migration: 1. An endpoint MUST NOT initiate connection migration before the handshake is confirmed, as defined in section 4.1.2 of [QUIC-TLS]. 2. An endpoint MUST NOT initiate connection migration if the peer sent the disable_active_migration transport parameter. The section 9.1 of [QUIC-TRANSPORT] analyzes several potential security problems and solutions in the process of connection migration. 4. Classification of Connection Migration According to business scenarios, connection migration can be divided into multiple types, which involve different implementation technologies. 4.1. Active Connection Migration and Passive Connection Migration According to different initiators, connection migration can be divided into Active Connection Migration (ACM) and Passive Connection Migration (PCM). From the perspective of the network model, ACM can be regarded as connection migration initiated by the application layer, and PCM can be regarded as connection migration initiated by the IP layer or lower layers. ACM requires the IP layer to present all available network connections to QUIC. The application layer or QUIC designs an effective connection migration strategy according to the measurement results of different network connections to achieve better user experience, security and economy. Available migration strategies include threshold-driven migration, polling migration, random migration, etc. The purpose of PCM is to maintain the connection between the QUIC client and the QUIC server in a mobile or weak network environment. QUIC is often forced to adapt to PCM. In addition, NAT/NAPT will also cause QUIC endpoints to perform forced connection migration. Tan, et al. Expires April 18, 2021 [Page 7] Internet-Draft QUIC Connection Migration October 2020 4.2. Vertical Connection Migration and Horizontal Connection Migration Due to the movement of QUIC terminals or access networks, QUIC needs to support connection migration in a multi-network access environment. Therefore, connection migration in this situation can be divided into Vertical Connection Migration (VCM) and Horizontal Connection Migration (HCM). VCM occurs between heterogeneous networks and HCM occurs in homogeneous networks. Due to temporal and spatial changes, VCM and HCM MAY occur alternately or simultaneously. Since the HCM occurs under a homogeneous network, the network before migration MAY have some similarities with the network after migration. This guides QUIC to better maintain connections by drawing on historical information. 4.3. Client Connection Migration and Server Connection Migration In most cases, the QUIC server is stationary. QUIC connection migration occurs on the QUIC client side. However, in scenarios such as P2P networks, mobile servers, and data center four-layer load balancing, both endpoints of QUIC communication MAY undergo connection migration. According to the location, connection migration is divided into Client Connection Migration (CCM) and Server Connection Migration (SCM). The section 9 of [QUIC-TRANSPORT] stipulates that only QUIC clients can actively initiate connection migration. The client MUST discard packets from unknown servers. The section 9.6 of [QUIC-TRANSPORT] describes the scene when clients initially connect to an address shared by multiple servers but would prefer to use a unicast address to ensure connection stability. So we believe that the client and server should be equal, and SCM is necessary. 4.4. Single-path Connection Migration and Multi-path Connection Migration According to the number of connection paths maintained between the client and the server during connection migration, connection migration can be divided into single-path connection migration (SPCM) and multi-path connection migration (MPCM). SPCM is a simple and common form of connection migration. However, in the future, with the continuous development of heterogeneous converged networks, it is also possible for endpoints to perform connection migration while maintaining multi-path transmission. It is worth noting that there is a difference between MPCM and MPQUIC Tan, et al. Expires April 18, 2021 [Page 8] Internet-Draft QUIC Connection Migration October 2020 [QUIC-MPQUIC]. MPCM is an event that MAY occur during MPQUIC transmission. Therefore, MPCM has more decision variables than SPCM. 5. Connection Migration Strategy In addition to the connection migration classification in Section 4, QUIC can also consider connection migration from strategy. 5.1. Failover Mode In failover mode, the networking stack monitors the quality of the connection or link, when they are not operating normally, the QUIC connection is migrated to an alternative path. QUIC doesn't require any packets to be exchanged before migrating to a new path, so this migration is seamless. However, if the new path hasn't been validated, there's less confidence that it will work. In this mode, the QUIC connection MAY be temporarily interrupted. 5.2. Standby Mode In standby mode, the networking stack establishes and validates an alternative path shortly after establishing a connection on the main path. When the link or the connection deteriorate, QUIC can switch to the alternative path. This means that there are two or more logical paths between the QUIC client and the QUIC server. In this mode, QUIC always uses only one of these paths for communication at any time. 5.3. Aggregation Mode In the aggregation mode, the QUIC client (or QUIC server) can use MPQUIC [QUIC-MPQUIC] technology to achieve greater network throughput. This means that multiple source IPs will share the same connection ID. 5.4. Load Balance Mode The section 9.6 of [QUIC-TRANSPORT] detailed load balancing mode. Servers MAY communicate a preferred address of two or more addresses to allow clients to pick the one most suited to their network attachment. The client SHOULD select one of the two or more addresses provided by the server and initiate path validation. As soon as path validation succeeds, the client SHOULD begin sending all future packets to the new server address using the new connection ID and discontinue use of the old server address. Tan, et al. Expires April 18, 2021 [Page 9] Internet-Draft QUIC Connection Migration October 2020 6. Trigger Condition for Connection Migration Except for PCM, other connection migrations can be triggered by RTT, packet loss rate, timeout, ECN or application signals. 7. Security Considerations TBD. 8. IANA Considerations TBD. 9. Acknowledgements None. 10. Normative references [QUIC-MPQUIC] Coninck, Q. and O. Bonaventure, "Multipath Extensions for QUIC (MP-QUIC)", August 2020, . [QUIC-TLS] Thomson, M. and S. Turner, "Using TLS to Secure QUIC", September 2020, . [QUIC-TRANSPORT] Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed and Secure Transport", September 2020, . Authors' Addresses Lizhuang Tan Beijing Jiaotong University Shangyuan Cun. 3. Haidian, Beijing 100044 China Email: lzhtan@bjtu.edu.cn Tan, et al. Expires April 18, 2021 [Page 10] Internet-Draft QUIC Connection Migration October 2020 Xiaochuan Gao China Unicom Zhonghe Street. 1. Daxing, Beijing 100176 China Email: gaoxc50@chinaunicom.cn Wei Su Beijing Jiaotong University Shangyuan Cun. 3. Haidian, Beijing 100044 China Email: wsu@bjtu.edu.cn Na Li CNCERT/SD Jingshiyi Road. 40. Shizhong, Jinan 250002 China Email: lina@cert.org.cn Wei Zhang Shandong Computing Science Center Keyuan Road. 19. Lixia, Jinan 250014 China Email: wzhang@qlu.edu.cn Tan, et al. Expires April 18, 2021 [Page 11]