Re: [regext] Comments to the feedback about epp-over-http

[Mario Loffredo]

Hi Matthias,

thanks a lot for your interest and feedback.

Please find my comments inline prefixed with [ML]

Il 28/03/2022 23:40, Matthias Pfeifer ha scritto:

Hello,

i would also add a comment and questions:

>In the perspective of moving to the cloud to achieve scalability and
>  cost reduction, it should be further noted that application protocols
>   that aren't based on HTTP can be hardly migrated by using cloud-
>   native features, both on client side and server side.  In addition,
>   from the security point of view, registries would be limited in terms
>   of the third-party security services available to protect their EPP
>   servers.

Can you please elaborate on

>"registries would be limited in terms of the third-party security 
services available to protect their EPP >servers."


Why?


And also on

>"and should be further noted that application protocols
>that aren't based on HTTP can be hardly migrated by using cloud-
>native features, both on client side and server side. " (since the 
cloudproviders offer tcp LB as well)


[ML] I added the text above following up the feedback provided by Gavin 
from CentralNIC who probably has already experienced some drawbacks in 
migrating to cloud his EPP server based on TCP.


@Gavin, you are surely more knowledgeable than me about this topic so if 
you wish to integrate my response, please feel free to do it.


My knowledge is limited to what I have learnt from the web.

That said, AFAIK most of cloud providers don't allow to open low level 
sockets. You cannot use any port except 80 and 443 (HTTP and HTTPS).  I 
imagine that they do that due to security reasons.


Honestly don't know whether and how such a block can be bypassed.

In addition, from what I've read, TCP load balancers are intended for 
TCP traffic on well-known ports, such as port 25 for SMTP.


It seems quite clear to me that cloud platforms have been designed to 
natively support HTTP-based rather than TCP-based applications.




>While TCP is connection-oriented, HTTP is stateless but not session
>less.  This means that, by making an EPP session untied from the
>network connection, the EPP communication over HTTP is more flexible
>and efficient than over TCP.

They work on different Layers so IMHO its hard to make a comparsion in 
that way.


[ML] We can compare their effects on the functioning of an EPP server.

SInce in EPP-over-TCP, an EPP session is mapped on a TCP connection, the 
session gets lost if the TCP connection breaks down.


This doesn't happen in EPP-over-HTTP because the EPP session is mapped 
on an HTTP session that is a pure logical concept.


In addition, if the EPP session is maintained outside the EPP server (or 
a pool of backend servers in a load balancing scheme) , the EPP session 
doesn't get lost even when the server (or one of the servers that has 
previously started the EPP session) is stopped.





>While HTTP load balancers are very common and are quite often 
software, TCP load

> balancers are usually implemented in dedicated hardware

Whats the point? TCP and HTTP LBs are even used in combination


[ML] The point is that HTTP load balancers are more flexible than TCP 
load balancers because they work at a higher layer.


Let's suppose, for example, to have an HTTP server based on HTTP/2 and 
we want to move to QUIC.


I presume that such a change would require little to no effort on the 
HTTP load balancer.




>An EPP server made up of a server pool must always operate with
>respect to the constraint that, once an EPP session is established,
>all the requests related to that session should be processed by the
>servers in the pool as long as the session is alive.

This is true in general and there are workarounds (eg CARP or VRRP  
and token)

The LB part looks too one-sided to me


[ML] Sorry, can you further clarify your remark?

I confess that I don't know CARP and VRRP in detail but it seems to me 
that they can't be helpful to figure out how to store session 
information to make session survive server failures.


In the case where sticky sessions are used and each backend server 
maintains the HTTP sessions it starts, if a server breaks down, you can 
recover the server but not its sessions.


Whereas sessions are stored on a persistent memory outside the backend 
servers and any server is able to serve the EPP requests, you can 
redirect the EPP traffic to another server without any impact on client 
side.



Anyway, we'll further review that section to make it appear more objective.



And a comment:

