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

[Mario Loffredo <[e-mail]>]

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