Subject: [regext] EPP and rate-limiting

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 17 Jan 2020 15:30:18 +0100

Sometimes, some clients are too talkative and, for instance, try
<create> too often to grab a domain. I'm not sure of the best error
code to return when such behaviour is detected. HTTP has 429 "Too Many
Requests" (RFC 6585) but I don't find a proper code in EPP. Any idea?

---

From: "Thomas Corte (TANGO support)" <[email-masked]>
Date: Fri, 17 Jan 2020 15:35:56 +0100

Hello Stephane,

> Requests" (RFC 6585) but I don't find a proper code in EPP. Any idea?

We're using 2502 ("Session limit exceeded; server closing connection") in
similar cases. And we're closing the connection, of course.

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES®
Knipp Medien und Kommunikation GmbH                    Thomas Corte
Technologiepark                             Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9                       Fax: +49 231 9703-200
D-44227 Dortmund                      E-Mail: [email-masked]
Germany

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 17 Jan 2020 14:43:02 +0000

> -----Original Message-----
> From: regext <[email-masked]> On Behalf Of Stephane
> Bortzmeyer
> Sent: Friday, January 17, 2020 9:30 AM
> To: [email-masked]
> Subject: [EXTERNAL] [regext] EPP and rate-limiting
> 
> Sometimes, some clients are too talkative and, for instance, try <create> too
> often to grab a domain. I'm not sure of the best error code to return when
> such behaviour is detected. HTTP has 429 "Too Many Requests" (RFC 6585)
> but I don't find a proper code in EPP. Any idea?

Perhaps 2002 ("Command use error")?

S:    <result code="2002">
S:      <msg>Command use error; too many requests</msg>
S:    </result>

Scott

---

From: "[email-masked]" <[email-masked]>
Date: Fri, 17 Jan 2020 15:49:41 +0100

On Fri, Jan 17, 2020 at 02:43:02PM +0000,
 Hollenbeck, Scott <[email-masked]> wrote 

> Perhaps 2002 ("Command use error")?

May be but the text in RFC 5730 limits it to "the command cannot
be executed due to a sequencing or context error".

---

From: "Thomas Corte (TANGO support)" <[email-masked]>
Date: Fri, 17 Jan 2020 16:04:20 +0100

Hello,

> be executed due to a sequencing or context error".

Admittedly, looking at this, our 2502 doesn't seem to be overly suitable
either:

      2502    "Session limit exceeded; server closing connection"

              This response code MUST be returned when a server receives
              a <login> command and the command cannot be completed
              because the client has exceeded a system-defined limit on
              the number of sessions that the client can establish.  It
              might be possible to establish a session by ending
              existing unused sessions and closing inactive connections.

(as this clearly refers to the number of open registry connections only).

I guess we interpreted "Session limit exceeded" in a liberal fashion, in
the sense that exceeding a rate limit means exceeding a limit *of* this
session, not the limit to the number of sessions.

Anyway, as the goal is to stop the client from further hitting the
server, closing the session (as opposed to let subsequent commands fail,
allowing the load on the server to continue) is IMHO a good way to react,
and in that case this seems to be the most suitable response code.

Best regards,

Thomas

---

From: "Gould, James" <[email-masked]>
Date: Fri, 17 Jan 2020 15:13:04 +0000

+1, there is no exact match, but 2502 is the closest match that also indicates that the connection will be closed.

-- 
 
JG

James Gould
Distinguished Engineer
[email-masked] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>

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

Verisign.com <http://verisigninc.com/>

On 1/17/20, 10:04 AM, "regext on behalf of Thomas Corte (TANGO support)" <[email-masked] on behalf of [email-masked]> wrote:

    Hello,

    

    

    
    Best regards,
    
    Thomas

    _______________________________________________
    regext mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/regext

---

From: "Patrick Mevzek" <[email-masked]>
Date: Fri, 17 Jan 2020 10:21:38 -0500

> Requests" (RFC 6585) but I don't find a proper code in EPP. Any idea?

If you look at what happens in the wild, you can come to the conclusion that there is probably no proper way to handle it in EPP... as many registries with this need do things in very different ways:

- closing the connection (2502) may be a tad too harsh
- some registries are using 2201 (Authorization error)
- some registries just delay the reply for some given amount of time, like if you are allowed one operation per second, you do one, if you do the other in 0.5s after the first one, then its reply will get delayed by 0.5s so that you are back to  "1 per second";
for example one registry will force a 2s delay on any domain:info reply on any domain the registrar does not own
- most often this is often policy, and not always very clearly documented by registries; there is also no real way for registrars to discover those things automatically (rate limiting can be per command or even per object, or depend on time of day, like create will be most severily rate limited in the time of day the registry does its deletion process).
- rules can also be very complicated, like for example one registry has this one:
"Limit:180 per 60 seconds per registrar" and "Limit:60,000 per day per registrar"
- some registries have "hitpoints" instead of rate-limiting: for any kind of EPP errors (which would cover your case of "registrar is trying to create a domain that already exists), you get one point, and after a given amount of points in a given amount of timeframe you get shutdown completely for some given amount of time; there is again nothing standard here, some registries doing that have their own EPP extension for the registrar to know how many hitpoints it has.

And the above list is far from being exhaustive...

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Francisco Obispo" <[email-masked]>
Date: Fri, 17 Jan 2020 12:06:36 -0800

> If you look at what happens in the wild, you can come to the conclusion that there is probably no proper way to handle it in EPP... as many registries with this need do things in very different way…

Hi *,

I agree with Patrick here, there are other tools the RY can use to handle situations like this.

In our EPP implementation we have some *reasonable limits* configured to deal with this type of situation, if the client is triggering a >=2000 error code and will continue to send the command, we basically delay the response as Patrick mentioned.

We’ve had a few interesting situations that we’ve observed. We had a registrar that was sending thousands of (epp `<hello />`) commands per second, this wasn’t affecting us as the `<hello>` processing doesn’t require a lot of work, but once we detected it,  a simple conversation with them was able to detect and fix a problem with their client implementation.

We have another situation where the client is sending a broken EPP `hello` command, triggering a syntax error, but that itself resets the timeout ticker, so they never notice it. We’ve contacted them about it and hopefully they’ll fix it.

Sending an *error* code requires the client to implement some sort of rate-limiting awareness making it non-trivial, whereas a delayed server response is handled automatically in most cases.

Best,

Francisco Obispo
VP - Technology
--------------------
Uniregistry

400 Spectrum Center Dr. Office 1660
Irvine, CA 92618

Office: +1 949 706 2300 x4202
[email-masked]

---

From: InterNetX - Marco Schrieck <[email-masked]>
Date: Mon, 20 Jan 2020 10:48:57 +0100

Hello,

Best rate limiting from my side is done by slowing down the requests.
It does not break the client even in other situations.

Regeards,
Marco