Subject: Re: [IPsec] IPsec Digest, Vol 123, Issue 21

From: Les Leposo <[email-masked]>
Date: Sat, 16 Aug 2014 12:48:13 +0300

Hi

some points of discussion below.

On Jul 31, 2014, at 7:19 PM, [email-masked] wrote:

> Send IPsec mailing list submissions to
> 	[email-masked]
> 
> To subscribe or unsubscribe via the World Wide Web, visit
> 	https://www.ietf.org/mailman/listinfo/ipsec
> or, via email, send a message with subject or body 'help' to
> 	[email-masked]
> 
> You can reach the person managing the list at
> 	[email-masked]
> 
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of IPsec digest..."
> 
> 
> Today's Topics:
> 
>   1. Re: Puzzles draft - another idea (Paul Wouters)
>   2. Re: Puzzles draft - another idea (Yaron Sheffer)
>   3. Confusion about NAT traversal in RFC5996 (Zhenjie Huang)
> 
> 
> ----------------------------------------------------------------------
> 
> Message: 1
> Date: Wed, 30 Jul 2014 15:02:56 -0400 (EDT)
> From: Paul Wouters <[email-masked]>
> To: Yoav Nir <[email-masked]>
> Cc: ipsec <[email-masked]>
> Subject: Re: [IPsec] Puzzles draft - another idea
> Message-ID: <[email-masked]>
> Content-Type: TEXT/PLAIN; charset=windows-1252; format=flowed
> 
> On Wed, 30 Jul 2014, Yoav Nir wrote:
> 
>> Suppose our half-open SA table can hold 100,000 entries and we clear them out after 10 seconds. That allows 10,000 entries per
>> second. More realistic number are 18 bits for the iPhone and 20 bits for the attacker, so to block out those iPhones, the attacker
>> would have to perform 10,000 * 2^20 SHA-256 hashes per second, or about 10 billion hashes. That?s about 400 server-class hardware
>> working full-time, or a 10,000-way botnet. The draft is all about increasing the work for the attacker, and I believe this is doing
>> it well. The baseline is sending 20,000 packets per second while only copying the cookie (no PK or hash operations at all).
>> 
>> It is possible to do as in the current draft, and set a single difficulty level (say, 18 bits). This allows the attacker a nice and
>> deterministic way to keep the half-open SA table full, which blocks out all clients, not just the iPhones.?
> 
> The iphone (which is only rumored to do IKEv2 with iOS8 likely to be
> released in September this year) currently has a
> terrible record of continuously re-establishing connections. Like
> whenever the screen saver hits it will tear down the tunnel. With
> an always-on profile, that means if I unblanc the screen, it will
> start a new IKE session.
> 
ikev2 "session resumption" promised some improvements over ikev1 - frankly that is part of the spec that needs to be 'MUST' and not 'SHOULD', for all servers.

> A scheme like this would drain the battery on top of the current
> re-establishing draining, that already prevents me from using an
> always-on profile - my iphone won't last for 4 hours.
> 
> Perhaps we should look at other types of puzzles that do not depend on
> raw CPU power?
Great question.

imho, if the hash calculations (and ike) are a big enough culprits, then perhaps the mobile SoC folks should consider bringing onboard IP that  accelerates/offloads the hash calculations (and other aspects of ike) to more energy efficient component/sub-system?

Or, a crazier idea... find ways to permit/standardise some types of cheating at the peers.
e.g. By allow "scripted/seeded" connections to be established and policed. i.e. peers are negotiating using a "scripted" sequence of nonces, hashes, e.t.c,
As follows:
- The client 1st connects to a trusted entity, gets the "script/seeds", which is also (concurrently) pushed down to the ikev2 server (may be the same machine). 
	- The peers need to store these "scripts/seeds" securely (i.e. sandboxing is a must).
	- The trusted entity needs to be very fast (probably with hardware acceleration) at generating these "scripts/seeds". Perhaps a new product category for servers.
- Then the client and server do the scripted dance all day - which is more energy efficient but results in a tunnel should be policed (as less secure than "unscripted" connections).

some $.02

