]> UCLouvain

maxime.piraux@uclouvain.be

UCLouvain

olivier.bonaventure@uclouvain.be

Transport QUIC quic address This document specifies a QUIC Transport Parameter enabling a QUIC server to advertise additional addresses that can be used for a QUIC connection. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the QUIC Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The QUIC protocol specifies several techniques for network path migration. The client can migrate from one of its local addresses to another at any time after the handshake using connection migration. The server can transfer a connection to one of its other addresses shortly after the handshake by using the preferred_address transport parameter. However, it cannot advertise additional addresses that a client may use. This limitation impacts several scenarios. For instance, a multihomed server that has access to several subnets cannot advertise all its addresses. In entreprise deployments where provider-assigned IPv6 Addresses are used to solve the multihoming problem , announcing several server addresses enables applications using QUIC to recover from provider failures. Also, a dual-stack server cannot advertise its other address so that a client losing the address family used to establish the connection can migrate to the other address family. This document proposes a QUIC Transport Parameter enabling a QUIC server to advertise additional addresses that can be used for a QUIC connection.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Overview The additional_addresses transport parameter proposed in this document enables a QUIC server to securely advertise additional addresses. These addresses can be used by the client to migrate to a new server address at any time after the handshake. When is used over a QUIC connection, the client can use these addresses to establish additional network paths. When sending packets to a new server address, the client validates the address using Path Validation as described in . When Preferred Adress and Additional Addresses are used together, the client SHOULD NOT migrate to an additional address before acting on the preferred address indicated by the server.

Example of use illustrates an example of use for Additional Addresses in a QUIC deployment featuring a load balancer and a multihomed server making use of the Preferred Address mechanism. First, the client sends its Initial packet to the load balancer, which forwards it to the first server IP. The server answers to the QUIC connection opening and indicates its first IP as a preferred address and its second one as an additional address. When the handshake completes, the client validates the preferred address and migrates to it. Later during the connection, the client can validate the path towards the second server IP and can migrate to it.

A server reached through a LB uses Add. Address | | .... | Handshake[0]: CRYPTO(EE(Pr.Addr=a,A.Addr=b)]| | |<--------------------/F/---------------------| | .... | Handshake[0]: CRYPTO(Fin) | | |---------------------/F/-------------------->| | | /* Migration to Preferred Address a */ | | |-------------------------------------------->| | .... | | | | | . | | 1-RTT[1]: PATH_CHALLENGE /* Migration to Add. Address b */ | |------------------------------------------------------------>| | 1-RTT[1]: PATH_RESPONSE | |<------------------------------------------------------------| | | Legend /F/ Forwarded by LB ]]>

Additional Addresses Transport Parameter The following transport parameter is defined:

additional_addresses (TBD - experiments use 0xadda):

A list of server addresses that the client can migrate the connection to. This transport parameter MUST NOT be sent by a client.

Additional Addresses Format

Additional Address Format

Address Version:

A 8-bit value identifying the Internet address version of this address. The value 4 indicates IPv4 while 6 indicates IPv6.

IP Address:

The address value. Its size depends on its version. IPv4 addresses are 32-bit long while IPv6 addresses are 128-bit long.

IP Port:

A 16-bit value representing the port to use with this IP Address.

Security Considerations This document specifies a mechanism allowing servers to influence the IP addresses towards which clients send QUIC packets. In this case, a malicious server could cause a client to send packets to a victim. A countermeasure similar to is to limit the packets that are sent to a non-validated additional addresses. A client MUST NOT send non-probing frames to an additional address prior to validating that address. The generic measures described in also remain applicable for further mitigation.

IANA Considerations This document defines a new transport parameter for advertising additional addresses. The draft defines a provisional identifier for experiments. IANA will allocate the final identifier. The following entry in should be added to the "QUIC Transport Parameters" registry under the "QUIC Protocol" heading. Addition to QUIC Transport Parameters Entries

Value	Parameter Name.	Specification
TBD (experiments use 0xadda)	addition_addresses

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm. This document describes how Transport Layer Security (TLS) is used to secure QUIC. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References Alibaba Inc. Alibaba Inc. UCLouvain UCLouvain Private Octopus Inc. Ericsson This document specifies a multipath extension for the QUIC protocol to enable the simultaneous usage of multiple paths for a single connection. Discussion Venues This note is to be removed before publishing as an RFC. Discussion of this document takes place on the QUIC Working Group mailing list (quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/quic/. Source for this draft and an issue tracker can be found at https://github.com/mirjak/draft-lmbdhk-quic-multipath. Connecting an enterprise site to multiple ISPs over IPv6 using provider-assigned addresses is difficult without the use of some form of Network Address Translation (NAT). Much has been written on this topic over the last 10 to 15 years, but it still remains a problem without a clearly defined or widely implemented solution. Any multihoming solution without NAT requires hosts at the site to have addresses from each ISP and to select the egress ISP by selecting a source address for outgoing packets. It also requires routers at the site to take into account those source addresses when forwarding packets out towards the ISPs. This document examines currently available mechanisms for providing a solution to this problem for a broad range of enterprise topologies. It covers the behavior of routers to forward traffic by taking into account source address, and it covers the behavior of hosts to select appropriate default source addresses. It also covers any possible role that routers might play in providing information to hosts to help them select appropriate source addresses. In the process of exploring potential solutions, this document also makes explicit requirements for how the solution would be expected to behave from the perspective of an enterprise site network administrator.

Acknowledgments We thank Quentin De Coninck and Francois Michel for their feedback and comments on the first version of this document.