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

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

> [ cut everything we agreed ]
> 
>>> > >      Depending on the Responder implementation, this can be repeated 
>>> > >      with
>>> > >      the same half-open SA.
>>> > > 
>>> > >   I don't think this "depends on the implemention". Since any on-path
>>> > >   attacker can spoof rubbish, a Responder MUST ignore the failed packet
>>> > >   and remain ready to accept the real one for a certain about of time. 
>>> > 
>>> >  "Depending on the Responder implementation" means here that if along 
>>> >  with discarding the failed packet the Responder also discards the 
>>> >  computed SK_* keys, then it will need to re-calculate them again
>>> >  when the next IKE_AUTH packet is received, so the attack can be
>>> >  repeated. The SK_* keys don't depend on IKE_AUTH messages,
>>> >  so in general there is no need to discard them even if the received
>>> >  IKE_AUTH packet failed to decrypt properly, and the draft advises to 
>>> >  keep them in this case. However, implementations may have good reasons 
>>> >  to do this (e.g. to free hardware resources if crypto is performed in 
>>> >  HW).
>>>
>>>  Oh, I didnt realise you talked about re-using DH components. Ok, in that
>>>  case it makes sense but you might want to say it only applies to those
>>>  who re-use DH calculations between different IKE peers. Our software
>>>  never does that (and I think FIPS also puts additional constraints on
>>>  this)
>>
>> No, it is not about re-using DH private key with different peers. I probably 
>> poorly explained. Let me try again.
>>
>> Once the IKE_SA_INIT is complete the responder has all needed data
>> to calculate SKEYSEED and SK_* keys. However, it is a CPU consuming
>> operations, so the responder may want to postpone them until the keys are
>> really needed, i.e. until it receives the IKE_AUTH request from the 
>> initiator.
>> This behaviour allows responder not to waste resources in case IKE_SA_INIT 
>> was from an attacker and IKE_AUTH request never comes. 
>> Once IKE_AUTH request arrives the responder performs DH, calculates SKEYSEED 
>> and SK_* keys that allows him to decrypt and verify this request. In case it 
>> fails
>> to decrypt IKE_AUTH request, the responder has two possibilities - keep just 
>> calculated SK_* keys until the next (hopely proper) IKE_AUTH
>> request is received or discard them (e.g. to save crypto resources) and
>> recalculate them again once the next IKE_AUTH request is received (note
>> that re-calculating will result in EXACTLY the same keys, since they don't
>> depent on any data from IKE_AUTH). The draft recommends to keep the keys 
>> until the proper IKE_AUTH request is received (or until the exchange timed 
>> out). This advise may look obvious, but I think is still worth to mention.
>>
>> I recall we've already discussed this while reviewing the -05 version...
> 
> Ohh okay. I vaguely remember. I guess reading this explanation, I would
> say it should not be needed to mention it in this document, but it you
> want to do it anyway, how about:
> 
> OLD:
> 
> Depending on the Responder implementation, this can be repeated with
> the same half-open SA.
> 
> NEW:
> 
> If a Responder does not hold on to the calculated SKEYSEED and SK_*
> keys (which it should in case a valid IKE_AUTH comes in later) this
> attack might be repeated on the same half-open SA.

OK.

>>>  This does not so much relate to IPv6 but to whether you rather
>>>  overestimate or underestimate the attacker's IP space. If you
>>>  underestimate, you will take longer to punish the attacking IPs. If you
>>>  overestimate you will needlessly slow down legitimate clients.
>>>
>>>  I don't know which of the two is better, hence my objection to "it makes
>>>  sense" because I don't see that.
>>
>> What's your suggestion for this text? Just remove "it make sense" or 
>> completely rewrite the para? If the latter, please provide the text.
> 
> Something like:
> 
> For IPv6, ISPs assign between a /48 and a /64, so it does not make sense
> for rate-limiting to work on single IPv6 IPs. Instead, ratelimits should
> be done based on either the /48 or /64 of the misbehaving IPv6 address
> observed.

OK.

>>> > >      When the Responder is under attack, it MAY choose to prefer
>>> > >      previously authenticated peers who present a Session Resumption
>>> > >      ticket (see [RFC5723] for details).
>>> > > 
>>> > >   Why is this only a MAY? Why is it not a SHOULD or MUST?
>>> > 
>>> >  A good question. I think the idea was not to force the Responder
>>> >  to serve only resumed clients and to let him(her) prioterize
>>> >  clients according to its own policy. In my opinion MUST is too strong, 
>>> >  but SHOULD is probably OK.
>>>
>>>  In the famous words of Steve Kent, if you say SHOULD instead of MUST,
>>>  explain when the Responder should not.
>>
>> 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.

>>>  That also
>>>  avoids what to do when rekey's happen because that would likely reset
>>>  the counter because it is a new state?
>>
>> 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.

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

> Paul

Regards,
Valery.