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

[Alexander Mayrhofer]

Guys,

i’ve yet to read up on the latest version of the document (and I will do so). 
However, as a quick comment:


  1.  Establish TCP connection
  2.  Establish TLS session via TLS-handshake
  3.  Establish HTTP session via setup of the HTTP session cookie (e.g., 
JSESSIONID)
  4.  Return EPP Greeting in framed HTTP response with the session cookie 
(e.g., JSESSIONID)
  5.  Support HTTP requests in the form of framed EPP commands that are 
returned in HTTP responses in the form of framed EPP responses.

[AM] Please please let’s not assume that HTTP is TCP. The protocol (imho MUST) 
also work over HTTP/3, which uses QUIC, which in turn uses UDP. However, the 
approach of using a session ID for identifying the equivalent of a TCP 
connection in “plain” EPP is still valid, and I support that design choice.



More feedback to come once I manage to squeeze in time to read through the 
draft more carefully.



Best,

Alex



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

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

[Mario Loffredo]

Hi James,

my comments are embedded below.


Il 29/03/2022 17:50, Gould, James ha scritto:


Mario,

My responses are embedded below.

--

JG




*James Gould
*Fellow Engineer
jgo...@verisign.com 



703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com 

*From: *Mario Loffredo 
*Date: *Tuesday, March 29, 2022 at 11:00 AM
*To: *James Gould , "regext@ietf.org" 

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


Hi James,

Il 29/03/2022 13:41, Gould, James ha scritto:

Mario,

My feedback is embedded below.

-- 


JG




*James Gould
*Fellow Engineer
jgo...@verisign.com


703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com



*From: *Mario Loffredo 

*Date: *Monday, March 28, 2022 at 6:59 AM
*To: *James Gould 
, "regext@ietf.org"
  
*Subject: *[EXTERNAL] Re: [regext] Comments to the feedback about
epp-over-http

Hi James,

thanks for ypur quick reply.

Please find my comments below.

Il 25/03/2022 16:45, Gould, James ha scritto:

Mario,

For #4 “Cookie vs. HTTP Connection”, you asked the question
“can you further clarify why we should opt for establishing
the cookie at setup of the connection and how should it be
possible? For example, what kind of request should be used to
start the HTTP connection?”.

I implemented pluggable transports in the Verisign EPP SDK,
which included HTTP, HTTPS, TCP, and TLS.  The Verisign EPP
SDK does include a client interface as well as a server stub
implementation, so I was able to see the transports from both
sides.  Support for HTTP and HTTPS was removed once we stopped
supporting EPP over HTTP.  The cookie is setup at the time of
the HTTP or HTTPS connection.  There is no “request” that is
used to start the HTTP connection, just like the case for TCP
and TLS.  A network connection is made, which includes the
underlying TLS handshake in the case of HTTPS and TLS and the
cookie is setup for HTTP and HTTPS, and then the EPP
application protocol rides on top of it.

It seems to me a very low-level implementation.

Sorry but I stiil don't understand how cookies are returned. They
should be returned in an HTTP response that doesn't correspond to
an HTTP request. Correct?

JG: HTTP is being defined as a transport for EPP, so it should be
treated as such.  The setup and tear-down of the HTTP connection,
includes the setup of the cookies that is used for HTTP session
tracking.  When a connection is made to the EPP / HTTPS server,
the TLS connection is first established via the TLS-handshake and
the HTTP session is established via setup of the session cookie
(e.g., JSESSIONID), which then enables the server to maintain
state.  State such as tracking failed login attempts and timeouts
(idle / command / absolute), which will result in a drop in the
HTTP session / connection when the login attempt threshold is
exceeded.  At the application layer, a HTTPS connection is treated
in the same way as a TLS connection, where the transport handles
the framing and the connection state, and the application layer
returns the EPP Greeting when the connection is setup and drops
the connection with a EPP logout occurs or other EPP session
conditions (e.g., exceeding timeouts).  The HTTP session cookie is
returned in all the HTTP responses.  There is absolutely no
intermingling of the transport layer (HTTP) with the application
layer (EPP) other than making a connection available to read and
write framed packets and the ability to close the connection when
needed.

