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

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 2 Jun 2016 17:57:40 +0300

Hi Paul,

thank you for the very thorough review (and especially - for the nits).

> This is a partial review of draft-ietf-ipsecme-ddos-protection-06
> up to Section 6. I hope to complete the rest in the next few days.
> 
> I think this document needs another revision before continuing.
> (and I would prefer it to be split in two)
> 
> Issues / Questions:
> 
>    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.

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

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

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

> And this also applies to this later section in the document:
> 
>    If the received IKE_AUTH message failed to decrypt correctly (or
>    failed to pass ICV check), then the Responder SHOULD still keep the
>    computed SK_* keys, so that if it happened to be an attack, then the
>    malicious Initiator cannot get advantage of repeating the attack
>    multiple times on a single IKE SA.

Please, see above.

Do you think more explanationa are needed here?

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

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

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

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

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

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

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

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

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

I won't comment the nits.

Thank you,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 2 Jun 2016 22:06:04 -0400 (EDT)

On Thu, 2 Jun 2016, Valery Smyslov wrote:

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

>    These operations are often more computationly expensive than those

Looks good.

>    must be handled by means of the Intrusion Prevention System (IPS)
>    technology.

Looks good.

> "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
> 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)

> Do you think more explanationa are needed here?

No I guess it is fine.

> the slowest sensible retransmission policy, which seems to be the one 
> described in the draft.
>

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.

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

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

>>  One does not "calculate" a PRF. One uses a PRF to calculate something.

You didn't provide text but I assume you changed it somehow.

> so that all possible defenses are described in one place.

Then I think it still requires a one-line introduction to puzzles.

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

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

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

>>  That should be normative too, MUST be discarded.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Fri, 3 Jun 2016 16:23:48 +0300

Hi Paul,

> vulnerable. That is why I suggest to just remove the paragraph.

Ok, I see your point.

> never does that (and I think FIPS also puts additional constraints on

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

>> Do you think more explanationa are needed here?

Are you sure after the above explanation?

> That way the text will also remain more relevant in the future if/when

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.

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

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

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

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

> implemetor decide how many IKE messages counts as abusive? 

OK, I see your point.

> That also

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.

> leave it open to interpretation whether it is abuse or not, and you can

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

Thank you,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 3 Jun 2016 12:14:10 -0400 (EDT)

On Fri, 3 Jun 2016, Valery Smyslov wrote:

[ cut everything we agreed ]

>> >  "Depending on the Responder implementation" means here that if along 
>> >  with discarding the failed packet the Responder also discards the 
>> >  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).
>>
> No, it is not about re-using DH private key with different peers. I probably 
> poorly explained. Let me try again.
>
> This behaviour allows responder not to waste resources in case IKE_SA_INIT 
> was from an attacker and IKE_AUTH request never comes. 
> to decrypt IKE_AUTH request, the responder has two possibilities - keep just 
> calculated SK_* keys until the next (hopely proper) IKE_AUTH
> 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.
>

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:

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.

> Are you sure after the above explanation?

No, see above :)

> So I'd rather keep the text as above.

I'm okay with that.

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

>> > >   saying "not blocking ranges with no attackers helps real clients", 

So this is still pending.

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

Sure.

> 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

Re-reading the section I agree with you. I guess in reviewing the
document I lost toe flow of information. No change needed.

> and ther are no interoperability issues whether is is MAY, SHOULD or MUST, it 
> is just the responder's local policy matter.

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.

> exchanges (per SA or course). So, just reset the counter every second and 
> measure how many exchanges happened within

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

so perhaps it is useful to elaborate a little more?

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 6 Jun 2016 10:26:17 +0300

OK.

OK.

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

---

From: "Waltermire, David A. (Fed)" <[email-masked]>
Date: Wed, 22 Jun 2016 17:21:42 +0000

Paul and Valery,

We are extremely close on wrapping up this draft. This thread appears to be all that remains before sending the draft to the IESG. Can you guys wrap up the final minor wording changes this week?

Valery, once agreement is reached on the text changes, can you post an updated draft early next week that is ready to send to the IESG?

Thanks,
Dave

