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