Re: [regext] EPP and rate-limiting

"Gould, James" <jgould@verisign.com> Fri, 17 January 2020 15:13 UTC

Return-Path: <jgould@verisign.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7606312002F for <regext@ietfa.amsl.com>; Fri, 17 Jan 2020 07:13:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uGx8dbvkK92R for <regext@ietfa.amsl.com>; Fri, 17 Jan 2020 07:13:06 -0800 (PST)
Received: from mail5.verisign.com (mail5.verisign.com [69.58.187.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A693120018 for <regext@ietf.org>; Fri, 17 Jan 2020 07:13:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=3728; q=dns/txt; s=VRSN; t=1579273987; h=from:to:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=vtQ7XIpKc13cE/XAzs2zs2OrB2v0CIF7mgmRfvIm4C4=; b=qHRKI6cH+79uw+fQTr8FTeMgC/G0RL9WAAkNwSFHN1Kl87Z7rMCrwuwk is8BtotArd0jQEc/pTr2wlQaed67sQ2Ts9vo1skxLkZ9dHrhnnOqyHo98 27I5PldGHAcz+LveCnH4lM+Fh96TXigpvCeuYkW+HDBXMOZMKEZNRG4pM PaCW3dLVfsgrWXPYL39FoKpPg6dgLivClXLbQ+DHEcAjRTorvGUcVpU0P jl09Yow0l10Alcus6etIv82Cs2TRVQw6WWcjmw755dKJM6fzyH3lIBnD0 MIFOJdhwjgOmqJrdoGGB3G150IqXWfT9cOrrDzGtDcJoidNAQb+w7r8B2 w==;
IronPort-SDR: Qx3sYLrelYA6OoUwHolUUmsGpJeJX4ZXK4iFDV8gn5C1qV/JQxrdUGCzcONqi2TP6jJbCjS+zu Xr+ChVHuVviQeO4zxoGJ9WsHKkLl4KGv7y6bCdT1QHO9Wq4+lmbPTFsJvk1gtU9CjvRUZXcKqq 1pvv9VjwseXp+KjZNz8Hl1hQMspgejVI43uHgaBiNJKt1V7lyFyeeKOPxdcGXwsfg8Vdfeirc0 vpFFNG2AGiyWJ5pBajbhnMb5pNksM1zAqdyp7T5sKHc+C2OB3XsBhy83RyQluCLO213/fdLUQx lLc=
X-IronPort-AV: E=Sophos;i="5.70,330,1574139600"; d="scan'208";a="458757"
IronPort-PHdr: 9a23:9ptJFxR0kl5fvaSgNzImB0xCrtpsv+yvbD5Q0YIujvd0So/mwa67ZByBt8tkgFKBZ4jH8fUM07OQ7/m8HzRfqsnY+DBaKdoQDkRD0Z1X1yUbQ+e9QXXhK/DrayFoVO9jb3RCu0+BDE5OBczlbEfTqHDhpRQbGxH4KBYnbr+tQt2agMu4zf299IPOaAtUmjW9falyLBKrpgnNq8Uam4RvJrs+xxfTvndFeetayGF1KVmOmxrw+tq88IRs/ihNtf8t7dJMXbn/c68lUbFWETMqPnwv6sb2rxfDVwyP5nUdUmUSjBVFBhXO4Q/5UJnsrCb0r/Jx1yaGM8L4S7A0Qimi4LxwSBD0kicHNiU2/3/Rh8dtka9UuhOhpxh4w47JfIGYMed1c63Bcd8GQ2dKQ91cXDJdDIyic4QPDvIBPedGoIn7u1sOtga1CQ21CO/y1jNEmnr60Ksn2OojDA7GxhQtEdIQvnrJsNX7OqQcUe63w6bGzDXMc/xY1jjm5YjUaR8hpO2AUa5qfMfTz0QkCgPLjk+XqYzgJz6Z2OUDs2+G7+pkSO2jk3MspQVrrTiq2MgskYfFjZ8Sx1DG+iV5x5s1JdmlR0Ngf96rDoFQtyCBN4t3TcMiRXtktzo9yr0DoJO2ejUBxpogxx7acfOHco6I7wr9VOmPOzd4hWlleLOwhxa08EigzPHzWtOo31ZNqypJitjMuW4R1xzd8MSHTeF9/kin1D2S1A7T8vlJLV0omabBNpIswLA9moAOvUnDECL6gkr7gayOekk55uSk8fnrb7f6qpOGKoN5hQLzPr4zlsG8Geg4PBYBUmuH9em50bDs5070TbFRgfAznKTVro3VKMUeq6GiBwJY04Qu5hOxAjqo0tkXgH8KJ09fdh2dlYjmIVTOLej9Dfe4nlujji9mx+vDPr39GpXNKWXDkKv5cbZ99UFczA0zwMhC6pxIEr8NPfL8VFf+utPZEhM1Lha4w/j7B9V6zIMeQXiDDbWEP6/Ir1+I/PkvI++WaIAJvzb9LuAp5//ojXAnhV8QZbSl0YcNZHylHPlrLV+VbWfsj9oPC2sHsQkzQPTviFKYUD5TY3iyX7g75jE+EI+mD4jDRoewgLyFwSi2BYNWaX5cClCNCnfodoqEW/EWZC2OJc9hlyQIVaK9RI85yRGuqAj6xqJ5IOrU/S0YsIjs1MNv6+DNkhEy7yB0ANqG3mGOSWF0n3sIRycs0K9iv0N30k2D3rRgg/xECdxT4OtEUh0kOp7T0eN7BMzyVxnAftiXVFamTM+qATYrTtI+kJcyZBM3J9WlixnYlwGtGaMY3/y3Lbob1erHwmDpINxhijyOgJUhiFwvWY1kMne6i4Z88QnLH8jFnhPd3+yweKsRzDLl9WqfwyyJpk4SGFpqXKrITWw3Z0bKo5L+/EyUHJG0DrFyeCRG1MqObuNoY9jklh8OEPXsP8nab0qvln2xHheHwPWHa4+8KDZV5znUFEVRy1Nbxn2BLwVrQ375+28=
X-IPAS-Result: A2FJAwAmziFe/zCZrQpiAx0BAQEJAREFBQGBe4MVgTEKhAeQeyWDbpcNFxsKCQEBAQEBAQEBAQcBGAsMAQECg3lFAheCGDgTAgMBAQsBAQEEAQEBAQEFAwEBAQKGIAyCOykBaS8JOQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQUCCAc0GQc1EgEBHgEBAQIBAQEhEToZAgIBCBoCEgETAgICGQwLFRACBAESgyYBglsvrCeBMoVKhGwFgQkohRsMhweBQj6BEScMFIJMPoJkAQGBMgsQLQomAQKCRjKCLASQT559AweCOYZWZ4lWhTiDP5czjlyHUWgokiQCBAIEBQIVgWmBe3AVOyoBgkEJRxgNiA0Xg1CFFIU+AXQOJIpzAQ+BIoEQAQE
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Fri, 17 Jan 2020 10:13:04 -0500
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%5]) with mapi id 15.01.1779.002; Fri, 17 Jan 2020 10:13:04 -0500
From: "Gould, James" <jgould@verisign.com>
To: "Thomas Corte (TANGO support)" <Thomas.Corte@knipp.de>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] Re: [regext] EPP and rate-limiting
Thread-Index: AQHVzURzZFRxtCbtP0uiGDLi86QrkafvQ/uAgAAEFwD//66fAA==
Date: Fri, 17 Jan 2020 15:13:04 +0000
Message-ID: <05DD4CE7-2524-4261-969C-328062378D5A@verisign.com>
References: <20200117143018.GA20025@nic.fr> <c17a7b413e2349df9a72a8e934e92af9@verisign.com> <20200117144941.GA22249@nic.fr> <6378528d-677f-43dd-0153-832beab0ccb3@knipp.de>
In-Reply-To: <6378528d-677f-43dd-0153-832beab0ccb3@knipp.de>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.f.191014
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <9D5C4DA9764C7746A3CE2677947976E2@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/DT14V9cO1nVeQg62Jk8745OgFJg>
Subject: Re: [regext] EPP and rate-limiting
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Jan 2020 15:13:08 -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
jgould@Verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com>

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)" <regext-bounces@ietf.org on behalf of Thomas.Corte@knipp.de> wrote:

    Hello,
    
    On 1/17/20 15:49, bortzmeyer@nic.fr wrote:
    
    > On Fri, Jan 17, 2020 at 02:43:02PM +0000,
    >  Hollenbeck, Scott <shollenbeck@verisign.com> wrote 
    >  a message of 21 lines which said:
    > 
    >> 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".
    
    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
    
    -- 
    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: Thomas.Corte@knipp.de
    Germany
    
    _______________________________________________
    regext mailing list
    regext@ietf.org
    https://www.ietf.org/mailman/listinfo/regext