[regext] Fwd: New Version Notification for draft-loffredo-regext-epp-over-http-00.txt

[Mario Loffredo]

Hi folks,

Just posted a draft about EPP over HTTP.  It aims to define rules for 
the EPP implementations leveraging HTTP due to its simplicity and ease 
of use.


The proposal preserves EPP commands semantics as HTTP is used merely for 
transportation.


The appendix includes possible strategies about how to implement load 
balancing in this context.



Even if EPP is largely implemented over TCP, some HTTP based 
implementations exist and a standardization would be advisable.


Feedback is welcome and appreciated.

Best,

Mario



 Messaggio Inoltrato 
Oggetto: 	New Version Notification for 
draft-loffredo-regext-epp-over-http-00.txt

Data:   Wed, 02 Mar 2022 03:16:34 -0800
Mittente:   internet-dra...@ietf.org
A: 	Jan Romanowski , Lorenzo Luconi Trombacchi 
, Lorenzo Trombacchi 
, Marcin Machnio , Mario 
Loffredo , Maurizio Martinelli 






A new version of I-D, draft-loffredo-regext-epp-over-http-00.txt
has been successfully submitted by Mario Loffredo and posted to the
IETF repository.

Name: draft-loffredo-regext-epp-over-http
Revision: 00
Title: Extensible Provisioning Protocol (EPP) Transport over HTTP
Document date: 2022-03-02
Group: Individual Submission
Pages: 15
URL: 
https://www.ietf.org/archive/id/draft-loffredo-regext-epp-over-http-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-loffredo-regext-epp-over-http/
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-loffredo-regext-epp-over-http



Abstract:
This document describes how the Extensible Provisioning Protocol
(EPP) is mapped over the Hypertext Transfer Protocol (HTTP). This
mapping requires the use of the Transport Layer Security (TLS)
protocol to protect information exchanged between an EPP client and
an EPP server.



The IETF Secretariat

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

Re: [regext] Fwd: New Version Notification for draft-loffredo-regext-epp-over-http-00.txt

[Gould, James]

Mario,

Thank you for sharing the draft.  We implemented EPP/HTTPS in parallel with 
EPP/TLS a while back for many years.  In the end, there were very few 
registrars that chose to use EPP/HTTPS, so it was shutdown.  I’m not sure at 
this point whether there is hunger from the registrars to implement EPP/HTTPS.


In reviewing the draft, one difference with our EPP/HTTPS implementation is 
that establishing the HTTPS session was separate from establishing the EPP 
session, like what is done with TLS.  The HTTPS session was established with 
returning the greeting, and the only EPP command that impacted the HTTPS 
session was the logout command by dropping the HTTPS session, like the logout 
command dropping the TLS connection on the server-side.  By not mixing the EPP 
commands with the underlying transport, it was possible to configure the 
transport (TLS or HTTPS) on the client-side, as was done in our EPP SDK.  My 
recommendation is to ensure to keep the transport purely a transport and not 
have the login command intermingled with the HTTPS session.  One other 
difference was the use of the media type “text/xml” instead of defining a new 
one with “application/epp+xml”.  The EPP packet length was set with the 
“Content-Length” header along with relying on the HTTP keep-alive, which is 
consistent.

--

JG

[cid:image001.png@01D82E0B.A9E53B40]

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: Wednesday, March 2, 2022 at 6:47 AM
To: "regext@ietf.org" 
Subject: [EXTERNAL] [regext] Fwd: New Version Notification for 
draft-loffredo-regext-epp-over-http-00.txt


Hi folks,

Just posted a draft about EPP over HTTP.  It aims to define rules for the EPP 
implementations leveraging HTTP due to its simplicity and ease of use.

The proposal preserves EPP commands semantics as HTTP is used merely for 
transportation.

The appendix includes possible strategies about how to implement load balancing 
in this context.



Even if EPP is largely implemented over TCP, some HTTP based implementations 
exist and a standardization would be advisable.

Feedback is welcome and appreciated.

Best,

Mario


 Messaggio Inoltrato 
Oggetto:

New Version Notification for draft-loffredo-regext-epp-over-http-00.txt