> -----Original Message-----
> From: IPsec [mailto:[email-masked]] On Behalf Of Valery Smyslov
> Sent: Monday, June 06, 2016 3:26 AM
> To: [email-masked]
> Cc: [email-masked]; Yoav Nir <[email-masked]>
> Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-06
> 
> >>> > >      Depending on the Responder implementation, this can be
> repeated
> >>> > >      with
> >>> > >      the same half-open SA.
> >>> > >
> >>> > 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
> >>>  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.
> >> 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.
> >>
> > 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:
> >
> >>> 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.
> >>
> > 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.
> 
> >>> > 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.
> >>
> >> 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.
> > 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.
> 
> >>>  avoids what to do when rekey's happen because that would likely
> >>> reset  the counter because it is a new state?
> >>
> >> 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.
> 
> 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 we need to mandate how implementations decide whether
> they are under attack.
> 
> > Paul
> 
> Regards,
> Valery.
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec

---

From: Paul Wouters <[email-masked]>
Date: Wed, 22 Jun 2016 22:20:42 -0400 (EDT)

On Mon, 6 Jun 2016, Valery Smyslov wrote:

>> >  resumption tickets (e.g. ticket expired) out of scope. I think there is 
>> >  no reasom to put MUST here, since in any case
>> >  and ther are no interoperability issues whether is is MAY, SHOULD or 
>> >  MUST, it is just the responder's local policy matter.

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.

>> >  and measure how many exchanges happened within

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.

> decide whether they are under attack.

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

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 23 Jun 2016 07:26:04 +0300

Hi Dave,

we've already incorporated Paul Wouters' comments in the draft on github.
The only thing that stops us publishing it is Paul's promise to
review the rest of the document (from Sections 7 up to the end).
I've just sent him a reminder asking if he could do it within the next
few days.

BTW, I'm on vacation till Tuesday. So, it's more realistic to post
an updated draft later next week, say Wednesday or Thursday
(I presume that Paul will do his promised review;
otherwise it's possible to post the draft earlier).

Regards,
Valery.

----- Original Message ----- 
From: "Waltermire, David A. (Fed)" <[email-masked]>
To: "Valery Smyslov" <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>; "Yoav Nir" <[email-masked]>
Sent: Wednesday, June 22, 2016 8:21 PM
Subject: RE: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-06

Paul and Valery,

We are extremely close on wrapping up this draft. This thread appears to be all that remains before sending the draft to 
the IESG. Can you guys wrap up the final minor wording changes this week?

Valery, once agreement is reached on the text changes, can you post an updated draft early next week that is ready to 
send to the IESG?

Thanks,
Dave

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 28 Jun 2016 08:37:58 +0300

HI Paul,

>     Initiators that have no resumption ticket.

Works for me.

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Thu, 30 Jun 2016 04:58:07 -0400 (EDT)

On Tue, 28 Jun 2016, Valery Smyslov wrote:

This is part two of my review. I do think the document needs some work
moving text to better locations and I have some questions I would like
to see resolved. I wrote down some nits but stopped doing that in the
end because I think chunks of text shoud be moved. By biggest issue
is that section 6 and section 7 are not clearly separated, and I see
various chunks of text I think is in the wrong section (or is section 6
text repeated in section 7)

I think this document should update 7296 due to adding non-encrypted
payloads to IKE_AUTH - even though the core IKEv2 RFC does not say that
is not allowed. Someone implementing 7296 should be aware of it to allow
it in their implementation.

I will redo a nits/grammer check on the next iteration of the document.

 	Note, that it is not possible with clients using NULL Authentication,
 	since their identity cannot be verified.

It feels that this sentence should be followed by some specific advise for
this category of clients?

Section 6 descibes in item 1: "A general DDoS attack" some numbers that I
find dangerous to follow. It descibes a scenario of 20 tunnels per second
as expected that when increased to 100 tunnels per second is considerared
a DDOS attack. But that does not take into account network failures
that would cause a large chunk of clients to reconnect at once. While
the draft says this "can be interpreted as an attack", implementors
might just put in these hardcoded numbers from the document. I'd rather
describe it a bit different so we don't give them these absolute numbers.

for example:

 	Typical measures might be 5 concurrent half-open SAs, 1 decrypt
 	failure, or 10 EAP failures within a minute.

Why is this "typical"? And again, these numbers provide too tempting easy
numbers for implementors to hardcode in their implementation. And I
think these are speculation at best.

    puzzle difficulty should be set to such a level (number of zero-bits)
    that all legitimate clients can handle it without degraded user
    experience.

This is of course the big issue of this draft. Is this possible at all?
Note te _lack_ of specific numbers here :)