> 
> Paul
> 
> 
> 
> ------------------------------
> 
> Message: 2
> Date: Wed, 30 Jul 2014 12:12:20 -0700
> From: Yaron Sheffer <[email-masked]>
> To: Yoav Nir <[email-masked]>
> Cc: ipsec <[email-masked]>
> Subject: Re: [IPsec] Puzzles draft - another idea
> Message-ID: <[email-masked]>
> Content-Type: text/plain; charset=utf-8; format=flowed
> 
> Makes sense to me.
> 
> 	Yaron
> 
> On 07/30/2014 11:45 AM, Yoav Nir wrote:
>> Hi, Yaron
>> 
>> Suppose our half-open SA table can hold 100,000 entries and we clear
>> them out after 10 seconds. That allows 10,000 entries per second. More
>> realistic number are 18 bits for the iPhone and 20 bits for the
>> attacker, so to block out those iPhones, the attacker would have to
>> perform 10,000 * 2^20 SHA-256 hashes per second, or about 10 billion
>> hashes. That?s about 400 server-class hardware working full-time, or a
>> 10,000-way botnet. The draft is all about increasing the work for the
>> attacker, and I believe this is doing it well. The baseline is sending
>> 20,000 packets per second while only copying the cookie (no PK or hash
>> operations at all).
>> 
>> It is possible to do as in the current draft, and set a single
>> difficulty level (say, 18 bits). This allows the attacker a nice and
>> deterministic way to keep the half-open SA table full, which blocks out
>> all clients, not just the iPhones.
>> 
>> Yoav
>> 
>> On Jul 30, 2014, at 6:40 PM, Yaron Sheffer <[email-masked]
>> <mailto:[email-masked]>> wrote:
>> 
>>> Hi Yoav,
>>> 
>>> this is a nice idea, but I think it actually performs worse than the
>>> baseline.
>>> 
>>> With the previous solution all clients had to expend the same number
>>> of cycles, but would be served FCFS so from time to time, the "good"
>>> ones would be served. With this proposal the attacker can push out the
>>> legitimate weak clients in a *deterministic* way. If I know all Check
>>> Point iPhone clients do 10 bits (I assume most implementations will
>>> choose a value and stick to it, because they do not have any
>>> information about the effort currently needed), I will configure my
>>> botnet to always do 11, and push out any legitimate clients.
>>> 
>>> Thanks,
>>> Yaron
>>> 
>>> On 07/30/2014 07:45 AM, Yoav Nir wrote:
>>>> Hi all
>>>> 
>>>> After the meeting on Friday, I talked to Tero and Brian Weis, and Tero
>>>> suggested a different sort of puzzle that could make it easier to
>>>> support both strong and weak clients. This is sort of like the
>>>> proof-of-work used by BitCoin.
>>>> 
>>>> 1. Calculate the cookie as before. For an example, let?s assume the
>>>>   cookie is fdbcfa5a430d7201282358a2a034de0013cfe2ae (20 octets).
>>>> 2. A ?legacy? initiator will return this exact cookie.
>>>> 3. A newer initiator will return the cookie, with some extra bytes.
>>>> 4. The ?value? of a returned cookie is determined by the number of
>>>>   trailing zero bits in the SHA-256 hash of the transmitted cookie:
>>>> 
>>>>   Cookie || extra data
>>>> 
>>>>   hash
>>>> 
>>>>   # trailing zero bits
>>>>   fdbcfa5a430d7201282358a2a034de0013cfe2ae
>>>> 
>>>>   ec2f327dae577a31152e3de2ac0f2f798e21f02e1afb04d33ff79bdd5d30eede
>>>> 
>>>>   1
>>>>   fdbcfa5a430d7201282358a2a034de0013cfe2ae0182
>>>> 
>>>>   71d3e8c09fbb8db5315e6364dce3ebd56ad35c96e284296e2ffffa256bdfa800
>>>> 
>>>>   11
>>>>   fdbcfa5a430d7201282358a2a034de0013cfe2ae022b3d
>>>> 
>>>>   3b4bdf201105e059e09f65219021738b8f6a148896b2e1be2fdc726aeb6e0000
>>>> 
>>>>   17
>>>>   fdbcfa5a430d7201282358a2a034de0013cfe2ae0aa679
>>>> 
>>>>   c352e914a41615496e3498e5ecb87b992be1ad40620f48af85428996c1f00000
>>>> 
>>>>   20
>>>>   fdbcfa5a430d7201282358a2a034de0013cfe2ae5c2880
>>>> 
>>>>   155319280d687074d0f78511f63c77c568a5418dd44e6467d8fc37723d800000
>>>> 
>>>>   23
>>>>   fdbcfa5a430d7201282358a2a034de0013cfe2ae022bffc8
>>>> 
>>>>   6469faf4455cf9a51b04edeea8195f27771d56b95f2d874764a71e2948000000
>>>> 
>>>>   27
>>>> 
>>>> 
>>>> 5. Initiators are limited (by the construction of the cookie) in the
>>>>   amount of time they can spend. So powerful clients will manage 23
>>>>   bits, while weaker clients will only manage 17.
>>>> 6. When an Initial request arrives with a cookie, first the first 20
>>>>   bytes are validated, and then the result is queued by ?value?.
>>>> 7. When the responder can handle a packet (has room in the half-open SA
>>>>   table) it processes the entry with the highest value in the queue.
>>>>   Entries expire after some time even if not handled.
>>>> 
>>>> 
>>>> I think if this algorithm is chosen, an attacker can still expend little
>>>> effort, get some 5-6 bits, and use that to push out all legacy clients.
>>>> We could counter that by having a minimum threshold at something like
>>>> 10-12 bits, some value that all supported platforms can easily manage in
>>>> under 0.5 seconds, and consider all values below that to be equal to
>>>> zero (not enough effort to matter).
>>>> 
>>>> This could get some more tweaks. But what do people think of this?
>>>> 
>>>> Thanks
>>>> 
>>>> Yoav
>>>> 
>>>> P.S. This is the first time I tried to send a table pasted into Apple
>>>> Mail to a mailing list. I apologize in advance if it comes out looking
>>>> horrific.
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> IPsec mailing list
>>>> [email-masked] <mailto:[email-masked]>
>>>> https://www.ietf.org/mailman/listinfo/ipsec
>> 
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Thu, 31 Jul 2014 16:19:22 +0000
> From: Zhenjie Huang <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> Subject: [IPsec] Confusion about NAT traversal in RFC5996
> Message-ID:
> 	<[email-masked]>
> Content-Type: text/plain; charset="us-ascii"
> 
> 
> Dear IPsec experts,
> 
> I am a System Engineer from Ericsson.
> I am currently reading your RFC5996. However, I feel confused with the following words about NAT traversal:
> 
> Section 2.23:
> A host behind a NAT SHOULD NOT do this type of dynamic address update if a validated packet has
> different port and/or address values because it opens a possible DoS attack (such as allowing an
> attacker to break the connection with a single packet).
> 
> It is very difficult to understand this case. Could you give me some hint why it opens a possible DoS attack when the host is behind a NAT?
> Your different opinions are really appreciated for my better understanding. Thank you very much!
> 
> Kind regards,
> Jerry Huang
> 
> 
> [Ericsson]<http://www.ericsson.com/>
> 
> ZHENJIE HUANG
> System Engineer
> CGC/X
> 
> Ericsson
> 13/F, ShuGuang Building, Nanshan
> Shenzhen, China
> Phone 0755-86925204
> Mobile 18576627893
> [email-masked]
> www.ericsson.com
> 
> 
> [http://www.ericsson.com/current_campaign]<http://www.ericsson.com/current_campaign>
> 
> Legal entity: N/A, registered office in N/A. This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL: <http://www.ietf.org/mail-archive/web/ipsec/attachments/20140731/7b167a7a/attachment.html>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: image001.gif
> Type: image/gif
> Size: 2367 bytes
> Desc: image001.gif
> URL: <http://www.ietf.org/mail-archive/web/ipsec/attachments/20140731/7b167a7a/attachment.gif>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: image002.gif
> Type: image/gif
> Size: 22330 bytes
> Desc: image002.gif
> URL: <http://www.ietf.org/mail-archive/web/ipsec/attachments/20140731/7b167a7a/attachment-0001.gif>
> 
> ------------------------------
> 
> Subject: Digest Footer
> 
> _______________________________________________
> IPsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> 
> ------------------------------
> 
> End of IPsec Digest, Vol 123, Issue 21
> **************************************

---

From: Yoav Nir <[email-masked]>
Date: Sun, 17 Aug 2014 16:27:43 +0300

> imho, if the hash calculations (and ike) are a big enough culprits, then perhaps the mobile SoC folks should consider bringing onboard IP that  accelerates/offloads the hash calculations (and other…

That’s just an arms race. If phones get specialized hardware that can do 2^25 hashes in a second, the attackers can get such hardware too, and we’ll have to turn up the difficulty to 25 bits. Older hardware (like older phones and computers) will suffer.

Yoav

---

From: Les Leposo <[email-masked]>
Date: Sun, 17 Aug 2014 18:04:29 +0300

> That’s just an arms race. If phones get specialized hardware that can do 2^25 hashes in a second, the attackers can get such hardware too, and we’ll have to turn up the difficulty to 25 bits. Older…
Great point, though a hinted point was that the hash speed remains similar while the power spent is reduced.

---

From: Tero Kivinen <[email-masked]>
Date: Mon, 18 Aug 2014 17:44:20 +0300

Les Leposo writes:
> ikev2 "session resumption" promised some improvements over ikev1 -
> frankly that is part of the spec that needs to be 'MUST' and not
> 'SHOULD', for all servers.

You do not need session resumption for that. You just need properly
done implementation. Unfortunately lots of IKEv2 implementations use
dead peer detection as periodic keepalive messages, instead of just
using it to verify whether the other end is alive or not.

If dead peer detection is implemented properly, as is described in the
rfc5996, the device can safely go to sleep if there is no traffic
going between the client and server, and when it wakes up from the
sleep the IKEv2 connection will still be there, and the other end has
not teared down the IKE SA (provided there was nothing that would have
caused it to try to send traffic to the sleeping node).

Unfortunately lots of devices send dead peer messages all the time
every n seconds, and if device is sleeping during that time, they will
tear down the IKE SA. This is broken implementation, not problem in
the protocol.

Yes, session resumption is even better, as it will allow telling the
other end, that don't even bother trying to send to me anything, I am
sleeping, but quite a lot can also be done if the implementations are
done properly.

If course if the device is not really sleeping, i.e. you just blank
the screen, and are still able to receive and send packets, then there
is no point of tearing down the IKE SA. 

> imho, if the hash calculations (and ike) are a big enough culprits,
> then perhaps the mobile SoC folks should consider bringing onboard
> IP that accelerates/offloads the hash calculations (and other
> aspects of ike) to more energy efficient component/sub-system?
> 
> e.g. By allow "scripted/seeded" connections to be established and
> policed. i.e. peers are negotiating using a "scripted" sequence of
> nonces, hashes, e.t.c, 
> As follows:
> - The client 1st connects to a trusted entity, gets the
> "script/seeds", which is also (concurrently) pushed down to the
> ikev2 server (may be the same machine).  
> 	- The trusted entity needs to be very fast (probably with
> hardware acceleration) at generating these "scripts/seeds". Perhaps
> a new product category for servers. 
> - Then the client and server do the scripted dance all day - which
> is more energy efficient but results in a tunnel should be policed
> (as less secure than "unscripted" connections). 

And of course you log in to the trusted entity using IPsec :-)

I mean if you are going to add very fast trusted entity providing the
scripts/seeds to devices, it is much better to just add more hardware
to your SGW device, so it can process 10,000 requests per second
instead of 100.

Also add some extra memory, so you can use it store hash table of
recent connections. I.e. when connection comes in you check whether it
is in on the recent connections table. If so you drop connection,
otherwise you send cookie/puzzle. When it comes back with proper
cookie/puzzle, you put it on the recent connections hash table and
continue IKEv2. When the IKEv2 connection finishes with
authentication, you remove the entry from the recent connections
table. If the authentication fails with IKEv2 authentication failure,
you slow down the response for the next time for 1 seconds, for the
second time 2 seconds, and so on.

I.e. the recent connections table has list of IP-address who have
tried to connect to you, but have not yet authenticated, i.e. either
real devices in the middle of authentication, or attackers. The real
devices in the middle of authentication will not try to reconnect, as
they are still continuing the process.

This means attacker needs one new routable IP-address for each attack.
So to send 100 new IKEv2 connection attacks to the SGW for an hour,
the attacker needs 30,000 botnet machines. To keep the same attack up
for 24 hours, it needs 720,000 machines etc. To keep it up for week
they need 5 million botnet machines. At that point the server need few
tens of megabytes of memory to keep the list of blacklisted
IP-addresses.

On the other hand 100 connections seconds should not yet cause DoS on
the SGW (that would be normal monday morning problem rate, and server
should be able to cope with that without dropping connections), so for
attacker to be able to block real users out, would most like 100 times
more connections per second. I.e. to block server for hour, they would
need 10,000 connections per second, and 3 million separate botnet
machines. 

Of course with IPv6 you most likely want to keep the /64 prefix in the
hash table, not for the whole IP-address, and for the IPv4 you can
mask out the lower 4 bits or something.

And of course you most likely you can also keep whitelist of known
IP-addresses which have done successfull authentication against the
SGW in last week or so, and those would always be allowed to be
processed first. This way even with those kind of DoS attacks, the
employees home machine, which have stable IP-address would still be
able to connect.
-- 
[email-masked]

---

From: Paul Wouters <[email-masked]>
Date: Mon, 18 Aug 2014 12:33:57 -0400 (EDT)

> caused it to try to send traffic to the sleeping node).