Data:

Wed, 02 Mar 2022 03:16:34 -0800

Mittente:

internet-dra...@ietf.org

A:

Jan Romanowski , Lorenzo 
Luconi Trombacchi 
, Lorenzo 
Trombacchi , 
Marcin Machnio , Mario Loffredo 
, Maurizio 
Martinelli 





A new version of I-D, draft-loffredo-regext-epp-over-http-00.txt
has been successfully submitted by Mario Loffredo and posted to the
IETF repository.

Name: draft-loffredo-regext-epp-over-http
Revision: 00
Title: Extensible Provisioning Protocol (EPP) Transport over HTTP
Document date: 2022-03-02
Group: Individual Submission
Pages: 15
URL: 
https://www.ietf.org/archive/id/draft-loffredo-regext-epp-over-http-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-loffredo-regext-epp-over-http/
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-loffredo-regext-epp-over-http


Abstract:
This document describes how the Extensible Provisioning Protocol
(EPP) is mapped over the Hypertext Transfer Protocol (HTTP). This
mapping requires the use of the Transport Layer Security (TLS)
protocol to protect information exchanged between an EPP client and
an EPP server.



The IETF Secretariat

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

Re: [regext] Fwd: New Version Notification for draft-loffredo-regext-epp-over-http-00.txt

[Gavin Brown]

Hi Jim and Mario,

> On 2 Mar 2022, at 13:01, Gould, James  wrote:
> 
> Mario,
>  
> Thank you for sharing the draft.  We implemented EPP/HTTPS in parallel with 
> EPP/TLS a while back for many years.  In the end, there were very few 
> registrars that chose to use EPP/HTTPS, so it was shutdown.  I’m not sure at 
> this point whether there is hunger from the registrars to implement 
> EPP/HTTPS. 

At least one registrar (DNSimple) had a go at writing an EPP over HTTPS spec a 
few years ago, regrettably it didn't get very far (for which I am partly to 
blame):

https://github.com/aeden/epp-over-http

I think now is a good time to reassess the appetite for EPP over HTTPS. As we 
all move to the cloud, where almost everything uses HTTP as a substrate, it 
becomes harder to deploy protocols that aren't based on HTTP in a cloud-native 
way, both on the client side and the server side.

From the security point of view, while EPP has a relatively small attack 
surface, if you're a registry, you're somewhat limited in terms of the 
third-party security services you can deploy to protect it. The same is true of 
whois, but at least we know that whois will one day be replaced by RDAP, which 
is HTTP based. I look forward to one day putting my entire infrastructure 
behind $YOUR_CLOUD_BASED_REVERSE_PROXY_OF_CHOICE - which necessitates retiring 
(or at least deprecating) ports 43 and 700.

G.

--
Gavin Brown
Head of Registry Services
CentralNic Group plc (LSE:CNIC)
https://centralnicregistry.com

Cal: http://cnic.link/gbcalendar

CentralNic Group plc is a company registered in England and Wales with company 
number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 
6BR.

https://www.centralnic.com

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

Re: [regext] Fwd: New Version Notification for draft-loffredo-regext-epp-over-http-00.txt

[Hollenbeck, Scott]

If there are implementations out there, I think this is worth doing.



Scott



From: regext  On Behalf Of Mario Loffredo
Sent: Wednesday, March 2, 2022 6:45 AM
To: regext@ietf.org
Subject: [EXTERNAL] [regext] Fwd: New Version Notification for 
draft-loffredo-regext-epp-over-http-00.txt



Caution: This email originated from outside the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Hi folks,

Just posted a draft about EPP over HTTP.  It aims to define rules for the EPP 
implementations leveraging HTTP due to its simplicity and ease of use.

The proposal preserves EPP commands semantics as HTTP is used merely for 
transportation.

The appendix includes possible strategies about how to implement load balancing 
in this context.



Even if EPP is largely implemented over TCP, some HTTP based implementations 
exist and a standardization would be advisable.

Feedback is welcome and appreciated.

Best,

Mario



 Messaggio Inoltrato 

Oggetto:

