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

From: Kathleen Moriarty <[email-masked]>
Date: Fri, 9 Sep 2016 14:31:41 -0400

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?

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.

Same in section 4.7, maybe "meaningless bits" or something along those lines?

   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.

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.

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.

Thank you!

-- 

Best regards,
Kathleen

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 9 Sep 2016 23:01:02 +0300

Hi Kathleen,

thank you for the review. I'll try to answer.

> 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?

>    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.

>    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.

> effort to reduce it might make the latter part of the draft as easy to

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?

>    first IKE Fragment messages before receiving the first one containing

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.

Thank you,
Valery.

---

From: [email-masked]
Date: Fri, 9 Sep 2016 16:06:48 -0400

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 <[email-masked]> wrote:
> 
> Hi Kathleen,
> 
> 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
> 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.
> 

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

>   attacker can just send arbitrary data, forcing the Responder    to perform costly CPU operations to compute SK_* keys.

Thank you!
>  from this list and can use any of them in the IKE SA being established.

Yes, thank you!

> to implementers while 7.2 is just an overview.

Yes, thank you!
>  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