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

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

Hi Paul,

>>>     An obvious defense, which is described in Section 4.2, is limiting
>>>     the number of half-open SAs opened by a single peer.  However, since
>>>     all that is required is a single packet, an attacker can use multiple
>>>     spoofed source IP addresses.
>>>
>>>  I am not sure why this is mentioned here in this way, because the attack
>>>  of spoofed source IP is already handled effectively with DOS cookies. I
>>>  think it is better to state "bot-nets are large enough that they have
>>>  enough unique IP addresses" and avoid talking about spoofing in this
>>>  section altogether.
>>
>> Here are some general observations of IKEv2 vulnerabilities,
>> regardless of the existing and proposed defense mechanisms, which are 
>> described in subsequent sections.
> 
> But it is incomplete and out of place. Section is is about The
> Vulnerability. It talks about vulnerabilities, then this one solution to
> one thing, then goes into detail about the work that makes it
> vulnerable. That is why I suggest to just remove the paragraph.

Ok, I see your point.

>>>     Stage #3 includes public key operations, typically more than one.
>>>
>>>  It seems this sentence needs to say something that these operations are
>>>  very expensive, similar to describing the "effort" in the previous
>>>  sentences of stage #1 and stage #2.
>>
>> OK. How about:
>>
>>    Stage #3 may include public key operations if certificates are involved.
>>    These operations are often more computationly expensive than those
>>    performed at stage #2.
> 
> Looks good.
> 
>>>     It seems that the first thing cannot be dealt with at the IKE level.
>>>     It's probably better left to Intrusion Prevention System (IPS)
>>>     technology.
>>>
>>>  I would rewrite this more authoritively, and not use the word "seems"
>>
>> OK. How about:
>>
>>    If an attacker is so powerfull that it is able to overwhelm
>>    the Responder's CPU that deals with generating cookies,
>>    then the attack cannot be dealt with at the IKE level and
>>    must be handled by means of the Intrusion Prevention System (IPS)
>>    technology.
> 
> Looks good.
> 
>>>     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...

>> Please, see above.
>>
>> Do you think more explanationa are needed here?
> 
> No I guess it is fine.

Are you sure after the above explanation?

>>>     Retransmission policies in practice wait at least one or two seconds
>>>     before retransmitting for the first time.
>>>
>>>  I'm not sure if this is still true. Libreswan starts at 0.5s and doubles,
>>>  and I know that iOS was faster too.
>>
>> Well, there are different implementations and each has its own
>> retransmission policy. The Responder should take into account
>> the slowest sensible retransmission policy, which seems to be the one 
>> described in the draft.
>>
>> Will the following text make you happy?
>>
>>    Many retransmission policies in practice wait one or two seconds
>>    before retransmitting for the first time.
> 
> It would be nicer to rewrite it without mentioning any absolute times.
> That way the text will also remain more relevant in the future if/when
> these timings change.

I don't think it is a good idea. The draft should give implementers some
estimate timings. "One or two seconds" is here a "worst case". If Implementers
take this data into consideration when selecting the short timeout,
they'll always be on the safe side, because if some implementations retransmit
more aggressively, then they'll always fit within this time period.

So I'd rather keep the text as above.

>>>     When not under attack, the half-open SA timeout SHOULD be set high
>>>     enough that the Initiator will have enough time to send multiple
>>>     retransmissions, minimizing the chance of transient network
>>>     congestion causing IKE failure.
>>>
>>>  I agree, but I'd like to note that this and the text just above mentioning
>>>  "several minutes" is kind of archaic. We found a limit of 30 seconds on
>>
>> That's what RFC 7296 recommends (Section 2.4).
> 
> Okay, fair enough. I guess you mention shortening it while under attack,
> so it's all okay.
> 
>>>  other implementations so common as a timeout, that we see no more value in
>>>  keeping an IKE exchange around for more then 30 seconds. (we do re-start
>>>  and try a new exchange from scratch for longer, in some configurations we
>>>  try that forever)
>>>
>>>     For IPv6, ISPs assign between a /48 and a /64, so it makes sense to use
>>>     a 64-bit prefix as the basis for rate limiting in IPv6.
>>>
>>>  Why does that make sense over using /48 ? Wouldn't you rather rate limit
>>>  some innocent neighbours over not actually defending against the attack?
>>>  If puzzles work as advertised, real clients on that /48 should still be
>>>  able to connect.
>>
>> Well, I'm not an IPv6 expert. Probably Michael Richardson (who suggested this 
>> change) or somebody else will comment on this.
> 
> 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.