>The reasons why we have used session cookiea are that they represent 
a standard method >(RFC6265), >well known to the community of REST 
service implementers, largely used and natively >supported by 
>libraries and frameworks on both client and server side. For example, 
it is the same >method used by >rdap-openid to map an RDAP session and 
tie it to an access token :-)


> Which method other than session cookie shoud be used instead ?

For

Re: [regext] Comments to the feedback about epp-over-http

[Gould, James]

Mario,

My feedback is embedded below.

--

JG

[cid:image001.png@01D84340.6739D180]

James Gould
Fellow Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com

From: Mario Loffredo 
Date: Monday, March 28, 2022 at 6:59 AM
To: James Gould , "regext@ietf.org" 
Subject: [EXTERNAL] Re: [regext] Comments to the feedback about epp-over-http


Hi James,

thanks for ypur quick reply.

Please find my comments below.
Il 25/03/2022 16:45, Gould, James ha scritto:
Mario,

For #4 “Cookie vs. HTTP Connection”, you asked the question “can you further 
clarify why we should opt for establishing the cookie at setup of the 
connection and how should it be possible? For example, what kind of request 
should be used to start the HTTP connection?”.

I implemented pluggable transports in the Verisign EPP SDK, which included 
HTTP, HTTPS, TCP, and TLS.  The Verisign EPP SDK does include a client 
interface as well as a server stub implementation, so I was able to see the 
transports from both sides.  Support for HTTP and HTTPS was removed once we 
stopped supporting EPP over HTTP.  The cookie is setup at the time of the HTTP 
or HTTPS connection.  There is no “request” that is used to start the HTTP 
connection, just like the case for TCP and TLS.  A network connection is made, 
which includes the underlying TLS handshake in the case of HTTPS and TLS and 
the cookie is setup for HTTP and HTTPS, and then the EPP application protocol 
rides on top of it.

It seems to me a very low-level implementation.

Sorry but I stiil don't understand how cookies are returned. They should be 
returned in an HTTP response that doesn't correspond to an HTTP request. 
Correct?

JG: HTTP is being defined as a transport for EPP, so it should be treated as 
such.  The setup and tear-down of the HTTP connection, includes the setup of 
the cookies that is used for HTTP session tracking.  When a connection is made 
to the EPP / HTTPS server, the TLS connection is first established via the 
TLS-handshake and the HTTP session is established via setup of the session 
cookie (e.g., JSESSIONID), which then enables the server to maintain state.  
State such as tracking failed login attempts and timeouts (idle / command / 
absolute), which will result in a drop in the HTTP session / connection when 
the login attempt threshold is exceeded.  At the application layer, a HTTPS 
connection is treated in the same way as a TLS connection, where the transport 
handles the framing and the connection state, and the application layer returns 
the EPP Greeting when the connection is setup and drops the connection with a 
EPP logout occurs or other EPP session conditions (e.g., exceeding timeouts).  
The HTTP session cookie is returned in all the HTTP responses.  There is 
absolutely no intermingling of the transport layer (HTTP) with the application 
layer (EPP) other than making a connection available to read and write framed 
packets and the ability to close the connection when needed.

If so, it seems to me uncompliant with what is stated in the first paragraph of 
Section 2.1 of RFC7230:

   HTTP is a stateless request/response protocol that operates by

   exchanging messages (Section 
3)
 across a reliable transport- or

   session-layer "connection" (Section 
6).
  An HTTP "client" is a

   program that establishes a connection to a server for the purpose of

   sending one or more HTTP requests.  An HTTP "server" is a program

   that accepts connections in order to service HTTP requests by sending

   HTTP responses.

JG: I don’t see how using HTTP as a EPP transport would be considered 
uncompliant with RFC7230.  Below is the flow of using HTTP as an EPP transport:

  1.  Establish TCP connection
  2.  Establish TLS session via TLS-handshake
  3.  Establish HTTP session via setup of the HTTP session cookie (e.g., 
JSESSIONID)
  4.  Return EPP Greeting in framed HTTP response with the session cookie 
(e.g., JSESSIONID)
  5.  Support HTTP requests in the form of framed EPP commands that are 
