From nobody Sat Aug 16 02:48:25 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25FB21A8724 for ; Sat, 16 Aug 2014 02:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.155 X-Spam-Level: ** X-Spam-Status: No, score=2.155 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FU_ENDS_2_WRDS=0.255, J_CHICKENPOX_31=0.6, J_CHICKENPOX_41=0.6, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8rTnhi5S3Wqh for ; Sat, 16 Aug 2014 02:48:21 -0700 (PDT) Received: from mail-we0-x235.google.com (mail-we0-x235.google.com [IPv6:2a00:1450:400c:c03::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EED481A8720 for ; Sat, 16 Aug 2014 02:48:20 -0700 (PDT) Received: by mail-we0-f181.google.com with SMTP id k48so3103770wev.26 for ; Sat, 16 Aug 2014 02:48:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=etl+CyPaHoD+77nQ+qjTC5eRM2tiFEbCp9ahFAHB55U=; b=cfyFHv044JvmdC8L/tiFHiz/BnX4a51ZPkMOfR9Ccpt8j/FN5+SkRBZXDTwyANIwrp xntWYsL8YQnka+4f8jR+0Nw1RMbEclQ8AIJCl0u0SvPV9ot+eo0V7WRfvCqVy1FKGNow vjYPdtcJd+e/3RSPacmDaV4s5pVDiEfqhdusT8C3aQstW+4S9doQhgaLaxKpENS82xKp VTNovhnPx3f3ng5uIa9gwNf7xMIXeLOo+g8bPv8S19zklKvbUS4OwnhjBFY1tD9auVs6 +4PmtTAaR+6rRLtVPG6mCf4QH0wTWkNSCfpH5NuIEtMshgoA7FUACcMcsUVi28/0QR/C jtwA== X-Received: by 10.180.206.38 with SMTP id ll6mr27221290wic.40.1408182499531; Sat, 16 Aug 2014 02:48:19 -0700 (PDT) Received: from [192.168.0.17] ([197.237.48.207]) by mx.google.com with ESMTPSA id wr6sm25357324wjc.24.2014.08.16.02.48.17 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 16 Aug 2014 02:48:18 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Les Leposo In-Reply-To: Date: Sat, 16 Aug 2014 12:48:13 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: ipsec@ietf.org X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/a45yHcg-gV5nHfnLurzdQNSOm_o Subject: Re: [IPsec] IPsec Digest, Vol 123, Issue 21 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Aug 2014 09:48:23 -0000 Hi some points of discussion below. On Jul 31, 2014, at 7:19 PM, ipsec-request@ietf.org wrote: > Send IPsec mailing list submissions to > ipsec@ietf.org >=20 > 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 > ipsec-request@ietf.org >=20 > You can reach the person managing the list at > ipsec-owner@ietf.org >=20 > When replying, please edit your Subject line so it is more specific > than "Re: Contents of IPsec digest..." >=20 >=20 > Today's Topics: >=20 > 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) >=20 >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Wed, 30 Jul 2014 15:02:56 -0400 (EDT) > From: Paul Wouters > To: Yoav Nir > Cc: ipsec > Subject: Re: [IPsec] Puzzles draft - another idea > Message-ID: > Content-Type: TEXT/PLAIN; charset=3Dwindows-1252; format=3Dflowed >=20 > On Wed, 30 Jul 2014, Yoav Nir wrote: >=20 >> 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). >>=20 >> 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.? >=20 > 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. >=20 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. >=20 > 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).=20 - 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 >=20 > Paul >=20 >=20 >=20 > ------------------------------ >=20 > Message: 2 > Date: Wed, 30 Jul 2014 12:12:20 -0700 > From: Yaron Sheffer > To: Yoav Nir > Cc: ipsec > Subject: Re: [IPsec] Puzzles draft - another idea > Message-ID: <53D94394.10703@gmail.com> > Content-Type: text/plain; charset=3Dutf-8; format=3Dflowed >=20 > Makes sense to me. >=20 > Yaron >=20 > On 07/30/2014 11:45 AM, Yoav Nir wrote: >> Hi, Yaron >>=20 >> 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). >>=20 >> 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. >>=20 >> Yoav >>=20 >> On Jul 30, 2014, at 6:40 PM, Yaron Sheffer > > wrote: >>=20 >>> Hi Yoav, >>>=20 >>> this is a nice idea, but I think it actually performs worse than the >>> baseline. >>>=20 >>> 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. >>>=20 >>> Thanks, >>> Yaron >>>=20 >>> On 07/30/2014 07:45 AM, Yoav Nir wrote: >>>> Hi all >>>>=20 >>>> 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. >>>>=20 >>>> 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: >>>>=20 >>>> Cookie || extra data >>>>=20 >>>> hash >>>>=20 >>>> # trailing zero bits >>>> fdbcfa5a430d7201282358a2a034de0013cfe2ae >>>>=20 >>>> ec2f327dae577a31152e3de2ac0f2f798e21f02e1afb04d33ff79bdd5d30eede >>>>=20 >>>> 1 >>>> fdbcfa5a430d7201282358a2a034de0013cfe2ae0182 >>>>=20 >>>> 71d3e8c09fbb8db5315e6364dce3ebd56ad35c96e284296e2ffffa256bdfa800 >>>>=20 >>>> 11 >>>> fdbcfa5a430d7201282358a2a034de0013cfe2ae022b3d >>>>=20 >>>> 3b4bdf201105e059e09f65219021738b8f6a148896b2e1be2fdc726aeb6e0000 >>>>=20 >>>> 17 >>>> fdbcfa5a430d7201282358a2a034de0013cfe2ae0aa679 >>>>=20 >>>> c352e914a41615496e3498e5ecb87b992be1ad40620f48af85428996c1f00000 >>>>=20 >>>> 20 >>>> fdbcfa5a430d7201282358a2a034de0013cfe2ae5c2880 >>>>=20 >>>> 155319280d687074d0f78511f63c77c568a5418dd44e6467d8fc37723d800000 >>>>=20 >>>> 23 >>>> fdbcfa5a430d7201282358a2a034de0013cfe2ae022bffc8 >>>>=20 >>>> 6469faf4455cf9a51b04edeea8195f27771d56b95f2d874764a71e2948000000 >>>>=20 >>>> 27 >>>>=20 >>>>=20 >>>> 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. >>>>=20 >>>>=20 >>>> 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). >>>>=20 >>>> This could get some more tweaks. But what do people think of this? >>>>=20 >>>> Thanks >>>>=20 >>>> Yoav >>>>=20 >>>> 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. >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> IPsec mailing list >>>> IPsec@ietf.org >>>> https://www.ietf.org/mailman/listinfo/ipsec >>=20 >=20 >=20 >=20 > ------------------------------ >=20 > Message: 3 > Date: Thu, 31 Jul 2014 16:19:22 +0000 > From: Zhenjie Huang > To: "ipsec@ietf.org" > Subject: [IPsec] Confusion about NAT traversal in RFC5996 > Message-ID: > = <6CCF0B32EEB49742A558E6A2BA50E7B6555C6ADB@ESGSCMB101.ericsson.se> > Content-Type: text/plain; charset=3D"us-ascii" >=20 >=20 > Dear IPsec experts, >=20 > I am a System Engineer from Ericsson. > I am currently reading your RFC5996. However, I feel confused with the = following words about NAT traversal: >=20 > 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). >=20 > 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! >=20 > Kind regards, > Jerry Huang >=20 >=20 > [Ericsson] >=20 > ZHENJIE HUANG > System Engineer > CGC/X >=20 > Ericsson > 13/F, ShuGuang Building, Nanshan > Shenzhen, China > Phone 0755-86925204 > Mobile 18576627893 > zhenjie.huang@ericsson.com > www.ericsson.com >=20 >=20 > = [http://www.ericsson.com/current_campaign] >=20 > 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 > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: = > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: image001.gif > Type: image/gif > Size: 2367 bytes > Desc: image001.gif > URL: = > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: image002.gif > Type: image/gif > Size: 22330 bytes > Desc: image002.gif > URL: = >=20 > ------------------------------ >=20 > Subject: Digest Footer >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 >=20 > ------------------------------ >=20 > End of IPsec Digest, Vol 123, Issue 21 > ************************************** From nobody Sun Aug 17 06:28:49 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8B66B1A08C5 for ; Sun, 17 Aug 2014 06:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EK5AZvL9rU-C for ; Sun, 17 Aug 2014 06:28:47 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 39F571A08C4 for ; Sun, 17 Aug 2014 06:28:47 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id n3so2534881wiv.1 for ; Sun, 17 Aug 2014 06:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=k72X/n52jvacvn7ayZRrP8PuJmyApZ21LLfyPYluRao=; b=K4ffyf/EWcxo/v4MR/JBqvqsW1XZel3MKPK3BzlpY+ExQKrI7ad8M2c1cJhcLFj+rV zSVGuzeHdmLYgsZ9rnV3Jf0byHNdRbD8SUBsld0z7uI4ZZ1rgtw+OruJmM1EXhMQ/H77 ducrbODaynOZ6UCRJagpTMZPF5FU1bkJeBJD1cqvVOfisPvu75zj0bAi6G+MEAkoeIvT utvsfIetrVBJasUnz1fG/vPwAG9G8RvJyIzatyxPBREuoTGsAScHG6hC9yyZXN39MFC0 UvsFanOKuRG/Ttjw7Nbjw2iN6Z0aAwvyTJ9hTqlg9RxZPMDJvepg/BnqC9FcyEWh096O VHMQ== X-Received: by 10.180.187.7 with SMTP id fo7mr61994538wic.4.1408282125706; Sun, 17 Aug 2014 06:28:45 -0700 (PDT) Received: from [172.24.250.90] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id w6sm34293238wjq.39.2014.08.17.06.28.44 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Aug 2014 06:28:45 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: Date: Sun, 17 Aug 2014 16:27:43 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Les Leposo X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/H-m1M6n1KmyGtA3-pq0H4GebfCg Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec Digest, Vol 123, Issue 21 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 13:28:48 -0000 On Aug 16, 2014, at 12:48 PM, Les Leposo wrote: > Hi >=20 > some points of discussion below. >=20 >> 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. >>=20 >> Perhaps we should look at other types of puzzles that do not depend = on >> raw CPU power? > Great question. >=20 > 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? That=92s 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=92ll have to turn up the difficulty to 25 bits. Older hardware (like = older phones and computers) will suffer. Yoav= From nobody Sun Aug 17 08:04:42 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0DF581A0AB7 for ; Sun, 17 Aug 2014 08:04:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D9LBsmXlPqr4 for ; Sun, 17 Aug 2014 08:04:40 -0700 (PDT) Received: from mail-wg0-x22e.google.com (mail-wg0-x22e.google.com [IPv6:2a00:1450:400c:c00::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 329901A0AC9 for ; Sun, 17 Aug 2014 08:04:39 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id m15so3966269wgh.17 for ; Sun, 17 Aug 2014 08:04:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=TO8NH6ppF6CQG9hC/e60MIRjWgAY8UWyAyq6XV7ndu0=; b=mvHTxNHNUs1v6Oq8tAuNpp9YfDxEqXb2KrUigIXPxDooGV4ELtFzzY4CZVt29HjIPV YirwPVpN7wwGU+MVtWGs9jbXoMjysXP//cmm8EDcHO5rbvvRp83Ac2/7uviPNjahVB/s CJYtjWLkrpif/AdprbWzKGEe8wU8F+FgjDnhWok24wjyHipL59V99cZSdU4oiAFwB3p9 5ilPNFBfY3VgcMhjQcXpeE12H9b9b52jvBiu2TuXLPQ+peXWXs4q6vrTAFDV8llBzptT Jc7rWsPspWPMLcV1CHrEXugM3mtUh4+ynF7S6rkkDJIcoXDiXeoTHD0E6ieMcUXxZhin eV0w== X-Received: by 10.180.80.225 with SMTP id u1mr33902778wix.69.1408287877724; Sun, 17 Aug 2014 08:04:37 -0700 (PDT) Received: from [192.168.0.17] ([197.237.48.207]) by mx.google.com with ESMTPSA id e3sm34874092wjp.4.2014.08.17.08.04.35 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 17 Aug 2014 08:04:36 -0700 (PDT) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Les Leposo In-Reply-To: Date: Sun, 17 Aug 2014 18:04:29 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <4F89453F-C1FC-4D12-8299-6AAE9485548F@gmail.com> References: To: Yoav Nir X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/rYXa5dku3-rbAX387vaMeJhZcQ0 Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec Digest, Vol 123, Issue 21 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Aug 2014 15:04:41 -0000 On Aug 17, 2014, at 4:27 PM, Yoav Nir wrote: >=20 > On Aug 16, 2014, at 12:48 PM, Les Leposo wrote: >=20 >> Hi >>=20 >> some points of discussion below. >>=20 >>> 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. >>>=20 >>> Perhaps we should look at other types of puzzles that do not depend = on >>> raw CPU power? >> Great question. >>=20 >> 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? >=20 > That=92s 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=92ll have to turn up the difficulty to 25 bits. Older hardware = (like older phones and computers) will suffer. Great point, though a hinted point was that the hash speed remains = similar while the power spent is reduced. >=20 > Yoav From nobody Mon Aug 18 07:44:29 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8CCE1A044D for ; Mon, 18 Aug 2014 07:44:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.911 X-Spam-Level: X-Spam-Status: No, score=0.911 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RP_MATCHES_RCVD=-0.668, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xspnpqDgp3sL for ; Mon, 18 Aug 2014 07:44:25 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18C521A0421 for ; Mon, 18 Aug 2014 07:44:24 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s7IEiKBI021035 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 Aug 2014 17:44:20 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s7IEiKIl022469; Mon, 18 Aug 2014 17:44:20 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21490.4420.127387.489490@fireball.kivinen.iki.fi> Date: Mon, 18 Aug 2014 17:44:20 +0300 From: Tero Kivinen To: Les Leposo In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 25 min X-Total-Time: 24 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/dPXO4wDwHSNV1SRV_SQUNEUCEVw Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec Digest, Vol 123, Issue 21 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 14:44:27 -0000 Les Leposo writes: > > 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. 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? > > 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). 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. -- kivinen@iki.fi From nobody Mon Aug 18 09:34:02 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1B6AE1A06CF for ; Mon, 18 Aug 2014 09:34:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Qqo7kHNt0RWM for ; Mon, 18 Aug 2014 09:34:00 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 211E91A06BB for ; Mon, 18 Aug 2014 09:34:00 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id AA39B813B2; Mon, 18 Aug 2014 12:33:58 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1408379638; bh=WPux5HnaroxDtBhWYRHxQfbLHmZFN21ps8YXkuAy+nY=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=OvkatKG4HPw6qo5XiVjc2l1WUQ39PR7kJV5cGI0F2tFMKvlb6tJ3Y2uGlVFVTZTDP s9/NowDmuZXAx1HF5ZVuAMRuTPhUlJdnUThtzcOtW2Rj93cmwW1MF1LhruW8xKitAp xFfAnFln70pJS7pI23+XhnIMKAS1WVajNlbDHDVk= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s7IGXvGJ025918; Mon, 18 Aug 2014 12:33:57 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 18 Aug 2014 12:33:57 -0400 (EDT) From: Paul Wouters To: Tero Kivinen In-Reply-To: <21490.4420.127387.489490@fireball.kivinen.iki.fi> Message-ID: References: <21490.4420.127387.489490@fireball.kivinen.iki.fi> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/I63TJg9cvPWIqRllfmnGqG99Skw Cc: ipsec@ietf.org, Les Leposo Subject: Re: [IPsec] IPsec Digest, Vol 123, Issue 21 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 16:34:01 -0000 On Mon, 18 Aug 2014, Tero Kivinen wrote: > 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). If the server has enough resources, yes. It should not kill clients with dpd. > 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. could someone at apple please relay this! This is stupidly draining my battery :P > 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. 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 nobody Mon Aug 18 10:23:31 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E3C11A06DA for ; Mon, 18 Aug 2014 10:23:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xjR_CG4NY1Cz for ; Mon, 18 Aug 2014 10:23:27 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E64AD1A06C8 for ; Mon, 18 Aug 2014 10:23:26 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id x13so5242618wgg.19 for ; Mon, 18 Aug 2014 10:23:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QQ4x5KpLAegDisqhvPEA4ebwGAj8iI3+Xq9kTuI60do=; b=owHLwH1VJW62Bas5/hv0LZzgnmygY4pbHLyu2ZeFoEEvwlfosQI3huH8Ryve9g6i0G iUo7itaryhIdtpM+0Cld3V5s2brm6MFLyd9KQ5hqbmuyUxLnWuE4g2s5HvxeU9Fw93KH 0llJajTwGmcNZ+LojDy8yJ3qrzSOSadccc3lXkPxhUTCMbPpFAN9piHb32Cyfg75GceZ tBbksD9Mzwk00QAPh+67lpSB0/ME+88pYEMDbvI4JlUhp0zkx+/HTHtBAfWKjTTrQkQf 7y83h/sbTwjhIAfRy9ykKJlaV/Ozs5WIq7qT0RmAUkze95+iESeDPLy6KgxaRMs8atK4 /iFA== X-Received: by 10.180.19.1 with SMTP id a1mr514541wie.16.1408382605574; Mon, 18 Aug 2014 10:23:25 -0700 (PDT) Received: from [192.168.0.17] ([197.237.48.207]) by mx.google.com with ESMTPSA id lg8sm43735845wjb.9.2014.08.18.10.23.23 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Aug 2014 10:23:24 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Les Leposo In-Reply-To: <21490.4420.127387.489490@fireball.kivinen.iki.fi> Date: Mon, 18 Aug 2014 20:23:19 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <9852A873-1EEA-45EC-AEA3-BA654249A662@gmail.com> References: <21490.4420.127387.489490@fireball.kivinen.iki.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/622AHXHVwK6LOJyqL94kK71-7y8 Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec Digest, Vol 123, Issue 21 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 17:23:29 -0000 On Aug 18, 2014, at 5:44 PM, Tero Kivinen wrote: > Les Leposo writes: >>> 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. >>>=20 >> 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. >=20 > 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. >=20 > 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). >=20 > 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. >=20 > 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. >=20 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). > 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.=20 ok, that sounds like a misconfig or bug in the IKE SA rekey. >=20 >> 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? >>=20 >> Or, a crazier idea... find ways to permit/standardise some types of >> cheating at the peers.=20 >> 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,=20 >> 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). =20 >> - The peers need to store these "scripts/seeds" securely (i.e. >> sandboxing is a must).=20 >> - The trusted entity needs to be very fast (probably with >> hardware acceleration) at generating these "scripts/seeds". Perhaps >> a new product category for servers.=20 >> - 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).=20 >=20 > And of course you log in to the trusted entity using IPsec :-) >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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. >=20 > 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.=20 >=20 > 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. >=20 > 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. > --=20 > kivinen@iki.fi From nobody Mon Aug 18 10:31:28 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98C8A1A0719 for ; Mon, 18 Aug 2014 10:31:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A65Vq2iKxdAL for ; Mon, 18 Aug 2014 10:31:15 -0700 (PDT) Received: from mail-wi0-x236.google.com (mail-wi0-x236.google.com [IPv6:2a00:1450:400c:c05::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 24A8A1A0716 for ; Mon, 18 Aug 2014 10:31:14 -0700 (PDT) Received: by mail-wi0-f182.google.com with SMTP id d1so4034801wiv.9 for ; Mon, 18 Aug 2014 10:31:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=dE3z1h68NtBHtE5CkeVpoxWVQbZ/LHSrMwTZPPWubh0=; b=oKjgXyeAzs+U/gk1UnArbN2MfTD4sGWKUXfHx/hq0jMIFJBDKpG1wJ10UVHKTSRg56 q3if+vKiBCUTmoGMdaCl3KmztpyabifKz2pmtjpz42S64QhtGTApP2eNpGak11mUyRLA WumcN/QZwOU2z4gsecmnW3gbw523MPpgDoK+6zh/6h9Zc2CDjHCK3vqM8tD97vYBgDrA sBNEScd4i6hzzIRJRrKXfUKwqc4R1TBnp6hQxKVVagmT+lhOK0FfDk5cJEaA58c81oFm krI/md8FvMAOVO6RRhHQdhIXoW/iLga1B8e4Sc5LVOzxZVf0t1RwDInB1VEnpotNuzOB /71Q== X-Received: by 10.180.36.238 with SMTP id t14mr517869wij.38.1408383073699; Mon, 18 Aug 2014 10:31:13 -0700 (PDT) Received: from [192.168.0.17] ([197.237.48.207]) by mx.google.com with ESMTPSA id pl1sm39838684wic.17.2014.08.18.10.31.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 18 Aug 2014 10:31:12 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Les Leposo In-Reply-To: Date: Mon, 18 Aug 2014 20:31:08 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <50B02F3B-2DA2-42D1-865E-9635A4D928BA@gmail.com> References: <21490.4420.127387.489490@fireball.kivinen.iki.fi> To: Paul Wouters X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/-j8BpVQiU4AwlstPbYY_3kGrWkg Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] IPsec Digest, Vol 123, Issue 21 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 17:31:22 -0000 On Aug 18, 2014, at 7:33 PM, Paul Wouters wrote: > On Mon, 18 Aug 2014, Tero Kivinen wrote: >=20 >> 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). >=20 > If the server has enough resources, yes. It should not kill clients = with > dpd. >=20 >> 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. >=20 > could someone at apple please relay this! This is stupidly draining my > battery :P do you know if it is an IKE SA rekey and if so, who is actually = initiating it? >=20 >> 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. >=20 > 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. >=20 >> This means attacker needs one new routable IP-address for each = attack. >=20 > for each 65k attacks. >=20 > Paul From nobody Mon Aug 18 10:52:10 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B20A51A070A for ; Mon, 18 Aug 2014 10:52:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5W50UjIi9B0 for ; Mon, 18 Aug 2014 10:52:07 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB0201A0708 for ; Mon, 18 Aug 2014 10:52:06 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0B68B813B2; Mon, 18 Aug 2014 13:52:06 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1408384326; bh=a90msIDOaCEhnN9rOfzvdYYXRcP6NxH0QMA5R1J5Bf0=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=XG2Zer19Fy7jnas86NKjXnuVfoaGkk3S2AHEjcdsP9jM1gkwxeyYvDU3HRsORgaXo 1BEAKGhwxaURQyUjOZ9MZg6XWf5g11C0Or8vISHlCXvtM2HQUBRmEUTr8fPCxd+L9j bnzuZVHb9ihu64GGQDJ3Ixc8/r5Tcr894eW4Rv/I= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s7IHq526027648; Mon, 18 Aug 2014 13:52:05 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Mon, 18 Aug 2014 13:52:05 -0400 (EDT) From: Paul Wouters To: Les Leposo In-Reply-To: <50B02F3B-2DA2-42D1-865E-9635A4D928BA@gmail.com> Message-ID: References: <21490.4420.127387.489490@fireball.kivinen.iki.fi> <50B02F3B-2DA2-42D1-865E-9635A4D928BA@gmail.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/njwKOJ5kQSvSnDM8zXjryCNEdLg Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] IPsec Digest, Vol 123, Issue 21 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Aug 2014 17:52:08 -0000 On Mon, 18 Aug 2014, Les Leposo wrote: >>> 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. >> >> could someone at apple please relay this! This is stupidly draining my >> battery :P > 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 nobody Tue Aug 19 01:27:06 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DE0421A884B for ; Tue, 19 Aug 2014 01:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BNrzNI7s-_Cj for ; Tue, 19 Aug 2014 01:27:04 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28A6E1A8849 for ; Tue, 19 Aug 2014 01:27:04 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id n3so4982756wiv.17 for ; Tue, 19 Aug 2014 01:27:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=T6f0IZL4U/bC5JA14n8+Uoar7csvT7aqcn8tuTQVQ00=; b=LOlU6cpIm5Vrsu6ILfPqOCzOcGvHrmvyePr0l1J9Rv5h6KTTD7c7pg6ssEn/Fd7UOJ hjcOD55XqUA1ztWry4355bDzO6irAx+49mDNo2LSp5kvo4jD36ElRcTdw3ZEaGS+LVM6 kViYJjXya/YDOFU1mbeQQpf3Gr9cKJZS3iw0r/qDGTwemXjgnYUCYkiC4jiMwYbgFVhI vv5AFAmr6tKgCjHVM/+t2Muhmj3Mf+GR1txDpNbF0a4rCVp82fNSzgYY1PhPf8XOxJUq sVYtsKcc9O0gNVqXZJKYvV0Jl0+n1vQrY3mi6jaIzHAoG7HYQaj5c685JUp+JAxT+/1I HgGg== X-Received: by 10.194.89.168 with SMTP id bp8mr25004397wjb.53.1408436822803; Tue, 19 Aug 2014 01:27:02 -0700 (PDT) Received: from [192.168.0.17] ([197.237.48.207]) by mx.google.com with ESMTPSA id ci3sm4652763wjc.35.2014.08.19.01.27.00 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 01:27:01 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Les Leposo In-Reply-To: Date: Tue, 19 Aug 2014 11:26:57 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <21490.4420.127387.489490@fireball.kivinen.iki.fi> <50B02F3B-2DA2-42D1-865E-9635A4D928BA@gmail.com> To: Paul Wouters X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/-Yz-qjKtGHgvNTPTxBxialG_e8w Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] IPsec Digest, Vol 123, Issue 21 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 08:27:06 -0000 On Aug 18, 2014, at 8:52 PM, Paul Wouters wrote: > On Mon, 18 Aug 2014, Les Leposo wrote: >=20 >>>> 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. >>>=20 >>> could someone at apple please relay this! This is stupidly draining = my >>> battery :P >> do you know if it is an IKE SA rekey and if so, who is actually = initiating it? >=20 > the entire ipsec system is brought down/up, eg racoon is completely > 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). >=20 > Paul From nobody Tue Aug 19 03:24:54 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C4091A8893 for ; Tue, 19 Aug 2014 03:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F1W6HBogFdYs for ; Tue, 19 Aug 2014 03:24:50 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C5EC1A0393 for ; Tue, 19 Aug 2014 03:24:50 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s7JAOjR3002406 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Aug 2014 13:24:45 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s7JAOjdA029647; Tue, 19 Aug 2014 13:24:45 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21491.9709.148603.972986@fireball.kivinen.iki.fi> Date: Tue, 19 Aug 2014 13:24:45 +0300 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <21490.4420.127387.489490@fireball.kivinen.iki.fi> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 4 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/525-49vraQQhxy8ZLhoJx1Yl9tM Cc: ipsec@ietf.org, Les Leposo Subject: Re: [IPsec] IPsec Digest, Vol 123, Issue 21 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 10:24:52 -0000 Paul Wouters writes: > > 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. > > 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. 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. > for each 65k attacks. Nope, one address per attack as you do not store port number (and not perhaps even full IP-address, especially in IPv6). -- kivinen@iki.fi From nobody Tue Aug 19 03:40:02 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C8401A8896 for ; Tue, 19 Aug 2014 03:40:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GDjzAA12h8dI for ; Tue, 19 Aug 2014 03:39:58 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73C091A03BF for ; Tue, 19 Aug 2014 03:39:58 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s7JAdpdq025078 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Aug 2014 13:39:51 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s7JAdprZ007675; Tue, 19 Aug 2014 13:39:51 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21491.10614.714777.145464@fireball.kivinen.iki.fi> Date: Tue, 19 Aug 2014 13:39:50 +0300 From: Tero Kivinen To: Les Leposo In-Reply-To: <9852A873-1EEA-45EC-AEA3-BA654249A662@gmail.com> References: <21490.4420.127387.489490@fireball.kivinen.iki.fi> <9852A873-1EEA-45EC-AEA3-BA654249A662@gmail.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 14 min X-Total-Time: 14 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/OnjClX0122bhOgwkzV107tXQMJo Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec Digest, Vol 123, Issue 21 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 10:40:00 -0000 Les Leposo writes: > 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... -- kivinen@iki.fi From nobody Tue Aug 19 07:31:56 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A11011A8905 for ; Tue, 19 Aug 2014 07:31:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qjJHso8AHlS1 for ; Tue, 19 Aug 2014 07:31:37 -0700 (PDT) Received: from mail-wg0-x234.google.com (mail-wg0-x234.google.com [IPv6:2a00:1450:400c:c00::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C3FC1A037E for ; Tue, 19 Aug 2014 07:31:37 -0700 (PDT) Received: by mail-wg0-f52.google.com with SMTP id a1so6364102wgh.11 for ; Tue, 19 Aug 2014 07:31:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=mb+rN1l2mXiEOeUPak07x0bYHrLUtGzkpdhHm65NHWY=; b=CYrzIWBjA7b4/j9unyNunLeW2A+unuaFefJDMqZ+d6vpnUUI9Go+mMs5dhGZ/VcqnB qiSlPQHgLn1NTIWjau0aRfgrFg7tUg8Yb6UY7ZIg02l53bSjsF5nHpQUPcn/XNnhmq1b Z4ZsetI5uw9ySIj2DDxsDnoA8HwCBrq4vGZklaE1de8W/8dFbWwFNXR5hiF3vtgAt+JT Xr0XI38gqdCvTnqdbmHa5YDHMtNceUeqf6zMENFYR4ZwRgqULtVN7xV/NVbsy2S8Ffk5 huyztZl8/Xhypy2nuX7fdvqU1nlbWAYfyg4bdVd+X5URRRDwq2Jiru+LkDZeGanc5mnT DAKA== X-Received: by 10.180.75.230 with SMTP id f6mr7497758wiw.5.1408458695732; Tue, 19 Aug 2014 07:31:35 -0700 (PDT) Received: from [192.168.0.17] ([197.237.48.207]) by mx.google.com with ESMTPSA id u7sm49283066wif.3.2014.08.19.07.31.32 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 07:31:34 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_286432FE-73C7-4E6A-A293-4400EED9B3F1" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Les Leposo In-Reply-To: <21491.10614.714777.145464@fireball.kivinen.iki.fi> Date: Tue, 19 Aug 2014 17:31:28 +0300 Message-Id: <1252045C-2D84-4764-AFCC-1450A2921A8C@gmail.com> References: <21490.4420.127387.489490@fireball.kivinen.iki.fi> <9852A873-1EEA-45EC-AEA3-BA654249A662@gmail.com> <21491.10614.714777.145464@fireball.kivinen.iki.fi> To: Tero Kivinen X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/NAyrZnjdrY7--Qpp1uvetX2jZcU Cc: ipsec@ietf.org Subject: Re: [IPsec] IPsec Digest, Vol 123, Issue 21 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 14:31:44 -0000 --Apple-Mail=_286432FE-73C7-4E6A-A293-4400EED9B3F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Aug 19, 2014, at 1:39 PM, Tero Kivinen wrote: > Les Leposo writes: >> have you overlooked the issue of nat mappings? >=20 > Nope. >=20 >> 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.=20 >=20 > IPsec NAT-T keepalives are completely different thing than DPD. >=20 > 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). >=20 > The dead peer detection (DPD) or liveness check is a procedure > specified in the RFC5996 section 2.4 where it says that: >=20 > ... 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. >=20 > 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. >=20 >> 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. >=20 > 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.=20 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=3Dlow-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.=20 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. >=20 >> 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. >=20 > 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. 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. >=20 > 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.=20 Correct, ios 4 & 5 used to do these sort of things. I'm not sure about = other smartphones. >=20 > 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...=20 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). > --=20 > kivinen@iki.fi --Apple-Mail=_286432FE-73C7-4E6A-A293-4400EED9B3F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Aug 19, 2014, at 1:39 PM, Tero = Kivinen <kivinen@iki.fi> = wrote:

Les Leposo writes:
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.

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=3Dlow-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.


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.
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.


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.
Correct, ios 4 & 5 = used to do these sort of things. I'm not sure about other = smartphones.


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...

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).