New Version Notification for draft-loffredo-regext-epp-over-http-00.txt

Data:

Wed, 02 Mar 2022 03:16:34 -0800

Mittente:

internet-dra...@ietf.org

A:

Jan Romanowski , Lorenzo 
Luconi Trombacchi 
, Lorenzo 
Trombacchi , 
Marcin Machnio , Mario Loffredo 
, Maurizio 
Martinelli 





A new version of I-D, draft-loffredo-regext-epp-over-http-00.txt
has been successfully submitted by Mario Loffredo and posted to the
IETF repository.

Name: draft-loffredo-regext-epp-over-http
Revision: 00
Title: Extensible Provisioning Protocol (EPP) Transport over HTTP
Document date: 2022-03-02
Group: Individual Submission
Pages: 15
URL: 
https://www.ietf.org/archive/id/draft-loffredo-regext-epp-over-http-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-loffredo-regext-epp-over-http/
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-loffredo-regext-epp-over-http


Abstract:
This document describes how the Extensible Provisioning Protocol
(EPP) is mapped over the Hypertext Transfer Protocol (HTTP). This
mapping requires the use of the Transport Layer Security (TLS)
protocol to protect information exchanged between an EPP client and
an EPP server.



The IETF Secretariat



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

Re: [regext] Fwd: New Version Notification for draft-loffredo-regext-epp-over-http-00.txt

[Mario Loffredo]

Hi James,

thanks a lot for your feedback.

My comments are below.

Il 02/03/2022 14:01, Gould, James ha scritto:


Mario,

Thank you for sharing the draft.  We implemented EPP/HTTPS in parallel 
with EPP/TLS a while back for many years.  In the end, there were very 
few registrars that chose to use EPP/HTTPS, so it was shutdown.  I’m 
not sure at this point whether there is hunger from the registrars to 
implement EPP/HTTPS.


[ML] Maybe one reason against the implementation of EPP over HTTP thus 
far has been the lack of a specification about it :-)


I believe that, especially for those registries accostumed to develop 
their systems in-house, EPP over HTTP can be more straightforward than 
EPP over TCP.


Implementers are normally more knowledgeable about REST programming than 
TCP sockets and web services can benefit from a lot of open-source 
software managing automatically some features and providing support for 
many others.


In reviewing the draft, one difference with our EPP/HTTPS 
implementation is that establishing the HTTPS session was separate 
from establishing the EPP session, like what is done with TLS.  The 
HTTPS session was established with returning the greeting, and the 
only EPP command that impacted the HTTPS session was the logout 
command by dropping the HTTPS session, like the logout command 
dropping the TLS connection on the server-side.  By not mixing the EPP 
commands with the underlying transport, it was possible to configure 
the transport (TLS or HTTPS) on the client-side, as was done in our 
EPP SDK.  My recommendation is to ensure to keep the transport purely 
a transport and not have the login command intermingled with the HTTPS 
session.


[ML]  My opinion is that the approach described in the draft is still 
compliant with RFC 5730.


Section 2.9.1 states that the EPP command starting a session is  
which appears to me also consistent with the fact that every session in 
a REST service is established after a successful authentication phase.


Neither It seems to me that the proposal mixes the EPP commands with the 
underlying transport. On the contrary, mapping an EPP session onto an 
HTTP session makes the application layer completely independent on the 
physical layer, for sure more independent than EPP over TCP.
One other difference was the use of the media type “text/xml” instead 
of defining a new one with “application/epp+xml”.
[ML] Just realized that the "application/epp+xml" was already defined by 
RFC 5730. I missed that . I'll remove the section regarding the media 
type from the document.
The EPP packet length was set with the “Content-Length” header along 
with relying on the HTTP keep-alive, which is consistent.


[ML] Don't think that strictly relying on the HTTP keep-alive feature is 
good, especially in a load balancing scheme.


Anyway, I have booked a slot at next meeting to present the proposal. So 
we can have time for a live discussion.



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: *Wednesday, March 2, 2022 at 6:47 AM
*To: *"regext@ietf.org" 
*Subject: *[EXTERNAL] [regext] Fwd: New Version Notification for 
draft-loffredo-regext-epp-over-http-00.txt


