RPKI to Router Protocol over QUIC
draft-liu-sidrops-rpki-rtr-over-quic-00

SIDROPS                                                          Y. Liu
Internet Draft                                             China Moblie
Intended status: Standards Track                                 C. Lin
Expires: May 10, 2025                              New H3C Technologies
                                                        November 3,
2024

                     RPKI to Router Protocol over QUIC
                  draft-liu-sidrops-rpki-rtr-over-quic-00

Abstract

   The Resource Public Key Infrastructure (RPKI) to Router Protocol
   provides a simple but reliable mechanism to receive
   cryptographically validated RPKI prefix origin data and router keys
   from a trusted cache. RPKI to Router (RTR) Protocol can be carried
   over various transports such as TCP, SSH or else. QUIC provides
   useful and secure semantics for RTR Protocol in particular as a
   single connection could carry multiple requests over streams,
   enabling much better efficiency and performance for both peers. This
   document describes how to use RTR Protocol over the QUIC transport
   protocol, named RTRoQUIC.

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 May 10, 2025.

Copyright Notice

   Copyright (c) 2024 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
   (http://trustee.ietf.org/license-info) in effect on the date of

Liu & Lin, et al.        Expire May 10, 2025                  [Page 1]
Internet-Draft         RPKI to Router over QUIC          November 2024

   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. Terminology and Definitions....................................3
   3. Connection Management..........................................4
      3.1. Connection Establishment..................................4
      3.2. Connection Termination....................................4
         3.2.1. QUIC Connection Termination Process..................4
         3.2.2. RTRoQUIC Considerations for Connection Termination...4
   4. Stream Mapping and Usage.......................................4
      4.1. Unidirectional Stream from Cache to Router................5
      4.2. Bidirectional Stream between Cache and Router.............5
   5. Endpoint Authentication........................................5
   6. Operational Considerations.....................................6
   7. IANA Considerations............................................6
   8. Security Considerations........................................6
   9. References.....................................................6
      9.1. Normative References......................................6
      9.2. Informative References....................................7
   Author's Address..................................................8

1. Introduction

   In order to verifiably validate the origin Autonomous Systems (ASes)
   and AS paths of BGP announcements, the Resource Public Key
   Infrastructure (RPKI) to Router Protocol [RFC8210] provides a simple
   but reliable mechanism to receive cryptographically validated RPKI
   [RFC6480] prefix origin data and router keys from a trusted cache.

   The transport-layer session between a router and a cache carries the
   binary Protocol Data Units (PDUs) in a persistent session. To
   prevent cache spoofing and DoS attacks by illegitimate routers, it
   is highly desirable that the router and the cache be authenticated
   to each other. Integrity protection for payloads is also desirable
   to protect against monkey-in-the-middle (MITM) attacks.

   The RPKI to Router (RTR) Protocol is not bound to any particular
   transport protocol, but allows a mapping to define how it could be

Liu & Lin, et al.       Expires May 10, 2025                  [Page 2]
Internet-Draft         RPKI to Router over QUIC          November 2024

   implemented over any specific transport protocol. At present, some
   secure transport protocols are defined to carry RTR Protocol: TCP-A0
   transport [RFC5925], Secure Shell version 2 (SSHv2) transport
   [RFC4252], TCP MD5 transport [RFC5925], TCP over IPsec transport
   [RFC4301], and Transport Layer Security (TLS) transport [RFC8446].

   However, because of the connection-oriented feature, almost all of
   the current secure transport protocols used by RTR Protocol is TCP
   based. As is well known, TCP has some shortcomings such as head-of-
   line blocking.

   QUIC [RFC9000] is a UDP-based multiplexed and secure transport
   protocol that provides connection-oriented and stateful interaction
   between a client and server. It can provide low latency and
   encrypted transport with resilient connections.

   QUIC uses multiple simultaneous streams to carry data in one
   direction. Each stream is a separate unidirectional or bidirectional
   channel consisting of an ordered stream of bytes. In Addition, each
   stream has its own flow control, which limit bytes sent on a stream,
   together with flow control of the connection.

   Therefore, QUIC is a proper secure transport protocol for the
   message transmission mechanism of RTR Protocol. In addition, QUIC
   does not have the TCP shortcomings such as head of line blocking.
   This document specifies how to use QUIC as the secure transport
   protocol for RTR Protocol.

2. Terminology 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.

   In this document, the terms "client" and "server" are used to refer
   to the two ends of the QUIC connection. The client actively
   initiates the QUIC connection. The terms "router" and "cache" are
   used to refer to the two ends of the RTR Protocol session. A router
   establishes and keeps open a connection to one or more caches,
   generally, a "router" is a "client" meanwhile a "cache" is a
   "server".

   *  Client: The endpoint that initiates a QUIC connection, the RTR
   router.

Liu & Lin, et al.       Expires May 10, 2025                  [Page 3]
Internet-Draft         RPKI to Router over QUIC          November 2024

   *  Server: The endpoint that accepts a QUIC connection, the RTR
   cache.

3. Connection Management

3.1. Connection Establishment

   QUIC connection establishment is described in [RFC9000]. During
   establishing connection, RTRoQUIC support is indicated by selecting
   the Application-Layer Protocol Negotiation (ALPN) [RFC7301] token as
   listed in the IANA Section 7 in the TLS handshake.

   The router MUST also act as the client meanwhile the cache must also
   act as the server.

   The router should be the initiator of the QUIC connection to the
   cache meanwhile the cache acts as a connection acceptor.

3.2. Connection Termination

3.2.1. QUIC Connection Termination Process

   The typical QUIC connection termination process is described in
   [RFC9000].

3.2.2. RTRoQUIC Considerations for Connection Termination

   When a RTR session is implemented based on a QUIC connection, the
   idle timeout should be disabled or the QUIC max_idle_timeout should
   be set appropriately in order to keep the QUIC connection persistent
   even if the RTR session is idle.

   When the cache and router support different versions, the checker
   should close the RTR session and the associated QUIC connection.

   When a router or cache is detecting the interruption of the QUIC
   connection, it SHOULD terminate the connection.

4. Stream Mapping and Usage

   Currently, there are eleven kinds of RTR Protocol Data Units (PDUs)
   exchanged between the cache and the router, namely Serial Notify
   PDU, Serial Query PDU, Reset Query PDU, Cache Response PDU, IPv4
   Prefix PDU, IPv6 Prefix PDU, End of Data PDU, Cache Reset PDU,
   Router Key PDU, Error Report PDU and ASPA PDU [I-D.ietf-sidrops-
   8210bis]. The eleven kinds of RTR PDUs need to be mapped into QUIC
   streams.

Liu & Lin, et al.       Expires May 10, 2025                  [Page 4]
Internet-Draft         RPKI to Router over QUIC          November 2024

   QUIC [RFC9000] is a UDP-based multiplexed and secure transport
   protocol that provides connection-oriented and stateful interaction
   between a client and server. It can provide low latency and
   encrypted transport with resilient connections.

   QUIC Streams provide a lightweight, ordered byte-stream abstraction
   to an application. Streams can be unidirectional or bidirectional
   meanwhile streams can be initiated by either the client or the
   server. Unidirectional streams carry data in one direction: from the
   initiator of the stream to its peer. Bidirectional streams allow for
   data to be sent in both directions.

   QUIC uses Stream ID to identify the stream. The least significant
   bit (0x1) of the stream ID identifies the initiator of the stream
   (client with the bit set to 0). The second least significant bit
   (0x2) of the stream ID distinguishes between bidirectional streams
   (with the bit set to 0) and unidirectional streams [RFC9000].

4.1. Unidirectional Stream from Cache to Router

   Among RTR PDUs from the cache (server) to the router (client), Cache
   Response PDU is always followed by payload PDUs and an End of Data
   PDU. And the payload PDUs include IPv4 Prefix PDU, IPv6 Prefix PDU,
   Router Key PDU and ASPA PDU.

   The above PDUs are initiated by the cache and no reply is needed
   from the router. So this six PDUs SHOULD be mapped into one
   unidirectional stream whose stream type is 0x3 according to section
   2.1 of [RFC9000].

4.2. Bidirectional Stream between Cache and Router

   In addition to the PDUs sent in the unidirectional flow, other PDUs
   currently include Serial Notify PDU, Serial Query PDU, Reset Query
   PDU, Cache Reset PDU and Error Report PDU. Some of these PDUs are
   initiated by the cache and some are sent by the router. So this PDUs
   MUST be mapped into one or more bidirectional stream whose stream
   type is 0x0 according to section 2.1 of [RFC9000].

5. Endpoint Authentication

   RTRoQUIC uses QUIC which uses TLS version 1.3 or greater. Therefore,
   the TLS handshake process can be used for RTRoQUIC endpoint
   authentication. A third-party authentication mechanism can also be
   applied for RTRoQUIC endpoint authentication, such as a TLS client
   certificate.

Liu & Lin, et al.       Expires May 10, 2025                  [Page 5]
Internet-Draft         RPKI to Router over QUIC          November 2024

6. Operational Considerations

   The decision to use RTRoQUIC instead of the TCP-based mechanism in
   [RFC8210] is an operational decision, and an implementation MUST
   provide a configuration mechanism to enable RTRoQUIC on the RTR
   session.

   Some connectivity problems (such as blocking UDP) could result in a
   failure to establish a QUIC connection. When this happens, the
   router SHOULD attempt to establish a TCP-based RTR session.

7. IANA Considerations

   This document creates a new registration for the identification of
   RTRoQUIC in the "Application Layer Protocol Negotiation (ALPN)
   Protocol IDs registry established in [RFC7301].

   The "RTRoQ" string identifies RTRoQUIC:

   *  Protocol: RTRoQUIC

   *  Identification Sequence: 0x52 0x54 0x52 0x6f 0x51 ("RTRoQ")

   *  Specification: This document

8. Security Considerations

   This document replaces the transport protocol layer of RTR from TCP
   to QUIC. The basic protocol specification of RTR is not modified,
   and therefore the new security risks are not introduced to the basic
   RTR protocol. RTRoQUIC enhances transport-layer security for RTR
   session according to [RFC9000].

   This document does not require to support third-party authentication
   (e.g., backend Authentication) due to the fact that TLS does not
   specify this way of authentication. If third-party authentication is
   needed, TLS client certificates are recommended to be used here.

9. References

9.1. Normative References

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

Liu & Lin, et al.       Expires May 10, 2025                  [Page 6]
Internet-Draft         RPKI to Router over QUIC          November 2024

   [RFC4252] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH)
             Authentication Protocol", RFC 4252, DOI 10.17487/RFC4252,
             January 2006, <https://www.rfc-editor.org/info/rfc4252>.

   [RFC4301] Kent, S. and K. Seo, "Security Architecture for the
             Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
             December 2005, <https://www.rfc-editor.org/info/rfc4301>.

   [RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP
             Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
             June 2010, <https://www.rfc-editor.org/info/rfc5925>.

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

   [RFC8210] Bush, R. and R. Austein, "The Resource Public Key
             Infrastructure (RPKI) to Router Protocol, Version 1", RFC
             8210, DOI 10.17487/RFC8210, September 2017,
             <https://www.rfc-editor.org/info/rfc8210>.

   [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
             Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
             <https://www.rfc-editor.org/info/rfc8446>.

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

   [I-D.ietf-sidrops-8210bis] Bush, R. and R. Austein, "The Resource
             Public Key Infrastructure (RPKI) to Router Protocol,
             Version 2", Work in Progress, Internet-Draft, draft-ietf-
             sidrops-8210bis-16, 27 September 2024,
             <https://datatracker.ietf.org/doc/html/draft-ietf-sidrops-
             8210bis-16>.

9.2. Informative References

   [RFC6480] Lepinski, M. and S. Kent, "An Infrastructure to Support
             Secure Internet Routing", RFC 6480, DOI 10.17487/RFC6480,
             February 2012, <https://www.rfc-editor.org/info/rfc6480>.

   [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan,
             "Transport Layer Security (TLS) Application-Layer Protocol
             Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301,
             July 2014, <https://www.rfc-editor.org/info/rfc7301>.

Liu & Lin, et al.       Expires May 10, 2025                  [Page 7]
Internet-Draft         RPKI to Router over QUIC          November 2024

Author's Address

   Yisong Liu
    China Mobile
   China
   Email: liuyisong@chinamobile.com

   Changwang Lin
   New H3C Technologies
   Beijing
   China

   Email: linchangwang.04414@h3c.com

Liu & Lin, et al.       Expires May 10, 2025                  [Page 8]