If the server has enough resources, yes. It should not kill clients with
dpd.

> is no point of tearing down the IKE SA.

could someone at apple please relay this! This is stupidly draining my
battery :P

> they are still continuing the process.

You would need the port number too to support multple clients behind the
same NAT router, upon which the attacker can then use multiple ports too.

> This means attacker needs one new routable IP-address for each attack.

for each 65k attacks.

Paul

---

From: Les Leposo <[email-masked]>
Date: Mon, 18 Aug 2014 20:23:19 +0300

> sleeping, but quite a lot can also be done if the implementations are

have you overlooked the issue of nat mappings?

ipsec nat keepalives are very useful for keeping nat mappings alive, and in a world full of all sorts of nat devices (some behaving reliably and others not), one would have to use low keepalive interval... like 10-60s.

Now, today's client devices need to be energy efficient - so the device sleeps/hibernates to save battery.
Sleeping past the nat keepalives is bound to happen (either by design or error).
At some point the device will wake from sleep and need to test reachability using dpd.

And in some cases (if the sleep was more than a certain threshold), rather than wait for dpd to failover, the choice is to go for rekey.

For many implementors and admins (and probably the protocol designers), the end primary goal has always been a reliable tunnel that is reliable, but this has come at the expense of battery consumption.

The battery consumption of iphone ike is probably better than other devices, but as a whole the protocol probably needs to emphasise energy efficient implementation/design (while ensuring that parts of the spec that are energy efficient (or performance boosting) are MUST and not SHOULD for servers).