I don't understand this paragraph:

    it is best to begin by requiring stateless cookies from all
    Initiators.  This will force the attacker to use real source
    addresses, and help avoid the need to impose a greater burden in the
    form of cookies on the general population of Initiators.

Perhaps the "form of cookies" was meant to say "puzzles" ?

And this one confuses me too:

    When cookies are activated for all requests and the attacker is still
    managing to consume too many resources, the Responder MAY increase
    the difficulty of puzzles imposed on IKE_SA_INIT

But up to now, we haven't been given advise to enable puzzles, and now we
are recommended to increase the difficult of puzzles?

    If the load on the Responder is still too great, and there are many
    nodes causing multiple half-open SAs or IKE_AUTH failures, the
    Responder MAY impose hard limits on those nodes.

Unlike elsewhere, it does not describe what failure to send back, if
anything, to the responder. Sending back a NOTIFY might actually not
be desirable, as it would tell the attacker their attack has reached
a good enough volume to lock out real clients. Some advise on how
to handle this scenario is needed.

And confusingly, only NOW are puzzles suggested as a next "last step",
even though before this it already told us to incrase puzzle strength.

Why is there not an option to add puzzles to the CREATE_CHILD_SA to
punish just those clients requesting too many of those? (I'm not sure
if it is a good idea, I'm asking because I'm not sure it is a bad idea)

Section 7 has:

 	According to the plan, described in Section 6, [.....]

We are not Cylons :)

Seriously though, section 6 describes _when_ to activate puzzles, and section 7
should describe how to activate puzzles without any contetx of when to enable it or not.
Currently, section 7 repeats some of the "plan" of section 6, which should not be
needed and makes the implementation section longer/harder to read. Some of the text
in section 7, like the new "processing some fraction of requests" should be in section 6,
not section 7.

7.1.1 states: "then it MUST include two notifications in its response message"
So earlier text said "may" also use cookies, and this text assumes there puzzles
can only happen with cookies. That is contradicting. I would say remove the requirement
in section 7 and change the text in section 6 to make it obvious that cookies should be
the first line of defense and should still be used when handing out puzzles on top of
cookies.

If you mean to talk about the interaction or combination of puzzles and cookies, perhaps
a separate section on that would be most clear.

7.1.1.1 introduces a term ZBC which I have no idea what it means yet. It then talks
about difficulty level 0 which I don't know what that is. Does it translate to number
of zero's in solution? If so I would expect level 1 to be the lowest? Maybe this
discussion should go into the section 7 introduction. What is the general idea of the
puzzle, what are difficuly levels, etc.

    The
    Responder MAY set different difficulty levels to different requests
    depending on the IP address the request has come from.

I would think that MAY should be stronger, a SHOULD ? If you can detect a few problem
causing IPs or IP ranges, you made good points saying to only punish those with puzzles.

    The Responder parses received SA payload and
    finds mutually supported set of transforms of type PRF.  It selects
    most preferred transform from this set and includes it into the
    PUZZLE notification.

I find the use of transform a bit confusing. I would say PRF. (and "most preferred" -> preferred)

    If there are no mutually
    supported PRFs, then negotiation will fail anyway and there is no
    reason to return a puzzle.

I first thought of the AES_GCM not needing PRF, then realised I confused IKE and IPsec SA.
Perhaps add change "negotiation will fail" to "IKE SA negotiation will fail".

7.1.1.3.  Generating Cookie

    If Responder supports puzzles then cookie should be computed in such
    a manner, that the Responder is able to learn some important
    information from the sole cookie,

We are in the middle of puzzles and not cookies. Why suddenly cookies?
Again, I think the document can use a better introduction in section 7
that explains the interaction between the two, laying out the principes.
Only later on do I read responder puzzle state is encoded in the cookie.

The point of encoding puzzle information in the cookie is presumbly so
that this state does not need to be remembered by the responder. So how
does it know "The number of consecutive puzzles given to the Initiator."?
Is this a counter in the <AdditionalInfo> ?

