Re: [core] Secdir last call review of draft-ietf-core-too-many-reqs-04

Jim Schaad <> Mon, 08 October 2018 16:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 80D05130E9B; Mon, 8 Oct 2018 09:53:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id jg3DcnP8BAPn; Mon, 8 Oct 2018 09:53:11 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C7CC4130E45; Mon, 8 Oct 2018 09:53:07 -0700 (PDT)
Received: from Jude ( by ( with Microsoft SMTP Server (TLS) id 15.0.1347.2; Mon, 8 Oct 2018 09:48:24 -0700
From: Jim Schaad <>
To: 'Daniel Migault' <>, <>
CC: <>, <>, <>
References: <>
In-Reply-To: <>
Date: Mon, 8 Oct 2018 09:52:58 -0700
Message-ID: <061801d45f27$602ef380$208cda80$>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 16.0
Thread-Index: AQHSfIc3LIj2hJ6wIQjT3ObuMBUElqUZVFMg
Content-Language: en-us
X-Originating-IP: []
Archived-At: <>
Subject: Re: [core] Secdir last call review of draft-ietf-core-too-many-reqs-04
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Constrained RESTful Environments \(CoRE\) Working Group list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 08 Oct 2018 16:53:25 -0000

> -----Original Message-----
> From: core <> On Behalf Of Daniel Migault
> Sent: Sunday, October 7, 2018 5:31 PM
> To:
> Cc:;;
> Subject: [core] Secdir last call review of
> Reviewer: Daniel Migault
> Review result: Has Nits
> Hi,
> Reviewer: Daniel Migault
> Review result: Has Nits
> I have reviewed this document as part of the security directorate's
> effort to review all IETF documents being processed by the IESG. These
> comments were written primarily for the benefit of the security area
> Document editors and WG chairs should treat these comments just like any
> other last call comments.
> The document is clear and almost ready.  Most of my comments concerns the
> "Security Considerations".
> Yours,
> Daniel
> 4.  CoAP Client Behavior
>    A client MUST NOT rely on a server being able to send the 4.29
>    Response Code in an overload situation because an overloaded server
>    may not be able to reply to all requests at all.
> <mglt>
> I believe the sentence may be rephrased. This is just a proposal.
>    may not be able to reply to all requests at all.
>    may not be able to reply (at all) to some requests. .
> </mglt>
> 5.  Security Considerations
>    Replying to CoAP requests with a Response Code consumes resources
>    from a server.  For a server under attack it may be more appropriate
>    to simply drop requests without responding.
> <mglt>
> The gain from the response with Too Many Requests Response Code is almost
> the current response and all *similar* requests from that client during
> Age. I suspect that is likely a gain except when there is no responses
from the
> server and client is not expect to send a request before Max Age. Simply
> dropping the requests may add the retry traffic, though it depends on the
> application. That said your text is correct. I am wondering if it would be
good to
> illustrate your purpose. </mglt>
>    If a CoAP reply with the Too Many Requests Response Code is not
>    authenticated and integrity protected, an attacker can attempt to
> Keranen                 Expires January 25, 2019                [Page 3]
> Internet-Draft  Too Many Requests Response Code for CoAP       July 2018
>    spoof a reply and make the client wait for an extended period of time
>    before trying again.
> <mglt>
> A similar attack may also consists in an attacker triggering multiple
request or
> transactions with a spoofed IP so the server generates the reply to the
> legitimate IP. This could be used if an attacker cannot directly send the
> response to the legitimate client.
> The response code provides an information about the state (overloaded) of
> server which can be used to infer additional information. This could
> be used by an active attacker among other to confirm an attack is
> that a server is receiving multiple packet at a given time which may be
used to
> identify some traffic patterns, identifying a bug a version...  For a
> attacker, the response code may among other indicate an appropriated time
> trigger a larger attack....
> Because the code enable an attacker to gain some kind of control of the
> and reveals some information about the status of the server. I would
suggest to
> mention that Too Many Response Code should not be considered outside
> unprotected channel. That is a server SHOULD NOT reply with a Too Many
> Requests Response Code unless the communication is encrypted. A client
> SHOULD ignore Too Many Response Code unless the communication is
> encrypted.
> The response seems to me small enough so reflection attacks may be out of
> scope.

I do not believe that this is aimed to be any type of DOS prevention tool.
I would disagree that this is a huge attack window.  The client will filter
the set of response that it is receiving to match only requests that it has
made.  Thus a general flood attack would not be useful unless it was
targeting the same messages ids (and tokens) as requests from the client
under attack.  But then these would be seen by the server as duplicate
messages and ignored w/o sending out a response.

I am not sure that I would consider the fact that the server is currently
"loaded" for some measure is a huge leak of information.  I don't think I
would care if that was leaked. 


> </mglt>
> _______________________________________________
> core mailing list