> is no point of tearing down the IKE SA. 
ok, that sounds like a misconfig or bug in the IKE SA rekey.

---

From: Les Leposo <[email-masked]>
Date: Mon, 18 Aug 2014 20:31:08 +0300

> could someone at apple please relay this! This is stupidly draining my
do you know if it is an IKE SA rekey and if so, who is actually initiating it?

---

From: Paul Wouters <[email-masked]>
Date: Mon, 18 Aug 2014 13:52:05 -0400 (EDT)

> do you know if it is an IKE SA rekey and if so, who is actually initiating it?

the entire ipsec system is brought down/up, eg racoon is completely
killed and restarted all the time.

Paul

---

From: Les Leposo <[email-masked]>
Date: Tue, 19 Aug 2014 11:26:57 +0300

> killed and restarted all the time.
Sounds like a totally reproducible crash/signal.

I'm sure if you file a radar with the procedure of how to reproduce (including connection duration & user activity), may be even a test account on your server, a developer on that end can gdb their way to the fix.

You would also have to indicate how long this problem has been happening e.g. years/months, ios versions (to identify regressions).

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 19 Aug 2014 13:24:45 +0300

> same NAT router, upon which the attacker can then use multiple ports too.

No need for port number. If server is under attack just block / slow
down everybody using the same IP-address (or IP-address mask).

