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

[Ari Keränen <[e-mail]>]

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 <[e-mail]> wrote:
> 
> 
> 
>> -----Original Message-----
>> From: core <[e-mail]> On Behalf Of Daniel Migault
>> Sent: Sunday, October 7, 2018 5:31 PM
>> To: [e-mail]
>> Cc: [e-mail]; [e-mail];
> [e-mail]
>> 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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/core
>