returned in HTTP responses in the form of framed EPP responses.
  6.  EPP session ends that drops the connection (HTTP / TLS / TCP)

Anyway, the approach normally followed by every HTTP implementer leverages the 
services provid

Re: [regext] Comments to the feedback about epp-over-http

[Thomas Corte (TANGO support)]

Hello,

On 3/25/22 15:58, Mario Loffredo wrote:


Hi folks,

here are in the following some comments grouped by subject to last 
meeting's feedback about EPP-over-HTTP:

...
*2)  Cookies*

Jim (Reed) asked why cookies should be used in this case.
...
Which method other than session cookie shoud be used instead ?


In terms of EPP-over-HTTP implementations in the wild, RED.ES's abysmal 
implementation for .es comes to mind, which uses a proprietary EPP 
extension for the submission of the EPP client's credentials along with 
each and every command. But such a move away from a stateful EPP session 
is surely not desirable, leaving cookies (or some other way to maintain 
state over multiple HTTP requests) as the only sensible choice.


Best regards,

Thomas Corte

--
TANGO REGISTRY SERVICES® is a product of:
Knipp Medien und Kommunikation GmbH
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund   E-Mail: supp...@tango-rs.com
Germany

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Comments to the feedback about epp-over-http

[Mario Loffredo]

Hi James,

Il 29/03/2022 13:41, Gould, James ha scritto:


Mario,

My feedback is embedded below.

--

JG




*James Gould
*Fellow Engineer
jgo...@verisign.com 



703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com 

*From: *Mario Loffredo 
*Date: *Monday, March 28, 2022 at 6:59 AM
*To: *James Gould , "regext@ietf.org" 

*Subject: *[EXTERNAL] Re: [regext] Comments to the feedback about 
epp-over-http


Hi James,

thanks for ypur quick reply.

Please find my comments below.

Il 25/03/2022 16:45, Gould, James ha scritto:

Mario,

For #4 “Cookie vs. HTTP Connection”, you asked the question “can
you further clarify why we should opt for establishing the cookie
at setup of the connection and how should it be possible? For
example, what kind of request should be used to start the HTTP
connection?”.

I implemented pluggable transports in the Verisign EPP SDK, which
included HTTP, HTTPS, TCP, and TLS.  The Verisign EPP SDK does
include a client interface as well as a server stub
implementation, so I was able to see the transports from both
sides.  Support for HTTP and HTTPS was removed once we stopped
supporting EPP over HTTP.  The cookie is setup at the time of the
HTTP or HTTPS connection.  There is no “request” that is used to
start the HTTP connection, just like the case for TCP and TLS.  A
network connection is made, which includes the underlying TLS
handshake in the case of HTTPS and TLS and the cookie is setup for
HTTP and HTTPS, and then the EPP application protocol rides on top
of it.

It seems to me a very low-level implementation.

Sorry but I stiil don't understand how cookies are returned. They 
should be returned in an HTTP response that doesn't correspond to an 
HTTP request. Correct?


JG: HTTP is being defined as a transport for EPP, so it should be 
treated as such.  The setup and tear-down of the HTTP connection, 
includes the setup of the cookies that is used for HTTP session 
tracking.  When a connection is made to the EPP / HTTPS server, the 
TLS connection is first established via the TLS-handshake and the HTTP 
session is established via setup of the session cookie (e.g., 
JSESSIONID), which then enables the server to maintain state.  State 
such as tracking failed login attempts and timeouts (idle / command / 
absolute), which will result in a drop in the HTTP session / 
connection when the login attempt threshold is exceeded.  At the 
application layer, a HTTPS connection is treated in the same way as a 
TLS connection, where the transport handles the framing and the 
connection state, and the application layer returns the EPP Greeting 
when the connection is setup and drops the connection with a EPP 
logout occurs or other EPP session conditions (e.g., exceeding 
timeouts).  The HTTP session cookie is returned in all the HTTP 
responses.  There is absolutely no intermingling of the transport 
layer (HTTP) with the application layer (EPP) other than making a 
connection available to read and write framed packets and the ability 
to close the connection when needed.