I would like to put a note here as well about the maximum cookie size of 64
bytes that implementors might not realise. to avoid naive implementations
building a very big "string cookie" with these bullet points of information.

Cookie = <VersionIDofSecret> | <AdditionalInfo> |
                      Hash(Ni | IPi | SPIi | <AdditionalInfo> | <secret>)

This would give the responder the AdditionalInfo information which it might
use as feedback on how successful the attack is. Why not use an encryption
of <AdditionalInfo> using the <secret> ? Would that be too expensive for
the Responder? I'd think not as it is not more expensive than decrypting
IKE_AUTH.

Or stick with the second approach listed, where the responder keeps this
state locally, which probably is better anyway because it needs to know
the scale of the entire attack that cannot be learned from individual
negotiation states.

7.1.2 states if the inititor does not want to solve a puzzle of difficulty X,
it will pretend not to support the NOTIFY. This causes the responder to not
learn that the initiator rejected the difficulty versus that it just does not
support puzzles. It would be useful for the responder to know how many iniators
support puzzles, so I would recommend a different NOTIFY for the "puzzle too
difficult" error path (Maybe a return notify of PUZZLED :)

    If the received message contains a PUZZLE notification and doesn't
    contain a COOKIE notification, then this message is malformed because
    it requests to solve the puzzle, but doesn't provide enough
    information to do it.

Again, conflicting with earlier text saying cookies are not mandated for puzzles,
which now it seems they are.

It seems 7.1.4 paragraph 2 and 3 are better moved to the introduction of that
section.

    If a PS payload is found in the message, then the Responder MUST
    verify the puzzle solution that it contains.

Doesn't that open up the responder to a DDOS attack. Initiators will just
submit fake puzzle solutions to drive up the initiator CPU.

Also, if the responder is no longer under attack, why can't it just ignore
the puzzle solution and continue with regular IKE?

    if the Responder didn't indicate any
    particular difficulty level (by setting ZBC to zero) and the
    Initiator was free to select any difficulty level it can afford,

Woah, these options were not discussed before at all. So that's what level 0 means!
I would really move this text to the start of section 7 in the introduction of how
puzzles work in general.

    o  Demand more work from Initiator by giving it a new puzzle.

This seems a waste of a round trip. Why can the responder demand a variable puzzle
without telling what would make it happy, only to have the initiator misguess and
cause another roundtrip, or to avoid a potential roundtrip, waste too much resources
and cause visible delays to endusers by overestimating puzzle difficulty? I think
this is not a good feature of the protocol.

    The more puzzles the Initiator solves the higher its chances are to be served

That seems bad. Each puzzle is a delaying round-trip!

    includes a puzzle
    solution in the first IKE_AUTH request message outside the Encrypted
    payload

Note this is very exceptional and should probably be written out in our syntax, eg:

HDR, SK {IDi, [CERT,] [CERTREQ,]
        [IDr,] AUTH, SAi2,
        TSi, TSr} [PUZZLE] -->

While I checked RFC 7296 it does not state some exchanges only have encrypted payloads,
and so technically this document does not update the core document, but I think many
implementations might not expect unencrypted payloads in IKE_AUTH and CREATE_CHILD_SA
so perhaps that is important enough to mark this document as "updating 7296".

    in the IKE_AUTH exchange S is a concatenation of Nr and SPIr.

Why Nr and SPIr? I think because of re-using DH vales on the responder? If so, it would
be good to explain that.

Should it state somewhere that IKE_AUTH puzzles are not allowed unless the clinet
confirmed support for puzzles in IKE_INIT. Because then the responder does not actually
know whetrher the initiator supports puzzles at all. And since it is stated those IKE_AUTH
responses without puzzle should be silently dropped, that becomes very important.

I think the IKE fragmentation paragraph deserves to be in its own sub-section. It's pretty
important to get it right and not start attempts to decrypt potentially bogus fragments.

Regarding the puzzle format, this is now 11 octects. we've aligned things in the past, so
should we do that hear and add another 1 octet of reserved bits? The puzzle notification
also misses an IANA line:    The payload type for the Puzzle payload is <TBA by IANA>.

Section 9 states: A good rule of thumb is for taking about 1 second to solve the puzzle.

