From nobody Mon Dec 1 07:41: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 C884F1A1B3C for ; Mon, 1 Dec 2014 07:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.096 X-Spam-Level: **** X-Spam-Status: No, score=4.096 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, J_CHICKENPOX_16=0.6, J_CHICKENPOX_42=0.6, 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 NygRY0Ve5fBF for ; Mon, 1 Dec 2014 07:41:43 -0800 (PST) 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 6C2BF1A3B9C for ; Mon, 1 Dec 2014 07:41:42 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id ge10so9035800lab.17 for ; Mon, 01 Dec 2014 07:41:41 -0800 (PST) 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=5N/PSMy5jUgsnxUkdCfDxOc0/FanXfny6ecJs/Wm0Aw=; b=BvFl7msddBDHjcG6fbTf/CtWbCw2brlnI3sx686Qp4tStZpVk+Ue4G+3t8P2Vq+zqO KURzGtuh+OT3xt1hANI52eAmy48AxYogEeyGmptg5hrRg21tKlDfGtaZDFLeA7ikw7Wh 50PRBlqZdLyL9Hyq4oEi2pypFdPWaLa9Rl5nJeBZBTAae5Exi6bt9vf8mDukr5veOd5A 3DYJYRBrGA4LZHUKg9wlPrRen++Zv0MF697PvbpV3duz3IHUWUIF4XCH3SK1c/+vw5ML /E/tiQqTWZ2M105mLRfWWKkikeDc+B2OtDnNYnzTdhD03qlh7l8B/3fjsw0v7Cwxj4Kt C0sg== X-Received: by 10.112.182.72 with SMTP id ec8mr56830995lbc.87.1417448500936; Mon, 01 Dec 2014 07:41:40 -0800 (PST) Received: from buildpc ([93.188.44.200]) by mx.google.com with ESMTPSA id v4sm4749966lav.25.2014.12.01.07.41.40 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 01 Dec 2014 07:41:40 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Yoav Nir" , "ipsec" References: <410D9347-2DFF-42FE-A821-A177112BED0E@gmail.com> Date: Mon, 1 Dec 2014 18:34:09 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; 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/r_mj5Wq9IfSOC6YnJoLkjJZyqLs Subject: [IPsec] Some speculations about puzzles 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 Dec 2014 15:41:45 -0000 Hi, this is a long message. First of all I think that the puzzles mechanism is a great tool to make DoS attacks harder for attackers and we should try to incorporate it into IKE. Moreover, I think that the puzzles could be used not only in IKE_SA_INIT, but also to defend against DoS attacks in IKE_AUTH exchange (see below). However, the puzzles mechanism is a controversal thing, since it requires an additional work from legitimate clients. It could be particularly troublesome for small battery-powered wireless devices (smartphones, IoT devices etc) - not only would it delay connection setup, but it also would decrease battery lifetime. So think that the puzzles mechanism if incorporated into IKE should follow some general principles: 1. Puzzles should be optional. It should be possible for client to just return cookie even if puzzle is given by SGW). 2. The ultimate decision whether to solve puzzle or ignore it should be made by client. 3. Those, who ignore puzzles (for any reason - either they are legacy clients or they decide to save battery) should still have a chance to setup connection (on "best effort" basis). In other words, let's consider puzzles mechanizm not as discriminating tool ("those who cannot solve puzzles won't be allowed in"), but as a "first-class ticket" for those, who are ready to pay for it. And the price for the first-class service should be high enough to make it unattractive for attackers. Concrete proposals. 1. Algorithm agility for puzzles. It is relatively easy to achieve. When IKE_SA_INIT request comes from the client, the server could quicly parse it, find SA payload and figure out the list of transforms the client proposes. Then it could select mutually supported PRF and indicate it to the client in response containing puzzle. The puzzle in this case would look like: "please, give me a string of octets such, that if this PRF is applied to that string of octets using supplied cookie as the key, then the result would contain this number of trailing zero bits" (another option - apply PRF to cookie + string of octets using zero key). Parsing IKE_SA_INIT message is a relatively easy task. The side advantage of this approach is that the server could quickly check the structure of the message and the list of proposed transforms and wouldn't spend more resources in case the initial message is malformed or no proposals are acceptable to the responder. 2. Cookie generation. Currently RFC7296 suggestd the following formula to compute cookie: Cookie = | Hash(Ni | IPi | SPIi | ) With puzzles more information should be present in the cookie to prevent some attacks from initiator. First, when responder asks initiator to solve the puzzle, it sets puzzle difficulty to some level and indicates it in the response message. When the solved puzzle is returned back to the responder, it must know in a stateless manner what level of difficulty it has requested. Otherwise the initiator could cheat. So responder must encode this information into cookie, as the cookie is an entity that initiator cannot forge. Then, it is desirable to also include timestamp into cookie to prevent initiator from re-using solved puzzles and from collecting a lot of puzzles, solving them and then presenting them all at once. Including timestamp allows the responder to determine how old this cookie is and, therefore, how much time it was taken from the initiator to solve the puzzle. If the results are suspicious (an easy puzzle took too long to be solved), then the request should be rejected, even in the case it contains a valid solution for the puzzle. And in case of accepting algorithm agility method described above the selected PRF must also be encoded in cookie. So, the cookie generation would look like: Cookie = | | | | Hash(Ni | IPi | SPIi | | | | ) Note, that should be allowed to be zero here - in case it is just a cookie request with no puzzle request. To summarize here is a possible sequence of messages in IKE_SA_INIT: request --> HDR, SA, KE, Ni, [N(NAT_DETECTION_SOURCE_IP)+, N(NAT_DETECTION_DESTINATION_IP),] [V+][N+] response with puzzle <-- HDR, N(COOKIE), N(PUZZLE, PRF=, DIFFICULTY=) [V+][N+] Legacy client or client that don't want to spend recources on puzzle would ignore N(PUZZLE) and act as if only N(COOKIE) was received. request --> HDR, [N(COOKIE),] SA, KE, Ni, [N(NAT_DETECTION_SOURCE_IP)+, N(NAT_DETECTION_DESTINATION_IP),] [V+][N+] At this point the responder will: - check that the cookie is valid - retrieve timestamp and difficulty level from the cookie and ensures it is fresh for that level - if the level is zero, then it means that no puzzle was requested - if the level is non-zero then it means that the initiator either doesn't support puzzles or is unwilling to solve them; in either case the request is processed on "best effort" basis - it could be served or dropped depending on current resource availability or on some probability (e.g.serve every Nth request in case of attack) Client, that is solved the puzzle: request --> HDR, [N(COOKIE),], N(PUZZLE_SOLUTION) SA, KE, Ni, [N(NAT_DETECTION_SOURCE_IP)+, N(NAT_DETECTION_DESTINATION_IP),] [V+][N+] At this point the responder will: - check that the cookie is valid - retrieve timestamp and difficulty level from the cookie and ensures it is fresh for that level - if the level is zero, then it means that no puzzle was requested, but initiator still supplied some solution; in this case N(PUZZLE_SOLUTION) is ignored and the message is processed as described above - if the level is non-zero then responder will retrieve PRF from the cookie and verify the correctness of supplied puzzle solution - if everything is OK then this request is served with higher priority 3. Using puzzles in IKE_AUTH exchange. The draft ipsecme-ddos-protection-00 describes DoS attack on IKE_AUTH exchange: Sending an Authentication request is surprisingly cheap. It requires a proper IKE header with the correct IKE SPIs, and it requires a single encrypted payload. The content of the payload might as well be junk. The responder has to perform the relatively expensive key derivation, only to find that the Authentication request does not decrypt. I think that the puzzles could be used to make this attack substantially more expensive for the attacker. The idea is to require the initiator to supply an additional string of octets in IKE_AUTH request such, that applying PRF with the Nr as the key to this string of octets concatenated with the content of the IKE_AUTH message will result in some number of zero trailing bits. In this case if the attacker fills in the content of SK payload with garbage, it will be detected by the responder without performing DH computation. The level of difficulty in this case must be set so, that the time needed to solve the puzzle is by the order of magnitude more, than to compute DH, so that this attack becomes unattractive for potential attacker. There are some options where to place puzzle solution in IKE_AUTH message. 1. It could be explicitely present as Notification payload before Encrypted payload: HDR, N(PUZZLE_SOLUTION), SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} 2. It could be placed right after Encrypted payload without any header. In this case the length indicated in IKE Header would be greater, than the length indicated in Encrypted payload header, and the solved puzzle would be placed in this gap. HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} In case of IKE fragmentation every fragment should contain its own solution for the puzzle. Note also, that puzzles in IKE_AUTH are mandatory for initiator if they are requested by responder - the request won't be processed untill the initiator provides puzzle solution (this is unlike puzzles in IKE_SA_INIT, where they should be optional). Regards, Valery Smyslov. From nobody Tue Dec 2 13:19: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 9EA221A6FC7 for ; Tue, 2 Dec 2014 13:19:45 -0800 (PST) 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 9KfS7CDDHfd4 for ; Tue, 2 Dec 2014 13:19:43 -0800 (PST) Received: from mail-wi0-x22a.google.com (mail-wi0-x22a.google.com [IPv6:2a00:1450:400c:c05::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D7CF1A1A86 for ; Tue, 2 Dec 2014 13:19:43 -0800 (PST) Received: by mail-wi0-f170.google.com with SMTP id bs8so31147038wib.3 for ; Tue, 02 Dec 2014 13:19:42 -0800 (PST) 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=O+OcDGJRFu95GdOLVmcpQyiSiE+1oPQZ/BJtoCE22k0=; b=TLMUpuTUd0Yh+stb6+5SDuSSekVZ1/FF5kNKiVP/ugBKgc48NDpti8OseHASHocl3F RJgobh/SVI9fnMcsqQwcYH+vq0e0i+8wK5mGmHqWyjpZ4KlgK7ax7Jx53vky+QFziSoR yte6/73WZE9ro0S+yZWCLBAM+mvOJvFe5ZiRmJaHl3d5ogzO/e6095zO+46r0NS4M9mS YdLO+LSfZiFbW+1WJ1yRa81agvqO9StdbFXBkS3aiBZ8vDQziVA/EZLhe6lTXnoMpAFf g7hJ3cTk0ytUBWJlRP8qOxNLX8+ToEAOSLwn4Qq4U20vBfSOzRkz2bFE2a7vWMTbbLiD whPQ== X-Received: by 10.180.126.37 with SMTP id mv5mr94326095wib.2.1417555182121; Tue, 02 Dec 2014 13:19:42 -0800 (PST) Received: from [10.0.0.9] (bzq-79-176-33-71.red.bezeqint.net. [79.176.33.71]) by mx.google.com with ESMTPSA id vy7sm33504466wjc.27.2014.12.02.13.19.41 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Dec 2014 13:19:41 -0800 (PST) Message-ID: <547E2CEB.3020200@gmail.com> Date: Tue, 02 Dec 2014 23:19:39 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Paul Hoffman , IPsecME WG References: <2CBE2213-E3B6-4E0C-95EC-D1DFB05D3A0E@vpnc.org> In-Reply-To: <2CBE2213-E3B6-4E0C-95EC-D1DFB05D3A0E@vpnc.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/3ChHQM4oYb1jVHuZSo7zQxqWjRE Subject: Re: [IPsec] Survey for WG interest in adopting draft-nagayama-ipsecme-ipsec-with-qkd 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, 02 Dec 2014 21:19:45 -0000 Here's a quick reminder to speak up if you're interested in this document and are willing to contribute as co-author or reviewer. Thanks, Yaron On 11/25/2014 10:06 PM, Paul Hoffman wrote: > > > Greetings again. There is a small emerging industry of crypto solutions that transmit keys using Quantum Key Distribution (QKD), and then use those keys for classical high-speed encryption. Several such solutions are using IKE, and there is a perceived need to standardize this usage. If so, that standardization should be done in this Working Group. > > If you agree with the need to standardize this usage, and believe that draft-nagayama-ipsecme-ipsec-with-qkd is likely to be a good starting place for that standardization, and are willing to review and contribute text to the document if it is adopted by the WG, please say so on the list. This WG has a history of adopting documents but then not having enough reviewers for us to feel confident that we are making a good standard, so we need to see a reasonable number of actively interested people before we adopt the document. If it is not adopted, the authors can ask for it to be published as an RFC through individual submission or by the Independent Submissions Editor. > > Please reply by December 8, 2015. > > --Paul Hoffman and Yaron Sheffer > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Tue Dec 2 13:20:41 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 774A01A872F for ; Tue, 2 Dec 2014 13:20:39 -0800 (PST) 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 2UvRaZ3m6Sz6 for ; Tue, 2 Dec 2014 13:20:38 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68EE71A1A86 for ; Tue, 2 Dec 2014 13:20:37 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id r20so22363679wiv.8 for ; Tue, 02 Dec 2014 13:20:35 -0800 (PST) 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=kcMbaFsuJz0tE0+UG1zpxrkuWFST2+z/g1mTmifZuBI=; b=ELl5YLmGvGAYWcVqB8nwvVVjW8KJdcKiOP1oIhupS4IeGsHr3S1HpRWOk2fOq7rxK5 vIu/mKn/XSB74Vc1wpOzVcuap+5Ozt3u0snfutc7ZqdpANHCuXY+k+FT1gZSjpaKn2NP jHU760lJls59PDMZc45LyFZegMEvChVty+7Yl0tQXxJw4yYeoTObcQEZWefaOrjXpxBF tvmYpnGDWv6n08+V2VZ//1VtzRviqQ9S0hMk/KqSaazOZ/4ufeF0C998oawKKXVAUxcq GUQ8jT+CR0SOM5dJ3N0MzWhMWYLrsZj1cI7lKcedkfUw3TejRtP9pxQCaDqWHbw/u6s9 ITyA== X-Received: by 10.180.218.39 with SMTP id pd7mr8334446wic.21.1417555235044; Tue, 02 Dec 2014 13:20:35 -0800 (PST) Received: from [10.0.0.9] (bzq-79-176-33-71.red.bezeqint.net. [79.176.33.71]) by mx.google.com with ESMTPSA id wv8sm33356355wjc.44.2014.12.02.13.20.34 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 02 Dec 2014 13:20:34 -0800 (PST) Message-ID: <547E2D21.2070600@gmail.com> Date: Tue, 02 Dec 2014 23:20:33 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Paul Hoffman , IPsecME WG References: In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/VxmCIW2Y4k6ztDlV8RIQ0kisMqA Subject: Re: [IPsec] Survey for WG interest in adopting draft-mglt-ipsecme-clone-ike-sa 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, 02 Dec 2014 21:20:39 -0000 And similarly for this draft: please speak up if you're interested in this document and are willing to contribute as co-author or reviewer. Thanks, Yaron On 11/25/2014 10:06 PM, Paul Hoffman wrote: > > > Greetings again. The "Clone IKE SA" proposal tries to optimize IKE SA setup in cases where VPN gateways have multiple interfaces and want to establish different SAs on the different interfaces without having to repeat the IKE authentication. Instead, they could clone a single IKE SA multiple times, and then move it to different interfaces using MOBIKE. > > If you agree with the need to standardize this usage, and believe that draft-mglt-ipsecme-clone-ike-sa is likely to be a good starting place for that standardization, and are willing to review and contribute text to the document if it is adopted by the WG, please say so on the list. This WG has a history of adopting documents but then not having enough reviewers for us to feel confident that we are making a good standard, so we need to see a reasonable number of actively interested people before we adopt the document. If it is not adopted, the authors can ask for it to be published as an RFC through individual submission or by the Independent Submissions Editor. > > Please reply by December 8, 2015. > > --Paul Hoffman and Yaron Sheffer > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Tue Dec 2 14:50: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 9EF9C1A1B21 for ; Tue, 2 Dec 2014 14:50:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.592 X-Spam-Level: * X-Spam-Status: No, score=1.592 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 EGjYYHagjN2F for ; Tue, 2 Dec 2014 14:50:04 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5A9B1A1AB8 for ; Tue, 2 Dec 2014 14:50:04 -0800 (PST) Received: from [192.168.0.2] (cpe-066-057-017-031.nc.res.rr.com [66.57.17.31]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 1F6E5278164; Wed, 3 Dec 2014 07:50:01 +0900 (JST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Rodney Van Meter In-Reply-To: <547E2CEB.3020200@gmail.com> Date: Tue, 2 Dec 2014 17:49:58 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <2CBE2213-E3B6-4E0C-95EC-D1DFB05D3A0E@vpnc.org> <547E2CEB.3020200@gmail.com> To: Yaron Sheffer X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/WVvBq8hKUKA1tp15BUYawsRbQ3I Cc: Rodney Van Meter , IPsecME WG , Paul Hoffman Subject: Re: [IPsec] Survey for WG interest in adopting draft-nagayama-ipsecme-ipsec-with-qkd 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, 02 Dec 2014 22:50:09 -0000 Hi, Sorry to be a little slow to reply. I was offline over Thanksgiving, = just saw the messages yesterday afternoon. Of course I favor adoption, and am willing to work with anyone who can = contribute to the development of an appropriate protocol. Momentum = seems to be toward a version supporting a variety of out-of-band = mechanisms, and I=E2=80=99m willing to work in that direction. Shota is looking in to the numerous issues I detailed in the long = message right after IETF. =E2=80=94Rod > On Dec 2, 2014, at 4:19 PM, Yaron Sheffer = wrote: >=20 > Here's a quick reminder to speak up if you're interested in this = document and are willing to contribute as co-author or reviewer. >=20 > Thanks, > Yaron >=20 > On 11/25/2014 10:06 PM, Paul Hoffman wrote: >> >>=20 >> Greetings again. There is a small emerging industry of crypto = solutions that transmit keys using Quantum Key Distribution (QKD), and = then use those keys for classical high-speed encryption. Several such = solutions are using IKE, and there is a perceived need to standardize = this usage. If so, that standardization should be done in this Working = Group. >>=20 >> If you agree with the need to standardize this usage, and believe = that draft-nagayama-ipsecme-ipsec-with-qkd is likely to be a good = starting place for that standardization, and are willing to review and = contribute text to the document if it is adopted by the WG, please say = so on the list. This WG has a history of adopting documents but then not = having enough reviewers for us to feel confident that we are making a = good standard, so we need to see a reasonable number of actively = interested people before we adopt the document. If it is not adopted, = the authors can ask for it to be published as an RFC through individual = submission or by the Independent Submissions Editor. >>=20 >> Please reply by December 8, 2015. >>=20 >> --Paul Hoffman and Yaron Sheffer >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >>=20 >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Dec 2 15:20: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 0E33F1A6FDB for ; Tue, 2 Dec 2014 15:20:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.311 X-Spam-Level: X-Spam-Status: No, score=-13.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_16=0.6, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 bc2qHcNMVtzU for ; Tue, 2 Dec 2014 15:20:35 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2CED41A2130 for ; Tue, 2 Dec 2014 15:20:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15194; q=dns/txt; s=iport; t=1417562435; x=1418772035; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=sVwRtkv1sPwZXjl7GeOaoEd/OIYVQyclTY5VY0r3zEI=; b=DORTRpaJClsdsCyuFdmnGwNX436YhjpWZ5q1Wktd19Yx6wN6afq5Lqr4 39TeNkAuaZg83bGN3BTb0h0zyHBwvf+ALpnkl37RyitbKIxYh5xoeH5eQ YVvA2tZqXE9q8F5doa5XluSLt38FgqsNED/2ahaH7VbWgv199uXSRShRW U=; X-Files: smime.p7s : 3708 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMFADtIflStJA2D/2dsb2JhbABbgmQjUlkExG2CHAqGHwKBGRYBAQEBAX2EAwEBBAEBASRHGwIBCA44Ah8GCyUCBAESDg2IEAMSAQzQJA2FewEBAQEBAQEBAgEBAQEBAQEBARUEimCDWIFPIQIaECICAoREBZBhgg6BS4MbgjKBf4EsgziHYIIYhkWCBB6BWW+BBiQcgQEBAQE X-IronPort-AV: E=Sophos;i="5.07,503,1413244800"; d="p7s'?scan'208";a="377096906" Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-4.cisco.com with ESMTP; 02 Dec 2014 23:20:34 +0000 Received: from xhc-aln-x05.cisco.com (xhc-aln-x05.cisco.com [173.36.12.79]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sB2NKYdx000703 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 2 Dec 2014 23:20:34 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x05.cisco.com ([173.36.12.79]) with mapi id 14.03.0195.001; Tue, 2 Dec 2014 17:20:33 -0600 From: "Graham Bartlett (grbartle)" To: Valery Smyslov , Yoav Nir , ipsec Thread-Topic: [IPsec] Some speculations about puzzles Thread-Index: AQHQDX1WXMPTLhaXMUeLlbXm0oFemJx9Vr0A Date: Tue, 2 Dec 2014 23:20:33 +0000 Message-ID: References: <410D9347-2DFF-42FE-A821-A177112BED0E@gmail.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [10.61.83.250] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3500407232_12742482" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/j2-bNlxZ0Fd3mXG9XNxudiewBgk Subject: Re: [IPsec] Some speculations about puzzles 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, 02 Dec 2014 23:20:38 -0000 --B_3500407232_12742482 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Valery Would the Timestamp be generated every time cycle? If this wasn't a static figure (per timecycle - maybe when the secret is changed?, but rather a rolling unix time), then how would the Responder be able to validate this Cookie (without trying every previous timestamp or having the timestamp included in the Initiators reply?). Would it not be better to save X number of Secrets and just try them instead (assuming that the Secret is changing fairly regularly)? The Secret could also be used to tell (approx) how old the Cookie is. I like the two options of the header in the clear. Many thanks On 01/12/2014 15:34, "Valery Smyslov" wrote: >Hi, this is a long message. > >First of all I think that the puzzles mechanism is a great tool >to make DoS attacks harder for attackers and we should >try to incorporate it into IKE. Moreover, I think that >the puzzles could be used not only in IKE_SA_INIT, but also >to defend against DoS attacks in IKE_AUTH exchange (see below). >However, the puzzles mechanism is a controversal thing, >since it requires an additional work from legitimate clients. >It could be particularly troublesome for small battery-powered wireless >devices (smartphones, IoT devices etc) - not only would it delay >connection >setup, but it also would decrease battery lifetime. > >So think that the puzzles mechanism if incorporated into IKE should follow >some general principles: >1. Puzzles should be optional. It should be possible for client to just >return > cookie even if puzzle is given by SGW). >2. The ultimate decision whether to solve puzzle or ignore it should be >made >by client. >3. Those, who ignore puzzles (for any reason - either they are legacy >clients > or they decide to save battery) should still have a chance to setup >connection > (on "best effort" basis). > >In other words, let's consider puzzles mechanizm not as discriminating >tool >("those who cannot solve puzzles won't be allowed in"), but as >a "first-class ticket" for those, who are ready to pay for it. >And the price for the first-class service should be high enough to make it >unattractive for attackers. > > >Concrete proposals. > >1. Algorithm agility for puzzles. It is relatively easy to achieve. When >IKE_SA_INIT request comes from the client, the server could quicly parse >it, >find SA payload and figure out the list of transforms the client proposes. >Then it could select mutually supported PRF and indicate it to the client >in response containing puzzle. The puzzle in this case would look like: >"please, give me a string of octets such, that if this PRF is applied >to that string of octets using supplied cookie as the key, then the >result would contain this number of trailing zero bits" (another option - >apply PRF to cookie + string of octets using zero key). > >Parsing IKE_SA_INIT message is a relatively easy task. >The side advantage of this approach is that the server >could quickly check the structure of the message and >the list of proposed transforms and wouldn't spend more resources >in case the initial message is malformed or no proposals are acceptable >to the responder. > >2. Cookie generation. Currently RFC7296 suggestd the following >formula to compute cookie: > > Cookie = | Hash(Ni | IPi | SPIi | ) > >With puzzles more information should be present in the cookie >to prevent some attacks from initiator. First, when >responder asks initiator to solve the puzzle, it sets puzzle >difficulty to some level and indicates it in the response message. >When the solved puzzle is returned back to the responder, >it must know in a stateless manner what level of difficulty >it has requested. Otherwise the initiator could cheat. So responder >must encode this information into cookie, as the cookie is an entity that >initiator cannot forge. Then, it is desirable to also include >timestamp into cookie to prevent initiator from re-using solved puzzles >and from collecting a lot of puzzles, solving them and then presenting >them >all at once. Including timestamp allows the responder >to determine how old this cookie is and, therefore, >how much time it was taken from the initiator to solve the puzzle. >If the results are suspicious (an easy puzzle took too long to be solved), >then the request should be rejected, even in the case it contains >a valid solution for the puzzle. And in case of accepting >algorithm agility method described above the selected PRF >must also be encoded in cookie. > >So, the cookie generation would look like: > > Cookie = | | | > >| > Hash(Ni | IPi | SPIi | | | | >) > >Note, that should be allowed to be zero here - >in case it is just a cookie request with no puzzle request. > >To summarize here is a possible sequence of messages in IKE_SA_INIT: > > request --> HDR, SA, KE, Ni, > [N(NAT_DETECTION_SOURCE_IP)+, > N(NAT_DETECTION_DESTINATION_IP),] > [V+][N+] > > response with puzzle <-- HDR, N(COOKIE), N(PUZZLE, PRF=, >DIFFICULTY=) > [V+][N+] > >Legacy client or client that don't want to spend recources on puzzle >would ignore N(PUZZLE) and act as if only N(COOKIE) was received. > > request --> HDR, [N(COOKIE),] > SA, KE, Ni, > [N(NAT_DETECTION_SOURCE_IP)+, > N(NAT_DETECTION_DESTINATION_IP),] > [V+][N+] > >At this point the responder will: >- check that the cookie is valid >- retrieve timestamp and difficulty level from the cookie and ensures it >is > fresh for that level >- if the level is zero, then it means that no puzzle was requested >- if the level is non-zero then it means that the initiator either > doesn't support puzzles or is unwilling to solve them; in either > case the request is processed on "best effort" basis - > it could be served or dropped depending on current resource availability > or on some probability (e.g.serve every Nth request in case of attack) > >Client, that is solved the puzzle: > > request --> HDR, [N(COOKIE),], N(PUZZLE_SOLUTION) > SA, KE, Ni, > [N(NAT_DETECTION_SOURCE_IP)+, > N(NAT_DETECTION_DESTINATION_IP),] > [V+][N+] > > >At this point the responder will: >- check that the cookie is valid >- retrieve timestamp and difficulty level from the cookie and ensures it >is > fresh for that level >- if the level is zero, then it means that no puzzle was requested, > but initiator still supplied some solution; in this case >N(PUZZLE_SOLUTION) > is ignored and the message is processed as described above >- if the level is non-zero then responder will retrieve PRF from the >cookie > and verify the correctness of supplied puzzle solution >- if everything is OK then this request is served with higher priority > > >3. Using puzzles in IKE_AUTH exchange. The draft >ipsecme-ddos-protection-00 >describes DoS attack on IKE_AUTH exchange: > > Sending an Authentication request is surprisingly cheap. It >requires > a proper IKE header with the correct IKE SPIs, and it requires a > single encrypted payload. The content of the payload might as well > be junk. The responder has to perform the relatively expensive key > derivation, only to find that the Authentication request does not >decrypt. > >I think that the puzzles could be used to make this attack substantially >more expensive for the attacker. The idea is to require the initiator >to supply an additional string of octets in IKE_AUTH request such, that >applying PRF with the Nr as the key to this string of octets >concatenated with the content of the IKE_AUTH message will >result in some number of zero trailing bits. In this case if the attacker >fills in the content of SK payload with garbage, it will be detected >by the responder without performing DH computation. The level of >difficulty >in this case must be set so, that the time needed to solve the puzzle is >by the order of magnitude more, than to compute DH, so that >this attack becomes unattractive for potential attacker. > >There are some options where to place puzzle solution >in IKE_AUTH message. > > 1. It could be explicitely present as Notification payload > before Encrypted payload: > > HDR, N(PUZZLE_SOLUTION), SK {IDi, [CERT,] [CERTREQ,] > [IDr,] AUTH, SAi2, TSi, TSr} > > 2. It could be placed right after Encrypted payload without > any header. In this case the length indicated in IKE Header > would be greater, than the length indicated in Encrypted payload > header, and the solved puzzle would be placed in this gap. > > HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} >puzzle> > >In case of IKE fragmentation every fragment should contain >its own solution for the puzzle. Note also, that puzzles in IKE_AUTH >are mandatory for initiator if they are requested by responder - >the request won't be processed untill the initiator provides >puzzle solution (this is unlike puzzles in IKE_SA_INIT, where >they should be optional). > > >Regards, >Valery Smyslov. > >_______________________________________________ >IPsec mailing list >IPsec@ietf.org >https://www.ietf.org/mailman/listinfo/ipsec --B_3500407232_12742482 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIOeAYJKoZIhvcNAQcCoIIOaTCCDmUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgggw+MIIEpzCCA4+gAwIBAgIQZmBP5MZi1b5ckUheWh5wbTANBgkqhkiG9w0BAQUFADBU MQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xv YmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMB4XDTE0MDEyNTIyNDE0OFoXDTE2MDYw MzExMDA1OFowQDEbMBkGA1UEAwwSZ3JiYXJ0bGVAY2lzY28uY29tMSEwHwYJKoZIhvcNAQkB FhJncmJhcnRsZUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCq YhYxolKrFoPfXuZTQdAiQVFg14EvWwIEMyXxhfH2RiwOSJRSsUVmTNYG8HdeSf0JdzjAMh9p ODgxLC90Q1nbLyBqmEAKElWTasAnATKBCD7aLhce+25cznTT4FDpJsvvU2lZFPWXSLQm3bNR +mEDP6pd8zR1ItOKBlNmGtwypUUvi4KrKRPzx1cSgVTN0Xocj4fC5N8Rj3tOqOns+EHOX4Rw oy/rebHjQyv1cRr6FyGhRuz24hPv8mAGr/iF0cMphAsujaGKyAo+tA05K3nI0fdoeCx2wdEs vo8jIeeZVii07b3K9+VdJQmerVKJyMfQT6gLkyuassY/5aXlglNxAgMBAAGjggGHMIIBgzAO BgNVHQ8BAf8EBAMCBaAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYm aHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wHQYDVR0RBBYwFIESZ3Ji YXJ0bGVAY2lzY28uY29tMAkGA1UdEwQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3MvZ3Nw ZXJzb25hbHNpZ24xZzIuY3JsMFUGCCsGAQUFBwEBBEkwRzBFBggrBgEFBQcwAoY5aHR0cDov L3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NwZXJzb25hbHNpZ24xZzIuY3J0MB0G A1UdDgQWBBRBHvZ1Aur9AFGMEId10iH6yeUX3jAfBgNVHSMEGDAWgBTsrJjMJ3KTz1YyzSPH nY1FhfQiAzANBgkqhkiG9w0BAQUFAAOCAQEAdhq5YZv5ZCu0/HdQF1S3f+quesVc39HKv+Fe 2rmKuJcxfGOFZGpKhJDa1+sFeN/T+e2e6UJ0Yy90GLqi5U1fioD3XRhsFiVOh7CbJQESF2Xx U1bhdutZFh6Ythe28iRPY6HQjJ/7ke5IQBWvLnAbCIzgy0GgZB9Vj+a2z6bzmfR6KAuLaMqM vahvJ0w+DeHMEOVnVzCdZzHMaEOXZHw/uZj5/hGvkp2C0rH/LhGunfAPX12WhVQSsgxWJhaF 8D49Ymrt7PWBsLokx06/15XwY2ogBmfLmeN/WhMy5HUiLn3EnzwF+RK2MStCDpP5AWzdnrTR tM43+AJrHwoI7H+C9DCCBBYwggL+oAMCAQICCwQAAAAAAS9O4SzhMA0GCSqGSIb3DQEBBQUA MFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdS b290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcN MTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1z YTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8aUcr5BvPNGjx0+LH0uRqeZCHrYQ7KN3QuahfxY8 fAzAbnvNDzGdEMyKn3+YX+k/QbAGNJOSFRxrAfhviF7WGcqDlin3HracDqMRgwrknWuFeqxh N2J7uXs3Y0zluJEkEittRXv+ZdXOG/Gp3gtoz5P9noc5jBbfWQpQBhcaJA2ucABbUVTHDTxi 7dBY8mTWq6kRAkGWBybHwq0YX+jaHudtQw0oBEmxjpJFP9qIXu0ckU/+OhtnAhrgzrsd4oAy qgc6u4dBYERcjDJFohihjbzPozgKDSSbdr44uO3p9Bg6ibjCxn2besLrIE7upoxvV09Fsf7h DeD/jcvs64z8pQIDAQABo4HlMIHiMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/ AgEAMB0GA1UdDgQWBBTsrJjMJ3KTz1YyzSPHnY1FhfQiAzBHBgNVHSAEQDA+MDwGBFUdIAAw NDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8w MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDAf BgNVHSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAr7un yEtmt9Ia7hmNpqP+xMd0t5hLM0QBY8G3Dlg70XI6F+ZeSZeeXgCtUT/JhdQ+HsJ8+c6HypDu vg/OZ0gILDFIa9LDfRWm+tHIgxKaJjtCy0izg838dLwwnt/O3kA9N/htEYev2lsmWYCV9cVU m5V1tW3XuYNg6SbtcDRH+Ki1RED9es3R0BgHSm012KPxsiAOOxuhm1D3Iqs1qe6ms5WTKXVg wb/j/kplOa13nshhc8zULVO+oAlD4+7czNK2RJiTvhJiDJDRTZy3DJ3BCQ8rXOGdWzDEI5ui B8TZ0s327g44Ylc6dgKgYelNn9RLYjNETX8OIJZlr0tFYpcYrDCCA3UwggJdoAMCAQICCwQA AAAAARVLWsOUMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i YWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJv b3QgQ0EwHhcNOTgwOTAxMTIwMDAwWhcNMjgwMTI4MTIwMDAwWjBXMQswCQYDVQQGEwJCRTEZ MBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMS R2xvYmFsU2lnbiBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2g7m mY3Oo+NPin778YuDJWvqSB/xKrC5lREEvfBj0eJnZs8c3c8bSCvujYmOmq8pgGWr6cctEsur HExwB6E9CjDNFY1P+N3UjFAVHO9Q7sQu9/zpUvKRfeBt1TUwjl5Dc/JB6dVq47KJOlY5OG8G PIhpWypNxadUuGyJzJv5PMrl/Yn1EjySeJbW3HRuk0Rh0Y3HRrJ1DoboGYrVbWzVeBaVounI Cjjr8iQTT3NUkxOFOhu8HjS1iwWMuXeLsdsfIJGrCVNukM57N3S5cEeRIlFjFnmusa5BJgjI GSvRRqpI1mQq14M0/ywqwWwZQ0oHhefTfPYhaO/q8lKff5OQzwIDAQABo0IwQDAOBgNVHQ8B Af8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUYHtmGkUNl8qJUC99BM00qP/8 /UswDQYJKoZIhvcNAQEFBQADggEBANZz53xPdtCNv+y6or40xSgytXz8bJwsK70JnlO/a16q EUi25Qijs8o9YU3TRgmzPsOg42NVG/K676054UO5OKPmL4omO++gUFb5xgr9OM3EC3BRlJeY BN/DX5TVFckUQZzEXXVkFQ3/VTDsho//De8suWNG9qr837xp/S4SSGSa4JXwpu8pjwGxFbUM HaX+aSxpJHges6cccWLuysiXrBddisL4R4ZuKsRWMZXQZ4mFK/lspl1GnQyqguSZUd1wt9tW PWHkauFc1vb+Pd5BzAeuY1K/U1P0K+nH/bb3gl+F0kEY24GzBBzFH6SAbxUgyd4MiAod1mZV 4vxIySkmaeAxggH+MIIB+gIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAxIENBIC0gRzIC EGZgT+TGYtW+XJFIXloecG0wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgFKpp QxCGMFK43kr6J2XlMFTYcJ1jPlh3c8lBOAi77bUwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTQxMjAyMjMyMDMyWjANBgkqhkiG9w0BAQEFAASCAQCqIcAp J95nJrJ9saEGqtm5EP7wlVwdNKkMnDJm+AoEt9ziFpFF0nxyJm00ad239pPm0W1u+mYHE1u9 dVg51oJkLQmXSd093pENb1CFk1bWR/T8rbyaThLb3bCXZg97HM6WOFyBu+PuxJ0pLyTQx6qp 9r3QHoYLHRDsqxHP2hINcwASOCFep9tSrN9w4+gNN6FVCU/QpfmjMcp1mTMePM+6wajUQrA3 YxMkelGB3VGF0iE3t5GpVwXVmZHNGcDCLmC5ok8B4kt5ViVqKaYIKf5Pl3CjrzhDpMi4fAjr 4gLkFPZfgFgFPxXPWEfk4CeNH1NaPLCFXjrIrYANLHmcArm3 --B_3500407232_12742482-- From nobody Wed Dec 3 04:09:53 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 EEE5C1A1A82 for ; Wed, 3 Dec 2014 04:09:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 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, J_CHICKENPOX_16=0.6, J_CHICKENPOX_42=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 WZlfr-8Nq0Pn for ; Wed, 3 Dec 2014 04:09:44 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCD3E1A0461 for ; Wed, 3 Dec 2014 04:09:43 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id k14so19603652wgh.37 for ; Wed, 03 Dec 2014 04:09:42 -0800 (PST) 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=+hoP+wRHJcD+QCxpk3DudyGBEOJf2pnos0yPulBeQiA=; b=SiBQVMD23EjeofMM0M5dospBSlXuZajlWRRBapwuECOuc77qsLVB9dNVX9Axcu3i3X Om9+djRARqjuLcy65uGJCU4nrgmb2QWEfbiRiyQdH++b5n7FXQ5HBe80GgI/sUCseU56 WlCuRgT0TG0gc5aFLwm6071QePYr49XHj8IwZ9y3U/qyYyryo4nJ9m4moWlN5mh5ChM3 Q8pFPqHjmriYuCNM8YyS1KZc2eWVfbFgmcDXCiZhZj+6zxX0nfJoRSbU+S44G1C423BV dy5TDd9jh04I0NRUn6CgUO0UhEL3uT4ECGDKYG0HpKq+nqaj2Rz/QTQ+qefbUXNvGlo9 ZT2w== X-Received: by 10.194.20.98 with SMTP id m2mr7025831wje.52.1417608582517; Wed, 03 Dec 2014 04:09:42 -0800 (PST) Received: from [192.168.0.10] ([41.212.114.217]) by mx.google.com with ESMTPSA id nb8sm79390wic.7.2014.12.03.04.09.39 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 04:09:41 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Les Leposo In-Reply-To: Date: Wed, 3 Dec 2014 15:09:35 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: <881AE47D-154A-4922-8429-0829493E26B0@gmail.com> References: To: ipsec@ietf.org X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/cpn1CA17CIIWN54mtm2M150D-zg Subject: Re: [IPsec] Survey for WG interest in adopting draft-mglt-ipsecme-clone-ike-sa (Yaron Sheffer) 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, 03 Dec 2014 12:09:48 -0000 Hi All, there probably are gateways that currently perform =E2=80=98faux-cloning = IKE-SAs=E2=80=99 (e.g. through data replication tricks) - if so, they = would only have an opportunity to do so upon receiving favourable = UPDATE_SA_ADDRESSES notifications. I=E2=80=99m not sure if clients do = this sort of thing. So, I support this draft because it could help standardise how = =E2=80=98low-cal=E2=80=99 clients & distributed servers hand-over = tunnels. It can also be used to improve handovers, but, it potentially = introduces some security risks. This draft is like __builtin_prefetch - it can be great if used = effectively, otherwise it could get a little worse. A few issues: 1) when is the =E2=80=98CLONE_IKE_SA=E2=80=99 notification exactly sent = - perhaps some examples (e.g. uplink route comes up)? 2) please consider good integration with =E2=80=98Session Resumption=E2=80= =99. particularly as a =E2=80=98low-cal=E2=80=99 extension to section = 4.3.3, someone alluded to this earlier. 3) please consider consistency with the =E2=80=98ADDITIONAL_IP*_ADDRESS = list, someone alluded to this earlier. 4) perhaps, a (configurable) maximum lifetime for the series of cloned = IKE_SAs? 5) What should be done for extraneous =E2=80=98CLONE_IKE_SA=E2=80=99 = notifications? > On Dec 3, 2014, at 2:20 AM, ipsec-request@ietf.org wrote: >=20 > 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: Survey for WG interest in adopting > draft-nagayama-ipsecme-ipsec-with-qkd (Yaron Sheffer) > 2. Re: Survey for WG interest in adopting > draft-mglt-ipsecme-clone-ike-sa (Yaron Sheffer) > 3. Re: Survey for WG interest in adopting > draft-nagayama-ipsecme-ipsec-with-qkd (Rodney Van Meter) > 4. Re: Some speculations about puzzles (Graham Bartlett (grbartle)) >=20 >=20 > ---------------------------------------------------------------------- >=20 > Message: 1 > Date: Tue, 02 Dec 2014 23:19:39 +0200 > From: Yaron Sheffer > To: Paul Hoffman , IPsecME WG > Subject: Re: [IPsec] Survey for WG interest in adopting > draft-nagayama-ipsecme-ipsec-with-qkd > Message-ID: <547E2CEB.3020200@gmail.com> > Content-Type: text/plain; charset=3Dutf-8; format=3Dflowed >=20 > Here's a quick reminder to speak up if you're interested in this=20 > document and are willing to contribute as co-author or reviewer. >=20 > Thanks, > Yaron >=20 > On 11/25/2014 10:06 PM, Paul Hoffman wrote: >> >>=20 >> Greetings again. There is a small emerging industry of crypto = solutions that transmit keys using Quantum Key Distribution (QKD), and = then use those keys for classical high-speed encryption. Several such = solutions are using IKE, and there is a perceived need to standardize = this usage. If so, that standardization should be done in this Working = Group. >>=20 >> If you agree with the need to standardize this usage, and believe = that draft-nagayama-ipsecme-ipsec-with-qkd is likely to be a good = starting place for that standardization, and are willing to review and = contribute text to the document if it is adopted by the WG, please say = so on the list. This WG has a history of adopting documents but then not = having enough reviewers for us to feel confident that we are making a = good standard, so we need to see a reasonable number of actively = interested people before we adopt the document. If it is not adopted, = the authors can ask for it to be published as an RFC through individual = submission or by the Independent Submissions Editor. >>=20 >> Please reply by December 8, 2015. >>=20 >> --Paul Hoffman and Yaron Sheffer >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >>=20 >=20 >=20 >=20 > ------------------------------ >=20 > Message: 2 > Date: Tue, 02 Dec 2014 23:20:33 +0200 > From: Yaron Sheffer > To: Paul Hoffman , IPsecME WG > Subject: Re: [IPsec] Survey for WG interest in adopting > draft-mglt-ipsecme-clone-ike-sa > Message-ID: <547E2D21.2070600@gmail.com> > Content-Type: text/plain; charset=3Dutf-8; format=3Dflowed >=20 > And similarly for this draft: please speak up if you're interested in=20= > this document and are willing to contribute as co-author or reviewer. >=20 > Thanks, > Yaron >=20 > On 11/25/2014 10:06 PM, Paul Hoffman wrote: >> >>=20 >> Greetings again. The "Clone IKE SA" proposal tries to optimize IKE SA = setup in cases where VPN gateways have multiple interfaces and want to = establish different SAs on the different interfaces without having to = repeat the IKE authentication. Instead, they could clone a single IKE SA = multiple times, and then move it to different interfaces using MOBIKE. >>=20 >> If you agree with the need to standardize this usage, and believe = that draft-mglt-ipsecme-clone-ike-sa is likely to be a good starting = place for that standardization, and are willing to review and contribute = text to the document if it is adopted by the WG, please say so on the = list. This WG has a history of adopting documents but then not having = enough reviewers for us to feel confident that we are making a good = standard, so we need to see a reasonable number of actively interested = people before we adopt the document. If it is not adopted, the authors = can ask for it to be published as an RFC through individual submission = or by the Independent Submissions Editor. >>=20 >> Please reply by December 8, 2015. >>=20 >> --Paul Hoffman and Yaron Sheffer >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >>=20 >=20 >=20 >=20 > ------------------------------ >=20 > Message: 3 > Date: Tue, 2 Dec 2014 17:49:58 -0500 > From: Rodney Van Meter > To: Yaron Sheffer > Cc: Rodney Van Meter , IPsecME WG > , Paul Hoffman > Subject: Re: [IPsec] Survey for WG interest in adopting > draft-nagayama-ipsecme-ipsec-with-qkd > Message-ID: > Content-Type: text/plain; charset=3Dutf-8 >=20 > Hi, >=20 > Sorry to be a little slow to reply. I was offline over Thanksgiving, = just saw the messages yesterday afternoon. >=20 > Of course I favor adoption, and am willing to work with anyone who can = contribute to the development of an appropriate protocol. Momentum = seems to be toward a version supporting a variety of out-of-band = mechanisms, and I?m willing to work in that direction. >=20 > Shota is looking in to the numerous issues I detailed in the long = message right after IETF. >=20 > ?Rod >=20 >> On Dec 2, 2014, at 4:19 PM, Yaron Sheffer = wrote: >>=20 >> Here's a quick reminder to speak up if you're interested in this = document and are willing to contribute as co-author or reviewer. >>=20 >> Thanks, >> Yaron >>=20 >> On 11/25/2014 10:06 PM, Paul Hoffman wrote: >>> >>>=20 >>> Greetings again. There is a small emerging industry of crypto = solutions that transmit keys using Quantum Key Distribution (QKD), and = then use those keys for classical high-speed encryption. Several such = solutions are using IKE, and there is a perceived need to standardize = this usage. If so, that standardization should be done in this Working = Group. >>>=20 >>> If you agree with the need to standardize this usage, and believe = that draft-nagayama-ipsecme-ipsec-with-qkd is likely to be a good = starting place for that standardization, and are willing to review and = contribute text to the document if it is adopted by the WG, please say = so on the list. This WG has a history of adopting documents but then not = having enough reviewers for us to feel confident that we are making a = good standard, so we need to see a reasonable number of actively = interested people before we adopt the document. If it is not adopted, = the authors can ask for it to be published as an RFC through individual = submission or by the Independent Submissions Editor. >>>=20 >>> Please reply by December 8, 2015. >>>=20 >>> --Paul Hoffman and Yaron Sheffer >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>>=20 >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >=20 >=20 >=20 > ------------------------------ >=20 > Message: 4 > Date: Tue, 2 Dec 2014 23:20:33 +0000 > From: "Graham Bartlett (grbartle)" > To: Valery Smyslov , Yoav Nir , > ipsec > Subject: Re: [IPsec] Some speculations about puzzles > Message-ID: > Content-Type: text/plain; charset=3D"us-ascii" >=20 > Hi Valery >=20 > Would the Timestamp be generated every time cycle? If this wasn't a = static > figure (per timecycle - maybe when the secret is changed?, but rather = a > rolling unix time), then how would the Responder be able to validate = this > Cookie (without trying every previous timestamp or having the = timestamp > included in the Initiators reply?). Would it not be better to save X > number of Secrets and just try them instead (assuming that the Secret = is > changing fairly regularly)? The Secret could also be used to tell = (approx) > how old the Cookie is. >=20 >=20 > I like the two options of the header in the clear. >=20 >=20 > Many thanks >=20 > On 01/12/2014 15:34, "Valery Smyslov" wrote: >=20 >> Hi, this is a long message. >>=20 >> First of all I think that the puzzles mechanism is a great tool >> to make DoS attacks harder for attackers and we should >> try to incorporate it into IKE. Moreover, I think that >> the puzzles could be used not only in IKE_SA_INIT, but also >> to defend against DoS attacks in IKE_AUTH exchange (see below). >> However, the puzzles mechanism is a controversal thing, >> since it requires an additional work from legitimate clients. >> It could be particularly troublesome for small battery-powered = wireless >> devices (smartphones, IoT devices etc) - not only would it delay >> connection >> setup, but it also would decrease battery lifetime. >>=20 >> So think that the puzzles mechanism if incorporated into IKE should = follow >> some general principles: >> 1. Puzzles should be optional. It should be possible for client to = just >> return >> cookie even if puzzle is given by SGW). >> 2. The ultimate decision whether to solve puzzle or ignore it should = be >> made=20 >> by client. >> 3. Those, who ignore puzzles (for any reason - either they are legacy >> clients >> or they decide to save battery) should still have a chance to setup >> connection >> (on "best effort" basis). >>=20 >> In other words, let's consider puzzles mechanizm not as = discriminating >> tool >> ("those who cannot solve puzzles won't be allowed in"), but as >> a "first-class ticket" for those, who are ready to pay for it. >> And the price for the first-class service should be high enough to = make it >> unattractive for attackers. >>=20 >>=20 >> Concrete proposals. >>=20 >> 1. Algorithm agility for puzzles. It is relatively easy to achieve. = When >> IKE_SA_INIT request comes from the client, the server could quicly = parse >> it, >> find SA payload and figure out the list of transforms the client = proposes. >> Then it could select mutually supported PRF and indicate it to the = client >> in response containing puzzle. The puzzle in this case would look = like: >> "please, give me a string of octets such, that if this PRF is applied >> to that string of octets using supplied cookie as the key, then the >> result would contain this number of trailing zero bits" (another = option - >> apply PRF to cookie + string of octets using zero key). >>=20 >> Parsing IKE_SA_INIT message is a relatively easy task. >> The side advantage of this approach is that the server >> could quickly check the structure of the message and >> the list of proposed transforms and wouldn't spend more resources >> in case the initial message is malformed or no proposals are = acceptable >> to the responder. >>=20 >> 2. Cookie generation. Currently RFC7296 suggestd the following >> formula to compute cookie: >>=20 >> Cookie =3D | Hash(Ni | IPi | SPIi | ) >>=20 >> With puzzles more information should be present in the cookie >> to prevent some attacks from initiator. First, when >> responder asks initiator to solve the puzzle, it sets puzzle >> difficulty to some level and indicates it in the response message. >> When the solved puzzle is returned back to the responder, >> it must know in a stateless manner what level of difficulty >> it has requested. Otherwise the initiator could cheat. So responder >> must encode this information into cookie, as the cookie is an entity = that >> initiator cannot forge. Then, it is desirable to also include >> timestamp into cookie to prevent initiator from re-using solved = puzzles >> and from collecting a lot of puzzles, solving them and then = presenting >> them >> all at once. Including timestamp allows the responder >> to determine how old this cookie is and, therefore, >> how much time it was taken from the initiator to solve the puzzle. >> If the results are suspicious (an easy puzzle took too long to be = solved), >> then the request should be rejected, even in the case it contains >> a valid solution for the puzzle. And in case of accepting >> algorithm agility method described above the selected PRF >> must also be encoded in cookie. >>=20 >> So, the cookie generation would look like: >>=20 >> Cookie =3D | | | >> =20 >> | >> Hash(Ni | IPi | SPIi | | | = | >> ) >>=20 >> Note, that should be allowed to be zero here - >> in case it is just a cookie request with no puzzle request. >>=20 >> To summarize here is a possible sequence of messages in IKE_SA_INIT: >>=20 >> request --> HDR, SA, KE, Ni, >> [N(NAT_DETECTION_SOURCE_IP)+, >> N(NAT_DETECTION_DESTINATION_IP),] >> [V+][N+] >>=20 >> response with puzzle <-- HDR, N(COOKIE), N(PUZZLE, PRF=3D, >> DIFFICULTY=3D) >> [V+][N+] >>=20 >> Legacy client or client that don't want to spend recources on puzzle >> would ignore N(PUZZLE) and act as if only N(COOKIE) was received. >>=20 >> request --> HDR, [N(COOKIE),] >> SA, KE, Ni, >> [N(NAT_DETECTION_SOURCE_IP)+, >> N(NAT_DETECTION_DESTINATION_IP),] >> [V+][N+] >>=20 >> At this point the responder will: >> - check that the cookie is valid >> - retrieve timestamp and difficulty level from the cookie and ensures = it >> is >> fresh for that level >> - if the level is zero, then it means that no puzzle was requested >> - if the level is non-zero then it means that the initiator either >> doesn't support puzzles or is unwilling to solve them; in either >> case the request is processed on "best effort" basis - >> it could be served or dropped depending on current resource = availability >> or on some probability (e.g.serve every Nth request in case of = attack) >>=20 >> Client, that is solved the puzzle: >>=20 >> request --> HDR, [N(COOKIE),], N(PUZZLE_SOLUTION) >> SA, KE, Ni, >> [N(NAT_DETECTION_SOURCE_IP)+, >> N(NAT_DETECTION_DESTINATION_IP),] >> [V+][N+] >>=20 >>=20 >> At this point the responder will: >> - check that the cookie is valid >> - retrieve timestamp and difficulty level from the cookie and ensures = it >> is >> fresh for that level >> - if the level is zero, then it means that no puzzle was requested, >> but initiator still supplied some solution; in this case >> N(PUZZLE_SOLUTION) >> is ignored and the message is processed as described above >> - if the level is non-zero then responder will retrieve PRF from the >> cookie >> and verify the correctness of supplied puzzle solution >> - if everything is OK then this request is served with higher = priority >>=20 >>=20 >> 3. Using puzzles in IKE_AUTH exchange. The draft >> ipsecme-ddos-protection-00 >> describes DoS attack on IKE_AUTH exchange: >>=20 >> Sending an Authentication request is surprisingly cheap. It >> requires >> a proper IKE header with the correct IKE SPIs, and it requires a >> single encrypted payload. The content of the payload might as = well >> be junk. The responder has to perform the relatively expensive = key >> derivation, only to find that the Authentication request does = not >> decrypt. >>=20 >> I think that the puzzles could be used to make this attack = substantially >> more expensive for the attacker. The idea is to require the initiator >> to supply an additional string of octets in IKE_AUTH request such, = that >> applying PRF with the Nr as the key to this string of octets >> concatenated with the content of the IKE_AUTH message will >> result in some number of zero trailing bits. In this case if the = attacker >> fills in the content of SK payload with garbage, it will be detected >> by the responder without performing DH computation. The level of >> difficulty >> in this case must be set so, that the time needed to solve the puzzle = is >> by the order of magnitude more, than to compute DH, so that >> this attack becomes unattractive for potential attacker. >>=20 >> There are some options where to place puzzle solution >> in IKE_AUTH message. >>=20 >> 1. It could be explicitely present as Notification payload >> before Encrypted payload: >>=20 >> HDR, N(PUZZLE_SOLUTION), SK {IDi, [CERT,] [CERTREQ,] >> [IDr,] AUTH, SAi2, TSi, TSr} >>=20 >> 2. It could be placed right after Encrypted payload without >> any header. In this case the length indicated in IKE Header >> would be greater, than the length indicated in Encrypted payload >> header, and the solved puzzle would be placed in this gap. >>=20 >> HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} >> > puzzle> >>=20 >> In case of IKE fragmentation every fragment should contain >> its own solution for the puzzle. Note also, that puzzles in IKE_AUTH >> are mandatory for initiator if they are requested by responder - >> the request won't be processed untill the initiator provides >> puzzle solution (this is unlike puzzles in IKE_SA_INIT, where >> they should be optional). >>=20 >>=20 >> Regards, >> Valery Smyslov.=20 >>=20 >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: smime.p7s > Type: application/pkcs7-signature > Size: 3708 bytes > Desc: not available > 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 128, Issue 2 > ************************************* From nobody Wed Dec 3 04:36: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 326AA1A1A93 for ; Wed, 3 Dec 2014 04:36:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.409 X-Spam-Level: X-Spam-Status: No, score=0.409 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, J_CHICKENPOX_16=0.6, J_CHICKENPOX_42=0.6, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 L-gbGm1zV3Qv for ; Wed, 3 Dec 2014 04:36:05 -0800 (PST) Received: from mail-lb0-x235.google.com (mail-lb0-x235.google.com [IPv6:2a00:1450:4010:c04::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 465091A1A27 for ; Wed, 3 Dec 2014 04:36:05 -0800 (PST) Received: by mail-lb0-f181.google.com with SMTP id l4so2686696lbv.26 for ; Wed, 03 Dec 2014 04:36:03 -0800 (PST) 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=zNiiC7ujA+W5QVMKnrqVmkt7IXxTjgi1z7LRRNmcOBQ=; b=XUuYPj8pB52efKMZOOcS9nfG6Aj7frKo/RIEJK7LQKAJ8nh0H7zFjRfD48eTPN8x4i mDOwZb/QNq4ll7sRapPeXbRtyX7/1eXct9KNy/p37PlzWW7wuxjHNE07GwrD8M3JsZaw lKXFM5/FFCuRnJyA/L6aY2mY0mGCT+I8dS1SbBBLRitwFmbToo2/gQUuXktB/ySNWxr7 SHgpeak/BS1RDGpvbUQbJWQo9CjnkSK55dxBmyKWJn4RqtEFjM0BIpYPTW7rrhF33eYt zVyTvM8RReRRjOYDIqz0Gd4XhUEVgpSVWNXqUP2E5TFRh8RuEQkuOkXQefDnyr550yKU GO2w== X-Received: by 10.112.131.1 with SMTP id oi1mr4115581lbb.2.1417610163674; Wed, 03 Dec 2014 04:36:03 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id mn4sm6422528lbb.4.2014.12.03.04.36.02 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 03 Dec 2014 04:36:03 -0800 (PST) Message-ID: <34CC278854404D2EB46355F3579111D2@buildpc> From: "Valery Smyslov" To: "Graham Bartlett \(grbartle\)" , "Yoav Nir" , "ipsec" References: <410D9347-2DFF-42FE-A821-A177112BED0E@gmail.com> Date: Wed, 3 Dec 2014 15:36:02 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1251"; 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/I90ib0WZMgxdSMFphuc51lmPJG0 Subject: Re: [IPsec] Some speculations about puzzles 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, 03 Dec 2014 12:36:14 -0000 Hi Graham, > Would the Timestamp be generated every time cycle? If this wasn't a static > figure (per timecycle - maybe when the secret is changed?, but rather a > rolling unix time), then how would the Responder be able to validate this > Cookie (without trying every previous timestamp or having the timestamp > included in the Initiators reply?). Yes, it is included in Initiator's reply. More precisely - it is encoded in cookie. So, the cookie has some structure. The particular encoding is implementation dependant (since it is a local responder's matter), but the idea is that the cookie contains some fields, that responder can extract from it and these fields are also included in Hash(Ni | IPi | SPIi | ... ) calculation to prevent attacker from manipulating them. For example: 1. First byte of cookie contains VersionIDofSecret 2. Next byte contains requested PuzzleDifficulty 3. Next 2 bytes contain transform ID for selected PRF 4. Next 4 bytes contain timestamp (just unix time()) 5. The rest of the cookie contains hash of all these values + Ni + IPi + SPIi + > Would it not be better to save X > number of Secrets and just try them instead (assuming that the Secret is > changing fairly regularly)? The Secret could also be used to tell (approx) > how old the Cookie is. Using the fact that the secret for cookie generation must be changed periodically is another option to deal with old puzzles. However, the secret is global and the period of its changes is relatively long (tens of seconds or even minutes). It is desirable to have finer mechanism to deal with different puzzle difficulty levels for different IP-addresses/prefixes. Of course it is possible to change secret every second, but then we should make the long enough to prevent wrapping and it is desirable that it survives reboots and so on, so it just becomes a timestamp :-) Regards, Valery. > I like the two options of the header in the clear. > > > Many thanks > > On 01/12/2014 15:34, "Valery Smyslov" wrote: > >>Hi, this is a long message. >> >>First of all I think that the puzzles mechanism is a great tool >>to make DoS attacks harder for attackers and we should >>try to incorporate it into IKE. Moreover, I think that >>the puzzles could be used not only in IKE_SA_INIT, but also >>to defend against DoS attacks in IKE_AUTH exchange (see below). >>However, the puzzles mechanism is a controversal thing, >>since it requires an additional work from legitimate clients. >>It could be particularly troublesome for small battery-powered wireless >>devices (smartphones, IoT devices etc) - not only would it delay >>connection >>setup, but it also would decrease battery lifetime. >> >>So think that the puzzles mechanism if incorporated into IKE should follow >>some general principles: >>1. Puzzles should be optional. It should be possible for client to just >>return >> cookie even if puzzle is given by SGW). >>2. The ultimate decision whether to solve puzzle or ignore it should be >>made >>by client. >>3. Those, who ignore puzzles (for any reason - either they are legacy >>clients >> or they decide to save battery) should still have a chance to setup >>connection >> (on "best effort" basis). >> >>In other words, let's consider puzzles mechanizm not as discriminating >>tool >>("those who cannot solve puzzles won't be allowed in"), but as >>a "first-class ticket" for those, who are ready to pay for it. >>And the price for the first-class service should be high enough to make it >>unattractive for attackers. >> >> >>Concrete proposals. >> >>1. Algorithm agility for puzzles. It is relatively easy to achieve. When >>IKE_SA_INIT request comes from the client, the server could quicly parse >>it, >>find SA payload and figure out the list of transforms the client proposes. >>Then it could select mutually supported PRF and indicate it to the client >>in response containing puzzle. The puzzle in this case would look like: >>"please, give me a string of octets such, that if this PRF is applied >>to that string of octets using supplied cookie as the key, then the >>result would contain this number of trailing zero bits" (another option - >>apply PRF to cookie + string of octets using zero key). >> >>Parsing IKE_SA_INIT message is a relatively easy task. >>The side advantage of this approach is that the server >>could quickly check the structure of the message and >>the list of proposed transforms and wouldn't spend more resources >>in case the initial message is malformed or no proposals are acceptable >>to the responder. >> >>2. Cookie generation. Currently RFC7296 suggestd the following >>formula to compute cookie: >> >> Cookie = | Hash(Ni | IPi | SPIi | ) >> >>With puzzles more information should be present in the cookie >>to prevent some attacks from initiator. First, when >>responder asks initiator to solve the puzzle, it sets puzzle >>difficulty to some level and indicates it in the response message. >>When the solved puzzle is returned back to the responder, >>it must know in a stateless manner what level of difficulty >>it has requested. Otherwise the initiator could cheat. So responder >>must encode this information into cookie, as the cookie is an entity that >>initiator cannot forge. Then, it is desirable to also include >>timestamp into cookie to prevent initiator from re-using solved puzzles >>and from collecting a lot of puzzles, solving them and then presenting >>them >>all at once. Including timestamp allows the responder >>to determine how old this cookie is and, therefore, >>how much time it was taken from the initiator to solve the puzzle. >>If the results are suspicious (an easy puzzle took too long to be solved), >>then the request should be rejected, even in the case it contains >>a valid solution for the puzzle. And in case of accepting >>algorithm agility method described above the selected PRF >>must also be encoded in cookie. >> >>So, the cookie generation would look like: >> >> Cookie = | | | >> >>| >> Hash(Ni | IPi | SPIi | | | | >>) >> >>Note, that should be allowed to be zero here - >>in case it is just a cookie request with no puzzle request. >> >>To summarize here is a possible sequence of messages in IKE_SA_INIT: >> >> request --> HDR, SA, KE, Ni, >> [N(NAT_DETECTION_SOURCE_IP)+, >> N(NAT_DETECTION_DESTINATION_IP),] >> [V+][N+] >> >> response with puzzle <-- HDR, N(COOKIE), N(PUZZLE, PRF=, >>DIFFICULTY=) >> [V+][N+] >> >>Legacy client or client that don't want to spend recources on puzzle >>would ignore N(PUZZLE) and act as if only N(COOKIE) was received. >> >> request --> HDR, [N(COOKIE),] >> SA, KE, Ni, >> [N(NAT_DETECTION_SOURCE_IP)+, >> N(NAT_DETECTION_DESTINATION_IP),] >> [V+][N+] >> >>At this point the responder will: >>- check that the cookie is valid >>- retrieve timestamp and difficulty level from the cookie and ensures it >>is >> fresh for that level >>- if the level is zero, then it means that no puzzle was requested >>- if the level is non-zero then it means that the initiator either >> doesn't support puzzles or is unwilling to solve them; in either >> case the request is processed on "best effort" basis - >> it could be served or dropped depending on current resource availability >> or on some probability (e.g.serve every Nth request in case of attack) >> >>Client, that is solved the puzzle: >> >> request --> HDR, [N(COOKIE),], N(PUZZLE_SOLUTION) >> SA, KE, Ni, >> [N(NAT_DETECTION_SOURCE_IP)+, >> N(NAT_DETECTION_DESTINATION_IP),] >> [V+][N+] >> >> >>At this point the responder will: >>- check that the cookie is valid >>- retrieve timestamp and difficulty level from the cookie and ensures it >>is >> fresh for that level >>- if the level is zero, then it means that no puzzle was requested, >> but initiator still supplied some solution; in this case >>N(PUZZLE_SOLUTION) >> is ignored and the message is processed as described above >>- if the level is non-zero then responder will retrieve PRF from the >>cookie >> and verify the correctness of supplied puzzle solution >>- if everything is OK then this request is served with higher priority >> >> >>3. Using puzzles in IKE_AUTH exchange. The draft >>ipsecme-ddos-protection-00 >>describes DoS attack on IKE_AUTH exchange: >> >> Sending an Authentication request is surprisingly cheap. It >>requires >> a proper IKE header with the correct IKE SPIs, and it requires a >> single encrypted payload. The content of the payload might as well >> be junk. The responder has to perform the relatively expensive key >> derivation, only to find that the Authentication request does not >>decrypt. >> >>I think that the puzzles could be used to make this attack substantially >>more expensive for the attacker. The idea is to require the initiator >>to supply an additional string of octets in IKE_AUTH request such, that >>applying PRF with the Nr as the key to this string of octets >>concatenated with the content of the IKE_AUTH message will >>result in some number of zero trailing bits. In this case if the attacker >>fills in the content of SK payload with garbage, it will be detected >>by the responder without performing DH computation. The level of >>difficulty >>in this case must be set so, that the time needed to solve the puzzle is >>by the order of magnitude more, than to compute DH, so that >>this attack becomes unattractive for potential attacker. >> >>There are some options where to place puzzle solution >>in IKE_AUTH message. >> >> 1. It could be explicitely present as Notification payload >> before Encrypted payload: >> >> HDR, N(PUZZLE_SOLUTION), SK {IDi, [CERT,] [CERTREQ,] >> [IDr,] AUTH, SAi2, TSi, TSr} >> >> 2. It could be placed right after Encrypted payload without >> any header. In this case the length indicated in IKE Header >> would be greater, than the length indicated in Encrypted payload >> header, and the solved puzzle would be placed in this gap. >> >> HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} >>>puzzle> >> >>In case of IKE fragmentation every fragment should contain >>its own solution for the puzzle. Note also, that puzzles in IKE_AUTH >>are mandatory for initiator if they are requested by responder - >>the request won't be processed untill the initiator provides >>puzzle solution (this is unlike puzzles in IKE_SA_INIT, where >>they should be optional). >> >> >>Regards, >>Valery Smyslov. >> >>_______________________________________________ >>IPsec mailing list >>IPsec@ietf.org >>https://www.ietf.org/mailman/listinfo/ipsec > From nobody Wed Dec 3 07:06:22 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 6677F1A1B6F for ; Wed, 3 Dec 2014 07:06:18 -0800 (PST) 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 XL5Zgy_uR9Dg for ; Wed, 3 Dec 2014 07:06:16 -0800 (PST) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AE881A1B56 for ; Wed, 3 Dec 2014 07:06:16 -0800 (PST) Received: by mail-wi0-f169.google.com with SMTP id r20so33476482wiv.0 for ; Wed, 03 Dec 2014 07:06:15 -0800 (PST) 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=sJuRh21yUcEZ+nPJXrByFIbGACLD322hY3wD+zUpaC4=; b=z3lvi8AlsJM6GzwZPTJh34A1ZyRlTkJAHFNN/IHIhAMZy4TM93ZOBgCVmcwnIoVLIo 4iDucU5yEuYkSFj5mqAdlia0iePrtKXGWIAo7rXJVYDIUOqbIriRSH3Ptd77zcyJfukH YYndtadzs/Pjsp4mOJTqJLyv6Vhg++Fakpig/F1QtLzq2HD4ZrsTCCZJFyF553BK5ASH KMIOXKn14k1nLQs6c2QVCTq9jLoM3Q7atizBqpx2R+dt62044X031AtRKg37xl6GlT7U FsYJYrYHfMY2QoA2C7fk45Q9Zf6W5IPZePlFF8eVZgxuVmQ39gITPB+fouiVQmoTCT+K 3zVQ== X-Received: by 10.180.103.162 with SMTP id fx2mr9004936wib.42.1417619171214; Wed, 03 Dec 2014 07:06:11 -0800 (PST) Received: from [172.24.251.68] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id gs9sm36631255wjc.47.2014.12.03.07.06.09 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 07:06:10 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=utf-8 From: Yoav Nir X-Priority: 3 In-Reply-To: <34CC278854404D2EB46355F3579111D2@buildpc> Date: Wed, 3 Dec 2014 17:06:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <410D9347-2DFF-42FE-A821-A177112BED0E@gmail.com> <34CC278854404D2EB46355F3579111D2@buildpc> To: Valery Smyslov X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/P6Mlo9bAqu29DcMSZ-6Mz3pB6ds Cc: ipsec , "Graham Bartlett \(grbartle\)" Subject: Re: [IPsec] Some speculations about puzzles 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, 03 Dec 2014 15:06:19 -0000 I think it=E2=80=99s simpler to keep a short list (a queue actually, but = usually with no more than 2-5 entries) or = pairs. Generate a new pair every 10 seconds or whenever the difficulty level = needs to change. Remember all entries for the last 20 seconds. Calculate = the cookie as described in the RFC. When receiving a cookie, you try to validate it using all the remembered = secret-difficulty pairs (I guess you check for sufficiently many zeros = before you check for the hash), and let them in if one such pair = validated. Yoav From nobody Wed Dec 3 07:36:40 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 C47301A1B79 for ; Wed, 3 Dec 2014 07:36:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.791 X-Spam-Level: X-Spam-Status: No, score=-0.791 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, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 xa-rCDMO0ceI for ; Wed, 3 Dec 2014 07:36:36 -0800 (PST) Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FD561A1B3E for ; Wed, 3 Dec 2014 07:36:35 -0800 (PST) Received: by mail-lb0-f174.google.com with SMTP id w7so12439512lbi.19 for ; Wed, 03 Dec 2014 07:36:34 -0800 (PST) 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=PnlKLo18x8CHnwEGeC5lbPXuUdVO6X8VQeqSxgUZtj4=; b=uB9AhOnvBqS0jWm1Ip+4i10wD7xglcTB8Zyt+YjmEMtDo1nwjnRTtr2HOA8IQ/pBhI ZdnQy3/YcXpGY0qLiofB5Ag4dIDebBuAYfkQZmiLCqOqkQi6Ys96rarVnOclxjo83cNC IZ+Blm+SXJnoEvjT+9j2IbgU69C5WfBoUSJINAlN0YMwl3SLv1luhgRM4wEuS8nEumlU kvxrpwi59+l0vJ/50AnL0VPdFtSu3+kjS6wwDKwFXetwQnsFKbtrLpTKalvH7XLGwR4R mDQQfd2oKL57AacHf6Xjf+kZwXoAZRYO36cPXBkcKkNUUPMiToO69DIfzzEoSLoFb2pj iqmw== X-Received: by 10.152.42.169 with SMTP id p9mr2840651lal.94.1417620994197; Wed, 03 Dec 2014 07:36:34 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id a9sm6464458lae.29.2014.12.03.07.36.33 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 03 Dec 2014 07:36:33 -0800 (PST) Message-ID: <5013824D2C6B44EA8D96BAB5B966D947@buildpc> From: "Valery Smyslov" To: "Yoav Nir" References: <410D9347-2DFF-42FE-A821-A177112BED0E@gmail.com> <34CC278854404D2EB46355F3579111D2@buildpc> Date: Wed, 3 Dec 2014 18:36:34 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit 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/7c1GXlBavjmrpPuOs05XzFzNHuw Cc: ipsec , "Graham Bartlett \(grbartle\)" Subject: Re: [IPsec] Some speculations about puzzles 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, 03 Dec 2014 15:36:36 -0000 It is probably a bit simpler, but less efficient. With this try-and-catch approach you would need to perform hash (or PRF) computations several times before rejecting invalid puzzles. I'm in favor to minimize wasting of resourses for solution, which primary goal is to defend against DoS attack. ----- Original Message ----- From: "Yoav Nir" To: "Valery Smyslov" Cc: "Graham Bartlett (grbartle)" ; "ipsec" Sent: Wednesday, December 03, 2014 6:06 PM Subject: Re: [IPsec] Some speculations about puzzles I think it’s simpler to keep a short list (a queue actually, but usually with no more than 2-5 entries) or pairs. Generate a new pair every 10 seconds or whenever the difficulty level needs to change. Remember all entries for the last 20 seconds. Calculate the cookie as described in the RFC. When receiving a cookie, you try to validate it using all the remembered secret-difficulty pairs (I guess you check for sufficiently many zeros before you check for the hash), and let them in if one such pair validated. Yoav From nobody Wed Dec 3 07:38:50 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 4A3C81A1B71 for ; Wed, 3 Dec 2014 07:38:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 prJC7gstSrP8 for ; Wed, 3 Dec 2014 07:38:44 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B932B1A1B3E for ; Wed, 3 Dec 2014 07:38:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1488; q=dns/txt; s=iport; t=1417621124; x=1418830724; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=diDOcIaVE69Q+Dwg/0oK6bHL3g0pZEnIE8LViu1KwS4=; b=WVnroMhPafPc9DSF3dkl/oHovAgShmP6pIn+sQTteUkDF8Z6SsJSTzsq AF2hh2Y0b3dvx5TZC5ciiH+EBsWkpbySeQ8oyubXDG1E4EMz8rw83oGTd 7PEfe9lCY8m9Y9JFzF4YsgkANz0TTZvF1qe1U6zcLM3l8Yrk5LtPrqiay o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApkIAGgBf1StJA2L/2dsb2JhbABagwaBKgSDAcU/AYQbAhx5FgEBAQEBfYQCAQEBBCMRRQwEAgEIDgMEAQEDAgYdAwICAjAUAQgIAgQBDQUIiDa/LZZfAQEBAQEBAQEBAQEBAQEBAQEBAQEBF4ErjwoWGwcGgmszgR4BBJAPnmCCAh6BWG+BBSQcgQABAQE X-IronPort-AV: E=Sophos;i="5.07,508,1413244800"; d="scan'208";a="102306508" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-5.cisco.com with ESMTP; 03 Dec 2014 15:38:43 +0000 Received: from xhc-rcd-x15.cisco.com (xhc-rcd-x15.cisco.com [173.37.183.89]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id sB3Fchjl009202 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Dec 2014 15:38:43 GMT Received: from xmb-rcd-x04.cisco.com ([169.254.8.11]) by xhc-rcd-x15.cisco.com ([173.37.183.89]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 09:38:43 -0600 From: "Scott Fluhrer (sfluhrer)" To: Yoav Nir , Valery Smyslov Thread-Topic: [IPsec] Some speculations about puzzles Thread-Index: AQHQDX1WbAhntBjV60qiTRTLi2hVz5x9Vr6AgAB5x1SAAI5qAP//o9XQ Date: Wed, 3 Dec 2014 15:38:42 +0000 Message-ID: References: <410D9347-2DFF-42FE-A821-A177112BED0E@gmail.com> <34CC278854404D2EB46355F3579111D2@buildpc> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.24.165.21] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/hz4wpWKMDTUNt8f6Evtj5DiCucM Cc: ipsec , "Graham Bartlett \(grbartle\)" Subject: Re: [IPsec] Some speculations about puzzles 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, 03 Dec 2014 15:38:46 -0000 DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSVBzZWMgW21haWx0bzpp cHNlYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgWW9hdiBOaXINCj4gU2VudDogV2Vk bmVzZGF5LCBEZWNlbWJlciAwMywgMjAxNCAxMDowNiBBTQ0KPiBUbzogVmFsZXJ5IFNteXNsb3YN Cj4gQ2M6IGlwc2VjOyBHcmFoYW0gQmFydGxldHQgKGdyYmFydGxlKQ0KPiBTdWJqZWN0OiBSZTog W0lQc2VjXSBTb21lIHNwZWN1bGF0aW9ucyBhYm91dCBwdXp6bGVzDQo+IA0KPiBJIHRoaW5rIGl0 4oCZcyBzaW1wbGVyIHRvIGtlZXAgYSBzaG9ydCBsaXN0IChhIHF1ZXVlIGFjdHVhbGx5LCBidXQg dXN1YWxseSB3aXRoIG5vDQo+IG1vcmUgdGhhbiAyLTUgZW50cmllcykgb3IgPGRpZmZpY3VsdHkt bGV2ZWwgOyBzZWNyZXQ+IHBhaXJzLg0KPiANCj4gR2VuZXJhdGUgYSBuZXcgcGFpciBldmVyeSAx MCBzZWNvbmRzIG9yIHdoZW5ldmVyIHRoZSBkaWZmaWN1bHR5IGxldmVsIG5lZWRzDQo+IHRvIGNo YW5nZS4gUmVtZW1iZXIgYWxsIGVudHJpZXMgZm9yIHRoZSBsYXN0IDIwIHNlY29uZHMuIENhbGN1 bGF0ZSB0aGUgY29va2llDQo+IGFzIGRlc2NyaWJlZCBpbiB0aGUgUkZDLg0KPiANCj4gV2hlbiBy ZWNlaXZpbmcgYSBjb29raWUsIHlvdSB0cnkgdG8gdmFsaWRhdGUgaXQgdXNpbmcgYWxsIHRoZSBy ZW1lbWJlcmVkDQo+IHNlY3JldC1kaWZmaWN1bHR5IHBhaXJzIChJIGd1ZXNzIHlvdSBjaGVjayBm b3Igc3VmZmljaWVudGx5IG1hbnkgemVyb3MgYmVmb3JlDQo+IHlvdSBjaGVjayBmb3IgdGhlIGhh c2gpLCBhbmQgbGV0IHRoZW0gaW4gaWYgb25lIHN1Y2ggcGFpciB2YWxpZGF0ZWQuDQoNCllvdSBj YW4gZG8gaXQgZWFzaWVyIHRoYW4gdGhhdDsgZW5jb2RlIGEgJ3B1enpsZSBpZCcgd2l0aGluIHRo ZSBwdXp6bGUgeW91IHNlbmQgdG8gdGhlIGNsaWVudCAoYW5kIHdoaWNoIHRoZXkgbXVzdCBzZW5k IGJhY2spOyB0aGF0IHdheSwgeW91IGNhbiBsb29rIHVwIHRoZSBwdXp6bGUgeW91IG9yaWdpbmFs bHkgYXNrZWQsIGFuZCBjaGVjayB0aGUgYW5zd2VyIG9ubHkgYWdhaW5zdCB0aGF0IG9uZS4NCg0K DQo= From nobody Wed Dec 3 07:45:01 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 317BC1A1B3E for ; Wed, 3 Dec 2014 07:45:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.108 X-Spam-Level: * X-Spam-Status: No, score=1.108 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 zqiCTE6vj4c1 for ; Wed, 3 Dec 2014 07:44:59 -0800 (PST) Received: from mail-la0-x22a.google.com (mail-la0-x22a.google.com [IPv6:2a00:1450:4010:c03::22a]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB3941A1B56 for ; Wed, 3 Dec 2014 07:44:58 -0800 (PST) Received: by mail-la0-f42.google.com with SMTP id s18so12815259lam.29 for ; Wed, 03 Dec 2014 07:44:57 -0800 (PST) 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=Wlajne9ikTEybCQaRK2lfZjAmDi0zAQ6+CrK/deRUtQ=; b=gnwiivBDpCG9QnijU19a6PQ5/zawiXg8scNWl7yCFEDRRf/jz+iIF7tQ0dgKfttSZH ao1rwGWQoins+7a6GtrGErv4ZqR09MPBN2U+ObvbSZrJy1PHkA9hbcfKet7vT/ldPGRh rkBP2A4MvGKnJj15AZET1tT6us4Ffv6k+UZL9oaUukW2Jl1TQrC8J/aNf2OopiGEuMau 394+NIffl4VupIU1CNLmRjC8SPCbWCtPA4L2vejp18ZDlqg5WBE+wKvCjDHZPS5iX43V Xxa3J2u9iTYPQ7LS0ueGWUrdskJCKZlF2mGpG9FEaG5yS7Al1IjR6HPTrSc6+W+/Y5Y1 ZFug== X-Received: by 10.152.28.131 with SMTP id b3mr5119111lah.12.1417621497262; Wed, 03 Dec 2014 07:44:57 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id px7sm6472941lac.17.2014.12.03.07.44.56 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 03 Dec 2014 07:44:56 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Scott Fluhrer \(sfluhrer\)" , "Yoav Nir" References: <410D9347-2DFF-42FE-A821-A177112BED0E@gmail.com> <34CC278854404D2EB46355F3579111D2@buildpc> Date: Wed, 3 Dec 2014 18:44:56 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit 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/xCBj6socOVCmJSL9WhLr_h3j6e0 Cc: ipsec , "Graham Bartlett \(grbartle\)" Subject: Re: [IPsec] Some speculations about puzzles 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, 03 Dec 2014 15:45:00 -0000 Hi Scott, this is almost identical to what I proposed in my original e-mail, if you substitute "difficulty level" with "puzzle id". In more generic way - responder encodes in cookie/puzzle all the information that could help him quickly reject invalid/stale/forged puzzles without wasting resources. Valery. >> I think it’s simpler to keep a short list (a queue actually, but usually >> with no >> more than 2-5 entries) or pairs. >> >> Generate a new pair every 10 seconds or whenever the difficulty level >> needs >> to change. Remember all entries for the last 20 seconds. Calculate the >> cookie >> as described in the RFC. >> >> When receiving a cookie, you try to validate it using all the remembered >> secret-difficulty pairs (I guess you check for sufficiently many zeros >> before >> you check for the hash), and let them in if one such pair validated. > > You can do it easier than that; encode a 'puzzle id' within the puzzle you > send to the client (and which they must send back); that way, you can look > up the puzzle you originally asked, and check the answer only against that > one. > > > From nobody Wed Dec 3 08:02: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 B2E761A1B86 for ; Wed, 3 Dec 2014 08:02:22 -0800 (PST) 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 unLX8HoNtwgt for ; Wed, 3 Dec 2014 08:02:18 -0800 (PST) Received: from mail-wg0-x232.google.com (mail-wg0-x232.google.com [IPv6:2a00:1450:400c:c00::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73E191A6EF8 for ; Wed, 3 Dec 2014 08:01:13 -0800 (PST) Received: by mail-wg0-f50.google.com with SMTP id k14so20057144wgh.23 for ; Wed, 03 Dec 2014 08:01:12 -0800 (PST) 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=294uBrxIxqUcA1TnASeC/jNPnTisjoKfS59LDTDVm+A=; b=TU86uCimrlOTq1905rAgC6KrcoeknIAtrnhekfR1xe5qASQ+ltcyFZLih4j7DEhe7N X6HY221yBfkAUp4OMu8sbjsRikzY6OOPvNncUZ8WpxzR8mxtVNAPi910aMZOsooybqJd 5UsNhHz6HfAYZ8Iln44rqHghSXzN+ehICVsNKxhfRaa2ktz3p/jEcilOV+bA/69hJN7x Uobqu0cBjGTrC26/IqI0YjQszxC3MJdPawHQsKIbOjFp0w9+AtkPncu6e95/UrreHjlc MaRtflUUQKRKOpQbRRJi36tU4Sf516sR0FQjbmQ0GNYUIPwWUPXldMqDagAlh4vBv7U9 12nQ== X-Received: by 10.194.235.193 with SMTP id uo1mr8127792wjc.105.1417622472226; Wed, 03 Dec 2014 08:01:12 -0800 (PST) Received: from [172.24.251.68] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id ef1sm3631977wic.0.2014.12.03.08.01.11 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 08:01:11 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=utf-8 From: Yoav Nir X-Priority: 3 In-Reply-To: Date: Wed, 3 Dec 2014 18:01:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <295C7FAB-4206-4EB2-B98D-0867BBE61E31@gmail.com> References: <410D9347-2DFF-42FE-A821-A177112BED0E@gmail.com> <34CC278854404D2EB46355F3579111D2@buildpc> To: Valery Smyslov X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/JmuSsZ8UOwfg7u7U36FRz1Dz1Uk Cc: ipsec , "Graham Bartlett \(grbartle\)" , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] Some speculations about puzzles 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, 03 Dec 2014 16:02:22 -0000 > On Dec 3, 2014, at 5:44 PM, Valery Smyslov wrote: >=20 > Hi Scott, >=20 > this is almost identical to what I proposed in my original e-mail, > if you substitute "difficulty level" with "puzzle id=E2=80=9D. Or call it =E2=80=9Cgeneration id=E2=80=9D, and increment it whenever = you generate a new secret and/or change the difficulty level.= From nobody Wed Dec 3 15:08:00 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 964B61A1EFC for ; Wed, 3 Dec 2014 15:07:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 7trxzWC8MJLW for ; Wed, 3 Dec 2014 15:07:55 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D9BA1A1B06 for ; Wed, 3 Dec 2014 15:07:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6242; q=dns/txt; s=iport; t=1417648076; x=1418857676; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=XjHOAX2K37ktpW0DM30wSKJfPCVNkZVWZOXRyj5zaUc=; b=eokSWz5FcTElyKnBQZ8hORF7/ifaR8ja+0I7p6rAGC6jb4hOXlNy5+zX s4tiU1s2zIn7OtCtWjRT3LAaop0LKYdjySF86etgYj8HiMwJwaWc8QyXB tGOyyrX2IdYy+o27wxxI/Cd0/zWdSzWp4G9Fq1cCR1DLS4coTnt+Q8Uhk I=; X-Files: smime.p7s : 3708 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8FAOyWf1StJV2d/2dsb2JhbABagmQigSoExCKIPQKBFhYBAQEBAX2EAgEBAQMBeRACAQgOCi4CHxElAgQBDQUOiBsDCQkB0RcNhV4BAQEBAQEBAQEBAQEBAQEBAQEBAQEXjjCCGxsHhEIFiiGFboF2gUCFIoFyjXmGHYN4b4FFgQABAQE X-IronPort-AV: E=Sophos;i="5.07,510,1413244800"; d="p7s'?scan'208";a="377361596" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-3.cisco.com with ESMTP; 03 Dec 2014 23:07:55 +0000 Received: from xhc-rcd-x02.cisco.com (xhc-rcd-x02.cisco.com [173.37.183.76]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id sB3N7sSR028036 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 3 Dec 2014 23:07:54 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-rcd-x02.cisco.com ([173.37.183.76]) with mapi id 14.03.0195.001; Wed, 3 Dec 2014 17:07:54 -0600 From: "Graham Bartlett (grbartle)" To: Yoav Nir , Valery Smyslov Thread-Topic: [IPsec] Some speculations about puzzles Thread-Index: AQHQDX1WXMPTLhaXMUeLlbXm0oFemJx9Vr0AgAB5tbeAAI59AIAACRoA//+dOJmAAGkNgIAAdziA Date: Wed, 3 Dec 2014 23:07:53 +0000 Message-ID: References: <410D9347-2DFF-42FE-A821-A177112BED0E@gmail.com> <34CC278854404D2EB46355F3579111D2@buildpc> <295C7FAB-4206-4EB2-B98D-0867BBE61E31@gmail.com> In-Reply-To: <295C7FAB-4206-4EB2-B98D-0867BBE61E31@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [10.55.146.100] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3500492871_13943843" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/aAS5hXcwt4OdUXNAVOX0h3NCuvI Cc: ipsec , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] Some speculations about puzzles 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, 03 Dec 2014 23:07:57 -0000 --B_3500492871_13943843 Content-type: text/plain; charset="ISO-8859-1" Content-transfer-encoding: quoted-printable If the 1 byte 'difficulty level' has become the 'puzzle id', could we break the 1 byte into two 4 bits? 1st 4 bits is 'puzzle/generation id', next 4bits is 'difficulty level', this allows for 16 cycles for when every secret changes and still allows 16 levels of puzzles.. (just a thought as if the difficulty level disappears you loose the ability to set a the hardness of the puzzle) On 03/12/2014 16:01, "Yoav Nir" wrote: > >> On Dec 3, 2014, at 5:44 PM, Valery Smyslov wrote: >>=20 >> Hi Scott, >>=20 >> this is almost identical to what I proposed in my original e-mail, >> if you substitute "difficulty level" with "puzzle id=B2. > >Or call it =B3generation id=B2, and increment it whenever you generate a new >secret and/or change the difficulty level. --B_3500492871_13943843 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIOeAYJKoZIhvcNAQcCoIIOaTCCDmUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgggw+MIIEpzCCA4+gAwIBAgIQZmBP5MZi1b5ckUheWh5wbTANBgkqhkiG9w0BAQUFADBU MQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xv YmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMB4XDTE0MDEyNTIyNDE0OFoXDTE2MDYw MzExMDA1OFowQDEbMBkGA1UEAwwSZ3JiYXJ0bGVAY2lzY28uY29tMSEwHwYJKoZIhvcNAQkB FhJncmJhcnRsZUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCq YhYxolKrFoPfXuZTQdAiQVFg14EvWwIEMyXxhfH2RiwOSJRSsUVmTNYG8HdeSf0JdzjAMh9p ODgxLC90Q1nbLyBqmEAKElWTasAnATKBCD7aLhce+25cznTT4FDpJsvvU2lZFPWXSLQm3bNR +mEDP6pd8zR1ItOKBlNmGtwypUUvi4KrKRPzx1cSgVTN0Xocj4fC5N8Rj3tOqOns+EHOX4Rw oy/rebHjQyv1cRr6FyGhRuz24hPv8mAGr/iF0cMphAsujaGKyAo+tA05K3nI0fdoeCx2wdEs vo8jIeeZVii07b3K9+VdJQmerVKJyMfQT6gLkyuassY/5aXlglNxAgMBAAGjggGHMIIBgzAO BgNVHQ8BAf8EBAMCBaAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYm aHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wHQYDVR0RBBYwFIESZ3Ji YXJ0bGVAY2lzY28uY29tMAkGA1UdEwQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3MvZ3Nw ZXJzb25hbHNpZ24xZzIuY3JsMFUGCCsGAQUFBwEBBEkwRzBFBggrBgEFBQcwAoY5aHR0cDov L3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NwZXJzb25hbHNpZ24xZzIuY3J0MB0G A1UdDgQWBBRBHvZ1Aur9AFGMEId10iH6yeUX3jAfBgNVHSMEGDAWgBTsrJjMJ3KTz1YyzSPH nY1FhfQiAzANBgkqhkiG9w0BAQUFAAOCAQEAdhq5YZv5ZCu0/HdQF1S3f+quesVc39HKv+Fe 2rmKuJcxfGOFZGpKhJDa1+sFeN/T+e2e6UJ0Yy90GLqi5U1fioD3XRhsFiVOh7CbJQESF2Xx U1bhdutZFh6Ythe28iRPY6HQjJ/7ke5IQBWvLnAbCIzgy0GgZB9Vj+a2z6bzmfR6KAuLaMqM vahvJ0w+DeHMEOVnVzCdZzHMaEOXZHw/uZj5/hGvkp2C0rH/LhGunfAPX12WhVQSsgxWJhaF 8D49Ymrt7PWBsLokx06/15XwY2ogBmfLmeN/WhMy5HUiLn3EnzwF+RK2MStCDpP5AWzdnrTR tM43+AJrHwoI7H+C9DCCBBYwggL+oAMCAQICCwQAAAAAAS9O4SzhMA0GCSqGSIb3DQEBBQUA MFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdS b290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcN MTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1z YTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8aUcr5BvPNGjx0+LH0uRqeZCHrYQ7KN3QuahfxY8 fAzAbnvNDzGdEMyKn3+YX+k/QbAGNJOSFRxrAfhviF7WGcqDlin3HracDqMRgwrknWuFeqxh N2J7uXs3Y0zluJEkEittRXv+ZdXOG/Gp3gtoz5P9noc5jBbfWQpQBhcaJA2ucABbUVTHDTxi 7dBY8mTWq6kRAkGWBybHwq0YX+jaHudtQw0oBEmxjpJFP9qIXu0ckU/+OhtnAhrgzrsd4oAy qgc6u4dBYERcjDJFohihjbzPozgKDSSbdr44uO3p9Bg6ibjCxn2besLrIE7upoxvV09Fsf7h DeD/jcvs64z8pQIDAQABo4HlMIHiMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/ AgEAMB0GA1UdDgQWBBTsrJjMJ3KTz1YyzSPHnY1FhfQiAzBHBgNVHSAEQDA+MDwGBFUdIAAw NDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8w MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDAf BgNVHSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAr7un yEtmt9Ia7hmNpqP+xMd0t5hLM0QBY8G3Dlg70XI6F+ZeSZeeXgCtUT/JhdQ+HsJ8+c6HypDu vg/OZ0gILDFIa9LDfRWm+tHIgxKaJjtCy0izg838dLwwnt/O3kA9N/htEYev2lsmWYCV9cVU m5V1tW3XuYNg6SbtcDRH+Ki1RED9es3R0BgHSm012KPxsiAOOxuhm1D3Iqs1qe6ms5WTKXVg wb/j/kplOa13nshhc8zULVO+oAlD4+7czNK2RJiTvhJiDJDRTZy3DJ3BCQ8rXOGdWzDEI5ui B8TZ0s327g44Ylc6dgKgYelNn9RLYjNETX8OIJZlr0tFYpcYrDCCA3UwggJdoAMCAQICCwQA AAAAARVLWsOUMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i YWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJv b3QgQ0EwHhcNOTgwOTAxMTIwMDAwWhcNMjgwMTI4MTIwMDAwWjBXMQswCQYDVQQGEwJCRTEZ MBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMS R2xvYmFsU2lnbiBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2g7m mY3Oo+NPin778YuDJWvqSB/xKrC5lREEvfBj0eJnZs8c3c8bSCvujYmOmq8pgGWr6cctEsur HExwB6E9CjDNFY1P+N3UjFAVHO9Q7sQu9/zpUvKRfeBt1TUwjl5Dc/JB6dVq47KJOlY5OG8G PIhpWypNxadUuGyJzJv5PMrl/Yn1EjySeJbW3HRuk0Rh0Y3HRrJ1DoboGYrVbWzVeBaVounI Cjjr8iQTT3NUkxOFOhu8HjS1iwWMuXeLsdsfIJGrCVNukM57N3S5cEeRIlFjFnmusa5BJgjI GSvRRqpI1mQq14M0/ywqwWwZQ0oHhefTfPYhaO/q8lKff5OQzwIDAQABo0IwQDAOBgNVHQ8B Af8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUYHtmGkUNl8qJUC99BM00qP/8 /UswDQYJKoZIhvcNAQEFBQADggEBANZz53xPdtCNv+y6or40xSgytXz8bJwsK70JnlO/a16q EUi25Qijs8o9YU3TRgmzPsOg42NVG/K676054UO5OKPmL4omO++gUFb5xgr9OM3EC3BRlJeY BN/DX5TVFckUQZzEXXVkFQ3/VTDsho//De8suWNG9qr837xp/S4SSGSa4JXwpu8pjwGxFbUM HaX+aSxpJHges6cccWLuysiXrBddisL4R4ZuKsRWMZXQZ4mFK/lspl1GnQyqguSZUd1wt9tW PWHkauFc1vb+Pd5BzAeuY1K/U1P0K+nH/bb3gl+F0kEY24GzBBzFH6SAbxUgyd4MiAod1mZV 4vxIySkmaeAxggH+MIIB+gIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAxIENBIC0gRzIC EGZgT+TGYtW+XJFIXloecG0wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgGitJ UF2JwYW12UmMHJeoD3BwmwMe4SerE0pIqadiqpEwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTQxMjAzMjMwNzUxWjANBgkqhkiG9w0BAQEFAASCAQAlE7sR 3o+vXhH9jlfCs90NkJ4LfN1Df9gX5iaJ+nV5Y+0jGbgpXS38xHoFcMx0Ql20m+iB9UrtqQGT ORLb3ZbQkbBW8cZmmm8WnWUCeXenIjdmKKBOeWmA+EI5RQgrHSZeIYhOR6CV8yImIRsHfHgH +svCSy53gKhC1ZfGXKfF4HPjUe9BCJdFtud4UWOuA9At+7kEoYk/lOL+Dn+RgbInfd9vw9Iy /uFpFKufcco2fLCoSKHSG0OJvs4klIUS4KpTDfouiPTuHEctgQmtQcPh7xRTqdgDHanHmz4P ezn0AipmP1xhTJT8COmmThbmv5XClMedNFniQ/bwQpKapDSl --B_3500492871_13943843-- From nobody Wed Dec 3 15:47:11 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 8D1DB1A1B80 for ; Wed, 3 Dec 2014 15:47:06 -0800 (PST) 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 9YGDTmUYw-dI for ; Wed, 3 Dec 2014 15:47:04 -0800 (PST) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAA821ACEE8 for ; Wed, 3 Dec 2014 15:46:35 -0800 (PST) Received: by mail-wi0-f177.google.com with SMTP id l15so26190458wiw.16 for ; Wed, 03 Dec 2014 15:46:34 -0800 (PST) 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=cpW4QWGW4ScOxl9XF7f+lOtcamqp6dmxILVyTysWn+M=; b=WU1we/Wy4eR8GggW3pulVgTNg7DQLr14Bu+9UukNLDGMkhVyPq5Z/7YOrRi2lAAJdz spn993LSz78hAX8uVN7jqh5tdi+BTgqvq530ZbD9HiHd6nhEF8M05nw78EoEjyQeGjYd ECZI6VKETRoV7V1q5kWq3Ei9m0yBJKeeSJWihCGQUu2vFh+OJDrhRBxaVsvqhLoKKTrm l8D3U7x0prWzVGlxE+MDPCm7hZHH6oUbqOwuaueg854I2d0qQV+psHiMXbjz30ZA77xo s8cLD7quwZHfgoWqM9eaUvM/hSnOcEJnXqSY3Lgejcc5YZvyW7uX5+YXrx4QrO5PZPAQ Cyfg== X-Received: by 10.194.85.161 with SMTP id i1mr10987356wjz.35.1417650394458; Wed, 03 Dec 2014 15:46:34 -0800 (PST) Received: from [192.168.1.104] (IGLD-84-229-24-231.inter.net.il. [84.229.24.231]) by mx.google.com with ESMTPSA id ud1sm38231573wjc.7.2014.12.03.15.46.33 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 15:46:33 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Yoav Nir In-Reply-To: Date: Thu, 4 Dec 2014 01:46:31 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <823EDABF-5456-48A4-B50C-D3FEE0760CAC@gmail.com> References: <410D9347-2DFF-42FE-A821-A177112BED0E@gmail.com> <34CC278854404D2EB46355F3579111D2@buildpc> <295C7FAB-4206-4EB2-B98D-0867BBE61E31@gmail.com> To: "Graham Bartlett (grbartle)" X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/E9XQPxw-cVx2NV8KHINVcNa5uLs Cc: ipsec , Valery Smyslov , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] Some speculations about puzzles 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, 03 Dec 2014 23:47:07 -0000 Why? The responder can remember that generation 8 had a 20-bit = difficulty level. If the attack then gets worse, than generation 9 is = created with a 23-bit difficulty level. The responder needs only remember the generation and associated = difficulty level. > On Dec 4, 2014, at 1:07 AM, Graham Bartlett (grbartle) = wrote: >=20 >=20 > If the 1 byte 'difficulty level' has become the 'puzzle id', could we > break the 1 byte into two 4 bits? >=20 > 1st 4 bits is 'puzzle/generation id', next 4bits is 'difficulty = level', > this allows for 16 cycles for when every secret changes and still = allows > 16 levels of puzzles.. >=20 > (just a thought as if the difficulty level disappears you loose the > ability to set a the hardness of the puzzle) >=20 >=20 > On 03/12/2014 16:01, "Yoav Nir" wrote: >=20 >>=20 >>> On Dec 3, 2014, at 5:44 PM, Valery Smyslov wrote: >>>=20 >>> Hi Scott, >>>=20 >>> this is almost identical to what I proposed in my original e-mail, >>> if you substitute "difficulty level" with "puzzle id=B2. >>=20 >> Or call it =B3generation id=B2, and increment it whenever you = generate a new >> secret and/or change the difficulty level. From nobody Wed Dec 3 23:20:53 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 414391A891C for ; Wed, 3 Dec 2014 23:20:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.108 X-Spam-Level: * X-Spam-Status: No, score=1.108 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 0F9lhnrvZMPs for ; Wed, 3 Dec 2014 23:20:50 -0800 (PST) Received: from mail-la0-x231.google.com (mail-la0-x231.google.com [IPv6:2a00:1450:4010:c03::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2B3D61A00A7 for ; Wed, 3 Dec 2014 23:20:50 -0800 (PST) Received: by mail-la0-f49.google.com with SMTP id hs14so13606860lab.22 for ; Wed, 03 Dec 2014 23:20:48 -0800 (PST) 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=gzhmR3AEtfa/PbpV9F9HKVfiP2YC5oGnD3SUs0TwYlA=; b=gH2CFOw6u/tCxWFC5gvWaRky6ITOxygqDVNvhukyxK3WUYDkZc7dyH4ZO3TpFJoNhq vMA8W2ktzhVSVjyjZxKEzZOsrmEvthPJvFk4bbcIb4uQHQS0sB4DV68HHNAi9Q1n5Gv1 Qz/JXIhmkvN6lRaqsiKKROl2ARZfMeb1VRKGSnhUQWDnaanwocNP4rBVyG5AwMjKM4MU pxByf1Faa4jz2uR2f9TPWnV7IRrtomU7v83TrSLMwGx6im4BnvmzhWTt5y+2bclC/aie 5eJUOxf5I58pWtgVAN27ipqrF4pmFurNQzMiXFmjtr2uy8Cx2ruE4uMqEpQA6ehtm1+N beMQ== X-Received: by 10.112.56.134 with SMTP id a6mr7874353lbq.25.1417677648589; Wed, 03 Dec 2014 23:20:48 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id j19sm7071416lbl.23.2014.12.03.23.20.47 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 03 Dec 2014 23:20:47 -0800 (PST) Message-ID: <684ED2F67C634CEE939606B79075D81A@buildpc> From: "Valery Smyslov" To: "Yoav Nir" References: <410D9347-2DFF-42FE-A821-A177112BED0E@gmail.com> <34CC278854404D2EB46355F3579111D2@buildpc> <295C7FAB-4206-4EB2-B98D-0867BBE61E31@gmail.com> Date: Thu, 4 Dec 2014 10:20:48 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; reply-type=original Content-Transfer-Encoding: 8bit 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/1QrzVpSkXxYbNRop1oJHURFHbN4 Cc: ipsec , "Graham Bartlett \(grbartle\)" , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] Some speculations about puzzles 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, 04 Dec 2014 07:20:51 -0000 >> Hi Scott, >> >> this is almost identical to what I proposed in my original e-mail, >> if you substitute "difficulty level" with "puzzle idâ€. > > Or call it “generation idâ€, and increment it whenever you generate a new > secret and/or change the difficulty level.= That will work. In this case it is better to make “generation id†long enough (4 bytes or longer) and initialize it with random value after reboot. Anyway, it doesn't matter how exactly the cookie is constructed and it should not be mandated in RFC, as it doest't affect interoperability. However, some guidance and examples should be given. In particular, RFC should advise implementers to construct cookie in such way, that the responder is able to quickly detect invalid/stale/forged cookies/puzzles spending as little resources as possible. From nobody Wed Dec 3 23:45: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 458211A8949 for ; Wed, 3 Dec 2014 23:45:19 -0800 (PST) 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 FUHwBiIa0FjK for ; Wed, 3 Dec 2014 23:45:15 -0800 (PST) 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 BC7881A8947 for ; Wed, 3 Dec 2014 23:45:14 -0800 (PST) Received: by mail-wi0-f182.google.com with SMTP id h11so26841629wiw.9 for ; Wed, 03 Dec 2014 23:45:13 -0800 (PST) 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=fHT5WMdxFgneDBrlduhUF/R9yczNn4XJOhPVm1vk0Ks=; b=xK09EZN4ZGWy3QK2Cq6wIVSSRcHJp9cSm27ir+zauHXu63BhuLU5pd6aQLziDuiAQh pegUba9oZKFbx9zITFbI+DobJJBSu8xmOjzCEajgmdH/g+mpw24EtWOYQO7YSBsBirvI CAWFhvKLWzjMu7naXQY1OvCX/oMm5VDb1belf2XQ9uUepxSTAlp1sEoA79DSpH5LdJsB YEF2dOJ2YBASNeX57yxGDaJE5LG6rmT6iDRCYxni3z/o7JhVJS1mqtFZBhPTAa1MY3sA eBlG2M+iPWtQ9pt2t4q2mVZdczpa3lkEBcj4ZVBHlPf7Ki8h3yJFtJ6KerXS9rn5rA/X UDGA== X-Received: by 10.194.109.201 with SMTP id hu9mr13348299wjb.45.1417679113586; Wed, 03 Dec 2014 23:45:13 -0800 (PST) Received: from [172.24.251.68] (dyn32-131.checkpoint.com. [194.29.32.131]) by mx.google.com with ESMTPSA id j9sm7299639wjb.38.2014.12.03.23.45.12 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 03 Dec 2014 23:45:12 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) Content-Type: text/plain; charset=utf-8 From: Yoav Nir X-Priority: 3 In-Reply-To: <684ED2F67C634CEE939606B79075D81A@buildpc> Date: Thu, 4 Dec 2014 09:45:09 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8A60A9DF-BFF6-4AAB-A34B-8B0E0910553D@gmail.com> References: <410D9347-2DFF-42FE-A821-A177112BED0E@gmail.com> <34CC278854404D2EB46355F3579111D2@buildpc> <295C7FAB-4206-4EB2-B98D-0867BBE61E31@gmail.com> <684ED2F67C634CEE939606B79075D81A@buildpc> To: Valery Smyslov X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/VcMOzqaANR5XQYPHQvCNwjvZVG0 Cc: ipsec , "Graham Bartlett \(grbartle\)" , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] Some speculations about puzzles 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, 04 Dec 2014 07:45:19 -0000 > On Dec 4, 2014, at 9:20 AM, Valery Smyslov wrote: >=20 >>> Hi Scott, >>>=20 >>> this is almost identical to what I proposed in my original e-mail, >>> if you substitute "difficulty level" with "puzzle id=E2=80=9D. >>=20 >> Or call it =E2=80=9Cgeneration id=E2=80=9D, and increment it whenever = you generate a new secret and/or change the difficulty level.=3D >=20 > That will work. In this case it is better to make =E2=80=9Cgeneration = id=E2=80=9D long enough (4 bytes or longer) > and initialize it with random value after reboot. >=20 > Anyway, it doesn't matter how exactly the cookie is constructed and it = should > not be mandated in RFC, as it doest't affect interoperability. = However, some > guidance and examples should be given. Definitely agree. If a document doesn=E2=80=99t give an example of how = to do this non-stupidly, implementers will come up with multiple = creative ways of doing this wrong. > In particular, RFC should advise > implementers to construct cookie in such way, that the responder is = able to quickly detect > invalid/stale/forged cookies/puzzles spending as little resources as = possible. Yoav From nobody Thu Dec 4 03:26:04 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 8A6491A016C for ; Thu, 4 Dec 2014 03:26:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.91 X-Spam-Level: X-Spam-Status: No, score=-13.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_42=0.6, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 XwBOpj2VT38t for ; Thu, 4 Dec 2014 03:25:59 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7662B1A0164 for ; Thu, 4 Dec 2014 03:25:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7913; q=dns/txt; s=iport; t=1417692359; x=1418901959; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=/pZbQ87ZauScyVsL1pHAMxf1HGKpzLe6S29vxL4vRcU=; b=WCOARxHJVVK9Wcv+LJX3FO/gfS5zxrZueAoTuF73opLGt9v83z+aSRs3 jPKWVhYsq12vLGSaf46bDpmuLmPvK+xy/wKLL8T5DvLhsDD1wG5BAXuAB CtacebvTD5WMwD1piUu2DRYszl/LjGAj0Rqp5XAmGGMw4uPbksXz+Hl/f g=; X-Files: smime.p7s : 3708 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjQFAOJDgFStJA2L/2dsb2JhbABagmQigSoEgwHBKIg8AiVzFgEBAQEBfYQDAQEEeRACAQgOCiwCAh8RJQIEDgUOiBsDEgGib5xjBpB6DYVeAQEBAQEBAQEBAQEBAQEBAQEBAQEBF44wghsbBwSCZ4FXBZAQgXaBQIUigXKNeoYdggIegVlvgUWBAAEBAQ X-IronPort-AV: E=Sophos;i="5.07,515,1413244800"; d="p7s'?scan'208";a="102614896" Received: from alln-core-6.cisco.com ([173.36.13.139]) by alln-iport-8.cisco.com with ESMTP; 04 Dec 2014 11:25:58 +0000 Received: from xhc-aln-x11.cisco.com (xhc-aln-x11.cisco.com [173.36.12.85]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id sB4BPwaE009787 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 4 Dec 2014 11:25:58 GMT Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by xhc-aln-x11.cisco.com ([173.36.12.85]) with mapi id 14.03.0195.001; Thu, 4 Dec 2014 05:25:58 -0600 From: "Graham Bartlett (grbartle)" To: Yoav Nir Thread-Topic: [IPsec] Some speculations about puzzles Thread-Index: AQHQDX1WXMPTLhaXMUeLlbXm0oFemJx9Vr0AgAB5tbeAAI59AIAACRoA//+dOJmAAGkNgIAAdziAgAAKzoCAAMNqAA== Date: Thu, 4 Dec 2014 11:25:57 +0000 Message-ID: References: <410D9347-2DFF-42FE-A821-A177112BED0E@gmail.com> <34CC278854404D2EB46355F3579111D2@buildpc> <295C7FAB-4206-4EB2-B98D-0867BBE61E31@gmail.com> <823EDABF-5456-48A4-B50C-D3FEE0760CAC@gmail.com> In-Reply-To: <823EDABF-5456-48A4-B50C-D3FEE0760CAC@gmail.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [10.55.146.103] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3500537156_14660914" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/R3dY2jfz7x5osQkBH22si2e0puk Cc: ipsec , Valery Smyslov , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] Some speculations about puzzles 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, 04 Dec 2014 11:26:01 -0000 --B_3500537156_14660914 Content-type: text/plain; charset="EUC-KR" Content-transfer-encoding: quoted-printable Hi Yoav As I understand this, changing the concept from 'difficulty level' to 'puzzle/generation id' doesn't allow for a responder to hand out some puzzles weaker than others at the same time? (Unless it's tracked locally as you said), but then the Responder would need to remember all previous Puzzles up to the last point where a certain GenerationID was used if it's to issue Puzzles of different difficulty at the same time. (Otherwise I see an attack where someone can potentially just make all new connections have the most difficult puzzles, there might be a need for some random un-fairness with 1 in X having hard puzzles?). Also if the 'difficulty level' is no longer used, how does the client know what difficulty this is ? Generation 9 could be 23-bit one day and 0 the next. If both are included this allows for the Responder to change secret and also allow for multiple difficulty types. Cookie =3D | | | | | Hash(Ni | IPi | SPIi | | | | | ) thanks On 03/12/2014 23:46, "Yoav Nir" wrote: >Why? The responder can remember that generation 8 had a 20-bit >difficulty level. If the attack then gets worse, than generation 9 is >created with a 23-bit difficulty level. > >The responder needs only remember the generation and associated >difficulty level. > >> On Dec 4, 2014, at 1:07 AM, Graham Bartlett (grbartle) >> wrote: >>=20 >>=20 >> If the 1 byte 'difficulty level' has become the 'puzzle id', could we >> break the 1 byte into two 4 bits? >>=20 >> 1st 4 bits is 'puzzle/generation id', next 4bits is 'difficulty level', >> this allows for 16 cycles for when every secret changes and still allows >> 16 levels of puzzles.. >>=20 >> (just a thought as if the difficulty level disappears you loose the >> ability to set a the hardness of the puzzle) >>=20 >>=20 >> On 03/12/2014 16:01, "Yoav Nir" wrote: >>=20 >>>=20 >>>> On Dec 3, 2014, at 5:44 PM, Valery Smyslov wrote: >>>>=20 >>>> Hi Scott, >>>>=20 >>>> this is almost identical to what I proposed in my original e-mail, >>>> if you substitute "difficulty level" with "puzzle id=A9=F7. >>>=20 >>> Or call it =A9=F8generation id=A9=F7, and increment it whenever you generate a >>>new >>> secret and/or change the difficulty level. > --B_3500537156_14660914 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIOeAYJKoZIhvcNAQcCoIIOaTCCDmUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgggw+MIIEpzCCA4+gAwIBAgIQZmBP5MZi1b5ckUheWh5wbTANBgkqhkiG9w0BAQUFADBU MQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xv YmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMB4XDTE0MDEyNTIyNDE0OFoXDTE2MDYw MzExMDA1OFowQDEbMBkGA1UEAwwSZ3JiYXJ0bGVAY2lzY28uY29tMSEwHwYJKoZIhvcNAQkB FhJncmJhcnRsZUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCq YhYxolKrFoPfXuZTQdAiQVFg14EvWwIEMyXxhfH2RiwOSJRSsUVmTNYG8HdeSf0JdzjAMh9p ODgxLC90Q1nbLyBqmEAKElWTasAnATKBCD7aLhce+25cznTT4FDpJsvvU2lZFPWXSLQm3bNR +mEDP6pd8zR1ItOKBlNmGtwypUUvi4KrKRPzx1cSgVTN0Xocj4fC5N8Rj3tOqOns+EHOX4Rw oy/rebHjQyv1cRr6FyGhRuz24hPv8mAGr/iF0cMphAsujaGKyAo+tA05K3nI0fdoeCx2wdEs vo8jIeeZVii07b3K9+VdJQmerVKJyMfQT6gLkyuassY/5aXlglNxAgMBAAGjggGHMIIBgzAO BgNVHQ8BAf8EBAMCBaAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYm aHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wHQYDVR0RBBYwFIESZ3Ji YXJ0bGVAY2lzY28uY29tMAkGA1UdEwQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3MvZ3Nw ZXJzb25hbHNpZ24xZzIuY3JsMFUGCCsGAQUFBwEBBEkwRzBFBggrBgEFBQcwAoY5aHR0cDov L3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NwZXJzb25hbHNpZ24xZzIuY3J0MB0G A1UdDgQWBBRBHvZ1Aur9AFGMEId10iH6yeUX3jAfBgNVHSMEGDAWgBTsrJjMJ3KTz1YyzSPH nY1FhfQiAzANBgkqhkiG9w0BAQUFAAOCAQEAdhq5YZv5ZCu0/HdQF1S3f+quesVc39HKv+Fe 2rmKuJcxfGOFZGpKhJDa1+sFeN/T+e2e6UJ0Yy90GLqi5U1fioD3XRhsFiVOh7CbJQESF2Xx U1bhdutZFh6Ythe28iRPY6HQjJ/7ke5IQBWvLnAbCIzgy0GgZB9Vj+a2z6bzmfR6KAuLaMqM vahvJ0w+DeHMEOVnVzCdZzHMaEOXZHw/uZj5/hGvkp2C0rH/LhGunfAPX12WhVQSsgxWJhaF 8D49Ymrt7PWBsLokx06/15XwY2ogBmfLmeN/WhMy5HUiLn3EnzwF+RK2MStCDpP5AWzdnrTR tM43+AJrHwoI7H+C9DCCBBYwggL+oAMCAQICCwQAAAAAAS9O4SzhMA0GCSqGSIb3DQEBBQUA MFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdS b290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcN MTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1z YTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8aUcr5BvPNGjx0+LH0uRqeZCHrYQ7KN3QuahfxY8 fAzAbnvNDzGdEMyKn3+YX+k/QbAGNJOSFRxrAfhviF7WGcqDlin3HracDqMRgwrknWuFeqxh N2J7uXs3Y0zluJEkEittRXv+ZdXOG/Gp3gtoz5P9noc5jBbfWQpQBhcaJA2ucABbUVTHDTxi 7dBY8mTWq6kRAkGWBybHwq0YX+jaHudtQw0oBEmxjpJFP9qIXu0ckU/+OhtnAhrgzrsd4oAy qgc6u4dBYERcjDJFohihjbzPozgKDSSbdr44uO3p9Bg6ibjCxn2besLrIE7upoxvV09Fsf7h DeD/jcvs64z8pQIDAQABo4HlMIHiMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/ AgEAMB0GA1UdDgQWBBTsrJjMJ3KTz1YyzSPHnY1FhfQiAzBHBgNVHSAEQDA+MDwGBFUdIAAw NDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8w MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDAf BgNVHSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAr7un yEtmt9Ia7hmNpqP+xMd0t5hLM0QBY8G3Dlg70XI6F+ZeSZeeXgCtUT/JhdQ+HsJ8+c6HypDu vg/OZ0gILDFIa9LDfRWm+tHIgxKaJjtCy0izg838dLwwnt/O3kA9N/htEYev2lsmWYCV9cVU m5V1tW3XuYNg6SbtcDRH+Ki1RED9es3R0BgHSm012KPxsiAOOxuhm1D3Iqs1qe6ms5WTKXVg wb/j/kplOa13nshhc8zULVO+oAlD4+7czNK2RJiTvhJiDJDRTZy3DJ3BCQ8rXOGdWzDEI5ui B8TZ0s327g44Ylc6dgKgYelNn9RLYjNETX8OIJZlr0tFYpcYrDCCA3UwggJdoAMCAQICCwQA AAAAARVLWsOUMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i YWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJv b3QgQ0EwHhcNOTgwOTAxMTIwMDAwWhcNMjgwMTI4MTIwMDAwWjBXMQswCQYDVQQGEwJCRTEZ MBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMS R2xvYmFsU2lnbiBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2g7m mY3Oo+NPin778YuDJWvqSB/xKrC5lREEvfBj0eJnZs8c3c8bSCvujYmOmq8pgGWr6cctEsur HExwB6E9CjDNFY1P+N3UjFAVHO9Q7sQu9/zpUvKRfeBt1TUwjl5Dc/JB6dVq47KJOlY5OG8G PIhpWypNxadUuGyJzJv5PMrl/Yn1EjySeJbW3HRuk0Rh0Y3HRrJ1DoboGYrVbWzVeBaVounI Cjjr8iQTT3NUkxOFOhu8HjS1iwWMuXeLsdsfIJGrCVNukM57N3S5cEeRIlFjFnmusa5BJgjI GSvRRqpI1mQq14M0/ywqwWwZQ0oHhefTfPYhaO/q8lKff5OQzwIDAQABo0IwQDAOBgNVHQ8B Af8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUYHtmGkUNl8qJUC99BM00qP/8 /UswDQYJKoZIhvcNAQEFBQADggEBANZz53xPdtCNv+y6or40xSgytXz8bJwsK70JnlO/a16q EUi25Qijs8o9YU3TRgmzPsOg42NVG/K676054UO5OKPmL4omO++gUFb5xgr9OM3EC3BRlJeY BN/DX5TVFckUQZzEXXVkFQ3/VTDsho//De8suWNG9qr837xp/S4SSGSa4JXwpu8pjwGxFbUM HaX+aSxpJHges6cccWLuysiXrBddisL4R4ZuKsRWMZXQZ4mFK/lspl1GnQyqguSZUd1wt9tW PWHkauFc1vb+Pd5BzAeuY1K/U1P0K+nH/bb3gl+F0kEY24GzBBzFH6SAbxUgyd4MiAod1mZV 4vxIySkmaeAxggH+MIIB+gIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAxIENBIC0gRzIC EGZgT+TGYtW+XJFIXloecG0wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgnSAl eC3BNk9R9h2Q7NLsvolvNThlYBEHo3eWA13kEV4wGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTQxMjA0MTEyNTU2WjANBgkqhkiG9w0BAQEFAASCAQA8n8R/ LFk68UIpXukS0W9t16VypSKaQwgvDhIdPa8g86sq5UypWmC6fcMsQyfMSMnRZSaOD49pOWEk bG1WB54jrGqfjcdLWxyHJn+EiptDqF4Fk6PtNe3G1ohbFVR54qQW1UXxrH+xCI5BFzriGLPO IO5hw8vRxk5tplBlnZUjMTalRoB456DUCxN2zY7BdspoyweFoKR1guAFPY9/BRZkcw7qbjRv 1kBsQMMm+coUMTZMjssiKiSFtehMoh+G+0Yn/vseOWdxGkZBlM4PRjrc8rZFJhw+WAjajx3N me4e3AjysByV30lWbnzKvwRuZCgfVWOKMMfglbyRZvfpz6cb --B_3500537156_14660914-- From nobody Thu Dec 4 03:50: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 747241A0282 for ; Thu, 4 Dec 2014 03:50:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.191 X-Spam-Level: X-Spam-Status: No, score=-0.191 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, J_CHICKENPOX_42=0.6, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 KeFYl4-3R-oa for ; Thu, 4 Dec 2014 03:50:18 -0800 (PST) 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 E8D341A026E for ; Thu, 4 Dec 2014 03:50:17 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id ge10so14307516lab.3 for ; Thu, 04 Dec 2014 03:50:16 -0800 (PST) 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=vSl546Fume05WfCI9/TcPmQ118LNPH6FKqH4TqhCu/0=; b=P8u71rmIsoBSkY2eVncZ0iEWtf+onCWT9lA1LfWommvp/Pzvuq0XR6LKykESnQG3EK 2zvvJIzR3Io+BdD9AUrKaUfvmiRuijyfL5c+8mv2bn9GA6a6y1MV9iBofs2m3X2bSOBQ qI4vWhgABGl30k1ZozRb5WAVWZhkA3enP6CDSfv2+9oMHxP+JZLRAH0uRabOUbu53xdg icqmNMqM4/RExxISwRm9dxwIxjsqzc7kWaPpqusJ5qLytFESKgpAmE2gwczIB+pZvsTY +TWpQBOfc7lvOkRPq+TIttzMYiRkX86J8aVJFeBG+udRQg0aWDutLIpwxLYayqdRQ64R QnwQ== X-Received: by 10.112.254.162 with SMTP id aj2mr9197726lbd.70.1417693816480; Thu, 04 Dec 2014 03:50:16 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id ji6sm1536120lbb.26.2014.12.04.03.50.15 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 04 Dec 2014 03:50:15 -0800 (PST) Message-ID: <72EE4F73162D4AC789A63918550028AF@buildpc> From: "Valery Smyslov" To: "Graham Bartlett \(grbartle\)" , "Yoav Nir" References: <410D9347-2DFF-42FE-A821-A177112BED0E@gmail.com> <34CC278854404D2EB46355F3579111D2@buildpc> <295C7FAB-4206-4EB2-B98D-0867BBE61E31@gmail.com> <823EDABF-5456-48A4-B50C-D3FEE0760CAC@gmail.com> Date: Thu, 4 Dec 2014 14:50:18 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="windows-1251"; reply-type=original Content-Transfer-Encoding: 8bit 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/mliDLr9zww0hrtJaPyGFlCMq0CA Cc: ipsec , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] Some speculations about puzzles 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, 04 Dec 2014 11:50:19 -0000 Hi Graham, I'm not Yoav, but I'll try to clarify. > Hi Yoav > > As I understand this, changing the concept from 'difficulty level' to > 'puzzle/generation id' doesn't allow for a responder to hand out some > puzzles weaker than others at the same time? (Unless it's tracked locally > as you said), but then the Responder would need to remember all previous Yes, in Yoav's approach the responder should remember last N pairs "generation_id : difficulty: secret". > Puzzles up to the last point where a certain GenerationID was used if it's > to issue Puzzles of different difficulty at the same time. (Otherwise I > see an attack where someone can potentially just make all new connections > have the most difficult puzzles, there might be a need for some random > un-fairness with 1 in X having hard puzzles?). > > Also if the 'difficulty level' is no longer used, how does the client know > what difficulty this is ? Generation 9 could be 23-bit one day and 0 the > next. In any case (with mine or Yoav's approach) the difficulty level must be indicated to initiator explicitely, in a separate field (it presumably must be in (to be defined) PUZZLE Notification). Difficulty level in cookie (as I suggested) is for responder's use only. For initiator the cookie is an opaque blob in any case, but responder must be able to determine which difficulty level was requested with any particular cookie. In my approach the level is encoded in the cookie itself, in Yoav's approach it is locally accociated with "generation_id", which is encoded in the cookie. Both approaches are workable. There are some advantages and drawbacks in each, but they are insignificant, IMHO. Regards, Valery. > If both are included this allows for the Responder to change secret and > also allow for multiple difficulty types. > > Cookie = | | | > | | > > Hash(Ni | IPi | SPIi | | | > | | > ) > > > thanks On 03/12/2014 23:46, "Yoav Nir" wrote: >Why? The responder can remember that generation 8 had a 20-bit >difficulty level. If the attack then gets worse, than generation 9 is >created with a 23-bit difficulty level. > >The responder needs only remember the generation and associated >difficulty level. > >> On Dec 4, 2014, at 1:07 AM, Graham Bartlett (grbartle) >> wrote: >> >> >> If the 1 byte 'difficulty level' has become the 'puzzle id', could we >> break the 1 byte into two 4 bits? >> >> 1st 4 bits is 'puzzle/generation id', next 4bits is 'difficulty level', >> this allows for 16 cycles for when every secret changes and still allows >> 16 levels of puzzles.. >> >> (just a thought as if the difficulty level disappears you loose the >> ability to set a the hardness of the puzzle) >> >> >> On 03/12/2014 16:01, "Yoav Nir" wrote: >> >>> >>>> On Dec 3, 2014, at 5:44 PM, Valery Smyslov wrote: >>>> >>>> Hi Scott, >>>> >>>> this is almost identical to what I proposed in my original e-mail, >>>> if you substitute "difficulty level" with "puzzle id©÷. >>> >>> Or call it ©øgeneration id©÷, and increment it whenever you generate a >>>new >>> secret and/or change the difficulty level. > From nobody Thu Dec 4 12:27:26 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 AD3EB1A1B03 for ; Thu, 4 Dec 2014 12:27:21 -0800 (PST) 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 wxoHAxVRGi9J for ; Thu, 4 Dec 2014 12:27:18 -0800 (PST) Received: from mail-wg0-x22f.google.com (mail-wg0-x22f.google.com [IPv6:2a00:1450:400c:c00::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 813201A1AFC for ; Thu, 4 Dec 2014 12:27:18 -0800 (PST) Received: by mail-wg0-f47.google.com with SMTP id n12so23838232wgh.34 for ; Thu, 04 Dec 2014 12:27:17 -0800 (PST) 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=PEP0Nm99c4M/3G+8EkO90J5mguQU989RidkxHE6eh/I=; b=ATVMYnn5dpPv3VaUzzlYT+J7+fCLgA4zGXFTdqQsXON828r2bUOTLyJ2wa6pWlMf0P buQwTXI2aDAcYBmS+cxsov2TGucfR4jDsz4pr0xRBGvexoW+Ya7yJJbUcNBeNJI5sM12 knIP+pgbSHI2I1J17zf86Ilscq4LZFe9E9Y9xkRVzkXrlWwqHdysKyg1gLGK+Q++YpsW k0bDD3MSR9tKKn04zNAdeABNawXVxwZyx35SF+xWK1z22/qegT6LRzlePl9gHc1TvMAB lxsIE+kBzDqRKDP+6lshp6JppGofaC5MRE3HGiJBDbiboLA2wgUjcrL550fUblLRT7dc 8Lyw== X-Received: by 10.180.20.6 with SMTP id j6mr1425218wie.59.1417724837158; Thu, 04 Dec 2014 12:27:17 -0800 (PST) Received: from [10.0.0.9] (bzq-79-176-33-71.red.bezeqint.net. [79.176.33.71]) by mx.google.com with ESMTPSA id l10sm56408187wif.20.2014.12.04.12.27.16 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 04 Dec 2014 12:27:16 -0800 (PST) Message-ID: <5480C3A3.6040103@gmail.com> Date: Thu, 04 Dec 2014 22:27:15 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Valery Smyslov , Yoav Nir , ipsec References: <410D9347-2DFF-42FE-A821-A177112BED0E@gmail.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/F8Zjwc8BYhxJmtUgqeQKJzorQAc Subject: Re: [IPsec] Some speculations about puzzles 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, 04 Dec 2014 20:27:21 -0000 Hi Valery, Going back to your original message (I guess not everyone read it to the end :-) I don't understand how puzzles for IKE_AUTH can be mandatory without breaking the protocol. The responder doesn't even know that the initiator supports puzzles. At the very least, we would need to add a "puzzles supported" notification. And again for IKE_AUTH, I don't see why with fragmentation you need one puzzle solution per fragment. The major CPU cost (DH computation, certificate stuff and decryption) comes once, after the message is re-assembled. So it seems to me only one puzzle response is needed for the entire message. Thanks, Yaron From nobody Thu Dec 4 13:14:52 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 006051A1E0F for ; Thu, 4 Dec 2014 13:14:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 66lGOsnyOU6P for ; Thu, 4 Dec 2014 13:14:43 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 49D7F1A1EED for ; Thu, 4 Dec 2014 13:14:40 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id B02182002A; Thu, 4 Dec 2014 16:18:03 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 1BF47637F5; Thu, 4 Dec 2014 16:14:38 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id F1179637F4; Thu, 4 Dec 2014 16:14:38 -0500 (EST) From: Michael Richardson To: Tero Kivinen In-Reply-To: <21624.32179.838590.460413@fireball.kivinen.iki.fi> References: <21624.32179.838590.460413@fireball.kivinen.iki.fi> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/CNtnjBu35kkSI1IC3hmSlf2MMOM Cc: IPsecME WG , Valery Smyslov , Paul Wouters Subject: [IPsec] load-sharing and draft-mglt-ipsecme-clone-ike-sa 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, 04 Dec 2014 21:14:47 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable Tero Kivinen wrote: >> > it can be used in load-sharing scenario when there are >> That would run into replay protection problems, just like if you copy >> all kernel IPsec state between machines. And I believe load sharing >> when properly done should be invisible to client side and not need >> special support. > Actually I tihnk the idea is to get rid of the replay protection > issues. In normal case if you just copy all IKE and IPsec state > between the servers, then you need to make sure you also copy all > replay data. If you clone the IKE SA, move the cloned IKE SA to new > IP-address (and new load sharing server in the cluster), and then > create the IPsec Child SAs there, then each of the replay data is only > located in the server you are talking to, and there is no need to move > replay data between the cluster members. Given the the original document is about making multiple interfaces work, in the degenerate case of a phone with 3G and wifi, it seems to me that the case where there are multiple gateways (probably with different ISPs) is ju= st=20 the degenerate case on speed/PCP. All that is to say that it seems we should adopt this document, if this is really a use case we care about. >> Throwing around private keys or computed shared secrets to multiple >> peers worry me. > Private keys do not need to be transmitted, only the SKEYSEED and > material generated from there needs to be transmitted (i.e. the > computed shared state). Doing load-sharing without the client > knowledge, do require exactly same material to be transmitted, but in > addition to that all the replay protection related material needs to > be transmitted also.=20 =20 I left this here: I think that load balancers often *do* share private keys, and I think this protocol could reduce this need. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVIDOvICLcPvd0N1lAQKR6ggAnFFmlrfTfx70UIS3rUgkdJJQGzjxcrri QRw+Zo3DcWL7CK8eLkMAD6qAjzeHHkyjuV8C+yanGayEkpY8KwPF7vgRfbb1kyua di+HqLfWeEaTd6tmmdp6P9vETFQMtePKSI/xnsJLQMF4Pk54K5tiDdRUvo782fZ4 GsCk0uz4raESmKnEJoLGUPPY0Cwj8JVG5DfVCCSwacu3wlPKChDIXeGlTM5B9pUu vei+ToaoAM/3z2HibumZQy/h3um1+uquTeoTvsgXjoDgPvmg0Tth9eJpIiUjOduN LjgIL78GR5IeC6urn7zqU8XB33atEbATXnnKsIHLoOD+h7c2sgs6tA== =MnTw -----END PGP SIGNATURE----- --=-=-=-- From nobody Thu Dec 4 23:40:40 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 A25111AC436 for ; Thu, 4 Dec 2014 23:40:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.669 X-Spam-Level: X-Spam-Status: No, score=0.669 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, 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 AJoT0H38ToI4 for ; Thu, 4 Dec 2014 23:40:37 -0800 (PST) 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 20F0D1A036C for ; Thu, 4 Dec 2014 23:40:37 -0800 (PST) Received: by mail-la0-f46.google.com with SMTP id q1so212122lam.19 for ; Thu, 04 Dec 2014 23:40:35 -0800 (PST) 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=taVmfoMazDnuCmA091YRZ5JU6RX+L4DVUV6mqWa8rFc=; b=GUHZd79OdY3SyZPRFFgkmpaXz74mDHFGJSPodXP9f1Iv13p/V9Ts9OLPttBlL2exZT 6bMCsY9gsvJLlZ+DpzqGxuV80iLnWsAhV9SQD/WMyCpOaFVtQbivYsC+64geTzlKyhYa MUqsQDj95eyEgRw62y1PQFiE5GPb2tL971E0cw5C9NRiMo17IWTJNCbgIbExoldT2SZN 3Ty/OkRa+sEyY8wfreN2HHEa6BTRz1UhJFGTQ6R6No4eT3w3hCLb0yvGVN0IdxDKUSZl 5T2I+2TASzi/loKq9bDGBR/bW6OhpJBDQiackfokBmHr0cnSIsrIN0YUZJVusJLtgvJc M18w== X-Received: by 10.112.159.229 with SMTP id xf5mr1503199lbb.64.1417765235544; Thu, 04 Dec 2014 23:40:35 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id rb2sm8082874lbb.19.2014.12.04.23.40.34 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 04 Dec 2014 23:40:34 -0800 (PST) Message-ID: <1D725EE23AEE4AFD956F6B2BBF4F4C2F@buildpc> From: "Valery Smyslov" To: "Yaron Sheffer" , "Yoav Nir" , "ipsec" References: <410D9347-2DFF-42FE-A821-A177112BED0E@gmail.com> <5480C3A3.6040103@gmail.com> Date: Fri, 5 Dec 2014 10:40:40 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; 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/CR8l5EELnKlhIkNAqFQkkkDQWwk Subject: Re: [IPsec] Some speculations about puzzles 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, 05 Dec 2014 07:40:38 -0000 Hi Yaron, > Going back to your original message (I guess not everyone read it to the > end :-) If your guess is correct then it's a pity :-( > I don't understand how puzzles for IKE_AUTH can be mandatory without > breaking the protocol. The responder doesn't even know that the initiator > supports puzzles. At the very least, we would need to add a "puzzles > supported" notification. I probably wasn't clear enough. I meant that if client supports puzzles and accepts puzzle in IKE_SA_INIT, then it must also solve puzzle in IKE_AUTH. In other words, the puzzles in IKE_SA_INIT are optional for the client, but if they are accepted by client in IKE_SA_INIT, then they must also be used in IKE_AUTH. The reason for such a strong requirement is that in the situation when responder has already created the state but has not yet authenticated the initiator it becomes an easy target for DoS attack (as it is mentioned in the draft). > And again for IKE_AUTH, I don't see why with fragmentation you need one > puzzle solution per fragment. The major CPU cost (DH computation, > certificate stuff and decryption) comes once, after the message is > re-assembled. So it seems to me only one puzzle response is needed for the > entire message. In this case the responder would become succeptible to the attack when attacker emits forged fragments, that takes place of good fragments from legitimate initiator in the reassembly queue. To detect the forgery responder needs to check fragment authenticity before inserting it into the reassembly queue. That would require performing DH and calculating SK_a*, but that is what we are willing to defer unless peer proves that it is really really wants to setup connection and is ready to spend quite a lot of resources to do it. It would be possible to protect with puzzle only the very first fragment, because as we have calculated SK_a* it takes very little resources to verify the other fragments, but fragments can arrive in any order, so puzzle must be in each fragment. That is a bit unfortunate for the initiator, I admit. > Thanks, > Yaron Regards, Valery. From nobody Fri Dec 5 00:44:44 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 832D21ACDBF for ; Fri, 5 Dec 2014 00:44:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] 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 i3ZJfFI0HAL5 for ; Fri, 5 Dec 2014 00:44:41 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 223991A0140 for ; Fri, 5 Dec 2014 00:44:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5809; q=dns/txt; s=iport; t=1417769081; x=1418978681; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=BoX3Ue/3x52Qu96FmaerCT23uKDw6FUmtT+78tuWsjc=; b=JeCqXJ0zS2d6rG5SXpkZIJFA3qbSuQuOcUpLFYCMGfEG1mU+6WYCTtjD KJgkEitxp7BPjMFqiCvHh6ASIIcvdk9m4EptCOGwx0/h5M/R0sYZLtAlj SLSuIKGEBXE9/1km3A2QjkIyh01Hp+dqquzJ7zLUPW5kbwfDZkkby61fb 4=; X-Files: smime.p7s : 3708 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhMFAKtvgVStJV2Y/2dsb2JhbABZgwaBKgTEHog5AoEZFgEBAQEBfYQDAQEEeRACAQgOOAIfESUCBAENBQ6IGAMS0FYNhXMBAQEBAQEBAQEBAQEBAQEBAQEBAQEXjiKCEhsHhDYBBI1ZgWmBb4E1hQmBaYEijAyCLYNig29vgUV+AQEB X-IronPort-AV: E=Sophos;i="5.07,521,1413244800"; d="p7s'?scan'208";a="377863210" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-4.cisco.com with ESMTP; 05 Dec 2014 08:44:40 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id sB58idHo026375 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 5 Dec 2014 08:44:39 GMT Received: from xmb-rcd-x13.cisco.com ([169.254.3.198]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.03.0195.001; Fri, 5 Dec 2014 02:44:38 -0600 From: "Graham Bartlett (grbartle)" To: Valery Smyslov , Yoav Nir Thread-Topic: [IPsec] Some speculations about puzzles Thread-Index: AQHQDX1WXMPTLhaXMUeLlbXm0oFemJx9Vr0AgAB5tbeAAI59AIAACRoA//+dOJmAAGkNgIAAdziAgAAKzoCAAMNqAP//ojybgAHDBQA= Date: Fri, 5 Dec 2014 08:44:37 +0000 Message-ID: References: <410D9347-2DFF-42FE-A821-A177112BED0E@gmail.com> <34CC278854404D2EB46355F3579111D2@buildpc> <295C7FAB-4206-4EB2-B98D-0867BBE61E31@gmail.com> <823EDABF-5456-48A4-B50C-D3FEE0760CAC@gmail.com> <72EE4F73162D4AC789A63918550028AF@buildpc> In-Reply-To: <72EE4F73162D4AC789A63918550028AF@buildpc> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.4.6.141106 x-originating-ip: [10.55.146.101] Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3500613876_16820177" MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/FR9DLU1WoB8kl0jU4hO613ou_Wg Cc: ipsec , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] Some speculations about puzzles 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, 05 Dec 2014 08:44:42 -0000 --B_3500613876_16820177 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Hi Valery Thanks again. I interoperated the thread as your approach would have 'difficulty' replaced with 'generation_id'. (I now know this isn't the case). thanks On 04/12/2014 11:50, "Valery Smyslov" wrote: >In my approach >the level is encoded in the cookie itself, in Yoav's approach it is >locally accociated with "generation_id", which is encoded >in the cookie. --B_3500613876_16820177 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIOeAYJKoZIhvcNAQcCoIIOaTCCDmUCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgggw+MIIEpzCCA4+gAwIBAgIQZmBP5MZi1b5ckUheWh5wbTANBgkqhkiG9w0BAQUFADBU MQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEqMCgGA1UEAxMhR2xv YmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMB4XDTE0MDEyNTIyNDE0OFoXDTE2MDYw MzExMDA1OFowQDEbMBkGA1UEAwwSZ3JiYXJ0bGVAY2lzY28uY29tMSEwHwYJKoZIhvcNAQkB FhJncmJhcnRsZUBjaXNjby5jb20wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCq YhYxolKrFoPfXuZTQdAiQVFg14EvWwIEMyXxhfH2RiwOSJRSsUVmTNYG8HdeSf0JdzjAMh9p ODgxLC90Q1nbLyBqmEAKElWTasAnATKBCD7aLhce+25cznTT4FDpJsvvU2lZFPWXSLQm3bNR +mEDP6pd8zR1ItOKBlNmGtwypUUvi4KrKRPzx1cSgVTN0Xocj4fC5N8Rj3tOqOns+EHOX4Rw oy/rebHjQyv1cRr6FyGhRuz24hPv8mAGr/iF0cMphAsujaGKyAo+tA05K3nI0fdoeCx2wdEs vo8jIeeZVii07b3K9+VdJQmerVKJyMfQT6gLkyuassY/5aXlglNxAgMBAAGjggGHMIIBgzAO BgNVHQ8BAf8EBAMCBaAwTAYDVR0gBEUwQzBBBgkrBgEEAaAyASgwNDAyBggrBgEFBQcCARYm aHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8wHQYDVR0RBBYwFIESZ3Ji YXJ0bGVAY2lzY28uY29tMAkGA1UdEwQCMAAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUF BwMEMEMGA1UdHwQ8MDowOKA2oDSGMmh0dHA6Ly9jcmwuZ2xvYmFsc2lnbi5jb20vZ3MvZ3Nw ZXJzb25hbHNpZ24xZzIuY3JsMFUGCCsGAQUFBwEBBEkwRzBFBggrBgEFBQcwAoY5aHR0cDov L3NlY3VyZS5nbG9iYWxzaWduLmNvbS9jYWNlcnQvZ3NwZXJzb25hbHNpZ24xZzIuY3J0MB0G A1UdDgQWBBRBHvZ1Aur9AFGMEId10iH6yeUX3jAfBgNVHSMEGDAWgBTsrJjMJ3KTz1YyzSPH nY1FhfQiAzANBgkqhkiG9w0BAQUFAAOCAQEAdhq5YZv5ZCu0/HdQF1S3f+quesVc39HKv+Fe 2rmKuJcxfGOFZGpKhJDa1+sFeN/T+e2e6UJ0Yy90GLqi5U1fioD3XRhsFiVOh7CbJQESF2Xx U1bhdutZFh6Ythe28iRPY6HQjJ/7ke5IQBWvLnAbCIzgy0GgZB9Vj+a2z6bzmfR6KAuLaMqM vahvJ0w+DeHMEOVnVzCdZzHMaEOXZHw/uZj5/hGvkp2C0rH/LhGunfAPX12WhVQSsgxWJhaF 8D49Ymrt7PWBsLokx06/15XwY2ogBmfLmeN/WhMy5HUiLn3EnzwF+RK2MStCDpP5AWzdnrTR tM43+AJrHwoI7H+C9DCCBBYwggL+oAMCAQICCwQAAAAAAS9O4SzhMA0GCSqGSIb3DQEBBQUA MFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxTaWduIG52LXNhMRAwDgYDVQQLEwdS b290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJvb3QgQ0EwHhcNMTEwNDEzMTAwMDAwWhcN MTkwNDEzMTAwMDAwWjBUMQswCQYDVQQGEwJCRTEZMBcGA1UEChMQR2xvYmFsU2lnbiBudi1z YTEqMCgGA1UEAxMhR2xvYmFsU2lnbiBQZXJzb25hbFNpZ24gMSBDQSAtIEcyMIIBIjANBgkq hkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA8aUcr5BvPNGjx0+LH0uRqeZCHrYQ7KN3QuahfxY8 fAzAbnvNDzGdEMyKn3+YX+k/QbAGNJOSFRxrAfhviF7WGcqDlin3HracDqMRgwrknWuFeqxh N2J7uXs3Y0zluJEkEittRXv+ZdXOG/Gp3gtoz5P9noc5jBbfWQpQBhcaJA2ucABbUVTHDTxi 7dBY8mTWq6kRAkGWBybHwq0YX+jaHudtQw0oBEmxjpJFP9qIXu0ckU/+OhtnAhrgzrsd4oAy qgc6u4dBYERcjDJFohihjbzPozgKDSSbdr44uO3p9Bg6ibjCxn2besLrIE7upoxvV09Fsf7h DeD/jcvs64z8pQIDAQABo4HlMIHiMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/ AgEAMB0GA1UdDgQWBBTsrJjMJ3KTz1YyzSPHnY1FhfQiAzBHBgNVHSAEQDA+MDwGBFUdIAAw NDAyBggrBgEFBQcCARYmaHR0cHM6Ly93d3cuZ2xvYmFsc2lnbi5jb20vcmVwb3NpdG9yeS8w MwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5nbG9iYWxzaWduLm5ldC9yb290LmNybDAf BgNVHSMEGDAWgBRge2YaRQ2XyolQL30EzTSo//z9SzANBgkqhkiG9w0BAQUFAAOCAQEAr7un yEtmt9Ia7hmNpqP+xMd0t5hLM0QBY8G3Dlg70XI6F+ZeSZeeXgCtUT/JhdQ+HsJ8+c6HypDu vg/OZ0gILDFIa9LDfRWm+tHIgxKaJjtCy0izg838dLwwnt/O3kA9N/htEYev2lsmWYCV9cVU m5V1tW3XuYNg6SbtcDRH+Ki1RED9es3R0BgHSm012KPxsiAOOxuhm1D3Iqs1qe6ms5WTKXVg wb/j/kplOa13nshhc8zULVO+oAlD4+7czNK2RJiTvhJiDJDRTZy3DJ3BCQ8rXOGdWzDEI5ui B8TZ0s327g44Ylc6dgKgYelNn9RLYjNETX8OIJZlr0tFYpcYrDCCA3UwggJdoAMCAQICCwQA AAAAARVLWsOUMA0GCSqGSIb3DQEBBQUAMFcxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9i YWxTaWduIG52LXNhMRAwDgYDVQQLEwdSb290IENBMRswGQYDVQQDExJHbG9iYWxTaWduIFJv b3QgQ0EwHhcNOTgwOTAxMTIwMDAwWhcNMjgwMTI4MTIwMDAwWjBXMQswCQYDVQQGEwJCRTEZ MBcGA1UEChMQR2xvYmFsU2lnbiBudi1zYTEQMA4GA1UECxMHUm9vdCBDQTEbMBkGA1UEAxMS R2xvYmFsU2lnbiBSb290IENBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA2g7m mY3Oo+NPin778YuDJWvqSB/xKrC5lREEvfBj0eJnZs8c3c8bSCvujYmOmq8pgGWr6cctEsur HExwB6E9CjDNFY1P+N3UjFAVHO9Q7sQu9/zpUvKRfeBt1TUwjl5Dc/JB6dVq47KJOlY5OG8G PIhpWypNxadUuGyJzJv5PMrl/Yn1EjySeJbW3HRuk0Rh0Y3HRrJ1DoboGYrVbWzVeBaVounI Cjjr8iQTT3NUkxOFOhu8HjS1iwWMuXeLsdsfIJGrCVNukM57N3S5cEeRIlFjFnmusa5BJgjI GSvRRqpI1mQq14M0/ywqwWwZQ0oHhefTfPYhaO/q8lKff5OQzwIDAQABo0IwQDAOBgNVHQ8B Af8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHQ4EFgQUYHtmGkUNl8qJUC99BM00qP/8 /UswDQYJKoZIhvcNAQEFBQADggEBANZz53xPdtCNv+y6or40xSgytXz8bJwsK70JnlO/a16q EUi25Qijs8o9YU3TRgmzPsOg42NVG/K676054UO5OKPmL4omO++gUFb5xgr9OM3EC3BRlJeY BN/DX5TVFckUQZzEXXVkFQ3/VTDsho//De8suWNG9qr837xp/S4SSGSa4JXwpu8pjwGxFbUM HaX+aSxpJHges6cccWLuysiXrBddisL4R4ZuKsRWMZXQZ4mFK/lspl1GnQyqguSZUd1wt9tW PWHkauFc1vb+Pd5BzAeuY1K/U1P0K+nH/bb3gl+F0kEY24GzBBzFH6SAbxUgyd4MiAod1mZV 4vxIySkmaeAxggH+MIIB+gIBATBoMFQxCzAJBgNVBAYTAkJFMRkwFwYDVQQKExBHbG9iYWxT aWduIG52LXNhMSowKAYDVQQDEyFHbG9iYWxTaWduIFBlcnNvbmFsU2lnbiAxIENBIC0gRzIC EGZgT+TGYtW+XJFIXloecG0wDQYJYIZIAWUDBAIBBQCgaTAvBgkqhkiG9w0BCQQxIgQgpr6J +nvEofRgScjT0dK1oMD8s/GJi22cWue0G4gg86owGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEH ATAcBgkqhkiG9w0BCQUxDxcNMTQxMjA1MDg0NDM2WjANBgkqhkiG9w0BAQEFAASCAQAC44lV wp2jlYbtMfp34eXpZahAnJMH8zBHBDKV82CzifLuPWQFyv83I3XmmMZ8x7JH7oTtDrHAUjvg HNbh+3dT3ZhmTLHfvq7Ak54QqKfPute0sYIN7uD9zAHRVx35xF+rTjNHjgfAuyEmbvDAk57Q Ih8AXY5NmDI+nMr16Nz3EH/5TfMPaBCgH2KgYLl43UWzVeh973fBjnHEP8y6CeFp1xG7j00J TZjdore4uazd835wCWcVqk8hfKCm8TOxQaQHVffSwblDl499HOglUjty85u7fzURJ7hUx00S fxVKn1jsLF1sGljBQgW+eOxL8fQw1+XC4eulXCftTXnZV3eS --B_3500613876_16820177-- From nobody Fri Dec 5 01:22: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 3041E1ACDBF for ; Fri, 5 Dec 2014 01:22:44 -0800 (PST) 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 hHRFZ-NkA6hM for ; Fri, 5 Dec 2014 01:22:42 -0800 (PST) Received: from mail-wg0-x22d.google.com (mail-wg0-x22d.google.com [IPv6:2a00:1450:400c:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9E511A00FF for ; Fri, 5 Dec 2014 01:22:41 -0800 (PST) Received: by mail-wg0-f45.google.com with SMTP id b13so364661wgh.32 for ; Fri, 05 Dec 2014 01:22:40 -0800 (PST) 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=C+KnEVxYA3+7X+PigSSBOG5XXEofMpcWMEPJ0jua0C4=; b=R15hfUgbOJlFLQKMT2/mMXRc9eC5+XxWDk78BdUMU+xy2Jv3sB6W7nJPbSYSM4Yvip XW1RJHVDQLuF/17GNadw9eJ5vvwIBtVdotJtxsNX9yUGtvrmEFttxfQNcms7Irp1uf/f nb2LmdrVfltQ0lLqMOauXYtf5LayuxDx/8Du52J0daXBxTNQNZMSeFOmiQdgITtq9bAh Z5Alo+QVVmJ4eUn4WCWbhjUNRTCRyI5x1aeEYESTLfHNZheEdBbDX1HvGmWk7Uz6ftxr SKGqKy7UV6cR86oAGYR3VxD1Okqkbw3PHEvn2adOzOPppkcbqLH5XCgtB+A66pEeth15 8Usw== X-Received: by 10.194.246.167 with SMTP id xx7mr21293314wjc.118.1417771360591; Fri, 05 Dec 2014 01:22:40 -0800 (PST) Received: from [10.0.0.9] (bzq-79-176-33-71.red.bezeqint.net. [79.176.33.71]) by mx.google.com with ESMTPSA id e7sm44102658wjx.31.2014.12.05.01.22.39 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Dec 2014 01:22:40 -0800 (PST) Message-ID: <5481795E.4000706@gmail.com> Date: Fri, 05 Dec 2014 11:22:38 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Valery Smyslov , Yoav Nir , ipsec References: <410D9347-2DFF-42FE-A821-A177112BED0E@gmail.com> <5480C3A3.6040103@gmail.com> <1D725EE23AEE4AFD956F6B2BBF4F4C2F@buildpc> In-Reply-To: <1D725EE23AEE4AFD956F6B2BBF4F4C2F@buildpc> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/MaDmZ6pj7v-gEjtz_-q733_l130 Subject: Re: [IPsec] Some speculations about puzzles 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, 05 Dec 2014 09:22:44 -0000 >> And again for IKE_AUTH, I don't see why with fragmentation you need >> one puzzle solution per fragment. The major CPU cost (DH computation, >> certificate stuff and decryption) comes once, after the message is >> re-assembled. So it seems to me only one puzzle response is needed for >> the entire message. > > In this case the responder would become succeptible to the attack > when attacker emits forged fragments, that takes place of > good fragments from legitimate initiator in the reassembly queue. > To detect the forgery responder needs to check fragment > authenticity before inserting it into the reassembly queue. > That would require performing DH and calculating > SK_a*, but that is what we are willing to defer unless peer > proves that it is really really wants to setup connection and > is ready to spend quite a lot of resources to do it. > > It would be possible to protect with puzzle only the very > first fragment, because as we have calculated SK_a* > it takes very little resources to verify the other fragments, > but fragments can arrive in any order, so puzzle must be > in each fragment. That is a bit unfortunate for the initiator, I admit. > I get your point, but I think this is more than unfortunate, this is real ugly. RFC 7383 is primarily about IKE_AUTH, and now, in the case of those broken networks that limit the MTU, we are reducing the effective MTU yet again. But I think we're looking at the wrong problem. Let us look at why we might need to add puzzles to IKE_AUTH at all. There are two cases: - The IKE SA is set up by a valid initiator. - The IKE SA is set up by an attacker. In the first case, the responder needs to compute SKEYSEED anyway. It should compute it once and cache it, even if it sees multiple bogus IKE_AUTH messages sent by attackers. Verifying IKE_AUTH messages is cheap once SKEYSEED has been computed, because you only need to verify that the SK integrity protection is valid. The (valid) initiator "pays the price" once, in the form of an IKE_SA_INIT puzzle. In the second case, the attacker also pays the price if we have a puzzle attached to IKE_SA_INIT. And the responder only computes SKEYSEED once, and caches the result. Since SKEYSEED is known to the attacker, it can send valid SK payloads, and the responder is forced to validate the certificate (expensive). So attaching a puzzle to IKE_AUTH is justified, to make the attacker pay for each certificate validation. But this also shows that the IKE_SA_INIT puzzle is sufficient to counteract the cost of computing SKEYSEED (which is all you need for reassembly), and when even using fragmentation, this is only done once. Thanks, Yaron From nobody Fri Dec 5 05:18:58 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 42FD51ACE56 for ; Fri, 5 Dec 2014 05:18:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.17 X-Spam-Level: X-Spam-Status: No, score=0.17 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, 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 JBwDIqp-FsHi for ; Fri, 5 Dec 2014 05:18:54 -0800 (PST) Received: from mail-la0-x233.google.com (mail-la0-x233.google.com [IPv6:2a00:1450:4010:c03::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BAB221ACE32 for ; Fri, 5 Dec 2014 05:18:53 -0800 (PST) Received: by mail-la0-f51.google.com with SMTP id ms9so621266lab.24 for ; Fri, 05 Dec 2014 05:18:52 -0800 (PST) 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=jI8o0hPij3BCnm5HXhM5MQfhv3Z2UPmG3iouGS3jNr0=; b=rllMz9Oh17XPLEP7yFgX4FFqmDQDOrkRAEKHpkxxuUqAzPZRFQwjlbYhDo18ON/vFm xBM8G5ZZMMfcWYM1ZaZFIRWWQooYaKGFjBJIfN+T1D1XtQCO4s1pM/Utz3RqqTvNJsv9 QYLA1Pe2mGxSBkJaNWWeKYrhjUrrrK+ZDCMIJkd0CfC8fqm3qQf7IDXN2WNhlmhf/y7v RN6bTiIEpgGMdgq1q8VqnDu1IofIn8neRc6J5JeuEdYsfGIC1QDB/7NPalWGqEqsWCmA 5uWe7i+K1oWqwozC0dzhgaMxNupM24+qsyB3v/FORI9wW20dshGb2p8Y1qIaunjbVXk7 LvuA== X-Received: by 10.152.37.6 with SMTP id u6mr2933375laj.74.1417785532213; Fri, 05 Dec 2014 05:18:52 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id j19sm8327375lbl.23.2014.12.05.05.18.51 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Fri, 05 Dec 2014 05:18:51 -0800 (PST) Message-ID: <21AF0ED4C70C48159AAAC490CBE893A5@buildpc> From: "Valery Smyslov" To: "Yaron Sheffer" , "Yoav Nir" , "ipsec" References: <410D9347-2DFF-42FE-A821-A177112BED0E@gmail.com> <5480C3A3.6040103@gmail.com> <1D725EE23AEE4AFD956F6B2BBF4F4C2F@buildpc> <5481795E.4000706@gmail.com> Date: Fri, 5 Dec 2014 16:19:00 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="utf-8"; 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/c-0FwMjlrCetB_EIZpGdC6-e1lg Subject: Re: [IPsec] Some speculations about puzzles 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, 05 Dec 2014 13:18:55 -0000 > I get your point, but I think this is more than unfortunate, this is > real ugly. RFC 7383 is primarily about IKE_AUTH, and now, in the case of > those broken networks that limit the MTU, we are reducing the effective > MTU yet again. Not much, a dozen of bytes. > But I think we're looking at the wrong problem. Let us look at why we > might need to add puzzles to IKE_AUTH at all. There are two cases: > - The IKE SA is set up by a valid initiator. > - The IKE SA is set up by an attacker. > > In the first case, the responder needs to compute SKEYSEED anyway. It > should compute it once and cache it, even if it sees multiple bogus > IKE_AUTH messages sent by attackers. Verifying IKE_AUTH messages is > cheap once SKEYSEED has been computed, because you only need to verify > that the SK integrity protection is valid. The (valid) initiator "pays > the price" once, in the form of an IKE_SA_INIT puzzle. > > In the second case, the attacker also pays the price if we have a puzzle > attached to IKE_SA_INIT. And the responder only computes SKEYSEED once, > and caches the result. Since SKEYSEED is known to the attacker, it can > send valid SK payloads, and the responder is forced to validate the > certificate (expensive). So attaching a puzzle to IKE_AUTH is justified, > to make the attacker pay for each certificate validation. > > But this also shows that the IKE_SA_INIT puzzle is sufficient to > counteract the cost of computing SKEYSEED (which is all you need for > reassembly), and when even using fragmentation, this is only done once. I agree with your analysis. However I'm not sure I agree with conclusion. IKE_SA_INIT puzzle defends from exhausting responder's memory, while IKE_AUTH puzzle defends from exhausting CPU power. My primary concern is distributed DoS attack when attackers are indistinguishable from legitimate clients. In this case attacker does pay the price of IKE_SA_INIT puzzle, but after that it is free to attack responder's CPU by sending bogus messages or valid messages with bogus content. I agree, that once SKEYSEED is computed the bogus messages are easy to detect. However performing DH is relatively expensive for responder, while sending bogus message is free for attacker (once it has paid an "entrance fee"), that makes this attack attractive. Another option - sending valid messages with bogus auth content, that will require responder to do a lot of work. It will require from attacker to compute SKEYSEED, but the responder would have to spend much more resources, so the attack is also attractive. IKE_AUTH puzzle eliminates the first attack and makes the second expensive for attacker. IKE_AUTH puzzle is just a "second line of defense". You are probably right that we can get rid of it and raise the difficulty level of the "first line", but I'm not yet sure that we will gain an equal effect. Regards, Valery. > Thanks, > Yaron From nobody Fri Dec 5 05:52:00 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 C09921A03A2 for ; Fri, 5 Dec 2014 05:51:59 -0800 (PST) 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 OW0lJCg3RSKY for ; Fri, 5 Dec 2014 05:51:58 -0800 (PST) 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 C4A9B1A0395 for ; Fri, 5 Dec 2014 05:51:57 -0800 (PST) Received: by mail-wi0-f180.google.com with SMTP id n3so1451785wiv.7 for ; Fri, 05 Dec 2014 05:51:56 -0800 (PST) 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=ONHmVD2y7noigWVY2yEXZgkTtuKQftyoLiwKMycZo4U=; b=Xm7vrWJuzL4aVqEVMxW+aRsdVknVgLOFDI3UXKtGiUjhfK9HayLj4fdpeGe6OdFwxo ipDN/JQc1LnZlIfZdXX2GmXariaoqcrjYANIxfvkB8MCufZjiYWhENF+iwhIxvvrHGuw CMS4WkVHhZPJZu8xtuVYyty0Z86o27DIHv+kAmRkRdBw/l93NbCtHgSeNCi1gqcJRxWh x5G4coYgbs6igWtKDiNMLpSZKDBI/42OLMcLJg/jZknSBYm7cncfRMCLxVUeGV3w+AQ6 vmcKqgAl1H7SFfqu9jJkgUTi5H0GvjhFS7AlfxqqjniZPdO19+DtSfUXtuBpPVefohdV 4Ytg== X-Received: by 10.194.2.164 with SMTP id 4mr23645161wjv.55.1417787516604; Fri, 05 Dec 2014 05:51:56 -0800 (PST) Received: from [10.0.0.9] (bzq-79-176-33-71.red.bezeqint.net. [79.176.33.71]) by mx.google.com with ESMTPSA id td6sm2366756wic.15.2014.12.05.05.51.55 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Dec 2014 05:51:56 -0800 (PST) Message-ID: <5481B87A.3060603@gmail.com> Date: Fri, 05 Dec 2014 15:51:54 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Valery Smyslov , Yoav Nir , ipsec References: <410D9347-2DFF-42FE-A821-A177112BED0E@gmail.com> <5480C3A3.6040103@gmail.com> <1D725EE23AEE4AFD956F6B2BBF4F4C2F@buildpc> <5481795E.4000706@gmail.com> <21AF0ED4C70C48159AAAC490CBE893A5@buildpc> In-Reply-To: <21AF0ED4C70C48159AAAC490CBE893A5@buildpc> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/6VpOAF3dBR0Boo8VKmn6XHAeLQI Subject: Re: [IPsec] Some speculations about puzzles 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, 05 Dec 2014 13:52:00 -0000 >> But I think we're looking at the wrong problem. Let us look at why we >> might need to add puzzles to IKE_AUTH at all. There are two cases: >> - The IKE SA is set up by a valid initiator. >> - The IKE SA is set up by an attacker. >> >> In the first case, the responder needs to compute SKEYSEED anyway. It >> should compute it once and cache it, even if it sees multiple bogus >> IKE_AUTH messages sent by attackers. Verifying IKE_AUTH messages is >> cheap once SKEYSEED has been computed, because you only need to verify >> that the SK integrity protection is valid. The (valid) initiator "pays >> the price" once, in the form of an IKE_SA_INIT puzzle. >> >> In the second case, the attacker also pays the price if we have a >> puzzle attached to IKE_SA_INIT. And the responder only computes >> SKEYSEED once, and caches the result. Since SKEYSEED is known to the >> attacker, it can send valid SK payloads, and the responder is forced >> to validate the certificate (expensive). So attaching a puzzle to >> IKE_AUTH is justified, to make the attacker pay for each certificate >> validation. >> >> But this also shows that the IKE_SA_INIT puzzle is sufficient to >> counteract the cost of computing SKEYSEED (which is all you need for >> reassembly), and when even using fragmentation, this is only done once. > > I agree with your analysis. However I'm not sure I agree with conclusion. > > IKE_SA_INIT puzzle defends from exhausting responder's > memory, while IKE_AUTH puzzle defends from exhausting CPU power. > My primary concern is distributed DoS attack when attackers > are indistinguishable from legitimate clients. In this case attacker > does pay the price of IKE_SA_INIT puzzle, > but after that it is free to attack responder's CPU by > sending bogus messages or valid messages with bogus content. I agree, > that once SKEYSEED is computed > the bogus messages are easy to detect. However performing DH is > relatively expensive for responder, > while sending bogus message is free for attacker > (once it has paid an "entrance fee"), that makes this > attack attractive. Another option - sending valid messages with bogus > auth content, that will require > responder to do a lot of work. It will require from attacker > to compute SKEYSEED, but the responder would have to spend much more > resources, > so the attack is also attractive. IKE_AUTH puzzle > eliminates the first attack and makes the second expensive for attacker. > > IKE_AUTH puzzle is just a "second line of defense". > You are probably right that we can get rid of it > and raise the difficulty level of the "first line", > but I'm not yet sure that we will gain an equal effect. We are almost in agreement. My understanding is that both the IKE_SA_INIT and IKE_AUTH puzzles are needed, and each one has a different goal: - IKE_SA_INIT puzzle: should counteract the responder's memory cost of keeping the half-open SA, and its CPU cost in computing DH. - IKE_AUTH puzzle: should counteract the responder's CPU cost of validating the AUTH payload. Thanks, Yaron From nobody Sun Dec 7 08:49:11 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 926201A0161 for ; Sun, 7 Dec 2014 08:49:09 -0800 (PST) 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_40=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 yz8hcxWdK9CS for ; Sun, 7 Dec 2014 08:49:05 -0800 (PST) Received: from avasout04.plus.net (avasout04.plus.net [212.159.14.19]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 379691A1A28 for ; Sun, 7 Dec 2014 08:49:04 -0800 (PST) Received: from [192.168.1.2] ([80.229.245.222]) by avasout04 with smtp id Qgp11p0054odrNw01gp2Ak; Sun, 07 Dec 2014 16:49:03 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=ZuVjKrLG c=1 sm=1 tr=0 a=ZDAw9H2lLuf1cmfnewsGHg==:117 a=ZDAw9H2lLuf1cmfnewsGHg==:17 a=0Bzu9jTXAAAA:8 a=rkJuIV0pGx0A:10 a=apiPipScAAAA:8 a=r77TgQKjGQsHNAKrUKIA:9 a=9iDbn-4jx3cA:10 a=cKsnjEOsciEA:10 a=gZbpxnkM3yUA:10 a=pGLkceISAAAA:8 a=48vgC7mUAAAA:8 a=S23qzirf2DUCEhIsXE8A:9 a=9pebkfvBdF0O4ddF:21 a=297OS6Fe3tROfExR:21 a=QEXdDO2ut3YA:10 a=MbdWAfERoIja7esbfbsA:9 a=51z2oLpCQnO0aEKg:21 a=BngvHNLU_QC-pxF7:21 a=d5gSFIO1a75MYmMC:21 a=_W_S_7VecoQA:10 X-AUTH: putwet+t-ietf:2500 Message-ID: <548484EE.2020100@putwet.me.uk> Date: Sun, 07 Dec 2014 16:48:46 +0000 From: Tony Putman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: ipsec@ietf.org References: <2CBE2213-E3B6-4E0C-95EC-D1DFB05D3A0E@vpnc.org> <547E2CEB.3020200@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050703000605040009080904" Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/QzyvscMTeAidbHHWl9DAMTYKroY Subject: Re: [IPsec] Survey for WG interest in adopting draft-nagayama-ipsecme-ipsec-with-qkd 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, 07 Dec 2014 16:49:09 -0000 This is a multi-part message in MIME format. --------------050703000605040009080904 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Hi, I'm in favour of standardizing this work and am willing to review the document(s). I don't have a view on the best way to achieve this, but I think that the work would benefit from discussion on the list. There are a number of open questions in my mind, including the following: - Should this be QKD only, or PFS through generic OTP? - Should this use PAK-DH? (there is a stronger argument for it if this is about a generic solution) - Should there be a standardized structure to the Key ID? (Again, not needed for direct QKD) - What is the best way to derive the keying material? Tony On 02/12/14 22:49, Rodney Van Meter wrote: > Hi, > > Sorry to be a little slow to reply. I was offline over Thanksgiving, just saw the messages yesterday afternoon. > > Of course I favor adoption, and am willing to work with anyone who can contribute to the development of an appropriate protocol. Momentum seems to be toward a version supporting a variety of out-of-band mechanisms, and I’m willing to work in that direction. > > Shota is looking in to the numerous issues I detailed in the long message right after IETF. > > —Rod > >> On Dec 2, 2014, at 4:19 PM, Yaron Sheffer wrote: >> >> Here's a quick reminder to speak up if you're interested in this document and are willing to contribute as co-author or reviewer. >> >> Thanks, >> Yaron >> >> On 11/25/2014 10:06 PM, Paul Hoffman wrote: >>> >>> >>> Greetings again. There is a small emerging industry of crypto solutions that transmit keys using Quantum Key Distribution (QKD), and then use those keys for classical high-speed encryption. Several such solutions are using IKE, and there is a perceived need to standardize this usage. If so, that standardization should be done in this Working Group. >>> >>> If you agree with the need to standardize this usage, and believe that draft-nagayama-ipsecme-ipsec-with-qkd is likely to be a good starting place for that standardization, and are willing to review and contribute text to the document if it is adopted by the WG, please say so on the list. This WG has a history of adopting documents but then not having enough reviewers for us to feel confident that we are making a good standard, so we need to see a reasonable number of actively interested people before we adopt the document. If it is not adopted, the authors can ask for it to be published as an RFC through individual submission or by the Independent Submissions Editor. >>> >>> Please reply by December 8, 2015. >>> >>> --Paul Hoffman and Yaron Sheffer >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --------------050703000605040009080904 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit
Hi,

I'm in favour of standardizing this work and am willing to review the document(s). I don't have a view on the best way to achieve this, but I think that the work would benefit from discussion on the list. There are a number of open questions in my mind, including the following:
 - Should this be QKD only, or PFS through generic OTP?
 - Should this use PAK-DH? (there is a stronger argument for it if this is about a generic solution)
 - Should there be a standardized structure to the Key ID? (Again, not needed for direct QKD)
 - What is the best way to derive the keying material?

Tony

On 02/12/14 22:49, Rodney Van Meter wrote:
Hi,

Sorry to be a little slow to reply.  I was offline over Thanksgiving, just saw the messages yesterday afternoon.

Of course I favor adoption, and am willing to work with anyone who can contribute to the development of an appropriate protocol.  Momentum seems to be toward a version supporting a variety of out-of-band mechanisms, and I’m willing to work in that direction.

Shota is looking in to the numerous issues I detailed in the long message right after IETF.

		—Rod


On Dec 2, 2014, at 4:19 PM, Yaron Sheffer <yaronf.ietf@gmail.com> wrote:

Here's a quick reminder to speak up if you're interested in this document and are willing to contribute as co-author or reviewer.

Thanks,
	Yaron

On 11/25/2014 10:06 PM, Paul Hoffman wrote:

<chair hats on>

Greetings again. There is a small emerging industry of crypto solutions that transmit keys using Quantum Key Distribution (QKD), and then use those keys for classical high-speed encryption. Several such solutions are using IKE, and there is a perceived need to standardize this usage. If so, that standardization should be done in this Working Group.

If you agree with the need to standardize this usage, and believe that draft-nagayama-ipsecme-ipsec-with-qkd is likely to be a good starting place for that standardization, and are willing to review and contribute text to the document if it is adopted by the WG, please say so on the list. This WG has a history of adopting documents but then not having enough reviewers for us to feel confident that we are making a good standard, so we need to see a reasonable number of actively interested people before we adopt the document. If it is not adopted, the authors can ask for it to be published as an RFC through individual submission or by the Independent Submissions Editor.

Please reply by December 8, 2015.

--Paul Hoffman and Yaron Sheffer
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

--------------050703000605040009080904-- From nobody Sun Dec 7 09:25:03 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 8C77D1A87A1 for ; Sun, 7 Dec 2014 09:25:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 PPhw_SLDpMYb for ; Sun, 7 Dec 2014 09:25:00 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5A461A879F for ; Sun, 7 Dec 2014 09:24:59 -0800 (PST) Received: from [10.0.1.5] (108-218-233-35.lightspeed.sntcca.sbcglobal.net [108.218.233.35]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 080E72780E2; Mon, 8 Dec 2014 02:24:56 +0900 (JST) Content-Type: multipart/alternative; boundary="Apple-Mail=_3451CF02-38F3-42EC-8769-3D4DA1B68CE7" Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Rodney Van Meter In-Reply-To: <548484EE.2020100@putwet.me.uk> Date: Sun, 7 Dec 2014 09:24:53 -0800 Message-Id: <5D08B62E-A53D-4317-B530-541958777737@sfc.wide.ad.jp> References: <2CBE2213-E3B6-4E0C-95EC-D1DFB05D3A0E@vpnc.org> <547E2CEB.3020200@gmail.com> <548484EE.2020100@putwet.me.uk> To: Tony Putman X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/Cvkw1PcJI162CQ6gQnHLpPJgiok Cc: Rodney Van Meter , ipsec@ietf.org Subject: Re: [IPsec] Survey for WG interest in adopting draft-nagayama-ipsecme-ipsec-with-qkd 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, 07 Dec 2014 17:25:02 -0000 --Apple-Mail=_3451CF02-38F3-42EC-8769-3D4DA1B68CE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Dec 7, 2014, at 8:48 AM, Tony Putman wrote: >=20 > Hi, >=20 > I'm in favour of standardizing this work and am willing to review the = document(s). I don't have a view on the best way to achieve this, but I = think that the work would benefit from discussion on the list. There are = a number of open questions in my mind, including the following: > - Should this be QKD only, or PFS through generic OTP? Keep in mind that at this point we are only modifying IKE=E2=80=99s = process of generating keys. The bulk encryption is still dependent on = AES or whatever algorithm you negotiate. However, OTP keys with short = lifetimes is a good balance between aggregate data rate and the rate of = consumption of key material, and is an excellent analogue for how = QKD-generated keys should be thought of, IMO. > - Should this use PAK-DH? (there is a stronger argument for it if = this is about a generic solution) Open to advice here. If I understand what you=E2=80=99re suggesting, I = think not. > - Should there be a standardized structure to the Key ID? (Again, not = needed for direct QKD) I think the best suggestion on the table here is to *not* standardize = that, but to include an annex or appendix in the RFC describing use = cases, of which the first would be how we use them in QKD. This allows = for different ideas of generation, including whether or not you need to = name the node, interface, even port as the context in which a numeric = key ID is to be interpreted. That would be very different for couriered = OTP, where it=E2=80=99s probably =E2=80=9Cpouch number=E2=80=9D+=E2=80=9Do= ffset inside pouch=E2=80=9D. > - What is the best way to derive the keying material? Tero and a couple of others had opinions here. =E2=80=94Rod >=20 > Tony >=20 > On 02/12/14 22:49, Rodney Van Meter wrote: >> Hi, >>=20 >> Sorry to be a little slow to reply. I was offline over Thanksgiving, = just saw the messages yesterday afternoon. >>=20 >> Of course I favor adoption, and am willing to work with anyone who = can contribute to the development of an appropriate protocol. Momentum = seems to be toward a version supporting a variety of out-of-band = mechanisms, and I=E2=80=99m willing to work in that direction. >>=20 >> Shota is looking in to the numerous issues I detailed in the long = message right after IETF. >>=20 >> =E2=80=94Rod >>=20 >>> On Dec 2, 2014, at 4:19 PM, Yaron Sheffer = wrote: >>>=20 >>> Here's a quick reminder to speak up if you're interested in this = document and are willing to contribute as co-author or reviewer. >>>=20 >>> Thanks, >>> Yaron >>>=20 >>> On 11/25/2014 10:06 PM, Paul Hoffman wrote: >>>> >>>>=20 >>>> Greetings again. There is a small emerging industry of crypto = solutions that transmit keys using Quantum Key Distribution (QKD), and = then use those keys for classical high-speed encryption. Several such = solutions are using IKE, and there is a perceived need to standardize = this usage. If so, that standardization should be done in this Working = Group. >>>>=20 >>>> If you agree with the need to standardize this usage, and believe = that draft-nagayama-ipsecme-ipsec-with-qkd is likely to be a good = starting place for that standardization, and are willing to review and = contribute text to the document if it is adopted by the WG, please say = so on the list. This WG has a history of adopting documents but then not = having enough reviewers for us to feel confident that we are making a = good standard, so we need to see a reasonable number of actively = interested people before we adopt the document. If it is not adopted, = the authors can ask for it to be published as an RFC through individual = submission or by the Independent Submissions Editor. >>>>=20 >>>> Please reply by December 8, 2015. >>>>=20 >>>> --Paul Hoffman and Yaron Sheffer >>>> _______________________________________________ >>>> 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 = >> _______________________________________________ >> 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 --Apple-Mail=_3451CF02-38F3-42EC-8769-3D4DA1B68CE7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On Dec 7, 2014, at 8:48 AM, Tony Putman <t-ietf@putwet.me.uk>= wrote:

=20 =20
Hi,

I'm in favour of standardizing this work and am willing to review the document(s). I don't have a view on the best way to achieve this, but I think that the work would benefit from discussion on the list. There are a number of open questions in my mind, including the following:
 - Should this be QKD only, or PFS through generic OTP?


Keep in mind that at = this point we are only modifying IKE=E2=80=99s process of generating = keys.  The bulk encryption is still dependent on AES or whatever = algorithm you negotiate.  However, OTP keys with short lifetimes is = a good balance between aggregate data rate and the rate of consumption = of key material, and is an excellent analogue for how QKD-generated keys = should be thought of, IMO.

 - Should this use PAK-DH? (there is a stronger argument = for it if this is about a generic solution)

Open to advice here.  If I understand what = you=E2=80=99re suggesting, I think not.

 - Should there be a standardized structure to the Key ID? (Again, not needed for direct QKD)

I think the best suggestion on the table here is to = *not* standardize that, but to include an annex or appendix in the RFC = describing use cases, of which the first would be how we use them in = QKD.  This allows for different ideas of generation, including = whether or not you need to name the node, interface, even port as the = context in which a numeric key ID is to be interpreted.  That would = be very different for couriered OTP, where it=E2=80=99s probably = =E2=80=9Cpouch number=E2=80=9D+=E2=80=9Doffset inside = pouch=E2=80=9D.

 - What is the best way to derive the keying material?

Tero and a couple of others had opinions = here.

=E2=80=94Rod


Tony

On 02/12/14 22:49, Rodney Van Meter wrote:
Hi,

Sorry to be a little slow to reply.  I was offline over Thanksgiving, =
just saw the messages yesterday afternoon.

Of course I favor adoption, and am willing to work with anyone who can =
contribute to the development of an appropriate protocol.  Momentum =
seems to be toward a version supporting a variety of out-of-band =
mechanisms, and I=E2=80=99m willing to work in that direction.

Shota is looking in to the numerous issues I detailed in the long =
message right after IETF.

		=E2=80=94Rod


On Dec 2, 2014, at 4:19 PM, Yaron =
Sheffer <yaronf.ietf@gmail.com> =
wrote:

Here's a quick reminder to speak up if you're interested in this =
document and are willing to contribute as co-author or reviewer.

Thanks,
	Yaron

On 11/25/2014 10:06 PM, Paul Hoffman wrote:

<chair hats on>

Greetings again. There is a small emerging industry of crypto solutions =
that transmit keys using Quantum Key Distribution (QKD), and then use =
those keys for classical high-speed encryption. Several such solutions =
are using IKE, and there is a perceived need to standardize this usage. =
If so, that standardization should be done in this Working Group.

If you agree with the need to standardize this usage, and believe that =
draft-nagayama-ipsecme-ipsec-with-qkd is likely to be a good starting =
place for that standardization, and are willing to review and contribute =
text to the document if it is adopted by the WG, please say so on the =
list. This WG has a history of adopting documents but then not having =
enough reviewers for us to feel confident that we are making a good =
standard, so we need to see a reasonable number of actively interested =
people before we adopt the document. If it is not adopted, the authors =
can ask for it to be published as an RFC through individual submission =
or by the Independent Submissions Editor.

Please reply by December 8, 2015.

--Paul Hoffman and Yaron Sheffer
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/=
mailman/listinfo/ipsec


_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/=
mailman/listinfo/ipsec

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/=
mailman/listinfo/ipsec

_______________________________________________
IPsec = mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

= --Apple-Mail=_3451CF02-38F3-42EC-8769-3D4DA1B68CE7-- From nobody Sun Dec 7 10:09: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 A1DB91A87EB for ; Sun, 7 Dec 2014 10:09:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] 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 hsFbxIbOZqNF for ; Sun, 7 Dec 2014 10:09:07 -0800 (PST) Received: from avasout04.plus.net (avasout04.plus.net [212.159.14.19]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB89E1A039B for ; Sun, 7 Dec 2014 10:09:05 -0800 (PST) Received: from [192.168.1.2] ([80.229.245.222]) by avasout04 with smtp id Qi901p0044odrNw01i91qX; Sun, 07 Dec 2014 18:09:03 +0000 X-CM-Score: 0.00 X-CNFS-Analysis: v=2.1 cv=ZuVjKrLG c=1 sm=1 tr=0 a=ZDAw9H2lLuf1cmfnewsGHg==:117 a=ZDAw9H2lLuf1cmfnewsGHg==:17 a=0Bzu9jTXAAAA:8 a=rkJuIV0pGx0A:10 a=IkcTkHD0fZMA:10 a=apiPipScAAAA:8 a=zhk4h2hAjqsBM_yw3Z0A:9 a=QEXdDO2ut3YA:10 X-AUTH: putwet+t-ietf:2500 Message-ID: <548497AD.2050605@putwet.me.uk> Date: Sun, 07 Dec 2014 18:08:45 +0000 From: Tony Putman User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.2.0 MIME-Version: 1.0 To: Rodney Van Meter References: <2CBE2213-E3B6-4E0C-95EC-D1DFB05D3A0E@vpnc.org> <547E2CEB.3020200@gmail.com> <548484EE.2020100@putwet.me.uk> <5D08B62E-A53D-4317-B530-541958777737@sfc.wide.ad.jp> In-Reply-To: <5D08B62E-A53D-4317-B530-541958777737@sfc.wide.ad.jp> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/qe1X6ntMEouO5SAeEFIBD2Ujs_s Cc: ipsec@ietf.org Subject: Re: [IPsec] Survey for WG interest in adopting draft-nagayama-ipsecme-ipsec-with-qkd 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, 07 Dec 2014 18:09:10 -0000 OK, I admit my previous email was a bit short on detail :-) On 07/12/14 17:24, Rodney Van Meter wrote: >> - Should this use PAK-DH? (there is a stronger argument for it if >> this is about a generic solution) > > Open to advice here. If I understand what you’re suggesting, I think not. > What I meant was that if we only consider a direct QKD link between the endpoints, then the keys are (theoretically) completely secure. But if we are considering other methods of sharing these keys, then there is an additional D-H barrier for an attacker to overcome if PAK-DH is used. Of course, there is also additional computation needed, so there is a trade-off. I think that it's worth discussing the trade-off on the list. >> - Should there be a standardized structure to the Key ID? (Again, >> not needed for direct QKD) > > I think the best suggestion on the table here is to *not* standardize > that, but to include an annex or appendix in the RFC describing use > cases, of which the first would be how we use them in QKD. This > allows for different ideas of generation, including whether or not you > need to name the node, interface, even port as the context in which a > numeric key ID is to be interpreted. That would be very different for > couriered OTP, where it’s probably “pouch numberâ€+â€offset inside pouchâ€. > I feel that the right thing to do here is to include a one-byte KEY_ID_TYPE, and at this stage to only define a single value (OPAQUE). This give scope to specialize it if necessary without needing any further changes to the protocol. It is difficult to know how this is going to be used, so I am in favour of keeping some flexibility (within reason, of course). Tony From nobody Sun Dec 7 18:45:01 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 8D5F11A1B4F for ; Sun, 7 Dec 2014 18:45:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.71 X-Spam-Level: X-Spam-Status: No, score=-1.71 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, MIME_8BIT_HEADER=0.3, T_RP_MATCHES_RCVD=-0.01] 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 1MQijOVUSFAW for ; Sun, 7 Dec 2014 18:44:59 -0800 (PST) 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 1C4211A1A7D for ; Sun, 7 Dec 2014 18:44:59 -0800 (PST) Received: from bofh.nohats.ca (bofh.nohats.ca [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 63A22817C1; Sun, 7 Dec 2014 21:44:56 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1418006696; bh=KzM2VenTQcIhC5qRZPpM39OM+75Zzi4iGu/yQLOHJak=; h=Date:From:To:cc:Subject:In-Reply-To:References; b=FvlX9uVdGZp3g9/Vb78+LaqL9yg89rzrX68QAr7sltAAI0QIfx+xkLY85f4qz1yO7 NADIBV9RA2bhU/Oydg5OkoxIiy/WasfgvGgClEZEbZHeBL14Diplvo3AogK/Z+UB57 K1URbOSJ1yoQ7UUC34z+ll9cM0oSSdjr0Dl8IklA= Received: from localhost (paul@localhost) by bofh.nohats.ca (8.14.7/8.14.7/Submit) with ESMTP id sB82itHm019358; Sun, 7 Dec 2014 21:44:55 -0500 X-Authentication-Warning: bofh.nohats.ca: paul owned process doing -bs Date: Sun, 7 Dec 2014 21:44:55 -0500 (EST) From: =?UTF-8?Q?Paul_Wouters_=F0=9F=94=93?= To: Tony Putman In-Reply-To: <548484EE.2020100@putwet.me.uk> Message-ID: References: <2CBE2213-E3B6-4E0C-95EC-D1DFB05D3A0E@vpnc.org> <547E2CEB.3020200@gmail.com> <548484EE.2020100@putwet.me.uk> User-Agent: Alpine 2.10 (LFD 1266 2009-07-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=utf-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/UG4kzwQZxzgUlsr74sWHLcI2fMU Cc: ipsec@ietf.org Subject: Re: [IPsec] Survey for WG interest in adopting draft-nagayama-ipsecme-ipsec-with-qkd 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, 08 Dec 2014 02:45:00 -0000 On Sun, 7 Dec 2014, Tony Putman wrote: >  - Should this be QKD only, or PFS through generic OTP? My preference would be that this would be usable for generic OTP as well. It could be used in practise, and it would allow implementors to be able to keep the code tested without needing to own expensive equipment. Paul From nobody Tue Dec 9 02:59:17 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 94A091A1B13 for ; Tue, 9 Dec 2014 02:59:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.609 X-Spam-Level: X-Spam-Status: No, score=0.609 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 keObFEknJc-q for ; Tue, 9 Dec 2014 02:59:10 -0800 (PST) Received: from mail-lb0-x22c.google.com (mail-lb0-x22c.google.com [IPv6:2a00:1450:4010:c04::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C95A1A1B18 for ; Tue, 9 Dec 2014 02:59:09 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id u10so283497lbd.3 for ; Tue, 09 Dec 2014 02:59:08 -0800 (PST) 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=FDFmSvgXwxGSt1lak9N9fc6EOxP0U60AoxlpggPHkIY=; b=iRNh+ERlVb4GyZOPyjUo1QrtU9rPZPomRec+9kMP7/sH1JXy9ssegx9wThwguyhhBh WTQj/Ne9dN+6WbfPmdcqmDa7ibzv1N5gl3IicnXa8nbbKe4swOfM6zcyiPy8nzTFjf2y IMIuBD96WsNH1GsTv8+USl88DQ+gF3BOttskTVSndZ3KqgZmnbJdHwNdMbNKXKWyTIGi tKtEZw0GwOSpPcQsdkhMK4lEkuQxm3+59+J+fnzRbv0C3o5lObX4d3jduwxnavWLp6aZ z60d18BIxDdBWaC64JRgGcoygEIcNNJUHCS+r/QjWJzPppPkntY+apYokP1RWmrwStyZ NSUA== X-Received: by 10.152.5.132 with SMTP id s4mr21171545las.39.1418122748108; Tue, 09 Dec 2014 02:59:08 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id or5sm260376lbb.42.2014.12.09.02.59.07 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Dec 2014 02:59:07 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Paul Hoffman" , "IPsecME WG" References: <2CBE2213-E3B6-4E0C-95EC-D1DFB05D3A0E@vpnc.org> Date: Tue, 9 Dec 2014 13:59:16 +0300 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/gAbIV55i83CoAW7hwgJBYaPWiSU Subject: Re: [IPsec] Survey for WG interest in adopting draft-nagayama-ipsecme-ipsec-with-qkd 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, 09 Dec 2014 10:59:11 -0000 Hi, I thought that I was a late, as today is already December 9, but then I've noticed, that the survey is untill December 8, 2015 :-) So I still have some time to express my opinion. I think that the document in its current form looks like it is screwing IKE. It leaves a lot of questions why it is done that way and not another, more convinient, way. I think, that not many of active members of ipsecme WG are experts in quantum computing (I definitely not), but all of them are experts in IKE. And I think that they could help authors to define the extension so, that it would not look like improper use of the protocol. So, the draft definitely needs more review from ipsecme WG. And thus - either adopt it (although I think that the technology itself is a bit premature and not widely used), or, preferrably, give it an individual submission with closer look from ipsecme WG. And I prefer it to have experimental status. Regards, Valery Smyslov. > > > Greetings again. There is a small emerging industry of crypto solutions > that transmit keys using Quantum Key Distribution (QKD), and then use > those keys for classical high-speed encryption. Several such solutions are > using IKE, and there is a perceived need to standardize this usage. If so, > that standardization should be done in this Working Group. > > If you agree with the need to standardize this usage, and believe that > draft-nagayama-ipsecme-ipsec-with-qkd is likely to be a good starting > place for that standardization, and are willing to review and contribute > text to the document if it is adopted by the WG, please say so on the > list. This WG has a history of adopting documents but then not having > enough reviewers for us to feel confident that we are making a good > standard, so we need to see a reasonable number of actively interested > people before we adopt the document. If it is not adopted, the authors can > ask for it to be published as an RFC through individual submission or by > the Independent Submissions Editor. > > Please reply by December 8, 2015. > > --Paul Hoffman and Yaron Sheffer > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Dec 9 03:01:37 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 E47A41A1AE8 for ; Tue, 9 Dec 2014 03:01:35 -0800 (PST) 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 dKY9jJV9t5Lv for ; Tue, 9 Dec 2014 03:01:34 -0800 (PST) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3A6D1A1A93 for ; Tue, 9 Dec 2014 03:01:33 -0800 (PST) Received: by mail-wi0-f181.google.com with SMTP id r20so1273344wiv.2 for ; Tue, 09 Dec 2014 03:01:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=xh8rtEodvTFo0C1G7BjgYKg7i8EKSWOXk9UzIrxCYdI=; b=jwaV+5rEujm/OzmIKQ7ooHGKxJmb97sP69Ns4sQHBtYN10ZKhtr5dFewRCf0xv7HqN 7zpav6em005jl1jFMvyQElDYEwolNrjfwN0YbAuAQkxU0i6AXyh/Ftvs59x05VebvQql jGADq51siZpw23BC/krHsWyfwuvX3IaEZ83T6uQUv2Z8Fxad/55AH/iVOGD9ZaZj7nxW O8bk8snIuKKLT381Y54HKN+lG47405o5nTOEUALyv3gp30x3/PeZ9UmR8QNIpg9rV52a sfZCWUAuZ96E4PMZOI3f+Hjclq5PkaRQ+W57pM69DMgkgbTQThoj15Q+CoqGV+u9WGfZ K1Ow== MIME-Version: 1.0 X-Received: by 10.180.198.164 with SMTP id jd4mr30863756wic.42.1418122892614; Tue, 09 Dec 2014 03:01:32 -0800 (PST) Received: by 10.194.236.106 with HTTP; Tue, 9 Dec 2014 03:01:32 -0800 (PST) In-Reply-To: <547E2D21.2070600@gmail.com> References: <547E2D21.2070600@gmail.com> Date: Tue, 9 Dec 2014 12:01:32 +0100 Message-ID: From: Daniel Migault To: Yaron Sheffer Content-Type: multipart/alternative; boundary=047d7b60470643205e0509c67724 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/J4k6W3qrAJHvKscaRSAKkVvv2KA Cc: IPsecME WG , Paul Hoffman Subject: Re: [IPsec] Survey for WG interest in adopting draft-mglt-ipsecme-clone-ike-sa 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, 09 Dec 2014 11:01:36 -0000 --047d7b60470643205e0509c67724 Content-Type: text/plain; charset=UTF-8 Hi, As a co-author of the draft I am of course supporting the draft and will contribute to it. BR, Daniel On Tue, Dec 2, 2014 at 10:20 PM, Yaron Sheffer wrote: > And similarly for this draft: please speak up if you're interested in this > document and are willing to contribute as co-author or reviewer. > > Thanks, > Yaron > > > On 11/25/2014 10:06 PM, Paul Hoffman wrote: > >> >> >> Greetings again. The "Clone IKE SA" proposal tries to optimize IKE SA >> setup in cases where VPN gateways have multiple interfaces and want to >> establish different SAs on the different interfaces without having to >> repeat the IKE authentication. Instead, they could clone a single IKE SA >> multiple times, and then move it to different interfaces using MOBIKE. >> >> If you agree with the need to standardize this usage, and believe that >> draft-mglt-ipsecme-clone-ike-sa is likely to be a good starting place >> for that standardization, and are willing to review and contribute text to >> the document if it is adopted by the WG, please say so on the list. This WG >> has a history of adopting documents but then not having enough reviewers >> for us to feel confident that we are making a good standard, so we need to >> see a reasonable number of actively interested people before we adopt the >> document. If it is not adopted, the authors can ask for it to be published >> as an RFC through individual submission or by the Independent Submissions >> Editor. >> >> Please reply by December 8, 2015. >> >> --Paul Hoffman and Yaron Sheffer >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 --047d7b60470643205e0509c67724 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

As a co-author of the dra= ft I am of course supporting the draft and will contribute to it.

BR,
Daniel

On Tue, Dec 2, 2014 at 10:20 PM, Yaron Sheffer <yar= onf.ietf@gmail.com> wrote:
= And similarly for this draft: please speak up if you're interested in t= his document and are willing to contribute as co-author or reviewer.

Thanks,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 Yaron

On 11/25/2014 10:06 PM, Paul Hoffman wrote:
<chair hats on>

Greetings again. The "Clone IKE SA" proposal tries to optimize IK= E SA setup in cases where VPN gateways have multiple interfaces and want to= establish different SAs on the different interfaces without having to repe= at the IKE authentication. Instead, they could clone a single IKE SA multip= le times, and then move it to different interfaces using MOBIKE.

If you agree with the need to standardize this usage, and believe that draf= t-mglt-ipsecme-clone-ike-sa is likely to be a good starting place fo= r that standardization, and are willing to review and contribute text to th= e document if it is adopted by the WG, please say so on the list. This WG h= as a history of adopting documents but then not having enough reviewers for= us to feel confident that we are making a good standard, so we need to see= a reasonable number of actively interested people before we adopt the docu= ment. If it is not adopted, the authors can ask for it to be published as a= n RFC through individual submission or by the Independent Submissions Edito= r.

Please reply by December 8, 2015.

--Paul Hoffman and Yaron Sheffer
_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec


_______________________________________________
IPsec mailing list
IPsec@ietf.org
h= ttps://www.ietf.org/mailman/listinfo/ipsec



--
Daniel Migault
Orange Labs -- Security
+33 6 70 = 72 69 58
--047d7b60470643205e0509c67724-- From nobody Tue Dec 9 04:41:46 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 907E91A0363 for ; Tue, 9 Dec 2014 04:41:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.909 X-Spam-Level: * X-Spam-Status: No, score=1.909 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, RCVD_IN_SORBS_WEB=0.77, SPF_PASS=-0.001, STOX_REPLY_TYPE=0.439] 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 Ji4n2pB9zYIB for ; Tue, 9 Dec 2014 04:41:43 -0800 (PST) Received: from mail-lb0-x234.google.com (mail-lb0-x234.google.com [IPv6:2a00:1450:4010: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 3F1A21A0217 for ; Tue, 9 Dec 2014 04:41:43 -0800 (PST) Received: by mail-lb0-f180.google.com with SMTP id l4so398525lbv.25 for ; Tue, 09 Dec 2014 04:41:41 -0800 (PST) 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=jXs/vNMkEB/VD+KQpNei70JIGvQx/kD+6Lp3LdBw4zI=; b=IK9wK1sQ4KMR6bj+lmM+gUZ10doakkTe1MU2TQitkKh2nbF+tk5w6OSC+3OYzE0fkr iQVBwT0mD9GrOlBcFrbiLc40dpd1Hpkths7kU/QBi5N5qsMQ9BYo7tNj0mA6hjX+Op4P EHr5KgjuOs7QmwWNojsmacyFLSW+2FUC0IzSeo4F9cmOSUb6g35FZZSEqeFKgpgtyYdW RJi982WQ4qVUOy5+hlJB6X9vu33zleY7CpLAw3Zp2KU/7kBe+EXsvfV6Bx5Ntk/3461U 4TYba0N+4AflaThckOaQKN1R5/hCxwH4Ohdm8uvpHqDT1nzLQpsk0PlnSwgLtH5RktCg yNbQ== X-Received: by 10.112.144.228 with SMTP id sp4mr21204180lbb.58.1418128901728; Tue, 09 Dec 2014 04:41:41 -0800 (PST) Received: from buildpc ([82.138.51.4]) by mx.google.com with ESMTPSA id zc5sm324734lbb.49.2014.12.09.04.41.40 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Dec 2014 04:41:41 -0800 (PST) Message-ID: <1C87F17FE5D044A7ADE2D2E6CBD0333C@buildpc> From: "Valery Smyslov" To: "Yaron Sheffer" , "Yoav Nir" , "ipsec" References: <410D9347-2DFF-42FE-A821-A177112BED0E@gmail.com> <5480C3A3.6040103@gmail.com> <1D725EE23AEE4AFD956F6B2BBF4F4C2F@buildpc> <5481795E.4000706@gmail.com> <21AF0ED4C70C48159AAAC490CBE893A5@buildpc> <5481B87A.3060603@gmail.com> Date: Tue, 9 Dec 2014 15:41:51 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="UTF-8"; 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/oyGCPt9IrT1YscIu16cOlQcAfJ4 Subject: Re: [IPsec] Some speculations about puzzles 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, 09 Dec 2014 12:41:44 -0000 Hi Yaron, > We are almost in agreement. My understanding is that both the > IKE_SA_INIT and IKE_AUTH puzzles are needed, and each one has a > different goal: > > - IKE_SA_INIT puzzle: should counteract the responder's memory cost of > keeping the half-open SA, and its CPU cost in computing DH. > > - IKE_AUTH puzzle: should counteract the responder's CPU cost of > validating the AUTH payload. Thank you, now I better understand your position. Let me rephrase it. You propose that IKE_AUTH puzzle resides inside SK payload and its verifications takes place after computing DH and verifying authenticity of IKE_AUTH messag, but before any actionts dealing with peer authentication take place. Am I right? This will allow attacker to perform an attack on responder's CPU power by sending single garbage message in IKE_AUTH, which will be partially counteracted by IKE_SA_INIT puzzle. But this will definitely ease legitimate client's burden in case of IKE fragmentation. I still prefer IKE_AUTH puzzle to reside outside SK payload and to be verified before performing DH and computing SKEYSEED. However, after some thoughts, I think that in case of IKE fragmentation, puzzle must only present in the very first fragment (outside SKF payload), not in the every fragment, as I proposed before. The responder in this case will pay no attention on the other fragments untill it receives the first one and verifies the puzzle. Fragments that were received before this event could be dropped (in a hope that they will be eventually retransmitted) or just collected with no action. In the latter case after the puzzle is vefified and DH is computed all the collected fragments must be verified for theit authenticity. This approach would still require legitimate client to re-solve puzzle in case it first sends unfragmented message and then switches IP fragmentation on (or in case it refragments the message with smaller MTU), but it would provide better defense against attacks on CPU exhausting in IKE_AUTH. Regards, Valery. From nobody Fri Dec 12 10:08:53 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 1EEDC1A8730 for ; Fri, 12 Dec 2014 10:08:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] 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 w6Dyb8KOWOuw for ; Fri, 12 Dec 2014 10:08:41 -0800 (PST) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (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 A27691A8723 for ; Fri, 12 Dec 2014 10:08:41 -0800 (PST) Received: from [10.20.30.90] (142-254-17-119.dsl.dynamic.fusionbroadband.com [142.254.17.119]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id sBCI8eMd064077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Dec 2014 11:08:41 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 142-254-17-119.dsl.dynamic.fusionbroadband.com [142.254.17.119] claimed to be [10.20.30.90] From: Paul Hoffman Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Message-Id: Date: Fri, 12 Dec 2014 10:08:40 -0800 To: IPsecME WG Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/LvAeh6_vQUQYwZ8_PD6FgTgWZxI Subject: [IPsec] Calls for adoption: wrap-up 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, 12 Dec 2014 18:08:43 -0000 Greetings. A few weeks ago, we started summaries for adoption by the WG = of two drafts: draft-nagayama-ipsecme-ipsec-with-qkd and = draft-mglt-ipsecme-clone-ike-sa. This message concludes that there is = not sufficient interest in the WG (that is, enough people who will = actively contribute to the draft progression) for either draft to be = advance successfully. Both drafts had some interest from people other than the authors, but it = seemed like a fair amount of that was defensive; that is, those people = were willing to work on the document, but mostly to prevent bad design, = not because they supported the use case. Given that, if the authors of = either decide to pursue publication, it would be great if they reached = out to all the people on the list who expressed opinions and try to = incorporate those before moving forwards. Notes about new versions of = these drafts (and other non-WG drafts) are still welcome on the list as = long as they do not disrupt the ongoing WG work. --Paul Hoffman= From nobody Fri Dec 12 10:50: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 DC2631AC40E for ; Fri, 12 Dec 2014 10:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.008 X-Spam-Level: X-Spam-Status: No, score=-97.008 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] 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 wU_W6P90N7_V for ; Fri, 12 Dec 2014 10:50:41 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 703731A907D for ; Fri, 12 Dec 2014 10:50:38 -0800 (PST) Received: from vanmetedneysmbp.wireless.duke.local (west-4b-pat-1.oit.duke.edu [152.3.43.164]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 069162781B5; Sat, 13 Dec 2014 03:50:35 +0900 (JST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Rodney Van Meter In-Reply-To: Date: Fri, 12 Dec 2014 13:50:31 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <9324C11F-E4B9-4464-871E-A94F18D54346@sfc.wide.ad.jp> References: To: Paul Hoffman X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/qQgALkC0aLk6-KhJmnVBP96T95U Cc: Rodney Van Meter , IPsecME WG Subject: Re: [IPsec] Calls for adoption: wrap-up 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, 12 Dec 2014 18:50:44 -0000 > On Dec 12, 2014, at 1:08 PM, Paul Hoffman = wrote: >=20 > Greetings. A few weeks ago, we started summaries for adoption by the = WG of two drafts: draft-nagayama-ipsecme-ipsec-with-qkd and = draft-mglt-ipsecme-clone-ike-sa. This message concludes that there is = not sufficient interest in the WG (that is, enough people who will = actively contribute to the draft progression) for either draft to be = advance successfully. >=20 > Both drafts had some interest from people other than the authors, but = it seemed like a fair amount of that was defensive; that is, those = people were willing to work on the document, but mostly to prevent bad = design, not because they supported the use case. Given that, if the = authors of either decide to pursue publication, it would be great if = they reached out to all the people on the list who expressed opinions = and try to incorporate those before moving forwards. Notes about new = versions of these drafts (and other non-WG drafts) are still welcome on = the list as long as they do not disrupt the ongoing WG work. >=20 For draft-nagayama-ipsecme-ipsec-with-qkd, that list is: Tero Kivinen Michael Richardson Paul Wouters Tony Putman Valery Smyslov Sheila Frankel didn=E2=80=99t respond on list in the last couple of = weeks, but I=E2=80=99m guessing she has at least a passing interest. plus of course the authors (Shota Nagayama & Rod Van Meter) Anybody else care to speak up? Shota is still trying to ingest the comments we got both on and off list = over the last few weeks; he has already responded to a few comments on = the ML. I hope we=E2=80=99ll have a coherent response to all of them, = and a draft-of-a-draft to share with a small group, Real Soon Now (er, = sometime in January, probably). It does seem that there was the most support for generalizing to other = out-of-band mechanisms, so I presume we will pursue that and make the = QKD interpretation an Annex or Appendix to the document. So, we=E2=80=99ll take this conversation off list, and come back when we = are close to the -02 I-D. =E2=80=94Rod From nobody Sat Dec 13 00:05:50 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 50C7C1AC3EE for ; Sat, 13 Dec 2014 00:05:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.898 X-Spam-Level: X-Spam-Status: No, score=0.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 tWyeTtUA_Pf2 for ; Sat, 13 Dec 2014 00:05:45 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BCDFF1A01F4 for ; Sat, 13 Dec 2014 00:05:44 -0800 (PST) Received: from [IPv6:2001:200:0:8802:838:bbbc:592e:c072] (unknown [IPv6:2001:200:0:8802:838:bbbc:592e:c072]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 045CC278118; Sat, 13 Dec 2014 17:05:42 +0900 (JST) Message-ID: <548BF356.1000403@sfc.wide.ad.jp> Date: Sat, 13 Dec 2014 17:05:42 +0900 From: Shota Nagayama User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: =?UTF-8?B?UGF1bCBXb3V0ZXJzIPCflJM=?= , Paul Hoffman References: <2CBE2213-E3B6-4E0C-95EC-D1DFB05D3A0E@vpnc.org> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/TFtmYnnRSJXi1gNGGvEQ1gkOgPw Cc: IPsecME WG Subject: Re: [IPsec] Survey for WG interest in adopting draft-nagayama-ipsecme-ipsec-with-qkd 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, 13 Dec 2014 08:05:47 -0000 (2014/11/29 4:21), Paul Wouters 🔓 wrote: > On Tue, 25 Nov 2014, Paul Hoffman wrote: > >> Greetings again. There is a small emerging industry of crypto >> solutions that transmit keys using Quantum Key Distribution (QKD), >> and then use those keys for classical high-speed encryption. Several >> such solutions are using IKE, and there is a perceived need to >> standardize this usage. If so, that standardization should be done in >> this Working Group. >> >> If you agree with the need to standardize this usage, and believe >> that draft-nagayama-ipsecme-ipsec-with-qkd is likely to be a good >> starting place for that standardization, and are willing to review >> and contribute text to the document if it is adopted by the WG, >> please say so on the list. This WG has a history of adopting >> documents but then not having enough reviewers for us to feel >> confident that we are making a good standard, so we need to see a >> reasonable number of actively interested people before we adopt the >> document. If it is not adopted, the authors can ask for it to be >> published as an RFC through individual submission or by the >> Independent Submissions Editor. > > I'm in favor of adopting this document as I can see a real use for this > in the future and since it is making changes to the IKE core protocol, > it would be best that this group is involved in that discussion. > > Some comments after a quick read: > > Why is the fallback field/mode negotiation required? Typically, those > decisions would be determined by local policy, and the remote end is > informed of that local policy by a new incoming IKE request (or not) > that uses a QKD payload or a DH payload. If the peers disagree about > the fallback method, would that prevent initial establishment of IKE? Though I replied that fallback mode might be treated as local policy and not to be negotiated at the beginning of IKE, now I notice a difference between fallback mode and other local policies, if my understanding is correct. In current IKE, after establishing the first SA, the success of rekeying is guaranteed at the configuration level; any difference of local policies which are not shared do not prevent rekeying the SA. If fallback mode isn't negotiated, when the system fallbacks, if no fallback method is enabled in both peers, rekeying gets blocked until QKD succeeds to generate new key. If fallback mode is negotiated at the beginning, the system may know whether rekeying in fallback mode be blocked as such or not. Then, this can be warned to users/system admins before fallback mode is needed to be operated. So, now I think that fallback mode should be negotiated at the beginning and it should not prevent initial establishment of IKE but should be warned. > > Why not leave the DH in place and just ignore the SKEYSEED / prf and > use the QKD bits for the private keys (or OTP)? It's less changes > to the IKE protocol (and friendlier to implementers :) > > Having an OTP mode, even without QKD would actually be neat, although it > would require a lot of kernel work too :) My first idea is just replacing QKD-generated bits with SKEYSEED. QKD is often argued with OTP to achieve provably secure and I know that just replacing QKD-generated bits with SKEYSEED can be used for OTP, however, I would like to target only IKE in this project. > > Paul > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Mon Dec 15 07:02:26 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 754841A1EFD for ; Mon, 15 Dec 2014 07:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.768 X-Spam-Level: X-Spam-Status: No, score=0.768 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 dO8Yyvrmemx4 for ; Mon, 15 Dec 2014 07:02:22 -0800 (PST) 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 5C17E1A1B5A for ; Mon, 15 Dec 2014 07:02:22 -0800 (PST) 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 sBFF2Jup011002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 15 Dec 2014 17:02:19 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sBFF2Ifj027468; Mon, 15 Dec 2014 17:02:18 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21646.63482.320494.538513@fireball.kivinen.iki.fi> Date: Mon, 15 Dec 2014 17:02:18 +0200 From: Tero Kivinen To: Shota Nagayama In-Reply-To: <548BF356.1000403@sfc.wide.ad.jp> References: <2CBE2213-E3B6-4E0C-95EC-D1DFB05D3A0E@vpnc.org> <548BF356.1000403@sfc.wide.ad.jp> X-Mailer: VM 8.2.0b under 24.3.1 (x86_64--netbsd) X-Edit-Time: 15 min X-Total-Time: 8 min Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/htn_KYMSq_DePPO3AGrixztLhJA Cc: IPsecME WG Subject: Re: [IPsec] Survey for WG interest in adopting draft-nagayama-ipsecme-ipsec-with-qkd 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, 15 Dec 2014 15:02:25 -0000 Shota Nagayama writes: > Though I replied that fallback mode might be treated as local policy > and not to be negotiated at the beginning of IKE, now I notice a > difference between fallback mode and other local policies, if my > understanding is correct. In current IKE, after establishing the > first SA, the success of rekeying is guaranteed at the configuration > level; Not true. Other end can simply reject the rekey by sending NO_ADDITIONAL_SAS notification back to the rekey request. RFC7296 section 1.3 last paragraph: The responder sends a NO_ADDITIONAL_SAS notification to indicate that a CREATE_CHILD_SA request is unacceptable because the responder is unwilling to accept any more Child SAs on this IKE SA. This notification can also be used to reject IKE SA rekey. Some minimal implementations may only accept a single Child SA setup in the context of an initial IKE exchange and reject any subsequent attempts to add more. > any difference of local policies which are not shared do not > prevent rekeying the SA. If fallback mode isn't negotiated, when the > system fallbacks, if no fallback method is enabled in both peers, > rekeying gets blocked until QKD succeeds to generate new key. Yes. Just like it does with normal IKEv2 rekey. On the other hand as both ends will KNOW for sure when the QKD has succeeded, there is no need for fallback policy for QKD use. There could be uses for it in the other out of band key distribution methods, as there the state might not be shared between both ends at the same time. In QKD the node will know it has shared keying material with the other end, and if it will know that it will also know that other end has the same key material also... > If fallback mode is negotiated at the beginning, the system may know > whether rekeying in fallback mode be blocked as such or not. Then, > this can be warned to users/system admins before fallback mode is > needed to be operated. So, now I think that fallback mode should be > negotiated at the beginning and it should not prevent initial > establishment of IKE but should be warned. I do not think there is any need for fallback mode to be negotiated. If the peer A is willing to fall back to diffie-hellman then it will try rekeying with diffie-hellman. If other end rejects this rekey with NO_ADDITIONAL_SAS or some other suitable error notification (depending how the actual out of band key distribution is negotiated), then they know there is differences in the policy, thus he cannot rekey. If his policy says it can continue in that case, it will, if not then it will close down the IKEv2 SA, and no more packets are sent/received as specified by the policy. -- kivinen@iki.fi From nobody Mon Dec 15 08:10: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 C63F41A702D for ; Mon, 15 Dec 2014 08:10:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.647 X-Spam-Level: X-Spam-Status: No, score=-3.647 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-2.3] 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 j1bCVyA4AyI4 for ; Mon, 15 Dec 2014 08:10:18 -0800 (PST) Received: from proper.com (Hoffman.Proper.COM [207.182.41.81]) (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 E3F751A700D for ; Mon, 15 Dec 2014 08:10:17 -0800 (PST) Received: from [10.20.30.90] (50-1-99-181.dsl.dynamic.fusionbroadband.com [50.1.99.181]) (authenticated bits=0) by proper.com (8.14.9/8.14.7) with ESMTP id sBFGAG7Q066552 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 15 Dec 2014 09:10:17 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: proper.com: Host 50-1-99-181.dsl.dynamic.fusionbroadband.com [50.1.99.181] claimed to be [10.20.30.90] Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\)) From: Paul Hoffman In-Reply-To: <548BF356.1000403@sfc.wide.ad.jp> Date: Mon, 15 Dec 2014 08:10:16 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <52EFE4AC-47EC-4EF8-956A-44ECF887A78F@vpnc.org> References: <2CBE2213-E3B6-4E0C-95EC-D1DFB05D3A0E@vpnc.org> <548BF356.1000403@sfc.wide.ad.jp> To: Shota Nagayama X-Mailer: Apple Mail (2.1993) Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/q35tIOG6cKWKHf6KGd5L3w3h3tY Cc: IPsecME WG Subject: Re: [IPsec] Survey for WG interest in adopting draft-nagayama-ipsecme-ipsec-with-qkd 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, 15 Dec 2014 16:10:18 -0000 Please note that the conclusion of this survey was that the WG was not = going to adopt the document. The chairs asked that the authors set up = their own discussion fora if they want to continue discussion. = Announcing new versions of non-WG drafts on this list is fine, but = trying to keep the discussion alive here is not. --Paul Hoffman= From ashokar@gmail.com Sun Dec 14 22:58:17 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 7AC8F1A1A14 for ; Sun, 14 Dec 2014 22:58:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.1 X-Spam-Level: X-Spam-Status: No, score=-0.1 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, 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 T0GZwLmTL1iv for ; Sun, 14 Dec 2014 22:58:15 -0800 (PST) Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6257F1A1A13 for ; Sun, 14 Dec 2014 22:58:15 -0800 (PST) Received: by mail-qg0-f54.google.com with SMTP id l89so8097300qgf.13 for ; Sun, 14 Dec 2014 22:58:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=luNYrrcKAiEORI2Ijv9EDFtBtQHArOkBUitf12ZSp5A=; b=bT0aGk1IKYZl9BzLgBRH0FxK5NgoKzQthLcAw97jOKB7OZb+zjnzGnF8osrzaxjDi8 tad8hvYg2L1Xr4AMqk+mhGFP1XBz6V06XP9Fg3LPmKK73uMn4Iay0oHydICdyDVRLv12 tzYR0BOlTGUDUdwgyp7zeMVFrb4nx5T9POIDyXqVNVNDNSe1mX4Rb8sSsmiLO+gZvEt2 lNG+mNZEfGncZrXTDEvkYjOkv3VqypuehwBC/bpw2R97xzMYSGK4JXeP+XZzLPFxMqSB KHfj0/DD5FLbN1O6aXGEj+7IiEHudk5VlbcHKVxM+3xwlJF6tjj5LB2IdepithizPqDH zFrQ== MIME-Version: 1.0 X-Received: by 10.224.15.78 with SMTP id j14mr41488322qaa.0.1418626694663; Sun, 14 Dec 2014 22:58:14 -0800 (PST) Received: by 10.140.80.136 with HTTP; Sun, 14 Dec 2014 22:58:14 -0800 (PST) Date: Mon, 15 Dec 2014 12:28:14 +0530 Message-ID: From: Ashok Kumar To: ipsec@ietf.org Content-Type: multipart/alternative; boundary=047d7bdc81cc3457f1050a3bc4bc Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/ULZcr6Ud_Crw87TT2EaLo4i-NfQ X-Mailman-Approved-At: Mon, 15 Dec 2014 08:24:12 -0800 Subject: [IPsec] RFC-4303 - Does ESN really worth/help to reduce/avoid replayed packets? 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, 15 Dec 2014 07:00:05 -0000 --047d7bdc81cc3457f1050a3bc4bc Content-Type: text/plain; charset=UTF-8 Hi All, As per my understanding, the anti-replay feature in IPsec helps to save CPU cycles in the IPsec gateway (or host) by discarding the replayed packets so that costly operation like MAC calculation and decryption can be avoided for such packets. Is my understanding right? >From "A2.3. Pseudo-Code Example" in RFC-4303, looks like any packet which are older than the anti-replay window start, would skip the anti-replay check and MAC check will be done. Though MAC check would fail (because Seqh would be incorrect), MAC calculation would still happens. It is most likely to happen for almost all replayed packets in a high throughput tunnel. Isn't it? Without ESN support, we will discard all packets whose sequence number is less than the anti-replay window base. So the problem which I see is, only with ESN support. Please correct me if I am missing something. Regards, Ashok Kumar PS: The " Pseudo-Code Example" from the RFC-4303: The following pseudo-code illustrates the above algorithms for anti- replay and integrity checks. The values for `Seql', `Tl', `Th' and `W' are 32-bit unsigned integers. Arithmetic is mod 2^32. If (Tl >= W - 1) Case A ==> This is most likely case. The else case will hit only when the anti-replay window span across two 32-bit sequence number spaces. If (Seql >= Tl - W + 1) ==> This will hit only if the packet sequence number is *not* below anti-replay window start. For replayed packet in a high throughput tunnel, it is less likely to hit. Seqh = Th If (Seql <= Tl) If (pass replay check) If (pass integrity check) Set bit corresponding to Seql Pass the packet on Else reject packet Else reject packet Else If (pass integrity check) Tl = Seql (shift bits) Set bit corresponding to Seql Pass the packet on Else reject packet Else ==> This case would most likely will hit for replayed packets in a high throughput tunnel (or replayed packets with little delay). Seqh = Th + 1 If (pass integrity check) Tl = Seql (shift bits) Th = Th + 1 Set bit corresponding to Seql Pass the packet on Else reject packet Else Case B If (Seql >= Tl - W + 1) Seqh = Th - 1 If (pass replay check) If (pass integrity check) Set the bit corresponding to Seql Pass packet on Else reject packet Else reject packet Else Seqh = Th If (Seql <= Tl) If (pass replay check) If (pass integrity check) Set the bit corresponding to Seql Pass packet on Else reject packet Else reject packet Else If (pass integrity check) Tl = Seql (shift bits) Set the bit corresponding to Seql Pass packet on Else reject packet --047d7bdc81cc3457f1050a3bc4bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi All,

As per my understanding, the anti-replay feature in I= Psec helps to save CPU cycles
in the IPsec gateway (o= r host) by discarding the replayed packets so that costly
operation like MAC calculation and decryption can be avoided for such = packets.
Is my understanding right?

From "A2.3. Ps= eudo-Code Example" in RFC-4303, looks like any packet which
are older than the an= ti-replay window start, would skip the anti-replay check
<= span style=3D"color:rgb(0,0,0);font-size:1em">and MAC check will be done. T= hough MAC check would fail (because Seqh
would be incorrect), MAC calculation would st= ill happens. It is most likely to
happen for almost all replayed packets in a high thr= oughput tunnel. Isn't it?

Without ESN support, we will discard all packets whose sequenc= e number
is= less than the anti-replay window base. So the problem which I see is,
only with ESN s= upport. Please correct me if I am missing something.

Regards,
Ashok Kumar

PS: The=C2=A0" Pseudo-Code Example" from t= he RFC-4303:

   The following pseudo-code illustr=
ates the above algorithms for anti-
   replay and integrity checks.  The values for `Seql', `Tl', `Th&#=
39; and
   `W' are 32-bit unsigned integers.  Arithmetic is mod 2^32.

        If (Tl >=3D W - 1)                            Case A

=3D=3D> This is most likely case. The =
else case will hit only when
    the anti-replay window=
 span across two 32-bit sequence number spaces.
      =
      If (Seql >=3D Tl - W + 1)

=3D=3D> This will hit only if the packet sequence number is *not* b=
elow
    anti-replay window start. For replayed packet =
in a high throughput tunnel,
    it is less likely to h=
it.
                Seqh =3D Th
                If (Seql <=3D Tl)
                    If (pass replay check)
                        If (pass integrity check)
                            Set bit corresponding to Seql
                            Pass the packet on
                        Else reject packet
                    Else reject packet
                Else
                    If (pass integrity check)
                        Tl =3D Seql (shift bits)
                        Set bit corresponding to Seql
                        Pass the packet on
                    Else reject packet
            Else

=3D=3D> Th=
is case would most likely will hit for replayed packets
    in a high throughput tunnel (or replayed packets with little delay).
                Seqh =3D Th + 1
                If (pass integrity check)
                    Tl =3D Seql (shift bits)
                    Th =3D Th + 1
                    Set bit corresponding to Seql
                    Pass the packet on
                Else reject packet
        Else                                    Case B
            If (Seql >=3D Tl - W + 1)
                Seqh =3D Th - 1
                If (pass replay check)
                    If (pass integrity check)
                        Set the bit corresponding to Seql
                        Pass packet on
                    Else reject packet
                Else reject packet
            Else
                Seqh =3D Th
                If (Seql <=3D Tl)
                    If (pass replay check)
                        If (pass integrity check)
                            Set the bit corresponding to Seql
                            Pass packet on
                        Else reject packet
                    Else reject packet
                =
Else

                    If (pass integrity check)
                        Tl =3D Seql (shift bits)
                        Set the bit corresponding to Seql
                        Pass packet on
                    Else reject packet


--047d7bdc81cc3457f1050a3bc4bc-- From nobody Mon Dec 15 08:30:12 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 F19F61A802E for ; Mon, 15 Dec 2014 08:30:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 nCXT1HUQjLJh for ; Mon, 15 Dec 2014 08:30:09 -0800 (PST) Received: from ausc60ps301.us.dell.com (ausc60ps301.us.dell.com [143.166.148.206]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FE451A6FC3 for ; Mon, 15 Dec 2014 08:30:09 -0800 (PST) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version:Return-Path; b=a4fjlUXvErQMXqL6Mpo4H+SUUGoSjEjlAhs5fB/XnFtNYcNCTtHSE0in oGbCQYzutsNyXu3fINatHFLZcywRWb2U79fmOqQ3LCOqedyhg3Ms2CQZT 5llEc6MZi5gwUANAGgim9msmmMJ7oHEiZydEOgB05YoRUBMws7A6z9zLi c=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1418661009; x=1450197009; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=SS15ea3gIP9dfW39tCNJicFPq/btJmLAucW1vAwcxFY=; b=JoSDzdsh5h5CjdPA52qFu+6ekgjhCOobibVVNq9yQOjFmqzDFX7FP0PK N8KfKUTfqtcEiv2t4Ml9LH+4FP5mYt8SI9ECvJ3nYYDi62I/pLTiLXdf4 P0zNIsnlkgko36kqEFW+vK7KTx+IbLyBCqqmJlRcOYTBUrm1sAV2xzmdZ U=; X-LoopCount0: from 10.175.216.251 X-IronPort-AV: E=Sophos;i="5.07,580,1413262800"; d="scan'208";a="614163275" From: To: Thread-Topic: [IPsec] RFC-4303 - Does ESN really worth/help to reduce/avoid replayed packets? Thread-Index: AQHQGIObq94+fYaO502FOt0r2zUijpyRPE+A Date: Mon, 15 Dec 2014 16:30:05 +0000 Message-ID: <66CAB7BB-DAC5-4675-82CB-317907C17712@dell.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.135.97] Content-Type: text/plain; charset="us-ascii" Content-ID: Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/-ckb2hQDAkMSWHkWnxDmqU4_kwo Cc: ipsec@ietf.org Subject: Re: [IPsec] RFC-4303 - Does ESN really worth/help to reduce/avoid replayed packets? 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, 15 Dec 2014 16:30:11 -0000 > On Dec 15, 2014, at 1:58 AM, Ashok Kumar wrote: >=20 > Hi All, >=20 > As per my understanding, the anti-replay feature in IPsec helps to save C= PU cycles > in the IPsec gateway (or host) by discarding the replayed packets so that= costly > operation like MAC calculation and decryption can be avoided for such pac= kets. > Is my understanding right? No. The anti-replay feature prevents replay attacks. The purpose is to av= oid delivering duplicate packets to the end system, where (depending on the= protocol) they might cause applications to malfunction. The benefit you d= escribe (to the IPSec gateway) is insignificant. paul From nobody Mon Dec 15 10:02: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 025671A8712 for ; Mon, 15 Dec 2014 10:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 z_L0UvFi4M6X for ; Mon, 15 Dec 2014 10:02:02 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [209.87.249.19]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C8CA1A86F8 for ; Mon, 15 Dec 2014 10:02:02 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 30FBE2009E; Mon, 15 Dec 2014 13:06:01 -0500 (EST) Received: by sandelman.ca (Postfix, from userid 179) id 92D76637F5; Mon, 15 Dec 2014 13:01:58 -0500 (EST) Received: from sandelman.ca (localhost [127.0.0.1]) by sandelman.ca (Postfix) with ESMTP id 73FC563740; Mon, 15 Dec 2014 13:01:58 -0500 (EST) From: Michael Richardson To: Paul_Koning@Dell.com In-Reply-To: <66CAB7BB-DAC5-4675-82CB-317907C17712@dell.com> References: <66CAB7BB-DAC5-4675-82CB-317907C17712@dell.com> X-Mailer: MH-E 8.2; nmh 1.3-dev; GNU Emacs 23.4.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Sender: mcr@sandelman.ca Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/vCCFhN-hleNDvXD-ol606HEP1Ag Cc: ipsec@ietf.org, ashokar@gmail.com Subject: Re: [IPsec] RFC-4303 - Does ESN really worth/help to reduce/avoid replayed packets? 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, 15 Dec 2014 18:02:04 -0000 --=-=-= Content-Transfer-Encoding: quoted-printable wrote: >> Hi All, >>=20 >> As per my understanding, the anti-replay feature in IPsec helps to >> save CPU cycles in the IPsec gateway (or host) by discarding the >> replayed packets so that costly operation like MAC calculation and >> decryption can be avoided for such packets. Is my understanding >> right? > No. The anti-replay feature prevents replay attacks. The purpose is > to avoid delivering duplicate packets to the end system, where > (depending on the protocol) they might cause applications to > malfunction. The benefit you describe (to the IPSec gateway) is > insignificant. Paul: what you said is correct about the reply feature. But what Ashok observed about the implementation recommendation is also cor= rect. The anti-replay *WINDOW* (a bit map of a particular size) in on the receive allows the receiver to receive packets out of order, but puts a lower limit on replay values that will be accepted. Once the window is closed, the gateway can discard packets without performing a MAC calculation. The affect on the IPsec gateway is not insignificant if the IPsec gateway can not perform MAC operations at wire speeds. For much of the life of the IPsec specification, software implementations of IPsec have been slower than line card speeds. It has only been in the past 7 to 9 years that this is frequently not been the case; and it is still the case for most home gateways, for instance. =2D-=20 Michael Richardson , Sandelman Software Works -=3D IPv6 IoT consulting =3D- --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQEVAwUBVI8iE4CLcPvd0N1lAQLg+Qf+OD9FZf7kJ7EjsXH0PD21qCLvigyr8KJi YejE6rUuQbHbfxGq+Do12NmZxhq80h4imlT0wxJNl77YHOR76YE44H+4aATQBt61 fGrTa8uqx/YcLVmqzeC6mkMm1WBwB1jmbouhbRl4Ikz1zEP3R3Ziq0arWBNlOf3d XrI04oyNw4BtKAv+lcaqDIIltJiaC6VOlBpG3ClauxrTXNX1FdoUjmJLZ7cD1usI PEQf8aj8T/NL4ZmLR8XoSpSdU3UMJ1zj2dmB3bdEL2D1jLjrQdTVsR8yTBkIrcRx 5FaPsVMaJbszVaxzNlzLqwrTliQbeTkBNwENgUry1SgAmysQjs0Cig== =hxVY -----END PGP SIGNATURE----- --=-=-=-- From nobody Mon Dec 15 12:44: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 C58F71A89B0 for ; Mon, 15 Dec 2014 12:44:14 -0800 (PST) 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, SPF_NEUTRAL=0.779, T_RP_MATCHES_RCVD=-0.01] 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 L9yXzXSpYeiF for ; Mon, 15 Dec 2014 12:44:11 -0800 (PST) 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 3411A1A89A8 for ; Mon, 15 Dec 2014 12:44:02 -0800 (PST) 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 sBFKhumd015706 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 15 Dec 2014 22:43:56 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.8/8.14.8/Submit) id sBFKhtR5012331; Mon, 15 Dec 2014 22:43:55 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <21647.18443.148411.872644@fireball.kivinen.iki.fi> Date: Mon, 15 Dec 2014 22:43:55 +0200 From: Tero Kivinen To: Paul Hoffman In-Reply-To: <52EFE4AC-47EC-4EF8-956A-44ECF887A78F@vpnc.org> References: <2CBE2213-E3B6-4E0C-95EC-D1DFB05D3A0E@vpnc.org> <548BF356.1000403@sfc.wide.ad.jp> <52EFE4AC-47EC-4EF8-956A-44ECF887A78F@vpnc.org> 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/A8OiaN7IgZFkcdLtpseprkeSeTA Cc: IPsecME WG , Shota Nagayama Subject: Re: [IPsec] Survey for WG interest in adopting draft-nagayama-ipsecme-ipsec-with-qkd 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, 15 Dec 2014 20:44:15 -0000 Paul Hoffman writes: > Please note that the conclusion of this survey was that the WG was > not going to adopt the document. The chairs asked that the authors > set up their own discussion fora if they want to continue > discussion. Announcing new versions of non-WG drafts on this list is > fine, but trying to keep the discussion alive here is not. I do not agree on that. The ipsec is the ietf list for ipsec related discussion. It was originally for ipsec WG and when IPsecME was formed we decided to use same mailing list, and I think that at point the idea was that mailing list should be used with all ipsec related discussions. The discussion about those draft has not been that overwhelming that we would need to create separate mailing list for that. If you are going to say that most of the active working group participants (I think most of the really active working group participants did answer to question, but there might be few missing) are not enough for draft to be working group document, and then you say that we cannot even discuss it on the ipsec list I think that is not ok. I do not want to joining several different mailing list for short time to discuss about each draft the chairs feel should not be adopted on the wg and then the lists would most likely be silent forever (except of course the mandatory spams). -- kivinen@iki.fi From nobody Tue Dec 16 05:16:55 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 7E9181ACD86 for ; Tue, 16 Dec 2014 05:16:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 Qa1n0O15FwvZ for ; Tue, 16 Dec 2014 05:16:50 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1795F1A1AEA for ; Tue, 16 Dec 2014 05:16:50 -0800 (PST) Received: from dommiel.bbn.com ([192.1.122.15]:49610 helo=COMSEC.local) by smtp.bbn.com with esmtp (Exim 4.77 (FreeBSD)) (envelope-from ) id 1Y0rzt-00084c-69; Tue, 16 Dec 2014 08:17:05 -0500 Message-ID: <549030BE.2070007@bbn.com> Date: Tue, 16 Dec 2014 08:16:46 -0500 From: Stephen Kent User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: Ashok Kumar , ipsec References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------000609040504050209080306" Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/DuyZupdRKdnVrcP5Xr77rfxCJhM Subject: Re: [IPsec] RFC-4303 - Does ESN really worth/help to reduce/avoid replayed packets? 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, 16 Dec 2014 13:16:52 -0000 This is a multi-part message in MIME format. --------------000609040504050209080306 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Ashok, > Hi All, > > As per my understanding, the anti-replay feature in IPsec helps to > save CPU cycles > in the IPsec gateway (or host) by discarding the replayed packets so > that costly > operation like MAC calculation and decryption can be avoided for such > packets. > Is my understanding right? only partially. The main reason for this is to protect an app from receiving replayed traffic that it might not otherwise detect and reject. Not an issue for TCP, but a possible issue for UDP-based apps. > From "A2.3. Pseudo-Code Example" in RFC-4303, looks like any packet which > are older than the anti-replay window start, would skip the > anti-replay check > and MAC check will be done. Though MAC check would fail (because Seqh > would be incorrect), MAC calculation would still happens. It is most > likely to > happen for almost all replayed packets in a high throughput tunnel. > Isn't it? That's not the intent. The intent is to immediately drop any packet for which the sequence number is older than the AR window, thus avoiding crypto operations that are not necessary. > Without ESN support, we will discard all packets whose sequence number > is less than the anti-replay window base. So the problem which I see is, > only with ESN support. Please correct me if I am missing something. See comments above. Steve --------------000609040504050209080306 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Ashok,
Hi All,

As per my understanding, the anti-replay feature in IPsec helps to save CPU cycles
in the IPsec gateway (or host) by discarding the replayed packets so that costly
operation like MAC calculation and decryption can be avoided for such packets.
Is my understanding right?
only partially. The main reason for this is to protect an app from receiving
replayed traffic that it might not otherwise detect and reject. Not an issue for
TCP, but a possible issue for UDP-based apps.
From "A2.3. Pseudo-Code Example" in RFC-4303, looks like any packet which
are older than the anti-replay window start, would skip the anti-replay check
and MAC check will be done. Though MAC check would fail (because Seqh
would be incorrect), MAC calculation would still happens. It is most likely to
happen for almost all replayed packets in a high throughput tunnel. Isn't it?
That's not the intent. The intent is to immediately drop any packet for which
the sequence number is older than the AR window, thus avoiding crypto operations
that are not necessary.
Without ESN support, we will discard all packets whose sequence number
is less than the anti-replay window base. So the problem which I see is,
only with ESN support. Please correct me if I am missing something.
See comments above.

Steve
--------------000609040504050209080306-- From nobody Tue Dec 16 08:45: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 54AC91A1BE3 for ; Tue, 16 Dec 2014 08:45:47 -0800 (PST) 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 lPCKP9MD9ryU for ; Tue, 16 Dec 2014 08:45:45 -0800 (PST) Received: from mail-qg0-x229.google.com (mail-qg0-x229.google.com [IPv6:2607:f8b0:400d:c04::229]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9432F1A6EF0 for ; Tue, 16 Dec 2014 08:45:27 -0800 (PST) Received: by mail-qg0-f41.google.com with SMTP id j5so10570422qga.28 for ; Tue, 16 Dec 2014 08:45:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yC+U5wWPxcz+9pPDEzDiyGS/otqmQLRPHM3rFw4dBFw=; b=JjfhU7GHt2m0uXelpcnr2kcSpk9Maz/l1tZ1q2nrdMkiCeGph9F6fdbVfCp8VS1kvO +sW104y3krCLfGFMESqo3+pXgcKERJMgBNHVLWF7zBuRBfG+Jl8tBDgmWQnvk2cXDrUF X8eiquSU8NeU8za6aAIx7ka03GNyaS2um6uvcU8v2pboADnHUXdEdXaSxpK8j9oO0P7B 7+36j1JjY8pajiY8XJhsswpoHwFU2xv+KznS4h863Bm03MWDi8gPO3H0oYi3/bMbPiTN Bgj8QZeZ9fowNbSlat7cGYu4lI55UV8rXouVo73lRRzDPGPx6nUzW4sHq/pcrE1nByrs Hg4w== MIME-Version: 1.0 X-Received: by 10.140.17.203 with SMTP id 69mr55150876qgd.32.1418748326647; Tue, 16 Dec 2014 08:45:26 -0800 (PST) Received: by 10.140.80.136 with HTTP; Tue, 16 Dec 2014 08:45:26 -0800 (PST) In-Reply-To: <66CAB7BB-DAC5-4675-82CB-317907C17712@dell.com> References: <66CAB7BB-DAC5-4675-82CB-317907C17712@dell.com> Date: Tue, 16 Dec 2014 22:15:26 +0530 Message-ID: From: Ashok Kumar To: Paul_Koning@dell.com Content-Type: multipart/alternative; boundary=001a11c002ba091f7f050a58169a Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/bpD_6nXcfIm45mUWaUEP6uPiSMk Cc: ipsec@ietf.org Subject: Re: [IPsec] RFC-4303 - Does ESN really worth/help to reduce/avoid replayed packets? 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, 16 Dec 2014 16:45:47 -0000 --001a11c002ba091f7f050a58169a Content-Type: text/plain; charset=UTF-8 Hi Paul, I agree that it helps to avoid delivering duplicate packets to the end system. But I am not convinced about the following statement. > The purpose is to avoid delivering duplicate packets to the end system, where (depending > on the protocol) they might cause applications to malfunction. The IPsec is transparent to end system. So IIUC, end-to-end system/application shouldn't assume that it will never receive duplicate packets. So regardless of whether IPsec is used/deployed or not, it is end system/application responsibility to handle any duplicate packets. Isn't it? Thanks, Ashok Kumar On Mon, Dec 15, 2014 at 10:00 PM, wrote: > > > > On Dec 15, 2014, at 1:58 AM, Ashok Kumar wrote: > > > > Hi All, > > > > As per my understanding, the anti-replay feature in IPsec helps to save > CPU cycles > > in the IPsec gateway (or host) by discarding the replayed packets so > that costly > > operation like MAC calculation and decryption can be avoided for such > packets. > > Is my understanding right? > > No. The anti-replay feature prevents replay attacks. The purpose is to > avoid delivering duplicate packets to the end system, where (depending on > the protocol) they might cause applications to malfunction. The benefit > you describe (to the IPSec gateway) is insignificant. > > paul > > --001a11c002ba091f7f050a58169a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Paul,

I agree that i= t helps to avoid delivering duplicate packets to the end system.
But I am not convinced ab= out the following statement.

> The = purpose is to avoid delivering duplicate packets to the end system, where (= depending
> on the protocol) they might cause appl= ications to malfunction.

The IPsec is = transparent to end system. So IIUC, end-to-end system/application
shouldn't assume that it will never receive duplicate packets. So rega= rdless of
whether IPsec is used/deployed or not, it is end system= /application responsibility
to handle any duplicate packets. Isn&= #39;t it?

Thanks,
Ashok Kumar

On Mon, Dec 15, 2014 at 10:00 PM, <Paul= _Koning@dell.com> wrote:
> On Dec 15, 2014, at 1:58 AM, Ashok Kumar <ashokar@gmail.com> wrote:
>
> Hi All,
>
> As per my understanding, the anti-replay feature in IPsec helps to sav= e CPU cycles
> in the IPsec gateway (or host) by discarding the replayed packets so t= hat costly
> operation like MAC calculation and decryption can be avoided for such = packets.
> Is my understanding right?

No.=C2=A0 The anti-replay feature prevents replay attacks.=C2=A0 The= purpose is to avoid delivering duplicate packets to the end system, where = (depending on the protocol) they might cause applications to malfunction.= =C2=A0 The benefit you describe (to the IPSec gateway) is insignificant.
=C2=A0 =C2=A0 =C2=A0 =C2=A0 paul

--001a11c002ba091f7f050a58169a-- From nobody Tue Dec 16 09:02: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 6910D1A6F33 for ; Tue, 16 Dec 2014 09:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.011 X-Spam-Level: X-Spam-Status: No, score=-7.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 KGHBj8W0UxRt for ; Tue, 16 Dec 2014 09:02:14 -0800 (PST) Received: from ausc60pc101.us.dell.com (ausc60pc101.us.dell.com [143.166.85.206]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C30C11A6F52 for ; Tue, 16 Dec 2014 09:02:13 -0800 (PST) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version:Return-Path; b=oI+HaupcCYknqXpG5klFkrTPEtSjF47tfmUPJjsg/R1jon94CaC1KH3z An73uiKkCeJIAejK3fK4AAYGLVuyN/BJevEDRbp7UXYJYYap4+MPS2Xak 0g5dMIJZnjB/FLmsFj5eYhF/mlQxv7SI2WGbu3gbQWkdKfKzstk8ernyT c=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1418749333; x=1450285333; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=3gnc2CKDbD2QzppgXh3ur+skKGr0dmVYGEg8kw8kAdA=; b=yszpdxvgoqo3pHhkd6pijL4yl28fM3Lwtqe7AK0paKGr8plObWiDRfPx oVRpXSm8JYBW0aTmDN4pxue3t8Tyt71x233EvK1ebJ+nnyn9T0ODPf9X/ pmzEzWQYSJYk64IGM6kVoE3cRIJelRIJe1JnIWJsoboOvt8Ypxcqa4vlX w=; X-LoopCount0: from 10.170.28.39 X-IronPort-AV: E=Sophos;i="5.07,587,1413262800"; d="scan'208";a="732756757" From: To: Thread-Topic: [IPsec] RFC-4303 - Does ESN really worth/help to reduce/avoid replayed packets? Thread-Index: AQHQGIObq94+fYaO502FOt0r2zUijpyRPE+AgAGWoQCAAASRgA== Date: Tue, 16 Dec 2014 17:01:48 +0000 Message-ID: <0960BFC1-E306-45CB-A954-4CF2595686B3@dell.com> References: <66CAB7BB-DAC5-4675-82CB-317907C17712@dell.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.135.94] Content-Type: text/plain; charset="utf-8" Content-ID: <32620C032BCCC441B2CCA15673AC1437@dell.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/o-6UGDBpIUGCid_wINR0rWyZ4YM Cc: ipsec@ietf.org Subject: Re: [IPsec] RFC-4303 - Does ESN really worth/help to reduce/avoid replayed packets? 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, 16 Dec 2014 17:02:16 -0000 DQo+IE9uIERlYyAxNiwgMjAxNCwgYXQgMTE6NDUgQU0sIEFzaG9rIEt1bWFyIDxhc2hva2FyQGdt YWlsLmNvbT4gd3JvdGU6DQo+IA0KPiBIaSBQYXVsLA0KPiANCj4gSSBhZ3JlZSB0aGF0IGl0IGhl bHBzIHRvIGF2b2lkIGRlbGl2ZXJpbmcgZHVwbGljYXRlIHBhY2tldHMgdG8gdGhlIGVuZCBzeXN0 ZW0uDQo+IEJ1dCBJIGFtIG5vdCBjb252aW5jZWQgYWJvdXQgdGhlIGZvbGxvd2luZyBzdGF0ZW1l bnQuDQo+IA0KPiA+IFRoZSBwdXJwb3NlIGlzIHRvIGF2b2lkIGRlbGl2ZXJpbmcgZHVwbGljYXRl IHBhY2tldHMgdG8gdGhlIGVuZCBzeXN0ZW0sIHdoZXJlIChkZXBlbmRpbmcNCj4gPiBvbiB0aGUg cHJvdG9jb2wpIHRoZXkgbWlnaHQgY2F1c2UgYXBwbGljYXRpb25zIHRvIG1hbGZ1bmN0aW9uLg0K PiANCj4gVGhlIElQc2VjIGlzIHRyYW5zcGFyZW50IHRvIGVuZCBzeXN0ZW0uIFNvIElJVUMsIGVu ZC10by1lbmQgc3lzdGVtL2FwcGxpY2F0aW9uDQo+IHNob3VsZG4ndCBhc3N1bWUgdGhhdCBpdCB3 aWxsIG5ldmVyIHJlY2VpdmUgZHVwbGljYXRlIHBhY2tldHMuIFNvIHJlZ2FyZGxlc3Mgb2YNCj4g d2hldGhlciBJUHNlYyBpcyB1c2VkL2RlcGxveWVkIG9yIG5vdCwgaXQgaXMgZW5kIHN5c3RlbS9h cHBsaWNhdGlvbiByZXNwb25zaWJpbGl0eQ0KPiB0byBoYW5kbGUgYW55IGR1cGxpY2F0ZSBwYWNr ZXRzLiBJc24ndCBpdD8NCg0KQ29udmVudGlvbmFsIHByb3RvY29sIGRlc2lnbiBjb25jZW50cmF0 ZXMgb24gaGFuZGxpbmcgZXZlbnRzIHRoYXQgb2NjdXIgbm9ybWFsbHkgaW4gYSBuZXR3b3JrLiAg Rm9yIGV4YW1wbGUsIGFjY2lkZW50YWwgZGF0YSBjb3JydXB0aW9uIG9jY3VycyBvbiBwaHlzaWNh bCBsaW5rcyBkdWUgdG8gbm9pc2UgYW5kIHRoZSBsaWtlLiAgUGFja2V0IHJlb3JkZXJpbmcgb2Nj dXJzIGR1ZSB0byBob3cgcm91dGluZyB3b3Jrcy4gIFBhY2tldCBkdXBsaWNhdGlvbiBtYXkgYWxz byBvY2N1ciBub3JtYWxseSBvbiBvY2Nhc2lvbi4gIEluIGFsbCB0aGVzZSwgdGhlIGRlc2lnbiBm b2N1c2VzIG9uIG5vbi1tYWxpY2lvdXMgZXZlbnRzOiByYW5kb20gb3Igb3RoZXJ3aXNlIGludGVy bWl0dGVudCBldmVudHMgYnV0IG5vdCBldmVudHMgY29uc3RydWN0ZWQgYnkgYW4gYWR2ZXJzYXJ5 IGludGVudCBvbiBicmVha2luZyB0aGluZ3MuDQoNCkJ5IGNvbnRyYXN0LCBzZWN1cml0eSBwcm90 b2NvbHMgc3VjaCBhcyBJUFNlYyBzcGVjaWZpY2FsbHkgYWltIHRvIGhhbmRsZSBldmVudHMgY3Jl YXRlZCBieSBhIG1hbGljaW91cyBhZHZlcnNhcnkuICBDb25zaWRlciB0aGUgZGF0YSBjb3JydXB0 aW9uIGNhc2U6IENSQyB3b3JrcyB2ZXJ5IHdlbGwgZm9yIHJhbmRvbSBiaXQgZXJyb3JzLCB3aGlj aCBpcyB3aHkgZGF0YSBsaW5rIGxheWVycyAoc3VjaCBhcyBFdGhlcm5ldCkgdXNlIGl0IHdpZGVs eS4gIENSQyBhbmQgY2hlY2tzdW1zIHdvcmsgd2VsbCBmb3Igc29tZSBvdGhlciBjbGFzc2VzIG9m IGFjY2lkZW50YWwgZGF0YSBlcnJvcnMsIHdoaWNoIGlzIHdoeSBTQ1RQIGFuZCBpU0NTSSB1c2Vz IENSQywgYW5kIFRDUCB1c2VzIGEgc2ltcGxlciBjaGVja3N1bS4NCg0KTm9uZSBvZiB0aG9zZSBh cmUgYW55IGhlbHAgYXQgYWxsIGFnYWluc3QgZGVsaWJlcmF0ZSBhdHRhY2tzLiAgSXQgaXMgdXR0 ZXJseSB0cml2aWFsIHRvIG1vZGlmeSBwYWNrZXRzIGluIGEgd2F5IHRoYXQgbGVhdmVzIHRoZSBj aGVja3N1bSBvciBDUkMgdW5jaGFuZ2VkIChvciwgZm9yIHRoYXQgbWF0dGVyLCB0byBhZGp1c3Qg dGhlIGNoZWNrc3VtIHNvIGl0IHN0aWxsIGxvb2tzIGNvcnJlY3QpLiAgU28gSVBTZWMgZG9lcyBu b3QgZG8gaXQgdGhhdCB3YXk7IGluc3RlYWQsIGl0IHVzZXMgYSBrZXllZCBzZWN1cmUgaGFzaCwg d2hpY2ggZG9lcyBoYXZlIHRoZSBwcm9wZXJ0eSB0aGF0IGl0IHJlc2lzdHMgZGVsaWJlcmF0ZSBt YWxpY2lvdXMgbW9kaWZpY2F0aW9uLg0KDQpTbyB0b28gd2l0aCBkdXBsaWNhdGUgcGFja2V0cy4g IFRDUCwgZm9yIGV4YW1wbGUsIGRlYWxzIHdpdGggZHVwbGljYXRlIHBhY2tldHMsIHdpdGhpbiBs aW1pdHMsIGFuZCBhc3N1bWluZyB0aGF0IHRoZXJlIGlzbuKAmXQgYW4gYWN0aXZlIGF0dGFja2Vy IG1vZGlmeWluZyB0aGUgcGFja2V0IHN0cmVhbS4gIEJ1dCB0aGUgVENQIG1lY2hhbmlzbXMgYXJl IG5vdCBkZXNpZ25lZCBmb3IgYW5kIGRvIG5vdCBoYW5kbGUgYSBkZWxpYmVyYXRlIGF0dGFjayBi eSBhIHNraWxsZnVsIGF0dGFja2VyLiAgT24gdGhlIG90aGVyIGhhbmQsIHRoZSBJUFNlYyByZXBs YXkgcHJldmVudGlvbiBtZWNoYW5pc20gZG9lcyBhZGRyZXNzIHN1Y2ggYXR0YWNrcy4NCg0KU28g d2hpbGUgaXQgbWF5IHNlZW0gdGhhdCBJUFNlYyBkb2VzIGEgYnVuY2ggb2YgdGhpbmdzIHRoYXQg b3RoZXIgcHJvdG9jb2xzIGFscmVhZHkgZG8sIG9yIHNob3VsZCBhbHJlYWR5IGRvLCB0aGlzIGlz IGdlbmVyYWxseSBub3QgdGhlIGNhc2U7IHRoZSBrZXkgZGlmZmVyZW5jZSBpcyDigJxhY2NpZGVu dGFs4oCdIHZzLiDigJxkZWxpYmVyYXRl4oCdIGluIGVhY2ggb2YgdGhlc2UgYXJlYXMuDQoNCglw YXVsDQoNCg== From nobody Tue Dec 16 09:14: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 342511A7002 for ; Tue, 16 Dec 2014 09:13:41 -0800 (PST) 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 1h99apAuENWJ for ; Tue, 16 Dec 2014 09:13:38 -0800 (PST) Received: from mail-qg0-x22d.google.com (mail-qg0-x22d.google.com [IPv6:2607:f8b0:400d:c04::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0E5321A7029 for ; Tue, 16 Dec 2014 09:11:58 -0800 (PST) Received: by mail-qg0-f45.google.com with SMTP id f51so10327511qge.4 for ; Tue, 16 Dec 2014 09:11:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=QTJtZDRzZwRyMYQYwC9vcgoOgPyHQRLKECFgJ0fuf2o=; b=U0ckAzR0BgDLzMPsifxa5ydjzzWjkfyCF1Qq/Ge9Esp9OHJOv14q2nRExlMwEnvO/n yIUH3QPCx++KxS6JKRku+1jMz0pWXcnew1huRHTFxnhLIC06PkXuNQZ+Wbhqq4Fe2jjX NXY5Bhj16RHvXUXbWSzZ12rBp25VD+usTv6maCkzO1fF/gVCfu8wxokdfEI4g35iUXQG HxSlZ9rgQkHCTmB2vv88xmivjLaaUMT2QW13/5GPKg42zmO1e7qHhlGR+TUYjje9hKli LSmD6e8TM1UzzTIKgSYzgtAxsfmz2vmhTu+2Q1x4pPygNlJiZ4XYn6SbmBLbcII3Cnz6 aq5A== MIME-Version: 1.0 X-Received: by 10.140.82.101 with SMTP id g92mr27167593qgd.26.1418749917116; Tue, 16 Dec 2014 09:11:57 -0800 (PST) Received: by 10.140.80.136 with HTTP; Tue, 16 Dec 2014 09:11:57 -0800 (PST) In-Reply-To: <25104.1418666518@sandelman.ca> References: <66CAB7BB-DAC5-4675-82CB-317907C17712@dell.com> <25104.1418666518@sandelman.ca> Date: Tue, 16 Dec 2014 22:41:57 +0530 Message-ID: From: Ashok Kumar To: Michael Richardson Content-Type: multipart/alternative; boundary=001a11c118d0d5c33b050a5874d5 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/RVKhtkWrcRvYts53zWtrcU3MnDA Cc: ipsec@ietf.org, Paul_Koning@dell.com Subject: Re: [IPsec] RFC-4303 - Does ESN really worth/help to reduce/avoid replayed packets? 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, 16 Dec 2014 17:13:41 -0000 --001a11c118d0d5c33b050a5874d5 Content-Type: text/plain; charset=UTF-8 Exactly. Michael has got my observation right. With ESN, the receiver will unnecessarily do MAC calculation for replayed packets which falls before the replay window. The reason is, replayed packets whose sequence number is lesser than the window start, will be considered as newer packet and anti-replay check would be skipped for such packets (as per pseudo code given in the RFC). Thanks, Ashok Kumar On Mon, Dec 15, 2014 at 11:31 PM, Michael Richardson wrote: > > > wrote: > >> Hi All, > >> > >> As per my understanding, the anti-replay feature in IPsec helps to > >> save CPU cycles in the IPsec gateway (or host) by discarding the > >> replayed packets so that costly operation like MAC calculation and > >> decryption can be avoided for such packets. Is my understanding > >> right? > > > No. The anti-replay feature prevents replay attacks. The purpose is > > to avoid delivering duplicate packets to the end system, where > > (depending on the protocol) they might cause applications to > > malfunction. The benefit you describe (to the IPSec gateway) is > > insignificant. > > Paul: what you said is correct about the reply feature. > > But what Ashok observed about the implementation recommendation is also > correct. > > The anti-replay *WINDOW* (a bit map of a particular size) in on the receive > allows the receiver to receive packets out of order, but puts a lower limit > on replay values that will be accepted. Once the window is closed, the > gateway can discard packets without performing a MAC calculation. > The affect on the IPsec gateway is not insignificant if the IPsec gateway > can not perform MAC operations at wire speeds. For much of the life of the > IPsec specification, software implementations of IPsec have been slower > than > line card speeds. It has only been in the past 7 to 9 years that this is > frequently not been the case; and it is still the case for most home > gateways, for instance. > > > > -- > Michael Richardson , Sandelman Software Works > -= IPv6 IoT consulting =- > > > > --001a11c118d0d5c33b050a5874d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Exactly. Michael has got my observatio= n right.

With ESN, the receiver will unnecessarily= do MAC calculation for replayed packets
which falls before the r= eplay window. The reason is, replayed packets whose sequence
numb= er is lesser than the window start, will be considered as newer packet and = anti-replay
check would be skipped for such packets (as per pseud= o code given in the RFC).

Thanks,
Ashok Kumar
<= /div>
On Mon, Dec 15, 2014 at 11:31 PM, Michael Ri= chardson <mcr+ietf@sandelman.ca> wrote:

<Paul_Koning@Dell.com> wrote:
=C2=A0 =C2=A0 >> Hi All,
=C2=A0 =C2=A0 >>
=C2=A0 =C2=A0 >> As per my understanding, the anti-replay feature in = IPsec helps to
=C2=A0 =C2=A0 >> save CPU cycles in the IPsec gateway (or host) by di= scarding the
=C2=A0 =C2=A0 >> replayed packets so that costly operation like MAC c= alculation and
=C2=A0 =C2=A0 >> decryption can be avoided for such packets.=C2=A0 Is= my understanding
=C2=A0 =C2=A0 >> right?

=C2=A0 =C2=A0 > No.=C2=A0 The anti-replay feature prevents replay attack= s.=C2=A0 The purpose is
=C2=A0 =C2=A0 > to avoid delivering duplicate packets to the end system,= where
=C2=A0 =C2=A0 > (depending on the protocol) they might cause application= s to
=C2=A0 =C2=A0 > malfunction.=C2=A0 The benefit you describe (to the IPSe= c gateway) is
=C2=A0 =C2=A0 > insignificant.

Paul: what you said is correct about the reply feature.

But what Ashok observed about the implementation recommendation is also cor= rect.

The anti-replay *WINDOW* (a bit map of a particular size) in on the receive=
allows the receiver to receive packets out of order, but puts a lower limit=
on replay values that will be accepted.=C2=A0 Once the window is closed, th= e
gateway can discard packets without performing a MAC calculation.
The affect on the IPsec gateway is not insignificant if the IPsec gateway can not perform MAC operations at wire speeds.=C2=A0 For much of the life o= f the
IPsec specification, software implementations of IPsec have been slower tha= n
line card speeds.=C2=A0 It has only been in the past 7 to 9 years that this= is
frequently not been the case; and it is still the case for most home
gateways, for instance.



--
Michael Richardson <mcr+IETF@= sandelman.ca>, Sandelman Software Works
=C2=A0-=3D IPv6 IoT consulting =3D-



--001a11c118d0d5c33b050a5874d5-- From nobody Tue Dec 16 09:26: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 720691A6EFC for ; Tue, 16 Dec 2014 09:26:03 -0800 (PST) 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 vc64lrwc4KIc for ; Tue, 16 Dec 2014 09:26:01 -0800 (PST) Received: from mail-qc0-x233.google.com (mail-qc0-x233.google.com [IPv6:2607:f8b0:400d:c01::233]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88F6D1A1EF3 for ; Tue, 16 Dec 2014 09:26:01 -0800 (PST) Received: by mail-qc0-f179.google.com with SMTP id c9so10842247qcz.10 for ; Tue, 16 Dec 2014 09:26:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=9n7kASjzzBV1Ox8PtYNhKvCKbzGzWk7IE2/aTH7MD5k=; b=IKqCtAyGmeEPdoDgS7szn8Sxrr8UAttNJC1iVzkjEdGcjDgBIaspfkIpTMvCdRLhGc ihkgR1xkdvxRDRrKA/i++wn3Y2KBe3hTM4xpWQidHNkeoyuj7/YpdbzvaU4h6yZ8bIsC yEfs4dJ0hCrsJpHs9/IyvFu70+oFrHtOB1101R9rutvbGxE3+Kg1sRJMmQa9+7VWU+2k XON/zwQyvF4DETy0tXdmZOIdQpt62t6JUn23pd4GON0uGs06I38u60MvfV0Wn8KIIGUH EIGp7oVDykaCgw5OCqQDzuE8dKLs014SzpW+LVtinXh4RFkBdXgIPvf4fj75MvtYOrXP njqg== MIME-Version: 1.0 X-Received: by 10.140.20.104 with SMTP id 95mr38426427qgi.47.1418750760743; Tue, 16 Dec 2014 09:26:00 -0800 (PST) Received: by 10.140.80.136 with HTTP; Tue, 16 Dec 2014 09:26:00 -0800 (PST) In-Reply-To: <549030BE.2070007@bbn.com> References: <549030BE.2070007@bbn.com> Date: Tue, 16 Dec 2014 22:56:00 +0530 Message-ID: From: Ashok Kumar To: Stephen Kent Content-Type: multipart/alternative; boundary=001a11c124401e7c4b050a58a7b8 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/tBNDC1qNkcdahebZJmU8DalKoN8 Cc: ipsec Subject: Re: [IPsec] RFC-4303 - Does ESN really worth/help to reduce/avoid replayed packets? 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, 16 Dec 2014 17:26:03 -0000 --001a11c124401e7c4b050a58a7b8 Content-Type: text/plain; charset=UTF-8 Hi Steve, On Tue, Dec 16, 2014 at 6:46 PM, Stephen Kent wrote: > Ashok, > > Hi All, > > As per my understanding, the anti-replay feature in IPsec helps to save > CPU cycles > in the IPsec gateway (or host) by discarding the replayed packets so that > costly > operation like MAC calculation and decryption can be avoided for such > packets. > Is my understanding right? > > only partially. The main reason for this is to protect an app from > receiving > replayed traffic that it might not otherwise detect and reject. Not an > issue for > TCP, but a possible issue for UDP-based apps. > IMHO, the end system/application shouldn't assume that IPsec is deployed in between. Even if IPsec is deployed, the anti-replay may not be enabled. Though anti-replay feature helps to avoid delivering duplicate packets, the application should still be able to handle any potential duplicate packets. > > From "A2.3. Pseudo-Code Example" in RFC-4303, looks like any packet > which > are older than the anti-replay window start, would skip the anti-replay > check > and MAC check will be done. Though MAC check would fail (because Seqh > would be incorrect), MAC calculation would still happens. It is most > likely to > happen for almost all replayed packets in a high throughput tunnel. Isn't > it? > > That's not the intent. The intent is to immediately drop any packet for > which > the sequence number is older than the AR window, thus avoiding crypto > operations > that are not necessary. > Exactly, that was my point too. With ESN (as per pseudo code given in the RFC), the replayed packet whose sequence number is older than window start wouldn't be dropped immediately. It will be dropped only after MAC check as higher 32-bit sequence number taken for MAC would be incorrect for such packets. May be, the pseudo code didn't cover the exact intention. Thanks, Ashok Kumar > Without ESN support, we will discard all packets whose sequence number > is less than the anti-replay window base. So the problem which I see is, > only with ESN support. Please correct me if I am missing something. > > See comments above. > > Steve > --001a11c124401e7c4b050a58a7b8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Steve,

On Tue, Dec 16, 2014 at 6:= 46 PM, Stephen Kent <kent@bbn.com> wrote:
=20 =20 =20
Ashok,
Hi All,

As per my understanding, the anti-replay feature in IPsec helps to save CPU cycles
in the IPsec gateway (or host) by discarding the replayed packets so that costly
operation like MAC calculation and decryption can be avoided for such packets.
Is my understanding right?
 only partially. The main reason for this is to protect an app from receiving
replayed traffic that it might not otherwise detect and reject. Not an issue for
TCP, but a possible issue for UDP-based apps.
IMHO, the end system/application shouldn't assume that IPs= ec is deployed in between.
Even if IPsec is deployed, the anti-re= play may not be enabled. Though anti-replay feature
helps to avoi= d delivering duplicate packets, the application should still be able
<= div>to handle any potential duplicate packets.
=C2=A0

From "A2.3. Pseudo-Code Example" in RFC-4303, looks like any packet which
are older than the anti-replay window start, would skip the anti-replay check
and MAC check will be done. Though MAC check would fail (because Seqh
would be incorrect), MAC calculation would still happens. It is most likely to
happen for almost all replayed packets in a high throughput tunnel. Isn't it?
 That's not the intent. The intent is to immediately drop any packet for which
the sequence number is older than the AR window, thus avoiding crypto operations
that are not necessary.

Exactly, = that was my point too. With ESN (as =C2=A0per pseudo code given in the RFC)= ,
the replayed packet whose sequence number is older than window = start
wouldn't be dropped immediately. It will be dropped onl= y after MAC check
as higher 32-bit sequence number taken for MAC = would be incorrect for
such packets. May be, the pseudo code didn= 't cover the exact intention.

Thanks,
Ashok Kumar


Without ESN support, we will discard all packets whose sequence number
is less than the anti-replay window base. So the problem which I see is,
only with ESN support. Please correct me if I am missing something.
 See comments above.

Steve
--001a11c124401e7c4b050a58a7b8-- From nobody Tue Dec 16 09:31: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 9CE701A6FF5 for ; Tue, 16 Dec 2014 09:31:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 q20uggfqj3-y for ; Tue, 16 Dec 2014 09:31:55 -0800 (PST) Received: from ausc60ps301.us.dell.com (ausc60ps301.us.dell.com [143.166.148.206]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CF1AF1A1B49 for ; Tue, 16 Dec 2014 09:31:54 -0800 (PST) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version:Return-Path; b=qBnbBPlKecaFIYYWvEQm2z1uprsGnrrPGuEi7C6OdeVXqPhG8JeRtjPz khAnq38Uj3DdHx9apIT52SPfRJQoNf7z96WBRQfjhrxBHY4Kg7pfGRpiy 3OWB0dP6zYFuNIzw+XYUlXB9c8pb8aiNhnqITin9gKHwj1ZTTOAiYnkd6 4=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1418751116; x=1450287116; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=fhThgAxz2IBtRNXRZn90mD4pOS3qjDpnVtUr8adCBpw=; b=GQNv3XSheidqNFeV0T/e3M3FwcJ0EiCbzQT6vIT+B73FY8D9wSoMbLpv oj79C4miaAyQEJDW5P2hUuUzz/91qUmj9HcmxeIswh96ct+Jpg+fdIbR+ PTmr9Ulz/TpIyrKW6LfLs+86JiKhkC7ktYNUvnW5WRUWwq+jvLgFbVTI8 M=; X-LoopCount0: from 10.170.28.40 X-IronPort-AV: E=Sophos;i="5.07,587,1413262800"; d="scan'208";a="614655554" From: To: Thread-Topic: [IPsec] RFC-4303 - Does ESN really worth/help to reduce/avoid replayed packets? Thread-Index: AQHQGIObq94+fYaO502FOt0r2zUijpyRPE+AgAAZrgCAAYRcgIAABX0A Date: Tue, 16 Dec 2014 17:31:37 +0000 Message-ID: References: <66CAB7BB-DAC5-4675-82CB-317907C17712@dell.com> <25104.1418666518@sandelman.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.135.94] Content-Type: text/plain; charset="utf-8" Content-ID: <32F74A9D9EBEDD4E9B2AEE9462F4797F@dell.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/-vamybji0cpNB31gr0RGWiODO64 Cc: ipsec@ietf.org, mcr+ietf@sandelman.ca Subject: Re: [IPsec] RFC-4303 - Does ESN really worth/help to reduce/avoid replayed packets? 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, 16 Dec 2014 17:31:57 -0000 DQo+IE9uIERlYyAxNiwgMjAxNCwgYXQgMTI6MTEgUE0sIEFzaG9rIEt1bWFyIDxhc2hva2FyQGdt YWlsLmNvbT4gd3JvdGU6DQo+IA0KPiANCj4gRXhhY3RseS4gTWljaGFlbCBoYXMgZ290IG15IG9i c2VydmF0aW9uIHJpZ2h0Lg0KPiANCj4gV2l0aCBFU04sIHRoZSByZWNlaXZlciB3aWxsIHVubmVj ZXNzYXJpbHkgZG8gTUFDIGNhbGN1bGF0aW9uIGZvciByZXBsYXllZCBwYWNrZXRzDQo+IHdoaWNo IGZhbGxzIGJlZm9yZSB0aGUgcmVwbGF5IHdpbmRvdy4gVGhlIHJlYXNvbiBpcywgcmVwbGF5ZWQg cGFja2V0cyB3aG9zZSBzZXF1ZW5jZQ0KPiBudW1iZXIgaXMgbGVzc2VyIHRoYW4gdGhlIHdpbmRv dyBzdGFydCwgd2lsbCBiZSBjb25zaWRlcmVkIGFzIG5ld2VyIHBhY2tldCBhbmQgYW50aS1yZXBs YXkNCj4gY2hlY2sgd291bGQgYmUgc2tpcHBlZCBmb3Igc3VjaCBwYWNrZXRzIChhcyBwZXIgcHNl dWRvIGNvZGUgZ2l2ZW4gaW4gdGhlIFJGQykuDQoNCkl04oCZcyB0cml2aWFsIGZvciBhbiBhdHRh Y2tlciB0byBmb3JjZSB0aGUgcmVjZWl2ZXIgdG8gZG8gTUFDIGNhbGN1bGF0aW9uczsgYWxsIHRo YXQgaGUgbmVlZHMgdG8gZG8gaXMgc2VuZCBwYWNrZXRzIHdpdGggbmV3IHNlcXVlbmNlIG51bWJl cnMuDQoNCllvdeKAmXJlIHJpZ2h0LCBpZiBFU04gaXMgbm90IGluIHVzZSwgc2VxdWVuY2UgbnVt YmVycyBiZWxvdyB0aGUgd2luZG93IGFyZSByZWNvZ25pemVkIGFzIG9sZCwgd2hpbGUgd2l0aCBF U04gdGhleSBhcmUgYXNzdW1lZCB0byBiZSBuZXcgKHdpdGggdGhlIG5leHQgaGlnaGVyIHZhbHVl IG9mIHRoZSB1cHBlciBzZXF1ZW5jZSBudW1iZXIpLiAgQnV0IGVpdGhlciB3YXksIGFueSByZXBs YXkgd2lsbCBiZSByZWplY3RlZCAocG9zc2libHkgd2l0aG91dCByZXF1aXJpbmcgYSBNQUMgY2hl Y2ssIHBvc3NpYmx5IHdpdGgpLg0KDQpUaGlzIGlzIHdoeSBJIHNheSB0aGF0IHRoZSBwdXJwb3Nl IG9mIHNlcXVlbmNlIG51bWJlcnMgaXMgdG8gcHJldmVudCByZXBsYXksIGFuZCB0aGF0IG9wdGlt aXppbmcgdGhlIElQU2VjIHJlY2VpdmUgcHJvY2Vzc2luZyBpcyBub3QgYSBnb2FsLg0KDQoJcGF1 bA0K From nobody Tue Dec 16 09:36: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 9336F1A6EFC for ; Tue, 16 Dec 2014 09:36:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 4_T7Qs7YyXy8 for ; Tue, 16 Dec 2014 09:36:15 -0800 (PST) Received: from ausxippc110.us.dell.com (AUSXIPPC110.us.dell.com [143.166.85.200]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FFA51A6FEB for ; Tue, 16 Dec 2014 09:36:15 -0800 (PST) DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator:x-originating-ip: Content-Type:Content-ID:Content-Transfer-Encoding: MIME-Version:Return-Path; b=QEBt68+KT2R6W35rDimm5nYtSNgP+FZoZxG3LsSmNfL+LfnLSidvlJQa IIfO1+T39hQq0zuDmB+A3Vle8ZQzmLEDk9Vq5RaFln+ZBV4EQQdM0p2Cp 9kSJumdyfs7IlXf3GssuRi/NVffgOFxKeF0vaFXVFBkohkcH4k6LDQGZV A=; DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dell.com; i=@dell.com; q=dns/txt; s=smtpout; t=1418751375; x=1450287375; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=JxEB41kfVYc+eWWInlYQQxqxJn6UTqyR8GNuxGStzOA=; b=KysjUHSFHIB5kzFLy5+2ohGktLg5pZtWAZ58a3e0MvxWRLSmb05Is/ro Nnr/lX7aPg4t1GIkolVxiUqGoqVqfj/vTtpXi0AjGWnpWr44YiaNs/w+b Q7knXLMO8SrpuCO5Xd6jDjMyrJH9vP8A6OenN9pi3shmYCJWDrHO0egJ0 k=; X-LoopCount0: from 10.175.216.250 X-IronPort-AV: E=Sophos;i="5.07,588,1413262800"; d="scan'208";a="104707613" From: To: Thread-Topic: [IPsec] RFC-4303 - Does ESN really worth/help to reduce/avoid replayed packets? Thread-Index: AQHQGIObq94+fYaO502FOt0r2zUijpySmKMAgABFogCAAALZgA== Date: Tue, 16 Dec 2014 17:36:12 +0000 Message-ID: References: <549030BE.2070007@bbn.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.166.135.94] Content-Type: text/plain; charset="utf-8" Content-ID: <37A9E041752F464097FCDE9533A90629@dell.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/fwUVvU1dZORXXG3-vX3_a6IGtnA Cc: ipsec@ietf.org, kent@bbn.com Subject: Re: [IPsec] RFC-4303 - Does ESN really worth/help to reduce/avoid replayed packets? 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, 16 Dec 2014 17:36:16 -0000 DQo+IE9uIERlYyAxNiwgMjAxNCwgYXQgMTI6MjYgUE0sIEFzaG9rIEt1bWFyIDxhc2hva2FyQGdt YWlsLmNvbT4gd3JvdGU6DQo+IC4uLg0KPiBJTUhPLCB0aGUgZW5kIHN5c3RlbS9hcHBsaWNhdGlv biBzaG91bGRuJ3QgYXNzdW1lIHRoYXQgSVBzZWMgaXMgZGVwbG95ZWQgaW4gYmV0d2Vlbi4NCj4g RXZlbiBpZiBJUHNlYyBpcyBkZXBsb3llZCwgdGhlIGFudGktcmVwbGF5IG1heSBub3QgYmUgZW5h YmxlZC4NCg0KQnV0IGFsbCB1c2VmdWwgSVBTZWMgZGVwbG95bWVudHMgaGF2ZSBhbnRpLXJlcGxh eSBlbmFibGVkLiAgU2VlIFN0ZXZlIEJlbGxvdmlu4oCZcyBwYXBlciBmb3Igd2h5IHRoYXQgaXMg c28uDQoNCkVuZCBzeXN0ZW1zIG5lZWQgY3J5cHRvZ3JhcGhpYyBtZWNoYW5pc21zIGlmIHRoZSBl bnZpcm9ubWVudCBpcyBqdWRnZWQgdG8gYmUgc3ViamVjdCB0byBtYWxpY291cyBhdHRhY2suICBJ UFNlYyBpcyBvbmUgZ29vZCBtZWNoYW5pc20gb2YgdGhhdCBraW5kOyB0aGVyZSBhcmUgb3RoZXJz ICh0aG91Z2ggZ2l2ZW4gcmVjZW50IGhpc3RvcnksIG15IGZpcnN0IHByZWZlcmVuY2UgaXMgSVBT ZWMgaWYgcG9zc2libGUpLiAgQXBwbGljYXRpb25zIGNhbiBhbHNvIGJ1aWxkIGluIHRoZWlyIG93 biBjcnlwdG8gbWVjaGFuaXNtcyByYXRoZXIgdGhhbiBoYXZpbmcgbG93ZXIgbGF5ZXJzIHByb3Zp ZGUgdGhlIHNlcnZpY2UsIGJ1dCBkb2luZyBzbyBpcyB2ZXJ5IGhhcmQgYW5kIHF1aXRlIHJpc2t5 Lg0KDQoJcGF1bA0KDQo= From nobody Tue Dec 16 09:40:17 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 ED7811A7013 for ; Tue, 16 Dec 2014 09:40:14 -0800 (PST) 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 dZTrZePQ8Pi8 for ; Tue, 16 Dec 2014 09:40:13 -0800 (PST) Received: from mail-qc0-x231.google.com (mail-qc0-x231.google.com [IPv6:2607:f8b0:400d:c01::231]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 41D891A7011 for ; Tue, 16 Dec 2014 09:40:13 -0800 (PST) Received: by mail-qc0-f177.google.com with SMTP id x3so10559117qcv.22 for ; Tue, 16 Dec 2014 09:40:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=hNAPU3eGcTtOW+DzhP1x1c78VIpJ+MkjX9c17G6arqU=; b=zwDd2iqQKnMOTNat0EMYtol3ntSjXGe4vkZDpwBmh0ic/0XwoIRuN9H6TSgQg8GC7+ NPEJhNvZCGfoGxRRAZeNipXb0NQnTnpa9Xhvs9vTQtsrNV+lLhFvQrgQLlRJ+SFe94iV 5+VGZbvJbcAgh9/rUq3INe7iOEWOGaZr3w35rQ1Z+25nSxc98s5QUAShk1tFtYgF8P41 0AAWjBRRScGb3lgtq+/qZIr6evtHKoVYNc38BWan3N/gPOmYPOTBdRtYoEfapwSx1PjI FTTln6iLdEGqRBcNOu48M6ktUlqfYhjhrSJDOqnbpxhXKIPd5M4ZrXGV+pSnASdzyHZX rMzw== MIME-Version: 1.0 X-Received: by 10.140.96.195 with SMTP id k61mr63068897qge.104.1418751612408; Tue, 16 Dec 2014 09:40:12 -0800 (PST) Received: by 10.140.80.136 with HTTP; Tue, 16 Dec 2014 09:40:12 -0800 (PST) In-Reply-To: References: <66CAB7BB-DAC5-4675-82CB-317907C17712@dell.com> <25104.1418666518@sandelman.ca> Date: Tue, 16 Dec 2014 23:10:12 +0530 Message-ID: From: Ashok Kumar To: Paul_Koning@dell.com Content-Type: multipart/alternative; boundary=001a113ace06e1dcf2050a58d939 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/wvZVEhaSjDf-T1ZjdndKMXmI1gk Cc: ipsec , Michael Richardson Subject: Re: [IPsec] RFC-4303 - Does ESN really worth/help to reduce/avoid replayed packets? 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, 16 Dec 2014 17:40:15 -0000 --001a113ace06e1dcf2050a58d939 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Thanks Paul, Michael and Steve! That clarifies my question. Regards, Ashok Kumar On Tue, Dec 16, 2014 at 11:01 PM, wrote: > > > > On Dec 16, 2014, at 12:11 PM, Ashok Kumar wrote: > > > > > > Exactly. Michael has got my observation right. > > > > With ESN, the receiver will unnecessarily do MAC calculation for > replayed packets > > which falls before the replay window. The reason is, replayed packets > whose sequence > > number is lesser than the window start, will be considered as newer > packet and anti-replay > > check would be skipped for such packets (as per pseudo code given in th= e > RFC). > > It=E2=80=99s trivial for an attacker to force the receiver to do MAC calc= ulations; > all that he needs to do is send packets with new sequence numbers. > > You=E2=80=99re right, if ESN is not in use, sequence numbers below the wi= ndow are > recognized as old, while with ESN they are assumed to be new (with the ne= xt > higher value of the upper sequence number). But either way, any replay > will be rejected (possibly without requiring a MAC check, possibly with). > > This is why I say that the purpose of sequence numbers is to prevent > replay, and that optimizing the IPSec receive processing is not a goal. > > paul > --001a113ace06e1dcf2050a58d939 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Thanks Paul, Michael and Steve!

That clarifies my question.

Regards,Ashok Kumar

On Tue, Dec 16, 2014 at 11:01 PM, <Paul= _Koning@dell.com> wrote:

> On Dec 16, 2014, at 12:11 PM, Ashok Kumar <ashokar@gmail.com> wrote:
>
>
> Exactly. Michael has got my observation right.
>
> With ESN, the receiver will unnecessarily do MAC calculation for repla= yed packets
> which falls before the replay window. The reason is, replayed packets = whose sequence
> number is lesser than the window start, will be considered as newer pa= cket and anti-replay
> check would be skipped for such packets (as per pseudo code given in t= he RFC).

It=E2=80=99s trivial for an attacker to force the receiver to do MAC= calculations; all that he needs to do is send packets with new sequence nu= mbers.

You=E2=80=99re right, if ESN is not in use, sequence numbers below the wind= ow are recognized as old, while with ESN they are assumed to be new (with t= he next higher value of the upper sequence number).=C2=A0 But either way, a= ny replay will be rejected (possibly without requiring a MAC check, possibl= y with).

This is why I say that the purpose of sequence numbers is to prevent replay= , and that optimizing the IPSec receive processing is not a goal.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 paul
--001a113ace06e1dcf2050a58d939-- From nobody Tue Dec 23 05:45:44 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 8C0261A039D for ; Tue, 23 Dec 2014 05:45:34 -0800 (PST) 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 7RfabCy1eP1c for ; Tue, 23 Dec 2014 05:45:28 -0800 (PST) Received: from mail-lb0-x236.google.com (mail-lb0-x236.google.com [IPv6:2a00:1450:4010:c04::236]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2725F1ACE06 for ; Tue, 23 Dec 2014 05:45:27 -0800 (PST) Received: by mail-lb0-f182.google.com with SMTP id f15so5939844lbj.27 for ; Tue, 23 Dec 2014 05:45:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2uIEDJieuwFNddnblnaEXcOpQbp6SBAw5DyvaWwklPU=; b=GbMJQ6MC3Itl00RzWbSiMd+2NGdTyaTRp8IautfHA2SXVvlsl6gsfaSUlPfc84nsYA XXJbiRMfXlTijIpPKtg/GGgZtqDrdvUYuChTcfjYSRvj4/ax/s86JH0c8eC9PZ9X7V6p F3meX6aO+7T3Euv0ZiWje2+MLlvMgUs4++YxkwZ/w1SikwiqG13DJ2Cb3VQhh1iHeygW BpHVn7eZ6ZuDpySOubYjBjWwTJR7B5Uxs344uhD3Qxqfergm3joqL6Usb74p887qNFuv sRPaahtNkt0n8b9hF9/jp/vcDuy4BNrOAPIQGxWyqjlowzWoR+Wn39jqtjkE31K2ZBqz j4PA== MIME-Version: 1.0 X-Received: by 10.112.211.130 with SMTP id nc2mr27862938lbc.0.1419342325566; Tue, 23 Dec 2014 05:45:25 -0800 (PST) Received: by 10.112.49.52 with HTTP; Tue, 23 Dec 2014 05:45:25 -0800 (PST) In-Reply-To: <21647.18443.148411.872644@fireball.kivinen.iki.fi> References: <2CBE2213-E3B6-4E0C-95EC-D1DFB05D3A0E@vpnc.org> <548BF356.1000403@sfc.wide.ad.jp> <52EFE4AC-47EC-4EF8-956A-44ECF887A78F@vpnc.org> <21647.18443.148411.872644@fireball.kivinen.iki.fi> Date: Tue, 23 Dec 2014 08:45:25 -0500 Message-ID: From: Kathleen Moriarty To: Tero Kivinen Content-Type: text/plain; charset=UTF-8 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/ldtW4xy73q84Pf4pWt1_8mQoBK0 Cc: IPsecME WG , Shota Nagayama , Paul Hoffman Subject: Re: [IPsec] Survey for WG interest in adopting draft-nagayama-ipsecme-ipsec-with-qkd 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, 23 Dec 2014 13:45:34 -0000 On Mon, Dec 15, 2014 at 3:43 PM, Tero Kivinen wrote: > Paul Hoffman writes: >> Please note that the conclusion of this survey was that the WG was >> not going to adopt the document. The chairs asked that the authors >> set up their own discussion fora if they want to continue >> discussion. Announcing new versions of non-WG drafts on this list is >> fine, but trying to keep the discussion alive here is not. > > I do not agree on that. The ipsec is the ietf list for ipsec related > discussion. It was originally for ipsec WG and when IPsecME was formed > we decided to use same mailing list, and I think that at point the > idea was that mailing list should be used with all ipsec related > discussions. > > The discussion about those draft has not been that overwhelming that > we would need to create separate mailing list for that. If you are > going to say that most of the active working group participants (I > think most of the really active working group participants did answer > to question, but there might be few missing) are not enough for draft > to be working group document, and then you say that we cannot even > discuss it on the ipsec list I think that is not ok. > > I do not want to joining several different mailing list for short time > to discuss about each draft the chairs feel should not be adopted on > the wg and then the lists would most likely be silent forever (except > of course the mandatory spams). Sorry for my delayed response, I was on vacation and found one of the few places that has really bad access (data roaming). I agree with Tero. This should be discussed on list as that is the purpose of this list. If there is enough support, the draft can be later added as a WG draft, but list members can work on it to develop it to that point. If it does not become a WG draft, this will help me to decide if the draft should be an individual submission or ISE. As Tero said, many of the active participants chimed in, so there may be enough support for an AD sponsored draft minimally. Thank you, Kathleen > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec -- Best regards, Kathleen From nobody Sat Dec 27 12:12: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 EAEE31A9153; Sat, 27 Dec 2014 12:12:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.26 X-Spam-Level: X-Spam-Status: No, score=-2.26 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] 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 jrr0b-AoLUd1; Sat, 27 Dec 2014 12:12:26 -0800 (PST) Received: from mx2.eict.de (mx2.eict.de [212.91.241.168]) by ietfa.amsl.com (Postfix) with ESMTP id 7CEBA1A9152; Sat, 27 Dec 2014 12:12:26 -0800 (PST) Received: by mx2.eict.de (Postfix, from userid 481) id 380F71FF4F; Sat, 27 Dec 2014 21:12:25 +0100 (CET) Received: from mail.eict.de (mx1 [172.16.6.1]) by mx2.eict.de (Postfix) with ESMTP id 5479F1FF47; Sat, 27 Dec 2014 21:12:24 +0100 (CET) Received: from sbs2008.eict.local (sbs2008.intern.eict.de [192.168.2.11]) by mail.eict.de (Postfix) with ESMTP id D3F7D378238; Sat, 27 Dec 2014 21:12:23 +0100 (CET) Received: from SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298]) by SBS2008.eict.local ([fe80::2051:ef24:c7c9:f298%13]) with mapi; Sat, 27 Dec 2014 21:12:23 +0100 From: Kostas Pentikousis To: "ippm@ietf.org" , "ipsec@ietf.org" Date: Sat, 27 Dec 2014 21:12:22 +0100 Thread-Topic: New Version Notification for draft-ietf-ippm-ipsec-07.txt Thread-Index: AdAiC6zxCbWVQLhEQ4a73n6+6VyUugAAFNfA Message-ID: <0C7EDCF89AB9E2478B5D010026CFF4AEB5AB607753@SBS2008.eict.local> Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/aom_TZCwGx2fVpbUUWjye27xHY8 Subject: [IPsec] WG: New Version Notification for draft-ietf-ippm-ipsec-07.txt 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, 27 Dec 2014 20:12:29 -0000 RGVhciBhbGwgQElQUE0gYW5kIEBJUFNFQywNCg0KV2UgaGF2ZSB1cGRhdGVkIGRyYWZ0LWlldGYt aXBwbS1pcHNlYyB0byBhZGRyZXNzIHRoZSBpc3N1ZSB0aGF0IGFyb3NlIGR1cmluZyB0aGUgc2hl cGhlcmQgcmV2aWV3IChJQU5BIGNvbnNpZGVyYXRpb25zKS4NCg0KUGxlYXNlIGxldCB1cyBrbm93 IGlmIHlvdSBoYXZlIGFueSBmaW5hbCBjb21tZW50cyBhbmQgc3VnZ2VzdGlvbnMuDQoNCkJlc3Qg cmVnYXJkcywNCg0KS29zdGFzDQoNCg0KLS0tLS1VcnNwcsO8bmdsaWNoZSBOYWNocmljaHQtLS0t LQ0KVm9uOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmddIA0KR2VzZW5kZXQ6IFNhbXN0YWcsIDI3LiBEZXplbWJlciAyMDE0IDIwOjMxDQpB bjogWWFuZyBDdWk7IEVtbWEgWmhhbmc7IEVtbWEgWmhhbmc7IFlhbmcgQ3VpOyBLb3N0YXMgUGVu dGlrb3VzaXM7IEtvc3RhcyBQZW50aWtvdXNpcw0KQmV0cmVmZjogTmV3IFZlcnNpb24gTm90aWZp Y2F0aW9uIGZvciBkcmFmdC1pZXRmLWlwcG0taXBzZWMtMDcudHh0DQoNCg0KQSBuZXcgdmVyc2lv biBvZiBJLUQsIGRyYWZ0LWlldGYtaXBwbS1pcHNlYy0wNy50eHQgaGFzIGJlZW4gc3VjY2Vzc2Z1 bGx5IHN1Ym1pdHRlZCBieSBLb3N0YXMgUGVudGlrb3VzaXMgYW5kIHBvc3RlZCB0byB0aGUgSUVU RiByZXBvc2l0b3J5Lg0KDQpOYW1lOgkJZHJhZnQtaWV0Zi1pcHBtLWlwc2VjDQpSZXZpc2lvbjoJ MDcNClRpdGxlOgkJSUtFdjItYmFzZWQgU2hhcmVkIFNlY3JldCBLZXkgZm9yIE8vVFdBTVANCkRv Y3VtZW50IGRhdGU6CTIwMTQtMTItMjcNCkdyb3VwOgkJaXBwbQ0KUGFnZXM6CQkxMw0KVVJMOiAg ICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYt aXBwbS1pcHNlYy0wNy50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1pZXRmLWlwcG0taXBzZWMvDQpIdG1saXplZDogICAgICAgaHR0cDov L3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1pcHBtLWlwc2VjLTA3DQpEaWZmOiAgICAg ICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQtaWV0Zi1pcHBtLWlw c2VjLTA3DQoNCkFic3RyYWN0Og0KICAgVGhlIE8vVFdBTVAgc2VjdXJpdHkgbWVjaGFuaXNtIHJl cXVpcmVzIHRoYXQgYm90aCB0aGUgY2xpZW50IGFuZA0KICAgc2VydmVyIGVuZHBvaW50cyBwb3Nz ZXNzIGEgc2hhcmVkIHNlY3JldC4gIFNpbmNlIHRoZSBjdXJyZW50bHktDQogICBzdGFuZGFyZGl6 ZWQgTy9UV0FNUCBzZWN1cml0eSBtZWNoYW5pc20gb25seSBzdXBwb3J0cyBhIHByZS1zaGFyZWQN CiAgIGtleSBtb2RlLCBsYXJnZSBzY2FsZSBkZXBsb3ltZW50IG9mIE8vVFdBTVAgaXMgaGluZGVy ZWQNCiAgIHNpZ25pZmljYW50bHkuICBBdCB0aGUgc2FtZSB0aW1lLCByZWNlbnQgdHJlbmRzIHBv aW50IHRvIHdpZGVyIElLRXYyDQogICBkZXBsb3ltZW50IHdoaWNoLCBpbiB0dXJuLCBjYWxscyBm b3IgbWVjaGFuaXNtcyBhbmQgbWV0aG9kcyB0aGF0DQogICBlbmFibGUgdHVubmVsIGVuZC11c2Vy cywgYXMgd2VsbCBhcyBvcGVyYXRvcnMsIHRvIG1lYXN1cmUgb25lLXdheSBhbmQNCiAgIHR3by13 YXkgbmV0d29yayBwZXJmb3JtYW5jZSBpbiBhIHN0YW5kYXJkaXplZCBtYW5uZXIuICBUaGlzIGRv Y3VtZW50DQogICBkaXNjdXNzZXMgdGhlIHVzZSBvZiBrZXlzIGRlcml2ZWQgZnJvbSBhbiBJS0V2 MiBTQSBhcyB0aGUgc2hhcmVkIGtleQ0KICAgaW4gTy9UV0FNUC4gIElmIHRoZSBzaGFyZWQga2V5 IGNhbiBiZSBkZXJpdmVkIGZyb20gdGhlIElLRXYyIFNBLCBPLw0KICAgVFdBTVAgY2FuIHN1cHBv cnQgY2VydGlmaWNhdGUtYmFzZWQga2V5IGV4Y2hhbmdlLCB3aGljaCB3b3VsZCBhbGxvdw0KICAg Zm9yIG1vcmUgb3BlcmF0aW9uYWwgZmxleGliaWxpdHkgYW5kIGVmZmljaWVuY3kuICBUaGUga2V5 IGRlcml2YXRpb24NCiAgIHByZXNlbnRlZCBpbiB0aGlzIGRvY3VtZW50IGNhbiBhbHNvIGZhY2ls aXRhdGUgYXV0b21hdGljIGtleQ0KICAgbWFuYWdlbWVudC4NCg0KICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWlu dXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNp b24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYg U2VjcmV0YXJpYXQNCg0K From nobody Wed Dec 31 21:13: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 8DCC81A003B for ; Wed, 31 Dec 2014 21:13:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 PcFTUvZ68hp2; Wed, 31 Dec 2014 21:13:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id D65691A005A; Wed, 31 Dec 2014 21:13:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: "Yaron Sheffer" , "Paul E. Hoffman" , ipsec@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150101051331.6009.80534.idtracker@ietfa.amsl.com> Date: Wed, 31 Dec 2014 21:13:31 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/-lW4e-ZO0wde7tGsaP3PNhL_F5A Subject: [IPsec] State changed: charter-ietf-ipsecme-09-01 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2015 05:13:34 -0000 State changed to Internal review. URL: http://datatracker.ietf.org/doc/charter-ietf-ipsecme/ From nobody Wed Dec 31 21:14:00 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 266941A0069; Wed, 31 Dec 2014 21:13:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 IJ5gb7IKzVGM; Wed, 31 Dec 2014 21:13:56 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 163A81A003B; Wed, 31 Dec 2014 21:13:56 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit To: "Yaron Sheffer" , ipsec@ietf.org, "Paul E. Hoffman" , iesg-secretary@ietf.org, iesg@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.10.0.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150101051356.4158.6369.idtracker@ietfa.amsl.com> Date: Wed, 31 Dec 2014 21:13:56 -0800 From: IETF Secretariat Archived-At: http://mailarchive.ietf.org/arch/msg/ipsec/7FklxthvQyELXLPifcuDI8kX90o Subject: [IPsec] Telechat update notice: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.15 List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jan 2015 05:13:57 -0000 Telechat date has been changed to 2015-01-08 from 2013-01-10 ID Tracker URL: http://datatracker.ietf.org/doc/charter-ietf-ipsecme/