If so, it seems to me uncompliant with what is stated in the first 
paragraph of Section 2.1 of RFC7230:


    HTTP is a stateless request/response protocol that operates by
    exchanging messages (Section 3  
)
 across a reliable transport- or
    session-layer "connection" (Section 6  
).*An
 HTTP "client" is a*
*   program that establishes a connection to a server for the purpose of*
*   sending one or more HTTP requests.*   *An HTTP "server" is a program*
*   that accepts connections in order to service HTTP requests by sending*
*   HTTP responses.*

JG: I don’t see how using HTTP as a EPP transport would be considered 
uncompliant with RFC7230. Below is the flow of using HTTP as an EPP 
transport:


 1. Establish TCP connection
 2. Establish TLS session via TLS-handshake
 3. Establish HTTP session via setup of the HTTP session cookie (e.g.,
JSESSIONID)
 4. Return EPP Greeting in framed HTTP response with the session
cookie (e.g., JSESSIONID)
 5. Support HTTP requests in the form of framed EPP commands that are
returned in HTTP responses in the form of framed EPP responses.
 6. EPP session ends that drops the connect

Re: [regext] Comments to the feedback about epp-over-http

[Mario Loffredo]

Hi Thomas,

Il 29/03/2022 14:05, Thomas Corte (TANGO support) ha scritto:

Hello,

On 3/25/22 15:58, Mario Loffredo wrote:


Hi folks,

here are in the following some comments grouped by subject to last 
meeting's feedback about EPP-over-HTTP:

...
*2)  Cookies*

Jim (Reed) asked why cookies should be used in this case.
...
Which method other than session cookie shoud be used instead ?


In terms of EPP-over-HTTP implementations in the wild, RED.ES's 
abysmal implementation for .es comes to mind, which uses a proprietary 
EPP extension for the submission of the EPP client's credentials along 
with each and every command. But such a move away from a stateful EPP 
session is surely not desirable, leaving cookies (or some other way to 
maintain state over multiple HTTP requests) as the only sensible choice.


That's exactly my main concern about such an idea that was the same 
supporting last proposal about EPP-over-HTTP submitted to this WG.


Making EPP completely stateful appeared,and still apeears, to me 
inefficient and in contrast with the trend in the design of REST services.



Best,

Mario




Best regards,

Thomas Corte


--
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Comments to the feedback about epp-over-http

[Thomas Corte (TANGO support)]

Hello Mario,

On 3/29/22 17:07, Mario Loffredo wrote:

That's exactly my main concern about such an idea that was the same 
supporting last proposal about EPP-over-HTTP submitted to this WG.


Making EPP completely stateful appeared,and still apeears, to me 
inefficient and in contrast with the trend in the design of REST services.


EPP *is* stateful by definition (see "Protocol Description" in RFC 5730), 
and that has implications beyond the fact that credentials are only 
presented to the server in the . The  also contains 
"handshake" information that tells the server which object and extension 
URIs the client understands, and that information governs the content of 
server responses during the session (e.g., which version of fee extension 
data is returned in the response to a billable operation).


Consequently, EPP would need to be completely revamped in order to 
facilitate stateless operation. All extensions relying on the  
handshake would need to be rewritten. The use of cookies (a 
well-established method to maintain server state over HTTP) seems like 
the lesser evil here.


Best regards,

Thomas

--
TANGO REGISTRY SERVICES® is a product of:
Knipp Medien und Kommunikation GmbH
Technologiepark Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9   Fax: +49 231 9703-200
D-44227 Dortmund   E-Mail: supp...@tango-rs.com
Germany

___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] Comments to the feedback about epp-over-http

[Gould, James]

Mario,

My responses are embedded below.

--

JG

[cid:image001.png@01D84363.253C6D10]

James Gould
Fellow Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com

From: Mario Loffredo 
Date: Tuesday, March 29, 2022 at 11:00 AM
To: James Gould , "regext@ietf.org" 
Subject: [EXTERNAL] Re: [regext] Comments to the feedback about epp-over-http


