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

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

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)" <[e-mail]>
To: "Valery Smyslov" <[e-mail]>; <[e-mail]>
Cc: <[e-mail]>; "Yoav Nir" <[e-mail]>
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



> -----Original Message-----
> From: IPsec [mailto:[e-mail]] On Behalf Of Valery Smyslov
> Sent: Monday, June 06, 2016 3:26 AM
> To: [e-mail]
> Cc: [e-mail]; Yoav Nir <[e-mail]>
> Subject: Re: [IPsec] Review of draft-ietf-ipsecme-ddos-protection-06
>
> > [ 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.
>
> _______________________________________________
> IPsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec