Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-05.txt

From: [email-masked]
Date: Mon, 21 Mar 2016 13:13:28 -0700

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 of the IETF.

        Title           : Protecting Internet Key Exchange Protocol version 2 (IKEv2) Implementations from Distributed Denial of Service Attacks
        Authors         : Yoav Nir
                          Valery Smyslov
	Filename        : draft-ietf-ipsecme-ddos-protection-05.txt
	Pages           : 29
	Date            : 2016-03-21

Abstract:
   This document recommends implementation and configuration best
   practices for Internet Key Exchange Protocol version 2 (IKEv2)
   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:
https://tools.ietf.org/html/draft-ietf-ipsecme-ddos-protection-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-ddos-protection-05

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/

---

From: Paul Wouters <[email-masked]>
Date: Mon, 21 Mar 2016 21:05:11 -0400 (EDT)

On Mon, 21 Mar 2016, [email-masked] wrote:

> Subject: [IPsec] I-D Action: draft-ietf-ipsecme-ddos-protection-05.txt

> 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

---

From: "Valery Smyslov" <[email-masked]>
Date: Tue, 22 Mar 2016 11:43:58 +0300

Hi Paul,

thank you for the detailed review.

>  use a 64-bit prefix as the basis for rate limiting in IPv6.

Do I get you right that you want to remove the following text?

                                                    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.

> I'm not sure what measuring the failed IKE_AUTH exchanges gains you?

It allows a responder to make a decision whether it is under attack.
If a percentage of IKE_AUTH exchanges that failed to decrypt properly
is high enough, then it means that a large fraction of initiators 
send bogus IKE_AUTH requests, so the responder can assume that they
do this for reason. In this case the responder can use puzzles in 
IKE_AUTH (see Section 7.2).

> resoures than previously failed attempts, otherwise you risk becoming a

It is based on both. You must maintain some statistics information
(number of half-open IKE_SA_INIT, number of failed IKE_AUTH)
and make a decision whether to use defensive measures
by analyzing this statistics.

If you only take into consideration your resources consumption,
then you would end up punishing legitimate clients in case 
there are so many of them that you just cannot handle the volume
of requests, even if there are no no orphaned IKE_SA_INIT or failed IKE_AUTH.
In other words, you must distinguish attack from just a high load. 
Statistics helps you in this case.

> that legitimate clients would be prevented from initiating IKE.

See above. Once you make a decision that an attak is in progress
(e.g. by monitoring the number of failed IKE_AUTH within
last N seconds), you'll turn on IKE_AUTH puzzles 
or take some other measures.

> the base IKEv2 spec. Although it does shortly after:

Cookies are described in the next chapter.

> prevents spoofed packets from taking up state, thereby limiting [....]

Could you please be more explicit what text you are not happy with?

> packet, I would say it is not worth implementing a separate list of

RFC 5723 describes two kinds of tickets - "ticket by reference"
and "ticket by value". In the former case the server stores
all the information regarding IKE SAs that can be resumed and the 
ticket is just an "index" in that database. With this approach
the server always knows whether the ticket was already used or not.
With the latter approach all the information regarding the SA
is stored in the ticket itself. The server stores nothing in this case - 
it just decrypts the presented ticket and resumes the IKE SA.
In this case the server doesn't know whether the ticket
is used before unless it maintaines a cache of recently
used tickets. 

> bogus responses faster than the real client. So I don't think this

Do you mean "bogus requests"? Isn't it a DoS attack?

> advise here is warranted - it has nothing to do with ddos.

I think this advise is closely related to DoS protection. 
You yourself described the attack two lines above.

> mind you write all the things I wrote here already]

OK.

> I don't agree. People put in 1s liveness probes, so that's a lot of IKE

Liveness check is about 50 bytes. Even if it is performed
every second, it results in 2 packet/sec and 100 bytes/sec traffic per a client. 
Is it a lot?

> I would more explicitely point the AUTH NULL based attacks to its RFC.

Well, I think we tryed to follow this way: there is little specific to 
NULL auth, it is just mentioned (and referenced) as one of the 
factors that may make DoS attacks more easy to mount.

> large scale use their code might see.

Sure. And that's why the draft doesn't prescribe any hard limits,
it just lists possible defense measures.

> it also talked about authenticated clients and launching many exchanges?

