Subject: Secdir last call review of draft-ietf-core-too-many-reqs-04

From: Daniel Migault <[email-masked]>
Date: Sun, 07 Oct 2018 17:30:43 -0700

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 ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. 
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.
OLD
   may not be able to reply to all requests at all.
NEW
   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 Max 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
spoofed response to the legitimate client.

The response code provides an information about the state (overloaded) of the
server which can be used to infer additional information. This could
potentially be used by an active attacker among other to confirm an attack is
efficient, 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 passive attacker, the response code may among other indicate an appropriated
time to trigger a larger attack....

Because the code enable an attacker to gain some kind of control of the client,
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.
</mglt>

---

From: Jim Schaad <[email-masked]>
Date: Mon, 8 Oct 2018 09:52:58 -0700

> -----Original Message-----
> From: core <[email-masked]> On Behalf Of Daniel Migault
> Sent: Sunday, October 7, 2018 5:31 PM
> To: [email-masked]
> Cc: [email-masked]; [email-masked];
[email-masked]
> Subject: [core] Secdir last call review of
draft-ietf-core-too-many-reqs-04
> effort to review all IETF documents being processed by the IESG. These
> comments were written primarily for the benefit of the security area
directors.
> Document editors and WG chairs should treat these comments just like any
> other last call comments.
> 
> The gain from the response with Too Many Requests Response Code is almost
> the current response and all *similar* requests from that client during
Max
> 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>
> 
> 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
spoofed
> response to the legitimate client.
> 
potentially
> be used by an active attacker among other to confirm an attack is
efficient,
> 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
passive
> attacker, the response code may among other indicate an appropriated time
to
> trigger a larger attack....
> 
> 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.
> 

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. 

Jim

> </mglt>
> 
> _______________________________________________
> core mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/core

---

From: Ari Keränen <[email-masked]>
Date: Sun, 21 Oct 2018 18:09:44 +0000

Thank you for the review Daniel!

I have now addressed your comments in the latest draft version in Github:
https://github.com/core-wg/too-many-reqs/pull/4/files

* Clarified the text in sections 4 and 5 roughly as proposed
* Added a note in section 5 that dropping requests may result in retries 
* Added a note that responses without encryption can leak information (agree with Jim that it’s not a major risk so didn’t add normative language on this)

I’m planning to submit a new version tomorrow before the DL.

Cheers,
Ari

> On 8 Oct 2018, at 19.53, Jim Schaad <[email-masked]> wrote:
> 
> 
>

---

From: Daniel Migault <[email-masked]>
Date: Mon, 22 Oct 2018 07:01:42 +0000

Hi Ari!

I checked the version on github.  It addresses my concerns also considering Jim’s feed backs. 

Yours, 

Daniel

From: Ari Keränen 
Sent: Sunday, October 21, 2018 2:10 PM
To: Daniel Migault <[email-masked]>; [email-masked]
Cc: [email-masked]; [email-masked]; [email-masked]; Jim Schaad <[email-masked]>
Subject: Re: [core] Secdir last call review of draft-ietf-core-too-many-reqs-04

 

Cheers,

Ari

On 8 Oct 2018, at 19.53, Jim Schaad <[email-masked] <mailto:[email-masked]> > wrote:

-----Original Message-----

From: core <[email-masked] <mailto:[email-masked]> > On Behalf Of Daniel Migault

To: [email-masked] <mailto:[email-masked]> 

Cc: [email-masked] <mailto:[email-masked]> ; [email-masked] <mailto:[email-masked]> ;

[email-masked] <mailto:[email-masked]> 

 

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

ongoing

directors.

Yours,

Daniel

4.  CoAP Client Behavior

<mglt>

OLD

NEW

</mglt>

<mglt>

Max

from the

good to

  before trying again.

<mglt>

request or

spoofed

The response code provides an information about the state (overloaded) of

the

potentially

efficient,

used to

passive

to

Because the code enable an attacker to gain some kind of control of the

client,

and reveals some information about the status of the server. I would

suggest to

encrypted.

The response seems to me small enough so reflection attacks may be out of

scope.

Jim

</mglt>

core mailing list

[email-masked] <mailto:[email-masked]>