Hi folks,

Just posted a draft about EPP over HTTP.  It aims to define rules for 
the EPP implementations leveraging HTTP due to its simplicity and ease 
of use.


The proposal preserves EPP commands semantics as HTTP is used merely 
for transportation.


The appendix includes possible strategies about how to implement load 
balancing in this context.


Even if EPP is largely implemented over TCP, some HTTP based 
implementations exist and a standardization would be advisable.


Feedback is welcome and appreciated.

Best,

Mario



 Messaggio Inoltrato 

*Oggetto: *



New Version Notification for draft-loffredo-regext-epp-over-http-00.txt

*Data: *



Wed, 02 Mar 2022 03:16:34 -0800

*Mittente: *



internet-dra...@ietf.org

*A: *



Jan Romanowski  
, Lorenzo Luconi Trombacchi 
 , 
Lorenzo Trombacchi  
, Marcin Machnio  
, Mario Loffredo  
, Maurizio Martinelli 
 





A new version of I-D, draft-loffredo-regext-epp-over-http-00.txt
has been successfully submitted by Mario Loffredo and posted to the
IETF repository.

Name: draft-loffredo-regext-epp-over-http
Revision: 00
Title: Extensible Provisioning Protocol (EPP) Transport over HTTP
Document date: 2022-03-02
Group: Individual Submission
Pages: 15
URL: 
https://www.ietf.org/archive/id/draft-loffredo-regext-epp-over-http-00.txt 

Re: [regext] Fwd: New Version Notification for draft-loffredo-regext-epp-over-http-00.txt

[Mario Loffredo]

Hi Gavin,

please find my comments below.

Il 02/03/2022 15:29, Gavin Brown ha scritto:

Hi Jim and Mario,


On 2 Mar 2022, at 13:01, Gould, James  wrote:

Mario,
  
Thank you for sharing the draft.  We implemented EPP/HTTPS in parallel with EPP/TLS a while back for many years.  In the end, there were very few registrars that chose to use EPP/HTTPS, so it was shutdown.  I’m not sure at this point whether there is hunger from the registrars to implement EPP/HTTPS.

At least one registrar (DNSimple) had a go at writing an EPP over HTTPS spec a 
few years ago, regrettably it didn't get very far (for which I am partly to 
blame):

https://github.com/aeden/epp-over-http


I provided my feedback about that proposal. My main concern was about 
the fact that every EPP command required the registrar to be previously 
authenticated. It appeared to me inefficient iin general and 
particularly when a massive amount of request are sent to the server in 
a very short time.


In addition, it didn't seem to me in line with the trend in REST 
services to allow for work sessions consequent to a user authentication 
phase (see rdap-openid ).




I think now is a good time to reassess the appetite for EPP over HTTPS. As we 
all move to the cloud, where almost everything uses HTTP as a substrate, it 
becomes harder to deploy protocols that aren't based on HTTP in a cloud-native 
way, both on the client side and the server side.

 From the security point of view, while EPP has a relatively small attack 
surface, if you're a registry, you're somewhat limited in terms of the 
third-party security services you can deploy to protect it. The same is true of 
whois, but at least we know that whois will one day be replaced by RDAP, which 
is HTTP based. I look forward to one day putting my entire infrastructure 
behind $YOUR_CLOUD_BASED_REVERSE_PROXY_OF_CHOICE - which necessitates retiring 
(or at least deprecating) ports 43 and 700.


Thanks a lot for the hint about deploying EPP on a cloud environment. 
Both the registries implementing the draft haven't considered this 
scenario.  I'll include it in section 2 ;-)



Best,

Mario




G.

--
Gavin Brown
Head of Registry Services
CentralNic Group plc (LSE:CNIC)
https://centralnicregistry.com

Cal: http://cnic.link/gbcalendar

CentralNic Group plc is a company registered in England and Wales with company 
number 8576358. Registered Offices: Saddlers House, Gutter Lane, London EC2V 
6BR.

https://www.centralnic.com

___
regext mailing list
regext@ietf.org
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: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo

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