= --Apple-Mail=_286432FE-73C7-4E6A-A293-4400EED9B3F1-- From nobody Tue Aug 19 07:32:21 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF581A033C for ; Tue, 19 Aug 2014 07:32:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2ruZ-mylD7i4 for ; Tue, 19 Aug 2014 07:32:16 -0700 (PDT) Received: from mail-lb0-x231.google.com (mail-lb0-x231.google.com [IPv6:2a00:1450:4010:c04::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 628A71A037E for ; Tue, 19 Aug 2014 07:32:15 -0700 (PDT) Received: by mail-lb0-f177.google.com with SMTP id s7so5623141lbd.36 for ; Tue, 19 Aug 2014 07:32:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=GYR8c/ZfFUGaldk/LA43/XpCsPvZJ2Gal2ZQg7qEf7M=; b=naSufhS1rK4mRzMlXXruR2KrdQ7wYg1z/CV5UqNwN5B3rtsQ401dt/Saa4iNipcuK6 Vrw9ngrO0QcuUjfSJtXwoL96oDlpouxMFLIpHupuqTfFWOAu5lZr82u9QeBBlPaCxwxm sMTCZ5K/m6xfW59sPJHv7hNHQd6gjerjT/VCwfRLR3RZ267Rdq3wSx9/Ql3Ehv7Utgfj iVMXzPh+N7Ve15QhHHy4sbNifYSRGHtqMozLOzkdDBNXCzARIDfjV2rkQIkUQQ2TExU6 LT1yc8ZdmECk9Ysw/8eW5tKMLMg3IVelsVLySqfM69kpDKlrqcTeenMHSeu3UH2/47Kv 2qng== X-Received: by 10.112.173.136 with SMTP id bk8mr33218685lbc.88.1408458732500; Tue, 19 Aug 2014 07:32:12 -0700 (PDT) Received: from [172.24.250.90] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id dq2sm32385962lbc.12.2014.08.19.07.32.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 07:32:11 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_F2FCC591-7E5F-413A-82AC-0E2467D93716" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: <9852A873-1EEA-45EC-AEA3-BA654249A662@gmail.com> Date: Tue, 19 Aug 2014 17:32:09 +0300 Message-Id: References: <21490.4420.127387.489490@fireball.kivinen.iki.fi> <9852A873-1EEA-45EC-AEA3-BA654249A662@gmail.com> To: Les Leposo X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/e37voAsaXFrrsbjUsN7nyP8MmME Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] IPsec Digest, Vol 123, Issue 21 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 14:32:19 -0000 --Apple-Mail=_F2FCC591-7E5F-413A-82AC-0E2467D93716 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 18, 2014, at 8:23 PM, Les Leposo wrote: >=20 > On Aug 18, 2014, at 5:44 PM, Tero Kivinen wrote: >=20 >> Les Leposo writes: >>>> 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. >>>>=20 >>> 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. >>=20 >> 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. >=20 >>=20 >> 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). >>=20 >> 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. >>=20 >> 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. >>=20 >=20 > have you overlooked the issue of nat mappings? >=20 > 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. >=20 > 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. >=20 > 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=92ve implemented. If you=92ve implemented = QCD (RFC 6290), then DPD fails or succeeds immediately as long as you = have connectivity, and it doesn=92t make sense to go directly to a new = Initial exchange.=20 AFAIK racoon doesn=92t 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.=20 Yoav --Apple-Mail=_F2FCC591-7E5F-413A-82AC-0E2467D93716 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Aug 18, 2014, at 8:23 PM, Les = Leposo <leposo@gmail.com> = wrote:


On Aug 18, 2014, at 5:44 PM, = Tero Kivinen <kivinen@iki.fi> = wrote:

Les Leposo = writes:
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.

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.


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.

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

AFAIK racoon doesn=92t 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

= --Apple-Mail=_F2FCC591-7E5F-413A-82AC-0E2467D93716-- From nobody Tue Aug 19 07:42:35 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4C93B1A8918 for ; Tue, 19 Aug 2014 07:42:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NZ8rmFOaFaGO for ; Tue, 19 Aug 2014 07:42:30 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 642131A8916 for ; Tue, 19 Aug 2014 07:42:30 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id B1FC281790; Tue, 19 Aug 2014 10:42:29 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1408459349; bh=SajG/bVH0vO61BqLLda22RnQ+78Yuob+hcpu+pha44o=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=jlgfN41xu9hwr+88IysYo7uFK/2YGYa6YmfI+aBnVb4F3MSpfp+e858tZ30fl1bKN ercZDdSVGi3oQw4ZIUNKTNIZs0UXCTYeoJBq2IKVhQpuUjLEMUSuGJ7lf+fZvIPg/h nzfYG0ieJiMIpUGiFswuGmiGnW1H2Cnc68H8zMiQ= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s7JEgThE020762; Tue, 19 Aug 2014 10:42:29 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 19 Aug 2014 10:42:29 -0400 (EDT) From: Paul Wouters To: Tero Kivinen In-Reply-To: <21491.9709.148603.972986@fireball.kivinen.iki.fi> Message-ID: References: <21490.4420.127387.489490@fireball.kivinen.iki.fi> <21491.9709.148603.972986@fireball.kivinen.iki.fi> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/BegxRNYgd78kwwHqDQ5NgkZTzdI Cc: ipsec@ietf.org, Les Leposo Subject: Re: [IPsec] IPsec Digest, Vol 123, Issue 21 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 14:42:33 -0000 On Tue, 19 Aug 2014, Tero Kivinen wrote: >> 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. > > No need for port number. If server is under attack just block / slow > down everybody using the same IP-address (or IP-address mask). Works great with CGN :P Paul From nobody Tue Aug 19 07:44:06 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 773381A8913 for ; Tue, 19 Aug 2014 07:44:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.668 X-Spam-Level: X-Spam-Status: No, score=-2.668 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Lga7-FoMBdCV for ; Tue, 19 Aug 2014 07:44:00 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [76.10.157.69]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E7911A8906 for ; Tue, 19 Aug 2014 07:44:00 -0700 (PDT) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 801F181790; Tue, 19 Aug 2014 10:43:59 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1408459439; bh=/X63O76ekADcFw4ejSY6p+t9TXAlRqICx8ycJIX1HKs=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=eybXsbBNqxbuXKC0/V8WpZaM1THBVixuEtJxCv2UWjdO7w7t1HBH+C+dZlX4h8gk2 /kaqSQC7boAtj3kAQpjkggWMfVQTcc20H3s9B/6iVW3G4A9LTMLA3wprF3AQJ7Zt/3 kb1M/M4L9DBcTGXLS0RnvQfgjQWwPk0UQvo4v44s= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id s7JEhxC2020925; Tue, 19 Aug 2014 10:43:59 -0400 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Tue, 19 Aug 2014 10:43:59 -0400 (EDT) From: Paul Wouters To: Les Leposo In-Reply-To: Message-ID: References: <21490.4420.127387.489490@fireball.kivinen.iki.fi> <50B02F3B-2DA2-42D1-865E-9635A4D928BA@gmail.com> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/tBe4o-n-0tT8x3R77bwk82FvFOA Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] IPsec Digest, Vol 123, Issue 21 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 14:44:02 -0000 On Tue, 19 Aug 2014, Les Leposo wrote: >> the entire ipsec system is brought down/up, eg racoon is completely >> 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). 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 nobody Tue Aug 19 07:48:15 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A0C21A0327 for ; Tue, 19 Aug 2014 07:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XkHLx2NBi295 for ; Tue, 19 Aug 2014 07:48:10 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 649B01A0376 for ; Tue, 19 Aug 2014 07:48:10 -0700 (PDT) Received: by mail-wi0-f173.google.com with SMTP id f8so5562139wiw.0 for ; Tue, 19 Aug 2014 07:48:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=IOYmWIJ4M9zinvWVJ/H/T2W9eZ6OYvRvTHh/iT0CObI=; b=R2n9gtkxfDbpAXSJ/hS+TjkkzBTljXH5B8qYjwwFLSjD8XvHRu0pJ9SZAUZCbz72pb NKrWUIIMgHF6jzAhaRPUEFS/Oq2i/7c4b7X3sdIOGctCJGvqHdsCJBo1Xh8waTfdz4Ha a/PMcGRpoAztTg2bk7ljeJUjSpdqgnb0AHaVcQfyx9MKWBtkYPZodGCabmcEMKMp9BxA XkiMmWvp5x7tWTwarGafhfG2apD/ZfTPHJe4N+cteHZOsyqYZSEdPfzgafvzu0IoXOHE sSmnpOOA10BSrZMJSp3MJI5OeJEDVs0+6XAxsnFsUqmkQ/dr6583nYL9bda0Do9UpmpY 26fw== X-Received: by 10.180.189.139 with SMTP id gi11mr7286156wic.51.1408459688972; Tue, 19 Aug 2014 07:48:08 -0700 (PDT) Received: from [192.168.0.17] ([197.237.48.207]) by mx.google.com with ESMTPSA id gi5sm50957390wjd.33.2014.08.19.07.48.06 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 07:48:08 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_7B9E4B50-7216-442B-932D-83751E8B4F02" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Les Leposo In-Reply-To: Date: Tue, 19 Aug 2014 17:48:00 +0300 Message-Id: References: <21490.4420.127387.489490@fireball.kivinen.iki.fi> <9852A873-1EEA-45EC-AEA3-BA654249A662@gmail.com> To: Yoav Nir X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/DP2T37jRUHoPe30EDsTv2tSLOWk Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] IPsec Digest, Vol 123, Issue 21 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 14:48:12 -0000 --Apple-Mail=_7B9E4B50-7216-442B-932D-83751E8B4F02 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 19, 2014, at 5:32 PM, Yoav Nir wrote: >=20 > On Aug 18, 2014, at 8:23 PM, Les Leposo wrote: >=20 >>=20 >> On Aug 18, 2014, at 5:44 PM, Tero Kivinen wrote: >>=20 >>> Les Leposo writes: >>>>> 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. >>>>>=20 >>>> 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. >>>=20 >>> 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. >>=20 >>>=20 >>> 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). >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>=20 >> have you overlooked the issue of nat mappings? >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >=20 > It depends which standards you=92ve implemented. If you=92ve = 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=92t make sense to go directly to a new Initial exchange.=20= >=20 What if the IKE SA was nearing expiry, and/or the server initiated a = rekey while you were asleep. > AFAIK racoon doesn=92t have that. Maybe it has session tickets, which = make the Initial exchange lighter. >=20 > Of course, wiping all state every time you blank the screen is (if = true) a very weird implementation choice.=20 Do you mean screen lock? >=20 > Yoav >=20 --Apple-Mail=_7B9E4B50-7216-442B-932D-83751E8B4F02 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Aug 19, 2014, at 5:32 PM, Yoav Nir = <ynir.ietf@gmail.com> = wrote:


On Aug 18, 2014, at 8:23 PM, Les = Leposo <leposo@gmail.com> = wrote:


On Aug 18, 2014, at 5:44 PM, = Tero Kivinen <kivinen@iki.fi> = wrote:

Les Leposo = writes:
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.

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.


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.

It depends which standards = you=92ve implemented. If you=92ve 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=92t 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.


AFAIK racoon doesn=92t= 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. 
Do you mean screen = lock?



Yoav


= --Apple-Mail=_7B9E4B50-7216-442B-932D-83751E8B4F02-- From nobody Tue Aug 19 07:56:30 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3242B1A03AC for ; Tue, 19 Aug 2014 07:56:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UeGrYXg3mdwA for ; Tue, 19 Aug 2014 07:56:23 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E46781A8938 for ; Tue, 19 Aug 2014 07:56:22 -0700 (PDT) Received: by mail-wi0-f172.google.com with SMTP id n3so5566246wiv.5 for ; Tue, 19 Aug 2014 07:56:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=EIF4NY4b1J0fsQL9I//cF8a7XCrnu1iwaKaR6E1Atjs=; b=lf6im8ja/QVVwOYNIjGIYvIrw5lopXfxb0lR/yr5ZWm0b8BhFRgqsHXDJtYIpsm55h /W3hddsI4y7mtCNRtz/SDSbx0mU8ZzTy1Cfq5EYzSMr6Kxnf/TYGltIU39CN2SZIO+4u MN7EocVZgEW4f6Iysus7WeMG7ZQdVtVT9aYLWjlUph6CXRW8LjDOG65UFGO1bh1X5z0p 7lyP1hoM2KwYZxk4SE5FW1NXuy7Zc2bPePcX6LrTsOvcqHPUIpqsLP8OejBsb5eIjMQO djGgCWs9ZGZDuu2CfndKIdjG1IbPVHDmPB6Pygbo6aVxQsvw0bjD3R54Q1wjPTid+6bj qYwQ== X-Received: by 10.180.10.166 with SMTP id j6mr7410454wib.73.1408460181622; Tue, 19 Aug 2014 07:56:21 -0700 (PDT) Received: from [192.168.0.17] ([197.237.48.207]) by mx.google.com with ESMTPSA id wi9sm51017429wjc.23.2014.08.19.07.56.19 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 07:56:20 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Les Leposo In-Reply-To: Date: Tue, 19 Aug 2014 17:56:16 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <47C1A4D5-966E-477D-AF81-D2CB92ECA031@gmail.com> References: <21490.4420.127387.489490@fireball.kivinen.iki.fi> <50B02F3B-2DA2-42D1-865E-9635A4D928BA@gmail.com> To: Paul Wouters X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/3cmK5C-cCXIhglGnDteqE9aGGIQ Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] IPsec Digest, Vol 123, Issue 21 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 14:56:25 -0000 On Aug 19, 2014, at 5:43 PM, Paul Wouters wrote: > On Tue, 19 Aug 2014, Les Leposo wrote: >=20 >>> the entire ipsec system is brought down/up, eg racoon is completely >>> killed and restarted all the time. >> Sounds like a totally reproducible crash/signal. >>=20 >> 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. >>=20 >> You would also have to indicate how long this problem has been = happening e.g. years/months, ios versions (to identify regressions). >=20 > Years ago I tried to file bug reports for IPsec to Apple. No feedback > ever, and lots of "developer" spam email. >=20 How long ago?=20 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? > 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. >=20 > Paul From nobody Tue Aug 19 08:11:59 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8F17C1A03A8 for ; Tue, 19 Aug 2014 08:11:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fHnHPG9mYwle for ; Tue, 19 Aug 2014 08:11:53 -0700 (PDT) Received: from mail-we0-x22c.google.com (mail-we0-x22c.google.com [IPv6:2a00:1450:400c:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D78121A03DB for ; Tue, 19 Aug 2014 08:11:52 -0700 (PDT) Received: by mail-we0-f172.google.com with SMTP id x48so6669556wes.31 for ; Tue, 19 Aug 2014 08:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=1LNHMC/W+B567GJGQQzfNdEhv8Kh37PPJq7ygae1X9A=; b=CVvxp03CMxzSo1BHKmb7y1VIOWj9G7bTEeReh22i2euY/LDQr79i1sB9es4GBByULg MUIsj76ccKeAtOWmcyDSds1KYePCxGwwo3cV9qWv+fb0G172GLQDdyKQ6X34FKVulSTc d2cDiIEJ4eOUKRjghpAVBUMhyHuKLgzj6erDkKGW0J2GFA9M2tgq9f1waBhf9JSd+u94 ZG479cQNAEFcUWHcpDYq8a0QjqrgAGw0+3zd68n7lbMrY60Sjv23JdCzVVE7Re0Pnaaa KXU7aBVv5wVGOqkhRVddQXXMGANVSVKNflv6c6+CxcPEMDWveqk/p+SKq9DOpTGggx9i JODw== X-Received: by 10.194.57.237 with SMTP id l13mr2247380wjq.102.1408461111335; Tue, 19 Aug 2014 08:11:51 -0700 (PDT) Received: from [172.24.250.90] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id es9sm51132526wjd.1.2014.08.19.08.11.48 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 08:11:48 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_79586301-FFE3-410F-A3E5-2C2987E7ED07" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Yoav Nir In-Reply-To: Date: Tue, 19 Aug 2014 18:11:47 +0300 Message-Id: References: <21490.4420.127387.489490@fireball.kivinen.iki.fi> <9852A873-1EEA-45EC-AEA3-BA654249A662@gmail.com> To: Les Leposo X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/viz8W6Pax6pcVWYZiMNLQN1AXr8 Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] IPsec Digest, Vol 123, Issue 21 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 15:11:58 -0000 --Apple-Mail=_79586301-FFE3-410F-A3E5-2C2987E7ED07 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 19, 2014, at 5:48 PM, Les Leposo wrote: >>>=20 >>> 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. >>>=20 >>> 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. >>=20 >> It depends which standards you=92ve implemented. If you=92ve = 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=92. 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 =93if you=92ve been silent for X seconds, you can assume that = I=92ve started a DPD and probably killed your IKE SA=94. >> and it doesn=92t make sense to go directly to a new Initial exchange.=20= >>=20 >=20 > 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=92s = OK that it happened, It=92s only a matter of detecting this efficiently. >> AFAIK racoon doesn=92t have that. Maybe it has session tickets, which = make the Initial exchange lighter. >>=20 >> Of course, wiping all state every time you blank the screen is (if = true) a very weird implementation choice.=20 > Do you mean screen lock? If that=92s what it is called on an iPhone (I don=92t 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.=20 Yoav --Apple-Mail=_79586301-FFE3-410F-A3E5-2C2987E7ED07 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Aug 19, 2014, at 5:48 PM, Les = Leposo <leposo@gmail.com> = wrote:


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.

