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

[Mario Loffredo <[e-mail]>]

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

[ML] I would agree with you if the goal was to partially or completely 
refactor EPP but this is not the philosophy behind this proposal.

This proposal aims to preserve EPP commands semantics and makes use of 
HTTP as a mere transport protocol.

So what are the other practical methods using HTTP that way and 
preserving the EPP commands?

James proposed his own one but the authors'opinion is that it involves a 
very low-level approach.

Except for setting the session cookie, this proposal doesn't require to 
know any additional features used in the REST context.

Therefore, I think it would be quite easy to wrap the core of an EPP 
server to make it interact with both a TCP and an HTTP server.

With regard to the use of a JWT token, while reviewing the rdap-openid 
document the WG has already agreed that it is unfit to be used outside 
the borders of a trusted environment. As a consequence, Scott

has recently replaced tokens with sessions (the same mechanism used by 
epp-over-http) in the interaction between a generic RDAP client and an 
RDAP server and stated tokens to be exchanged between the RDAP server, 
acting as registered OpenID Connect client, and an OpenID Provider.

It should further be noted that not only the Login command lets the 
client authenticate but also negotiate the XML namespaces that will be 
valid during the EPP session. Therefore, the simple replacement of the 
EPP authentication with another HTTP-based mechanism wouldn't be 
sufficient.

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

[ML] Are you proposing to rewrite EPP :-) ?

I don't object to the idea but, IMHO, a general refactoring of EPP 
should also address other topics; for example, the use of JSON instead 
of XML so that extensions can be managed more easily.


Hope I addresed all your remarks.


Best,

Mario

>
>
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext

-- 
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: [phone]
Web: http://www.iit.cnr.it/mario.loffredo