If so, it seems to me uncompliant with what is stated in the first
paragraph of Section 2.1 of RFC7230:

    HTTP is a stateless request/response protocol that operates by

    exchanging messages (Section 3  
)
 across a reliable transport- or

    session-layer "connection" (Section 6  

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

[Gould, James]

Mario,

I include my feedback embedded below.

--

JG

[cid:image001.png@01D8441C.E658EC30]

James Gould
Fellow Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com

From: Mario Loffredo 
Date: Wednesday, March 30, 2022 at 8:28 AM
To: James Gould , "regext@ietf.org" 
Subject: [EXTERNAL] Re: [regext] Comments to the feedback about epp-over-http


Hi James,

my comments are embedded below.


Il 29/03/2022 17:50, Gould, James ha scritto:
Mario,

My responses are embedded below.

--

JG

[cid:image002.png@01D8441C.E658EC30]

James Gould
Fellow Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com

From: Mario Loffredo 

Date: Tuesday, March 29, 2022 at 11:00 AM
To: James Gould , 
"regext@ietf.org" 

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


Hi James,
Il 29/03/2022 13:41, Gould, James ha scritto:
Mario,

My feedback is embedded below.

--

JG

[cid:image003.png@01D8441C.E658EC30]

James Gould
Fellow Engineer
jgo...@verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com

From: Mario Loffredo 

Date: Monday, March 28, 2022 at 6:59 AM
To: James Gould , 
"regext@ietf.org" 

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


Hi James,

thanks for ypur quick reply.

Please find my comments below.
Il 25/03/2022 16:45, Gould, James ha scritto:
Mario,

For #4 “Cookie vs. HTTP Connection”, you asked the question “can you further 
clarify why we should opt for establishing the cookie at setup of the 
connection and how should it be possible? For example, what kind of request 
should be used to start the HTTP connection?”.

I implemented pluggable transports in the Verisign EPP SDK, which included 
HTTP, HTTPS, TCP, and TLS.  The Verisign EPP SDK does include a client 
interface as well as a server stub implementation, so I was able to see the 
transports from both sides.  Support for HTTP and HTTPS was removed once we 
stopped supporting EPP over HTTP.  The cookie is setup at the time of the HTTP 
or HTTPS connection.  There is no “request” that is used to start the HTTP 
connection, just like the case for TCP and TLS.  A network connection is made, 
which includes the underlying TLS handshake in the case of HTTPS and TLS and 
the cookie is setup for HTTP and HTTPS, and then the EPP application protocol 
rides on top of it.

It seems to me a very low-level implementation.

Sorry but I stiil don't understand how cookies are returned. They should be 
returned in an HTTP response that doesn't correspond to an HTTP request. 
Correct?

JG: HTTP is being defined as a transport for EPP, so it should be treated as 
such.  The setup and tear-down of the HTTP connection, includes the setup of 
the cookies that is used for HTTP session tracking.  When a connection is made 
to the EPP / HTTPS server, the TLS connection is first established via the 
TLS-handshake and the HTTP session is established via setup of the session 
cookie (e.g., JSESSIONID), which then enables the server to maintain state.  
State such as tracking failed login attempts and timeouts (idle / command / 
absolute), which will result in a drop in the HTTP session / connection when 
the login attempt threshold is exceeded.  At the application layer, a HTTPS 
connection is treated in the same way as a TLS connection, where the transport 
handles the framing and the connection state, and the application layer returns 
the EPP Greeting when the connection is setup and drops the connection with a 
EPP logout occurs or other EPP session conditions (e.g., exceeding timeouts).  
The HTTP session cookie is returned in all the HTTP responses.  There is 
absolutely no intermingling of the transport layer (HTTP) with the application 
layer (EPP) other than making a connection available to read and write framed 
packets and the ability to close the connection when needed.

If so, it seems to me uncompliant with what is stated in the first paragraph of 
Section 2.1 of RFC7230:

   HTTP is a stateless request/response protocol that operates by

   

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

[Mario Loffredo]

Hi James,

here are again my responses below.

Il 30/03/2022 15:59, Gould, James ha scritto:


Mario,

I include my feedback embedded below.

--

JG




*James Gould
*Fellow Engineer
jgo...@verisign.com 



703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com 

*From: *Mario Loffredo 
*Date: *Wednesday, March 30, 2022 at 8:28 AM
*To: *James Gould , "regext@ietf.org" 

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


Hi James,

my comments are embedded below.

Il 29/03/2022 17:50, Gould, James ha scritto:

Mario,

My responses are embedded below.

-- 


JG




*James Gould
*Fellow Engineer
jgo...@verisign.com


703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com



*From: *Mario Loffredo 

*Date: *Tuesday, March 29, 2022 at 11:00 AM
*To: *James Gould 
, "regext@ietf.org"
  
*Subject: *[EXTERNAL] Re: [regext] Comments to the feedback about
epp-over-http

Hi James,

Il 29/03/2022 13:41, Gould, James ha scritto:

Mario,

My feedback is embedded below.

-- 


JG




*James Gould
*Fellow Engineer
jgo...@verisign.com



703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com



*From: *Mario Loffredo 

*Date: *Monday, March 28, 2022 at 6:59 AM
*To: *James Gould 
, "regext@ietf.org"
 

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

Hi James,

thanks for ypur quick reply.

Please find my comments below.

Il 25/03/2022 16:45, Gould, James ha scritto:

Mario,

For #4 “Cookie vs. HTTP Connection”, you asked the
question “can you further clarify why we should opt for
establishing the cookie at setup of the connection and how
should it be possible? For example, what kind of request
should be used to start the HTTP connection?”.

I implemented pluggable transports in the Verisign EPP
SDK, which included HTTP, HTTPS, TCP, and TLS.  The
Verisign EPP SDK does include a client interface as well
as a server stub implementation, so I was able to see the
transports from both sides.  Support for HTTP and HTTPS
was removed once we stopped supporting EPP over HTTP.  The
cookie is setup at the time of the HTTP or HTTPS
connection.  There is no “request” that is used to start
the HTTP connection, just like the case for TCP and TLS. 
A network connection is made, which includes the
underlying TLS handshake in the case of HTTPS and TLS and
the cookie is setup for HTTP and HTTPS, and then the EPP
application protocol rides on top of it.

It seems to me a very low-level implementation.

Sorry but I stiil don't understand how cookies are returned.
They should be returned in an HTTP response that doesn't
correspond to an HTTP request. Correct?

JG: HTTP is being defined as a transport for EPP, so it should
be treated as such.  The setup and tear-down of the HTTP
connection, includes the setup of the cookies that is used for
HTTP session tracking. When a connection is made to the EPP /
HTTPS server, the TLS connection is first established via the
TLS-handshake and the HTTP session is established via setup of
the session cookie (e.g., JSESSIONID), which then enables the
server to maintain state.  State such as tracking failed login
attempts and timeouts (idle / command / absolute), which will
result in a drop in the HTTP session / connection when the
login attempt threshold is exceeded.  At the application
layer, a HTTPS connection is treated in the same way as a TLS
connection, where the transport handles the framing and the