Because with NULL auth the peer is not authenticated 
and we'd rather limit him/her abilities to mount DoS attack
by initiating N exchanges in parallel, that would increase
our peak load. If the peer is authenticated, then launching
N exchanges simultaneously is not an attack in general. 
And if the authenticated peer mounts such a DoS attack, the
he/she could be traced down and either out-of-band
measures are taken or peer's credentials are revoked.

> document should list it is updating those RFC's.

Is it really needed? RFC 7296 doesn't deal with NULL auth,
and RFC 7619 does reference this draft in Security Considerations.
What others think of it?

> that 1s should probably just be dropped or rejected.

It doesn't matter what exchange type is. The intention is to artificially 
limit the number of exchanges the malicious peer can initiate per second.
There is a MID window, so the peer cannot initiate a new exchange until
one of the currently active exchanges is completed. If, for example,
window size is 1, then the malcious peer cannot initiate a new
exchange until we send a responce to the current one. If we send
response immediately, then the malicious peer immediately
initiates another exchange. If we respond in 3 seconds, then 
it will have to wait 3 seconds, before it can initiate a new exchange
(probably sending retransmissions during that time that we will ignore). 
That's an idea. If malicious peer is so impatient, that it'll tear down 
the IKE SA if no response is received within 3 seconds, 
then it'll make worse for itself - it'll need to create
a new IKE SA from scratch passing all the puzzles barriers.

> an IKE answer. 

I don't think artificaial delay is a violation of RFC 7296.
Each IKE request will be answered. RFC 7296 doesn't require that
it is answered immediately (or as soon as responder can prepare the response).

> And these should be very cheap to send anyway. At least

Yes, you can count the number of received retransmissions during the artificial
delay and once the delay is over send back that number of identical responses at once.
It is cheap. However I'm not sure it makes sense.

> should give some advise too?

I think RFC 7383 lists possible DoS attacks in Security Considerations section.
Do you think it's not enough?

> Paul

Regards,
Valery.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 22 Mar 2016 15:49:35 +0200

> that 1s should probably just be dropped or rejected.

If someone is stupid enough to allow anybody to configure liveness
timeout of 1 seconds, he gets what he deserves.

In normal case having more than 10 exchanges per minute is too much,
unless you are using per port SAs or similar special cases.

Also having liveness checks more often than 30 seconds should be
penalized, especially if implementation is using broken periodic
liveness checks. It is fine to have 10 second liveness check timeout
for one way traffic, i.e., when the traffic changes to be one-way you
ONCE do liveness check after 10 seconds, but then you do NOT do
liveness check again until something else happens.

It will still take several minutes to notice that the liveness check
failed, so there is no point of doing them too often.
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 22 Mar 2016 16:01:30 +0200

Valery Smyslov writes:
> Liveness check is about 50 bytes. Even if it is performed every
> second, it results in 2 packet/sec and 100 bytes/sec traffic per a
> client. Is it a lot?

When you pay for all your mobile traffic for 0.62 eur/MB (my roaming
charges in Hong Kong) that will 8 eur/day. And I am sure there are
better use for the bandwidth than sending liveness checks. 

> If we respond in 3 seconds, then it will have to wait 3 seconds,
> before it can initiate a new exchange (probably sending
> retransmissions during that time that we will ignore). That's an
> idea. If malicious peer is so impatient, that it'll tear down the
> IKE SA if no response is received within 3 seconds, then it'll make
> worse for itself - it'll need to create a new IKE SA from scratch
> passing all the puzzles barriers.

And RFC7296 do suggest that you try for several minutes before you
time out:

   The number of retries and length of timeouts are not covered in this
   specification because they do not affect interoperability.  It is
   suggested that messages be retransmitted at least a dozen times over
   a period of at least several minutes before giving up on an SA, but
   different environments may require different rules.  To be a good
   network citizen, retransmission times MUST increase exponentially to
   avoid flooding the network and making an existing congestion
   situation worse.  

> I don't think artificaial delay is a violation of RFC 7296. Each IKE
> request will be answered. RFC 7296 doesn't require that it is
> answered immediately (or as soon as responder can prepare the
> response).

That is true. Having delay before responding to the request is
completely legal and is perfect way to make sure nobody uses stupid
settings like 1 second liveness delay. If you detect such setting it
might be good idea to put 60 second delay for liveness check that come
more often than once per minute... 
-- 
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 22 Mar 2016 10:45:21 -0400

> use a 64-bit prefix as the basis for rate limiting in IPv6.

