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

[Daniel Migault <daniel.migault@xxxxxxxxxxxx>]

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 <daniel.migault@xxxxxxxxxxxx>; core@xxxxxxxx
Cc: secdir@xxxxxxxx; draft-ietf-core-too-many-reqs.all@xxxxxxxx; ietf@xxxxxxxx; Jim Schaad <ietf@xxxxxxxxxxxxxxxxx>
Subject: Re: [core] Secdir last call review of draft-ietf-core-too-many-reqs-04

 

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 <ietf@xxxxxxxxxxxxxxxxx> wrote:

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

From: core <core-bounces@xxxxxxxx> On Behalf Of Daniel Migault

Sent: Sunday, October 7, 2018 5:31 PM

To: secdir@xxxxxxxx

Cc: draft-ietf-core-too-many-reqs.all@xxxxxxxx; ietf@xxxxxxxx;

core@xxxxxxxx

Subject: [core] Secdir last call review of

draft-ietf-core-too-many-reqs-04

 

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.

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

core@xxxxxxxx

https://www.ietf.org/mailman/listinfo/core

 

<<attachment: smime.p7s>>