QUIC M. Piraux Internet-Draft O. Bonaventure Intended status: Experimental UCLouvain Expires: 17 April 2023 14 October 2022 Additional addresses for QUIC draft-piraux-quic-additional-addresses-00 Abstract 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 This note is to be removed before publishing as an RFC. The latest revision of this draft can be found at https://mpiraux.github.io/draft-piraux-quic-additional-addresses/ draft-piraux-quic-additional-addresses.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft- piraux-quic-additional-addresses/. Discussion of this document takes place on the QUIC Working Group mailing list (mailto:quic@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/quic/. Subscribe at https://www.ietf.org/mailman/listinfo/quic/. Source for this draft and an issue tracker can be found at https://github.com/mpiraux/draft-piraux-quic-additional-addresses. 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." Piraux & Bonaventure Expires 17 April 2023 [Page 1] Internet-Draft Additional addresses for QUIC October 2022 This Internet-Draft will expire on 17 April 2023. Copyright Notice Copyright (c) 2022 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 to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1. Example of use . . . . . . . . . . . . . . . . . . . . . 3 4. Additional Addresses Transport Parameter . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . 6 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7 1. 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. Piraux & Bonaventure Expires 17 April 2023 [Page 2] Internet-Draft Additional addresses for QUIC October 2022 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 [RFC8678], 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. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. 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 [MULTIPATH-QUIC] 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 Section 8.2 of [QUIC-TRANSPORT]. 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. 3.1. Example of use Figure 1 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. Piraux & Bonaventure Expires 17 April 2023 [Page 3] Internet-Draft Additional addresses for QUIC October 2022 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. Client Load-balancer Server @ IP a Server @ IP b | | | | | Initial[0]: CRYPTO(CH) | | |---------------------/F/-------------------->| | .... | 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 Figure 1: A server reached through a LB uses Add. Address 4. 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 { Additional Address (..) ..., } Figure 2: Additional Addresses Format Piraux & Bonaventure Expires 17 April 2023 [Page 4] Internet-Draft Additional addresses for QUIC October 2022 Additional Address { Address Version (8), IP Address (..), IP Port (16), } Figure 3: 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. 5. 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 Section 21.5.3 of [QUIC-TRANSPORT] 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 Section 21.5.6 of [QUIC-TRANSPORT] also remain applicable for further mitigation. 6. 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 Table 1 should be added to the "QUIC Transport Parameters" registry under the "QUIC Protocol" heading. Piraux & Bonaventure Expires 17 April 2023 [Page 5] Internet-Draft Additional addresses for QUIC October 2022 +==============================+====================+===============+ | Value | Parameter Name. | Specification | +==============================+====================+===============+ | TBD (experiments | addition_addresses | Section 4 | | use 0xadda) | | | +------------------------------+--------------------+---------------+ Table 1: Addition to QUIC Transport Parameters Entries 7. References 7.1. Normative References [QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, . [QUIC-TRANSPORT] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 7.2. Informative References [MULTIPATH-QUIC] Liu, Y., Ma, Y., De Coninck, Q., Bonaventure, O., Huitema, C., and M. Kühlewind, "Multipath Extension for QUIC", Work in Progress, Internet-Draft, draft-ietf-quic-multipath-02, 11 July 2022, . [RFC8678] Baker, F., Bowers, C., and J. Linkova, "Enterprise Multihoming using Provider-Assigned IPv6 Addresses without Network Prefix Translation: Requirements and Solutions", RFC 8678, DOI 10.17487/RFC8678, December 2019, . Piraux & Bonaventure Expires 17 April 2023 [Page 6] Internet-Draft Additional addresses for QUIC October 2022 Acknowledgments We thank Quentin De Coninck and Francois Michel for their feedback and comments on the first version of this document. Authors' Addresses Maxime Piraux UCLouvain Email: maxime.piraux@uclouvain.be Olivier Bonaventure UCLouvain Email: olivier.bonaventure@uclouvain.be Piraux & Bonaventure Expires 17 April 2023 [Page 7]