Change it to
    > For IPv6, ISPs assign between a /48 and a /64, so it makes sense to

(it seems that /56 and /60 are the suite spots)

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Paul Wouters <[email-masked]>
Date: Sun, 27 Mar 2016 13:41:36 -0400 (EDT)

>    assigned whole subnets, so we don't expect the kind of NAT deployment

Yes. Since it is speculative and will quickly go stale in the RFC (we hope :)

> is high enough, then it means that a large fraction of initiators send bogus 
> IKE_AUTH requests, so the responder can assume that they
> do this for reason. In this case the responder can use puzzles in IKE_AUTH 
> (see Section 7.2).

Ok, although I'm still not convinced doing this won't make the problem
worse for the legitimate client.

> by analyzing this statistics.

I agree on the half-open SA's, I'm not convinced about meassuring failed
IKE_AUTH. Previous failures cost no current resources, so I'm not sure
if it should be used to as a metric. The metric should be based on
current resources, which seem already reflected in the number of
half-open SA's you're carrying and the amount of resources those are
using.

> then you would end up punishing legitimate clients in case there are so many 
> of them that you just cannot handle the volume of requests

Sure, just like puzzles punish legitimate clients :)

> In other words, you must distinguish attack from just a high load.

"just a high load" would not have zillions of half-open SA's.

> last N seconds), you'll turn on IKE_AUTH puzzles or take some other measures.

you seem to think you can save the poor legitimate client in a see of
botnet. I am not convinced of that. Excluding that, the only thing the
server needs to do when under attack is ensure it does not die. So a
limit of the half-open SA's make sense _for the server itself_. It's not
doing that to help legitimate clients - those have already lost. They
are drowned out (with or without a sea of puzzles)

> Could you please be more explicit what text you are not happy with?

I don't think it is obvious enough in the text that cookies prevent
attacks based on source IP spoofing, and tHat this attack is based on
a network of compromised machines that talk IKE without needing
spoofing. I would also just say "attacker" instead of "bot-net" to keep
it generic.

> all the information regarding IKE SAs that can be resumed and the ticket is 
> just an "index" in that database. With this approach

Ok, so that ticket is not covered in the above text. If there is such
a ticket, it is unused, not re-used.

> is stored in the ticket itself. The server stores nothing in this case - it 
> just decrypts the presented ticket and resumes the IKE SA.

Ahh okay. Thanks for the information. That makes sense now. But it does
open up another attack. Attackers can flood the responder with bogus
resumption tickets, using up the responders CPU. But I see that is covered
itself in RFC 5723 section 9.3, but that is currently not references in
your current document. Possibly add that for completeness sake?

> Do you mean "bogus requests"? Isn't it a DoS attack?

Yes I meany bogus IKE_AUTH requests.

> I think this advise is closely related to DoS protection. You yourself 
> described the attack two lines above.

It is an (obvious) attack but not a DDOS attack. eg:

client    IKE_INIT Request          --->
                                     <--- IKE_INIT Response  server
attaker   IKE_AUTH Request (bogus)  --->  [fails]
client    IKE_AUTH Request          --->

I think any implementor should really already handle this case in
general. Any failures of unauthenticated packets must be dropped
and the timeout timer continued to wait for the legitimate response.
That's a core part of the IKEv2 spec, so I don't think that needs
to be repeated in this document.

>>  mind you write all the things I wrote here already]

Just to clarify, I do think you need to rewrite the text to not blindly
trust the ASN.1 length encoding. Or just remove that advise and stick
to the other items to discuss right after.

> every second, it results in 2 packet/sec and 100 bytes/sec traffic per a 
> client. Is it a lot?

See other discussions. We sadly have a strong demand by operational
people to have really short liveness timers. While as implementor, we
have refused < 1s, people often do use 1s timers as a way to do High
Availability. So I think the advise of limiting the number of allowed
responses for an IKE SA in general is dangerous. There are many
unexpected use cases.

> Well, I think we tryed to follow this way: there is little specific to NULL 
> auth, it is just mentioned (and referenced) as one of the factors that may 
> make DoS attacks more easy to mount.

hmm ok.

> it just lists possible defense measures.

right.

> Because with NULL auth the peer is not authenticated and we'd rather limit 
> him/her abilities to mount DoS attack
> N exchanges simultaneously is not an attack in general. And if the 
> authenticated peer mounts such a DoS attack, the