Hi James,
Il 29/03/2022 13:41, Gould, James ha scritto:
Mario,

My feedback is embedded below.

--

JG

[cid:image002.png@01D84363.253C6D10]

James Gould
Fellow Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com

From: Mario Loffredo 

Date: Monday, March 28, 2022 at 6:59 AM
To: James Gould , 
"regext@ietf.org" 

Subject: [EXTERNAL] Re: [regext] Comments to the feedback about epp-over-http


Hi James,

thanks for ypur quick reply.

Please find my comments below.
Il 25/03/2022 16:45, Gould, James ha scritto:
Mario,

For #4 “Cookie vs. HTTP Connection”, you asked the question “can you further 
clarify why we should opt for establishing the cookie at setup of the 
connection and how should it be possible? For example, what kind of request 
should be used to start the HTTP connection?”.

I implemented pluggable transports in the Verisign EPP SDK, which included 
HTTP, HTTPS, TCP, and TLS.  The Verisign EPP SDK does include a client 
interface as well as a server stub implementation, so I was able to see the 
transports from both sides.  Support for HTTP and HTTPS was removed once we 
stopped supporting EPP over HTTP.  The cookie is setup at the time of the HTTP 
or HTTPS connection.  There is no “request” that is used to start the HTTP 
connection, just like the case for TCP and TLS.  A network connection is made, 
which includes the underlying TLS handshake in the case of HTTPS and TLS and 
the cookie is setup for HTTP and HTTPS, and then the EPP application protocol 
rides on top of it.

It seems to me a very low-level implementation.

Sorry but I stiil don't understand how cookies are returned. They should be 
returned in an HTTP response that doesn't correspond to an HTTP request. 
Correct?

JG: HTTP is being defined as a transport for EPP, so it should be treated as 
such.  The setup and tear-down of the HTTP connection, includes the setup of 
the cookies that is used for HTTP session tracking.  When a connection is made 
to the EPP / HTTPS server, the TLS connection is first established via the 
TLS-handshake and the HTTP session is established via setup of the session 
cookie (e.g., JSESSIONID), which then enables the server to maintain state.  
State such as tracking failed login attempts and timeouts (idle / command / 
absolute), which will result in a drop in the HTTP session / connection when 
the login attempt threshold is exceeded.  At the application layer, a HTTPS 
connection is treated in the same way as a TLS connection, where the transport 
handles the framing and the connection state, and the application layer returns 
the EPP Greeting when the connection is setup and drops the connection with a 
EPP logout occurs or other EPP session conditions (e.g., exceeding timeouts).  
The HTTP session cookie is returned in all the HTTP responses.  There is 
absolutely no intermingling of the transport layer (HTTP) with the application 
layer (EPP) other than making a connection available to read and write framed 
packets and the ability to close the connection when needed.

If so, it seems to me uncompliant with what is stated in the first paragraph of 
Section 2.1 of RFC7230:

   HTTP is a stateless request/response protocol that operates by

   exchanging messages (Section 
3)
 across a reliable transport- or

   session-layer "connection" (Section 
6).
  An HTTP "client" is a

   program that establishes a connection to a server for the purpose of

   s

[regext] Fwd: Comments to the feedback about epp-over-http

[Matthias Pfeifer]

Hello Mario,


That said, AFAIK most of cloud providers don't allow to open low level 
sockets. You cannot use any >port except 80 and 443 (HTTP and HTTPS).  I 
imagine that they do that due to security reasons.


I am assuming that you are talking about services the cloud provider 
offers (btw, aws do tcp LB)?


If so, this should clearly stated out otherwise this could be confusing 
the technical community (which is in fact able to set up LBs nearly 
everywhere ;) )


In addition, from what I've read, TCP load balancers are intended for 

TCP traffic on well-known ports, >such as port 25 for SMTP.

Maybe some of the crappy outofthebox do that. In general TCP doesnt 
care. well-known port numbers are just convention.




On 29.03.22 11:26, Mario Loffredo wrote:

