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