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

["Valery Smyslov" <[e-mail]>]

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?

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

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

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

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

Thank you,
Valery.

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