On Mon, 21 Mar 2016, [email protected] wrote:
Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-05.txt
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ddos-protection-05
I would remove most of the speculative text in:
In IPv4 it makes sense to limit the number of half-open SAs based on
IP address. Most IPv4 nodes are either directly attached to the
Internet using a routable address or are hidden behind a NAT device
with a single IPv4 external address. IPv6 networks are currently a
rarity, so we can only speculate on what their wide deployment will
be like, but the current thinking is that ISP customers will be
assigned whole subnets, so we don't expect the kind of NAT deployment
that is common in IPv4. For this reason, it makes sense to use a
64-bit prefix as the basis for rate limiting in IPv6.
And replace it with:
For IPv6, ISPs assign either a /48 or /64, so it makes sense to
use a 64-bit prefix as the basis for rate limiting in IPv6.
I'm not sure about:
The number of half-open SAs is easy to measure, but it is also
worthwhile to measure the number of failed IKE_AUTH exchanges. If
possible, both factors should be taken into account when deciding
which IP address or prefix is considered suspicious.
I'm not sure what measuring the failed IKE_AUTH exchanges gains you?
Whether or not you accept new work should more depend on your own
resoures than previously failed attempts, otherwise you risk becoming a
victim of lock-out attacks where an attacker causes so many failures
that legitimate clients would be prevented from initiating IKE.
Especially with CGNAT.
Next item:
There are two ways to rate-limit a peer address or prefix:
1. Hard Limit - where the number of half-open SAs is capped, and any
further IKE_SA_INIT requests are rejected.
2. Soft Limit - where if a set number of half-open SAs exist for a
particular address or prefix, any IKE_SA_INIT request will
require solving a puzzle.
This does not mention the build-in defense of the DCOOKIE defense from
the base IKEv2 spec. Although it does shortly after:
The cookie mechanism limits the amount of allocated
state to the size of the bot-net, multiplied by the number of half-
open SAs allowed per peer address, multiplied by the amount of state
allocated for each half-open SA. With typical values this can easily
reach hundreds of megabytes.
It would be clearer to to mention explicitely that the cookie mechanism
prevents spoofed packets from taking up state, thereby limiting [....]
Note that the Responder SHOULD cache
tickets for a short time to reject reused tickets (Section 4.3.1),
and therefore there should be no issue of half-open SAs resulting
from replayed IKE_SESSION_RESUME messages.
I should probably read 5723, but why would one ever respond to an "old"
re-used or unknown session resume ticket? I guess the only use is a
faster failure of lost resumption tickets for real clients? Since just
sending a "go away" response is not more computationally expensive then
creating a "go away" response for an invalid IKE SPI or badly formed IKE
packet, I would say it is not worth implementing a separate list of
recently used tickets.
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.
Well, it needs to do this anyway in case the attacker is just sending
bogus responses faster than the real client. So I don't think this
advise here is warranted - it has nothing to do with ddos.
To prevent this kind of attacks the responder should not blindly
download the whole file. Instead it SHOULD first read the initial
few bytes, decode the length of the ASN.1 structure from these bytes,
and then download no more than the decoded number of bytes.
That seems really bad. If the attacker controls the URL, they can also
put an malicious ASN.1 encoding in the cert. Much better is to [Oh never
mind you write all the things I wrote here already]
With a typical setup and typical Child SA lifetimes, there
are typically no more than a few such exchanges, often less.
I don't agree. People put in 1s liveness probes, so that's a lot of IKE
packets.
Since any endpoint can initiate a new exchange, [...]
I would more explicitely point the AUTH NULL based attacks to its RFC.
Then focus this document on the possible abuse of legitimate clients.
However, I don't know what I would want to advise. You can put in
maximums for rekeys, reauths, or child sa's, but those should at most
be configuration options, and not hardcoded options in the
implementation - since implementors cannot predict what legitimate
large scale use their code might see.
For that reason, it is NOT RECOMMENDED to
ever increase the IKEv2 window size above its default value of one
if the peer uses NULL Authentication.
I'm not sure why here the auth method is used to discriminate. Earlier
it also talked about authenticated clients and launching many exchanges?
Also, this advise is actually an update to RFC7619/RFC7296 so this
document should list it is updating those RFC's.
If the peer initiates too many exchanges of any kind,
implementations can introduce an artificial delay before
responding to request messages. This delay would decrease the
rate the implementation need to process requests from any
particular peer, making it possible to process requests from the
others. The delay should not be too long to avoid causing the IKE
SA to be deleted on the other end due to timeout.
I am not sure how useful this advise is. Since people use liveness
timeouts of 1s, a malicious peer can always do 1s of exchanges. So if
you want to introduce delays, they should probably delay only
non-liveness exchanges. And liveness exchanges that are more frequent
that 1s should probably just be dropped or rejected.
Note, that if the Responder
receives retransmissions of the request message during the delay
period, the retransmitted messages should be silently discarded.
That also updated RFC-7296 which states that each IKE request should get
an IKE answer. And these should be very cheap to send anyway. At least
our implementation caches the last sent IKE packet for retransmissions.
While the document mentions Fragmentation with respect to puzzles, it
does not mention ddos attacks based on malicious fragmentation packets.
It could be that the base RFC is clear enough, but perhaps this document
should give some advise too?
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
