]> UCLouvain & WEL RI

maxime.piraux@uclouvain.be

UCLouvain & WEL RI

olivier.bonaventure@uclouvain.be

Transport QUIC quic address This document specifies a QUIC frame 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 frame and 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 frame proposed in this document enables a QUIC server to securely advertise additional addresses. The Additional Addresses transport parameter enables a QUIC client to indicate support for this frame. 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 client indicates support for this extension by using the dedicated transport parameter. 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 using the dedicated frame. 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 load-balancer uses Add. Addresses |--------------------->| | .... | Handshake[0]: CRYPTO(EE(Pr.Addr=a),..) | | |<---------------------|<---------------------| | | 1-RTT[0]: ADDITIONAL_ADDRESSES([b]) | | |<---------------------|<---------------------| | .... | Handshake[0]: CRYPTO(Fin) | | |--------------------->|--------------------->| | | /* Migration to Preferred Address a */ | | |-------------------------------------------->| | .... | | | | | . | | 1-RTT[X]: PATH_CHALLENGE /* Migration to Add. Address b */ | |------------------------------------------------------------>| | 1-RTT[Y]: PATH_RESPONSE | |<------------------------------------------------------------| | | ]]>

Additional Addresses Transport Parameter The following transport parameter is defined:

additional_addresses (TBD - experiments use 0x925addaXX):

Indicates the support of the ADDITIONAL_ADDRESSES frame as defined in the -XX draft version of this document. This transport parameter has a zero-length value. It MUST NOT be sent by a server.

ADDITIONAL_ADDRESSES Frames The server uses an ADDITIONAL_ADDRESSES frame (type=TBD - experiments use 0x925addaXX) to advertise the additional addresses that a client can use to reach it. This frame MUST NOT be sent by a client and can only appear in 1-RTT packets.

ADDITIONAL_ADDRESSES Frame Format

Sequence Number:

A variable-length integer indicating the sequence of the frame. The number is monotonically increasing within a QUIC connection and is chosen by the sender. It helps the receiver to order ADDITIONAL_ADDRESSES frames by recency. A receiver SHOULD ignore frames with a Sequence Number lower or equal to the highest Sequence Number received.

Additional Addresses Count:

A variable-length integer indicating the number of additional addresses in the frame.

Additional Address Format

Address Version:

An 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.

The ADDITIONAL_ADDRESSES frame is ack-eliciting. When a packet containing an ADDITIONAL_ADDRESSES frame is lost and its content is still relevant, the sender MAY retransmit the frame as is. Otherwise, sending a new frame with a new Sequence number is preferred. The server can update the client on its additional addresses at any time by sending an ADDITIONAL_ADDRESSES frame. When a client is using one of these additional addresses and receives an ADDITIONAL_ADDRESSES frame not containing this address, it SHOULD stop using it in favor of another 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. Given that a server can provide additional addresses at any point in time, a malicious server could overload a client and direct it against many addresses. To alleviate this, a client can choose to limit the number of addresses it keeps track of and the frequency at which it considers them. 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 indicating support for additional addresses. The draft defines provisional identifiers for experiments. IANA will allocate the final identifiers. The following entry in should be added to the "QUIC Transport Parameters" registry under the "QUIC" heading. Addition to QUIC Transport Parameters Entries

Value	Parameter Name.	Specification
TBD (experiments use 0x925addaXX)	additional_addresses

The last byte of the experimental transport parameter ID is used by implementations to indicate the version of this document they support. For instance, the value 0x925adda01 indicates the support of the -01 version of this document. The following entry in should be added to the "QUIC Frame Types" registry under the "QUIC" heading. Addition to QUIC Frame Types Entries

Value	Frame Type Name	Specification
TBD (experiments use 0x925addaXX)	ADDITIONAL_ADDRESSES

The last byte of the experimental frame type is used by implementations to indicate the version of this document they support. For instance, the value 0x925adda01 indicates the support of the -01 version of this document.

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. 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. Uber Technologies Inc. University of Mons (UMONS) UCLouvain and Tessares 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 François Michel for their feedback and comments on the first version of this document. We thank Marcel Kempf, Moritz Buhl, Louis Navarre and François Michel for joining the interop during the IETF 118 Hackathon.