idnits 2.17.1 draft-loffredo-regext-epp-over-http-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (7 March 2022) is 773 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3470' is defined on line 466, but no explicit reference was found in the text == Unused Reference: 'RFC6839' is defined on line 479, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 6839 ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) ** Downref: Normative reference to an Informational RFC: RFC 8095 ** Obsolete normative reference: RFC 8740 (Obsoleted by RFC 9113) Summary: 6 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Registration Protocols Extensions M. Loffredo 3 Internet-Draft L. Luconi Trombacchi 4 Intended status: Standards Track M. Martinelli 5 Expires: 8 September 2022 IIT-CNR/Registro.it 6 J. Romanowski 7 M. Machnio 8 NASK/.pl Registry 9 7 March 2022 11 Extensible Provisioning Protocol (EPP) Transport over HTTP 12 draft-loffredo-regext-epp-over-http-01 14 Abstract 16 This document describes how the Extensible Provisioning Protocol 17 (EPP) is mapped over the Hypertext Transfer Protocol (HTTP). This 18 mapping requires the use of the Transport Layer Security (TLS) 19 protocol to protect information exchanged between an EPP client and 20 an EPP server. 22 Status of This Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at https://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on 8 September 2022. 39 Copyright Notice 41 Copyright (c) 2022 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 46 license-info) in effect on the date of publication of this document. 47 Please review these documents carefully, as they describe your rights 48 and restrictions with respect to this document. Code Components 49 extracted from this document must include Revised BSD License text as 50 described in Section 4.e of the Trust Legal Provisions and are 51 provided without warranty as described in the Revised BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 57 2. Reasons behind Using HTTP . . . . . . . . . . . . . . . . . . 3 58 3. Message Exchange . . . . . . . . . . . . . . . . . . . . . . 4 59 4. Session Management . . . . . . . . . . . . . . . . . . . . . 5 60 5. Return Codes . . . . . . . . . . . . . . . . . . . . . . . . 8 61 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 62 6.1. IIT-CNR/Registro.it EPP Server . . . . . . . . . . . . . 8 63 6.2. .pl domain Registry (NASK) EPP Server . . . . . . . . . . 9 64 7. Transport Considerations . . . . . . . . . . . . . . . . . . 9 65 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 66 9. Internationalization Considerations . . . . . . . . . . . . . 10 67 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 68 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 69 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 70 12.1. Normative References . . . . . . . . . . . . . . . . . . 11 71 12.2. Informative References . . . . . . . . . . . . . . . . . 12 72 Appendix A. Notes on Load Balancing . . . . . . . . . . . . . . 13 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 75 1. Introduction 77 Although the Extensible Provisioning Protocol (EPP) core 78 specification [RFC5730] does not state the transport protocol, only 79 the mapping over TCP [RFC5734] has been standardized thus far. 80 Nevertheless, some EPP implementations leverage HTTP due to its ease 81 of use and simplicity. This document describes the reasons behind 82 using HTTP as the transport protocol for EPP and how EPP is mapped 83 over HTTP preserving the semantics of commands. 85 HTTP is defined in some IETF documents according to the versions 86 currently in use: HTTP/1.1 [RFC7230], HTTP/2 [RFC7540], HTTP/3 87 [I-D.ietf-quic-http]. As the differences among such versions do not 88 affect the EPP mapping, hereinafter the version number is omitted 89 except for presenting the special features in the underlying layers 90 of the HTTP stack. 92 Security services beyond those defined in EPP are provided by the 93 Transport Layer Security (TLS) protocol [RFC8446]. 95 1.1. Conventions Used in This Document 97 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 98 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 99 "OPTIONAL" in this document are to be interpreted as described in BCP 100 14 [RFC2119] [RFC8174] when, and only when, they appear in all 101 capitals, as shown here. 103 2. Reasons behind Using HTTP 105 Unlike TCP, HTTP is loosely coupled with the network and provides 106 client-server cross-platform technology communication. Indeed, since 107 an HTTP connection is a higher-level abstraction of a network 108 connection, there is no need to take over all of the lower-level 109 details of TCP. For example, while in TCP the data transmission 110 between a client and a server starts only after having established a 111 connection through a 3-way handshake (i.e. SYN, SYN-ACK, ACK), HTTP 112 uses a one-way communication so that a client can directly issue a 113 request to a server and then receive a response. 115 All the burden needed to manage the HTTP connections is usually 116 performed by an application server, which a service can be deployed 117 on. Service implementors are only required to process the requests 118 and return the responses. Definitively, HTTP ease of use and 119 simplicity reduces the development time. 121 While TCP is connection-oriented, HTTP is stateless but not session 122 less. This means that, by making an EPP session untied from the 123 network connection, the EPP communication over HTTP is more flexible 124 and efficient than over TCP. 126 The main reason supporting the usage of TCP has always been its 127 speed. TCP has been significantly faster than HTTP as HTTP was 128 initially built on top of TCP so that every HTTP request should be 129 issued on a new TCP connection. However, subsequent HTTP versions 130 have been defined over time to increase the protocol speed and reduce 131 the gap with TCP: 133 * Compared to the original HTTP specification, HTTP/1.1 introduced 134 the "keep-alive" connection by default to enable a request- 135 response sequence on a single TCP connection without repeating the 136 connection handshake at each request; 137 * As opposed to HTTP/1.1, which keeps all requests and responses in 138 plain text format, HTTP/2 defined the binary framing layer to 139 encapsulate all messages in binary format; 140 * HTTP/3 is based on QUIC transport protocol 141 [I-D.ietf-quic-transport]. QUIC uses UDP [RFC768] instead of TCP 142 to exchange packets between the client and the server. It 143 incorporates TLS whereas HTTP/1.1 and HTTP/2 define TLS as an add- 144 on. So doing, HTTP/3 can provide a very quick handshake to 145 establish a secure connection. 147 In the perspective of moving to the cloud to achieve scalability and 148 cost reduction, it should be further noted that application protocols 149 that aren't based on HTTP can be hardly migrated by using cloud- 150 native features, both on client side and server side. In addition, 151 from the security point of view, registries would be limited in terms 152 of the third-party security services available to protect their EPP 153 servers. 155 Finally, some considerations should be done about load balancing 156 which is generally used by EPP operators to distribute the requests 157 across a pool of servers and, consequently, provide an efficient 158 domains registration and maintenance service. While HTTP load 159 balancers are very common and are quite often software, TCP load 160 balancers are usually implemented in dedicated hardware. In 161 addition, HTTP load balancers don't merely forward the traffic but 162 can make high-level routing decisions based on the message content. 163 With regard to the performance, although HTTP load balancers do more 164 work, their throughput is evaluated considerably fast. 166 Additional notes on how EPP sessions can be managed in HTTP load 167 balancing are included in Appendix A. 169 3. Message Exchange 171 EPP describes client-server interaction as a command-response 172 exchange where the client sends one command to the server and the 173 server returns one response to the client. A client MUST use the 174 POST method (Section 3.3 of [RFC7231]) to issue an EPP command 175 through the request body. A server receiving a request MUST return 176 an EPP message in the response body using the "Content-Length" 177 entity-header field to indicate the length in decimal number of 178 OCTETs of the entity-body. No EPP message information MUST be issued 179 through any other part of the request or the response. If the HTTP 180 connection is closed after a server receives and successfully 181 processes a command but before the response can be returned to the 182 client, the server MAY attempt to undo the effects of the command to 183 ensure a consistent state between the client and the server. 185 Commands MUST be processed independently and in the same order as 186 received from the server. An EPP client MAY issue multiple EPP 187 commands to an EPP server on an HTTP connection by relying on the 188 HTTP keep-alive capability. A server SHOULD limit a client to a 189 maximum number of HTTP connections based on server capabilities and 190 operational load. 192 A client might be able to realize a slight performance gain by 193 pipelining the requests, but this feature does not change the basic 194 single command, single response operating mode of the EPP protocol. 195 A server SHOULD limit the amount of time required for a client to 196 issue a well-formed EPP command and, consequently close an open HTTP 197 connection. 199 4. Session Management 201 The EPP session is implemented by using the mechanism described in 202 [RFC6265]. An EPP session is started by the client issuing an EPP 203 command. A server receiving an EPP command MUST use 204 the "Set-Cookie" response header to send the client a token that the 205 client will return in future requests within the scope of the EPP 206 session. For example (Figure 1), the server can send the client a 207 "session identifier" (a.k.a "session ID") named SID. The client then 208 returns the session ID in the "Cookie" header of the subsequent 209 requests. 211 == Server -> Client == 213 Set-Cookie: SID=52ceb07c2a824f09a1c6f9c45574097d 215 == Client -> Server == 217 Cookie: SID=52ceb07c2a824f09a1c6f9c45574097d 219 Figure 1 221 The name of the cookie attribute identifying the session ID is not 222 relevant and depends on the implementations. Examples of the names 223 that some programming languages use to represent the session ID 224 include JSESSIONID (Java EE), PHPSESSID (PHP), and ASPSESSIONID 225 (Microsoft ASP). 227 An EPP session is ended by the client issuing an EPP 228 command. A server receiving an EPP command MUST end the EPP 229 session invalidating it after having issued the response. 231 A client MAY open multiple EPP sessions and distribute commands from 232 a single EPP session over multiple HTTP connections. A server SHOULD 233 limit a client to a maximum number of EPP sessions based on server 234 capabilities and operational load. 236 EPP sessions that are inactive for more than a server-defined period 237 MAY be ended by a server invalidating the session. 239 Clients MAY issue the command outside an EPP session. In 240 such a case, servers MUST return the response without 241 starting a session. To accomplish this, a server MAY return no 242 cookie at all or provide the client with an expired cookie so that it 243 cannot be used for further communication with the server. Clients 244 MAY also issue the command within an EPP session to keep it 245 alive. 247 The mechanism implemented by a server to maintain the relationship 248 between a session and the EPP information negotiated with the client 249 through the command (e.g. the language, the namespace URIs 250 representing both the objects and the extensions to be managed during 251 the session) is out of the scope of this document. 253 The state machine described in Section 2 of [RFC5730] is updated as 254 shown in Figure 2. 256 | 257 V 258 +-----------------+ +-----------------+ 259 | Waiting for |----------------->| Prepare | 260 | Client |<-----------------| Greeting | 261 +-----------------+ Send +-----------------+ 262 ^ | ^ | Greeting 263 | | | | 264 | | | | Other command +-----------------+ 265 | | | +------------------>| Prepare | 266 | | +---------------------| Fail Response | 267 | | Send 2002 Response +-----------------+ 268 | | 269 Send 2200 | +-------------------------------+ 270 Response | +---------------+ | 271 +-------| Prepare Auth | | 272 | Fail Response | | 273 +---------------+ V 274 +-----------------+ ^ +-----------------+ 275 | End | | | Processing | 276 | Session | +---------| | 277 +-----------------+ Auth Fail +-----------------+ 278 ^ ^ | 279 | | Timeout | Auth OK 280 | +-------------------------------+ | Start 281 | | | Session 282 | | V 283 | +-----------------+ +-----------------+ 284 | | Prepare |<----------| Waiting for | 285 | | Greeting |---------->| Command or | 286 | +-----------------+ Send | or | 287 | Greeting | | 288 | Send 1500 +-----------------+ 289 | Response | ^ | 290 +-----------------+ | | | 291 | Processing | | | | 292 | |<--------------------+ | | Command 293 +-----------------+ | | Received 294 +-----------------+ Send | | 295 | Prepare | Response | | 296 | Response |----------+ | 297 +-----------------+ V 298 ^ +-----------------+ 299 Command | | Processing | 300 Processed +----------| Command | 301 +-----------------+ 303 Figure 2 305 5. Return Codes 307 Servers MUST NOT use HTTP return codes to signal clients about the 308 failure of the EPP commands. The HTTP code 200 MUST be used for both 309 successful and unsuccessful EPP requests. Servers MUST use HTTP 310 codes to signal clients about the failure of the HTTP requests. 312 Servers MUST return a 2002 response (i.e. Command use error) if the 313 client issues an EPP command other than the and the 314 commands through HTTP requests including either an empty or an 315 invalid session ID. Servers receiving a command through an 316 HTTP request including a session ID MAY return a 2002 response (i.e. 317 Command use error) or simply ignore the incoming session ID. 319 6. Implementation Status 321 NOTE: Please remove this section and the reference to RFC 7942 prior 322 to publication as an RFC. 324 This section records the status of known implementations of the 325 protocol defined by this specification at the time of posting of this 326 Internet-Draft, and is based on a proposal described in [RFC7942]. 327 The description of implementations in this section is intended to 328 assist the IETF in its decision processes in progressing drafts to 329 RFCs. Please note that the listing of any individual implementation 330 here does not imply endorsement by the IETF. Furthermore, no effort 331 has been spent to verify the information presented here that was 332 supplied by IETF contributors. This is not intended as, and must not 333 be construed to be, a catalog of available implementations or their 334 features. Readers are advised to note that other implementations may 335 exist. 337 According to RFC 7942, "this will allow reviewers and working groups 338 to assign due consideration to documents that have the benefit of 339 running code, which may serve as evidence of valuable experimentation 340 and feedback that have made the implemented protocols more mature. 341 It is up to the individual working groups to use this information as 342 they see fit". 344 6.1. IIT-CNR/Registro.it EPP Server 346 * Responsible Organization: Institute of Informatics and Telematics 347 of National Research Council (IIT-CNR)/Registro.it 348 * Location: https://epp.nic.it/ EPP endpoint available only "per IP 349 address" basis. 351 * Description: The .it EPP server is deployed on WildFly Application 352 Server. TLS versions supported are 1.2 and 1.3. Load balancing 353 is implemented with NGINX. EPP sessions are maintained on a Redis 354 cluster. 355 * Level of Maturity: This is a live implementation. 356 * Coverage: This implementation includes all of the features 357 described in this specification except for the media type that is 358 currently set to "text/xml". 359 * Contact Information: Mario Loffredo, mario.loffredo@iit.cnr.it 361 6.2. .pl domain Registry (NASK) EPP Server 363 * Responsible Organization: .pl domain Registry (NASK)/dns.pl 364 * Location: https://dns.pl EPP endpoint available only "per IP 365 address" basis. 366 * Description: It is an implementation of the EPP protocol that is 367 used by .pl Registry. 368 * Level of Maturity: This is a live implementation. 369 * Coverage: This implementation includes all of the features 370 described in this specification. 371 * Contact Information: Marcin Machnio, info@dns.pl 373 7. Transport Considerations 375 Section 2.1 of the EPP core specification [RFC5730] describes 376 considerations to be addressed by protocol transport mappings. This 377 document addresses each of the considerations using a combination of 378 features described in this document and features provided by HTTP as 379 follows: 381 * Sections 3.3.3 and 3.9.3 of [RFC8095] includes features to provide 382 reliability, flow control, ordered delivery, and congestion 383 control of, respectively, UDP and HTTP over TCP as 384 Pseudotransport. 385 * Section 3 and Section 4 of this document describe how the stateful 386 nature of EPP is preserved through controlled message exchanges 387 and managed sessions. 388 * Section 3 of this document notes that command pipelining is 389 possible with HTTP, though batch-oriented processing (combining 390 multiple EPP commands in a single HTTP request) is not permitted. 392 8. IANA Considerations 394 This document has no actions for IANA. 396 9. Internationalization Considerations 398 Servers MUST use the "charset" attribute in the HTTP "Content-Type" 399 response header field to specify the UTF-8 character encoding (e.g. 400 Content-Type: application/epp+xml; charset=UTF-8). 402 10. Security Considerations 404 Since clients credentials are included in the EPP command, 405 the HTTP over TLS [RFC8740] MUST be used to protect them from 406 disclosure while in transit. As well, the transfer over TLS prevents 407 from sniffing the session ID and, consequently, impersonating a 408 client to perform actions on registrars' objects. 410 Anyway, servers are RECOMMENDED to implement additional measures to 411 verify the client. These measures include IP whitelisting and 412 locking the session ID to the client's IP address. 414 As a further measure to enforce the security, servers MAY require 415 clients to present a digital certificate. Clients who possess and 416 present a valid X.509 digital certificate, issued by a recognized 417 Certification Authority (CA), could be identified and authenticated 418 by a server who trusts the corresponding CA. This certificate-based 419 mechanism is supported by HTTPS and can be used with EPP over HTTP. 420 The TLS protocol describes the specification of a client certificate 421 in Section 7.4.6 of [RFC8446]. 423 With regard to sessions, session IDs SHOULD be randomly generated to 424 mitigate the risk of obtaining a valid one through a brute-force 425 search. A session ID SHOULD be at least 128 bits or 16 bytes long. 426 An example of a reliable session ID is the Universally Unique 427 Identifier (UUID). Servers MAY limit the lifetime of active sessions 428 to avoid them being exchanged for a long time. 430 The following measures MAY also be taken to control cookies usage: 432 * restricting their scope through the "Domain" and "Path" 433 attributes; 434 * limiting their lifetime through the "Max-Age" and "Expire" 435 attributes. 437 Other attributes that are normally used to secure the cookies and 438 prevent them to be accessed from unintended parties or scripts, such 439 as "HttpOnly" and "Secure", are meaningless in this context. 441 Finally, servers are RECOMMENDED to perform additional checks to 442 limit the rate of open EPP sessions and HTTP connections to mitigate 443 the risk of congestion of requests. Here again, IP whitelisting 444 could also be implemented to prevent DDoS attacks. 446 If the EPP server is configured as a load balancer routing the 447 requests to a pool of backend servers, some of the aforementioned 448 checks SHOULD be implemented on the load balancer side. 450 11. Acknowledgements 452 The authors would like to acknowledge the following individuals for 453 their contributions to this document: Cristian Lucchesi, Stefano 454 Ruberti, Luca Vasarelli, Roberto Ravazzolo from IIT-CNR/Registro.it 455 and Adrian Prokop, Sławomir Mateuszczyk from NASK/.pl Registry. 457 12. References 459 12.1. Normative References 461 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 462 Requirement Levels", BCP 14, RFC 2119, 463 DOI 10.17487/RFC2119, March 1997, 464 . 466 [RFC3470] Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for 467 the Use of Extensible Markup Language (XML) within IETF 468 Protocols", BCP 70, RFC 3470, DOI 10.17487/RFC3470, 469 January 2003, . 471 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 472 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 473 . 475 [RFC6265] Barth, A., "HTTP State Management Mechanism", RFC 6265, 476 DOI 10.17487/RFC6265, April 2011, 477 . 479 [RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type 480 Structured Syntax Suffixes", RFC 6839, 481 DOI 10.17487/RFC6839, January 2013, 482 . 484 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 485 Protocol (HTTP/1.1): Message Syntax and Routing", 486 RFC 7230, DOI 10.17487/RFC7230, June 2014, 487 . 489 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 490 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 491 DOI 10.17487/RFC7231, June 2014, 492 . 494 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 495 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 496 DOI 10.17487/RFC7540, May 2015, 497 . 499 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 500 Code: The Implementation Status Section", BCP 205, 501 RFC 7942, DOI 10.17487/RFC7942, July 2016, 502 . 504 [RFC8095] Fairhurst, G., Ed., Trammell, B., Ed., and M. Kuehlewind, 505 Ed., "Services Provided by IETF Transport Protocols and 506 Congestion Control Mechanisms", RFC 8095, 507 DOI 10.17487/RFC8095, March 2017, 508 . 510 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 511 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 512 May 2017, . 514 [RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol 515 Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, 516 . 518 [RFC8740] Benjamin, D., "Using TLS 1.3 with HTTP/2", RFC 8740, 519 DOI 10.17487/RFC8740, February 2020, 520 . 522 12.2. Informative References 524 [I-D.ietf-quic-http] 525 Bishop, M., "Hypertext Transfer Protocol Version 3 526 (HTTP/3)", Work in Progress, Internet-Draft, draft-ietf- 527 quic-http-34, 2 February 2021, 528 . 531 [I-D.ietf-quic-transport] 532 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 533 and Secure Transport", Work in Progress, Internet-Draft, 534 draft-ietf-quic-transport-34, 14 January 2021, 535 . 538 [RFC5734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 539 Transport over TCP", STD 69, RFC 5734, 540 DOI 10.17487/RFC5734, August 2009, 541 . 543 [RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 544 DOI 10.17487/RFC0768, August 1980, 545 . 547 Appendix A. Notes on Load Balancing 549 An EPP server should be able to serve a large number of concurrent 550 requests from clients and return the responses in a fast and reliable 551 manner. In addition, since EPP is extensible, EPP servers might be 552 updated and the replacement of an EPP server with a new version 553 should take place in accordance with the service level agreement 554 negotiated between the registry and the registrars. To 555 cost-effectively scale high volumes of requests and redeploy a server 556 without affecting its functioning, best practice in providing a 557 software service generally requires using load balancing. This 558 section presents two possible approaches to the implementation of a 559 HTTP load balancing solution for an EPP server. 561 An EPP server made up of a server pool must always operate with 562 respect to the constraint that, once an EPP session is established, 563 all the requests related to that session should be processed by the 564 servers in the pool as long as the session is alive. 566 One possible approach is using sticky sessions. In this case, the 567 load balancer assigns an identifier to each client issuing a request. 568 Then, according to such identifier, the load balancer can route all 569 of the requests of a given client to the backend server that started 570 the session for its entire duration. This approach requires each 571 backend server to maintain the EPP information connected to the 572 sessions opened by that server. This means that when a backend 573 server is stopped and then restarted after its update, all the 574 sessions currently active and managed by that server are lost. 576 A more efficient solution consists in releasing the sessions from the 577 server pool. According to this approach, every session is stored 578 somewhere outside the server pool. The load balancer distributes the 579 request based on the load of each backend server and according to a 580 specific algorithm. When a server receives a request, it first 581 retrieves the session information by the session ID and, if any, 582 processes the request. Sessions are normally stored in a cluster of 583 NO-SQL databases so that performance and efficiency requirements are 584 fulfilled. In this approach, only the ongoing requests are lost when 585 a backend server is stopped and restarted. Moreover, maintaining the 586 sessions on a persistent data storage results in supporting a 587 virtually unlimited number of concurrent sessions. 589 Authors' Addresses 591 Mario Loffredo 592 IIT-CNR/Registro.it 593 Via Moruzzi,1 594 56124 Pisa 595 Italy 596 Email: mario.loffredo@iit.cnr.it 597 URI: https://www.iit.cnr.it 599 Lorenzo Luconi Trombacchi 600 IIT-CNR/Registro.it 601 Via Moruzzi,1 602 56124 Pisa 603 Italy 604 Email: lorenzo.luconi@iit.cnr.it 605 URI: https://www.iit.cnr.it 607 Maurizio Martinelli 608 IIT-CNR/Registro.it 609 Via Moruzzi,1 610 56124 Pisa 611 Italy 612 Email: maurizio.martinelli@iit.cnr.it 613 URI: https://www.iit.cnr.it 615 Jan Romanowski 616 NASK/.pl Registry 617 Kolska 12 618 01-045 Warszawa 619 Poland 620 Email: jan.romanowski@nask.pl 621 URI: https://www.dns.pl/ 623 Marcin Machnio 624 NASK/.pl Registry 625 Kolska 12 626 01-045 Warszawa 627 Poland 628 Email: info@dns.pl 629 URI: https://www.dns.pl/