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

[Les Leposo <[e-mail]>]

Hi

some points of discussion below.

On Jul 31, 2014, at 7:19 PM, [e-mail] wrote:

> Send IPsec mailing list submissions to
> 	[e-mail]
> 
> 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
> 	[e-mail]
> 
> You can reach the person managing the list at
> 	[e-mail]
> 
> 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 <[e-mail]>
> To: Yoav Nir <[e-mail]>
> Cc: ipsec <[e-mail]>
> Subject: Re: [IPsec] Puzzles draft - another idea
> Message-ID: <[e-mail]>
> 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 <[e-mail]>
> To: Yoav Nir <[e-mail]>
> Cc: ipsec <[e-mail]>
> Subject: Re: [IPsec] Puzzles draft - another idea
> Message-ID: <[e-mail]>
> 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 <[e-mail]
>> <mailto:[e-mail]>> 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
>>>> [e-mail] <mailto:[e-mail]>
>>>> https://www.ietf.org/mailman/listinfo/ipsec
>> 
> 
> 
> 
> ------------------------------
> 
> Message: 3
> Date: Thu, 31 Jul 2014 16:19:22 +0000
> From: Zhenjie Huang <[e-mail]>
> To: "[e-mail]" <[e-mail]>
> Subject: [IPsec] Confusion about NAT traversal in RFC5996
> Message-ID:
> 	<[e-mail]>
> 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 [phone]
> Mobile [phone]
> [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ipsec
> 
> 
> ------------------------------
> 
> End of IPsec Digest, Vol 123, Issue 21
> **************************************