Re: [IPsec] AD review of draft-ietf-ipsecme-ddos-protection

[[e-mail]]

Hi Valery,  

Thanks for the quick response, inline.

Please excuse typos, sent from handheld device 

> On Sep 9, 2016, at 4:01 PM, Valery Smyslov <[e-mail]> wrote:
> 
> Hi Kathleen,
> 
> thank you for the review. I'll try to answer.
> 
>> Hello,
>> Thank you for you work on draft-ietf-ipsecme-ddos-protection.  This is
>> a good read that lays out the problem well and describes the solution
>> well.  Thanks for that!
>> I have some nits and questions before we put this into IETF last call.
>> Section 4.2 -
>> This level of detail is great.  Hopefully developers make sure logs
>> and other ways to help with troubleshooting to determine the number of
>> half open SA and failed IKE-Auth exchanges.  Are these maintained with
>> counters (SNMP/YANG) or log entries or some other way?  Does this
>> matter and does it need to be indicated here for developers so
>> implementors have the tools needed to determine next steps?
> 
> I think that it is a local matter how implementations measure the number of half-open SAs. It is possible to maintain some counters or parse local log files. Or, for example, just call size() method
> for some kind of container (list, map) in case all half-open SAs are placed there.
> 
> The only requirement is that implementations must do this measuring
> periodically to get a picture of what is happening. Again, it is a local matter how often implementations should learn the number of half-open SAs, the draft doesn't impose any restrictions.
> 
> Do you think some clarification is needed here?
> 

No, it's fine to leave it out.  I appreciate the explanation.

>> Section 4.6:  Suggest using some descriptive language instead of
>> saying 'garbage' in the following sentence for non-native English
>> speakers:
>>   The
>>   attacker can just send garbage in the IKE_AUTH message forcing the
>>   Responder to perform costly CPU operations to compute SK_* keys.
> 
> How about:
> 
>   Instead of sending properly formed and encrypted IKE_AUTH message the
>   attacker can just send arbitrary data, forcing the Responder    to perform costly CPU operations to compute SK_* keys.
>   (by the way, I'm a non-native English speaker, and the word "garbage"
> doesn't shock me here, but I agree that more formal language is probably better)
> 
>> Same in section 4.7, maybe "meaningless bits" or something along those lines?
> 
> Great! Definitely better from my point of view, thank you.

Thank you!
> 
>>   Malicious
>>   initiators can use this feature to mount a DoS attack on the
>>   responder by providing an URL pointing to a large file possibly
>>   containing garbage.
>> Section 7.1.1.2: The following sentence could be cleaned up a bit
>> (last paragraph):
>>   The
>>   initial request message sent by the Initiator contains an SA payload
>>   with the list of transforms the Initiator supports and is willing to
>>   use in the IKE SA being established.
> 
> I'm not sure what's wrong with this sentence, but I'll try. Is the followng better?
> 
>  The
>  initial request message sent by the Initiator, contains an SA payload,
>  containing a list of transforms. The Initiator supports all transforms
>  from this list and can use any of them in the IKE SA being established.

Yes, thank you!

> 
>> Section 7.2.1.1
>> The first sentence of course fits in this section, but has already
>> been said in the draft.  This whole section seems repetitious.  There
>> are a few places where text is repeated, is it possible to reduce
>> repetition?  It might not be for clarity as the sections vary, but an
>> effort to reduce it might make the latter part of the draft as easy to
>> read as the start.
> 
> Yes, this sentence almost duplicates the sentence from the second para
> of previous Section (7.2). But I'd rather to keep it in 7.2.1.1 and just
> remove from 7.2, because 7.2.1.1 gives more detailed instructions
> to implementers while 7.2 is just an overview.
> 
> Are you OK with this?

Yes, thank you!
> 
>> Section 7.2.4: 4th paragraph, 1st sentence doesn't read well.  Can you
>> break it up and phase the "non-first" differently?  I don't think that
>> is a term of art, is it?
>>   If the Initiator uses IKE Fragmentation, then it is possible, that
>>   due to packet loss and/or reordering the Responder could receive non-
>>   first IKE Fragment messages before receiving the first one containing
>>   the PS payload.
> 
> How about:
> 
>  If the Initiator uses IKE Fragmentation, then it sends all IKE Fragment messages simultaneously.
>  Due to packets loss and/or reordering the Responder could receive   subsequent IKE Fragment messages before receiving the first one, that contains   the PS payload.

Better, thanks!  Let me know when you have the updated draft & I'll initiate IETF last call.

Thanks,
Kathleen 

> 
> Thank you,
> Valery.
> 
>> Thank you!
>> -- 
>> Best regards,
>> Kathleen
>