This will block real users out if they are behind the same NAT than
the attacker... On the other hand then the user should fix his home
windows and get rid of the botnet running there :-)

> > This means attacker needs one new routable IP-address for each attack.

Nope, one address per attack as you do not store port number (and not
perhaps even full IP-address, especially in IPv6). 
-- 
[email-masked]

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 19 Aug 2014 13:39:50 +0300

> have you overlooked the issue of nat mappings?

Nope.

> ipsec nat keepalives are very useful for keeping nat mappings alive,
> and in a world full of all sorts of nat devices (some behaving
> reliably and others not), one would have to use low keepalive
> interval... like 10-60s. 

IPsec NAT-T keepalives are completely different thing than DPD.

IPsec NAT-T keepalives are packets sent by the device behind the NAT
as specified in the RFC3948 section 2.3. The responder SHOULD ignore
the received NAT-keepalive packet, and MUST NOT be used to detect
whether a connection is live (RFC 3948 section 4). Only device behind
the NAT sends them and other end does not respond to them, or send its
own keepalives (unless it is also behind NAT).

The dead peer detection (DPD) or liveness check is a procedure
specified in the RFC5996 section 2.4 where it says that:

	... If there has only been outgoing traffic on all of
   the SAs associated with an IKE SA, it is essential to confirm
   liveness of the other endpoint to avoid black holes.  If no
   cryptographically protected messages have been received on an IKE SA
   or any of its Child SAs recently, the system needs to perform a
   liveness check in order to prevent sending messages to a dead peer.
   (This is sometimes called "dead peer detection" or "DPD", although it
   is really detecting live peers, not dead ones.)  Receipt of a fresh
   cryptographically protected message on an IKE SA or any of its Child
   SAs ensures liveness of the IKE SA and all of its Child SAs.

