Re: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-06

[Paul Wouters <[e-mail]>]

On Mon, 6 Jun 2016, Valery Smyslov wrote:

>> >  When it has good reasons :-)
>> > 
>> >  Seriously, consider the situation when the responder finds itself
>> >  under attack and switches to only respond to IKE_SA_RESUME
>> >  requests. In this case it will leave legitimate clients without
>> >  resumption tickets (e.g. ticket expired) out of scope. I think there is 
>> >  no reasom to put MUST here, since in any case
>> >  it is a local policy which dictates the responder's behaviour,
>> >  and ther are no interoperability issues whether is is MAY, SHOULD or 
>> >  MUST, it is just the responder's local policy matter.
>> >  So SHOULD is just good advise.
>>
>>  Actually, what you are describing is something else:
>>
>>  When the Responder is under attack, it MUST NOT prefer previously
>>  authenticated peers who present a Session Resumption ticket [RFC5723]
>>  as that could cause a complete lock-out of legitimate clients that
>>  have no session to resume.
>>
>>  Although that is probably better rewritten a bit:
>>
>>  When the Responder is under attack, it SHOULD prefer previously
>>  authenticated peers who present a Session Resumption ticket [RFC5723]
>>  unless the attack itself consists of sending bogus resumption requests,
>>  in which case it SHOULD treat resumption and new session requests
>>  equally to avoid locking out a class of legitimate clients.
>
> I'd rather change it a bit:
>
>    When the Responder is under attack, it SHOULD prefer previously
>    authenticated peers who present a Session Resumption ticket [RFC5723].
>    However, the Responder SHOULD NOT swich to resumed clients
>    completely (and thus refuse every IKE_SA_INIT request),
>    so that legitimate initiators without resumption tickets still have
>    chances to connect.

Ok, minor change:

     When the Responder is under attack, it SHOULD prefer previously
     authenticated peers who present a Session Resumption ticket [RFC5723].
     However, the Responder SHOULD NOT serve resumed Initiators exclusively
     because dropping all IKE_SA_INIT requests would lock out legitimate
     Initiators that have no resumption ticket.

>> >  Well, I think the proper approach is to measure the rate of such
>> >  exchanges (per SA or course). So, just reset the counter every second 
>> >  and measure how many exchanges happened within
>> >  the second. If the number looks abusive, take measures.
>>
>>  From our implementation point of view "per SA" is difficult, because we
>>  delete failed SA states, and then lose the count of those. So in that
>>  sense, using global counters makes more sense. For us, a rekey means
>>  that the old state is replaced with a new state.
>
> I don't see any problem here. We are talking not about failed exchanges
> (after which the SA must be deleted), but about an abusive number of 
> unnecessary exchanges, which are successful from IKEv2 point of view.
> You can very well count their number per SA and it is not a big deal
> to reset counters when IKE SA is rekeyed.

I don't think you would want to reset the counters, but I know that our
implementation, which creates a new state object for the rekeyed state,
would lose information unless we specifically added code to copy those.

>>  so perhaps it is useful to elaborate a little more?
>
> Isn't all this a local matter of implementation?
> I don't think we need to mandate how implementations
> decide whether they are under attack.

I agree, this discussion does not need to be in the document.

Paul