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

[Mario Loffredo]

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?


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


Anyway, the approach normally followed by every HTTP implementer 
leverages the services provided by an application server that 
incorporates an HTTP server.


You don't need to manage HTTP connections, HTTP resquest/response 
marhsalling/unmarshalling and other low-level details. You just need to 
focus on the core of your server.


Similarly, on the other side side, after having configured an HTTP 
client instance, a client simply builds and sends an HTTP request, and  
then receives and processes an HTTP response.


If there is a HTTP transport for EPP, then it should be purely a 
transport and not intermingle with the application protocol.  There is 
no need to directly tie a HTTP session with the established EPP 
session.  By keeping them separate, it makes it much easier for the 
client and the server to have pluggable transports, where the 
processing of the EPP commands including the hello, login, and logout 
treat the transport as simply a connection with no intermingling of 
session management.


If it means that you have to reimplement what has commonly been used for 
years, it isn't clear to me how it could be much easier. On the 
contrary, it seems to me much trickier, especially if you implement 
EPP-over-HTTP from scratch.


If the goal is using the same approach for mapping every transport layer 
without considering the peculiarites of each transport protocol and the 
technology the implementers are accostumed to use to deal with them, it 
doesn't make sense to me.


For example, I cannot figure out how HTTP load balancing could support 
your solution.



Best,

Mario


--

JG




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



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

Verisign.com 

*From: *regext  on behalf of Mario Loffredo 


*Date: *Friday, March 25, 2022 at 11:01 AM
*To: *"regext@ietf.org" 
*Subject: *[EXTERNAL] [regext] Comments to the feedback about 
epp-over-http


Hi folks,

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


*1) Draft title*

Ulrich suggested to call the document EPP-over-HTTPS.

I replied that the name was assigned to be consistent with RFC5734, 
i.e. EPP-over-TCP.


SImilarly to RFC5734, the draft states, first in the abstract and then 
in the security considerations, that TLS is required.


That being said, the authors don't object to renaming the dcocument 
EPP-over-HTTPS if the WG agrees.


*2)  Cookies*

Jim (Reed) asked why cookies should be used in this case.

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 :-)


.it and .pl have been using this method since the beginning and the 
registrars, after being informed 

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

[Matthias Pfeifer]

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)



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



>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

>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

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 (REST) API I would prefer token(JWT) based model in general. Login / 
Logout including session management would add (at least a little bit) 
more complexity and probably CORS issues on client side.



Why we don't chase the transport protocol restriction out of EPP in 
general? :)



Thx and best, Matthias




On 28.03.22 12:56, Mario Loffredo wrote:
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 :-)


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