Why is this a good rule of thumb? Again this comes down to me having no idea whether or
not puzzles is a good idea to begin with. I'm very skeptical of this claim. A botnet
will be able to waste 1s of 99% CPU on this attack per node.

    Initiators should set a maximum difficulty level beyond which they
    won't try to solve the puzzle and log or display a failure message to
    the administrator or user.

and again note that this information will never be available to the Responder, so it
can never figure out what solving levels is causing a sharp drop in legitimate clients.
(other than seeing an attack that is more successful, but it won't know that this is
caused by the puzzle difficulty level)

    that the Responder's load remain close to the maximum it can tolerate.

Which ignores the pain on initiators. it should probably be pointed out somewhere
that confirmation a puzzle solution is a lot cheaper than solving the puzzle.

nits

Note this draft also mentions IKEv2 with version instead of
refering to just IKE, which makes more sense if we end up
with IKEv3.

buggy implementation -> broken implementation

escape any responsibility for its actions ->
escape any responsibility for its bad behaviour

Since currently there is no way -> Since there is currently no way

In IKEv2 client can request various configuration attributes ->
In IKE, a client can request various configuration attributes

Most often those attributes  -> Most often these attributes

for defeating the DDoS attack -> for surviving DDoS attacks.

Implementations may be deployed in different environments ->
  Implementations are deployed in different environments

As an example -> For example

, searching for two things: -> for two scenarios:

Supposing the the tunnels  -> Supposing that the tunnels

If they are mitigated well enough -> If these are mitigated successfully

    This is a good
    thing as it prevents Initiators that are not close to the attackers
    from being affected.

I think this sentence adds nothing and can be removed.

This will force the attacker to use real source addresses,  ->
This will mitigate attacks based on IP address spoofing

I would probably shorten the introduction of section 7 to something like:

 	Puzzles can be added in the IKE_INIT and IKE_AUTH ecchanges.

and leave out the text describing the document flow, like "Both sections are divided into ..."

 	The message may optionally contain a COOKIE notification

If implementations base themselves on this draft, it is actually basically
guaranteed to have a cookie, say "may optionally" seems a bit weak?
"most likely" or "usually" seems better.

I mean, this part of the document should assume previous parts of the document
are implemented.

To support this feature -> To support crypto agility

also MAY ignore -> MAY ignore

ready to deal with them, -> ready to solve them"

---

From: "Valery Smyslov" <[email-masked]>
Date: Thu, 30 Jun 2016 18:23:09 +0300

Hi Paul,

thank you for part two of your review.

> it in their implementation.

Hmmm... Not sure it is needed. As you said RFC 7296 doesn't explicitely
prohibit that (so we don't violate its requirements) and there is a clear negotiation 
mechanism with puzzles, so that old implementations won't be affected.

I think we should be consitent in our policy whether to update core RFC or not.
For example, RFC 5723 (Resumption) defines new exchange IKE_SA_RESUME
that can be used in conjunction with IKE_AUTH instead of IKE_SA_INIT.
RFC 7296 tells only about IKE_SA_INIT + IKE_AUTH, however 
RFC 5723 doesn't update IKEv2 RFC. Is our situation much
different? I don't think so.

To be clear - I'm not against updating RFC 7296, I just think it is not needed.

OK.

> this category of clients?

What's your suggestion? We've mentioned several times that NULL Authentiacted 
peers are special case for DoS defense, here we just remind about this fact
to readers once more. I don't think any special advice could be gived here.
If you have one, please share it with us.

> describe it a bit different so we don't give them these absolute numbers.

Well, there is a text in the beginning of this section:

        the numbers given here are not normative, and their purpose is to
        illustrate the configurable parameters needed for defeating a
        DDoS attack.

Isn't this text enough for any sane implementer not to hardcode those numbers?

> think these are speculation at best.

How about:

            For example, measures might be 5 concurrent half-open
            SAs, 1 decrypt failure, or 10 EAP failures within a
            minute. 

> Note te _lack_ of specific numbers here :)

Yes, no specific figures can be given here. This text just says
that unless the responder finds itself under severe DoS attack,
puzzles, if used, must not be hard.

> Perhaps the "form of cookies" was meant to say "puzzles" ?

Agreed.

> are recommended to increase the difficult of puzzles?

