Hi Yoav I have some comments, which I have included below, I hope I have interoperated your document correctly.
<<>>
Within section 2 I feel the following (or similar should be added).
RFC6989 defines a set of checks to be performed on received DH public
values, the checks against a malformed DH value prevents a vulnerability
when DH values are reused between peers. These checks can be very
computationally expensive. The check is performed in SA_INIT when the DH
value is received, in this case Stage #1 would increase in CPU power
consumed.
GB> from memory Yaron mentioned about the checks being performed when
IKE_AUTHis received, RFC6989 states the checks should be performed when
the public value
is received, if the checks can be performed at IKE_AUTH then maybe add the
following?
Although this check could be delayed until the encrypted IKE_AUTH is
received, should this check fail at Stage #2 the keys would never be
derived.
<<>>
A strategy against DDoS has to rely on at least 4 components:
1. Hardening the half-open SA database by reducing retention time.
2. Hardening the half-open SA database by rate-limiting single IPs/
prefixes.
3. Guidance on what to do when an Authentication request fails to
Decrypt.
GB> I believe another check should be added between 2 and 3. (step 3 now
become step 4)
3. Guidance on what to do when a number of DH Public Key value check fails
(if RFC6989 checks are used).
(the reason being if this was the case, you'd never get to # 3.)
<<>>
In the following you say that puzzle shouldn't be used, but then say about
setting the level ?
When there is no general DDoS attack, it is suggested that no Cookie
or puzzles be used. At this point the only defensive measure is the
monitoring, and setting a soft limit per peer IP or prefix. The soft
limit can be set to 3-5, and the puzzle difficulty should be set to
such a level (number of zero-bits) that all legitimate clients can
handle it without degraded user experience.
Maybe change to ?
'can be set to 3-5, and should the puzzle be used, the difficulty..'
<<>>
Supposing the the tunnels are established
using EAP (see section 2.16 or RFC 7296)
GB> 'or' should be 'of'
<<>>
I don't think the first thing is something we can deal with at the
IKE level. It's probably better left to Intrusion Prevention System
(IPS) technology.
GB> I thought that we could add some words to how to help configure the
IPS?
(the following is an example of an idea I had)..
Should an IPS or similar device be used when a VPN headend is under very
heavy
load when receiving many spoofed SA_INIT request. A strategy to note the
IP TTL of IP addresses that leave 1/2 open connections and rate limit any
requests that have a TTL at or below this value could be employed.
<<>>
Could you add the following to Section 7?
As the puzzle is performed before the peer can reveal its identity, VPN
headends can be deployed in a fashion where similar resourced clients are
grouped in collections to connect to the same headend, this allows for
puzzles of similar difficulty to be given to clients with similar
processing power. Note that the idea of groups clients of similar
processing power allows an attacker to prey on groups of low powered
clients.
<<>>
I have some more ideas that I'll follow up soon.
Many thanks
On 27/10/2014 21:48, "[email protected]" <[email protected]>
wrote:
>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
> This draft is a work item of the IP Security Maintenance and Extensions
>Working Group of the IETF.
>
> Title : Protecting Internet Key Exchange (IKE)
>Implementations from Distributed Denial of Service Attacks
> Author : Yoav Nir
> Filename : draft-ietf-ipsecme-ddos-protection-00.txt
> Pages : 12
> Date : 2014-10-27
>
>Abstract:
> This document recommends implementation and configuration best
> practices for Internet-connected IPsec Responders, to allow them to
> resist Denial of Service and Distributed Denial of Service attacks.
> Additionally, the document introduces a new mechanism called "Client
> Puzzles" that help accomplish this task.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-ietf-ipsecme-ddos-protection/
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-ietf-ipsecme-ddos-protection-00
>
>
>Please note that it may take a couple of minutes from the time of
>submission
>until the htmlized version and diff are available at tools.ietf.org.
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>IPsec mailing list
>[email protected]
>https://www.ietf.org/mailman/listinfo/ipsec
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