This is done by sending empty INFORMATIONAL message to the other end,
and if there is response to it then other end is up and running. You
are supposed to do this only when you suspect something is wrong, i.e.
the traffic changed to be one way (i.e. no packets coming back), or
you get ICMP or unauthenticated notify payload or similar.

> Now, today's client devices need to be energy efficient - so the
> device sleeps/hibernates to save battery. Sleeping past the nat
> keepalives is bound to happen (either by design or error). At some
> point the device will wake from sleep and need to test reachability
> using dpd.

Yes, if the device sleeps a long time, it should check whether the IKE
SA is still up by using DPD. This has nothing to do with the NAT
keepalives. 

> And in some cases (if the sleep was more than a certain threshold),
> rather than wait for dpd to failover, the choice is to go for rekey.

Rekey is not an option, as that would require the IKE SA to still be
up. I think you mean startting the IKE SA from the beginning. If the
device has been sleeping for long time, and it suspects the IKE SA is
gone, it might try shorter period for the DPD, i.e. send few retries
for the empty INFORMATIONAL message and if no response is received,
then fall back to start the IKE SA from the beginning.

The device of course needs to first wait that the network is up again
before doing this test, as when you wake up from the sleep, the device
most likely needs to find the wifi network again, do DHCP, perhaps
even do hotel login page etc before it can actually send any packets
to network, and doing DPD during that time, would certainly fail, even
when the other end would still be there. 

It is important to remember what are the fundamental restrictions set
by the protocol, and which issues are just caused by bad
implementations. Quite a lot of the problems we are seeing are caused
by bad implementations... 
-- 
[email-masked]

---

From: Les Leposo <[email-masked]>
Date: Tue, 19 Aug 2014 17:31:28 +0300

> SA is still up by using DPD. This has nothing to do with the NAT

Paul's concerns centred around chattiness and the client-side energy cost of this chattiness.
Hence, I offered some suggestion for reducing the energy cost of the chattiness, while probing down the path of DPD, and rekeys to get to the root of the high chattiness.

Paul's ios issue seems pathological - linked to the ike daemon crashing or being signalled. But unless there is a gold standard implementation that can maintain tunnels like all week (on a single charge) we can't just stop at poor-implementation=low-battery.

But let me explain why I ventured into Keepalives and DPD.
Keepalives help maintain the network path. In their absence, the network path (from the server's point of view) will likely change (particularly in today's world full of crappy nats and ip oversubscription, made worse by multi-connection web pages and apps).