This text has already been corrected (thanks to Dave's review).

> to handle this scenario is needed.

Section 4.2 describes a "Hard Limit" as situation when any 
further IKE_SA_INIT requests are rejected. 
In any case, I think section 7 is explicit enough that no NOTIFY
is sent in this case.

And I think that sending back a NOTIFY is a really bad idea.
First, as you said it'll be an extra information for attacker 
and second - it consumes additional resources from responer
that is already under DoS attack, for no good reason.

> even though before this it already told us to incrase puzzle strength.

The text earlier is about puzzles for selected IP addresses, while
here it advises to impose puzzles on all initiators.

> if it is a good idea, I'm asking because I'm not sure it is a bad idea)

Once IKE SA is created you don't need to use puzzles.
Section 5 lists less controversal and more effective countermeasures.

> in section 7, like the new "processing some fraction of requests" should be in section 6,

Well, my understanding is that section 6 gives a higher level picture (roadmap, strategy) 
of how responder is recommended to defend itself, while section 7 is very specific about 
how puzzles should be used in IKEv2 to get interoperability. I agree that they overlap,
but I don't think they must be merged. When you start implementing puzzles
you may read the draft starting from Section 7. 

So, what's wrong with the fact that SEction 7 refers to SEction 6?
Do you want the reference to be removed?

> can only happen with cookies. That is contradicting. I would say remove the requirement

Sorry, where is contradiction? You may always use cookie as described in RFC 7296.

> the first line of defense and should still be used when handing out puzzles on top of

Section 6 already recommends to first require cookies from all initiators before 
making next step and require puzzles.

> a separate section on that would be most clear.

Yes. The text above is only meant to say that puzzle notification
must always go together with cookie notification. I don't think 
we need a separate section for this requirement. How about:

                If the Responder makes a decision to use puzzles, then it 
                includes two notifications in its response message - the COOKIE notification and
                the PUZZLE notification. Note that the PUZZLE notification MUST always 
                be accompanied with the COOKIE notification, since the content of the COOKIE 
                notification is used as an input data when solving puzzle.

> 7.1.1.1 introduces a term ZBC which I have no idea what it means yet. It then talks

Already introduced in 4.4.

> about difficulty level 0 which I don't know what that is. Does it translate to number

The format of the PUZZLE notification is described in 8.1

> puzzle, what are difficuly levels, etc.

I think 4.4 serves this.

> causing IPs or IP ranges, you made good points saying to only punish those with puzzles.

I don't think so. It is responder's local matter how to defend itself.

OK. How about:

              The Responder parses the received SA payload and finds a
              mutually supported PRFs. The
              Responder selects the preferred PRF from the list of 
              mutually supported ones and includes it into the PUZZLE notification.

OK.

> We are in the middle of puzzles and not cookies. Why suddenly cookies?

Because puzzles closely linked with cookies :-)

> that explains the interaction between the two, laying out the principes.

Again, section 4.4 introduces puzzles on a higher level.

> Is this a counter in the <AdditionalInfo> ?

Yes. However, it is a local matter how responder generated cookie.
He could use alternative methods, the method described in this section 
is only an example.

OK.

> This would give the responder the AdditionalInfo information which it might

Attacker?

> the Responder? I'd think not as it is not more expensive than decrypting

Sure, it is possible. The above is just an example.
However, I don't think an attacker learns much from
AdditionalInfo. All the information from there he must already know
(of course unless the responder puts there something really sensitive).

> the scale of the entire attack that cannot be learned from individual

Both approaches (and also some combinations of them) are possible.

> difficult" error path (Maybe a return notify of PUZZLED :)

Hmmm... What the responder shoud do with this notify?
Just perform some completely unreliable statistical measurments (for what purpose)?

I think that better approach would be for such initiators that want to 
participate in such polls just solve puzzle with say 1 bit difficulty.
It'll cost them always nothing and will read to the same results for responder: 
serve such initiators with the lowest priority (as if they don't support
puzzles). But again, I don't understand what is the value of such polls.

> which now it seems they are.

Sorry, I don't see where the conflict is. Cookie mechanism is unchanged from RFC 7296.
Puzzles mechanism is used only with cookie mechanism because cookie content
is used while solving puzzle. 