So you are saying basically that this text should have appeared in the
AUTH NULL RFC, but didn't. Perhaps then a separate section for AUTH NULL
clients could be put in this document, and then also let it update that
RFC?

> and RFC 7619 does reference this draft in Security Considerations.

I'm curious too what others think this is: a "recommendation" or a "change".

> limit the number of exchanges the malicious peer can initiate per second.

See earlier discussion about 1s liveness probes.... It is very common.

> initiates another exchange. If we respond in 3 seconds, then it will have to 
> wait 3 seconds, before it can initiate a new exchange

Yes, I don't have a problem with this part.

> That's an idea. If malicious peer is so impatient, that it'll tear down the 
> IKE SA if no response is received within 3 seconds, then it'll make worse for 
> itself - it'll need to create

Sure.

> it is answered immediately (or as soon as responder can prepare the 

Yes, you are right. Strike this remark :)

> Do you think it's not enough?

It is, but you are inconsistent with what you pull it or reference from
other RFC's? See above discussion.

btw. thanks for this discussion. It has raised some interesting
implementation details, some of which I now want to implement :)

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 28 Mar 2016 17:05:55 +0300

Hi Paul,

OK.

> half-open SA's you're carrying and the amount of resources those are

You are right that once an attacker sent bogus IKE_AUTH request
and the responder spent some CPU resources to calculate the DH
to only recognize that it cannot decrypt the message, nothing can be 
done since the responder has already spent that resources.

However, let's look on a wider picture. The goal of attacker is to 
exhaust responder's CPU power (not the memory like in half-open SAs), 
so the attacker would initiate zillions of fake IKE SAs to send bogus IKE_AUTH 
request on each of them. Only in this case the attack will be successful. 
But since the responder's CPU most likely doesn't have zillions cores,
the processing of all these SAs will be done in sequence
and will take some time. If during that time the responder
measures the percentage of bogus IKE_AUTH requests
it can detect that the attack is most likely in progress and
turn on IKE_AUTH puzzles. So few millions of that 
zillions bogus IKE_AUTH requests would pass before
the defense is activated, however the others will be thwarted.

> "just a high load" would not have zillions of half-open SA's.

Sure. And would not have zillions of bogus IKE_AUTH requests.
That's why it is not sufficient to measure only load.
If the responder cannot tolerate the load caused solely by legitimate users
(no half-open SAs, no bogus IKE_AUTH requests, just too many initiators),
then you'd better replace it with the more powerfull one 
than to punish the users.

> botnet. 

By all means. Otherwise we would fail completely.

I agree that in case of attack the legitimate clients would suffer,
however the server shoul do its best to allow them to work.

> I am not convinced of that. Excluding that, the only thing the
> server needs to do when under attack is ensure it does not die. 

No. It should continue to serve legitimate clients (at least try to do it).

> So a limit of the half-open SA's make sense _for the server itself_. It's not

The liveness of the server is not a goal per se.
If it were the goal then there would be a simple and perfect DDoS defense - 
just unplug network cable. The server will be alive forever,
however it won't provide the service, so the _Denial_of_Service_
attack will be successful. We don't want that kind of defense.

OK.

OK.

> to be repeated in this document.

The text is not exactly about this. 

Once the responder sent IKE_SA_INIT response it is able to 
calculate SKEYSEED and SK_* keys. However, it is a good
idea not to do it immeditely, but instead wait for the IKE_AUTH request to come.
The reason is that in case IKE_AUTH request never came (attack, 
network problem etc.), the responder would not spent 
quite a lot of CPU resources calculating D-H shared secret.

However, in this case careless implementations could
discard the just computed SK_* keys if the IKE_AUTH 
request failes to decrypt. This is wrong, because these
key depend only in the information from IKE_SA_INIT 
and there is no reason to discard them once they are computed. 
The text just emphasize this idea.

OK.

> responses for an IKE SA in general is dangerous. There are many

No, there is no advises to limit the number of responses.
There is an advice to delay responce in case of there are too
many requests in order to limit the rate of requests. 
If your implementation relies on an immediate reply and 
no packets loss, then don't follow this advice.

However, I think that if implementations cannot tolerate
2-3 sec delay to requests, then they cannot operate reliably.

> AUTH NULL RFC, but didn't. 

The more general text was included there (Section 3.2), and you were the author :-)

> Perhaps then a separate section for AUTH NULL

I don't think the update is needed. RFC 7619 has already referenced
this document (as a draft) and has warnings that NULL auth
clients are unauthenticated and thus can mount various attacks.