It depends which standards = you=92ve implemented. If you=92ve 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=92.

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 =93if you=92ve been = silent for X seconds, you can assume that I=92ve started a DPD and = probably killed your IKE SA=94.

and it doesn=92t 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.

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

AFAIK racoon doesn=92t 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. 
Do you mean screen = lock?

If that=92s what it is = called on an iPhone (I don=92t 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


<= /html>= --Apple-Mail=_79586301-FFE3-410F-A3E5-2C2987E7ED07-- From nobody Tue Aug 19 09:11:10 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A4D471A0462 for ; Tue, 19 Aug 2014 09:11:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s4x__Ybe4HXr for ; Tue, 19 Aug 2014 09:11:08 -0700 (PDT) Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9ACD31A04E9 for ; Tue, 19 Aug 2014 09:11:06 -0700 (PDT) Received: by mail-wg0-f48.google.com with SMTP id x13so6670232wgg.7 for ; Tue, 19 Aug 2014 09:11:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=cClI/EbXsN7eGS6uQWgPXNCw53koesq2kJY1t3ztYQs=; b=WI+CgOKq2bR1205vfUHGgNw4Pzi8L06XuMN5h5koiKdW4RjKT4ZQYKNRLqnBlFXsJs jzqfxVOSMLJCI4YLE2F8qTnB+DXAt/sWfzCDqS8LuMa4GLMaqXPaHcr61hO/ba4EpznO VFnwEtwdRgyAyHQLKZaj6taR0B6NwxEukuR1Qi0sJ2jp5i5ENfwbiciSxcFYKeh/Li70 /Pfcy2YZLS4F6EjEo0IPplnzKcvMggLDVRhiV21dlPJh97g76EicXAi95Ii8/4yHy2mG nK+5fykk4CKmXgoq2oAhF58mEnpaBkIR3mABaMd4Sj7QWKeOv6SvSZQJ5MbWlJC467Uu 6jAw== X-Received: by 10.180.103.74 with SMTP id fu10mr7867389wib.47.1408464665317; Tue, 19 Aug 2014 09:11:05 -0700 (PDT) Received: from [192.168.0.17] ([197.237.48.207]) by mx.google.com with ESMTPSA id o9sm26302363wjo.11.2014.08.19.09.11.03 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 09:11:04 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_28B2A972-CCAF-48A3-A395-0F28367758D4" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Les Leposo In-Reply-To: Date: Tue, 19 Aug 2014 19:10:58 +0300 Message-Id: References: <21490.4420.127387.489490@fireball.kivinen.iki.fi> <9852A873-1EEA-45EC-AEA3-BA654249A662@gmail.com> To: Yoav Nir X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/6Qx3FmkT6O-Tc-CiTVhe8N5njZQ Cc: ipsec@ietf.org, Tero Kivinen Subject: Re: [IPsec] IPsec Digest, Vol 123, Issue 21 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 16:11:09 -0000 --Apple-Mail=_28B2A972-CCAF-48A3-A395-0F28367758D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Aug 19, 2014, at 6:11 PM, Yoav Nir wrote: >=20 > On Aug 19, 2014, at 5:48 PM, Les Leposo wrote: >=20 >>>>=20 >>>> 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. >>>>=20 >>>> 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. >>>=20 >>> It depends which standards you=92ve implemented. If you=92ve = 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=92. >=20 > 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 =93if you=92ve been silent for X seconds, you can assume that = I=92ve started a DPD and probably killed your IKE SA=94. >=20 >>> and it doesn=92t make sense to go directly to a new Initial = exchange.=20 >>>=20 >>=20 >> What if the IKE SA was nearing expiry, and/or the server initiated a = rekey while you were asleep. >=20 > Under IKEv2 rules, the rekey failed and the old IKE SA is gone. It=92s = OK that it happened, It=92s only a matter of detecting this efficiently. yup >=20 >>> AFAIK racoon doesn=92t have that. Maybe it has session tickets, = which make the Initial exchange lighter. >>>=20 >>> Of course, wiping all state every time you blank the screen is (if = true) a very weird implementation choice.=20 >> Do you mean screen lock? >=20 > If that=92s what it is called on an iPhone (I don=92t 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.=20 >=20 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. > Yoav >=20 >=20 --Apple-Mail=_28B2A972-CCAF-48A3-A395-0F28367758D4 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
On Aug 19, 2014, at 6:11 PM, Yoav Nir = <ynir.ietf@gmail.com> = wrote:


On Aug 19, 2014, at 5:48 PM, Les = Leposo <leposo@gmail.com> = wrote:


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.

It depends which standards = you=92ve implemented. If you=92ve 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=92.

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 =93if you=92ve been = silent for X seconds, you can assume that I=92ve started a DPD and = probably killed your IKE SA=94.

and it doesn=92t 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.

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


AFAIK racoon doesn=92t 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. 
Do you mean screen = lock?

If that=92s what it is = called on an iPhone (I don=92t 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. 

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.

Yoav


<= /div>
= --Apple-Mail=_28B2A972-CCAF-48A3-A395-0F28367758D4-- From nobody Tue Aug 19 09:44:49 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 86C841A0650 for ; Tue, 19 Aug 2014 09:44:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FgMpIMVXynHv for ; Tue, 19 Aug 2014 09:44:43 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8C1D1A067E for ; Tue, 19 Aug 2014 09:44:42 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s7JGiciU004491 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Aug 2014 19:44:38 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s7JGibGR028254; Tue, 19 Aug 2014 19:44:37 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21491.32501.475060.892333@fireball.kivinen.iki.fi> Date: Tue, 19 Aug 2014 19:44:37 +0300 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <21490.4420.127387.489490@fireball.kivinen.iki.fi> <21491.9709.148603.972986@fireball.kivinen.iki.fi> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 2 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/zl0soFTwdftGh3MoD7GmIYHYvDQ Cc: ipsec@ietf.org, Les Leposo Subject: Re: [IPsec] IPsec Digest, Vol 123, Issue 21 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 16:44:45 -0000 Paul Wouters writes: > On Tue, 19 Aug 2014, Tero Kivinen wrote: > > >> 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. > > > > No need for port number. If server is under attack just block / slow > > down everybody using the same IP-address (or IP-address mask). > > Works great with CGN :P 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. -- kivinen@iki.fi From nobody Tue Aug 19 10:42:19 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F4211A8929 for ; Tue, 19 Aug 2014 10:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JsQkMToM_FZj for ; Tue, 19 Aug 2014 10:42:17 -0700 (PDT) Received: from mail-wg0-x22c.google.com (mail-wg0-x22c.google.com [IPv6:2a00:1450:400c:c00::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 403A61A066D for ; Tue, 19 Aug 2014 10:42:17 -0700 (PDT) Received: by mail-wg0-f44.google.com with SMTP id m15so6685352wgh.15 for ; Tue, 19 Aug 2014 10:42:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=HGo43t9B3riwpZhTwV56VzpPXZlN8wGK6emXCx8hKOo=; b=V+7PruAPItc6gGk5ITe8bvBN2ezEpjq6jtgqpnYiaf9MhU7J6jmXCUxfs3wDsTl2gd SjsWyOOULP4nA9E/uOd8HQmt4PxU1up/0Pxc+FEs+MVbTtVONMfYuvOuGuuuEEV5h62A FNXOcvvi2L/mf0mE7+nnYJPKmqr58XiyTsk+LZwMoT7G99TkoWnclX6q7VHmgOz9aoOv VyInypi7pM3bh62C8y8nMPYxl+sAQh8WYmjuQgEcPiEiLTPOcso5YKf97j48OrNumoTv bf+YCPXM7+1/jRiPmdN4AJPuzRsGPrNyxgNN/72+iRYSY9PtQDK5GenMN1Vk4yOqh3ww bKJQ== X-Received: by 10.180.184.99 with SMTP id et3mr8665768wic.31.1408470135927; Tue, 19 Aug 2014 10:42:15 -0700 (PDT) Received: from [192.168.0.17] ([197.237.48.207]) by mx.google.com with ESMTPSA id ph10sm52001726wjb.25.2014.08.19.10.42.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Aug 2014 10:42:14 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) From: Les Leposo In-Reply-To: Date: Tue, 19 Aug 2014 20:42:09 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <21490.4420.127387.489490@fireball.kivinen.iki.fi> <50B02F3B-2DA2-42D1-865E-9635A4D928BA@gmail.com> To: Paul Wouters X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/X5lEkvCFh8b1-TGGFzmCBunYrjE Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] IPsec Digest, Vol 123, Issue 21 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Aug 2014 17:42:18 -0000 On Aug 19, 2014, at 5:43 PM, Paul Wouters wrote: > On Tue, 19 Aug 2014, Les Leposo wrote: >=20 >>> the entire ipsec system is brought down/up, eg racoon is completely >>> killed and restarted all the time. >> Sounds like a totally reproducible crash/signal. >>=20 >> 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. >>=20 >> You would also have to indicate how long this problem has been = happening e.g. years/months, ios versions (to identify regressions). >=20 > Years ago I tried to file bug reports for IPsec to Apple. No feedback > ever, and lots of "developer" spam email. >=20 > 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. >=20 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). > Paul From nobody Wed Aug 20 04:36:45 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 89DDB1A024F for ; Wed, 20 Aug 2014 04:36:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.701 X-Spam-Level: X-Spam-Status: No, score=0.701 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5qQPEli0qJ0 for ; Wed, 20 Aug 2014 04:36:40 -0700 (PDT) Received: from mail-la0-x22c.google.com (mail-la0-x22c.google.com [IPv6:2a00:1450:4010:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7BFC31A0242 for ; Wed, 20 Aug 2014 04:36:39 -0700 (PDT) Received: by mail-la0-f44.google.com with SMTP id el20so7274390lab.3 for ; Wed, 20 Aug 2014 04:36:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type; bh=TZJNJQ+OyvgBhUJOAVNORfqSw605LDOfb9v/ZpwrI2w=; b=lGjG7d7CXUyAsTNf44kIUbHnjG9j95erNyphQFwTRIaJngMVzEcmIP8VwWxU9Nl6Hi uCMNFfl7IjwNtnYEErezpxC/SExPoA50qMN5FIeUlY3SHa/FDZZVMOVycdrGelqzXI4L mLYpZZky5TgYwYp/MdTyCAPty9EMF08ixrizL8dJeBmUZZjSE+mPd9mMpdVlNXQAxus3 7sHVOxpyn+apTAqKqFH+0gohvviBvbNsTOhPkfG7FBVJZnaJ/3RAxkbGIJbqsEfEZ2Go btzZv44Wkx6gbvQOYx1XeMafZ0xNbvtzc74NI2UvoqWqC1jD07A4n0q3IYhBu6TGAOuq zJCw== X-Received: by 10.152.6.133 with SMTP id b5mr25261777laa.16.1408534597115; Wed, 20 Aug 2014 04:36:37 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id bc17sm14300007lab.24.2014.08.20.04.36.35 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 20 Aug 2014 04:36:36 -0700 (PDT) Message-ID: <7C3DE8C9078E4ECC86A3CB77B9449616@buildpc> From: "Valery Smyslov" To: "Yaron Sheffer" , "ipsec" References: <53D287BA.2070104@gmail.com> Date: Wed, 20 Aug 2014 15:36:41 +0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0D9F_01CFBC8C.8A59FBB0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/9LgX_gzg0A20nkFmkOkvUwQl4zo Subject: Re: [IPsec] Garage door - let's pick a different example X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 11:36:42 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0D9F_01CFBC8C.8A59FBB0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Yaron, sorry for late reply - I was on vacation. I still think that the example is valid. The example describes the = remote opener which opens the only door. If you want to open different doors using single = opener then you might run into trouble you described. But this attack can be thwarted by = using more specific commands: not just "open" and "close", but "open garage = door", "close kitchen door" etc. In this case each door must know its name and must act only if received command concerns it. Note, that mutual = authentication is still not needed here. Another example, where initiator must be authenticated while responder is not needed to be authenticated is some sensor (e.g. temperature), = that sleeps most of the time, but periodically wakes up, measures something (like temperature) and sends the result to some server. Clearly, the = sensor must=20 be authenticated, but the server it connects to may be left = unauthenticated (I presume that the measurement itself is not secret, so no harm if attacker gets it, authentication is only needed for the server to be sure it receives authorative data). Regards, Valery. ----- Original Message -----=20 From: Yaron Sheffer=20 To: ipsec=20 Sent: Friday, July 25, 2014 8:37 PM Subject: [IPsec] Garage door - let's pick a different example This might sound like a nit, but we have this text in the draft, as a = use case for null auth: "User wants to get some simple action from the remote device. Consider = garage door opener: it must authenticate user to open the door, but it = is not necessary for the user to authenticate the door opener. In this = case one-way authentication is sufficient." The problem is, this is an incorrect protocol. Specifically, a MITM = (who might be physically located by the kitchen door), could redirect = the protocol exchange to a door different from the one I intended to = open. Seeing that nothing happens, I will simply press the remote again = and open the garage door, too. This is of course a generic problem, where unauthenticated protocols = have unforeseen consequences. Thanks, Yaron -------------------------------------------------------------------------= ----- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0D9F_01CFBC8C.8A59FBB0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Yaron,
 
sorry for late reply - I was on = vacation.
 
I still think that the example is valid. The example = describes=20 the remote opener which
opens the only door. If you = want to open=20 different doors using single opener then you might
run into trouble you described. But  this = attack can=20 be thwarted by using
more specific commands: not just "open" and "close", = but "open=20 garage door",
"close kitchen door" etc. In this case each door = must know its=20 name
and must act only if received command concerns it. = Note, that=20 mutual authentication
is still not needed here.
 
Another example, where initiator must be = authenticated while=20 responder
is not needed to be authenticated is some sensor = (e.g.=20 temperature), that
sleeps most of the time, but periodically wakes up,=20 measures something
(like temperature) and sends the result to some = server.=20 Clearly, the sensor must
be authenticated, but the = server it=20 connects to may be left unauthenticated
(I presume that the measurement itself is not = secret, so no=20 harm
if attacker gets it, authentication is only needed = for the=20 server to
be sure it receives authorative data).
 
Regards,
Valery.
 
 
----- Original Message -----
From:=20 Yaron=20 Sheffer
To: ipsec
Sent: Friday, July 25, 2014 = 8:37 PM
Subject: [IPsec] Garage door - = let's pick=20 a different example

This might sound like a nit, but we have this text in = the=20 draft, as a use case for null auth:

"User wants to get some = simple=20 action from the remote device. Consider garage door opener: it must=20 authenticate user to open the door, but it is not necessary for the = user to=20 authenticate the door opener.  In this case one-way = authentication is=20 sufficient."

The problem is, this is an incorrect protocol.=20 Specifically, a MITM (who might be physically located by the kitchen = door),=20 could redirect the protocol exchange to a door different from the one = I=20 intended to open. Seeing that nothing happens, I will simply press the = remote=20 again and open the garage door, too.

This is of course a = generic=20 problem, where unauthenticated protocols have unforeseen=20 consequences.

Thanks,
    Yaron

_______________________________________________
IPsec = mailing=20 = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
= ------=_NextPart_000_0D9F_01CFBC8C.8A59FBB0-- From nobody Wed Aug 20 04:44:15 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 062911A0240 for ; Wed, 20 Aug 2014 04:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.7 X-Spam-Level: X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NKmIrKS7xE3F for ; Wed, 20 Aug 2014 04:44:11 -0700 (PDT) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23BBE1A0201 for ; Wed, 20 Aug 2014 04:44:10 -0700 (PDT) Received: by mail-lb0-f171.google.com with SMTP id l4so6740040lbv.16 for ; Wed, 20 Aug 2014 04:44:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=L1WiRHpV2Ftak4vocfDxFwHC5WiFBmJ0iqNUmQK6zy0=; b=Vb3yBbAf9M3tWaJhgxmwgS2wqVmquNjmdd9qxYKr658f0xqak+mcaAxWvRX52qRjoJ YPF2pw8/c8xAIioMFgugr9mtDCpKh9fIPYcyXNjBunvMJ36qZ9D8y10Vf4jUtz+mBac6 8Iu8kWwrVOnMAJAh4VvyOly88WymbO1WKkGa6q1uOqikGYWg1huwubnK9C9cUaHy9FUP bZ0RJW9ZNfeCvaGeR2iqaaLhPyFJ1zwtiwlrZsiv+fm8sbMAgnUzOIyXbEOtiIe28mpo fvhZFmXbLtkrQdWTq2racmJR/yPs3AkT/8yWEi1QTtt8L2WrXvtVeb/I/4LNGDl1Jnu+ X77Q== X-Received: by 10.152.6.5 with SMTP id w5mr2255432law.94.1408535049408; Wed, 20 Aug 2014 04:44:09 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id n2sm14312201lag.18.2014.08.20.04.44.07 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 20 Aug 2014 04:44:08 -0700 (PDT) Message-ID: <928B7ECCB4514DD59919DA91270DC747@buildpc> From: "Valery Smyslov" To: "Yaron Sheffer" , "Tero Kivinen" References: <53D287BA.2070104@gmail.com> <21458.58173.437081.804657@fireball.kivinen.iki.fi> <53D3E6AA.9090500@gmail.com> Date: Wed, 20 Aug 2014 15:44:14 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/IfuPzF0nkSl6lxzyR_JK9XwjQt4 Cc: ipsec Subject: Re: [IPsec] Garage door - let's pick a different example X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 11:44:13 -0000 >> No, that is not caused by the unauthenticated protocol, but caused by >> the same device to be used with two different doors. Even if the >> device would do full authentication and would verify that the door is >> in his list of doors which can be opened, attacker could still do the >> same thing. >> >> Only way to get rid of that, would be to either put display on the >> device telling which door responded, or put multiple buttons to the >> device and you would have to bind each button to exactly one door >> (i.e. each button using separate key or shared secret). >> >> And, not you do not even need man in the middle in cryptographic >> sense, just rerouting the packets from the air to the other >> destination would be enough. >> >> So for that kind of uses the device would need to be tied to exactly >> one door... >> > > What you're saying is that to secure this system, we need authentication > of the device, either at the IKE level or at the application level (plus > UI improvements). I agree, and suggest again that this is not a good use > case for null or one-way authentication. Not really authentication of the devices, but at least indication in the protocol which device the sending command is concerned. And an ability for the device to understand who it is (garage or kitchen). That is cheaper than mutual authentication. Regards, Valery. > Thanks, > Yaron > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Aug 20 04:55:34 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D42471A0271 for ; Wed, 20 Aug 2014 04:55:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.354 X-Spam-Level: ** X-Spam-Status: No, score=2.354 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, TVD_FINGER_02=1.215] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qM_Czpb4Rs93 for ; Wed, 20 Aug 2014 04:55:32 -0700 (PDT) Received: from mail-la0-x22e.google.com (mail-la0-x22e.google.com [IPv6:2a00:1450:4010:c03::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C446D1A0270 for ; Wed, 20 Aug 2014 04:55:31 -0700 (PDT) Received: by mail-la0-f46.google.com with SMTP id b8so7143301lan.19 for ; Wed, 20 Aug 2014 04:55:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=IfUeIPPDs7IOYvYDLqQ/lGr70pNpvowcr2Ut01snX9M=; b=hiv1R7T6b2rVV1ShtVbLykiQUoONddEzodgN8GhkTUojGCv6SbO+GHkrYuAVeuybVl 9sfSbzaBXba11zq8PmioJloGvOhXU4S6c1SVY9xx79apzxhjdO142EsSBALCN/FC6KgD cdN7dIFCmw63oHIxA8DGZnVphH0eQ53f8TZ368+ItTAcDdUp7sQa0AnFx7/N7GZrywuS GmOk9wgajEhFXY/DnlTskrE+IVELpJyhg3N/HqregPwKMq+J7c/jsZ8jnN3UsHsGJxcs R1LBaTngdoUOU0H1j1T72a4ea6ENG/uzqwiNwWVvOrG0zh4NURRKd4ffzBczSPgTH6gU 3gTA== X-Received: by 10.112.114.227 with SMTP id jj3mr27952311lbb.39.1408535730008; Wed, 20 Aug 2014 04:55:30 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id p4sm14333175lap.0.2014.08.20.04.55.28 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 20 Aug 2014 04:55:29 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Hannes Tschofenig" References: <53D287BA.2070104@gmail.com> <53D6125B.4030509@gmx.net> <782DD2E2-9691-42A3-8D7F-5EF6268D98EB@gmail.com> Date: Wed, 20 Aug 2014 15:55:34 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1252"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/ZDLcnme4NIzgnaCqEKAhrbBQxnY Cc: ipsec Subject: Re: [IPsec] Garage door - let's pick a different example X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 11:55:33 -0000 Hi Hannes, I agree that the example is a bit artificial and in real life one would not use IKE/IPsec to control garage door. At least now. But if IoT becomes ubiquitous then who knows, probably such setup will be default "off shelf" solution... Regards, Valery. P.S. What about mutual authentication in this case - please see my reply to original Yaron's message. > Hi Yaron, > > if you further try to implement a prototype for a door opener then you > might run into a number of issues, such as > > * how does the garage opener discover the garage door? > * what radio technology are you going to use? > * how does the garage door authorize the garage opener? > > When you then answer all these questions you might realize (as I did) > that you neither want to use IPsec there nor even IP. > > Ciao > Hannes > > PS: I agree with your statement about mutual authentication. From nobody Wed Aug 20 05:17:20 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 21B2F1A02E8 for ; Wed, 20 Aug 2014 05:17:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.001 X-Spam-Level: X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fTjHZ9ka2ZYc for ; Wed, 20 Aug 2014 05:17:17 -0700 (PDT) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE4971A02E5 for ; Wed, 20 Aug 2014 05:17:16 -0700 (PDT) X-AuditID: c1b4fb30-f79736d0000053b8-2a-53f491ca6d9f Received: from ESESSHC013.ericsson.se (Unknown_Domain [153.88.253.124]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 66.EF.21432.AC194F35; Wed, 20 Aug 2014 14:17:15 +0200 (CEST) Received: from ESESSMB309.ericsson.se ([169.254.9.84]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.03.0174.001; Wed, 20 Aug 2014 14:17:14 +0200 From: =?iso-8859-1?Q?P=E5l_Dammvik?= To: "ipsec@ietf.org" Thread-Topic: Rekeying of child sa, Question on TS handling according to RFC 5996 Thread-Index: Ac+8cADLb6zidk/KSCOu+0//Eszt4w== Date: Wed, 20 Aug 2014 12:17:13 +0000 Message-ID: Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.20] Content-Type: multipart/alternative; boundary="_000_F68C660364DABE41AF4617F517EF548411707BE2ESESSMB309erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUyM+Jvje7piV+CDS7vYbLYv+UFmwOjx5Il P5kCGKO4bFJSczLLUov07RK4MhZOn85esN6uYua8t8wNjH1mXYycHBICJhIzt7WyQNhiEhfu rWcDsYUEjjJKnGvR7WLkArIXM0pM3vGUHSTBJmAvseTcMzBbREBV4tSy6awgtrCAr8S19hdA NgdQPERi3koBiBI9iW0TZ4PNZAEq39j8BqyVF6h8243JYK2MArIS97/fA7uBWUBc4taT+UwQ 9whILNlznhnCFpV4+fgfK4StKHF1+nImiPp8ifNbVrBCzBSUODnzCcsERqFZSEbNQlI2C0kZ RFxP4sbUKWwQtrbEsoWvmSFsXYkZ/w6xIIsvYGRfxShanFqclJtuZKSXWpSZXFycn6eXl1qy iREYEQe3/DbYwfjyueMhRgEORiUe3gUTPgcLsSaWFVfmHmKU5mBREuddeG5esJBAemJJanZq akFqUXxRaU5q8SFGJg5OqQbGsFR2cbnuE8XRc+5vnTllaS1L4e99K9doTn5fzvljVS6jr2i1 3fZ/apn+V3/MC67S2DAvd9tzgYObToWd9Wi7VXLZMnTlp7w12z2XzH5xxGt//J5lPKzG/EFf BFRvBOaEz4pyZilqelDJc2Iyv/GfqJ7nHY8u2DZ4eW0Tv//U481vaVsBI9YYJZbijERDLeai 4kQAOPaef2kCAAA= Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/uAZrPAVohlDRUDukGm2gQ_QRTgY Subject: [IPsec] Rekeying of child sa, Question on TS handling according to RFC 5996 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Aug 2014 12:17:19 -0000 --_000_F68C660364DABE41AF4617F517EF548411707BE2ESESSMB309erics_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable One of the differences between RFC 5996 and 4306 is in the rekeying where i= t's stated in RFC 5996 section 2.8: "Note that, when rekeying, the new Child SA SHOULD NOT have different Traff= ic Selectors and algorithms than the old one." Additionally in section 1.3.3 (that also addresses rekeying) of the same R= FC, it's stated: "The Traffic Selectors for traffic to be sent on that SA are specified in t= he TS payloads in the response, which may be a subset of what the initiator= of the Child SA proposed." I think these sentences leaves some room for interpretation what the create= child sa request message can contain in the rekeying scenario. When a node initiates rekeying of a child sa using the create child sa mes= sage exchange, which traffic selectors is it allowed to include in the crea= te child sa request? Does it have to be identical to the negotiated traff= ic selector from the old child sa (i.e. the traffic selector received in th= e original create child sa response for the sa) or can it for example be th= e same traffic selectors as originally proposed in the create child sa requ= est for the old child sa..? There is a strange sentence related to this topic in section 1.7 " Signific= ant Differences between RFC 4306 and This document" related to this topic: "The new Section 2.9.2 covers Traffic Selectors in rekeying." but there does not seem to be a chapter 2.9.2 in the document ?! Is this an editorial mistake or something missing? As the RFC has similar statement for the negotiated algorithms (i.e. encryp= tion, integrity), the same question pops up there.. I.e. should it in the c= reate child sa request only include the algorithms used by the old child sa= or can it include all algorithms originally proposed... Regards P=E5l --_000_F68C660364DABE41AF4617F517EF548411707BE2ESESSMB309erics_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

One of the differences between RFC 5996 and 4306 is in the rekeying w= here it's stated in RFC 5996 section  2.8:

 

"Note that, when rekeying, the new Child SA SHOULD NOT have diff= erent Traffic Selectors and algorithms than the old one."

 

Additionally in section 1.3.3 (that also addresses rekeying)  of= the same RFC,  it's stated:

 

"The Traffic Selectors for traffic to be sent on that SA are spe= cified in the TS payloads in the response, which may be a subset of what th= e initiator of the Child SA proposed."

 

I think these sentences leaves some room for interpretation what the = create child sa request message can contain in the rekeying scenario.

When a node initiates rekeying  of a child sa using the create c= hild sa message exchange, which traffic selectors is it allowed to include = in the create child  sa request?  Does it have to be identical to the negotiated traffic selector from the old child sa (= i.e. the traffic selector received in the original create child sa response= for the sa) or can it for example be the same traffic selectors as origina= lly proposed in the create child sa request for the old child sa..?

 

There is a strange sentence related to this topic in section 1.7 &quo= t; Significant Differences between RFC 4306 and This document" related= to this topic:

 

"The new Section 2.9.2 covers Traffic Selectors in rekeying.&quo= t;

 

but there does not seem to be a chapter 2.9.2 in the document ?!=

 

Is this an editorial mistake or something missing?<= /p>

 

As the RFC has similar statement for the negotiated algorithms (i.e. = encryption, integrity), the same question pops up there.. I.e. should it in= the create child sa request only include the algorithms used by the old child sa or can it include all algorithms o= riginally proposed...

 

Regards P=E5l

--_000_F68C660364DABE41AF4617F517EF548411707BE2ESESSMB309erics_-- From nobody Thu Aug 21 04:30:47 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C681A0196 for ; Thu, 21 Aug 2014 04:30:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.489 X-Spam-Level: X-Spam-Status: No, score=-1.489 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RP_MATCHES_RCVD=-0.668, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gsSC7DbiVwfa for ; Thu, 21 Aug 2014 04:30:43 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C59B01A0175 for ; Thu, 21 Aug 2014 04:30:42 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s7LBUds3021062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 21 Aug 2014 14:30:39 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s7LBUcAt020003; Thu, 21 Aug 2014 14:30:38 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <21493.55390.157248.181030@fireball.kivinen.iki.fi> Date: Thu, 21 Aug 2014 14:30:38 +0300 From: Tero Kivinen To: =?iso-8859-1?Q?P=E5l?= Dammvik In-Reply-To: References: X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 20 min X-Total-Time: 56 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/8d5AMMNgdlcov5N3tu7WFaD6hDs Cc: "ipsec@ietf.org" , sec-ads@tools.ietf.org Subject: [IPsec] Rekeying of child sa, Question on TS handling according to RFC 5996 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 11:30:45 -0000 P=E5l Dammvik writes: > One of the differences between RFC 5996 and 4306 is in the rekeying > where it's stated in RFC 5996 section 2.8: >=20 > "Note that, when rekeying, the new Child SA SHOULD NOT have > different Traffic Selectors and algorithms than the old one." >=20 > Additionally in section 1.3.3 (that also addresses rekeying) of the > same RFC, it's stated: >=20 > "The Traffic Selectors for traffic to be sent on that SA are > specified in the TS payloads in the response, which may be a subset > of what the initiator of the Child SA proposed." >=20 > I think these sentences leaves some room for interpretation what the > create child sa request message can contain in the rekeying > scenario. >=20 > When a node initiates rekeying of a child sa using the create child > sa message exchange, which traffic selectors is it allowed to > include in the create child sa request=3F Does it have to be identica= l > to the negotiated traffic selector from the old child sa (i.e. the > traffic selector received in the original create child sa response > for the sa) or can it for example be the same traffic selectors as > originally proposed in the create child sa request for the old child > sa..=3F >=20 > There is a strange sentence related to this topic in section 1.7 " > Significant Differences between RFC 4306 and This document" related > to this topic: >=20 > "The new Section 2.9.2 covers Traffic Selectors in rekeying." >=20 > but there does not seem to be a chapter 2.9.2 in the document =3F! >=20 > Is this an editorial mistake or something missing=3F Yes. This is editorial mistake done in 2009... There was original ticket #12 (2008-09-22).=20 http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/12=3Fversion=3D1#L1 which said that we should mention traffic selectors in rekeying.=20 Then we had discussion on the mailing list between 2009-04-01 and 2009-04-08.=20 http://www.ietf.org/mail-archive/web/ipsec/current/msg04112.html http://www.ietf.org/mail-archive/web/ipsec/current/msg04117.html http://www.ietf.org/mail-archive/web/ipsec/current/msg04129.html http://www.ietf.org/mail-archive/web/ipsec/current/msg04133.html http://www.ietf.org/mail-archive/web/ipsec/current/msg04134.html http://www.ietf.org/mail-archive/web/ipsec/current/msg04138.html Then the ticket was closed at 2009-04-20 with status of fixed and with status saying: Added section 2.9.2 on traffic selectors in rekeying. Also added a reference to the new section in 2.8. Then the ticket was reopened at 2009-04-24 and ticket was updated to include new text for the section 2.9.2: http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/12 ---------------------------------------------------------------------- 2.9.2 Traffic Selectors in Rekeying Rekeying is used to replace an existing Child SA with another. If the new SA were allowed to have a narrower set of selectors than the original, traffic that was allowed on the old SA would be dropped in the new SA, thus violating the idea of "replacing". Thus, the new SA MUST NOT have narrower selectors than the original. If the rekeyed SA would ever need to have narrower scope than currently used SA, that would mean that the policy was changed in a way that the currently used SAs are against the policy. In that case, the SA should have been already deleted after the policy change took effect. When the initiator attemepts to rekey the Child SA, the proposed traffic selectors SHOULD be either the same as, or a superset of, the traffic selectors used in the old Child SA. That is, they would be the same as, or a superset of, the currently active (decorrelated) policy. The responder MUST NOT narrow down the traffic selectors narrower than the scope currently in use. Because a rekeyed SA can never have narrower scope than the one currently in use, there is no need for the selectors from the packet, so those selectors SHOULD NOT be sent. ---------------------------------------------------------------------- Then 2009-08-10 the ticket was again closed with comment: Fixed in -05: In 2.8, changed "Note that, when rekeying, the new Child SA MAY have different traffic selectors and algorithms than the old one." to "Note that, when rekeying, the new Child SA SHOULD NOT have different traffic selectors and algorithms than the old one.". In -05 version of the draft this changes was really done, but the section 2.9.2 was not added. In the -07 version the change log was modified to say that the section 2.9.2 was added, but it still wasn't added. And nobody noticed this until now... The RFC editor just asked this when going through the rfc5996bis document, i.e. they asked what this 2.9.2 should be as it is referenced, but not included in the document. Does the missing section 2.9.2 quoted above answer your question=3F This is also question what should we do for the rfc5996bis. We have two options, we removed the text saying section 2.9.2 was added in the RFC5996, or we add the section 2.9.2 from the ticket #12, and add note that saying that this time we really added it... What does the working group feel we should do=3F Note, that if we add the 2.9.2 that might cause delays, as I am not sure if we can do that kind of change after IESG has already approved the rfc5996bis (it is now in the AUTH48), meaning it might need IESG to recheck that part. On the other hand I think adding the text which we already have approved in 2009 to the specification would be the right thing to do, as there clearly is need for clarification (as we can see from the Dammvik's question).=20 > As the RFC has similar statement for the negotiated algorithms (i.e. > encryption, integrity), the same question pops up there.. I.e. > should it in the create child sa request only include the algorithms > used by the old child sa or can it include all algorithms originally > proposed... --=20 kivinen@iki.fi From nobody Thu Aug 21 04:48:57 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE5E21A01F7 for ; Thu, 21 Aug 2014 04:48:55 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char E5 hex): To: ...en" ,\n\t"P\345l Dammvik" ; Thu, 21 Aug 2014 04:48:54 -0700 (PDT) Received: from mail-la0-x230.google.com (mail-la0-x230.google.com [IPv6:2a00:1450:4010:c03::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C0D121A01F2 for ; Thu, 21 Aug 2014 04:48:53 -0700 (PDT) Received: by mail-la0-f48.google.com with SMTP id gl10so8372660lab.21 for ; Thu, 21 Aug 2014 04:48:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=BksynOud7JRtJvG3u1SGQiJzzADGDAf0GUZpPKEKNss=; b=emCVJT+Aqxudp35A8y9PPzKOscCXHpiTQATVRdI9AE6mCqlZAQ3gEK7OS3V9Yl8hWG hea9o6ltz2hYpguGNNWk29KHvlxveRGw+HsaOE/y40vSh73XnshlmiTYqfVbIBuTSTjS Wh1cTRliFebFsa2FDlZq3GOgFZ2DQRaNrxll/rbj/KrZuyedZP+lTri9JLUkAas44wby bR82yo6BK+TfRrPNCyZgksmWvpyo/f4A8ra4pvdAoYuVIWeCPHGuKZMoqiC/AySBmJaD FDXPKhN7WtwB7QLBbmM9EVKn3niA4lA1k9RzwaoOOChLW2DoAUXG7Rk2MWRWzZGw2J+q y9gg== X-Received: by 10.112.56.206 with SMTP id c14mr44748728lbq.27.1408621732096; Thu, 21 Aug 2014 04:48:52 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id du2sm5428742lac.25.2014.08.21.04.48.50 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 21 Aug 2014 04:48:51 -0700 (PDT) Message-ID: <257268920DEA479E9FC65BFA164783C2@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" , "Pål Dammvik" References: <21493.55390.157248.181030@fireball.kivinen.iki.fi> Date: Thu, 21 Aug 2014 15:49:09 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/JSyXwCJR-1mZ_uTg8EO-nclOAw4 Cc: ipsec@ietf.org, sec-ads@tools.ietf.org Subject: Re: [IPsec] Rekeying of child sa, Question on TS handling according to RFC 5996 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 11:48:56 -0000 Hi Tero, > This is also question what should we do for the rfc5996bis. > > We have two options, we removed the text saying section 2.9.2 was > added in the RFC5996, or we add the section 2.9.2 from the ticket #12, > and add note that saying that this time we really added it... > > What does the working group feel we should do? Note, that if we add > the 2.9.2 that might cause delays, as I am not sure if we can do that > kind of change after IESG has already approved the rfc5996bis (it is > now in the AUTH48), meaning it might need IESG to recheck that part. > > On the other hand I think adding the text which we already have > approved in 2009 to the specification would be the right thing to do, > as there clearly is need for clarification (as we can see from the > Dammvik's question). I think we should add this text. The text is useful and I don't see a reason to sacrifice it in favour to speed up RFC publication. Regards, Valery. > kivinen@iki.fi From nobody Thu Aug 21 06:53:18 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC84D1A02E4 for ; Thu, 21 Aug 2014 06:53:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.901 X-Spam-Level: X-Spam-Status: No, score=-3.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9R0sQ-_2MVkq for ; Thu, 21 Aug 2014 06:53:14 -0700 (PDT) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DEEE1A02D8 for ; Thu, 21 Aug 2014 06:53:13 -0700 (PDT) X-AuditID: c1b4fb2d-f793d6d000005356-b3-53f5f9c7928d Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.124]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id 1C.A1.21334.7C9F5F35; Thu, 21 Aug 2014 15:53:11 +0200 (CEST) Received: from ESESSMB309.ericsson.se ([169.254.9.84]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.03.0174.001; Thu, 21 Aug 2014 15:53:11 +0200 From: =?iso-8859-1?Q?P=E5l_Dammvik?= To: Tero Kivinen Thread-Topic: [IPsec] Rekeying of child sa, Question on TS handling according to RFC 5996 Thread-Index: AQHPvTNVx7QAOH2/gU2uCwGWL297mpvbE4RA Date: Thu, 21 Aug 2014 13:53:10 +0000 Message-ID: References: <21493.55390.157248.181030@fireball.kivinen.iki.fi> In-Reply-To: <21493.55390.157248.181030@fireball.kivinen.iki.fi> Accept-Language: sv-SE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+Jvje7xn1+DDa70W1vs3/KCzeLo+eds FssXT2Z3YPZYsuQnk8fhrwtZPL5c/swWwBzFZZOSmpNZllqkb5fAlfH5xW3mgt3GFfsOzWFt YFyp2cXIySEhYCJx5lE/K4QtJnHh3nq2LkYuDiGBo4wSlyaeZIVwFjNKnNj0lw2kik3AXmLJ uWfsILaIgKLE7idbmUBsZoEoickzdoNNEhaIlmj+PI0JoiZGYuLvw8wQtpHE1ENfWUBsFgFV iWtnO8HivAK+EpdXzGWEWNbMKNE+8w3YMk4BB4l1Fw6ANTAKyErc/36PBWKZuMStJ/OZIM4W kFiy5zwzhC0q8fLxP6AjOIBsRYnl/XIQ5XoSN6ZOYYOwtSWWLXwNtVdQ4uTMJywTGMVmIZk6 C0nLLCQts5C0LGBkWcUoWpxaXJybbmSsl1qUmVxcnJ+nl5dasokRGFUHt/zW3cG4+rXjIUYB DkYlHt4HK78EC7EmlhVX5h5ilOZgURLnXXRuXrCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkG ximVEjNtzffm7j3Wzda21krnn5rr1+Z1vYfSjT+q7tqqs0ha493n97JfCna1yvqHn5kpWmnp 3uZp9/BF/p9nUhbRqtO+zO/YZ8VYL1dRNZ3/RPQxdxHmwD8hLl0PKi9KbdbT/vVRc+drO7vN b18/+/zlek/kdY2/+1bqP3sq2jzvfo/SgS1mb5RYijMSDbWYi4oTASiKZEyLAgAA Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/ZSMMoODFdNuMZIv0YMC_0lW881A Cc: "ipsec@ietf.org" , "sec-ads@tools.ietf.org" Subject: Re: [IPsec] Rekeying of child sa, Question on TS handling according to RFC 5996 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 13:53:17 -0000 Hi Tero, Thank's a lot for this clarification. I really think that the proposed te= xt for section 2.9.2 clarifies this in a good way and would appreciate if = that was inserted into the next revision. Regards P=E5l -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi]=20 Sent: den 21 augusti 2014 13:31 To: P=E5l Dammvik Cc: ipsec@ietf.org; sec-ads@tools.ietf.org Subject: [IPsec] Rekeying of child sa, Question on TS handling according to= RFC 5996 P=E5l Dammvik writes: > One of the differences between RFC 5996 and 4306 is in the rekeying > where it's stated in RFC 5996 section 2.8: >=20 > "Note that, when rekeying, the new Child SA SHOULD NOT have > different Traffic Selectors and algorithms than the old one." >=20 > Additionally in section 1.3.3 (that also addresses rekeying) of the > same RFC, it's stated: >=20 > "The Traffic Selectors for traffic to be sent on that SA are > specified in the TS payloads in the response, which may be a subset > of what the initiator of the Child SA proposed." >=20 > I think these sentences leaves some room for interpretation what the > create child sa request message can contain in the rekeying > scenario. >=20 > When a node initiates rekeying of a child sa using the create child > sa message exchange, which traffic selectors is it allowed to > include in the create child sa request? Does it have to be identical > to the negotiated traffic selector from the old child sa (i.e. the > traffic selector received in the original create child sa response > for the sa) or can it for example be the same traffic selectors as > originally proposed in the create child sa request for the old child > sa..? >=20 > There is a strange sentence related to this topic in section 1.7 " > Significant Differences between RFC 4306 and This document" related > to this topic: >=20 > "The new Section 2.9.2 covers Traffic Selectors in rekeying." >=20 > but there does not seem to be a chapter 2.9.2 in the document ?! >=20 > Is this an editorial mistake or something missing? Yes. This is editorial mistake done in 2009... There was original ticket #12 (2008-09-22).=20 http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/12?version=3D1#L1 which said that we should mention traffic selectors in rekeying.=20 Then we had discussion on the mailing list between 2009-04-01 and 2009-04-08.=20 http://www.ietf.org/mail-archive/web/ipsec/current/msg04112.html http://www.ietf.org/mail-archive/web/ipsec/current/msg04117.html http://www.ietf.org/mail-archive/web/ipsec/current/msg04129.html http://www.ietf.org/mail-archive/web/ipsec/current/msg04133.html http://www.ietf.org/mail-archive/web/ipsec/current/msg04134.html http://www.ietf.org/mail-archive/web/ipsec/current/msg04138.html Then the ticket was closed at 2009-04-20 with status of fixed and with status saying: Added section 2.9.2 on traffic selectors in rekeying. Also added a reference to the new section in 2.8. Then the ticket was reopened at 2009-04-24 and ticket was updated to include new text for the section 2.9.2: http://trac.tools.ietf.org/wg/ipsecme/trac/ticket/12 ---------------------------------------------------------------------- 2.9.2 Traffic Selectors in Rekeying Rekeying is used to replace an existing Child SA with another. If the new SA were allowed to have a narrower set of selectors than the original, traffic that was allowed on the old SA would be dropped in the new SA, thus violating the idea of "replacing". Thus, the new SA MUST NOT have narrower selectors than the original. If the rekeyed SA would ever need to have narrower scope than currently used SA, that would mean that the policy was changed in a way that the currently used SAs are against the policy. In that case, the SA should have been already deleted after the policy change took effect. When the initiator attemepts to rekey the Child SA, the proposed traffic selectors SHOULD be either the same as, or a superset of, the traffic selectors used in the old Child SA. That is, they would be the same as, or a superset of, the currently active (decorrelated) policy. The responder MUST NOT narrow down the traffic selectors narrower than the scope currently in use. Because a rekeyed SA can never have narrower scope than the one currently in use, there is no need for the selectors from the packet, so those selectors SHOULD NOT be sent. ---------------------------------------------------------------------- Then 2009-08-10 the ticket was again closed with comment: Fixed in -05: In 2.8, changed "Note that, when rekeying, the new Child SA MAY have different traffic selectors and algorithms than the old one." to "Note that, when rekeying, the new Child SA SHOULD NOT have different traffic selectors and algorithms than the old one.". In -05 version of the draft this changes was really done, but the section 2.9.2 was not added. In the -07 version the change log was modified to say that the section 2.9.2 was added, but it still wasn't added. And nobody noticed this until now... The RFC editor just asked this when going through the rfc5996bis document, i.e. they asked what this 2.9.2 should be as it is referenced, but not included in the document. Does the missing section 2.9.2 quoted above answer your question? This is also question what should we do for the rfc5996bis. We have two options, we removed the text saying section 2.9.2 was added in the RFC5996, or we add the section 2.9.2 from the ticket #12, and add note that saying that this time we really added it... What does the working group feel we should do? Note, that if we add the 2.9.2 that might cause delays, as I am not sure if we can do that kind of change after IESG has already approved the rfc5996bis (it is now in the AUTH48), meaning it might need IESG to recheck that part. On the other hand I think adding the text which we already have approved in 2009 to the specification would be the right thing to do, as there clearly is need for clarification (as we can see from the Dammvik's question).=20 > As the RFC has similar statement for the negotiated algorithms (i.e. > encryption, integrity), the same question pops up there.. I.e. > should it in the create child sa request only include the algorithms > used by the old child sa or can it include all algorithms originally > proposed... --=20 kivinen@iki.fi From nobody Thu Aug 21 12:21:16 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 655191A89F5 for ; Thu, 21 Aug 2014 12:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KbXhiKfNrIwg for ; Thu, 21 Aug 2014 12:21:12 -0700 (PDT) Received: from mail-we0-x229.google.com (mail-we0-x229.google.com [IPv6:2a00:1450:400c:c03::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66D071A86DF for ; Thu, 21 Aug 2014 12:21:12 -0700 (PDT) Received: by mail-we0-f169.google.com with SMTP id u56so9815101wes.0 for ; Thu, 21 Aug 2014 12:21:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=2luDZiG4+wN6a5RAxA2hk+boLDQnBM+3nr9qeIdmawc=; b=BiYHuWISDWQ94GiLdXbxkDdD5w72b9MqdfOjCziUGMuq8+8/nwQkmWMBcs4Wod17Og qKr78xIyuY7cLcgQeDeg3mUOUXq4gjifLyWcXxNJ2Fhr5mCwX0Lt02ChQ7gtjyBDEELn +sDSfJx8k2U3iyRjcM1YS83VuW7f253BrsB8a/BmlFRU6lqnVG8rZ6napnjQjKtBMYeu e5coqVUkxgepyXz6ciwMP7BH3YE9/9E1olHX3zT37TJ2/ATWJFFxjZEnfHJl1QkFMiwN b35l+FFdjel76qR0mWlnWuvG3dl/chgg7YKo1iy8/LHcAv5zUrk60g/yKAN87xadfFoy l33A== X-Received: by 10.180.205.234 with SMTP id lj10mr273184wic.1.1408648870793; Thu, 21 Aug 2014 12:21:10 -0700 (PDT) Received: from [192.168.1.104] (bzq-84-109-50-18.red.bezeqint.net. [84.109.50.18]) by mx.google.com with ESMTPSA id vn10sm68885101wjc.28.2014.08.21.12.21.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Aug 2014 12:21:10 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Content-Type: text/plain; charset=us-ascii From: Yoav Nir X-Priority: 3 In-Reply-To: <257268920DEA479E9FC65BFA164783C2@buildpc> Date: Thu, 21 Aug 2014 22:21:07 +0300 Content-Transfer-Encoding: 7bit Message-Id: <66302A57-27E5-46EF-A373-A82008169B8E@gmail.com> References: <21493.55390.157248.181030@fireball.kivinen.iki.fi> <257268920DEA479E9FC65BFA164783C2@buildpc> To: Valery Smyslov X-Mailer: Apple Mail (2.1878.6) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/S5UcdKlN3iMfgi4T515bmDodXI4 Cc: ipsec@ietf.org, sec-ads@tools.ietf.org, Tero Kivinen , =?iso-8859-1?Q?P=E5l_Dammvik?= Subject: Re: [IPsec] Rekeying of child sa, Question on TS handling according to RFC 5996 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 19:21:14 -0000 +1 On Aug 21, 2014, at 2:49 PM, Valery Smyslov wrote: > Hi Tero, > >> This is also question what should we do for the rfc5996bis. >> We have two options, we removed the text saying section 2.9.2 was >> added in the RFC5996, or we add the section 2.9.2 from the ticket #12, >> and add note that saying that this time we really added it... >> What does the working group feel we should do? Note, that if we add >> the 2.9.2 that might cause delays, as I am not sure if we can do that >> kind of change after IESG has already approved the rfc5996bis (it is >> now in the AUTH48), meaning it might need IESG to recheck that part. >> On the other hand I think adding the text which we already have >> approved in 2009 to the specification would be the right thing to do, >> as there clearly is need for clarification (as we can see from the >> Dammvik's question). > > I think we should add this text. The text is useful and I don't see > a reason to sacrifice it in favour to speed up RFC publication. > > Regards, > Valery. > >> kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Thu Aug 21 14:19:43 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA2CE1A0B0E for ; Thu, 21 Aug 2014 14:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YNTNiWObbLhC for ; Thu, 21 Aug 2014 14:19:38 -0700 (PDT) Received: from mail-qg0-x234.google.com (mail-qg0-x234.google.com [IPv6:2607:f8b0:400d:c04::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BACF1A0ACA for ; Thu, 21 Aug 2014 14:19:38 -0700 (PDT) Received: by mail-qg0-f52.google.com with SMTP id f51so9380600qge.39 for ; Thu, 21 Aug 2014 14:19:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:mime-version:subject:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=fyY9X4kE7RA5Oi+P/BQdyor7uRzZf15nxUW2WrzikGw=; b=ljPT1PpI6P5mT7hkZcqmuVaCtSXTYD5M69n1JUSD11eK9+eCo0dPH4poJHhg+1WfhJ 1OteWtQgP4vlo5fTj/8tt51PwUFg1DcbBlw5Wn4Z6ObGIAZEjLu0vPvNWZKXxg9Q4ccU DqIAlXpg1B3Zr+R/cXWZgm7fw3uHMh8FhXGyfqgrxak4ppfFTW9mndMI20SSwECIv8+m X2yWxYU34AXPvuYlrsTj1whZJFe6dkgbfB/uf853jCrdU4KAlHcr//ZtVCT+NEWLNp4h LT2HpSuoNPK5goh4D4kcn/KhRaq/6teVEPPIiAlRFjwqyiEUvHENEhy8Xctt9RNs07on VL9w== X-Received: by 10.140.103.75 with SMTP id x69mr1759724qge.17.1408655977381; Thu, 21 Aug 2014 14:19:37 -0700 (PDT) Received: from [192.168.1.7] (pool-96-233-18-79.bstnma.east.verizon.net. [96.233.18.79]) by mx.google.com with ESMTPSA id a41sm30745998qgf.37.2014.08.21.14.19.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 21 Aug 2014 14:19:35 -0700 (PDT) From: Kathleen Moriarty X-Google-Original-From: Kathleen Moriarty Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) X-Mailer: iPhone Mail (11D257) In-Reply-To: <66302A57-27E5-46EF-A373-A82008169B8E@gmail.com> Date: Thu, 21 Aug 2014 17:19:31 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <21493.55390.157248.181030@fireball.kivinen.iki.fi> <257268920DEA479E9FC65BFA164783C2@buildpc> <66302A57-27E5-46EF-A373-A82008169B8E@gmail.com> To: Yoav Nir Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/aa9e8CAtQ4dGCl7ir3HiXvqHH8I Cc: "ipsec@ietf.org" , Valery Smyslov , "sec-ads@tools.ietf.org" , Tero Kivinen , =?utf-8?Q?P=C3=A5l_Dammvik?= Subject: Re: [IPsec] Rekeying of child sa, Question on TS handling according to RFC 5996 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Aug 2014 21:19:40 -0000 Assuming this is agreed upon by the working group, getting the text to be ad= ded along with a diff of the draft will be helpful to share with the IESG. T= hey will want a quick look to make sure they agree, but it sounds like this m= akes sense. Thanks, Kathleen=20 Sent from my iPhone > On Aug 21, 2014, at 3:21 PM, Yoav Nir wrote: >=20 > +1 >=20 >> On Aug 21, 2014, at 2:49 PM, Valery Smyslov wrote: >>=20 >> Hi Tero, >>=20 >>> This is also question what should we do for the rfc5996bis. >>> We have two options, we removed the text saying section 2.9.2 was >>> added in the RFC5996, or we add the section 2.9.2 from the ticket #12, >>> and add note that saying that this time we really added it... >>> What does the working group feel we should do? Note, that if we add >>> the 2.9.2 that might cause delays, as I am not sure if we can do that >>> kind of change after IESG has already approved the rfc5996bis (it is >>> now in the AUTH48), meaning it might need IESG to recheck that part. >>> On the other hand I think adding the text which we already have >>> approved in 2009 to the specification would be the right thing to do, >>> as there clearly is need for clarification (as we can see from the >>> Dammvik's question). >>=20 >> I think we should add this text. The text is useful and I don't see >> a reason to sacrifice it in favour to speed up RFC publication. >>=20 >> Regards, >> Valery. >>=20 >>> kivinen@iki.fi >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Fri Aug 22 12:26:42 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 986CB1A058E for ; Fri, 22 Aug 2014 12:26:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b75Nq7V-YeN5 for ; Fri, 22 Aug 2014 12:26:38 -0700 (PDT) Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C4B961A04B4 for ; Fri, 22 Aug 2014 12:26:37 -0700 (PDT) Received: by mail-wi0-f178.google.com with SMTP id hi2so133340wib.17 for ; Fri, 22 Aug 2014 12:26:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=aX4Bs0nsV37YycqloQt5yZyMX9Pac+pp9fOJavTSFs4=; b=wSw58LUtfhdgROhmOrsfPt9SEaX6vEE1l5tzFdrMDPHs5fAIOrmEBBM1tIbKK4V7mv G74OXZnrpnpku/T9Gnf+fpm55HWTdi0sJl/gCMehpHjkw6XN8UGOrwTa93H3qa7D8cHd Ch5l0kEjqHlDoS2S8jiiRF3oGdmR6A1Nr6X3BXyTbKklN61hJeWA/m+/DbAccbJxQJRd SJnvb/M9ZyoL9/UkxrmyRQ/RiY9kE3uiLVUt/RLtUKSuMRD1OolVB5qI37vCCzSoHZ9R HzxKE/A7CnZ0AOR+FZfBQ557UPLTKjW/liK0zxuBmdbQl9R/X3vJd8A8SZAHHRyiUCWp nYjA== X-Received: by 10.180.99.4 with SMTP id em4mr541305wib.8.1408735596285; Fri, 22 Aug 2014 12:26:36 -0700 (PDT) Received: from [10.0.0.3] (bzq-79-177-106-104.red.bezeqint.net. [79.177.106.104]) by mx.google.com with ESMTPSA id xw9sm77336389wjc.32.2014.08.22.12.26.35 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 22 Aug 2014 12:26:35 -0700 (PDT) Message-ID: <53F79969.5030906@gmail.com> Date: Fri, 22 Aug 2014 22:26:33 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: ipsec References: <20140822174338.3A91F18047C@rfc-editor.org> In-Reply-To: <20140822174338.3A91F18047C@rfc-editor.org> X-Forwarded-Message-Id: <20140822174338.3A91F18047C@rfc-editor.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/fp22-gZZytPLyY735dkzLLLHHTc Subject: [IPsec] Fwd: RFC 7321 on Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Aug 2014 19:26:40 -0000 -------- Forwarded Message -------- Subject: RFC 7321 on Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) Date: Fri, 22 Aug 2014 10:43:38 -0700 (PDT) From: rfc-editor@rfc-editor.org Reply-To: ietf@ietf.org To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org CC: drafts-update-ref@iana.org, rfc-editor@rfc-editor.org A new Request for Comments is now available in online RFC libraries. RFC 7321 Title: Cryptographic Algorithm Implementation Requirements and Usage Guidance for Encapsulating Security Payload (ESP) and Authentication Header (AH) Author: D. McGrew, P. Hoffman Status: Standards Track Stream: IETF Date: August 2014 Mailbox: mcgrew@cisco.com, paul.hoffman@vpnc.org Pages: 11 Characters: 25724 Obsoletes: RFC 4835 I-D Tag: draft-ietf-ipsecme-esp-ah-reqts-10.txt URL: https://www.rfc-editor.org/rfc/rfc7321.txt This document updates the Cryptographic Algorithm Implementation Requirements for the Encapsulating Security Payload (ESP) and Authentication Header (AH). It also adds usage guidance to help in the selection of these algorithms. ESP and AH protocols make use of various cryptographic algorithms to provide confidentiality and/or data origin authentication to protected data communications in the IP Security (IPsec) architecture. To ensure interoperability between disparate implementations, the IPsec standard specifies a set of mandatory-to- implement algorithms. This document specifies the current set of mandatory-to-implement algorithms for ESP and AH, specifies algorithms that should be implemented because they may be promoted to mandatory at some future time, and also recommends against the implementation of some obsolete algorithms. Usage guidance is also provided to help the user of ESP and AH best achieve their security goals through appropriate choices of cryptographic algorithms. This document is a product of the IP Security Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet Standards Track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the Official Internet Protocol Standards (https://www.rfc-editor.org/standards) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Sat Aug 23 02:13:13 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 387761A8738 for ; Sat, 23 Aug 2014 02:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L36BhqDSQum4 for ; Sat, 23 Aug 2014 02:13:08 -0700 (PDT) Received: from mail-wi0-x234.google.com (mail-wi0-x234.google.com [IPv6:2a00:1450:400c:c05::234]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA24A1A8736 for ; Sat, 23 Aug 2014 02:13:07 -0700 (PDT) Received: by mail-wi0-f180.google.com with SMTP id n3so602462wiv.13 for ; Sat, 23 Aug 2014 02:13:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=7ZsQq2S23C+iRX8Swnkz98JtmMNTmot1ciwcZGuY6sg=; b=0R4jOm5iogvxQgX4SdBBYTtdeRwhwWhENbNh6S1v6H7rURgzqT/4zQZT1klVR/+EPL 5VuOfNf69NmsOnexnGXRTxj0ZvsEbDUwqh3hh6SiP2u6zq1b2xfNv6vYwRv3bh7ZoKLa 20AyQCW059vtnZkKScR/JJ+QnnSivncPvNvlWGUkidd1ryngjLXx8cFD0SYcalwcxJ0V WLWJ+mNX8YMBcWeRqofPGoU2v/uAElL9uBszx3UAnN8dZxh1NNLyGliqs4NKT9fJt6gJ B7wky0CXmwW3703VDiUgf680z/B43SF/+iQy4KQaliWVefSwndXUkSRSdshANQArJAkW pPoQ== X-Received: by 10.180.75.49 with SMTP id z17mr3152759wiv.80.1408785186363; Sat, 23 Aug 2014 02:13:06 -0700 (PDT) Received: from [10.0.0.3] (bzq-79-177-106-104.red.bezeqint.net. [79.177.106.104]) by mx.google.com with ESMTPSA id ne14sm1149975wic.14.2014.08.23.02.13.05 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 23 Aug 2014 02:13:05 -0700 (PDT) Message-ID: <53F85B1F.6000007@gmail.com> Date: Sat, 23 Aug 2014 12:13:03 +0300 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Valery Smyslov , ipsec References: <53D287BA.2070104@gmail.com> <7C3DE8C9078E4ECC86A3CB77B9449616@buildpc> In-Reply-To: <7C3DE8C9078E4ECC86A3CB77B9449616@buildpc> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/DGJdmWAJ6q2n5QM-FjwD7JbO7x8 Subject: Re: [IPsec] Garage door - let's pick a different example X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Aug 2014 09:13:10 -0000 Hi Valery, I agree the garage system can be made secure, if engineered correctly. But garage engineering is out of scope for this draft :-) IMO the sensor example is much simpler and therefore much better. I would suggest that you replace the garage in the draft by a thermometer. Thanks, Yaron On 08/20/2014 02:36 PM, Valery Smyslov wrote: > Hi Yaron, > sorry for late reply - I was on vacation. > I still think that the example is valid. The example describes > the remote opener which > opens the only door. If you want to open different doors using single > opener then you might > run into trouble you described. But this attack can be thwarted by using > more specific commands: not just "open" and "close", but "open garage door", > "close kitchen door" etc. In this case each door must know its name > and must act only if received command concerns it. Note, that mutual > authentication > is still not needed here. > Another example, where initiator must be authenticated while responder > is not needed to be authenticated is some sensor (e.g. temperature), that > sleeps most of the time, but periodically wakes up, measures something > (like temperature) and sends the result to some server. Clearly, the > sensor must > be authenticated, but the server it connects to may be left unauthenticated > (I presume that the measurement itself is not secret, so no harm > if attacker gets it, authentication is only needed for the server to > be sure it receives authorative data). > Regards, > Valery. > ----- Original Message ----- > > *From:* Yaron Sheffer > *To:* ipsec > *Sent:* Friday, July 25, 2014 8:37 PM > *Subject:* [IPsec] Garage door - let's pick a different example > > This might sound like a nit, but we have this text in the draft, as > a use case for null auth: > > "User wants to get some simple action from the remote device. > Consider garage door opener: it must authenticate user to open the > door, but it is not necessary for the user to authenticate the door > opener. In this case one-way authentication is sufficient." > > The problem is, this is an incorrect protocol. Specifically, a MITM > (who might be physically located by the kitchen door), could > redirect the protocol exchange to a door different from the one I > intended to open. Seeing that nothing happens, I will simply press > the remote again and open the garage door, too. > > This is of course a generic problem, where unauthenticated protocols > have unforeseen consequences. > > Thanks, > Yaron > > ------------------------------------------------------------------------ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Mon Aug 25 05:10:54 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA05A1A904A for ; Mon, 25 Aug 2014 05:10:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.268 X-Spam-Level: X-Spam-Status: No, score=-3.268 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.668] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id htXMjdDJbUbG for ; Mon, 25 Aug 2014 05:10:50 -0700 (PDT) Received: from a.mx.secunet.com (a.mx.secunet.com [195.81.216.161]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A68C81A9043 for ; Mon, 25 Aug 2014 05:10:50 -0700 (PDT) Received: from localhost (alg1 [127.0.0.1]) by a.mx.secunet.com (Postfix) with ESMTP id 146191A0078; Mon, 25 Aug 2014 14:10:45 +0200 (CEST) X-Virus-Scanned: by secunet Received: from a.mx.secunet.com ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id wQnIQbpb2wz7; Mon, 25 Aug 2014 14:10:36 +0200 (CEST) Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by a.mx.secunet.com (Postfix) with ESMTP id 6889D1A0076; Mon, 25 Aug 2014 14:10:36 +0200 (CEST) Received: from [10.208.1.76] (10.208.1.76) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 25 Aug 2014 14:10:39 +0200 Message-ID: <53FB27BE.2010504@secunet.com> Date: Mon, 25 Aug 2014 14:10:38 +0200 From: Johannes Merkle User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Tero Kivinen References: <20140701161112.18036.94027.idtracker@ietfa.amsl.com> <53B6BA3F.40509@secunet.com> <21452.4707.784185.458764@fireball.kivinen.iki.fi> <53D225B4.2030508@secunet.com> In-Reply-To: <53D225B4.2030508@secunet.com> Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.76] Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/ZITxZ7odvy4GKkslAbP1H-z7L4Q Cc: ipsec@ietf.org Subject: Re: [IPsec] Last Call: (Signature Authentication in IKEv2) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 12:10:53 -0000 Tero, you haven't responded to my objection yet. Please let me know if you think that I am mistaken; otherwise the example should be corrected. Johannes Johannes Merkle wrote on 25.07.2014 11:39: > Tero, > > thanks for updating the document. However, I'm not sure the first issue is solved. > > Tero Kivinen wrote on 20.07.2014 21:02: >> Changed to: >> >> With RSASSA-PSS, the algorithm object identifier must always >> be id-RSASSA-PSS, and the hash function and padding parameters >> are conveyed in the parameters (which are not optional in this >> case). See for more information. >> >> In the RSASSA-PSS the parameters are required, but they can be empty, >> so they are not optional in this case. >> > > Really? Section 3.1 of RFC 4055 states > When RSASSA-PSS is used in an AlgorithmIdentifier, the parameters > MUST employ the RSASSA-PSS-params syntax. The parameters may be > either absent or present when used as subject public key information. > > My understanding of this is that the parameters can indeed be absent not just empty. > > IMHO the semantic is different: If the parameters are empty (empty sequence in RSASSA-PSS-param), the default values > apply, and according to Section 3.3, case 3, of RFC 4055, the parameters in a signature MUST be validated against the > (default) parameters specified in SPKI. However, if the parameters are absent, then, according to Section 3.3, case 2, > of RFC 4055, no parameter validation is needed in a signature validation, i.e. a signature may use any parameters. > > Maybe, I misinterpret the spec here? > > > > From nobody Mon Aug 25 05:42:33 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3808F1A9083 for ; Mon, 25 Aug 2014 05:42:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 160vc14yy0AL for ; Mon, 25 Aug 2014 05:42:29 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C244F1A9082 for ; Mon, 25 Aug 2014 05:42:28 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s7PCgPbN027260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 25 Aug 2014 15:42:25 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s7PCgPFM017386; Mon, 25 Aug 2014 15:42:25 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21499.12081.402882.766863@fireball.kivinen.iki.fi> Date: Mon, 25 Aug 2014 15:42:25 +0300 From: Tero Kivinen To: Johannes Merkle In-Reply-To: <53FB27BE.2010504@secunet.com> References: <20140701161112.18036.94027.idtracker@ietfa.amsl.com> <53B6BA3F.40509@secunet.com> <21452.4707.784185.458764@fireball.kivinen.iki.fi> <53D225B4.2030508@secunet.com> <53FB27BE.2010504@secunet.com> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 6 min X-Total-Time: 6 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/vzwVJlPGAmRGD0JLjaeloXDKUJg Cc: ipsec@ietf.org Subject: Re: [IPsec] Last Call: (Signature Authentication in IKEv2) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Aug 2014 12:42:31 -0000 Johannes Merkle writes: > you haven't responded to my objection yet. Please let me know if you > think that I am mistaken; otherwise the example > should be corrected. I have not have time to come back to this draft yet, I was still supposed to be on vacation for last week and this week, but I had to get back to get the RFC5996bis stuff going, so thats why I have been trying to concentrate on that. Yes, I think you are right that the change I made in there might not be correct. I need to try to parse the RFCs more to try to find out how the RSASSA-PSS parameters are supposed to be included. There is also cases that inside the parameters there is hash and mgf algorithms, which have parameters and they have again different rules whether they needs to be include, absent etc... The RSASSA-PSS is so complicated that getting things right seems to require multiple readings of the RFCs to parse everything right :-) Luckily all this text is non-normative, the implementors are supposed to be reading the other RFCs for real specifications, but that does not mean we can write anything that is wrong here either... -- kivinen@iki.fi From nobody Thu Aug 28 07:32:23 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98E981A6F80 for ; Thu, 28 Aug 2014 07:32:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.896 X-Spam-Level: ** X-Spam-Status: No, score=2.896 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439, STOX_REPLY_TYPE_WITHOUT_QUOTES=1.757] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j1A9dkbB2zRw for ; Thu, 28 Aug 2014 07:32:18 -0700 (PDT) Received: from mail-lb0-x233.google.com (mail-lb0-x233.google.com [IPv6:2a00:1450:4010:c04::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 618611A6F83 for ; Thu, 28 Aug 2014 07:32:17 -0700 (PDT) Received: by mail-lb0-f179.google.com with SMTP id l4so981314lbv.24 for ; Thu, 28 Aug 2014 07:32:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:references:subject:date:mime-version :content-type:content-transfer-encoding; bh=pRuaJcBmocFYge4VqxxpepNOB3+hWs3aTxkMxgYg9UI=; b=0MEm8LALDh79Qi8i01YXnedrXNm+/gJXJZsUeTOmJ/dHNIORZLsJ1k5QQsH8zpt4Xa FY0M8ZFPPFkH3CxkwJpyz0oprGnMFC/c4xsl8m+gDjq0JEPYFkZI/4JILXHWuc6oYYE4 KQxdkivbhMlMeii2WNb8TdBPh6ZWN4fUJYleEV+eLm6CCMcgByrzHdGkSbN6hZdzCnM0 qF1jEJdyGvt49bOhzqiT0fDMmolzN0f8X7848564NhfDxXDG0h2/nYHSapfnM7G9zuhg axDpOgN3ElWPDhA0ENAHVSUJ//WN8zA2Fy91eZnXtv1kut3hIK3aexcg1zkG6D3lMNjb oteA== X-Received: by 10.152.245.171 with SMTP id xp11mr4731352lac.61.1409236335672; Thu, 28 Aug 2014 07:32:15 -0700 (PDT) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id tc8sm6256883lbb.8.2014.08.28.07.32.14 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 28 Aug 2014 07:32:14 -0700 (PDT) Message-ID: From: "Valery Smyslov" To: "Tero Kivinen" , References: <21493.55390.157248.181030@fireball.kivinen.iki.fi> Date: Thu, 28 Aug 2014 18:33:38 +0400 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/AZAlOlzdp4faZ5eDdNsWUfyNzO4 Subject: [IPsec] Typos in draft-kivinen-ipsecme-ikev2-rfc5996bis-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Aug 2014 14:32:20 -0000 Hi, if new version of draft-kivinen-ipsecme-ikev2-rfc5996bis is issued, then it is also possible fix a typo I've come across. Section 2.8.1, second para: This form of rekeying may temporarily result in multiple similar SAs between the same pairs of nodes. When there are two SAs eligible to receive packets, a node MUST accept incoming packets through either SA. If redundant SAs are created though such a collision, the SA ^^^^^^ s/though/through created with the lowest of the four nonces used in the two exchanges SHOULD be closed by the endpoint that created it. Regards, Valery. From nobody Fri Aug 29 06:13:13 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D0ED1A0342 for ; Fri, 29 Aug 2014 06:13:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.789 X-Spam-Level: X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.668, SPF_NEUTRAL=0.779] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AQ-t7M9rEtKL for ; Fri, 29 Aug 2014 06:13:08 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi [IPv6:2001:1bc8:100d::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C647F1A030B for ; Fri, 29 Aug 2014 06:11:50 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.8/8.14.8) with ESMTP id s7TDBkEX000643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 29 Aug 2014 16:11:46 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id s7TDBkju000246; Fri, 29 Aug 2014 16:11:46 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21504.31762.454252.961126@fireball.kivinen.iki.fi> Date: Fri, 29 Aug 2014 16:11:46 +0300 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: References: <21493.55390.157248.181030@fireball.kivinen.iki.fi> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 1 min X-Total-Time: 1 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/qR_ZR21GcuAKQJ4-yP_P0ZWOkqs Cc: ipsec@ietf.org Subject: [IPsec] Typos in draft-kivinen-ipsecme-ikev2-rfc5996bis-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Aug 2014 13:13:10 -0000 Valery Smyslov writes: > if new version of draft-kivinen-ipsecme-ikev2-rfc5996bis is issued, > then it is also possible fix a typo I've come across. > > Section 2.8.1, second para: > This form of rekeying may temporarily result in multiple similar SAs > between the same pairs of nodes. When there are two SAs eligible to > receive packets, a node MUST accept incoming packets through either > SA. If redundant SAs are created though such a collision, the SA > ^^^^^^ > s/though/through > created with the lowest of the four nonces used in the two exchanges > SHOULD be closed by the endpoint that created it. This typo was already noticed and fixed during the rfc-editor process. -- kivinen@iki.fi From nobody Sun Aug 31 21:28:31 2014 Return-Path: X-Original-To: ipsec@ietfa.amsl.com Delivered-To: ipsec@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB3A11A9105 for ; Sun, 31 Aug 2014 21:28:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_WEB=0.77, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxPQFOPV7z2g for ; Sun, 31 Aug 2014 21:28:27 -0700 (PDT) Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1blp0184.outbound.protection.outlook.com [207.46.163.184]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 298E31A6F85 for ; Sun, 31 Aug 2014 21:28:26 -0700 (PDT) Received: from DM2PR0601MB713.namprd06.prod.outlook.com (10.242.115.155) by DM2PR0601MB714.namprd06.prod.outlook.com (10.242.115.156) with Microsoft SMTP Server (TLS) id 15.0.1015.19; Mon, 1 Sep 2014 04:28:23 +0000 Received: from DM2PR0601MB713.namprd06.prod.outlook.com ([10.242.115.155]) by DM2PR0601MB713.namprd06.prod.outlook.com ([10.242.115.155]) with mapi id 15.00.1015.018; Mon, 1 Sep 2014 04:28:24 +0000 From: Avishek Ganguly To: "ipsec@ietf.org" Thread-Topic: Question Regarding IKEv2 RFC5996 Use of NO_PROPOSAL_CHOSEN and INVALID_KE_PAYLOAD Thread-Index: Ac/FnSWEFTen3/ebTi+t+niQ7k32vQ== Date: Mon, 1 Sep 2014 04:28:23 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [121.242.14.67] x-microsoft-antispam: BCL:0;PCL:0;RULEID:;UriScan:; x-forefront-prvs: 03218BFD9F x-forefront-antispam-report: SFV:NSPM; SFS:(6009001)(189002)(199003)(95666004)(107046002)(99286002)(90102001)(33646002)(99396002)(50986999)(2351001)(54356999)(229853001)(110136001)(76576001)(31966008)(92566001)(74316001)(561944003)(2501002)(106356001)(16236675004)(105586002)(108616004)(15202345003)(15975445006)(66066001)(80022001)(79102001)(74662001)(46102001)(87936001)(85306004)(4396001)(76482001)(2656002)(21056001)(19580395003)(74502001)(86362001)(19625215002)(85852003)(19300405004)(83322001)(20776003)(81342001)(83072002)(101416001)(64706001)(77982001)(81542001)(24736002); DIR:OUT; SFP:; SCL:1; SRVR:DM2PR0601MB714; H:DM2PR0601MB713.namprd06.prod.outlook.com; FPR:; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Content-Type: multipart/alternative; boundary="_000_f349616c76c3467a95239d459bb4fb01DM2PR0601MB713namprd06p_" MIME-Version: 1.0 X-OriginatorOrg: ixiacom.com X-MS-Exchange-CrossPremises-AuthAs: Internal X-MS-Exchange-CrossPremises-AuthMechanism: 04 X-MS-Exchange-CrossPremises-AuthSource: DM2PR0601MB713.namprd06.prod.outlook.com X-MS-Exchange-CrossPremises-SCL: 1 X-MS-Exchange-CrossPremises-messagesource: StoreDriver X-MS-Exchange-CrossPremises-BCC: X-MS-Exchange-CrossPremises-originalclientipaddress: 121.242.14.67 X-MS-Exchange-CrossPremises-avstamp-service: 1.0 X-MS-Exchange-CrossPremises-antispam-scancontext: DIR:Originating; SFV:NSPM; SKIP:0; X-MS-Exchange-CrossPremises-processed-by-journaling: Journal Agent X-OrganizationHeadersPreserved: DM2PR0601MB714.namprd06.prod.outlook.com Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/I2BcdJzT12Rkol48HO1WDMDxSVU Cc: Avishek Ganguly Subject: [IPsec] Question Regarding IKEv2 RFC5996 Use of NO_PROPOSAL_CHOSEN and INVALID_KE_PAYLOAD X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Sep 2014 04:28:28 -0000 --_000_f349616c76c3467a95239d459bb4fb01DM2PR0601MB713namprd06p_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, I have questions regarding use of NO_PROPOSAL_CHOSEN and INVALID_KE_PAYLOAD= in IKE_SA_INIT exchange in RFC 5996 IKEv2. According to "Section 3.10.1. Notify Message Types NO_PROPOSAL_CHOSEN 14 None of the proposed crypto suites was acceptable. This can be sent in any case where the offered proposals (including but not limited to SA payload values, USE_TRANSPORT_MODE notify, IPCOMP_SUPPORTED notify) are not acceptable for the responder. " according to the above statement it is meant that if initiator sends a prop= osal with a Diffie-Hellman group value that is unacceptable by the responde= r, then responder must send a NO_PROPOSAL_CHOSEN notification. But according to "Section 1.2. The Initial Exchanges Because the initiator sends its Diffie-Hellman value in the IKE_SA_INIT, it must guess the Diffie-Hellman group that the responder will select from its list of supported groups. If the initiator guesses wrong, the responder will respond with a Notify payload of type INVALID_KE_PAYLOAD indicating the selected group. " >From the INVALID_KE_PAYLOAD description stated above means that NO_PROPOSAL= _CHOSEN case is exclusive of this INVALID_KE_PAYLOAD. Is it right interpretation of the above two error types ? Thanks and Regards, Avishek --_000_f349616c76c3467a95239d459bb4fb01DM2PR0601MB713namprd06p_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

I have questions regarding use of NO_PROPOSAL_CHOSEN= and INVALID_KE_PAYLOAD in IKE_SA_INIT exchange in RFC 5996 IKEv2.

According to

"Section 3.10.1.  Notify Message Types

NO_PROPOSAL_CHOSEN     &nbs= p;            &= nbsp;    14

      None of the proposed = crypto suites was acceptable.  This can be

      sent in any case wher= e the offered proposals (including but not

      limited to SA payload= values, USE_TRANSPORT_MODE notify,

      IPCOMP_SUPPORTED noti= fy) are not acceptable for the responder.

"

according to the above statement it is meant that if= initiator sends a proposal with a Diffie-Hellman group value that is unacc= eptable by the responder, then responder must send a NO_PROPOSAL_CHOSEN not= ification.

 

But according to

"Section 1.2. The Initial Exchanges<= /p>

Because the initiator sends its Diffie-Hellman value= in the

   IKE_SA_INIT, it must guess the Diffie-H= ellman group that the

   responder will select from its list of = supported groups.  If the

   initiator guesses wrong, the responder = will respond with a Notify

   payload of type INVALID_KE_PAYLOAD indi= cating the selected group.

"

From the INVALID_KE_PAYLOAD description stated above= means that NO_PROPOSAL_CHOSEN case is exclusive of this INVALID_KE_PAYLOAD= .

 

Is it right interpretation of the above two error ty= pes ?

 

Thanks and Regards,

Avishek

 

--_000_f349616c76c3467a95239d459bb4fb01DM2PR0601MB713namprd06p_--