>>>     Regardless of the type of rate-limiting used, there is a huge
>>>     advantage in blocking the DoS attack using rate-limiting for
>>>     legitimate clients that are away from the attacking nodes.  In such
>>>     cases, adverse impacts caused by the attack or by the measures used
>>>     to counteract the attack can be avoided.
>>>
>>>  I don't understand this paragraph at all. I guess "rate-limiting for
>>>  legitimate clients" just confuses me. I think it might attempt to be
>>>  saying "not blocking ranges with no attackers helps real clients", but
>>>  it is very unclear.
>>
>> Yoav?
>>
>>>     to calculate the PRF
>>>
>>>  One does not "calculate" a PRF. One uses a PRF to calculate something.
>>
>> OK.
> 
> You didn't provide text but I assume you changed it somehow.

s/PRF/"output of PRF" or s/PRF/"the result of PRF"   Is it OK?

>>>  The section that starts with "Upon receiving this challenge," seems to
>>>  be discussing the pros and conns of this method before it has explained
>>>  the method. The reader is forced to skip this or forward to section 7
>>>  and getting back to this part. I suggest to re-order some text to avoid
>>>  this, or to give a better short summary of the puzzle nature just before
>>>  this paragraph.
>>
>> It describes the puzzles mechanism in general, while Sections 7 & 8
>> describe the particular instantiation of puzzles in IKEv2.
>> I'd rather to keep some background about puzzles here,
>> so that all possible defenses are described in one place.
> 
> Then I think it still requires a one-line introduction to puzzles.

I'm a bit confused. I've been thinking that the whole Section 4.4 
is a high-level description of the puzzles. Where do you want to insert
the one-line introduction?

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

>>>     The Responder MAY require such
>>>     Initiators to pass a return routability check by including the COOKIE
>>>     notification in the IKE_SESSION_RESUME response message, as allowed
>>>     by Section 4.3.2. of [RFC5723].
>>>
>>>  Perhaps this should say the responder SHOULD require COOKIEs for resumed
>>>  sessions if it also requires COOKIEs for IKE_INIT requests. That is, it
>>>  should not give preference to resumed sessions as those could be equally
>>>  forged as IKE_INIT requests.
>>
>> A good point. I tend to agree. Yoav?
>>
>>>     With a typical setup and typical Child SA lifetimes, there
>>>     are typically no more than a few such exchanges, often less.
>>>
>>>  (ignoring the language) I do not believe this is true. This goes back to
>>>  the discussion on how often people deploy liveness probes. Implementors
>>>  seem to think 30s, while endusers want and do configure things like 1s.
>>>  I don't think the text about the amount of IKE exchanges are typical
>>>  are needed because the text below talks about specific abuse anyway,
>>>  and not in terms of just number of exchanges.
>>
>> Are you suggesting to remove it?
> 
> Yes. You can just talk about something like "If an abusive amount of
> (otherwise) valid IKE messages are received, ....." and let the
> implemetor decide how many IKE messages counts as abusive? 

OK, I see your point.

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

>>>        If the peer creates too many Child SA with the same or overlapping
>>>        Traffic Selectors, implementations can respond with the
>>>        NO_ADDITIONAL_SAS notification.
>>>
>>>  I think this requires normative language, eg: implementations MUST respond
>>>  with a NO_ADDITIONAL_SAS notification. The same for the next bullet item
>>>  where it says "implementations can introduce an artificial delay", which
>>>  should be like: "MAY introduce an artificial delay" (or even SHOULD, or
>>>  rewrite "too many" to "many" and use MAY)
>>
>> I'd use MAY and keep "too many". "Too many" means here that a peer is at 
>> least misbehaved, while just "many" doesn't imply this
>> (in my reading).
> 
> You cannot say "too many" and "MAY". If it is too many, it is abusive.
> So you MUST take action. On the other hand if you say "many", then you
> leave it open to interpretation whether it is abuse or not, and you can
> use "MAY".

I see. Language differences :-) Ok, let's remove "too".

>>>  Section 5 switchs from talking about "the Responder" to "the
>>>  implementation".
>>>  I think it should be "the Responder" throughout the document.
>>
>> OK.
>>
>>>      the retransmitted messages should be silently discarded.
>>>
>>>  That should be normative too, MUST be discarded.
>>
>> Agree.
> 
> Paul

Thank you,
Valery.