Explicit QUIC Path-ID extension
draft-huitema-quic-mpath-explicit-00

Network Working Group                                         C. Huitema
Internet-Draft                                      Private Octopus Inc.
Intended status: Standards Track                         9 November 2023
Expires: 12 May 2024

                    Explicit QUIC Path-ID extension
                  draft-huitema-quic-mpath-explicit-00

Abstract

   The work on QUIC multipath has almost converged, but we are still
   debating how to identify paths.  The draft multipath version 06
   identifies paths explicitly using the sequence number of the
   Connection Identifier used for sending packets on the path.  The WG
   is considering an alternate proposal in which the path ID is
   explicit.  In order to compare the two solutions, we propose here an
   extension to the multipath draft allowing endpoints to negotiate the
   use of explicit sequence numbers.  When the extension is negotiated,
   endpoints announce new connection identifiers using a new
   MP_CONNECTION_ID frame, which carries the parameters of the
   NEW_CONNECTION_ID plus a path ID.  This path ID is used instead of
   the CID sequence number to identify packet number spaces, to create
   encryption nonces, to identify paths in MP_ACK, MP_ABANDON,
   MP_AVAILABLE and MP_STANBY frames, and to perform the logic
   associated with path creation, path CID rotation, and NAT rebinding.
   The draft analyzes the pros and cons of using this extension.  After
   experimentation and analysis, we expect that this extension will be
   either absorbed into a new version of the QUIc multipath draft, or
   abandoned.

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 12 May 2024.

Huitema                    Expires 12 May 2024                  [Page 1]
Internet-Draft              Explicit Path-ID               November 2023

Copyright Notice

   Copyright (c) 2023 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
     1.1.  Conventions and Definitions . . . . . . . . . . . . . . .   3
   2.  The Explicit Path ID extension  . . . . . . . . . . . . . . .   3
     2.1.  Negotiation of Explicit Path ID . . . . . . . . . . . . .   3
     2.2.  Path identifiers  . . . . . . . . . . . . . . . . . . . .   3
     2.3.  MP_CONNECTION_ID frame  . . . . . . . . . . . . . . . . .   4
     2.4.  Management of Connection IDs and Path-ID  . . . . . . . .   5
     2.5.  Effect of RETIRE_CONNECTION_ID and MP_PATH_ABANDON
           frame . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.6.  Path Management . . . . . . . . . . . . . . . . . . . . .   5
   3.  Implementation Considerations . . . . . . . . . . . . . . . .   5
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   6.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Introduction

   A couple months ago, Marten Seeman proposed to revisit the use of
   Connection ID (CID) sequence numbers, see [Explicit-ID].  Marten's
   argument was that using explicit path identifiers would simplify path
   management, path initiation and loss recovery.  The reaction to that
   proposal was mixed.  On one hand, the solution proposed in draft-06
   of [QUIC-MP] is already implemented in multiple interoperable
   implementations, and covers the required QUIC Multipath scenarios.
   On the other hand, the usage of CID sequence numbers as identifiers
   of packet number spaces interferes with loss recovery after CID
   rotation.  This can be alleviated by special code linking old and new
   number spaces, but there is still a hard to cover special case when

Huitema                    Expires 12 May 2024                  [Page 2]
Internet-Draft              Explicit Path-ID               November 2023

   CID rotation and NAT rebinding happen simultaneously.  In addition,
   having explicit path identifiers would allow endpoints to control the
   number of paths independently of the number of connection
   identifiers.

   This document proposes a QUIC extension that would allow testing and
   evaluation of the explicit path identifier proposal.

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

2.  The Explicit Path ID extension

