Internet Engineering Task Force J. Yao Internet-Draft H. Li Intended status: Standards Track M. Zhang Expires: 1 December 2023 CNNIC May 2023 Extensible Provisioning Protocol (EPP) Transport over QUIC draft-yao-regext-epp-quic-00 Abstract This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a UDP-Based Multiplexed and Secure Transport connection(QUIC). EPP over QUIC (EoQ) has privacy properties similar to EPP over TCP with TLS specified in RFC 5734. This mapping can protect information exchanged between an EPP client and an EPP server, and can reduce protocol-induced delays due to QUIC features. 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 3 October 2023. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. Yao, et al. Expires 1 November 2023 [Page 1] Internet-Draft EPP over QUIC April 2023 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. Key Words . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Design for EPP Minimum Latency and Strong Security . . . . . 3 4. EPP Session Management . . . . . . . . . . . . . . . . . . . 3 5. QUIC Stream Mapping and Usage . . . . . . . . . . . . . . . . 4 6. EoQ Error Codes . . . . . . . . . . . . . . . . . . . . . . . 5 7. EPP Transaction Cancellation . . . . . . . . . . . . . . . . 5 8. Transaction Errors . . . . . . . . . . . . . . . . . . . . . 6 9. Protocol Errors . . . . . . . . . . . . . . . . . . . . . . . 6 10. EPP Session Resumption and Connection Migration . . . . . . . 7 11. EPP Message Exchange . . . . . . . . . . . . . . . . . . . . 7 12. Data Unit Format . . . . . . . . . . . . . . . . . . . . . . 9 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 13.1. Registration of an EoQ Identification String . . . . . . 10 13.2. Registration of Port Number . . . . . . . . . . . . . . 10 14. Security Considerations . . . . . . . . . . . . . . . . . . . 11 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 16. Normative References . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction This document describes how an Extensible Provisioning Protocol (EPP) session is mapped onto a UDP-Based Multiplexed and Secure Transport connection(QUIC). EPP over QUIC (EoQ) has privacy properties similar to EPP over TCP with TLS specified in RFC 5734. This mapping can protect information exchanged between an EPP client and an EPP server and can reduce protocol-induced delays due to QUIC features. EPP is described in [RFC5730]. QUIC is described in [RFC9000]. Using TLS to Secure QUIC is described in [RFC9001]. This document does not specify support for server-initiated transactions within established EoQ connections. That is, only the initiator of the EoQ connection may send commands over the connection. Yao, et al. Expires 1 November 2023 [Page 2] Internet-Draft EPP over QUIC April 2023 2. Key Words 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. Design for EPP Minimum Latency and Strong Security QUIC is specifically designed to reduce protocol-induced delays, with features such as: Support for 0-RTT data during session resumption, Support for advanced packet-loss recovery procedures as specified in "QUIC Loss Detection and Congestion Control" [RFC9002], Mitigation of head-of-line blocking by allowing parallel delivery of data on multiple streams. This mapping of EPP to QUIC will take advantage of these features in three ways: 1)Optional support for sending 0-RTT data during session resumption. 2)Long-lived QUIC connections over which multiple EPP transactions are performed, generating the sustained traffic required to benefit from advanced recovery features. 3)Mapping of each EPP command/Response transaction to a separate stream, to mitigate head- of-line blocking. This enables servers to respond to commands "out of order". It also enables clients to process responses as soon as they arrive, without having to wait for in-order delivery of responses previously posted by the server. [RFC9001] describes how to use TLS to secure QUIC, which will be used in EoQ to protect EPP transactions. 4. EPP Session Management EoQ connections are established as described in the QUIC transport specification [RFC9000]. During connection establishment, EoQ support is indicated by selecting the Application-Layer Protocol Negotiation (ALPN) token "eoq" in the crypto handshake. Mapping EPP session management facilities onto the QUIC service is straightforward. An EPP session first requires creation of a QUIC connection between two peers, one that initiates the connection request and one that responds to the connection request. The initiating peer is called the "client", and the responding peer is called the "server". An EPP server MUST listen for QUIC connection requests on a standard QUIC port assigned by IANA. The EPP client MUST create a stream and send an EPP to the EPP server after the QUIC connection has been established. The EPP server MUST return an EPP to the client after receiving the EPP message. An EPP session is normally ended by the client issuing an EPP command. A server receiving an EPP command Yao, et al. Expires 1 November 2023 [Page 3] Internet-Draft EPP over QUIC April 2023 MUST end the EPP session. A client MAY end an EPP session by closing the connection directly. A server MAY limit the life span of an established QUIC connection. EPP sessions that are inactive for more than a server-defined period MAY be ended by a server closing the QUIC connection directly. A server MAY also close QUIC connections that have been open and active for longer than a server-defined period. Clients MAY discard their connections to the server before the idle timeout (server-defined period) expires. Clients and servers MAY close the connection for a variety of other reasons, such as using QUIC's CONNECTION_CLOSE. Client and servers that send packets over a connection discarded by their peers might receive a stateless reset indication. If a connection fails, all the in-progress transactions on that connection MUST be abandoned. 5. QUIC Stream Mapping and Usage The mapping of EPP traffic over QUIC streams takes advantage of the QUIC stream features detailed in Section 2 of QUIC [RFC9000]. EPP follows a simple pattern in which the client sends a command, and the server provides one response. The mapping specified here requires that the client selects a separate QUIC stream for each command. The server then uses the same stream to provide the response message for that command. The practical result of this mechanism is that the content of each QUIC stream is exactly the same as the content of a TCP connection that would manage exactly one command. The client MUST select the next available client-initiated bidirectional stream for each subsequent command on a QUIC connection, in conformance with the QUIC [RFC9000]. In TCP connections, packet losses and other network events might cause commands to arrive in a different order, but servers SHOULD process commands as they arrive. In each QUIC connection, commands are not expected to arrive in order and servers SHOULD process commands as they arrive. The client MUST send the EPP command over the selected stream and MUST indicate through the STREAM FIN mechanism that no further data will be sent on that stream. The server MUST send the response on the same stream and MUST indicate, after the last response, through the STREAM FIN mechanism that no further data will be sent on that stream. Therefore, a single EPP transaction consumes a single bidirectional client-initiated stream. This means that the client's first command occurs on QUIC stream 0, the second on 4, and so on (see Section 2.1 of [RFC9000]). Servers MAY defer processing of a command until the STREAM FIN has been indicated on the stream selected by the client. Servers and clients MAY monitor the number of "dangling" streams which are not expected commands or responses. Implementations MAY impose a limit on the number of such dangling streams. If limits are encountered, implementations MAY close the connection. Yao, et al. Expires 1 November 2023 [Page 4] Internet-Draft EPP over QUIC April 2023 6. EoQ Error Codes The following error codes are defined for use when abruptly terminating streams, for use as application protocol error codes when aborting reading of streams, or for immediately closing connections: * EOQ_NO_ERROR (0x0): No error. This is used when the connection or stream needs to be closed, but there is no error to signal. * EOQ_INTERNAL_ERROR (0x1): The EoQ implementation encountered an internal error and is incapable of pursuing the transaction or the connection. * EOQ_PROTOCOL_ERROR (0x2): The EoQ implementation encountered a protocol error and is forcibly aborting the connection. * EOQ_REQUEST_CANCELLED (0x3): A EoQ client uses this to signal that it wants to cancel an outstanding transaction. * EOQ_EXCESSIVE_LOAD (0x4): A EoQ implementation uses this to signal when closing a connection due to excessive load. * EOQ_UNSPECIFIED_ERROR (0x5): A EoQ implementation uses this in the absence of a more specific error code. * EOQ_ERROR_RESERVED (0xd098ea5e): An alternative error code used for tests. 7. EPP Transaction Cancellation In QUIC, sending STOP_SENDING requests that a peer cease transmission on a stream. If a EoQ client wishes to cancel an outstanding request, it MUST issue a QUIC STOP_SENDING, and it SHOULD use the error code EOQ_REQUEST_CANCELLED. The STOP_SENDING request may be sent at any time but will have no effect if the server response has already been sent, in which case the client will simply discard the incoming response. The corresponding EPP transaction MUST be abandoned. Servers that receive STOP_SENDING act in accordance with Section 3.5 of [RFC9000]. Servers SHOULD NOT continue processing an EPP transaction if they receive a STOP_SENDING. Servers MAY impose implementation limits on the total number or rate of cancellation requests. If limits are encountered, servers MAY close the connection. In this case, servers wanting to help client debugging MAY use the error code EOQ_EXCESSIVE_LOAD. Servers MUST NOT continue processing an EPP transaction if they receive a RESET_STREAM request from the client before the client indicates the STREAM FIN. The server MUST issue a RESET_STREAM to indicate that the transaction is abandoned unless: it has already done so for another reason or it has Yao, et al. Expires 1 November 2023 [Page 5] Internet-Draft EPP over QUIC April 2023 already both sent the response and indicated the STREAM FIN. 8. Transaction Errors Servers normally complete transactions by sending a response on the transaction's stream, including cases where the EPP response indicates an EPP error. If a server is incapable of sending a response due to an internal error, it SHOULD issue a QUIC RESET_STREAM frame. The error code SHOULD be set to EOQ_INTERNAL_ERROR. The corresponding EPP transaction MUST be abandoned. Clients MAY limit the number of unsolicited QUIC RESET_STREAM frames received on a connection before choosing to close the connection. 9. Protocol Errors Other error scenarios can occur due to malformed, incomplete, or unexpected messages during a transaction. These include (but are not limited to): * a client receives a STREAM FIN before receiving the expected response * a server receives more than one command on a stream * a client receives a STOP_SENDING request * a client or server does not indicate the expected STREAM FIN after sending requests or responses * a client or a server attempts to open a unidirectional QUIC stream * a server attempts to open a server-initiated bidirectional QUIC stream If a peer encounters such an error condition, it is considered a fatal error. It SHOULD forcibly abort the connection using QUIC's CONNECTION_CLOSE mechanism and SHOULD use the EoQ error code EOQ_PROTOCOL_ERROR. In some cases, it MAY instead silently abandon the connection, which uses fewer of the local resources but makes debugging at the offending node more difficult. Yao, et al. Expires 1 November 2023 [Page 6] Internet-Draft EPP over QUIC April 2023 10. EPP Session Resumption and Connection Migration Using 0-RTT for EoQ has many compelling advantages. Clients can establish connections and send commands without incurring a connection delay. Servers can thus negotiate low values of the connection timers, which reduces the total number of connections that they need to manage. Session resumption and 0-RTT data transmission may create privacy risks. EPP protocols are normally run by trusted registries and registrars. So it is not a big issue for EoQ users. The recommendation for TLS 1.3 [RFC8446] is that the capability to use 0-RTT data should be turned off by default and only enabled if the user clearly understands the associated risks. Clients SHOULD use resumption tickets only once, as specified in Appendix C.4 of [RFC8446]. By default, clients SHOULD NOT use session resumption if the client's connectivity has changed. The QUIC session resumption mechanism reduces the cost of re-establishing sessions and enables 0-RTT data. There is a linkability issue associated with session resumption, if the same resumption token is used several times. The session resumption mechanism allows servers to correlate the resumed sessions with the initial sessions and thus to track the client. This creates a virtual long duration session. The series of commands in that session can be used by the server to identify the client. EPP client that use a small set of static IP addresses are more likely to prefer the reduced latency provided by session resumption and may consider this a valid reason to use resumption tickets even if the IP address changed between sessions. EoQ implementations might consider using the connection migration features defined in Section 9 of [RFC9000]. These features enable connections to continue operating as the client's connectivity changes. 11. EPP Message Exchange With the exception of the EPP client Hello, EPP messages are initiated by the EPP client in the form of EPP commands. An EPP server MUST return an EPP response to an EPP command on the same QUIC stream that carried the command. If the QUIC stream is closed after a server receives and successfully processes a command but before the response can be returned to the client, the server MAY attempt to undo the effects of the command to ensure a consistent state between the client and the server. EPP commands are idempotent, so processing a command more than once produces the same net effect on the repository as successfully processing the command once. An EPP client streams EPP commands to an EPP server on an established QUIC connection. A client MUST NOT distribute commands from a single EPP session over multiple QUIC connections. A client MAY establish multiple QUIC connections to support multiple EPP sessions with each session mapped to a single connection. A server SHOULD limit a client to a maximum number of streams based on server capabilities Yao, et al. Expires 1 November 2023 [Page 7] Internet-Draft EPP over QUIC April 2023 and operational load. EPP describes client-server interaction as a command-response exchange where the client sends one command to the server and the server returns one response to the client. Each EPP data unit MUST contain a single EPP message. Commands MUST be processed independently. A server SHOULD impose a limit on the amount of time required for a client to issue a well-formed EPP command. A server SHOULD end an EPP session and close a QUIC stream if a well-formed command is not received within the time limit. A general state machine for an EPP server is described in Section 2 of [RFC5730]. General client-server message exchange using QUIC transport is illustrated in Figure 1. Client Server | | | Successful QUIC Connection | | <<------------------------------->> | | | | Send | | >>------------------------------->> | | | | Stream for Greeting | | | | Send Greeting | | <<-------------------------------<< | | | | Send | | >>------------------------------->> | | | | Stream for | | | | Send Response | | <<-------------------------------<< | | | | Send Command X | | >>------------------------------->> | | | | Stream for Command X | | | | Send Response X | | <<-------------------------------<< | | | | Send Command Y | | >>------------------------------->> | | | Yao, et al. Expires 1 November 2023 [Page 8] Internet-Draft EPP over QUIC April 2023 | Stream for Command Y | | | | Send Response Y | | <<-------------------------------<< | | . | . . | Send | | >>------------------------------->> | | | | Stream for | | | | Send Response & Close Connection | | <<-------------------------------<< | | | Figure 1: QUIC Client-Server Message Exchange The EPP server MUST follow the "EPP Server State Machine" procedure described in section 2 of RFC5730. An EPP session is normally initiated by sending an EPP command to the EPP server and ended by the client issuing an EPP command. EPP clients and servers SHOULD prepare to support the commands and responses in parallel and sending them out of order between EPP command after the EPP session is created. In EoQ, they do that by sending commands and processing responses on their specific streams as soon as possible. 12. Data Unit Format The EPP data unit contains two fields: a 32-bit header that describes the total length of the data unit, and the EPP XML instance. The length of the EPP XML instance is determined by subtracting four octets from the total length of the data unit. A receiver must successfully read that many octets to retrieve the complete EPP XML instance before processing the EPP message. EPP Data Unit Format (one tick mark represents one bit position): Yao, et al. Expires 1 November 2023 [Page 9] Internet-Draft EPP over QUIC April 2023 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Total Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | EPP XML Instance | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+//-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Total Length (32 bits): The total length of the EPP data unit measured in octets in network (big endian) byte order. The octets contained in this field MUST be included in the total length calculation. EPP XML Instance (variable length): The EPP XML instance carried in the data unit. 13. IANA Considerations 13.1. Registration of an EoQ Identification String This document creates a new registration for the identification of EoQ in the "TLS Application-Layer Protocol Negotiation (ALPN) Protocol IDs" registry [RFC7301]. * The "eoq" string identifies EoQ: * Protocol: EoQ * Identification Sequence: 0x65 0x6F 0x71 ("eoq") * Specification: This document 13.2. Registration of Port Number IANA is requested to assign the following value in the "Service Name and Transport Protocol Port Number Registry" in the System range. The registry for that range requires IETF Review or IESG Approval [RFC6335]. * Service Name: EoQ * Port Number: 700 * Transport Protocol(s): UDP * Assignee: IESG * Contact: IETF Chair Yao, et al. Expires 1 November 2023 [Page 10] Internet-Draft EPP over QUIC April 2023 * Description: EPP run over QUIC * Reference: This document 14. Security Considerations EPP over QUIC provides the similary securtiy with EPP over TCP with TLS. Some related security issues have been discussed in RFC5734 and RFC9000. 15. Acknowledgements The authors thank the discussion in the IETF REGEXT discussion. 16. Normative References [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, DOI 10.17487/RFC3688, January 2004, . [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, . [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain Name Mapping", STD 69, RFC 5731, DOI 10.17487/RFC5731, August 2009, . [RFC5734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Transport over TCP", STD 69, RFC 5734, DOI 10.17487/RFC5734, August 2009, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, . [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, May 2021, . Yao, et al. Expires 1 November 2023 [Page 11] Internet-Draft EPP over QUIC April 2023 Authors' Addresses Jiankang Yao CNNIC 4 South 4th Street,Zhongguancun,Haidian District Beijing Beijing, 100190 China Phone: +86 10 5881 3007 Email: yaojk@cnnic.cn Hongtao Li CNNIC 4 South 4th Street,Zhongguancun,Haidian District Beijing Beijing, 100190 China Email: lihongtao@cnnic.cn Man Zhang CNNIC 4 South 4th Street,Zhongguancun,Haidian District Beijing Beijing, 100190 China Email: zhangman@cnnic.cn Yao, et al. Expires 1 November 2023 [Page 12]