Extensible Provisioning Protocol (EPP) Transport over QUIC
draft-yao-regext-epp-quic-01
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Jiankang Yao , Hongtao Li , Zhiwei Yan , Dan Keathley , James Gould | ||
| Last updated | 2024-02-18 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-yao-regext-epp-quic-01
Yao, et al. Expires 21 August 2024 [Page 4] Internet-Draft EPP over QUIC February 2024 Client Server | | | Successful QUIC Connection | | <<------------------------------->> | | | | Successful QUIC Stream | | <<------------------------------->> | | | | Send Greeting | | <<-------------------------------<< | | | | Send <login> | | >>------------------------------->> | | | | Send Response | | <<-------------------------------<< | | | | Send Command X | | >>------------------------------->> | | | | Send Response X | | <<-------------------------------<< | | | | Send Command Y | | >>------------------------------->> | | | | Send Response Y | | <<-------------------------------<< | | . | . . | Send <logout> | | >>------------------------------->> | | | | Send Response | | <<-------------------------------<< | | | | Close QUIC Stream | | <<------------------------------->> | | | | Close QUIC Connection | | <<------------------------------->> | Figure 1: QUIC Client-Server Message Exchange The EPP server MUST follow the "EPP Server State Machine" procedure described in [RFC5730]. Yao, et al. Expires 21 August 2024 [Page 5] Internet-Draft EPP over QUIC February 2024 5. 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): 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. 6. Transport Considerations Section 2.1 of [RFC5730] describes considerations to be addressed by protocol transport mappings. This document addresses each of those considerations using a combination of features of the QUIC protocol itself and features of this document. * Command Order: QUIC guarantees ordered processing of data within each stream. Section 2 of [RFC9000] describes streams in detail. * Session Mapping: EPP session management utilizes QUIC streams and is described in Section 3 * Stateful Nature: QUIC supports stateful communications between endpoints via connection IDs and long-lived streams within each connection. Sections 2 and 5 of [RFC9000] describe these features, respectively. * Frame Data Units: QUIC uses frames as one of its units of information when sending data over a stream. Part packets-frames of [RFC9000] describes frames, and packets, in detail. Yao, et al. Expires 21 August 2024 [Page 6] Internet-Draft EPP over QUIC February 2024 * Congestion Avoidance: QUIC provides various mechanisms to help achieve congestion avoidance. [RFC9002] describes these mechanisms in detail. * Reliability: QUIC uses message acknowledgement, packet retransmission, and other features to ensure reliability. Part packetization of [RFC9000] describes these features in detail. * Pipelining: Pipelining is allowed in EoQ. QUIC streams support sending multiple frames without waiting for responses from the other peer. This does not change the basic single command, single response operating mode of the core EPP protocol. 7. IANA Considerations 7.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]. * Protocol: EoQ * Identification Sequence: 0x65 0x6F 0x71 ("eoq") * Reference: This document 7.2. Registration of Port Number The "Service Name and Transport Protocol Port Number Registry" contains an entry for EPP UDP/700 based on [RFC6335]. However, no known implementations of EPP over UDP exist. The entry will be reassigned to reference this draft. * Service Name: epp * Port Number: 700 * Transport Protocol(s): UDP * Assignee: IESG * Contact: IETF Chair * Description: EPP run over QUIC * Reference: This document Yao, et al. Expires 21 August 2024 [Page 7] Internet-Draft EPP over QUIC February 2024 8. 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]. EoQ servers run the risk of a resource exhaustion attack by allowing the creation of unlimited QUIC streams per QUIC connection. Servers SHOULD limit a client to a maximum number of QUIC streams per QUIC connection based on server capabilities and operational load. 9. Acknowledgements The authors wish to thank the following persons for their feedback and suggestions: Scott Hollenbeck. 10. Normative References [BCP14] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017. <https://www.rfc-editor.org/info/bcp14> [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, <https://www.rfc-editor.org/info/rfc5730>. [RFC5734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Transport over TCP", STD 69, RFC 5734, DOI 10.17487/RFC5734, August 2009, <https://www.rfc-editor.org/info/rfc5734>. [RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>. [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>. Yao, et al. Expires 21 August 2024 [Page 8] Internet-Draft EPP over QUIC February 2024 [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>. [RFC9001] Thomson, M., Ed. and S. Turner, Ed., "Using TLS to Secure QUIC", RFC 9001, DOI 10.17487/RFC9001, May 2021, <https://www.rfc-editor.org/info/rfc9001>. [RFC9002] Iyengar, J., Ed. and I. Swett, Ed., "QUIC Loss Detection and Congestion Control", RFC 9002, DOI 10.17487/RFC9002, May 2021, <https://www.rfc-editor.org/info/rfc9002>. Appendix A. Change History A.1. Change from 00 to 01 1. Added Dan Keathley and James Gould as co-authors and aligned the draft with EPP RFC 5734. 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 21 August 2024 [Page 9] Internet-Draft EPP over QUIC February 2024 Daniel Keathley VeriSign, Inc. 12061 Bluemont Way Reston, VA 20190 United States of America Email: dkeathley@verisign.com URI: http://www.verisigninc.com James Gould VeriSign, Inc. 12061 Bluemont Way Reston, VA 20190 United States of America Email: jgould@verisign.com URI: http://www.verisigninc.com Yao, et al. Expires 21 August 2024 [Page 10]