2.1.  Negotiation of Explicit Path ID

   The path management extension is negotiated by means of the
   "enable_explicit_path_id" transport parameter:

   *  "enable_explicit_path_id" (current version uses 0xced74c7a, the
      first 32 bits of the MD5 hash of the string "Marten might be right
      after all").  This parameter has a zero-length value.

   If any of the endpoints does not advertise the
   enable_explicit_path_id transport parameter, then the endpoints MUST
   NOT use any frame or mechanism defined in this document.

   The enable_explicit_path_id parameter MUST NOT be presented if the
   enable_multipath parameter defined in [QUIC-MP] is not also
   negotiated.

2.2.  Path identifiers

   The Explicit QUIC Path-ID extension defines a "Path ID" as an integer
   between 0 and 2^62 - 1.  The Path-ID is used instead of the
   destination Connection ID sequence number in all places where the
   destination Connection ID sequence number identifies a path in
   [QUIC-MP].  The changes from [QUIC-MP] are:

   *  Each CID is associated with a Path-ID, as documented in {#mp-
      connection-id-frame}. Multiple connection identifiers can be
      associated with the same path-id.

Huitema                    Expires 12 May 2024                  [Page 3]
Internet-Draft              Explicit Path-ID               November 2023

   *  Each endpoint associates a Receiver Packet Number space to each
      Path ID that it provides to the peer.

   *  Each endpoint associates a Sender Packet Number space to each
      Path-ID received from the peer.

   *  The path ID associated with the Destination Connection ID is used
      to construct the packet protection nonce defined in Section 5.2 of
      [QUIC-MP]

   *  The path ID associated with the Destination Connection ID is used
      to identify the path in ACK_MP frames.

   *  The path ID associated with the Destination Connection ID used by
      the peer is used to identify the path in the PATH_ABANDON,
      PATH_STANDBY and PATH_AVAILABLE frames.

   The initial connection ID issued by an endpoint is sent in the Source
   Connection ID field of the long packet header (see Section 17.2 of
   [QUIC-TRANSPORT]) during the handshake.  The path ID of the initial
   connection ID is 0.  If the preferred_address transport parameter is
   sent (see Section 9.6 of [QUIC-TRANSPORT], the path ID of the
   supplied connection ID is 1.

2.3.  MP_CONNECTION_ID frame

   When the enable_explicit_path_id option is negotiated, endpoints use
   the MP_CONNECTION_ID frame in lieu of the NEW_CONNECTION_ID frame
   defined in [QUIC-TRANSPORT].

   MP_CONNECTION_ID frames are formatted as shown in Figure 1.

   MP_CONNECTION_ID Frame {
     Type (i) = TBD (current version uses 0x15228c09),
     Sequence Number (i),
     Retire Prior To (i),
     Path Id (i),
     Length (8),
     Connection ID (8..160),
     Stateless Reset Token (128),
   }

                  Figure 1: MP_CONNECTION_ID Frame Format

   The Path Id component is as defined in Section 2.2.  The other
   compenents are as defined for the components of the NEW_CONNECTION_ID
   frame in Section 19.15 of [QUIC-TRANSPORT].

Huitema                    Expires 12 May 2024                  [Page 4]
Internet-Draft              Explicit Path-ID               November 2023

2.4.  Management of Connection IDs and Path-ID

   Connection identifiers are managed as specified in [QUIC-TRANSPORT].
   The endpoints announce the number of Connection ID that they are
   willing to store using the active_connection_id_limit parameter
   defined in Section 18.2 of [QUIC-TRANSPORT].  Endpoints use the
   RETIRE_CONNECTION_ID frame to signal that they won't use a Connection
   ID any more.  They use the Retire Prior To parameter of
   MP_CONNECTION_ID Frames to induce the peer to retire obsolete
   Connection identifiers.

2.5.  Effect of RETIRE_CONNECTION_ID and MP_PATH_ABANDON frame

   Receiving a RETIRE_CONNECTION_ID frame DOES NOT cause an endpoint to
   discard the resources associated with the Path-ID associated with the
   Connection Identifier.  These resources are only discarded after an
   explicit PATH_ABANDON, or at the end of the connection.

2.6.  Path Management

   Path management generally follows the specifications of Section 4 of
   [QUIC-MP], but with a series of modifications:

   *  To open a new path, the client SHALL use different Connection IDs
      on different paths, selecting for each path Connection IDs for
      which the path ID is not yet in use.

   *  When responding on a path, the server SHOULD use a connection ID
      for which the path ID is not yet in use.  There is no requirement
      that the server and the client use matching path-ID.

   The endpoints retain the sending IP addresses and UDP ports
   associated with the path (4 tuple), as well as the sending and
   receiving connection IDs used.

   *  if the 4 tuple are different but the path-ID is the same, the
      packet arrival is treated as a NAT rebinding for the specified
      path.

   *  if CID are different but path-ID are the same, the packet arrival
      is treated as a CID renewal for the specified path.

3.  Implementation Considerations

   Retiring path-id?  Does Abandon(path-ID) removes all the connection
   ID with that path?

Huitema                    Expires 12 May 2024                  [Page 5]
Internet-Draft              Explicit Path-ID               November 2023

   If "Abandon Path", how can the endpoint ensure that there are no
   future references to the same path?

   Maintaining the packet sequence number across multiple CID --
   especially if multiple interfaces.

4.  Security Considerations

   TODO. resource explosion?

5.  IANA Considerations

   This document registers a new value in the QUIC Transport Parameter
   Registry:

      +==================+=========================+===============+
      | Value            | Parameter Name.         | Specification |
      +==================+=========================+===============+
      | TBD (experiments | enable_explicit_path_id | Section 2.1   |
      | use 0x29e3d19e)  |                         |               |
      +------------------+-------------------------+---------------+

          Table 1: Addition to QUIC Transport Parameters Entries

6.  Acknowledgements

7.  References

7.1.  Normative References

   [QUIC-MP]  Liu, Y., Ed., Ma, Y., De Coninck, Q., Ed., Bonaventure,
              O., Huitema, C., and M. Kuehlewind, Ed., "Multipath
              Extension for QUIC", Work in Progress, Internet-Draft,
              draft-ietf-quic-multipath,
              <https://datatracker.ietf.org/doc/draft-ietf-quic-
              multipath/>.

   [QUIC-RECOVERY]
              Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection
              and Congestion Control", RFC 9002,
              <https://www.rfc-editor.org/rfc/rfc9002>.

   [QUIC-TLS] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure
              QUIC", RFC 9001, <https://www.rfc-editor.org/rfc/rfc9001>.

Huitema                    Expires 12 May 2024                  [Page 6]
Internet-Draft              Explicit Path-ID               November 2023

   [QUIC-TRANSPORT]
              Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              <https://www.rfc-editor.org/rfc/rfc9000>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

7.2.  Informative References

   [Explicit-ID]
              Seeman, M., "separate Path IDs from Connection IDs", issue
              number 214, QUIC multipath Github repository , April 2023.

Author's Address

   Christian Huitema
   Private Octopus Inc.
   Email: huitema@huitema.net

Huitema                    Expires 12 May 2024                  [Page 7]