> It seems 7.1.4 paragraph 2 and 3 are better moved to the introduction of that

I think it will make reading the section more difficult.

Why do you think is is needed?

> submit fake puzzle solutions to drive up the initiator CPU.

Every defense mechanism has its limits. If attacker can exhaust your CPU
by sending fake puzzle solutions, then you loose. 

> the puzzle solution and continue with regular IKE?

I see your point. However the puzzles must be easy to check, especially if the responder 
is not under attack.

Are you suggesting to change this MUST to SHOULD?
Then what are situations when responder can skip puzzles validation?

> I would really move this text to the start of section 7 in the introduction of how

These options are described in 7.1.1.1

> this is not a good feature of the protocol.

It is the responder's local policy whether to demand more work (by requesting
new puzzle) or not. 

> That seems bad. Each puzzle is a delaying round-trip!

But each new puzzle proves that the initiator spends more effort,
so its chances to be served raise with each round trip.
I don't think where will be more than 2-3 of them.
And in many cases solving more difficult puzzle would 
delay connection more than solving a few of less
difficult ones, even with additional round trips.

> HDR, SK {IDi, [CERT,] [CERTREQ,]

Your picture is wrong. SK payload is always the last payload in the message
(according to RFC 7296), so PS payload can only be placed before it.
And it is not optional in case the puzzle mechanism is used.

What's wrong for you with the picture from the draft?

   HDR, PS, SK {IDi, [CERT,] [CERTREQ,]
               [IDr,] AUTH, SA, TSi, TSr}   -->

> so perhaps that is important enough to mark this document as "updating 7296".

Please, see above (the beginning of this message).

> Why Nr and SPIr? I think because of re-using DH vales on the responder? If so, it would

No, it has nothing common with reusing DH secrets.
We just need fresh some unpredictable for an Initiator data for solving
IKE_AUTH puzzles, so Nr and SPIr are natural choise.

> responses without puzzle should be silently dropped, that becomes very important.

Section 7.2.1 says:

   The Responder MUST NOT use puzzles in the IKE_AUTH exchange unless a
   puzzle has been previously presented and solved in the preceding
   IKE_SA_INIT exchange.

Isn't it not enough?

> important to get it right and not start attempts to decrypt potentially bogus fragments.

I'm very reluctant to do so, since IKE fragmentation nuances are present
in severalsections. I think it's better to have them "in place" rather than
keep together out of context. Another option is to make IKE Fragmentation 
dedicated subsection in every relevant section, but it's usually only a para
and somebody already complained on the large number of subsections in Section 7.
So, unless you think it is absolutely necessary, I'll refrain from doing that.

> should we do that hear and add another 1 octet of reserved bits? The puzzle notification

I'd rather make it compact. We already have payloads and notifications with odd length 
even in the core spec (like CERREQ or IPCOMP_SUPPORTED) and there is no
any requirement in IKEv2 that payloads are aligned, so I don't see any reason for wasting
an extra byte in the precious IKE_SA_INIT spae (remember IP fragmentation!).

> also misses an IANA line:    The payload type for the Puzzle payload is <TBA by IANA>.

It is in the description of the corresponding field:

   o  Notify Message Type (2 octets) -- MUST be <TBA by IANA>, the value
      assigned for the PUZZLE notification.

> Why is this a good rule of thumb? Again this comes down to me having no idea whether or

There are some explanations below.

> will be able to waste 1s of 99% CPU on this attack per node.

Then the difficulty level will increase.

> caused by the puzzle difficulty level)

Do you have better solution?

> that confirmation a puzzle solution is a lot cheaper than solving the puzzle.

The text means that the difficulty level must not be too high even under attack.
So, I don't understand how it ignores the pain on initiators. Instead, the responder
is advised to keep difficulty level as low as possible, only to keep itself
operational even under attack, so that it can still serve legitimate initiators.

> nits

Accepted most of them, exceptions described below.

> and leave out the text describing the document flow, like "Both sections are divided into ..."

Well, that part was added by Dave's request as a short descrition
of Section 7 subsections.

> I mean, this part of the document should assume previous parts of the document

This section describes how puzzles are handled by the responder,
including situations with non-supporting initiators, in which cases
COOKIE is really optional/ So, left as is.

Thank you,
Valery.