If mobile device sleeps a long time, the likelihood that device wakes to a network path change is significant. Aside from pure blackouts, black holes and Source IP changes, Source Port address changes will cause issues for some servers/configurations. 

Hence dpd is increasingly used to verify both path and peer, both by design (e.g. upon waking just do dpd, or upon waking daemon kicks off dpd if it sees outgoing esp traffic and no incoming esp traffic) and by configuration. As of ios 4 & 5, i'm sure the iphone ike did the former approach, and many admins do the latter.
Same goes for wake, where the daemon has to wait for the interface to return (and verify the underlying network) before trying DPD, ios 4 & 5 did that.

Keepalives and DPD were merely a small illustration of the larger issue which is that in todays real world network conditions, maintaining the tunnel is a challenge.
Protocol chattiness increases as the client daemon adapts (itself or by the developer) to the lowest common denominator (the crappy nat, the roadside motel wifi, oversubscribed cell data network, or city apartment 'high interference' wifi, or the buggy/misconfigured server).
Hence I kept probing down the path of DPD, and rekeys because Paul's concerns centered around chattiness and .

Even with good implementation of the latest ikev2 spec, the lowest common denominator will demand more energy. And so, spec tweaks and creative (supplementary) drafts/standards are needed (aside from additional server-side hardware investment)

1) Session Resumption ... ikev2 MUST (not SHOULD) both as tools for handling post wake/crash recovery.
2) MOBIKE & correct handling of Source Port Address Changes ... MUST (... the latter should have been a MUST for Ikev1).
3) additional IKEv2 drafts/standards to create 'very low cal' clients and improve handling of path mtu (.... another effect of the lowest common denominator). These 'very low cal' clients will also be chatty, but consume less because more of the ike operations are offloaded to the high capacity server.
4) Strategies for dealing with network/sleep/wake events crash-recovery and energy conservation... perhaps as drafts or design guidelines to improve the standard of all ikev2 implementations.

> then fall back to start the IKE SA from the beginning.
For your choice of algorithm, the lowest common denominators will always experience delays in connecting because the DPD retries max out more often than not. Just pointing that out.

> when the other end would still be there. 
Correct, ios 4 & 5 used to do these sort of things. I'm not sure about other smartphones.

> by bad implementations... 

Not solely. the network then isn't the same now. Back then the lowest common denominator was a laptop connected through a cell modem or campus wifi network, path mtu wasn't bad, certificate payloads weren't big.

Now it is a power-constrained smartphone connected to a high-loss oversubscribed network. Some of the issues that weren't important/visible then are now significant (e.g. source address/port changes are very common, large certificate payloads commonplace & their interaction with small or changing path mtu is an obstacle, detecting local ip address changes alone isn't enough... you might get the same address back but your ports/gw/dns changed).

---

From: Yoav Nir <[email-masked]>
Date: Tue, 19 Aug 2014 17:32:09 +0300

> And in some cases (if the sleep was more than a certain threshold), rather than wait for dpd to failover, the choice is to go for rekey.

It depends which standards you’ve implemented. If you’ve implemented QCD (RFC 6290), then DPD fails or succeeds immediately as long as you have connectivity, and it doesn’t make sense to go directly to a new Initial exchange. 

AFAIK racoon doesn’t have that. Maybe it has session tickets, which make the Initial exchange lighter.

Of course, wiping all state every time you blank the screen is (if true) a very weird implementation choice. 

Yoav

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Aug 2014 10:42:29 -0400 (EDT)

> down everybody using the same IP-address (or IP-address mask).

Works great with CGN :P

Paul

---

From: Paul Wouters <[email-masked]>
Date: Tue, 19 Aug 2014 10:43:59 -0400 (EDT)

> You would also have to indicate how long this problem has been happening e.g. years/months, ios versions (to identify regressions).

Years ago I tried to file bug reports for IPsec to Apple. No feedback
ever, and lots of "developer" spam email.

If Apple cares, they can contact me to convince me the process changed.
But from what I'm hearing, if you're not doing millions in revenue, you
don't really get their attention whatsoever.

Paul

---

From: Les Leposo <[email-masked]>
Date: Tue, 19 Aug 2014 17:48:00 +0300