> I'm curious too what others think this is: a "recommendation" or a "change".

I think it is a recommendation.

> See earlier discussion about 1s liveness probes.... It is very common.

As I said above you can ignore this recommendation
if your implementation so deeply relies on quick response.

OK.

OK.

> implementation details, some of which I now want to implement :)

Thank you :-)

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 28 Mar 2016 10:57:52 -0400 (EDT)

On Mon, 28 Mar 2016, Valery Smyslov wrote:

[ cutting a bunch of text since we seem to just disagree about whether
  puzzles are harmful or helpful ]

> Once the responder sent IKE_SA_INIT response it is able to calculate SKEYSEED 
> and SK_* keys. However, it is a good
> The reason is that in case IKE_AUTH request never came (attack, network 
> problem etc.), the responder would not spent quite a lot of CPU resources 
> calculating D-H shared secret.

If we assume cookies take care of spoofed IPs, then an attacker trying
to waste the responders resources would exchange an IKE_INIT round,
and then just send a bunch of IKE_AUTH packets (with proper SPIs) that
all will fail to decrypt. The responder has to try all of them because
it could be a legitimate client. So I'm not sure if you actually buy
anything by postponing the SKEYSEED and SK_* calculation?

> discard the just computed SK_* keys if the IKE_AUTH request failes to 
> decrypt.

Like I said, that would be _really_ stupid. So stupid that I don't think
it needs to go into an RFC. As you have to protect against the attack
I list above anyway.

> many requests in order to limit the rate of requests. If your implementation 
> relies on an immediate reply and no packets loss, then don't follow this 
> advice.

Can you at least put in a small note on the issue of liveness probes and
the risk of delaying these? Eg a 3 probe, 1s each liveness would die in
3 seconds, which seems to be well within the range in which you say
implementations could delay things.

> 2-3 sec delay to requests, then they cannot operate reliably.

I've had long frustrating discussions with Large Clients that run things
that need to failover/restart within seconds, using very flaky third
world networking, and insisting on liveness timers of 1s. It happens :/
Apparently, it is more reliable for them to restart than to wait 30 seconds.

> The more general text was included there (Section 3.2), and you were the 

Oh, I am very fallible :)

> clients are unauthenticated and thus can mount various attacks.

Ohh, you are right. it does reference it already. Still, putting the
"updates" in might work because it will cause an "updated by" clause
to appear at the top of 7619, so people are more convinced they need
to also read this document. But I'll let the chairs weight in on this.

Paul

---

From: "Valery Smyslov" <[email-masked]>
Date: Mon, 28 Mar 2016 18:19:30 +0300

> anything by postponing the SKEYSEED and SK_* calculation?

Postponing SKEYSEED and SK_* calculation saves your resources
if IKE_AUTH request never come. It can be if there are some network
problems (for example, the IKE_AUTH message is too long, get fragmented
by IP and dropped by NAT, and the initiator doesn't support IKE fragmentation)
or if the initiator never mind to send IKE_AUTH (i.e. it is an attack 
on half-open SAs, that could be even with cookies - in case of botnets).

> it needs to go into an RFC. As you have to protect against the attack

Mostly yes. However in some cases it is not so stupid. If you do all crypto in hardware
and this hardware may handle limited number of key handles, then
you'd probably discard the keys in this case not to exhaust crypto HW memory.
In this case you'll recalculate them once new IKE_AUTH arrives.
This a tradeoff and the draft recommends (with SHOULD) to keep the keys.

OK.

Regards,
Valery.

---

From: Paul Wouters <[email-masked]>
Date: Mon, 28 Mar 2016 11:26:36 -0400 (EDT)

On Mon, 28 Mar 2016, Valery Smyslov wrote:

> if IKE_AUTH request never come.

But if the attacker wants to exhaust your cpu, they _will_ come back
with a /dev/random filled IKE_AUTH request.

> It can be if there are some network
> or if the initiator never mind to send IKE_AUTH (i.e. it is an attack on 
> half-open SAs, that could be even with cookies - in case of botnets).

That's not really a ddos protection. It's more of a common sense thing.

> This a tradeoff and the draft recommends (with SHOULD) to keep the keys.

Ok, I guess I feel it is a bit of a stretch away from "ddos defense" and
more of a "core implementation sanity", but I guess that line is a
little subjective, and I guess a paragraph extra won't hurt the
document.

Paul