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

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

Its related to tcp sessions (with openbsd/carp/pfsync) you can easily 
build stateful cluster.

> 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.
>
with carp you can cus the session is handled there :)

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

You could the tcp-session requirement out and add a token based session 
system.

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

Well, we do not need OIDC for using JWT (also OIDC wouldnt solve here 
anything).

>>
>>
>> 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
>> regext@ietf.org
>> https://www.ietf.org/mailman/listinfo/regext
>