On Aug 19, 2014, at 5:32 PM, Yoav Nir <[email-masked]> wrote:

> It depends which standards you’ve implemented. If you’ve implemented QCD (RFC 6290), then DPD fails or succeeds immediately as long as you have connectivity,
RFC 6290 is ikev2 2011, Pauls complaint is regarding ikev1/ikev2... not sure. If ikev1, then we're beating a dead horse.
But if ikev2, then my point still stands that the appropriate use of 'MUST'.

> and it doesn’t make sense to go directly to a new Initial exchange. 
> 

What if the IKE SA was nearing expiry, and/or the server initiated a rekey while you were asleep.

> Of course, wiping all state every time you blank the screen is (if true) a very weird implementation choice. 
Do you mean screen lock?

---

From: Les Leposo <[email-masked]>
Date: Tue, 19 Aug 2014 17:56:16 +0300

> ever, and lots of "developer" spam email.
How long ago? 

Is this around the question of keeping the tunnel up while the screen is passcode-locked (as alluded by Yoav)?

And do you have the radar numbers?

---

From: Yoav Nir <[email-masked]>
Date: Tue, 19 Aug 2014 18:11:47 +0300

On Aug 19, 2014, at 5:48 PM, Les Leposo <[email-masked]> wrote:

> But if ikev2, then my point still stands that the appropriate use of 'MUST’.

I think that a remote access gateway that services battery-sensitive devices should allow a lot of time before initiating its own DPD. Unfortunately, there is no way for a gateway to communicate to the client “if you’ve been silent for X seconds, you can assume that I’ve started a DPD and probably killed your IKE SA”.

> What if the IKE SA was nearing expiry, and/or the server initiated a rekey while you were asleep.

Under IKEv2 rules, the rekey failed and the old IKE SA is gone. It’s OK that it happened, It’s only a matter of detecting this efficiently.

>> Of course, wiping all state every time you blank the screen is (if true) a very weird implementation choice. 

If that’s what it is called on an iPhone (I don’t have one). I mean whatever makes the screen go blank so that you need to press a button and swipe the screen in some direction, optionally including a code. 

Yoav

---

From: Les Leposo <[email-masked]>
Date: Tue, 19 Aug 2014 19:10:58 +0300

> Under IKEv2 rules, the rekey failed and the old IKE SA is gone. It’s OK that it happened, It’s only a matter of detecting this efficiently.

yup

> If that’s what it is called on an iPhone (I don’t have one). I mean whatever makes the screen go blank so that you need to press a button and swipe the screen in some direction, optionally includin…
Not the official term. It is a screen lock because  the user was logged out and you would have to log back in.

I haven't used ios vpn in almost 2 years.
I believe that can be tweaked either by a setting on the Gateway policies or on ios provisioning profile.
But it sounds like a system level security policy/decision. Not necessarily directly related to the ike daemon (perhaps another part of the system).
I hate to keep theorising on Paul's issue, but it might be that the Screen lock/unlock is indirectly triggering a signal/crash on the ike daemon.

---

From: Tero Kivinen <[email-masked]>
Date: Tue, 19 Aug 2014 19:44:37 +0300

> > down everybody using the same IP-address (or IP-address mask).

Yes, blocks the nicely. Just what they asked for... :-)

On the other hand CGD should notice if there is widespread DoS attack
done through it, and hopefully someone will block those attacks in
there... Those attacks will consume quite a lot of resources on the
CGD so operators would actually like to block them.
-- 
[email-masked]

---

From: Les Leposo <[email-masked]>
Date: Tue, 19 Aug 2014 20:42:09 +0300

> don't really get their attention whatsoever.
That's an interesting take.

Imho, generally, part of the issue with ikev2 (circa 2011-2012), no one really knew where ike/ipsec it was going in enterprise (aside from the 3GPP area which was considered niche and not worthy of the attention it deserved).

Back then, SSL VPN was the shiny toy that dev managers & customers wanted, especially because it was easy to develop, a new opportunity for revenue stream, and the enterprise server vendors had made it so easy to deploy (e.g. you install the app and go to a webpage to log in and download your configs); completely overlooking significant weaknesses (and those of its library implementations).