Hi Matthias,

thanks a lot for your interest and feedback.

Please find my comments inline prefixed with [ML]

Il 28/03/2022 23:40, Matthias Pfeifer ha scritto:

Hello,

i would also add a comment and questions:

>In the perspective of moving to the cloud to achieve scalability and
>  cost reduction, it should be further noted that application protocols
>   that aren't based on HTTP can be hardly migrated by using cloud-
>   native features, both on client side and server side. In addition,
>   from the security point of view, registries would be limited in terms
>   of the third-party security services available to protect their EPP
>   servers.

Can you please elaborate on

>"registries would be limited in terms of the third-party security 
services available to protect their EPP >servers."


Why?


And also on

>"and should be further noted that application protocols
>that aren't based on HTTP can be hardly migrated by using cloud-
>native features, both on client side and server side. " (since the 
cloudproviders offer tcp LB as well)


[ML] I added the text above following up the feedback provided by 
Gavin from CentralNIC who probably has already experienced some 
drawbacks in migrating to cloud his EPP server based on TCP.


@Gavin, you are surely more knowledgeable than me about this topic so 
if you wish to integrate my response, please feel free to do it.


My knowledge is limited to what I have learnt from the web.

That said, AFAIK most of cloud providers don't allow to open low level 
sockets. You cannot use any port except 80 and 443 (HTTP and HTTPS).  
I imagine that they do that due to security reasons.


Honestly don't know whether and how such a block can be bypassed.

In addition, from what I've read, TCP load balancers are intended for 
TCP traffic on well-known ports, such as port 25 for SMTP.


It seems quite clear to me that cloud platforms have been designed to 
natively support HTTP-based rather than TCP-based applications.




>While TCP is connection-oriented, HTTP is stateless but not session
>less.  This means that, by making an EPP session untied from the
>network connection, the EPP communication over HTTP is more flexible
>and efficient than over TCP.

They work on different Layers so IMHO its hard to make a comparsion 
in that way.


[ML] We can compare their effects on the functioning of an EPP server.

SInce in EPP-over-TCP, an EPP session is mapped on a TCP connection, 
the session gets lost if the TCP connection breaks down.


This doesn't happen in EPP-over-HTTP because the EPP session is mapped 
on an HTTP session that is a pure logical concept.


In addition, if the EPP session is maintained outside the EPP server 
(or a pool of backend servers in a load balancing scheme) , the EPP 
session doesn't get lost even when the server (or one of the servers 
that has previously started the EPP session) is stopped.





>While HTTP load balancers are very common and are quite often 
software, TCP load

> balancers are usually implemented in dedicated hardware

Whats the point? TCP and HTTP LBs are even used in combination


[ML] The point is that HTTP load balancers are more flexible than TCP 
load balancers because they work at a higher layer.


This is a depends-on field: This might be correct if you LB acts as a 
(reverse)proxy and can simply "more" that just routing packets (it is 
than an application in itself)





Let's suppose, for example, to have an HTTP server based on HTTP/2 and 
we want to move to QUIC.


I presume that such a change would require little to no effort on the 
HTTP load balancer.


Its also depends on. If someone has provide patches/upgrades for your 
device, probably yes.



I was wondering which problem do you exactly try to solve?

Bandwith issues on EPP services? :)

And the language should focus more on technical aspects and where the 
proposed tech solve concrete issues.



Best, Matthias







>An EPP server made up of a server pool must always operate with
>respect to the constraint that, once an EPP session is established,
>all the requests related to that session should be processed by the
>servers in the pool as long as the session is alive.

This is true in general and there

[regext] Fwd: Comments to the feedback about epp-over-http

[Mario Loffredo]

Hi Matthias,

Il 29/03/2022 18:54, Matthias Pfeifer ha scritto:

Hello Marion,

>That said, AFAIK most of cloud providers don't allow to open low 
level sockets. You cannot use any >port except 80 and 443 (HTTP and 
HTTPS).  I imagine that they do that due to security reasons.


I am assuming that you are talking about services the cloud provider 
offers (btw, aws do tcp LB)?


If so, this should clearly stated out otherwise this could be 
confusing the technical community (which is in fact able to set up LBs 
nearly everywhere ;) )


>In addition, from what I've read, TCP load balancers are intended for 
TCP traffic on well-known ports, >such as port 25 for SMTP.


Maybe some of the crappy outofthebox do that. In general TCP doesnt 
care. well-known port numbers are just convention.


Thanks a lot for the heads up.

Surely, we'll review the document to address your feedback.


Best,

Mario





On 29.03.22 11:26, Mario Loffredo wrote:

Hi Matthias,

thanks a lot for your interest and feedback.

Please find my comments inline prefixed with [ML]

Il 28/03/2022 23:40, Matthias Pfeifer ha scritto:

Hello,

i would also add a comment and questions:

>In the perspective of moving to the cloud to achieve scalability and
>  cost reduction, it should be further noted that application protocols
>   that aren't based on HTTP can be hardly migrated by using cloud-
>   native features, both on client side and server side. In addition,
>   from the security point of view, registries would be limited in 
terms

>   of the third-party security services available to protect their EPP
>   servers.

Can you please elaborate on

>"registries would be limited in terms of the third-party security 
services available to protect their EPP >servers."


Why?


And also on

>"and should be further noted that application protocols
>that aren't based on HTTP can be hardly migrated by using cloud-
>native features, both on client side and server side. " (since the 
cloudproviders offer tcp LB as well)


[ML] I added the text above following up the feedback provided by 
Gavin from CentralNIC who probably has already experienced some 
drawbacks in migrating to cloud his EPP server based on TCP.


@Gavin, you are surely more knowledgeable than me about this topic so 
if you wish to integrate my response, please feel free to do it.


My knowledge is limited to what I have learnt from the web.

That said, AFAIK most of cloud providers don't allow to open low 
level sockets. You cannot use any port except 80 and 443 (HTTP and 
HTTPS).  I imagine that they do that due to security reasons.


Honestly don't know whether and how such a block can be bypassed.

In addition, from what I've read, TCP load balancers are intended for 
TCP traffic on well-known ports, such as port 25 for SMTP.


It seems quite clear to me that cloud platforms have been designed to 
natively support HTTP-based rather than TCP-based applications.




>While TCP is connection-oriented, HTTP is stateless but not session
>less.  This means that, by making an EPP session untied from the
>network connection, the EPP communication over HTTP is more flexible
>and efficient than over TCP.

They work on different Layers so IMHO its hard to make a comparsion 
in that way.


[ML] We can compare their effects on the functioning of an EPP server.

SInce in EPP-over-TCP, an EPP session is mapped on a TCP connection, 
the session gets lost if the TCP connection breaks down.


This doesn't happen in EPP-over-HTTP because the EPP session is 
mapped on an HTTP session that is a pure logical concept.


In addition, if the EPP session is maintained outside the EPP server 
(or a pool of backend servers in a load balancing scheme) , the EPP 
session doesn't get lost even when the server (or one of the servers 
that has previously started the EPP session) is stopped.





>While HTTP load balancers are very common and are quite often 
software, TCP load

> balancers are usually implemented in dedicated hardware

Whats the point? TCP and HTTP LBs are even used in combination


[ML] The point is that HTTP load balancers are more flexible than TCP 
load balancers because they work at a higher layer.


This is a depends-on field: This might be correct if you LB acts as a 
(reverse)proxy and can simply "more" that just routing packets (it is 
than an application in itself)





Let's suppose, for example, to have an HTTP server based on HTTP/2 
and we want to move to QUIC.


I presume that such a change would require little to no effort on the 
HTTP load balancer.


Its also depends on. If someone has provide patches/upgrades for your 
device, probably yes.



I was wondering which problem do you exactly try to solve?

Bandwith issues on EPP services? :)

And the language should focus more on technical aspects and where the 
proposed tech solve concrete issues.



Best, Matthias







>An EPP server made up of a server pool must always operate with
>respect to the constraint that, once an EPP se