From nobody Mon Feb 1 15:18:47 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 022781B388B; Mon, 1 Feb 2016 15:18:46 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.13.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160201231846.14339.27829.idtracker@ietfa.amsl.com> Date: Mon, 01 Feb 2016 15:18:46 -0800 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-safecurves-01.txt 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: Mon, 01 Feb 2016 23:18:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Curve25519 and Curve448 for IKEv2 Key Agreement Authors : Yoav Nir Simon Josefsson Filename : draft-ietf-ipsecme-safecurves-01.txt Pages : 5 Date : 2016-02-01 Abstract: This document describes the use of Curve25519 and Curve448 for ephemeral key exchange in the Internet Key Exchange (IKEv2) protocol. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-safecurves/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-safecurves-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-safecurves-01 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 1 15:26:35 2016 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 257341B389F for ; Mon, 1 Feb 2016 15:26:33 -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 uM-L5bflICET for ; Mon, 1 Feb 2016 15:26:26 -0800 (PST) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 833581B3891 for ; Mon, 1 Feb 2016 15:26:26 -0800 (PST) Received: by mail-wm0-x22d.google.com with SMTP id l66so93019602wml.0 for ; Mon, 01 Feb 2016 15:26:26 -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=+nMXW29Lb3TJ/fNTh2YiXvvWXsoPBX/jwpr2FvZ7f8E=; b=XNo9+dBl4pEkOMbFrkaVN0xHWeN6iUpL2SyRgJ1UzjtNrQ9khBcegwdmxgso5BpLjt rvuuSSb44NmeuhuUsB0+QIiBBX21UTJjSXr/Vu6ywIIcjfZJEBowYyWUUfuq+KzC5NgM RLY5de8DU/6lsw5KZecP9BXn6XxRmqUu+PzqtdJONS8nES7IM3iapk6ojerPjyyY6cmP RPMhVE5jgAmuHxEgpAbwD0caEW8UQV04xppy7hqUNMUQpDjCSLKmWrYFWmy/GmtWuLz8 az9eorb3rtaqDWUr107eVY8531cKUDt+H2mILlF6QSdgfMKCudOti+s6zOiTqH/oVfHj 4n4w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=+nMXW29Lb3TJ/fNTh2YiXvvWXsoPBX/jwpr2FvZ7f8E=; b=ZIxG7zsG/JpE/H8UX0s1K0HHTB3lRyyp+9syUObEEutusXpGPOnuuaUYAKp6DqsaoF gjRej2YXg7ER0TK+0llfj/UlJFDJdJ6Gx2YtzjUazEiS3rCDY+CVoaiYM+bI8rCRuqUA KXtjVF7konHrAjRYXfdKMplnMk2EBiX3vAsqR1Kcn9gtt58UYThNH7nZWHWZqXb6UguW 27g1SrobzOlYr3Z/UzJb5U+i8OnSXGpppIHtLioh8tZP9oS19f/hrvvxUEMvlgDr41VP bOWRG0OShShmf08dIdmbKWm7gov7QPy+5Sc1yXEXZWMT+VCr3nrw7cnhkpM4t4dAKiH6 KINg== X-Gm-Message-State: AG10YOQ2D0ZxushBPEFMHavRY74dQrrXpbC1TWae2IyWVVdrbfit/bNvjo53ZUtLDjfdGQ== X-Received: by 10.194.83.136 with SMTP id q8mr24888288wjy.51.1454369185157; Mon, 01 Feb 2016 15:26:25 -0800 (PST) Received: from [192.168.1.13] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id t195sm13752069wme.13.2016.02.01.15.26.23 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 01 Feb 2016 15:26:23 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: <20160201231846.14339.27829.idtracker@ietfa.amsl.com> Date: Tue, 2 Feb 2016 01:26:22 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <994E9F5F-AA8A-49B9-9B1F-CB9F11CD004F@gmail.com> References: <20160201231846.14339.27829.idtracker@ietfa.amsl.com> To: "ipsec@ietf.org WG" X-Mailer: Apple Mail (2.3112) Archived-At: Cc: Simon Josefsson Subject: Re: [IPsec] I-D Action: draft-ietf-ipsecme-safecurves-01.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: Mon, 01 Feb 2016 23:26:33 -0000 Hi. Differences in this version: - Changed the reference from CFRG draft to RFC 7748 - A few editorial fixes The analogous TLS draft (draft-ietf-tls-rfc4492bis) is still waiting for = CFRG to complete its work on signatures.=20 In my opinion, we don=E2=80=99t have to wait. The CFRG EdDSA draft will = provide formats and OIDs (I hope). RFC 7427 allows us to use signatures = with only an OID and a format without needing to assign numbers or = invent IKE-specific formats. We might want to mention the recommended = algorithm (Ed25519 and Ed448, but not the =E2=80=9Cph=E2=80=9D versions) = in RFC 4307bis, but I don=E2=80=99t think we need it here. Given this, I think it could be time to progress this draft. Yoav > On 2 Feb 2016, at 1:18 AM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the IP Security Maintenance and = Extensions Working Group of the IETF. >=20 > Title : Curve25519 and Curve448 for IKEv2 Key = Agreement > Authors : Yoav Nir > Simon Josefsson > Filename : draft-ietf-ipsecme-safecurves-01.txt > Pages : 5 > Date : 2016-02-01 >=20 > Abstract: > This document describes the use of Curve25519 and Curve448 for > ephemeral key exchange in the Internet Key Exchange (IKEv2) = protocol. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-ipsecme-safecurves/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-ipsecme-safecurves-01 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-safecurves-01 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Tue Feb 9 14:09:04 2016 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A3F041B2AF5; Tue, 9 Feb 2016 14:09:01 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.14.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20160209220901.13052.49853.idtracker@ietfa.amsl.com> Date: Tue, 09 Feb 2016 14:09:01 -0800 Archived-At: Cc: ipsec@ietf.org Subject: [IPsec] I-D Action: draft-ietf-ipsecme-rfc4307bis-03.txt 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: Tue, 09 Feb 2016 22:09:01 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions of the IETF. Title : Algorithm Implementation Requirements and Usage Guidance for IKEv2 Authors : Yoav Nir Tero Kivinen Paul Wouters Daniel Migault Filename : draft-ietf-ipsecme-rfc4307bis-03.txt Pages : 14 Date : 2016-02-09 Abstract: The IPsec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange protocol provides a mechanism to negotiate which algorithms should be used in any given Security Association. To ensure interoperability between different implementations, it is necessary to specify a set of algorithm implementation requirements and Usage guidance to ensure that there is at least one algorithm that all implementations will have available. This document defines the current algorithm implementation requirements and usage guidance of IKEv2. This document does not update the algorithms used for packet encryption using IPsec Encapsulated Security Payload (ESP) The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-ipsecme-rfc4307bis/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-03 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-ipsecme-rfc4307bis-03 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Wed Feb 10 01:46:02 2016 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 020C71A049A for ; Wed, 10 Feb 2016 01:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.372 X-Spam-Level: ** X-Spam-Status: No, score=2.372 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, HELO_DYNAMIC_IPADDR=1.951, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311, RP_MATCHES_RCVD=-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 mrlFIYHX9jKw for ; Wed, 10 Feb 2016 01:45:59 -0800 (PST) Received: from h-62.96.220.36.host.de.colt.net (a.mx.secunet.com [62.96.220.36]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 089821A046D for ; Wed, 10 Feb 2016 01:45:58 -0800 (PST) Received: from localhost (alg1 [127.0.0.1]) by h-62.96.220.36.host.de.colt.net (Postfix) with ESMTP id AE08F1A034D; Wed, 10 Feb 2016 10:45:56 +0100 (CET) X-Virus-Scanned: by secunet Received: from h-62.96.220.36.host.de.colt.net ([127.0.0.1]) by localhost (a.mx.secunet.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id o5KQKHcGqYyN; Wed, 10 Feb 2016 10:45:55 +0100 (CET) Received: from mail-essen-01.secunet.de (unknown [10.53.40.204]) by h-62.96.220.36.host.de.colt.net (Postfix) with ESMTP id 221FA1A032B; Wed, 10 Feb 2016 10:45:55 +0100 (CET) Received: from [10.208.1.99] (10.208.1.99) by mail-essen-01.secunet.de (10.53.40.204) with Microsoft SMTP Server (TLS) id 14.3.266.1; Wed, 10 Feb 2016 10:45:54 +0100 To: Daniel Migault , "ipsec@ietf.org" References: From: Johannes Merkle X-Enigmail-Draft-Status: N1110 Message-ID: <56BB06E9.6080604@secunet.com> Date: Wed, 10 Feb 2016 10:46:17 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.208.1.99] X-EXCLAIMER-MD-CONFIG: 2c86f778-e09b-4440-8b15-867914633a10 Archived-At: Subject: Re: [IPsec] RFC4307bis working version 3 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, 10 Feb 2016 09:46:01 -0000 > Please find the working version of version 03: > https://github.com/mglt/drafts/commit/40e6a1e0e99064b54a328e27f0c3d498c2c7164c > Feel free to provide comments. Given the difficulty and time needed to deprecate cryptographic algorithms, I advocate to disallow DSS for authentication. It is not widely deployed, anyway. And for the digital signature method, why should we require SHA-1? -- Johannes From nobody Wed Feb 10 03:44:06 2016 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 B83221A1BDB for ; Wed, 10 Feb 2016 03:44:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.101 X-Spam-Level: X-Spam-Status: No, score=-1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-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 AoRRV9c1JUEo for ; Wed, 10 Feb 2016 03:44:04 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 A6CEA1A1BCF for ; Wed, 10 Feb 2016 03:44:04 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3q0fPY5pxhz32J; Wed, 10 Feb 2016 12:44:01 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 825Z-z9dOhmX; Wed, 10 Feb 2016 12:44:00 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Wed, 10 Feb 2016 12:44:00 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id DF27F600B883; Wed, 10 Feb 2016 06:43:58 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca DF27F600B883 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DBA33B10EE; Wed, 10 Feb 2016 06:43:58 -0500 (EST) Date: Wed, 10 Feb 2016 06:43:58 -0500 (EST) From: Paul Wouters To: Johannes Merkle In-Reply-To: <56BB06E9.6080604@secunet.com> Message-ID: References: <56BB06E9.6080604@secunet.com> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] RFC4307bis working version 3 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, 10 Feb 2016 11:44:05 -0000 On Wed, 10 Feb 2016, Johannes Merkle wrote: >> Please find the working version of version 03: >> https://github.com/mglt/drafts/commit/40e6a1e0e99064b54a328e27f0c3d498c2c7164c >> Feel free to provide comments. Note we should reference it via: https://tools.ietf.org/html/draft-ietf-ipsecme-rfc4307bis-03 > Given the difficulty and time needed to deprecate cryptographic algorithms, I advocate to disallow DSS for > authentication. It is not widely deployed, anyway. We cannot "disallow" it as it might be in use today. The idea is these series of drafts move things from SHOULD to SHOULD+ to MUST to MUST- to SHOULD NOT to MUST NOT. We are trying to phase things in and out smoothly unless there are strong reasons to speed up this process. > And for the digital signature method, why should we require SHA-1? Because it is very common to use right now. We cannot go from MUST to MUST NOT. Paul From nobody Wed Feb 10 06:48:12 2016 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 0379B1B2B83 for ; Wed, 10 Feb 2016 06:48:12 -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 hbuM-mPq949A for ; Wed, 10 Feb 2016 06:48:10 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DF561B2B76 for ; Wed, 10 Feb 2016 06:48:10 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id g62so29931161wme.0 for ; Wed, 10 Feb 2016 06:48:10 -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=78Aa1H6VewespiI3YO9vw6TiiIfJjVsXV/gPfrBAfJA=; b=C0cuyUhsJubNnQuLrmwGxBm3WSYJDBw9rgcnXJiJ9OVZB7BwmoeBVhXxAnisSC2Dkm 8YhqtS20mfTsN0ZZ7ne40Pvmo9QL5BJ5AaLb38GPYXdt0un/QchhDyDDpeOgDa+reFP+ 8vbZsXRF+5FvBkSBWhRO4uu3XjDJ3YsPuGDFQ7SwxMSYqJZLFUht6tjXdr9knIv5CUja 8wWA/CWLrNe5yH2HxhRKISvi7kjExnRngaRhRI7EA5/d4bDdkPr5D3Lt/o0yIAsx7aIy PyGiDLvdEhvUokS/l9fsA7uIZ5M3HeuVRdyMRHkwLiOuMMwLikN2mG+mgxaHPzswuCns +r4A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:content-transfer-encoding:message-id:references :to; bh=78Aa1H6VewespiI3YO9vw6TiiIfJjVsXV/gPfrBAfJA=; b=kx0ZC8H20r8pcNkxQL4Q5wwl9b51jhUJx4IYT+zeAR2Tl+Wifmrsv5ynpEyEY8J/93 kvJtn2aB1GC7nEg8B/RtAHPUKpBNu2ndh2RiuQDyalPY6chvVLuqFYRwXoxfbtD2is6L NhFU2D6j73BKUR1msxGaX5ELKHOiyVe+fXAMP5RTPtxOaZJZ60L67AK6ZSz/jMorIFK1 goMRzKZFNl4gN+ndnuFhn2khlELR5+X+1nYBzWNjDuCMT+wC75vxMDrais4bBEUWOWjc Ql9aX4LH49XQrultk0hYQk4m7/qQXRJwXw1jYLNPe/zwyBV2E30AB/bmByvqSKohWnTj ZyCw== X-Gm-Message-State: AG10YOQ0Vp1TrBYRTGBIjjruI4bnZZ9JNKnPpzFnbN4oV2Kex9bhbHJN7MtChl7H/X7UVQ== X-Received: by 10.194.142.135 with SMTP id rw7mr40811367wjb.42.1455115688838; Wed, 10 Feb 2016 06:48:08 -0800 (PST) Received: from [172.24.250.160] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id t3sm3305507wjz.11.2016.02.10.06.48.07 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 10 Feb 2016 06:48:07 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: Date: Wed, 10 Feb 2016 16:48:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <28E8C820-7F60-484F-904F-FC59FA3446B8@gmail.com> References: <56BB06E9.6080604@secunet.com> To: Paul Wouters X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "ipsec@ietf.org" , Johannes Merkle Subject: Re: [IPsec] RFC4307bis working version 3 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, 10 Feb 2016 14:48:12 -0000 On 10 Feb 2016, at 1:43 PM, Paul Wouters wrote: >=20 >> And for the digital signature method, why should we require SHA-1? >=20 > Because it is very common to use right now. We cannot go from MUST to > MUST NOT. No, but RFC 4307 says nothing about hashes in signatures (whether RSA(1) = or digital signature(14)). So whatever we recommend here is new. This is even more true for digital signature(14) as we hardly have any = legacy code to maintain backwards compatibility with[1]. Also, unlike in TLS, we did not tie signature algorithms in certificates = to signature algorithms in the protocol, so it=E2=80=99s fine to insist = on SHA2-256 in the protocol while accepting SHA1 in the certificate. At = least it=E2=80=99s fine as far as IKE goes. This is important because = there are all kinds of certificates and CAs that we have to work with, = but I don=E2=80=99t believe there is any modern IKE implementation = (definitely not one that has implemented RFC 7427) that does not support = SHA2-256 at least. So ISTM that we should be fine recommending SHA2-256 at the MUST level = with SHA1 in the SHOULD NOT level (to allow people who manage to = interface old hardware modules to new IKE software) Yoav [1] "legacy code with which to maintain backwards compatibility"?= From nobody Thu Feb 11 04:04:26 2016 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 1C0E51B29E4 for ; Thu, 11 Feb 2016 04:04:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.579 X-Spam-Level: * X-Spam-Status: No, score=1.579 tagged_above=-999 required=5 tests=[BAYES_50=0.8, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLPdqBNYSUkp for ; Thu, 11 Feb 2016 04:04:23 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 EDAB81B29E2 for ; Thu, 11 Feb 2016 04:04:22 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u1BC4H8E011524 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 11 Feb 2016 14:04:17 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u1BC4H1Y025258; Thu, 11 Feb 2016 14:04:17 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22204.30913.71236.788305@fireball.acr.fi> Date: Thu, 11 Feb 2016 14:04:17 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: <28E8C820-7F60-484F-904F-FC59FA3446B8@gmail.com> References: <56BB06E9.6080604@secunet.com> <28E8C820-7F60-484F-904F-FC59FA3446B8@gmail.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 10 min X-Total-Time: 18 min Archived-At: Cc: "ipsec@ietf.org" , Paul Wouters , Johannes Merkle Subject: Re: [IPsec] RFC4307bis working version 3 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, 11 Feb 2016 12:04:25 -0000 Yoav Nir writes: > >> And for the digital signature method, why should we require SHA-1? > > > > Because it is very common to use right now. We cannot go from MUST to > > MUST NOT. > > No, but RFC 4307 says nothing about hashes in signatures (whether > RSA(1) or digital signature(14)). So whatever we recommend here is > new. There are two issues there. The RFC7296 says that SHA-1 is SHOULD for RSA Digital Signatures in section 3.8: RSA Digital Signature 1 Computed as specified in Section 2.15 using an RSA private key with RSASSA-PKCS1-v1_5 signature scheme specified in [PKCS1] (implementers should note that IKEv1 used a different method for RSA signatures). To promote interoperability, implementations that support this type SHOULD support signatures that use SHA-1 as the hash function and SHOULD use SHA-1 as the default hash function when generating signatures. Implementations can use the certificates received from a given peer as a hint for selecting a mutually understood hash function for the AUTH payload signature. Note, however, that the hash algorithm used in the AUTH payload signature doesn't have to be the same as any hash algorithm(s) used in the certificate(s). So for RSA Digital Signatures the SHA-1 was SHOULD, and I think it should still be SHOULD for that, as that is the algorithm everybody are using. Also note, that there is no negotiation for the signature algorithm there, thus if one end picks SHA2-256 and other end does not support it the authentication will simply fail, and there is no way to recover. On the other hand we should be downgrading that method completely over the generic Digital Signature method specified in RFC7427. When using RFC7427 signature there is negotiation for the signature algorithm, providing the algorithm agility. I.e. in that case it is safe to propose SHA-1, SHA-256 etc and then both ends pick one of the algorithms other end supports. For RFC7427 support there is no point of requiring MUST for SHA-1 as all of RFC7427 implementations are new, and they should support SHA2 based algorithms too. I.e. It would be better to say SHA-1 for RFC7427 for SHOULD NOT, and SHA2-256 for MUST. The RFC7427 support is still only SHOULD... > This is even more true for digital signature(14) as we hardly have > any legacy code to maintain backwards compatibility with[1]. Yes. > So ISTM that we should be fine recommending SHA2-256 at the MUST > level with SHA1 in the SHOULD NOT level (to allow people who manage > to interface old hardware modules to new IKE software) Agree for RFC7427. For Old RSA Digital Signatures SHA-1 is the one that is still used, and I think we should keep that SHOULD- or similar. -- kivinen@iki.fi From nobody Thu Feb 11 05:21:56 2016 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 C610A1B3117 for ; Thu, 11 Feb 2016 05:21:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.883 X-Spam-Level: **** X-Spam-Status: No, score=4.883 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FROM_MISSPACED=0.001, FROM_MISSP_EH_MATCH=1.999, J_CHICKENPOX_74=0.6, SPF_NEUTRAL=0.779, TO_NO_BRKTS_FROM_MSSP=0.694, T_FROM_MISSP_DKIM=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 6tPn8rLfkjFF for ; Thu, 11 Feb 2016 05:21:51 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 066481B3011 for ; Thu, 11 Feb 2016 05:21:50 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u1BDLl6l019044 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for ; Thu, 11 Feb 2016 15:21:47 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u1BDLl62026321; Thu, 11 Feb 2016 15:21:47 +0200 (EET) From: "Tero Kivinen <" MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22204.35563.59863.235973@fireball.acr.fi> Date: Thu, 11 Feb 2016 15:21:47 +0200 To: ipsec@ietf.org X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 76 min X-Total-Time: 75 min Archived-At: Subject: [IPsec] Comments to the draft-ietf-ipsecme-rfc4307bis-03 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, 11 Feb 2016 13:21:55 -0000 Here are some comments for the algorithms and some nits we should fix. > 1.1. Updating Algorithm Implementation Requirements and Usage Guidance > > The field of cryptography evolves continiously. New stronger ^^^^^^^^^^^^ Typo. > 2. Conventions Used in This Document ... > SHOULD- This term means the same as SHOULD. However, an algorithm > marked as SHOULD- may be deprecated to a MAY in a future > version of this document. I think we should also mention that it may be deprectated to SHOULD NOT or even MUST NOT in addition to MAY. For example I think SHA-1 might be in that class for now. We need to keep it as SHOULD as it is so widely implemented and is needed for backwards compability, but when it is no longer needed then it will move to SHOULD NOT, or MUST NOT. > 3.1. Type 1 - IKEv2 Encryption Algorithm Transforms ... > +-----------------------------+----------+-------+----------+ > | Name | Status | AEAD? | Comment | > +-----------------------------+----------+-------+----------+ > | ENCR_AES_CBC | MUST- | No | [1] | > | ENCR_CHACHA20_POLY1305 | SHOULD | Yes | | > | AES-GCM with a 16 octet ICV | SHOULD | Yes | [1] | > | ENCR_AES_CCM_8 | SHOULD | Yes | [1][IoT] | > | ENCR_3DES | MAY | No | | > | ENCR_DES | MUST NOT | No | | > +-----------------------------+----------+-------+----------+ I think the table itself is ok, i.e., this is how we want to specify them. > AES-GCM with a 16 octet ICV was not considered as in RFC4307. At the > time RFC4307 was written, AES-GCM was not defined in an IETF > document. AES-GCM was defined for ESP in [RFC4106] and later for > IKEv2 in [RFC5282]. The main motivation for adopting AES-GCM for ESP > is encryption performance as well as key longevity - compared to AES- > CBC for example. This resulted in AES-GCM widely implemented for > ESP. As the load of IKEv2 is expected to remain relatively small, > many IKEv2 implementations do not include AES-GCM. In addition to > its former MAY, this document does not promote AES-GCM to a greater > status than SHOULD so to preserve interoperability between IKEv2 > implementations. Up to here this is ok. > [PAUL: I dont follow the reasoning, as we could > have AES and AES-GCM at MUST level] This document considers AES-GCM > as mandatory to implement to promote the slightly more secure AEAD > method over the traditional encrypt+auth method. Its status is > expected to be raised once widely deployed. This text is leftover, and should be removed, as it is now for SHOULD, not SHOULD+ or MUST. Also I think the ENCR_CHACHA20_POLY1305 is most likely going to be the next MUST to implement algorithm, in the next iteration of this document, if implementations actually start implementing and deploying it. > ENCR_3DES has been downgraded from RFC4307 MUST-. All IKEv2 > implementation already implement ENCR_AES_CBC, so there is no need to > keep ENCR_3DES. In addition, ENCR_CHACHA20_POLY1305 provides a more > modern alternative to AES. [PAUL: removed 'efficient' as we said > above encryption efficiency at the IKE level hardly matters] Remove 'PAUL:' comment. > 3.2. Type 2 - IKEv2 Pseudo-random Function Transforms ... > +-------------------+---------+---------+ > | Name | Status | Comment | > +-------------------+---------+---------+ > | PRF_HMAC_SHA2_256 | MUST | | > | PRF_HMAC_SHA2_512 | SHOULD+ | | > | PRF_HMAC_SHA1 | MUST- | [1] | > | PRF_AES128_CBC | SHOULD | [IoT] | > +-------------------+---------+---------+ Again the table is mostly ok. We need to keep PRF_HMAC_SHA1 as MUST-, as it is the most widely implemented and deployed algorithm. In next version we will move it to lower level. On the other hand we should add other PRFs to the MUST NOT, i.e. say that PRF_HMAC_MD5 is MUST NOT, and perhaps say that PRF_HMAC_TIGER is SHOULD NOT. > 3.3. Type 3 - IKEv2 Integrity Algorithm Transforms > > The algorithms in the below table are negotiated in the SA payload > and used in the ENCR payload. References to the specifications ^^^^ Replace this with Encrypted Payload, just like it is in section 3.1. > +------------------------+--------+---------+ > | Name | Status | Comment | > +------------------------+--------+---------+ > | AUTH_HMAC_SHA2_256_128 | MUST | | > | AUTH_HMAC_SHA2_512_256 | SHOULD | | > | AUTH_HMAC_SHA1_96 | SHOULD | | > | AUTH_AES_XCBC_96 | SHOULD | [IoT] | > +------------------------+--------+---------+ This is not aligned with the PRF section, where we had PRF_HMAC_SHA1 as MUST-, and here we have it as SHOULD. As both are used in the same way, I think we should have MUST- here too. I do not think the AUTH_HMAC_SHA2_256_128 has wide enough imployment base yet to make it only MUST algorithm. Also we might want to add that AUTH_HMAC_MD5_96, AUTH_DES_MAC, AUTH_KPDK_MD5 are MUST NOT. Also perhaps point out that AUTH_MHAC_MD5_128, and AUTH_HMAC_SHA1_160, are not for IKE use and are MUST NOT for IKEv2. > AUTH_HMAC_SHA1_96 has been downgraded from MUST in RFC4307. There is > an industry-wide trend to deprecate its usage. I think MUST- would be better than SHOULD. > 3.4. Type 4 - IKEv2 Diffie-Hellman Group Transforms I think we should add note here saying that attacks against Diffie-Hellman groups are different than against the RSA and other authentication algorithms. To break Diffie-Hellman few years later will provide attacker the information what was transmitted over the IPsec link. To break RSA or DSS used for the authentication will need active attack to fake authentication to gain same effect. Breaking RSA or other authentication algorithms few years later when it is no longer in use does not provide anything. Because of this you need to use greated security margin for the Diffie-Hellman than what you need to do for authentication. This text should either be here, or in the beginning of the section 4 (or in both places). > +--------+----------------------------------------------+-----------+ > | Number | Description | Status | > +--------+----------------------------------------------+-----------+ > | 14 | 2048-bit MODP Group | MUST | > | 19 | 256-bit random ECP group | SHOULD | > | 5 | 1536-bit MODP Group | SHOULD | > | | | NOT | > | 2 | 1024-bit MODP Group | SHOULD | > | | | NOT | > | 1 | 768-bit MODP Group | MUST NOT | > | 22 | 1024-bit MODP Group with 160-bit Prime Order | MUST NOT | > | | Subgroup | | > | 23 | 1024-bit MODP Group with 224-bit Prime Order | MUST NOT | > | | Subgroup | | > | 24 | 1024-bit MODP Group with 256-bit Prime Order | MUST NOT | > | | Subgroup | | > +--------+----------------------------------------------+-----------+ This table is hard to read as SHOULD NOT is split over two lines, It would be better to make this more readable and ensure that SHOULD stays on one line... I do not agree on making groups 22-24 as MUST NOT. I think SHOULD NOT would be better for them than MUST NOT. Provided that you do all the checks specified in the RFC6989 I think they are still secure. > Group 14 or 2048-bit MODP Group is raised from SHOULD+ in RFC4307 as > a replacement for 1024-bit MODP Group. Group 14 is widely > implemented and considered secure Period missing from the end. > Group 19 or 256-bit random ECP group was not specified in RFC4307. > Group 19 is widely implemented and considered secure Period missing from the end. > Group 5 or 1536-bit MODP Group is downgrade from MUST- to SHOULD NOT. > It was specified earlier, but now considered to be vulnerable to be > broken within the next few years by a nation state level attack, so > its security margin is considered too narrow. This is untrue. Group 5 was NOT mentioned in the RFC4307, i.e., it was not MUST-. Correct text would say that "Group 5 or 1536-bit MODP Group was not specified in the RFC4307, but is now considered to be vulnerable to be broken within then next few years by a nation state level attack, so its security margin is considered too narrow". > Group 2 or 1024-bit MODP Group is downgrade from MUST- to SHOULD NOT. > It was specified earlier, but now it is known to be weak against > sufficiently funded attackers using commercially available mass- > computing resources, so its security margin is considered too narrow. > It is expected in the near future to be downgraded to MUST NOT. This text is ok. > Group 1 or 768-bit MODP Group can be broken within hours using cheap > of-the-shelves hardware. It provides no security whatsoever. As is this. > Curve25519 has been designed with performance and security in mind > and have been recommended by CFRG. At the time of writing, the IKEv2 > specification is still at the draft status. This document specifies > it as to encourage its implementation and deployment. If it gets > widely implemented then it most likely will be upgraded to SHOULD or > even MUST in the future. As we do not have Curve25519 listed in the table, we should have text for it either. Remove this text. And yes, when it gets specified, and gets implemented it might change to SHOULD or MUST... > Group 22-24 or 1024-bit MODP Group with 160-bit and 2048-bit MODP > Group with 224-256-bit Prime Order Subgroup are exposed to > synchronization or transcription attacks. This is not really true. To be exposed to the synchronization or transcription attacks it requires the implementations to use broken authentication hash (MD5), and/or use static SPIi and SPIr, and NOT to implement checks listed in the RFC6989. It is ok to say they are SHOULD NOT, as they are slower than other groups, as there is extra modexp to be done to check against small subgroup attack. We should also provide reference to the RFC6989 and say that checks specified in the section 2.2 first bullet MUST be done. > 4. IKEv2 Authentication > > IKEv2 authentication may involve a signatures verification. > Signatures may be used to validate a certificate or to check the > signature of the AUTH value. Cryptographic recommendations regarding > certificate validation are out of scope of this document as what > mandatory implementations are provided by the PKIX WG. This document ^^^^^^^ That WG does not exist anymore, so change that to say PKIX community. > is mostly concerned on signature verification and generation for the > authentication. Here we could add text explaining that braking signature authentication requires breaking it while it is still in use, breaking it few years later does not help, thus security levels are different than with the Diffie-Hellman. Also we should point out RFC4307 did not give any guidance for them. > 4.1. IKEv2 Authentication Method > > +--------+-------------------------+--------+-----------------------+ > | Number | Description | Status | Comment | > +--------+-------------------------+--------+-----------------------+ > | 1 | RSA Digital Signature | MUST | With keys length 2048 | > | 1 | RSA Digital Signature | SHOULD | With keys length | > | | | | 3072/4096 | > | 1 | RSA Digital Signature | MUST | With keys length | > | | | NOT | lower than 2048 | > | 3 | DSS Digital Signature | MAY | | > | 9 | ECDSA with SHA-256 on | SHOULD | | > | | the P-256 curve | | | > | 10 | ECDSA with SHA-384 on | SHOULD | | > | | the P-384 curve | | | > | 11 | ECDSA with SHA-512 on | SHOULD | | > | | the P-521 curve | | | > | 14 | Digital Signature | SHOULD | | > +--------+-------------------------+--------+-----------------------+ I do not agree on MUST NOT for RSA with lower than 2048 bit keys. First of all 2047 bit keys are about same than 2048. Also breaking RSA requires dedicated attack against that specific user. The 1024 bit Diffie-Hellman attacks were based on that everybody uses same group, thus nation wide bodies can do precalcuation for that group and gain speedup for that. For RSA everybody is using different key, thus I do not think there is such issues. I think it would be safe to say that 1024 bit RSA is SHOULD NOT, and anything lower than 1000 bit is MUST NOT, but where the limit goes between SHOULD NOT and MAY is different thing. Perhaps something like: < 1000 bits MUST NOT < 1500 bits SHOULD NOT < 2000 bits MAY < 2500 bits MUST < 5000 bits SHOULD And the whole RSA Digital Signatures method is MUST-. I.e. split this table in two, first one saying: +--------+-------------------------+-----------+ | Number | Description | Status | +--------+-------------------------+-----------+ | 1 | RSA Digital Signature | MUST- | | 3 | DSS Digital Signature | MUST NOT | | 9 | ECDSA with SHA-256 on | SHOULD | | | the P-256 curve | | | 10 | ECDSA with SHA-384 on | SHOULD | | | the P-384 curve | | | 11 | ECDSA with SHA-512 on | SHOULD | | | the P-521 curve | | | 14 | Digital Signature | SHOULD+ | +--------+-------------------------+-----------+ and then have another section to specify the RSA key lengths, which is used for both RSA Digital Signature, and Digital Signature using RSA. > RSA Digital Signature is mostly kept for interoperability. It is > expected to be downgraded in the future as signatures are based on > RSASSA-PKCS1-v1.5, not any more recommemded. Instead, more robust > use of RSA is expected to be performed via the Digital Signature > method. This is good. > ECDSA family are also expected to be downgraded as it does not > provide hash function agility. Instead ECDSA is expected to be > performed using the generic Digital Signature method. If we are expecting them to be downgraded, why are we listing them as SHOULD, and not SHOULD-? Or why are we actually listing them at all. Perhaps it would be better to say that for ECDSA the recommended method is to do RFC7427 support. > DSS Digital Signature is bound to SHA-1 and thus is expected to be > downgraded to MUST NOT in the future. I think we should deprecate it to MUST NOT already now. Or at least mark it as SHOULD NOT... > Digital Signature is expected to be promoted as it provides hash > function, signature format and algorithm agility. Add reference to the RFC7427 here. > [MGLT: Do we have any recommendation for the authentication based on > PSK?] I do not think we want to say anything about that, so we can remove this comment. > 4.2. Digital Signature Recommendation > > Here are the recommendations for the authentication methods. Add here text saying that this section only covers RFC7427. > +--------+-------------+----------+---------------------------------+ > | Number | Description | Status | Comment | > +--------+-------------+----------+---------------------------------+ > | OID | RSA | MUST | With keys length 2048 | > | OID | RSA | SHOULD | With keys length 3072/4096 | > | OID | RSA | MUST NOT | With keys length lower than | > | | | | 2048 | > | OID | ECDSA | SHOULD | | > +--------+-------------+----------+---------------------------------+ Again remove the key lengths, and list the actual oid names, i.e. say that PKCS#1 1.5 RSA is now SHOULD as it allows easy transtion from the RSA Digital signatures using PKCS#1 1.5 RSA to Digital Signature (RFC7427) method. I.e. sha1WithRSAEncryption SHOULD NOT sha256WithRSAEncryption MAY all others are MAY. For the DSA: dsa-with-sha1 SHOULD NOT dsa-with-sha256 MAY For ECDSA ecdsa-with-sha1 SHOULD NOT ecdsa-with-sha256 MAY ecdsa-with-sha384 MAY ecdsa-with-sha512 MAY And for RSASSA-PSS: id-RSASSA-PSS MUST I.e. the final table will be like: +--------------------------+----------------+-------------+ | OID | Algorithm | Status | +--------------------------+----------------+-------------+ | sha1WithRSAEncryption | PKCS#1 1.5 RSA | SHOULD NOT | | sha256WithRSAEncryption | PKCS#1 1.5 RSA | MAY | | dsa-with-sha1 | DSA | SHOULD NOT | | dsa-with-sha256 | DSA | MAY | | ecdsa-with-sha1 | ECDSA | SHOULD NOT | | ecdsa-with-sha256 | ECDSA | MAY | | ecdsa-with-sha384 | ECDSA | MAY | | ecdsa-with-sha512 | ECDSA | MAY | | id-RSASSA-PSS | RSASSA-PSS | MUST | +--------------------------+----------------+-------------+ And then have the hash function table still as separate: > Here are the recommendations when a hash function is involved in a > signature. > > +--------+-------------+--------+---------+ > | Number | Description | Status | Comment | > +--------+-------------+--------+---------+ > | 1 | SHA1 | MUST | | > | 2 | SHA2-256 | MUST | | > | 3 | SHA2-384 | MAY | | > | 4 | SHA2-512 | SHOULD | | > +--------+-------------+--------+---------+ And here I think SHA1 should be SHOULD NOT, and others as they are in table. > With the use of Digital Signature, RSASSA-PKCS1-v1.5 MAY be > implemented, and RSASSA-PSS MUST be implemented. As we already have the OID table specifying this, I do not think we need this text here, but we might again explain bit of the reasons. I.e. sha1WithRSAEncryption, dsa-with-sha1 and ecdsa-with-sha1 are all SHOULD NOTs as they use SHA-1 which is SHOULD NOT to be used as hash algorithm. The sha256WithRSAEncryption is MAY as PKCS#1 1.5 based RSA would be better to be replaced with RSASSA-PSS based RSA, but they are allowed as they provide easy transition from the old RSA Digital signatures to Digital signatures. > 5. Security Considerations ... > The Diffie-Hellman Groups parameter is the most important one to > choose conservatively. Any party capturing all traffic that can > break the selected DH group can retroactively gain access to the > symmetric keys used to encrypt all the IPsec data. However, > specifying extremely large DH group also puts a considerable load on > the device, especially when this is a large VPN gateway or an IoT > constrained device. Ok, we already have this text here, so it might not need to be in the 3.4, but adding some text on the beginning of section 4 might still be needed. -- kivinen@iki.fi From nobody Mon Feb 15 13:52:12 2016 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 E62081AC425 for ; Mon, 15 Feb 2016 13:52:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.407 X-Spam-Level: X-Spam-Status: No, score=-2.407 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, 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 Q65B4_GhqiRY for ; Mon, 15 Feb 2016 13:52:09 -0800 (PST) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 90DDE1A90CE for ; Mon, 15 Feb 2016 13:52:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1455573129; x=2319486729; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Lh0whCJTcznfYKV8jlKmEHJDNwUKaRvmme86JhAGxSo=; b=a6KfY2jyr6yExp0iRe5UguofVdJa2AU+OZRobNLw4HWIho8mkhU/1qGbNyBfyrHI np97kXquF2ZR9V3WjpupaBxwRPWTddZKVToyKcR8Zq4cBTeXjSOnbt2OawXsO/vp UYg+aFoAWvtyfZcXF6G7WjJ/XE05CLi9eRpg5MJfNEM2IXi82PjbH+nyCFgk11Jy DGnxVzMN6XIi6H00OvcnLQv7cKpviBm+86EjnUKCe0NG0ozkozV4OTN1ULrYV1tf YWxorjj8Zyl7go93YAIcNO1skEcnnLMWehhTZICTA+I/Lok9/4EyMJU+uNjbz3Lq nrYhgGeuhzOn9c6n6Mfl7w==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 4F.2C.21432.88842C65; Mon, 15 Feb 2016 13:52:09 -0800 (PST) X-AuditID: 11973e13-f79916d0000053b8-4c-56c248888b19 Received: from chive.apple.com (chive.apple.com [17.128.115.15]) (using TLS with cipher DHE-RSA-AES128-SHA (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 2C.C7.29392.78842C65; Mon, 15 Feb 2016 13:52:08 -0800 (PST) Received: from [17.226.23.78] (unknown [17.226.23.78]) by chive.apple.com (Oracle Communications Messaging Server 7.0.5.35.0 64bit (built Mar 31 2015)) with ESMTPSA id <0O2L00ET6ZEUT020@chive.apple.com> for ipsec@ietf.org; Mon, 15 Feb 2016 13:52:07 -0800 (PST) Sender: tpauly@apple.com From: Tommy Pauly Content-type: multipart/alternative; boundary="Apple-Mail=_942B819E-9A22-4D00-A856-6B1C7177C93E" Message-id: Date: Mon, 15 Feb 2016 13:52:06 -0800 To: ipsec@ietf.org MIME-version: 1.0 (Mac OS X Mail 10.0 \(3160\)) X-Mailer: Apple Mail (2.3160) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUi2FAYpdvpcSjMoC/QYv+WF2wOjB5Llvxk CmCM4rJJSc3JLEst0rdL4MqYdm4zU8Fc6YpFc3axNDBeFO9i5OSQEDCR+LG9hwXCFpO4cG89 WxcjF4eQwF5GiRXf77DBFD1dsAAqMY1JYsb0fawgCSGBLiaJ07PDuhg5OIQFJCQ270kECbMJ qEgc/7aBGcRmFkiSuP97FxOILSxgKtH35idYK6+AjcS1PUvAFrMIqErc6PvIBjJGREBIomlr AkSJvsTaFTNZIU6Qlbh4eyMjyAkSAhPYJF596WOdwCgwC8mKWUh6IOLaEssWvmaGsDUl9ncv Z8EU15Do/DaRdQEj2ypGodzEzBzdzDxTvcSCgpxUveT83E2MoBCebie8g/H0KqtDjAIcjEo8 vBzA0BZiTSwrrsw9xCjNwaIkzjvVFSgkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qBcQr/LpuO g3v3MEn9q94ao3Ldt+H/giP33d5sjN5dvYXtUZ/qr5AjYaItdW8ur9d8v8vTYfu8ppmd3/80 d/hzNdRt54jif/wmfmrPwu2VejZ5GdKtArvlIn2O+b3p2eGmWWCqsootdaOmUEVO0M6LVrfY pnyvvZcwYYqd2U+trMI6rbQHLy/pKbEUZyQaajEXFScCAOYD91BCAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFIsWRmVeSWpSXmKPExsUi2FDMr9vhcSjM4MJtaYv9W16wOTB6LFny kymAMYrLJiU1J7MstUjfLoErY9q5zUwFc6UrFs3ZxdLAeFG8i5GTQ0LAROLpggVsELaYxIV7 64FsLg4hgWlMEjOm72MFSQgJdDFJnJ4d1sXIwSEsICGxeU8iSJhNQEXi+LcNzCA2s0CSxP3f u5hAbGEBU4m+Nz/BWnkFbCSu7VnCAmKzCKhK3Oj7yAYyRkRASKJpawJEib7E2hUzWSFOkJW4 eHsj4wRG3llIps5CUgYR15ZYtvA1M4StKbG/ezkLpriGROe3iawLGNlWMQoUpeYkVprpJRYU 5KTqJefnbmIEB11h1A7GhuVWhxgFOBiVeHg5gMEoxJpYVlyZe4hRgoNZSYRXRgcoxJuSWFmV WpQfX1Sak1p8iHEiI9AzE5mlRJPzgTGRVxJvaGJiYGJsbGZsbG5iTkthJXHe5yJbwoQE0hNL UrNTUwtSi2COYuLglGpgbHRk0Eub+o1pvcY+nYee2w9uW7ZG9lfdxW2WBQXvOeXyVb/bHWXN fNa6v9ylbqZrZo/0w53eC6vPHd9+wW/tl9JzBf3PDK6/vnz/o+7kyrKHJhHrd1xd/irx5inR 2X53zCOdfviuerluTmiEfWitHKd236HbC2ctbJu+JEFJvNjV8u3VQ9a615RYijMSDbWYi4oT ATbSWqGtAgAA Archived-At: Subject: [IPsec] New version of IKEv2 TCP Encapsulation draft 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 Feb 2016 21:52:11 -0000 --Apple-Mail=_942B819E-9A22-4D00-A856-6B1C7177C93E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hello all, I=E2=80=99ve just posted a new version of the IKEv2 and IPSec TCP = Encapsulation draft. The changes include: - Making the use case (as a last resort if UDP is blocked) more clear in = the introduction - Clarify connection establishment and teardown section (allowing a = resumed connection to start with either IKE or ESP traffic, allowing = multiple SAs on one TCP connection) - Adding more details about interactions with IKEv2 fragmentation, and = TCP MSS and QoS markings - Clarifying the keep-alive/DPD section - A new appendix written by a new author from Cisco giving four example = exchanges with TCP encapsulation of IKEv2. https://tools.ietf.org/id/draft-pauly-ipsecme-tcp-encaps-03.txt = https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-03 = I believe this should address many of the comments the last draft = received. Please take a look and provide your feedback! If the working = group is in favor, I=E2=80=99d like to see if this can be adopted by the = working group. Thanks, Tommy --Apple-Mail=_942B819E-9A22-4D00-A856-6B1C7177C93E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Hello all,

I=E2=80=99ve just posted a new version of the IKEv2 and IPSec = TCP Encapsulation draft. The changes include:

- Making the use case (as a last resort = if UDP is blocked) more clear in the introduction
- = Clarify connection establishment and teardown section (allowing a = resumed connection to start with either IKE or ESP traffic, allowing = multiple SAs on one TCP connection)
- Adding more = details about interactions with IKEv2 fragmentation, and TCP MSS and QoS = markings
- Clarifying the keep-alive/DPD = section
- A new appendix written by a new author = from Cisco giving four example exchanges with TCP encapsulation of = IKEv2.

https://tools.ietf.org/id/draft-pauly-ipsecme-tcp-encaps-03.txt=
https://tools.ietf.org/html/draft-pauly-ipsecme-tcp-encaps-03

I believe = this should address many of the comments the last draft received. Please = take a look and provide your feedback! If the working group is in favor, = I=E2=80=99d like to see if this can be adopted by the working = group.

Thanks,
Tommy

= --Apple-Mail=_942B819E-9A22-4D00-A856-6B1C7177C93E-- From nobody Wed Feb 17 08:10:07 2016 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 77CBA1A894E for ; Wed, 17 Feb 2016 08:10:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 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, 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 3ACS3Vq6-vy1 for ; Wed, 17 Feb 2016 08:10:04 -0800 (PST) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F2AE01A8948 for ; Wed, 17 Feb 2016 08:10:03 -0800 (PST) Received: by mail-wm0-x230.google.com with SMTP id a4so35237529wme.1 for ; Wed, 17 Feb 2016 08:10:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:message-id:date :to:mime-version; bh=K8LllwzuyzOBncqbDIq3tMpQ8J7OHdJLrAAkvVuifJI=; b=acJKgCu55iqwxNBWRyCWgBwstEqSVybYn4UqwEEaFPaG4i20EMCiK6CGQUZ0jD5u8b G/56V0m2SDUt5UZ8F+wCaH3ZK+f5jT+Sqxh3sHbLN7CsJc0pD3xC42dJztJeoGM/Tvqn rYrbvDxJ76nnhdAxwfbRlaURgh9Zf4CJYYL7rDP0GdgPpRBscw2ZGe3DXcHFbl0Sd+hZ dhIxqYp32V7rg185dcBV5MutuwBl+E29u+R/kRcgVXF/VF9AZRsRhA+u8QmQ1sL5o8OF jnhpSxOmTXx+5ER8VfwMWjFG/oMSPOkKEmOSuIP6pYVYxsL9qPIOSFuL+n1qTSly2lzQ Vk3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:content-type:content-transfer-encoding :subject:message-id:date:to:mime-version; bh=K8LllwzuyzOBncqbDIq3tMpQ8J7OHdJLrAAkvVuifJI=; b=RtujeqIEEOtdlL7pa8mXRPI8zo4tBt7tDQLNPSH1gYdH+wwL3NdzliyZSHgTlgC9Q4 j4tK45l7IDp5q4N64SyugTQLDTreZO7qH0s3rpC9kXW8JbJaY6291HvkMQz9jJrR38cU CfSE9ohh3XAnxqte5JSld93E3O11/qI6wEuZUPWKer4hYb8OKX82+ma9qu84imzKNbGy 2JwrjB4TuARQJMFhcpU6k+K1A7+EQoX994BXhJaoHTK8ZugD/eIu9EW95U3CzBYycN7X D60rBq/rVaT77iGo9KTkEXAeueN0fpgZ5riL4E37vYYc3E5Zk6XI8I/m3TWofRll1GVw uYjA== X-Gm-Message-State: AG10YORvavs774mMvhu5XwZM7yGiucJW00uTdpA9xIRTMMHBmp1u47Zm1sPkeuMm0lpV8A== X-Received: by 10.28.180.84 with SMTP id d81mr4863609wmf.42.1455725402471; Wed, 17 Feb 2016 08:10:02 -0800 (PST) Received: from [172.24.248.214] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id 74sm3791317wmn.17.2016.02.17.08.10.01 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 17 Feb 2016 08:10:01 -0800 (PST) From: Yoav Nir Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-Id: <54947C0C-EB83-4BD7-8DB1-979F68037B10@gmail.com> Date: Wed, 17 Feb 2016 18:09:59 +0200 To: "ipsec@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [IPsec] DDoS Protection - single vs multiple solutions 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, 17 Feb 2016 16:10:06 -0000 Hi As we=E2=80=99re nearing WGLC for the DDoS protection draft, there is a = question we=E2=80=99ve left open in the past that should be resolved. The issue is with the variability of the time it takes to solve a = puzzle. To demonstrate it, I ran a simulation of trying to solve a = 20-bit puzzle 1000 times on some specific hardware [1]. The results are = available in ODS [2] and XSLX [3] formats, and also summarized below: Average 1.3226669 Min 0.0001190 Max 7.9450660 Standard Deviation 1.2873387 5th percentile 0.0843579 95th percentile 3.8978098 95th / 5th percentiles 46.2 Max / Min 66765.3 So an =E2=80=9Cunlucky=E2=80=9D initiator, defined here as the 95th = percentile for solution time, takes 46x as long to solve the puzzle as a = =E2=80=9Clucky=E2=80=9D one (defined as the 5th percentile). This = introduces delays that are visible to human users, whether they are = looking at a dialog box on a remote access client or are waiting for = their networked application to work. A while ago Scott Fluhrer suggested a way to make this more fair [4]. = The puzzle we were discussing then was a little different, but his = method can be adapted to the puzzle that is in the current draft. = Instead of requiring just one solution, require the client to find = several solutions. The puzzle can be made correspondingly easier. The = expected time for finding one solution for a 20-bit puzzle should be the = same as the time to find four solutions to an 18-bit puzzle, or 16 = solutions to a 16-bit puzzle. The results in [2] and [3] bear this out. While the expected time is pretty similar, the different between worst = case and average case is much better: Test Parameters 20x1 18x4 16x16 Average 1.3226669 1.3400430 1.3445518 Min 0.0001190 0.1013960 0.5210680 Max 7.9450660 3.9507410 3.0532380 Standard Deviation 1.2873387 0.6568984 0.3353262 5th percentile 0.0843579 0.4548676 0.8529980 95th percentile 3.8978098 2.5217214 1.9443243 95th / 5th perc. 46.2 5.5 2.3 Max / Min 66765.3 39.0 5.9 In my opinion the right thing to do is to choose a multi-solution puzzle = and adjust the difficulty accordingly. This adds a little complexity but = provides a more consistent delay. There have been two arguments against = it so far.=20 1. The Initial request will become larger with multiple solutions. This = is not necessarily true, since the initiator is still limited in the = number of possible keys it can try. We can have PRF keys be all zeros = except for the last 32 or 64 bits. This is good enough, because no = current hardware is able to test 2^32 keys in a reasonable time, and = 64-bits gives us protection for the foreseeable future. So a single = result can be as low as 4 or 8 octets. 2. The Responder will need to spend more resources verifying more = solutions. This is not necessarily true either, because the Responder = can just pick one or two solutions at random and only verify them. Not = that a single run of the HMAC function takes that many resources. Yoav [1] 2.4 GHz Intel Core i5. The CPU in a late 2013 13-inch MacBook Pro. [2] = https://trac.tools.ietf.org/wg/ipsecme/trac/raw-attachment/wiki/TempDocs/p= uzzle_stats.ods [3] = https://trac.tools.ietf.org/wg/ipsecme/trac/raw-attachment/wiki/TempDocs/p= uzzle_stats.xslx [4] = https://mailarchive.ietf.org/arch/msg/ipsec/30_tZekTBxdYPFVc6B1bXaEMtEQ From nobody Wed Feb 17 11:17:48 2016 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 B720A1A92FD for ; Wed, 17 Feb 2016 11:17:46 -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 yQi4VkW97wel for ; Wed, 17 Feb 2016 11:17:45 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C35591ACDC5 for ; Wed, 17 Feb 2016 11:17:38 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id g62so251350762wme.0 for ; Wed, 17 Feb 2016 11:17:38 -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=5n8f3WTKggBJ690JnAXVJlJo/sadeS3m+TK2HbXcvcg=; b=CjGJIFQHE01yWs6a45q5oVLO8/+RTbj2y7R5JIUcm9U2J8WQG8NRJ1/iFLK/weeXHI PAtSKmeWdoC66puUbfhoNiqGuH4J8GUxFXHDWgun8X4t3wgmEDrLhb2EGni1OUtsICdj ENUuvxP309XfvruzJ5ZANWuSQqrQS1JObUQ/mNREihpTDl151eLmsoLApAF7XU7EhK/9 7iTFRdyH09+IxGFxhbEu9OgbBaktyn2jgtKze6i9lMI2/lHp8KICKCnuPMvqxhx1Iqhf BEGp5oLCI7cFDrpbqW82vxX42TloWxYK1jACtDAe9G1o0pyWWWYXbBpMvb5OrOdGsCii IS3A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:content-transfer-encoding:message-id:references:to; bh=5n8f3WTKggBJ690JnAXVJlJo/sadeS3m+TK2HbXcvcg=; b=BomlLnrAdZuZX2VP4+EN7zMfvG+EX4dgw7a7GbfF/du+3oMmF67urDa88wvWUsbTeW UBcXti97XuMdPvJfJ+6PZ5AyyNA/AcfoTXTmEK1Cv/cXho8sYy5odhLtr8pHVHWIN0qv boHNQNIrbSQVPPwYP5dqwFjyQ6rqRFcGqT/fcXXZlgdiRn5c7JMzWjdJMETeATnbRZBd Ee5fWHqLYi3+lSjM/ydeyRP7DU6SUi3scHrPGbgGPRKz/Z59nm/2twLS16ZoUCb5t0eM VJHlp8YsmQ2J9FfY39eHX76l0eEQwxF4HNKx+iLaSaKbrG+PEce+GNUVdZpFrTxSKqiL ePmg== X-Gm-Message-State: AG10YOTIgVKjracp38iq2q2KNKLlMh3pJuzK4WJGeBPUZxTr0nyJSjyiKZi0Jgbu7eALKw== X-Received: by 10.194.117.68 with SMTP id kc4mr3528072wjb.111.1455736657411; Wed, 17 Feb 2016 11:17:37 -0800 (PST) Received: from [192.168.1.13] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id c136sm26781977wmd.3.2016.02.17.11.17.36 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Wed, 17 Feb 2016 11:17:36 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: <54947C0C-EB83-4BD7-8DB1-979F68037B10@gmail.com> Date: Wed, 17 Feb 2016 21:17:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54947C0C-EB83-4BD7-8DB1-979F68037B10@gmail.com> To: "ipsec@ietf.org WG" X-Mailer: Apple Mail (2.3112) Archived-At: Subject: Re: [IPsec] DDoS Protection - single vs multiple solutions 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, 17 Feb 2016 19:17:46 -0000 On 17 Feb 2016, at 6:09 PM, Yoav Nir wrote: > A while ago Scott Fluhrer suggested a way to make this more fair As it turns out, this was first suggested by Yaron: https://mailarchive.ietf.org/arch/msg/ipsec/_JUTE8p5H6bhFOA1HCuaYX1NCKQ Scott=E2=80=99s idea was a little different. Sorry for the confusion. Yoav From nobody Wed Feb 17 11:53:09 2016 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 3D9F31ACD85 for ; Wed, 17 Feb 2016 11:53:08 -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 PCiYcpfW7LGx for ; Wed, 17 Feb 2016 11:53:06 -0800 (PST) Received: from mail-wm0-x232.google.com (mail-wm0-x232.google.com [IPv6:2a00:1450:400c:c09::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B3051ACD83 for ; Wed, 17 Feb 2016 11:53:06 -0800 (PST) Received: by mail-wm0-x232.google.com with SMTP id g62so178073108wme.1 for ; Wed, 17 Feb 2016 11:53:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=RvihbB0hK8/RJpR7uS1GrB01FKLJa0ZaHOqy3QxD8p0=; b=GjwSEDdgQxuydUWHr9Gb91Mu2Q/wTivZmnbosQ7YUX/ypaLCOaxjCPbctrdp5Vo2f5 FVMoJzvqp1HV7znlrTS80EYauQHinLFDJ0s9aD1ltFu65MLaCVQgW/aCk3QnhXxEfiVw +4w/F3cPctQr0AnTYvuZiWyZ7N0wMYEzOXKZyfikgDYj09MLGFuqxQ4xts/qvjb9/T5l pwayaP/GDq+Alb5Qj5U/MlAgbrvqe17PRQeLGxXFpdtlHm+CQ7wNpgGXYE32sMyaLOhi ie9DM1h9kiiEOcm8/htf2eNYsAS8nImX/vMBgvDsv7FEiV4A7yGSNuHfbjUZQ+IwRhXW 9bNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=RvihbB0hK8/RJpR7uS1GrB01FKLJa0ZaHOqy3QxD8p0=; b=WquBvu1W81US5+oFBz9tHE9wxvax2uTXXuDVC0FLoICWdqT4LyCxtANovml0+VosAF V+YtxRwgMG7I3ft8b1mskXVIX9DBP5lPRWIBFMrNeS4Q5Yib0JW+W6hycCVmwuOFynTo dvKJCz4zYXnfKFSOsBgg+4dkiwXjDnsh+90Wt7OGjJIaV8Wr7jNKZQ6D1EauUXSENGBl IQhfA7iyv2BS3/bO5LWnvjDLX5gQHvky6Ln5ZGFt3xNYniriQQOHGvd1/UvRcHBeRkM+ mA0cEao38CzX7FxGdqwbkVEpTE0iSKk3tSbVi02rC3yJCkjv/EOCQiBKrygqZdtS91xK Z9SQ== X-Gm-Message-State: AG10YOQKjm7hmzPpmgZfRgLsM/urfbQjJ/8xcqq+tv/ikm/V0C0T/tWRd3Mm0iMAIHJSxw== X-Received: by 10.28.131.141 with SMTP id f135mr26865093wmd.33.1455738784906; Wed, 17 Feb 2016 11:53:04 -0800 (PST) Received: from [10.0.0.11] (bzq-79-182-36-67.red.bezeqint.net. [79.182.36.67]) by smtp.gmail.com with ESMTPSA id 74sm4665674wmn.17.2016.02.17.11.53.03 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 17 Feb 2016 11:53:03 -0800 (PST) To: Yoav Nir , "ipsec@ietf.org WG" References: <54947C0C-EB83-4BD7-8DB1-979F68037B10@gmail.com> From: Yaron Sheffer Message-ID: <56C4CF9D.4010101@gmail.com> Date: Wed, 17 Feb 2016 21:53:01 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [IPsec] DDoS Protection - single vs multiple solutions 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, 17 Feb 2016 19:53:08 -0000 Scott's idea was different, and possibly better. At the cost of some Responder compute work, his idea makes the Initiator's effort nearly deterministic. https://mailarchive.ietf.org/arch/msg/ipsec/30_tZekTBxdYPFVc6B1bXaEMtEQ Thanks, Yaron On 02/17/2016 09:17 PM, Yoav Nir wrote: > On 17 Feb 2016, at 6:09 PM, Yoav Nir wrote: > >> A while ago Scott Fluhrer suggested a way to make this more fair > As it turns out, this was first suggested by Yaron: > https://mailarchive.ietf.org/arch/msg/ipsec/_JUTE8p5H6bhFOA1HCuaYX1NCKQ > > Scott’s idea was a little different. > > Sorry for the confusion. > > Yoav > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From nobody Wed Feb 17 12:03:17 2016 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 EFDEB1B29B0 for ; Wed, 17 Feb 2016 12:03:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 2efd7GkpQX9j for ; Wed, 17 Feb 2016 12:03:14 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91AE81AD1DB for ; Wed, 17 Feb 2016 12:03:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2292; q=dns/txt; s=iport; t=1455739394; x=1456948994; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=dI96CxdGwUBWduJB4F2lUJX5McCPptthbGYz7H4jFno=; b=QjP8rq5d2Z2J9kBL8u0su6BCVNSd2jysX6XW3XI2kYsWyyQHBA9rcMcK TjMDWJJeu+M5aaym0UwoAhoQeOPyVle/vDV0hi+V3QQWbkIfuGyday6A8 4wZXsGRtN7tKcFE12w1Vd3sAzRMcZh+wmuBzF4s6/2WCAkGQR5QrIBquL k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A3AgBL0cRW/5RdJa1egzpSbQa6GAENg?= =?us-ascii?q?WcXCoVsAhyBMDgUAQEBAQEBAWQnhEEBAQEEAQEBIBE6FwQCAQgRBAEBAQICIwM?= =?us-ascii?q?CAgIfBgsUAQgIAgQBEggTh2oDEg6sWIoKDYRcAQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBEQR7hReEO4I6gVY7gmqBOgWXBAGFUoYTgWyOeocEh0IBHgEBQoNjaocIPHw?= =?us-ascii?q?BAQE?= X-IronPort-AV: E=Sophos;i="5.22,462,1449532800"; d="scan'208";a="238915666" Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 Feb 2016 20:03:13 +0000 Received: from XCH-RCD-009.cisco.com (xch-rcd-009.cisco.com [173.37.102.19]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id u1HK3D2M028406 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 17 Feb 2016 20:03:13 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-009.cisco.com (173.37.102.19) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 17 Feb 2016 14:03:14 -0600 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Wed, 17 Feb 2016 14:03:14 -0600 From: "Scott Fluhrer (sfluhrer)" To: Yaron Sheffer , Yoav Nir , "ipsec@ietf.org WG" Thread-Topic: [IPsec] DDoS Protection - single vs multiple solutions Thread-Index: AQHRaZ247NPVUOqwUUWU38kovYQqzp8xAQ8AgAAJ54D//51BsA== Date: Wed, 17 Feb 2016 20:03:14 +0000 Message-ID: References: <54947C0C-EB83-4BD7-8DB1-979F68037B10@gmail.com> <56C4CF9D.4010101@gmail.com> In-Reply-To: <56C4CF9D.4010101@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.59] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [IPsec] DDoS Protection - single vs multiple solutions 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, 17 Feb 2016 20:03:16 -0000 T24gdGhlIG90aGVyIGhhbmQgKHNpbmNlIHdlJ3JlIGNvbXBsZW1lbnRpbmcgZWFjaCBvdGhlcidz IGlkZWFzKSwgd2l0aCBZYXZvbidzIGlkZWEsIGl0J3MgZWFzeSB0byBoYXZlIHB1enpsZSBOKzEg ZGVwZW5kIG9uIHRoZSBzb2x1dGlvbiB0byBwdXp6bGUgTi4gIFRoYXQgbWF5IGxpbWl0ICh0byBz b21lIHNtYWxsIGV4dGVudCkgdGhlIGFkdmFudGFnZSB0aGF0IGEgaGlnaGx5IHBhcmFsbGVsIHN5 c3RlbSB3b3VsZCBoYXZlIGluIHNvbHZpbmcgcHV6emxlcyAtIHdoaWxlIHBhcmFsbGVsaXNtIG1p Z2h0IGJlIGFibGUgdG8gc3BlZWQgYW55IGluZGl2aWR1YWwgcHV6emxlLCB0aGV5IHdvdWxkIHN0 aWxsIGhhdmUgdG8gc29sdmUgdGhlIHNlcXVlbmNlIG9mIHB1enpsZXMgc2VxdWVudGlhbGx5Lg0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IElQc2VjIFttYWlsdG86aXBz ZWMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIFlhcm9uIFNoZWZmZXINCj4gU2VudDog V2VkbmVzZGF5LCBGZWJydWFyeSAxNywgMjAxNiAyOjUzIFBNDQo+IFRvOiBZb2F2IE5pcjsgaXBz ZWNAaWV0Zi5vcmcgV0cNCj4gU3ViamVjdDogUmU6IFtJUHNlY10gRERvUyBQcm90ZWN0aW9uIC0g c2luZ2xlIHZzIG11bHRpcGxlIHNvbHV0aW9ucw0KPiANCj4gU2NvdHQncyBpZGVhIHdhcyBkaWZm ZXJlbnQsIGFuZCBwb3NzaWJseSBiZXR0ZXIuIEF0IHRoZSBjb3N0IG9mIHNvbWUNCj4gUmVzcG9u ZGVyIGNvbXB1dGUgd29yaywgaGlzIGlkZWEgbWFrZXMgdGhlIEluaXRpYXRvcidzIGVmZm9ydCBu ZWFybHkNCj4gZGV0ZXJtaW5pc3RpYy4NCj4gDQo+IGh0dHBzOi8vbWFpbGFyY2hpdmUuaWV0Zi5v cmcvYXJjaC9tc2cvaXBzZWMvMzBfdFpla1RCeGRZUEZWYzZCMWJYYUVNdEUNCj4gUQ0KPiANCj4g VGhhbmtzLA0KPiAgICAgIFlhcm9uDQo+IA0KPiBPbiAwMi8xNy8yMDE2IDA5OjE3IFBNLCBZb2F2 IE5pciB3cm90ZToNCj4gPiBPbiAxNyBGZWIgMjAxNiwgYXQgNjowOSBQTSwgWW9hdiBOaXIgPHlu aXIuaWV0ZkBnbWFpbC5jb20+IHdyb3RlOg0KPiA+DQo+ID4+IEEgd2hpbGUgYWdvIFNjb3R0IEZs dWhyZXIgc3VnZ2VzdGVkIGEgd2F5IHRvIG1ha2UgdGhpcyBtb3JlIGZhaXINCj4gPiBBcyBpdCB0 dXJucyBvdXQsIHRoaXMgd2FzIGZpcnN0IHN1Z2dlc3RlZCBieSBZYXJvbjoNCj4gPg0KPiBodHRw czovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL2lwc2VjL19KVVRFOHA1SDZiaEZPQTFI Q3VhWVgxTkMNCj4gSw0KPiA+IFENCj4gPg0KPiA+IFNjb3R04oCZcyBpZGVhIHdhcyBhIGxpdHRs ZSBkaWZmZXJlbnQuDQo+ID4NCj4gPiBTb3JyeSBmb3IgdGhlIGNvbmZ1c2lvbi4NCj4gPg0KPiA+ IFlvYXYNCj4gPg0KPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPiBJUHNlYyBtYWlsaW5nIGxpc3QNCj4gPiBJUHNlY0BpZXRmLm9yZw0K PiA+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMNCj4gDQo+IF9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IElQc2VjIG1h aWxpbmcgbGlzdA0KPiBJUHNlY0BpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2lwc2VjDQo= From nobody Thu Feb 18 04:59:12 2016 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 EFE0D1A1AB9 for ; Thu, 18 Feb 2016 04:59:10 -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 eoOGIGdp4gKw for ; Thu, 18 Feb 2016 04:59:09 -0800 (PST) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB5A51A1A97 for ; Thu, 18 Feb 2016 04:58:53 -0800 (PST) Received: by mail-lf0-x235.google.com with SMTP id l143so31783604lfe.2 for ; Thu, 18 Feb 2016 04:58:53 -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=52/SQ3i3yaFrYKTbpZudSRfRbP5+RdOgfFfWpIDf9x0=; b=rUQpdqfJVrCXWDKRuxrQfH1iWH22UYVTY2Tz8i+H95MMgbM0Ub/Sy/1kCVxYShFN73 UIuHfLfpGTIsVEPxSQofFDnkQkEZgYMsttwEwmtMUVeCdAdcxarTgtEb4stohCNeTzeD +e6hUiKOnASFJcUpvjbtAJp/hD+6yvUPaaI2jl6XjIe8o0Nq2iwEaK4HlGtNrBc+DZS0 df4Q1YH+kLmV/kT8yTXVzNvzJE6hMgtcgSveg6EThlp5GvuyeIdyOZXIfIt73GKold9B p1FOcKJ5JijDP1dssQmATUien68f8mnq3MipVFtbcTA2wr5KrlibGwKUVqTGAOU93VDF NIGA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:references:subject:date :mime-version:content-type:content-transfer-encoding; bh=52/SQ3i3yaFrYKTbpZudSRfRbP5+RdOgfFfWpIDf9x0=; b=Tq/NHF2/v4kqe8odV08kOoJGRw7kGeQdYzyd2nHqIDok7kR62uQ9hn0J5bQ9fuOKmO S+pifEmnHs9GwwzbbavD4nL5axUFxKiLzAk/LgnM4/10S8ZqtDaN9K+S2vE3SnzRMna7 rfpLOTTabcfa0D6HqgN0PyOQiwlrQiQ6XgpLfbXamYM2U6/HE7LkMcCZy1lkclI8L12h oq9dSWEktFgMaYtiyVgR1DxBi1jM9i25Tfdd1OFKz3XPousyYS6i4EguNy9bnJ1LPmnR DRLC4cX/Nl9g/TZRFj3CYMikvOgeAHHL3yUzd9XBmtEwwc/LFIT5Bktso4pwzfBt2wpd rmxA== X-Gm-Message-State: AG10YORJImoNaDBzGCjpw4PBU1bqf1+eLbRuL4GoVMfuFUUuYFpYg1ALeblYxy9V0jEkZA== X-Received: by 10.25.149.68 with SMTP id x65mr3080727lfd.138.1455800331994; Thu, 18 Feb 2016 04:58:51 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id 37sm932650lfs.3.2016.02.18.04.58.50 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Feb 2016 04:58:51 -0800 (PST) Message-ID: <3C34F58C00A4424E992DC2D37F61D36F@buildpc> From: "Valery Smyslov" To: "Yoav Nir" , References: <54947C0C-EB83-4BD7-8DB1-979F68037B10@gmail.com> Date: Thu, 18 Feb 2016 15:58:47 +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: Subject: Re: [IPsec] DDoS Protection - single vs multiple solutions 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, 18 Feb 2016 12:59:11 -0000 Hi, > As we’re nearing WGLC for the DDoS protection draft, there is a question we’ve left > open in the past that should be resolved. > > The issue is with the variability of the time it takes to solve a puzzle. To demonstrate it, > I ran a simulation of trying to solve a 20-bit puzzle 1000 times on some specific hardware [1]. > The results are available in ODS [2] and XSLX [3] formats, and also summarized below: > > Average 1.3226669 > Min 0.0001190 > Max 7.9450660 > Standard Deviation 1.2873387 > 5th percentile 0.0843579 > 95th percentile 3.8978098 > 95th / 5th percentiles 46.2 > Max / Min 66765.3 > > So an “unlucky†initiator, defined here as the 95th percentile for solution time, takes 46x as long > to solve the puzzle as a “lucky†one (defined as the 5th percentile). This introduces delays that are visible > to human users, whether they are looking at a dialog box on a remote access client or are waiting > for their networked application to work. > > A while ago Scott Fluhrer suggested a way to make this more fair [4]. The puzzle we were discussing > then was a little different, but his method can be adapted to the puzzle that is in the current draft. > Instead of requiring just one solution, require the client to find several solutions. The puzzle can be made > correspondingly easier. The expected time for finding one solution for a 20-bit puzzle should be the same > as the time to find four solutions to an 18-bit puzzle, or 16 solutions to a 16-bit puzzle. The results in [2] > and [3] bear this out. > > While the expected time is pretty similar, the different between worst case and average case is much better: > > Test Parameters 20x1 18x4 16x16 > Average 1.3226669 1.3400430 1.3445518 > Min 0.0001190 0.1013960 0.5210680 > Max 7.9450660 3.9507410 3.0532380 > Standard Deviation 1.2873387 0.6568984 0.3353262 > 5th percentile 0.0843579 0.4548676 0.8529980 > 95th percentile 3.8978098 2.5217214 1.9443243 > 95th / 5th perc. 46.2 5.5 2.3 > Max / Min 66765.3 39.0 5.9 > > In my opinion the right thing to do is to choose a multi-solution puzzle and adjust the difficulty accordingly. > This adds a little complexity but provides a more consistent delay. There have been two arguments against it so far. I tend to support this idea, but I think in this case the sub-puzzles must be chained to deal with parallel solving. Something like the following: Puzzle_data[0] = cookie Puzzle_data[1] = Puzzle_solution[0] | cookie Puzzle_data[2] = Puzzle_solution[1] | cookie ... Puzzle_data[n] = Puzzle_solution[n-1] | cookie Or probably someone could suggest more clever construction? Note, that the draft already supports multiple puzzles by allowing the responder to request another puzzle after verifying the received solution. However, this is different from the proposed mechanizm and is more focused on solving the problem of wide range of initiators' capabilities. The two mechanisms would complement each other. Should the number of sub-puzzles be fixed in the protocol or should we allow the responder to specify it in the PUZZLE notification? It seems that after 4 (or 8?) sub-puzzles an effect of sub-puzzling becomes less and less visible. > 1. The Initial request will become larger with multiple solutions. This is not necessarily true, since the initiator > is still > limited in the number of possible keys it can try. We can have PRF keys be all zeros except for the last 32 or 64 > bits. > This is good enough, because no current hardware is able to test 2^32 keys in a reasonable time, and 64-bits gives > us protection for the foreseeable future. So a single result can be as low as 4 or 8 octets. The size of the request will be larger in any case. Currently Puzzle Solution payload may contain as few bytes of the key as needed (for PRFs with variable-size keys). But I don't think the number of sub-puzzles should be more than 4 (or 8), so that's not such a big problem. > 2. The Responder will need to spend more resources verifying more solutions. This is not necessarily true either, > because the Responder can just pick one or two solutions at random and only verify them. Not that a single run > of the HMAC function takes that many resources. It's true, however there is a tradeoff. If the number of sub-puzzles is small (say 4), then verifying a single solution gives an attacker that solves a single sub-puzzle a 25% chance to pass through. Is it always acceptable for responder? I think the responder SHOULD verify all (or at least half). > Yoav Regards, Valery. From nobody Thu Feb 18 05:51:08 2016 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 E70D11A6F3A for ; Thu, 18 Feb 2016 05:51: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 B32bp34rtRS0 for ; Thu, 18 Feb 2016 05:51:05 -0800 (PST) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 601301A0364 for ; Thu, 18 Feb 2016 05:51:05 -0800 (PST) Received: by mail-wm0-x234.google.com with SMTP id b205so25883383wmb.1 for ; Thu, 18 Feb 2016 05:51:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=P4Skemq5z0Y6bMc9YB5zEoTkG+MbUGAnqIGOpyz0CTU=; b=hAyMGM2cFVbrDdAqayh4u/U8i9f6Sv1Mv8tM7dxYPlVgnlJQ9xGb/LFHTcfohnJFqS 41gHf+rrngJDzKgTULQ8c+/KllYadr/geFkFzODOS4eytXF7d/vYyV4vmCSKQOBXMfxJ UYoFG+FyxV8jF3yNiKJZGx0KqASnjJGXTOOkyKA5lVqX5NlCuJiTQLoQmNkeq5rXttDf ILl1VOUXklOLKgQyXkceGQt6lSdmOdI8XYAjd+Th6bp8k0NwxexhQ6UALD6WhbcV+kpJ 4LqaHgFubcwSXBJuWPqVUgjsjZ9tg0IQjJgRWg2FOW8+2kfZHd7nobpmm3Gdi/ZTUPA0 xMKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=P4Skemq5z0Y6bMc9YB5zEoTkG+MbUGAnqIGOpyz0CTU=; b=DeanS9+eoopzD0CbfCdNWOhGYeZl09aN5wPdjs/itobIDWY2OLD8+gAClNb7LQC5Dm Cj6qTvm7p5hRFAEpkM2FB+pVHCGzrhJXsbnzIA1yf+vW7AY0p5qdUn4q4EcGMrqHN4w7 4i44muFmdOxMm1AgJqt0qs+chFfOkkCvm5kF1TJO42BwOZKwSytaaQKnaQ/rUNydM9sv b2Vjl7GqOb2LoN57fQnKHndRwbD+51pBKpXxXsnSOTR14YUL7QDh4057h7avWyfzbFYf 2CBzj0ZlhL6dmQX20YbHUuL4L9jO5/jXeZks1Te+wPb7TN2/lYN+f8z6ozYyy2WfkM1n h7QA== X-Gm-Message-State: AG10YORAvVIZsAXDauToFLt67pBZ2aMhCijuPAs8B5x+r3r77dIF+n9HMe4Ye++jOTbMhg== X-Received: by 10.28.46.82 with SMTP id u79mr3747231wmu.67.1455803463956; Thu, 18 Feb 2016 05:51:03 -0800 (PST) Received: from [172.24.248.170] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id lz5sm6693667wjb.5.2016.02.18.05.51.02 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 18 Feb 2016 05:51:03 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: text/plain; charset=utf-8 From: Yoav Nir X-Priority: 3 In-Reply-To: <3C34F58C00A4424E992DC2D37F61D36F@buildpc> Date: Thu, 18 Feb 2016 15:51:01 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <54947C0C-EB83-4BD7-8DB1-979F68037B10@gmail.com> <3C34F58C00A4424E992DC2D37F61D36F@buildpc> To: Valery Smyslov X-Mailer: Apple Mail (2.3112) Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] DDoS Protection - single vs multiple solutions 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, 18 Feb 2016 13:51:07 -0000 On 18 Feb 2016, at 2:58 PM, Valery Smyslov wrote: >=20 >=20 > I tend to support this idea, but I think in this case the sub-puzzles = must be chained to deal with parallel solving. > Something like the following: >=20 > Puzzle_data[0] =3D cookie > Puzzle_data[1] =3D Puzzle_solution[0] | cookie > Puzzle_data[2] =3D Puzzle_solution[1] | cookie > ... > Puzzle_data[n] =3D Puzzle_solution[n-1] | cookie >=20 > Or probably someone could suggest more clever construction? I=E2=80=99m not really against this, but is parallel solving really an = issue? It does give an advantage to an 8-core desktop or 16-core server = over a 2-core laptop. OTOH it might mitigate the power disparity between = smartphones and laptops because phones have 4, 6, or 8 cores, while most = laptops tend to have 2.=20 Yoav From nobody Thu Feb 18 06:20:19 2016 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 D61561AC408 for ; Thu, 18 Feb 2016 06:20:16 -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_40=-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 tISNXbR_xZeg for ; Thu, 18 Feb 2016 06:20:16 -0800 (PST) Received: from mail-lb0-x230.google.com (mail-lb0-x230.google.com [IPv6:2a00:1450:4010:c04::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 323D61AC44B for ; Thu, 18 Feb 2016 06:20:08 -0800 (PST) Received: by mail-lb0-x230.google.com with SMTP id bc4so29253123lbc.2 for ; Thu, 18 Feb 2016 06:20:08 -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=mxbOpjFNyiOhERyeJ2IWMW5hhZXmKbFXi7oxRCjrxYE=; b=zPpqroO6NuRGhJYPWGGQbEQOKZtGlA3OoCkdPJJ8AyU3nT8eZc+D6HUoAChrxLNIkH l1Hbxwog+NcUm1t3Z0AtAlxsZcS5dSh4ESHdvnmJe9rpVHsJkKs/mH5h4/H0Xc/e6xhm lFbsBDB5SIM13rcaQIGCGIvx4nx82nYcE/neErozj46Qm5aBnjszbiN2jwNpVj0SqXHw 92MZTGHM8kj32rzO0oYTA1ipLcy0+SyD/mum7axDj6sPg95wCXgJ1wnfabBcOSt3hXVy +cLW47a5npuJXicSV839Kmya0Ym1aNeO0CnNE81WmFVvQERTdd0b/oJLont3p0cJ23bp xmfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-type:content-transfer-encoding; bh=mxbOpjFNyiOhERyeJ2IWMW5hhZXmKbFXi7oxRCjrxYE=; b=b0ystylTovy+RbmVFLJQR167WvOndmYccnsBiZnsbbOBOwmqk7Ki5N8W2aX3+k3vAh sQC7MaJXRJtdGYHdgnHtLA4T8i6U1bZxf/zSDfv8BQck9wysZWWW8RFJ2xrDfy1gcjRD Y+iNA09bNTpe7LieSqbtVBW6BlQx99c/EWuuxbZetLNwgNKjUBdpwZp6oFzC1ooajQZ4 LhYbypGp78g/1sGSwyqpm+XzIaIYkNvXnGXGLYVmFQHSu8kFq04feiqOPtqqOXua4pVe Au5zr98E/fTg91mUtsnJRLLzowV4uHC+YZxF8SuhXtwiV9/YFalsQfFgOfSwtzpAW/GA Qahg== X-Gm-Message-State: AG10YORo7RV1xyv4ZEO+/gqVLCKKsYjxGZv7tHseDliTkH9aMeTP32Nd4ukOsMmqlhfZqw== X-Received: by 10.112.17.70 with SMTP id m6mr3346516lbd.130.1455805206223; Thu, 18 Feb 2016 06:20:06 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id q10sm970354lfq.8.2016.02.18.06.20.05 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Feb 2016 06:20:05 -0800 (PST) Message-ID: <876B1AC1A5984E8FB8B6C3D8F55E8C08@buildpc> From: "Valery Smyslov" To: "Yoav Nir" References: <54947C0C-EB83-4BD7-8DB1-979F68037B10@gmail.com> <3C34F58C00A4424E992DC2D37F61D36F@buildpc> Date: Thu, 18 Feb 2016 17:20:02 +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: Cc: ipsec@ietf.org Subject: Re: [IPsec] DDoS Protection - single vs multiple solutions 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, 18 Feb 2016 14:20:17 -0000 >> I tend to support this idea, but I think in this case the sub-puzzles must be chained to deal with parallel solving. >> Something like the following: >> >> Puzzle_data[0] = cookie >> Puzzle_data[1] = Puzzle_solution[0] | cookie >> Puzzle_data[2] = Puzzle_solution[1] | cookie >> ... >> Puzzle_data[n] = Puzzle_solution[n-1] | cookie >> >> Or probably someone could suggest more clever construction? > > I’m not really against this, but is parallel solving really an issue? > It does give an advantage to an 8-core desktop or 16-core server over a 2-core laptop. > OTOH it might mitigate the power disparity between smartphones and laptops because > phones have 4, 6, or 8 cores, while most laptops tend to have 2. The primary goal of sub-puzzling (as I see it) is not to make puzzle equally hard for all clients, but to make puzzle hardness more predictable. As far as I understand you got the figures from your previous message by sequential solutions of a given number of puzzles, didn't you? Did you experimented with parallel puzzle solving on multicore CPUs? Probably the effect of sub-puzzling in this case would be a bit different. It's interesting to compare the results. > Yoav Regards, Valery. From nobody Thu Feb 18 06:57:46 2016 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 6E3A91ACE6A for ; Thu, 18 Feb 2016 06:57: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 l_sUCUpQvtJr for ; Thu, 18 Feb 2016 06:57:44 -0800 (PST) Received: from mail-wm0-x22f.google.com (mail-wm0-x22f.google.com [IPv6:2a00:1450:400c:c09::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A667C1ACDE7 for ; Thu, 18 Feb 2016 06:57:43 -0800 (PST) Received: by mail-wm0-x22f.google.com with SMTP id g62so29073274wme.0 for ; Thu, 18 Feb 2016 06:57:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=r7XBiB151znEqMCGhcjp8m6jid+IYJOsSnouE/qU71o=; b=IDlKOLm/hLgBd2g1cobNN3dIpOZ640Tzv51sEGuq32gZ+QfhIBWmU+wStn6S1sxhEI Tm4vbRhR6CqlQy0pBSMJRf1va5bF1TN79cBDSKb0dsdeMYVwnxPxHwBcJUOxgXdJ7Mtz qqrE353qXhpMBDft2Qqow3TfEe9CpDSvdS8iJQloXAog0fnRgPp05YGCGLIYyDPgnbdJ pAq3dQuwAj0Mq/a+u2ySOMDuCh0OoEGzehVs1w2byXo4gjdPEQorLnTgFzjEXEfPOWBN wbmnxacj70OForx5y0T+17uVo7cwBFYYRTngeIizsA0dCxW8GDpd7TCR+RBDfIKIpB70 O/Tg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:mime-version:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=r7XBiB151znEqMCGhcjp8m6jid+IYJOsSnouE/qU71o=; b=UNWDsGQeqd3uuxbU6y9hq5I/Z4mmmnm1/7bt1k8HInhhvYQrHj0ZNQCaqMLN9ld3Pi Bycz+riZ9VOyJ9VS6CsHVedimmjrf47NuLJgtGwAZCadq74AusjOlFSnZM5yxOgPf1+9 pv53ftRB4TvxXYX7hUhw2PwOyiT6vfxSHUIyMLpecpCzk10Bm4PJfyShAxPGeNt6tmif XD21qJi7uMbsUFzbfJ00KOMRp0L7PCBzLJvQtYBgQDGj+IpLFQuXeiXcvucsVJ3yTLHv UHwvGwyJFk4u0vl+GUYFnvjZPP8DPjM5Qevm7XfQlRuKRqjE6AUuStoVbBzOm1EqTCXT xb/A== X-Gm-Message-State: AG10YOS3nGTCkkTRExXzuGv54HqaEchfE83EzzmZnPT8nIv5LiErIBxEM3XROpxjig4ddw== X-Received: by 10.28.1.9 with SMTP id 9mr3677649wmb.97.1455807462247; Thu, 18 Feb 2016 06:57:42 -0800 (PST) Received: from [172.24.248.170] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id 73sm3340657wmy.22.2016.02.18.06.57.40 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 18 Feb 2016 06:57:41 -0800 (PST) Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) Content-Type: text/plain; charset=utf-8 From: Yoav Nir X-Priority: 3 In-Reply-To: <876B1AC1A5984E8FB8B6C3D8F55E8C08@buildpc> Date: Thu, 18 Feb 2016 16:57:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <2777D644-99B4-41F4-9DF0-EF7EB2F560A3@gmail.com> References: <54947C0C-EB83-4BD7-8DB1-979F68037B10@gmail.com> <3C34F58C00A4424E992DC2D37F61D36F@buildpc> <876B1AC1A5984E8FB8B6C3D8F55E8C08@buildpc> To: Valery Smyslov X-Mailer: Apple Mail (2.3112) Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] DDoS Protection - single vs multiple solutions 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, 18 Feb 2016 14:57:45 -0000 > On 18 Feb 2016, at 4:20 PM, Valery Smyslov wrote: >=20 >>> I tend to support this idea, but I think in this case the = sub-puzzles must be chained to deal with parallel solving. >>> Something like the following: >>>=20 >>> Puzzle_data[0] =3D cookie >>> Puzzle_data[1] =3D Puzzle_solution[0] | cookie >>> Puzzle_data[2] =3D Puzzle_solution[1] | cookie >>> ... >>> Puzzle_data[n] =3D Puzzle_solution[n-1] | cookie >>>=20 >>> Or probably someone could suggest more clever construction? >>=20 >> I=E2=80=99m not really against this, but is parallel solving really = an issue? >> It does give an advantage to an 8-core desktop or 16-core server over = a 2-core laptop. >> OTOH it might mitigate the power disparity between smartphones and = laptops because >> phones have 4, 6, or 8 cores, while most laptops tend to have 2. >=20 > The primary goal of sub-puzzling (as I see it) is not to make puzzle = equally > hard for all clients, but to make puzzle hardness more predictable. Sure, but I=E2=80=99d rather not make the client disparity problem more = severe. > As far as I understand you got the figures from your previous message > by sequential solutions of a given number of puzzles, didn't you? > Did you experimented with parallel puzzle solving on multicore CPUs? > Probably the effect of sub-puzzling in this case would be a bit = different. > It's interesting to compare the results. My tests are single-CPU mostly out of convenience. I iterated over = possible keys until 1, 4, or 16 solutions were found. This should be = very easily parallelizable and times would be halved if I had used both = cores. With a chain such as you=E2=80=99re suggesting, I could still = parallelize. For each step I could still partition the key space and = search in parallel until one solution was found before proceeding to the = next step.=20 Yoav =20= From nobody Thu Feb 18 07:46:38 2016 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 C6F3B1A86E3 for ; Thu, 18 Feb 2016 07:46:36 -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 RugCKfOkcMFL for ; Thu, 18 Feb 2016 07:46:36 -0800 (PST) Received: from mail-lb0-x22b.google.com (mail-lb0-x22b.google.com [IPv6:2a00:1450:4010:c04::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4F111A0087 for ; Thu, 18 Feb 2016 07:46:30 -0800 (PST) Received: by mail-lb0-x22b.google.com with SMTP id x4so31265476lbm.0 for ; Thu, 18 Feb 2016 07:46:30 -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=mlhtjRKPNmmlfKDi8xHCMHTBUloyjgzyY+FAXTzk818=; b=QcsgAbZWyMMRExkB5OaXwiCautIE39aDUX451t+Eg/kelVsHDSsJSB4RS/62z+vQqs IXq+6/QrQ8bifSE/Z8GzKXJmeNSuiDxyGwO2wjSJcFAnHocHoO9LM/TuR8Yh1RDQCT6t xbj5NR4yIb+EwG58LzsMafpv/G4q6beUJ79jQBZCyOl0nXstvfx8KciFF/ZX1L9ZEE+L U0RWijSVHu+mHrx464eCBmiycIEiFGvSsu0Gz6NoTB4ZhskKEnWEzmsF9SnQeJEsgYDl 39QExtb9ruzGeJIXvQ4+ij8gYZF152ckZ45HD3GDU3kq05Lq6aBsHHGAmeui53hSbe84 MXMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-type:content-transfer-encoding; bh=mlhtjRKPNmmlfKDi8xHCMHTBUloyjgzyY+FAXTzk818=; b=iIBAi3yNqanaGTwYik6qfQCBqMyNbo3+kjm6/3r8CGTc6nQR30pTqng1wotyEkjfks 5Z15nGL/5G42JtdsUhQDrStWutyNweaGq5spw1Pws+yq4zdKnxLiOAKR/UgLVjQwm9um j3AnUpGu8Qg3vgeQ5eQ3gXy/B4oG+NVwGNyYnFCy0WW3fLNGVHLD1LsxyUlFAOqU355C 6PLRr1YREBXSA0Xc7oT81yLHyz2Y1k92Yw0CP0PdlbcLFgnvEpLjJtXMcX/mmRuNeoDS B8mH3DPi/eJ9/bSiUcT/RxKzQxxRMiS3hDGuUzeL62XayEd5bf4sRcmBF3XsjkYD5oMS N5ww== X-Gm-Message-State: AG10YORMWO38pOxzQ1F3MXn+EtADsIMZ2ota86BVoV6GawVkjp0C4/uKrup+uRRRsTIQ/w== X-Received: by 10.112.146.104 with SMTP id tb8mr3505780lbb.95.1455810388926; Thu, 18 Feb 2016 07:46:28 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id i186sm262329lfb.30.2016.02.18.07.46.27 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 18 Feb 2016 07:46:27 -0800 (PST) Message-ID: <393C679EE8E041FFACD586F13C32CA74@buildpc> From: "Valery Smyslov" To: "Yoav Nir" References: <54947C0C-EB83-4BD7-8DB1-979F68037B10@gmail.com> <3C34F58C00A4424E992DC2D37F61D36F@buildpc> <876B1AC1A5984E8FB8B6C3D8F55E8C08@buildpc> <2777D644-99B4-41F4-9DF0-EF7EB2F560A3@gmail.com> Date: Thu, 18 Feb 2016 18:46:25 +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: Cc: ipsec@ietf.org Subject: Re: [IPsec] DDoS Protection - single vs multiple solutions 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, 18 Feb 2016 15:46:37 -0000 > With a chain such as you’re suggesting, I could still parallelize. For each step I could still > partition the key space and search in parallel until one solution was found before proceeding to the next step. Yes. So it seems that the chaining is useless. > Yoav Regards, Valery. From nobody Fri Feb 19 14:03:43 2016 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 637111B2D4D for ; Fri, 19 Feb 2016 14:03:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.106 X-Spam-Level: X-Spam-Status: No, score=-13.106 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 mv5j8vaOhu0w for ; Fri, 19 Feb 2016 14:03:39 -0800 (PST) Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAF061B2A13 for ; Fri, 19 Feb 2016 14:03:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7964; q=dns/txt; s=iport; t=1455919419; x=1457129019; h=from:to:subject:date:message-id:mime-version; bh=kQ4f5n/rbS61iD6+PLFQmx26KkEXJQ0AZ9SNEn6tqWo=; b=hfcP2zQ0Uy+VDAaFEyiCXzovjOQfRAhqxGIqkT1ltCRQGQ5kvxM++qRM UfKPJgSpvHXuxF32v6vC8jcbpVcFoRBj6pM121Iglng+5vPiF33yYwpYJ mEA2uz95cEHLE2pweq26nZMLwzGXc8RTv7wur1DzPADSbEpZnHX5bRVKa k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ApBQBxkMdW/5BdJa1VCYJuTFJzvDUhh?= =?us-ascii?q?WyBWTwQAQEBAQEBAWQnhEgtXgGBACYBBBsTh38OnTWeSQEBAQEBAQQBAQEBAQE?= =?us-ascii?q?WBIYSiEdWhA0FlwcBjVaOeo5HATcrggMZgUiIZ30BAQE?= X-IronPort-AV: E=Sophos;i="5.22,472,1449532800"; d="scan'208,217";a="240587647" Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Feb 2016 22:03:38 +0000 Received: from XCH-RCD-010.cisco.com (xch-rcd-010.cisco.com [173.37.102.20]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u1JM3cKv013129 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL) for ; Fri, 19 Feb 2016 22:03:38 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-010.cisco.com (173.37.102.20) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 19 Feb 2016 16:03:37 -0600 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Fri, 19 Feb 2016 16:03:39 -0600 From: "Scott Fluhrer (sfluhrer)" To: "IPsecme WG (ipsec@ietf.org)" Thread-Topic: draft-fluhrer-qr-ikev2-01 Thread-Index: AdFrYV92xfNPMN/lQHOXoduZDaDkow== Date: Fri, 19 Feb 2016 22:03:39 +0000 Message-ID: <46cc66173e324ae0b788f36cd58f5dfa@XCH-RCD-006.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.59] Content-Type: multipart/alternative; boundary="_000_46cc66173e324ae0b788f36cd58f5dfaXCHRCD006ciscocom_" MIME-Version: 1.0 Archived-At: Subject: [IPsec] draft-fluhrer-qr-ikev2-01 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, 19 Feb 2016 22:03:42 -0000 --_000_46cc66173e324ae0b788f36cd58f5dfaXCHRCD006ciscocom_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Last year, NSA made an announcement about how to deal with the potentiality= of someone developing a Quantum Computer; (https://www.nsa.gov/ia/programs= /suiteb_cryptography/). Among their recommendations was the advice that: "CSfC deployments involving an IKE/IPsec layer may use RFC 2409-conformant = implementations of the IKE standard (IKEv1) together with large, high-entro= py, pre-shared keys and the AES-256 encryption algorithm. RFC 2409 is the o= nly version of the IKE standard that leverages symmetric pre-shared keys in= a manner that may achieve quantum resistant confidentiality. The reason they gave this advise was the IKEv1, unlike IKEv2, stirred in th= e preshared key into the KDF function (along with the (EC)DH shared secret)= ; hence if the preshared key was strong, then Shor's algorithm (which can r= ecover the (EC)DH shared secret) is not enough to recover the negotiated ke= ys. Now, we don't want people to migrate back to an obsolete version of the pro= tocol; hence we've devised a way to strengthen IKEv2 the same way. It was considered important to minimize the changes made to IKEv2. From a = cryptographical prespective, the only change we make is that we modify the = nonces that we present to the KDF. By keeping the cryptographical changes = minimal, we reduce the risk of accidentally introducing a weakness. Like IKEv1, this solution assumes that the initiator and the responder shar= e a secret string (called a PPK in the draft). However, unlike IKEv1, that= is not the only authentication that's in the system. We leave the existin= g authentication methods in place, and add this in addition. One thing that was a source of complexity was that we did not want to assum= e that every system had the same PPK; that instead that systems would want = a pairwise PPK. However, if a responder configured its PPK on a per-peer b= asis, and didn't learn the peer until after an IKEv2 tunnel has been establ= ished, that would mean that the responder would need to know the PPK before= it officially learned the peer. To solve this, we added the PPK_REQUEST/P= PK_ENCODE notifications to give the responder a hint about which PPK to use= (without leaking the identity to third parties). Would anyone be willing to review this draft? I believe that we have a nee= d for such a solution. --_000_46cc66173e324ae0b788f36cd58f5dfaXCHRCD006ciscocom_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Last year, NSA made an announcement about how to dea= l with the potentiality of someone developing a Quantum Computer; (https://www.nsa.g= ov/ia/programs/suiteb_cryptography/).  Among their recommendations was the advice that:

 

“CSfC deployments i= nvolving an IKE/IPsec layer may use RFC 2409-conformant implementations of = the IKE standard (IKEv1) together with large, high-entropy, pre-shared keys= and the AES-256 encryption algorithm. RFC 2409 is the only version of the IKE standard that leverages symmetric pre-= shared keys in a manner that may achieve quantum resistant confidentiality.=

 

The reason they gave this advise was the IKEv1, unli= ke IKEv2, stirred in the preshared key into the KDF function (along with th= e (EC)DH shared secret); hence if the preshared key was strong, then Shor&#= 8217;s algorithm (which can recover the (EC)DH shared secret) is not enough to recover the negotiated keys.

 

Now, we don’t want people to migrate back to a= n obsolete version of the protocol; hence we’ve devised a way to stre= ngthen IKEv2 the same way.

 

It was considered important to minimize the changes = made to IKEv2.  From a cryptographical prespective, the only change we= make is that we modify the nonces that we present to the KDF.  By kee= ping the cryptographical changes minimal, we reduce the risk of accidentally introducing a weakness.

 

Like IKEv1, this solution assumes that the initiator= and the responder share a secret string (called a PPK in the draft). = However, unlike IKEv1, that is not the only authentication that’s in= the system.  We leave the existing authentication methods in place, and add this in addition.

 

One thing that was a source of complexity was that w= e did not want to assume that every system had the same PPK; that instead t= hat systems would want a pairwise PPK.  However, if a responder config= ured its PPK on a per-peer basis, and didn’t learn the peer until after an IKEv2 tunnel has been established, that woul= d mean that the responder would need to know the PPK before it officially l= earned the peer.  To solve this, we added the PPK_REQUEST/PPK_ENCODE n= otifications to give the responder a hint about which PPK to use (without leaking the identity to third parties= ).

 

 

Would anyone be willing to review this draft?  = I believe that we have a need for such a solution.

--_000_46cc66173e324ae0b788f36cd58f5dfaXCHRCD006ciscocom_-- From nobody Fri Feb 19 16:21:37 2016 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 E52341A89ED for ; Fri, 19 Feb 2016 16:21:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.006] 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 tWLgs2b5d270 for ; Fri, 19 Feb 2016 16:21:36 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 E4CF71A1A2C for ; Fri, 19 Feb 2016 16:21:35 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3q6VnS6TWVz54H; Sat, 20 Feb 2016 01:21:32 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id yg_tjfo8K64C; Sat, 20 Feb 2016 01:21:30 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Sat, 20 Feb 2016 01:21:30 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 4041D6000062; Fri, 19 Feb 2016 19:21:29 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 4041D6000062 Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 3B25A25936; Fri, 19 Feb 2016 19:21:29 -0500 (EST) Date: Fri, 19 Feb 2016 19:21:29 -0500 (EST) From: Paul Wouters To: "Scott Fluhrer (sfluhrer)" In-Reply-To: <46cc66173e324ae0b788f36cd58f5dfa@XCH-RCD-006.cisco.com> Message-ID: References: <46cc66173e324ae0b788f36cd58f5dfa@XCH-RCD-006.cisco.com> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Cc: "IPsecme WG \(ipsec@ietf.org\)" Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01 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, 20 Feb 2016 00:21:37 -0000 On Fri, 19 Feb 2016, Scott Fluhrer (sfluhrer) wrote: > Last year, NSA made an announcement about how to deal with the potentiality of someone developing a Quantum Computer; (https://www.nsa.gov/ia/programs/suiteb_cryptography/).  Among their > recommendations was the advice that: > > “CSfC deployments involving an IKE/IPsec layer may use RFC 2409-conformant implementations of the IKE standard (IKEv1) together with large, high-entropy, pre-shared keys and the AES-256 > encryption algorithm. RFC 2409 is the only version of the IKE standard that leverages symmetric pre-shared keys in a manner that may achieve quantum resistant confidentiality. > > The reason they gave this advise was the IKEv1, unlike IKEv2, stirred in the preshared key into the KDF function (along with the (EC)DH shared secret); hence if the preshared key was > strong, then Shor’s algorithm (which can recover the (EC)DH shared secret) is not enough to recover the negotiated keys. > Now, we don’t want people to migrate back to an obsolete version of the protocol; hence we’ve devised a way to strengthen IKEv2 the same way. > Would anyone be willing to review this draft?  I believe that we have a need for such a solution. Yes, I am happy to review. I also think this might make a good topic to discuss face to face at the next meeting. Paul From nobody Sat Feb 20 00:12:11 2016 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 967A31A0114 for ; Sat, 20 Feb 2016 00:12:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.229 X-Spam-Level: X-Spam-Status: No, score=-1.229 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, 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 cEICPY4J2LBt for ; Sat, 20 Feb 2016 00:12:06 -0800 (PST) Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDC921A0108 for ; Sat, 20 Feb 2016 00:12:05 -0800 (PST) Received: by mail-lf0-x236.google.com with SMTP id j78so67234223lfb.1 for ; Sat, 20 Feb 2016 00:12:05 -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; bh=T01NmHFjBxuwzl6IgThbq+5wHO4zoPWwUiwjEY/co9o=; b=k0/38CbkMXZSEJq79xj2SKfyZG06qeCfLCZ0J4r8fUleDlvS8mClUiAtBnZdxjXuil unj+cKVkiXtcfVjuFMjSaWFsHeeKAinO3bk2JOBBxfqOQXB7VYtLPjMkuGFD80+nur0c vnjtcahMdzx22V+0v8y7ctvaiGlOv1E7yu4gnfjbp6ovyIM2uqdzo7coHjw8LSTDZu3V ZKkJWRgBzCBMvHrZXVygNftF3mb8zPp/suyU0+5I9cydsUC7WFqhMpwKRiFovZhfMETV oh572kqEkbdyn588NWKqIWgm2Xwx7JS4084SGJ5l9kLI5Fn1mGXJfNiczgUThfCOn6fU RlBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:references:subject:date :mime-version:content-type; bh=T01NmHFjBxuwzl6IgThbq+5wHO4zoPWwUiwjEY/co9o=; b=J7RJC3+crI+MAiPncBPFG2lbpTBpBW9NMxj1wbvsf0cupgxScCKeA1+fYR1nAdobA9 J1J7QQiSxxYXt2fi5ZLBUNVKGDN0ecKJLukcN1USu/u3iQxog0boeECdaQG6Ai00zFM1 zHbYuGkzeKo4FEVmPMaOAvuTEh3OvY7EeaRk0LPgmqYaU7oG/A02xlhVvZtU0CnjNf5d yKvg/ly8904hC5XK4p3GYjgAc7fQDIPKLE0vCifEuWq1wS0Yzy4yvuaxYS+b0evgmqfx 6Oqnz0gcagKc8qsTOXuJOeyvK6AQSS3Jf3GExkvTjms1BdYS6F5IPRUrzDAP9ldoHdjS CnXQ== X-Gm-Message-State: AG10YOQ5HSjC2gQ4rTAdBh88JZ09MS9wd9/dQ0Uq9D5jyKgVbDn3x9JqVPMklj+q4K3Xkg== X-Received: by 10.25.91.20 with SMTP id p20mr5706780lfb.79.1455955924019; Sat, 20 Feb 2016 00:12:04 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id n96sm2011497lfi.45.2016.02.20.00.12.03 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 20 Feb 2016 00:12:03 -0800 (PST) Message-ID: <81FF76AD3936477D913A27BED694E464@buildpc> From: "Valery Smyslov" To: "Scott Fluhrer \(sfluhrer\)" , References: <46cc66173e324ae0b788f36cd58f5dfa@XCH-RCD-006.cisco.com> Date: Sat, 20 Feb 2016 11:12:01 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0093_01D16BCF.85650ED0" 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: Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01 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, 20 Feb 2016 08:12:09 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0093_01D16BCF.85650ED0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Scott, thank you for issuing a new version of the draft that addresses most of = my comments on -00 version. However I still have some concerns. I'm not happy with the way algorithm = agility support is added into the draft.=20 Currently the draft specifies PPK Indicator Algorithm as a 4 bytes long = integer with a single defined value of 1 (AES256_SHA256). This definition does imply the need = for new registry since more algorithms would be specified. I don't see any = compelling reason to add a new registry, since the existing registries can be reused.=20 I'd propose the following way to support algorithm agility. When the responder receives the initial request with PPK_REQUEST = notification, it parses SA payload collecting all PRF type transforms. The result is the list of = PRFs the initiator supports. The responder picks the most preferred PRF from the list and = returns=20 its value (as defined in the IKEv2 registry "Transform Type 2 - = Pseudo-random Function Transform IDs")=20 as PPK Indicator algorithm in PPK_ENCODE notification. The PPK indicator = is computed using this PRF as foolws: ppk_indicator =3D PRF(PRF(ppk, "A"), ppk_indicator_input) This proposal has the following advantages. 1. Reusing existing IKEv2 registry 2. Better interoperability, since the PRF transform is mandatory in the = SA payload in IKEv2 and the responder can always be sure that the chosen PRF is = supported by the initiator. With the current proposal the situation is = possible when=20 the initiator includes, for example, only AEAD transforms in SA = payload. In this case even AEAD transform is (for example) AES based, there = is no guarantee that plain AES encryption is also supported by the initiator. 3. The current PPK Indicator Algorithm field combines 2 algorithms - = encryption and prf. Once more algorithms are supported as PPK indicator the = size of the registry will be grown quickly since every new prf will be = combined with every new cipher (yes, it can be limited by combining only selected prfs with only selected ciphers, but that would reduce = interoperability). This would make the idea of precomputing ppk indicators on responder less efficient (you may easily precompute the whole ppk database = using few popular PRFs, but if these PRFs are combined with ciphers -=20 the resulting number of their combinations could become too big). I see the only disadvantage of this proposal. As you wrote you = specifically used combination of encryption and PRF since AES is supported in = hardware=20 on some CPUs and thus gives some performance advantages over PRF-only scheme. I don't think it is a compelling argument. It reflects only the = current situation in the industry and may change over time. I don't think the = protocol should be based on such shaky grounds. Am I missing something? Few editorial issues: 1. Abstract No point at the end of the abstract. 2. Section 1 [The general idea is that we add an additional secret that is shared between the initiator and the responder; this secret is in addition to the authentication method that is already provided within IKEv2.] s/in addition/an addition ?=20 3. IANA Considerations section is missing. Regards, Valery Smyslov. Last year, NSA made an announcement about how to deal with the = potentiality of someone developing a Quantum Computer; = (https://www.nsa.gov/ia/programs/suiteb_cryptography/). Among their = recommendations was the advice that: =20 "CSfC deployments involving an IKE/IPsec layer may use RFC = 2409-conformant implementations of the IKE standard (IKEv1) together = with large, high-entropy, pre-shared keys and the AES-256 encryption = algorithm. RFC 2409 is the only version of the IKE standard that = leverages symmetric pre-shared keys in a manner that may achieve quantum = resistant confidentiality. =20 The reason they gave this advise was the IKEv1, unlike IKEv2, stirred = in the preshared key into the KDF function (along with the (EC)DH shared = secret); hence if the preshared key was strong, then Shor's algorithm = (which can recover the (EC)DH shared secret) is not enough to recover = the negotiated keys. =20 Now, we don't want people to migrate back to an obsolete version of = the protocol; hence we've devised a way to strengthen IKEv2 the same = way. =20 It was considered important to minimize the changes made to IKEv2. = >From a cryptographical prespective, the only change we make is that we = modify the nonces that we present to the KDF. By keeping the = cryptographical changes minimal, we reduce the risk of accidentally = introducing a weakness. =20 Like IKEv1, this solution assumes that the initiator and the responder = share a secret string (called a PPK in the draft). However, unlike = IKEv1, that is not the only authentication that's in the system. We = leave the existing authentication methods in place, and add this in = addition. =20 One thing that was a source of complexity was that we did not want to = assume that every system had the same PPK; that instead that systems = would want a pairwise PPK. However, if a responder configured its PPK = on a per-peer basis, and didn't learn the peer until after an IKEv2 = tunnel has been established, that would mean that the responder would = need to know the PPK before it officially learned the peer. To solve = this, we added the PPK_REQUEST/PPK_ENCODE notifications to give the = responder a hint about which PPK to use (without leaking the identity to = third parties). =20 =20 Would anyone be willing to review this draft? I believe that we have = a need for such a solution. -------------------------------------------------------------------------= ----- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0093_01D16BCF.85650ED0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Scott,
 
thank you for issuing a new version of the draft = that=20 addresses most of my comments on -00 version.
 
However I still have some concerns. I'm not happy = with the way=20 algorithm agility support is added
into the draft.
 
Currently the draft specifies PPK Indicator = Algorithm as a 4=20 bytes long integer with a single
defined value of 1 (AES256_SHA256). This definition = does imply=20 the need for new
registry since more algorithms would be specified. I = don't see=20 any compelling reason to add a new registry,
since the existing registries can be=20 reused. 
 
I'd propose the following way to support algorithm=20 agility.
 
When the responder receives the initial request with = PPK_REQUEST notification, it parses
SA payload collecting all PRF type = transforms. The=20 result is the list of PRFs the initiator
supports. The responder picks the most preferred PRF = from the=20 list and returns
its value (as defined in the IKEv2 registry = "Transform Type 2=20 - Pseudo-random Function Transform IDs") 
as PPK Indicator algorithm in = PPK_ENCODE=20 notification. The PPK indicator is computed
using this PRF as foolws:
 
ppk_indicator =3D PRF(PRF(ppk, "A"),=20 ppk_indicator_input)
 
This proposal has the following = advantages.
1. Reusing existing IKEv2 registry
2. Better interoperability, since the PRF = transform is=20 mandatory in the SA payload
    in IKEv2 and the responder can = always be=20 sure that the chosen PRF is supported
    by the initiator. With the = current proposal=20 the situation is possible when
    the initiator includes, for = example, only=20 AEAD transforms in SA payload.
    In this case even AEAD transform = is (for=20 example) AES based, there is no guarantee
    that plain AES encryption is also = supported=20 by the initiator.
3. The current PPK Indicator Algorithm field = combines 2=20 algorithms - encryption
    and prf. Once more algorithms are = supported=20 as PPK indicator the size
    of the registry will be grown = quickly since=20 every new prf will be combined
    with every new cipher (yes, it = can be=20 limited by combining only
    selected prfs with only selected = ciphers,=20 but that would reduce interoperability).
    This would make the idea of = precomputing=20 ppk indicators on responder
    less efficient (you may easily = precompute=20 the whole ppk database using few
    popular PRFs, but if these PRFs = are=20 combined with ciphers -
    the resulting number of their = combinations=20 could become too big).
 
I see the only disadvantage of this proposal. As you = wrote you=20 specifically
used combination of encryption and PRF since = AES is supported in hardware
on some CPUs and thus gives = some=20 performance advantages over PRF-only
scheme. I don't think it is a compelling = argument. It=20 reflects only the current
situation in the industry and may change over time. = I don't=20 think the protocol
should be based on such shaky grounds. Am I missing=20 something?
 
 
Few editorial issues:
 
1. Abstract
    No point at the end of the=20 abstract.
 
2. Section 1
   [The general idea is that we add an = additional=20 secret that is shared
   between the initiator and the = responder;=20 this secret is in addition
   to the authentication method = that is=20 already provided within IKEv2.]
    s/in addition/an addition ? =
 
3. IANA Considerations section is = missing.
 
Regards,
Valery Smyslov.
 
 
 

Last year, NSA made an announcement about how to = deal with=20 the potentiality of someone developing a Quantum Computer; (https://www= .nsa.gov/ia/programs/suiteb_cryptography/). =20 Among their recommendations was the advice that:

 

=93CSfC deployments = involving an=20 IKE/IPsec layer may use RFC 2409-conformant implementations of the IKE = standard (IKEv1) together with large, high-entropy, pre-shared keys = and the=20 AES-256 encryption algorithm. RFC 2409 is the only version of the IKE = standard=20 that leverages symmetric pre-shared keys in a manner that may achieve = quantum=20 resistant confidentiality.

 

The reason they gave this advise was the IKEv1, = unlike=20 IKEv2, stirred in the preshared key into the KDF function (along with = the=20 (EC)DH shared secret); hence if the preshared key was strong, then = Shor=92s=20 algorithm (which can recover the (EC)DH shared secret) is not enough = to=20 recover the negotiated keys.

 

Now, we don=92t want people to migrate back to an = obsolete=20 version of the protocol; hence we=92ve devised a way to strengthen = IKEv2 the=20 same way.

 

It was considered important to minimize the = changes made to=20 IKEv2.  From a cryptographical prespective, the only change we = make is=20 that we modify the nonces that we present to the KDF.  By keeping = the=20 cryptographical changes minimal, we reduce the risk of accidentally=20 introducing a weakness.

 

Like IKEv1, this solution assumes that the = initiator and=20 the responder share a secret string (called a PPK in the draft).  = However, unlike IKEv1, that is not the only authentication that=92s in = the=20 system.  We leave the existing authentication methods in place, = and add=20 this in addition.

 

One thing that was a source of complexity was = that we did=20 not want to assume that every system had the same PPK; that instead = that=20 systems would want a pairwise PPK.  However, if a responder = configured=20 its PPK on a per-peer basis, and didn=92t learn the peer until after = an IKEv2=20 tunnel has been established, that would mean that the responder would = need to=20 know the PPK before it officially learned the peer.  To solve = this, we=20 added the PPK_REQUEST/PPK_ENCODE notifications to give the responder a = hint=20 about which PPK to use (without leaking the identity to third=20 parties).

 

 

Would anyone be willing to review this = draft?  I=20 believe that we have a need for such a solution.

_______________________________________________
IPsec = mailing=20 = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
= ------=_NextPart_000_0093_01D16BCF.85650ED0-- From nobody Sat Feb 20 07:12:58 2016 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 27CC31A88E1 for ; Sat, 20 Feb 2016 07:12:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.347 X-Spam-Level: X-Spam-Status: No, score=-1.347 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553] 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 fn7p5E1y8Pce for ; Sat, 20 Feb 2016 07:12:55 -0800 (PST) Received: from hoffman.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 B35751A877A for ; Sat, 20 Feb 2016 07:12:55 -0800 (PST) Received: from [192.168.114.1] (50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216]) (authenticated bits=0) by hoffman.proper.com (8.15.2/8.14.9) with ESMTPSA id u1KFCrZv091593 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 20 Feb 2016 08:12:54 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) X-Authentication-Warning: hoffman.proper.com: Host 50-1-98-216.dsl.dynamic.fusionbroadband.com [50.1.98.216] claimed to be [192.168.114.1] From: "Paul Hoffman" To: "Valery Smyslov" Date: Sat, 20 Feb 2016 07:12:53 -0800 Message-ID: <85BF557F-8A66-405E-B879-E02A01EBA365@vpnc.org> In-Reply-To: <81FF76AD3936477D913A27BED694E464@buildpc> References: <46cc66173e324ae0b788f36cd58f5dfa@XCH-RCD-006.cisco.com> <81FF76AD3936477D913A27BED694E464@buildpc> MIME-Version: 1.0 Content-Type: text/plain; format=flowed X-Mailer: MailMate (1.9.3r5187) Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01 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, 20 Feb 2016 15:12:57 -0000 Your proposal of using heuristics from the SA payload instead of using a new registry seems like a bad tradeoff. It costs nothing to create a new registry. Further, the code that implementers need to write to use the new registered value is smaller *and more definitive* than the code needed to use your proposed heuristics. As for your prediction that AES support might be removed from some CPUs in the future: that seems particularly unlikely. Basically, you never see CPU features removed from a product line. You sometimes see new families of low-end CPUs designed without all the features of current CPUs, but even that would not be a negative here. Further, if we need algorithms beyond AES in the future, it seems really likely that a competition for a replacement would favor one that could re-use the AES support in current chips. I think a small registry for the (hopefully) few developers who care about QR a decade before anyone thinks there is any possibility of its use is a reasonable way forward. --Paul Hoffman From nobody Sat Feb 20 08:42:55 2016 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 CF0E81A8981 for ; Sat, 20 Feb 2016 08:42:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.15 X-Spam-Level: *** X-Spam-Status: No, score=3.15 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, MIME_CHARSET_FARAWAY=2.45, 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 r1BNNghguvlC for ; Sat, 20 Feb 2016 08:42:52 -0800 (PST) Received: from mail-lb0-x22f.google.com (mail-lb0-x22f.google.com [IPv6:2a00:1450:4010:c04::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C94BE1A8958 for ; Sat, 20 Feb 2016 08:42:51 -0800 (PST) Received: by mail-lb0-x22f.google.com with SMTP id bc4so62547832lbc.2 for ; Sat, 20 Feb 2016 08:42:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:from:to:cc:references:in-reply-to:subject:date :mime-version:content-type:content-transfer-encoding:importance; bh=UIsL9D+w441zYOP7M16BFejTblx28QgqJYs8PtKCe9E=; b=yc1MHkP/P09nozdf6y7DbIgv7NfqGr9czkfEof8yaIhrKCl2TlbK/NSjf1Eandudpp kMoTFSCKhxCoCV5DVRyhAgbsvBR70GwuNoDVefAdWttBSP4bYiQdcWqY/i0Svmekk8HZ 2wFAegTcosXGmfpvBz0UvW8ztRb87KZ8kNc8n3Z0AzzFvLELcmZXKTp3dQm9UtCHrUX0 D4HlwimvxIaa0V4k3H6nku89dOmkaG0gvAUlclwqvDw8lZEG0GYShuNwH46p3YfWYx6E B5nWr6QeIS5BH2YHoonXgcPbc3RNoH9PfSgI9zaTiQ2iykp65juCNVelAMKtY0DFk+I5 ZKgQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:in-reply-to :subject:date:mime-version:content-type:content-transfer-encoding :importance; bh=UIsL9D+w441zYOP7M16BFejTblx28QgqJYs8PtKCe9E=; b=CJg2x4zOHEwomagMDJ1588TU5MkrnkflKPoyg7cCBw+RpkMox4+D1zOFovtz1f56YL ycIoJAdDEMDpp1C4P6gIC8/CJ+c4QnIVj2BNhFyt5qJVPG4083Y8Ygt7SI9gfb4C5Uk1 8oHfBVpGcZCOKiHdF5kweWe2WYkAHVsqXM2et1hZrMwaze/dcrfS2tbs1U0kZc8IErZs JYvU1P4QQSfUNh5cFNoz1Wp5htFVzPoTxdBBA58b/5BlQ2DYFv4BfSG3zuOzTHhGZ2jT xVq+KRkXFQftciZ3iUi3dKkCCwfnE4rfoi9h+6Q8JbdWgsJuzrnFWL8N/5dbZTa4Imkp z2Rw== X-Gm-Message-State: AG10YOSvCZi+ct1PbxJNszMH8lqsihyPcQWTGht+kyN688VXz2pcDiZj3FOHTet6M2QHYA== X-Received: by 10.112.77.138 with SMTP id s10mr6299402lbw.125.1455986570054; Sat, 20 Feb 2016 08:42:50 -0800 (PST) Received: from chichi (ppp85-140-202-132.pppoe.mtu-net.ru. [85.140.202.132]) by smtp.gmail.com with ESMTPSA id td7sm2164327lbb.6.2016.02.20.08.42.48 (version=TLSv1/SSLv3 cipher=OTHER); Sat, 20 Feb 2016 08:42:49 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Paul Hoffman" References: <46cc66173e324ae0b788f36cd58f5dfa@XCH-RCD-006.cisco.com> <81FF76AD3936477D913A27BED694E464@buildpc> <85BF557F-8A66-405E-B879-E02A01EBA365@vpnc.org> In-Reply-To: <85BF557F-8A66-405E-B879-E02A01EBA365@vpnc.org> Date: Sat, 20 Feb 2016 19:42:42 +0300 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="koi8-r"; reply-type=response Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal Importance: Normal X-Mailer: Microsoft Windows Live Mail 16.4.3528.331 X-MimeOLE: Produced By Microsoft MimeOLE V16.4.3528.331 Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01 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, 20 Feb 2016 16:42:54 -0000 Hi Paul, there is no heuristics in my proposal. The initiator's SA payload contains all PRFs it supports. The responder can pick up any of them and be sure that the chosen PRF is supported by initiator. It is a native negotiation mechanism of IKEv2. And note that DDoS protection draft uses exactly the same mechanism. And I never said that support for AES will be removed. I meant that there are some alternatives for AES (like Chacha20), which are not supported in hardware. Moreover, if (for example) SHA2 is supported in hardware tomorrow, then there will be no perfirmance advantages in using AES. What about the registries - I just follow Occam's razor principle. Regards, Valery. -----Original Message----- From: Paul Hoffman Date: 20 ÆÅ×ÒÁÌÑ 2016 Ç. 18:12 To: Valery Smyslov Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01 Your proposal of using heuristics from the SA payload instead of using a new registry seems like a bad tradeoff. It costs nothing to create a new registry. Further, the code that implementers need to write to use the new registered value is smaller *and more definitive* than the code needed to use your proposed heuristics. As for your prediction that AES support might be removed from some CPUs in the future: that seems particularly unlikely. Basically, you never see CPU features removed from a product line. You sometimes see new families of low-end CPUs designed without all the features of current CPUs, but even that would not be a negative here. Further, if we need algorithms beyond AES in the future, it seems really likely that a competition for a replacement would favor one that could re-use the AES support in current chips. I think a small registry for the (hopefully) few developers who care about QR a decade before anyone thinks there is any possibility of its use is a reasonable way forward. --Paul Hoffman From nobody Mon Feb 22 03:21:01 2016 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 66E801A8992 for ; Mon, 22 Feb 2016 03:20:58 -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 P0FP2l7D1JXA for ; Mon, 22 Feb 2016 03:20:55 -0800 (PST) Received: from mail-wm0-x236.google.com (mail-wm0-x236.google.com [IPv6:2a00:1450:400c:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E16611A1B1D for ; Mon, 22 Feb 2016 03:20:54 -0800 (PST) Received: by mail-wm0-x236.google.com with SMTP id g62so167215158wme.1 for ; Mon, 22 Feb 2016 03:20:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:subject:message-id:date:to:mime-version; bh=3KN18hU8Nh03XLUyAvsDLfOiKU+167cv8DqbRBg+UNc=; b=ZcmmQQmkb27/R/zCUxWgpUsBPUR9b209KlwVap/IDEO8TK+KQP2ulL2bmoPFSxvQD5 W4esw/CppKDbhxn3LDUY0k8Xk+Q64G5wjsdLFDqtlZ5zDWaXpdf21GIYcHtzEeqhOsJN vx3/mSjHxDhN5+Dc6/a+egJkuPM2Oh6uFxsU8yDAyENyhcIV7JZh4yQbtHhs527DlDMQ hmxDXEG0K5zkOeJ3eADgTCpsvS3vLRMr4bTx5v5AtqW6A7tzZ3uh/2OCS9fBfx2T6J+6 owslhj5hGt4Z16pVuXc3YzwyTIFJlfTynR6XJmZZsZQFZTcTWpJeqU4RPlXCtakmVTI2 ZDEA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:subject:message-id:date:to:mime-version; bh=3KN18hU8Nh03XLUyAvsDLfOiKU+167cv8DqbRBg+UNc=; b=WxxR+NsgqwkhfhQlbjLWdUhGDtwrkfTlsIreNBxj/6vnjXwGFOWki/Gv1TInyy2/bP i+rr4V3R08gfCAEeLKfi/dCR3XoXFR6R8lLdgkYtuiWz+EyNdgbCiZuUQ4wKGagJRNx1 9XpVdasQmL0aA8H/PBaZkNqZ+vDjr14kYSDTj5Pmf4CP7e2WgJQDs+dMJKX4H41PbdTP Mr2/eCt5Azt+LA95n0Wi0VpKD02ETiT6si9xJzNB1zGofuoQanjRj2ktG4u6WsxiLje5 Ez6dE3iHy3GGvgVFSLUYrHr4L/YcQOGN7zB36B7jBgbr3WS+StnAz3PWIC4fPqghEm2z uCHw== X-Gm-Message-State: AG10YOTJ5jZ+Mrck38VzDoKM/buNmhI3LYdBsfhWjdZoitR9nZNg+vQFah7akF50uQD3iw== X-Received: by 10.28.21.21 with SMTP id 21mr11075751wmv.38.1456140053484; Mon, 22 Feb 2016 03:20:53 -0800 (PST) Received: from [172.24.249.139] (dyn32-131.checkpoint.com. [194.29.32.131]) by smtp.gmail.com with ESMTPSA id fv6sm20601110wjc.12.2016.02.22.03.20.52 for (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 22 Feb 2016 03:20:52 -0800 (PST) From: Yoav Nir Content-Type: multipart/alternative; boundary="Apple-Mail=_B233799B-E2F5-46C6-AA6B-3F88CA533323" Message-Id: <9DC60612-D5BC-4D55-8364-90DA5CAEB41F@gmail.com> Date: Mon, 22 Feb 2016 13:20:49 +0200 To: "ipsec@ietf.org WG" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) X-Mailer: Apple Mail (2.3112) Archived-At: Subject: [IPsec] Textual changes to the DDoS draft 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, 22 Feb 2016 11:20:58 -0000 --Apple-Mail=_B233799B-E2F5-46C6-AA6B-3F88CA533323 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi all Valery submitted a new PR with a couple of textual changes, mostly based = on comments by Dave. https://github.com/ietf-ipsecme/drafts/pull/12 = The changes (listed below) seem fine to me. If nobody objects, I will = merge them in on Friday. Yoav List of changes: #1: Change snarky reference to Starbucks to something less snarky and = less related to starbucks: OLD: For example, if a certain purveyor of beverages resembling coffee = provides Internet connectivity to its customers through an IPv4 NAT = device, a single malicious customer can create enough half-open SAs to = fill the quota for the NAT device external IP address. Legitimate = Initiators on the same network will not be able to initiate IKE. NEW: For example, if an network service provider or some establishment offers = Internet connectivity to its customers or employees through an IPv4 NAT = device, a single malicious customer can create enough half-open SAs to = fill the quota for the NAT device external IP address. Legitimate = Initiators on the same network will not be able to initiate IKE. #2: Purely textual change OLD: Regardless of the type of rate-limiting used, there is a huge advantage = in blocking the DoS attack using rate-limiting in that legitimate = clients who are away from the attacking nodes should not be adversely = affected by either the attack or by the measures used to counteract it. NEW: Regardless of the type of rate-limiting used, there is a huge advantage = in blocking the DoS attack using rate-limiting for legitimate clients = that are away from the attacking nodes. In such cases, adverse impacts = caused by the attack or by the measures used to counteract the attack = can be avoided.= --Apple-Mail=_B233799B-E2F5-46C6-AA6B-3F88CA533323 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi all

Valery submitted a new PR with a couple of textual changes, = mostly based on comments by Dave.

https://github.com/ietf-ipsecme/drafts/pull/12

The changes (listed = below) seem fine to me. If nobody objects, I will merge them in on = Friday.

Yoav

List of changes:

#1: Change snarky reference to Starbucks to something less = snarky and less related to starbucks:
OLD:
For example, if a certain purveyor of beverages resembling = coffee provides Internet connectivity to its customers through an IPv4 = NAT device, a single malicious customer can create enough half-open SAs = to fill the quota for the NAT device external IP address. Legitimate = Initiators on the same network will not be able to initiate = IKE.

NEW:
For example, if an network service = provider or some establishment offers Internet connectivity to its = customers or employees through an IPv4 NAT device, a single malicious = customer can create enough half-open SAs to fill the quota for the NAT = device external IP address. Legitimate Initiators on the same network = will not be able to initiate IKE.


#2: = Purely textual change
OLD:
Regardless of the type of rate-limiting used, there is a huge = advantage in blocking the DoS attack using rate-limiting in that = legitimate clients who are away from the attacking nodes should not be = adversely affected by either the attack or by the measures used to = counteract it.

NEW:
Regardless of the type of = rate-limiting used, there is a huge advantage in blocking the DoS attack = using rate-limiting for legitimate clients that are away from the = attacking nodes. In such cases, adverse impacts caused by the attack or = by the measures used to counteract the attack can be = avoided.
= --Apple-Mail=_B233799B-E2F5-46C6-AA6B-3F88CA533323-- From nobody Tue Feb 23 08:54:33 2016 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 C16651B363E for ; Tue, 23 Feb 2016 08:54:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.179 X-Spam-Level: ** X-Spam-Status: No, score=2.179 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_12=0.6, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQfV5LsIxtqY for ; Tue, 23 Feb 2016 08:54:29 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 DEE5F1B2B46 for ; Tue, 23 Feb 2016 08:53:16 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u1NGr6Z3022793 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 23 Feb 2016 18:53:06 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u1NGr5xP001910; Tue, 23 Feb 2016 18:53:05 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Message-ID: <22220.36465.788794.855413@fireball.acr.fi> Date: Tue, 23 Feb 2016 18:53:05 +0200 From: Tero Kivinen To: "Scott Fluhrer \(sfluhrer\)" In-Reply-To: <46cc66173e324ae0b788f36cd58f5dfa@XCH-RCD-006.cisco.com> References: <46cc66173e324ae0b788f36cd58f5dfa@XCH-RCD-006.cisco.com> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 33 min X-Total-Time: 33 min Archived-At: Cc: "IPsecme WG \(ipsec@ietf.org\)" Subject: [IPsec] draft-fluhrer-qr-ikev2-01 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 Feb 2016 16:54:32 -0000 Scott Fluhrer (sfluhrer) writes: > The reason they gave this advise was the IKEv1, unlike IKEv2, > stirred in the preshared key into the KDF function (along with the > (EC)DH shared secret); hence if the preshared key was strong, then > Shor=E2=80=99s algorithm (which can recover the (EC)DH shared secret)= is not > enough to recover the negotiated keys. The fact that IKEv1 stirred the preshared keys when generating the keying material for the IKE SA encryption etc keys was the reason that Main mode of the IKEv1 cannot be used in general case. I.e. as in IKEv1 when using main mode and preshared keys the responder needs to know the identity of the initiator based solely on the IP-address, as it cannot decrypt the Identity payload before it knows the pre shared keys. This "feature" of the protocol is really bad, and we should not copy anything like that to the IKEv2.=20 > Now, we don=E2=80=99t want people to migrate back to an obsolete vers= ion of > the protocol; hence we=E2=80=99ve devised a way to strengthen IKEv2 t= he same > way. Agree. > It was considered important to minimize the changes made to IKEv2. > From a cryptographical prespective, the only change we make is that > we modify the nonces that we present to the KDF. By keeping the > cryptographical changes minimal, we reduce the risk of accidentally > introducing a weakness. I think you are doing this wrong. There is no need to change the SKEYSEED calculation. That only prototects the IKE SA encryption, authentication keys. It would be much better to change the KEYMAT calculation only, and keep the SKEYSEED calculation as it is now. SKEYSEED is used to authenticate the other end and to attack that do require online attacks done during the IKE SA lifetime. Even if the attacker can break the encryption and MAC keys used for the IKE SA that will leak out the actual traffic transmitted over the IPsec SA. It does leak out the identities of the peers, but using active attacks those are visible anyways. To make IPsec quantum computing safe, i.e. so that saved IPsec SA flows cannot be decrypted later when QC computers are available and which can break Diffie-Hellman used now, we just need to add the strong shared secret to the KEYMAT calculations. I.e. in addition to the g^ir (new) and nonces, we can add the PPK there: KEYMAT =3D prf+(SK=5Fd, PPK | Ni | Nr) KEYMAT =3D prf+(SK=5Fd, PPK | g^ir (new) | Ni | Nr) This way even if the attacker stores all the IKE and IPsec flows, and can then later break the DH used to protect the SKEYSEED, they will be able to decrypt the IKE SA, but the actual traffic is still protected as KEYMAT used to generate traffic keys contains PPK. This also gets rid of the complicated PPK=5FREQUEST and PPK=5FACK from = the IKE=5FSA=5FINIT. In this case the initiator just needs to indicate which PPK it will be using (especially with the OOB PPK keys there might be one-time pad of them or they might be generated using some external method like QKD). As the identification of the PPK can be just random octet string which interpretation is left to the implementation. Both end needs to have same PPK anyways, so in addition the PPK they might have ID string for it. The full exchange would be something like this: Initiator Responder ------------------------------------------------------------------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,], =09N(PPK=5FID, x1), N(PPK=5FID, x2), ..., AUTH, SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] =09=09=09=09 =09 N(PPK=5FID, x1), AUTH,=20 =09=09=09=09=09 SAr2, TSi, TSr} SKEYSEED is calculated normally, but the based on the agreed PPK=5FID both ends fetch the real PPK to be used for the KEYMAT calculations. Initiator can send multiple PPK=5FIDs, as there might be cases where initiator and responder might be out of sync when using one time pad keys, and responder replies with one PPK=5FID which is the selected PPK=5FID. As the contents of the PPK=5FID is completely implementation dependent,= it might also contain some other structure, for example the initiator might send largest offset in its one-time pad in PPK=5FID, and responde= r will pick any offset that is larger than that in response. Also as it is not needed until the IPsec SA is created, there is no need to put them in the unencrypted IKE=5FSA=5FINIT, we can put them in the IKE=5FA= UTH payload.=20 The PPK is then fetched from database or whatever, and used in the KEYMAT calculation as specified above. The same PPK=5FID payloads can be used also in the CREATE=5FCHILD=5FSA exchanges in similar ways as we can do another Diffie-Hellman there. I gave about same comments when we were checking this last time, i.e. when we were talking about the draft-nagayama-ipsecme-ipsec-with-qkd-01.txt draft. --=20 kivinen@iki.fi From nobody Tue Feb 23 09:05:34 2016 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 E23881B3647 for ; Tue, 23 Feb 2016 09:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.506 X-Spam-Level: X-Spam-Status: No, score=-0.506 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, J_CHICKENPOX_12=0.6, RP_MATCHES_RCVD=-0.006] 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 An_a4OvQMfEP for ; Tue, 23 Feb 2016 09:05:32 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 610841B3667 for ; Tue, 23 Feb 2016 09:05:28 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3q8mwQ2dhkz39; Tue, 23 Feb 2016 18:05:26 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id bH9rT90nQ5mo; Tue, 23 Feb 2016 18:05:23 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 23 Feb 2016 18:05:23 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 11829600B74F; Tue, 23 Feb 2016 12:05:23 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 11829600B74F Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 0DC131C7D4; Tue, 23 Feb 2016 12:05:23 -0500 (EST) Date: Tue, 23 Feb 2016 12:05:23 -0500 (EST) From: Paul Wouters To: Tero Kivinen In-Reply-To: <22220.36465.788794.855413@fireball.acr.fi> Message-ID: References: <46cc66173e324ae0b788f36cd58f5dfa@XCH-RCD-006.cisco.com> <22220.36465.788794.855413@fireball.acr.fi> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "IPsecme WG \(ipsec@ietf.org\)" , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01 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 Feb 2016 17:05:33 -0000 On Tue, 23 Feb 2016, Tero Kivinen wrote: > The fact that IKEv1 stirred the preshared keys when generating the > keying material for the IKE SA encryption etc keys was the reason that > Main mode of the IKEv1 cannot be used in general case. > > I.e. as in IKEv1 when using main mode and preshared keys the responder > needs to know the identity of the initiator based solely on the > IP-address, as it cannot decrypt the Identity payload before it knows > the pre shared keys. > > This "feature" of the protocol is really bad, and we should not copy > anything like that to the IKEv2. It was solved in for instant the GSSAPI drafts, by sending the ID in the first packet exchange, and mixing it into the SKEYSEED to avoid MITM token/id passing. So it _can_ be done but it does reveal the ID's in the clear unless this is done in an AUTH roundtrip to add protection against passive attackers at the expense of one roundtrip. > I.e. in addition to the g^ir (new) and nonces, we can add the PPK > there: > > KEYMAT = prf+(SK_d, PPK | Ni | Nr) > > KEYMAT = prf+(SK_d, PPK | g^ir (new) | Ni | Nr) So devil's advocate here. Haven't we just reduced all of IKE to a convoluted one time pad scheme? Paul From nobody Tue Feb 23 10:10:32 2016 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 9E12A1B3CFD for ; Tue, 23 Feb 2016 10:10:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.521 X-Spam-Level: X-Spam-Status: No, score=-0.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1xprC6hsbZkZ for ; Tue, 23 Feb 2016 10:10:29 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 5A1881B3CEB for ; Tue, 23 Feb 2016 10:10:29 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u1NIAJ7N011334 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 23 Feb 2016 20:10:19 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u1NIAJFk012464; Tue, 23 Feb 2016 20:10:19 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22220.41099.415272.864148@fireball.acr.fi> Date: Tue, 23 Feb 2016 20:10:19 +0200 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <46cc66173e324ae0b788f36cd58f5dfa@XCH-RCD-006.cisco.com> <22220.36465.788794.855413@fireball.acr.fi> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 10 min Archived-At: Cc: "IPsecme WG \(ipsec@ietf.org\)" , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01 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 Feb 2016 18:10:31 -0000 Paul Wouters writes: > > This "feature" of the protocol is really bad, and we should not copy > > anything like that to the IKEv2. > > It was solved in for instant the GSSAPI drafts, by sending the ID in > the first packet exchange, and mixing it into the SKEYSEED to avoid > MITM token/id passing. So it _can_ be done but it does reveal the > ID's in the clear unless this is done in an AUTH roundtrip to add > protection against passive attackers at the expense of one roundtrip. Main mode of IKEv1 is supposed to protect identity. It is described in the section 4.5 Identity Protection Exchange in the RFC 2408. So anything which leaks out the identities in main mode is not really main mode, but some other exchange. Don't remember what GSSAPI draft did for the exchange type, i.e. did they have separate exchange type, or did they reuse the number 2 Identity Protection... IKEv2 the only exchange we have is something that will protect identities for passive attackers. > > I.e. in addition to the g^ir (new) and nonces, we can add the PPK > > there: > > > > KEYMAT = prf+(SK_d, PPK | Ni | Nr) > > > > KEYMAT = prf+(SK_d, PPK | g^ir (new) | Ni | Nr) > > So devil's advocate here. Haven't we just reduced all of IKE to a > convoluted one time pad scheme? Yes and no. If the method of getting the PPK based on the PPK_ID is an offset to the one time pad, then yes, we are using one time pad to generate keys, but it is not one time pad scheme, as we only use the PPK to generate the keys for the encryption and the encryption is not using one time pad. If the PPK is for example just static 256-bit random shared secret between peers, then there is no one time pad property there at all, but the IPsec SA traffic is still protected against enemies using quantum computer to break the Diffie-Hellman. Unless the enemy also gets the PPK he will not be able to decrypt the IPsec SA traffic. -- kivinen@iki.fi From nobody Tue Feb 23 10:25:24 2016 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 B1A071B3FA1 for ; Tue, 23 Feb 2016 10:25:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.006] 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 navD7wGEOpOH for ; Tue, 23 Feb 2016 10:25:22 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 DFBE11B3F9A for ; Tue, 23 Feb 2016 10:25:21 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3q8phb14VMz2yJ; Tue, 23 Feb 2016 19:25:19 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id qAjICCsE7E2E; Tue, 23 Feb 2016 19:25:18 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Tue, 23 Feb 2016 19:25:18 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 7A6AE600B74F; Tue, 23 Feb 2016 13:25:17 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 7A6AE600B74F Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 75FD81C7D4; Tue, 23 Feb 2016 13:25:17 -0500 (EST) Date: Tue, 23 Feb 2016 13:25:17 -0500 (EST) From: Paul Wouters To: Tero Kivinen In-Reply-To: <22220.41099.415272.864148@fireball.acr.fi> Message-ID: References: <46cc66173e324ae0b788f36cd58f5dfa@XCH-RCD-006.cisco.com> <22220.36465.788794.855413@fireball.acr.fi> <22220.41099.415272.864148@fireball.acr.fi> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: "IPsecme WG \(ipsec@ietf.org\)" , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01 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 Feb 2016 18:25:23 -0000 On Tue, 23 Feb 2016, Tero Kivinen wrote: > So anything which leaks out the identities in main mode is not really > main mode, but some other exchange. Don't remember what GSSAPI draft > did for the exchange type, i.e. did they have separate exchange type, > or did they reuse the number 2 Identity Protection... The gssapi draft used the same private number as the XAUTH draft leading to more alcohol consumption for implementors :) > IKEv2 the only exchange we have is something that will protect > identities for passive attackers. So we can send IDs in a dedicated IKE_AUTH round trip. >> So devil's advocate here. Haven't we just reduced all of IKE to a >> convoluted one time pad scheme? > > Yes and no. > If the PPK is for example just static 256-bit random shared secret > between peers, then there is no one time pad property there at all, > but the IPsec SA traffic is still protected against enemies using > quantum computer to break the Diffie-Hellman. Unless the enemy also > gets the PPK he will not be able to decrypt the IPsec SA traffic. If you have a static 256 bit random shared secret, why not use it as PRF for KEYMAT and skip IKE altogether :P Paul From nobody Tue Feb 23 10:55:14 2016 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 4A4D31A8700 for ; Tue, 23 Feb 2016 10:55:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 tc0--4lRxdVo for ; Tue, 23 Feb 2016 10:55:10 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 881081A8033 for ; Tue, 23 Feb 2016 10:55:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2136; q=dns/txt; s=iport; t=1456253710; x=1457463310; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=ghEmqCBrGJ3fZen4TcaPfVu4YtoEe6lBLyv1fCN1Ztc=; b=NT8Hmd+t2MPmfp1uz87hdcBnv8qy8eX2ROjy7l6tgIIkpDbazQyLqKre +UhTg/CJocvxy0p3WNK74/jMk/PyjsLXzWgyK7SbEUH6R6V2ZJB+JqsUj QzJvIIaN4GuxXlIJHElZG8ebTPP9f23ECckjFsaH/3EZlBW7hWcaayEzR 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AMAgCaqsxW/4kNJK1egzqBPwa6ZQENg?= =?us-ascii?q?WaGDQIcgTA4FAEBAQEBAQFkJ4RBAQEBAwEjEUUMBAIBCBEEAQEDAiMDAgICMBQ?= =?us-ascii?q?BCAgBAQQOBQiIDQiuMI5zAQEBAQEBAQEBAQEBAQEBAQEBAQEBFXuFF4Q6hEuCa?= =?us-ascii?q?oE6AQSXBwGNVo54jkgBHgEBQoIDGYFIaoc4fQEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,490,1449532800"; d="scan'208";a="240170753" Received: from alln-core-4.cisco.com ([173.36.13.137]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 23 Feb 2016 18:55:09 +0000 Received: from XCH-RCD-008.cisco.com (xch-rcd-008.cisco.com [173.37.102.18]) by alln-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u1NIt9NO018890 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 23 Feb 2016 18:55:09 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-008.cisco.com (173.37.102.18) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Tue, 23 Feb 2016 12:55:09 -0600 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Tue, 23 Feb 2016 12:55:09 -0600 From: "Scott Fluhrer (sfluhrer)" To: Tero Kivinen Thread-Topic: [IPsec] draft-fluhrer-qr-ikev2-01 Thread-Index: AdFrYV92xfNPMN/lQHOXoduZDaDkowDK5U6AAAlAryA= Date: Tue, 23 Feb 2016 18:55:09 +0000 Message-ID: References: <46cc66173e324ae0b788f36cd58f5dfa@XCH-RCD-006.cisco.com> <22220.36465.788794.855413@fireball.acr.fi> In-Reply-To: <22220.36465.788794.855413@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.70.230.234] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Cc: "IPsecme WG \(ipsec@ietf.org\)" Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01 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 Feb 2016 18:55:13 -0000 DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFRlcm8gS2l2aW5lbiBbbWFp bHRvOmtpdmluZW5AaWtpLmZpXQ0KPiBTZW50OiBUdWVzZGF5LCBGZWJydWFyeSAyMywgMjAxNiAx MTo1MyBBTQ0KPiBUbzogU2NvdHQgRmx1aHJlciAoc2ZsdWhyZXIpDQo+IENjOiBJUHNlY21lIFdH IChpcHNlY0BpZXRmLm9yZykNCj4gU3ViamVjdDogW0lQc2VjXSBkcmFmdC1mbHVocmVyLXFyLWlr ZXYyLTAxDQo+IA0KPiBTY290dCBGbHVocmVyIChzZmx1aHJlcikgd3JpdGVzOj4gDQo+ID4gSXQg d2FzIGNvbnNpZGVyZWQgaW1wb3J0YW50IHRvIG1pbmltaXplIHRoZSBjaGFuZ2VzIG1hZGUgdG8g SUtFdjIuDQo+ID4gRnJvbSBhIGNyeXB0b2dyYXBoaWNhbCBwcmVzcGVjdGl2ZSwgdGhlIG9ubHkg Y2hhbmdlIHdlIG1ha2UgaXMgdGhhdCB3ZQ0KPiA+IG1vZGlmeSB0aGUgbm9uY2VzIHRoYXQgd2Ug cHJlc2VudCB0byB0aGUgS0RGLiBCeSBrZWVwaW5nIHRoZQ0KPiA+IGNyeXB0b2dyYXBoaWNhbCBj aGFuZ2VzIG1pbmltYWwsIHdlIHJlZHVjZSB0aGUgcmlzayBvZiBhY2NpZGVudGFsbHkNCj4gPiBp bnRyb2R1Y2luZyBhIHdlYWtuZXNzLg0KPiANCj4gSSB0aGluayB5b3UgYXJlIGRvaW5nIHRoaXMg d3JvbmcuIFRoZXJlIGlzIG5vIG5lZWQgdG8gY2hhbmdlIHRoZSBTS0VZU0VFRA0KPiBjYWxjdWxh dGlvbi4gVGhhdCBvbmx5IHByb3RvdGVjdHMgdGhlIElLRSBTQSBlbmNyeXB0aW9uLCBhdXRoZW50 aWNhdGlvbiBrZXlzLg0KPiBJdCB3b3VsZCBiZSBtdWNoIGJldHRlciB0byBjaGFuZ2UgdGhlIEtF WU1BVCBjYWxjdWxhdGlvbiBvbmx5LCBhbmQga2VlcA0KPiB0aGUgU0tFWVNFRUQgY2FsY3VsYXRp b24gYXMgaXQgaXMgbm93Lg0KDQpXaHkgd291bGQgaXQgYmUgbXVjaCBiZXR0ZXI/DQoNCkJ5IGtl ZXBpbmcgU0tfZSwgZXRjIHVucHJvdGVjdGVkLCB5b3UgYXJlIGFsbG93aW5nIGFuIGF0dGFja2Vy IHdpdGggYSBRdWFudHVtIENvbXB1dGVyIHRvIGRlY3J5cHQgdGhlIElLRSBwcm90b2NvbCB0cmFm ZmljLiAgVGhhdCBtZWFucyB0aGF0IGhlIGdldHMgdGhpbmdzIGxpa2UgdGhlIHRyYWZmaWMgc2Vs ZWN0b3JzLg0KDQpUaGF0IGlzIGEgcmVkdWN0aW9uIGluIHRoZSBzZWN1cml0eSBtb2RlbCB0aGF0 IElLRXYyIHByZXNlbnRzOyB5ZXMsIGFuIGFjdGl2ZSBhdHRhY2tlciBjYW4gZ2V0IHRoZSBpZGVu dGl0aWVzLCBidXQgd2UgY2FuJ3QgZ2V0IHRoZSByZXN0IG9mIHRoZSBJS0V2MiB0cmFmZmljLiAg SSB3b3VsZCB3b25kZXIgaWYgdGhlIFdHIHdvdWxkIGFncmVlIHRvIHRoYXQsIGdpdmVuIHRoYXQg dGhlcmUgaXMgYW4gYWx0ZXJuYXRpdmUgdGhhdCBkb2Vzbid0IGRvIHRoYXQuDQoNCj4gDQo+IFRo aXMgYWxzbyBnZXRzIHJpZCBvZiB0aGUgY29tcGxpY2F0ZWQgUFBLX1JFUVVFU1QgYW5kIFBQS19B Q0sgZnJvbSB0aGUNCj4gSUtFX1NBX0lOSVQuDQoNCklzIHRoYXQgdGhlIHNvbGUgcmVhc29uIGl0 IGlzICJtdWNoIGJldHRlciI/ICBUaGUgbm90aWZpY2F0aW9uIGV4Y2hhbmdlIHJlYWxseSBpc24n dCB0aGF0IGhhcmQuLi4NCg0KDQo= From nobody Wed Feb 24 03:44:34 2016 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 D57561A8FD6 for ; Wed, 24 Feb 2016 03:44:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.509 X-Spam-Level: ** X-Spam-Status: No, score=2.509 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_12=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 gEfrVCrjyylJ for ; Wed, 24 Feb 2016 03:44:33 -0800 (PST) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 997DB1A6FE0 for ; Wed, 24 Feb 2016 03:44:32 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id 78so9910497lfy.3 for ; Wed, 24 Feb 2016 03:44:32 -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=ZtQ5wl04QwV0/0DIv/rpHqXnHTtL2bcHrkNJ60GINX8=; b=VQ86nj6R6FJzMvjpFTVS9FbvocyNK64bNzKUKMG/ASk5fhMWp2kp6ZmnQRlcNq73hR BLhXW0nqM9bwMfb/Fmfx1MZcy2bUh+CcnS12ASW1dKsSwkCp0EG5dOFrStViu1L9XPgO 6rlWxSqfsqSmRg28IEGFA2sRJ/mE3EkB9fyQPZOo99AfgbgNL+/b7U4GcfC8DvAZgBrJ +IShvaCx8AvhHBEq8v+OKo2KznxOJfXZdgDYQv53dOrnN9hjx/sqRxUcTtLnT8frOSBx PDNC8hJkMJR9EIIc3JVtwNt5Ki5/Cf9fkU/yVrTkBLxQje3QrDA1nmYxGqHdBpVKs9SS VQTA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-type:content-transfer-encoding; bh=ZtQ5wl04QwV0/0DIv/rpHqXnHTtL2bcHrkNJ60GINX8=; b=LiW1UjYnm00WU/eJx9ZMf4hw32aChMByEgLHWE83Moo3ky1M6q2UwYI0UpDZRkj1j7 RUAmezY7TPl9cAkO/9nDrylYwS8D2ZpppG/+7VITv0bXjFJMgvCoo8BbSXMN27w98CR7 BODWUdsnZZ1Av7GH7ps9l8yHzRXow5Y7auc/ijEiETc0lho+M1RYWQxMz922WsZkT+JC PfSkVyqbjMW9XOcuMCfzUkWgHH5sOmII5alQT+aBCrcMQ8Yzwz/UM9/3i6pUlIgXx5XD /UYxJgxU6bivKVvX9Y6HsVyEBnjAknH0EZgt3dyXomc4ifL8dzoKJU6f0vEgttoO3p/+ Q8Ww== X-Gm-Message-State: AG10YOSgKzvyEutaP7FC1raHKqlmx2wWkk9Ikb4aTyK7YDuG7hx+VlkuzvcO0tXoYcDE3w== X-Received: by 10.25.91.71 with SMTP id p68mr11723513lfb.55.1456314270805; Wed, 24 Feb 2016 03:44:30 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id pm9sm317257lbb.25.2016.02.24.03.44.29 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Feb 2016 03:44:29 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Tero Kivinen" , "Scott Fluhrer \(sfluhrer\)" References: <46cc66173e324ae0b788f36cd58f5dfa@XCH-RCD-006.cisco.com> <22220.36465.788794.855413@fireball.acr.fi> Date: Wed, 24 Feb 2016 14:44:28 +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: Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01 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, 24 Feb 2016 11:44:34 -0000 Hi Tero, > I think you are doing this wrong. There is no need to change the > SKEYSEED calculation. That only prototects the IKE SA encryption, > authentication keys. It would be much better to change the KEYMAT > calculation only, and keep the SKEYSEED calculation as it is now. > > SKEYSEED is used to authenticate the other end and to attack that do > require online attacks done during the IKE SA lifetime. Even if the > attacker can break the encryption and MAC keys used for the IKE SA > that will leak out the actual traffic transmitted over the IPsec SA. > It does leak out the identities of the peers, but using active attacks > those are visible anyways. Only one party's identity is visible, not both. And active attacks are more complex and easier to detect. > To make IPsec quantum computing safe, i.e. so that saved IPsec SA > flows cannot be decrypted later when QC computers are available and > which can break Diffie-Hellman used now, we just need to add the > strong shared secret to the KEYMAT calculations. > > I.e. in addition to the g^ir (new) and nonces, we can add the PPK > there: > > KEYMAT = prf+(SK_d, PPK | Ni | Nr) > > KEYMAT = prf+(SK_d, PPK | g^ir (new) | Ni | Nr) > > This way even if the attacker stores all the IKE and IPsec flows, and > can then later break the DH used to protect the SKEYSEED, they will be > able to decrypt the IKE SA, but the actual traffic is still protected > as KEYMAT used to generate traffic keys contains PPK. I think this proposal is worse than presented in the draft. It leaves information in the IKE SA vulnerable to QC-based attacks. Thus it completely eliminates the IKEv2 property of protecting identities against passive attackers. Moreover, the way PPK is used in the draft is more clear and easier to implement. Note, that the only difference between the crypto formulas from RFC7296 and the draft is that every use of Nx (where x = [ir]) is replaced with PRF(PPK | Nx). It is simple and modular from implementer's point of view. Moreover, in this case the PPK is used as the key for PRF, while in your proposal the PPK is used as additional data fetched into PRF. Using secret material (PPK) as a data is always a pain for the products that maintain "security core", while using secret as a key is simple and natural. > This also gets rid of the complicated PPK_REQUEST and PPK_ACK from the > IKE_SA_INIT. I don't think it's prohibitevly complex. Regards, Valery. From nobody Wed Feb 24 06:27:53 2016 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 4674D1B307A for ; Wed, 24 Feb 2016 06:27:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006, 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 gmIMMPPiBxpK for ; Wed, 24 Feb 2016 06:27:48 -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 B77201B3049 for ; Wed, 24 Feb 2016 06:27:48 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A1C4A2002A for ; Wed, 24 Feb 2016 09:28:53 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id BAAAD63750 for ; Wed, 24 Feb 2016 09:27:47 -0500 (EST) From: Michael Richardson To: "IPsecme WG \(ipsec\@ietf.org\)" In-Reply-To: <22220.36465.788794.855413@fireball.acr.fi> References: <46cc66173e324ae0b788f36cd58f5dfa@XCH-RCD-006.cisco.com> <22220.36465.788794.855413@fireball.acr.fi> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 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 Archived-At: Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01 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, 24 Feb 2016 14:27:50 -0000 --=-=-= Content-Type: text/plain I like Tero's approach. > As the contents of the PPK_ID is completely implementation dependent, it > might also contain some other structure, for example the initiator might > send largest offset in its one-time pad in PPK_ID, and responder will pick > any offset that is larger than that in response. Also as it is not needed > until the IPsec SA is created, there is no need to put them in the > unencrypted IKE_SA_INIT, we can put them in the IKE_AUTH payload. I was thinking that an offset into some *broadcasted* one-time pad would be attractive if it permitted one to avoid pre-distribution of the pad, but as long as the attacker can record that, and eventually break the encryption protecting sending the offset, then it fails. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVs294ICLcPvd0N1lAQKn2AgAuBoPNAG3eRjUf6wwxNlUhDrcL3YbdoVC 00+8F0ORx9h2Eq7oMO11WiILdDaJXR/2emMpjyp1JM/J0hH37hH0vthnOLwAbZml KhTdk29Xf3AN0uXatv79lZR3O+Vp97T/mh7dCaJJyyoKGuMGp7Wq9CukXKLifIwp 3MoGpjw5VzB6xfBKflnG7R9rQBlVPiHk+WNRjt2QaXuKHLbnTbcnrHNuIAVXeHHM u9YRWSwJS5JsrG/K1eednH/Lf1txGwE6dP7APSU6KRvCV8R5UVJuYxEqUZcgwMmk AfGGDz7xOMXFQiBY53Vr5o6DcfubQyhT1XaeZZQ1Xym0UV2QTcutZw== =3125 -----END PGP SIGNATURE----- --=-=-=-- From nobody Wed Feb 24 10:26:49 2016 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 D955C1B2C45 for ; Wed, 24 Feb 2016 10:26:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.778 X-Spam-Level: X-Spam-Status: No, score=0.778 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sCapOOEcZV5M for ; Wed, 24 Feb 2016 10:26:46 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 2100E1B3767 for ; Wed, 24 Feb 2016 10:26:39 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u1OIQT4k018169 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 24 Feb 2016 20:26:29 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u1OIQRja017129; Wed, 24 Feb 2016 20:26:27 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22221.62931.602318.946149@fireball.acr.fi> Date: Wed, 24 Feb 2016 20:26:27 +0200 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <46cc66173e324ae0b788f36cd58f5dfa@XCH-RCD-006.cisco.com> <22220.36465.788794.855413@fireball.acr.fi> <22220.41099.415272.864148@fireball.acr.fi> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 5 min X-Total-Time: 5 min Archived-At: Cc: "IPsecme WG \(ipsec@ietf.org\)" , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01 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, 24 Feb 2016 18:26:48 -0000 Paul Wouters writes: > If you have a static 256 bit random shared secret, why not use it > as PRF for KEYMAT and skip IKE altogether :P That would generate same key for each IPsec SA, which would be really bad especially if you are using any of the modern modes (GCM, CCM, CTR). Static traffic keys are bad. Static authentication keys are ok. Static shared secret used to derive the traffic keys in such way that it will be unique and allows rekeying traffic keys it also ok. You do need at least nonce exchange in IKE to make sure keys are different every time. -- kivinen@iki.fi From nobody Wed Feb 24 10:45:06 2016 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 26BDE1B3CBC for ; Wed, 24 Feb 2016 10:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eIF_PKRyp230 for ; Wed, 24 Feb 2016 10:45:04 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 93B3F1B3CB1 for ; Wed, 24 Feb 2016 10:45:03 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u1OIivsw002087 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 24 Feb 2016 20:44:57 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u1OIivZL016541; Wed, 24 Feb 2016 20:44:57 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22221.64041.548941.11678@fireball.acr.fi> Date: Wed, 24 Feb 2016 20:44:57 +0200 From: Tero Kivinen To: "Scott Fluhrer \(sfluhrer\)" In-Reply-To: References: <46cc66173e324ae0b788f36cd58f5dfa@XCH-RCD-006.cisco.com> <22220.36465.788794.855413@fireball.acr.fi> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 18 min X-Total-Time: 18 min Archived-At: Cc: "IPsecme WG \(ipsec@ietf.org\)" Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01 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, 24 Feb 2016 18:45:05 -0000 Scott Fluhrer (sfluhrer) writes: > > I think you are doing this wrong. There is no need to change the SKEYSEED > > calculation. That only prototects the IKE SA encryption, authentication keys. > > It would be much better to change the KEYMAT calculation only, and keep > > the SKEYSEED calculation as it is now. > > Why would it be much better? Simplier, and less error prone. No issues with fixed ciphers used in negotiation. Keeps the IKE_SA_INIT smaller, which makes it better for DoS attack protection. Makes error handling easier, as you can actually decrypt the IKE_AUTH always and can see that something goes wrong. One of the issues with IKEv1 with wrong pre shared keys was that you decrypted the frame and got some garbage out, and you did not know whether that was attacker, or wheter other end had wrong pre shared key. > By keeping SK_e, etc unprotected, you are allowing an attacker with > a Quantum Computer to decrypt the IKE protocol traffic. That means > that he gets things like the traffic selectors. Yes. On VPN uses this might actually matter, but in most likely it does not matter even in there, as the traffic selectors is from one IP-address assigned temporarely for that user to all other addresses, i.e., they do not actually leak anything. It would be bigger issue if it would actually leak the addresses used in the traffic, but when using tunnel mode those addresses are still protected. For non-VPN cases, i.e., when using transport mode, traffic selectors are visible from the IPsec frames anyways. > That is a reduction in the security model that IKEv2 presents; yes, > an active attacker can get the identities, but we can't get the rest > of the IKEv2 traffic. Active attacker can also get the Traffic selectors the initiator offers, he will also get the certificate used, and the CAs the initiator has configured to. > I would wonder if the WG would agree to that, given that there is an > alternative that doesn't do that. I think it is more useful to get this deployed than to get complicated alternative that nobody implements. Adding the PPK to the KEYMAT when generating IPsec SA keys from the notify payload sent in the IKE_AUTH would be change that is only few lines. In addition to that you need the code to fetch the PPK based on the PPK_ID, and how complicated that is depends on the method you are using. If you are using static PPK_ID and PPK, that is most likely also very small change. > > This also gets rid of the complicated PPK_REQUEST and PPK_ACK from > > the IKE_SA_INIT. > > Is that the sole reason it is "much better"? The notification > exchange really isn't that hard... Yes. Simplicity makes things much better. I have checked your draft few times, but usually noticed that there is some AES+SHA operations, and even using algorithms which are not implemented on the IoT devices. Actually just trying to understand what those AES+SHA operations does, takes more time than I have now available, so I cannot say whether the method works or not. -- kivinen@iki.fi From nobody Wed Feb 24 11:40:43 2016 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 59C0C1B3E1F for ; Wed, 24 Feb 2016 11:40:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.079 X-Spam-Level: X-Spam-Status: No, score=0.079 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, J_CHICKENPOX_32=0.6, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hD1eMze2ilzp for ; Wed, 24 Feb 2016 11:40:38 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 91E081B3E11 for ; Wed, 24 Feb 2016 11:40:37 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u1OJeRJM026801 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Wed, 24 Feb 2016 21:40:27 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u1OJeQUp005921; Wed, 24 Feb 2016 21:40:26 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22222.1834.892900.623823@fireball.acr.fi> Date: Wed, 24 Feb 2016 21:40:26 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: References: <46cc66173e324ae0b788f36cd58f5dfa@XCH-RCD-006.cisco.com> <22220.36465.788794.855413@fireball.acr.fi> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 16 min X-Total-Time: 16 min Archived-At: Cc: ipsec@ietf.org, "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01 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, 24 Feb 2016 19:40:40 -0000 Valery Smyslov writes: > > SKEYSEED is used to authenticate the other end and to attack that do > > require online attacks done during the IKE SA lifetime. Even if the > > attacker can break the encryption and MAC keys used for the IKE SA > > that will leak out the actual traffic transmitted over the IPsec SA. > > It does leak out the identities of the peers, but using active attacks > > those are visible anyways. > > Only one party's identity is visible, not both. > And active attacks are more complex and easier to detect. The responder identity is usually quite static, as responders IP-address is usually static... If there are multiple responder IDs in the same IP-address, then initiator usually needs to tell which one of them he wants to connect using both IDi, and IDr in his IKE_AUTH request, and in that case the active attacker do get both identities. > > To make IPsec quantum computing safe, i.e. so that saved IPsec SA > > flows cannot be decrypted later when QC computers are available and > > which can break Diffie-Hellman used now, we just need to add the > > strong shared secret to the KEYMAT calculations. > > > > I.e. in addition to the g^ir (new) and nonces, we can add the PPK > > there: > > > > KEYMAT = prf+(SK_d, PPK | Ni | Nr) > > > > KEYMAT = prf+(SK_d, PPK | g^ir (new) | Ni | Nr) > > > > This way even if the attacker stores all the IKE and IPsec flows, and > > can then later break the DH used to protect the SKEYSEED, they will be > > able to decrypt the IKE SA, but the actual traffic is still protected > > as KEYMAT used to generate traffic keys contains PPK. > > I think this proposal is worse than presented in the draft. > It leaves information in the IKE SA vulnerable to QC-based attacks. And what information do you think is there that is really worth of protecting? My understanding is that when there really are attackers using QC-based attacks in real, we need to change the IKEv2 again, to make the authentication methods also protected against QC-based attacks. What we are solving now is the fact that someone can save all the IKEv2 / IPsec traffic now, and when they do get the quantum computers, they can break the Diffie-Hellman and then get the traffic keys used to protect the IPsec traffic. I.e. the saving of traffic happens now and breaking of the traffic happens much later. What information there are in the IKEv2 SA which is important to protect for that kind of attacks? > Thus it completely eliminates the IKEv2 property of protecting > identities against passive attackers. Yes. I think protecting the actual IPsec traffic is much more important than protecting the identities, especially as they are already vulnerable to the active attackers. Detecting active attackers is easier, but I still assume that quite a lot of implementations do retry silently if they do not get reply back to the IKE_AUTH, i.e., there is no big alerts at that time warning user that there might be active attacker on link, who just stole your ID. > Moreover, the way PPK is used in the draft is more clear and > easier to implement. Note, that the only difference between the crypto > formulas from RFC7296 and the draft is that every use of Nx (where x = [ir]) > is replaced with PRF(PPK | Nx). It is simple and modular from > implementer's point of view. The draft had all kind of talks about AES and SHA256, so I just assume that was there to confuse people and it is not needed? > Moreover, in this case the PPK is used as the key for PRF, while in > your proposal the PPK is used as additional data fetched into PRF. The reason I used that is that cryptographers who designed the IKEv2 did that same thing with the share secret output from the Diffie-Hellman, i.e., the g^ir. So I do assume that is safe, and if it not then we need some proper cryptographer to tell me why not. Also using the PPK as key to the PRF will limit the size of the PPK to match you PRF key length. Using it as a data is supposed to be better if I remember right why this method was selected for the IKEv2. Anyways I am not cryptographer, I just assume that the people who are and who said it is ok to do KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr) know what they were doing. > Using secret material (PPK) as a data is always a pain for the > products that maintain "security core", while using secret as a key > is simple and natural. But this what we do in IKEv2 for all cases, also the SKEYSEED is calculated in same way: SKEYSEED = prf(Ni | Nr, g^ir) I.e. the public values Ni and Nr are used as key, and the shared secret g^ir is used as data. If you think that is unsafe, I would like to get more information about that, as that would mean that we need to change the cryptographic protocol used in the IKEv2... -- kivinen@iki.fi From nobody Wed Feb 24 23:38:20 2016 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 D1E131A03A6 for ; Wed, 24 Feb 2016 23:38:18 -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_12=0.6, J_CHICKENPOX_32=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 esxOZCJqLfv2 for ; Wed, 24 Feb 2016 23:38:17 -0800 (PST) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DCD351A03AA for ; Wed, 24 Feb 2016 23:38:16 -0800 (PST) Received: by mail-lf0-x232.google.com with SMTP id m1so27684529lfg.0 for ; Wed, 24 Feb 2016 23:38: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=IccK+MyvsvBTTfgZVkb81oMkuaVtzFqgldjQrTND+kQ=; b=vOJYpbq9QO8j5iysP6Gm09XBLjwfffOHcBSeIZCyNiRssgh7+9Gy6O4EIgwimIszPX +/FYqdKFg5OiiKa5/NGItKUoOtGvDYEKcAYogT4GpLevyOCwu9DOLtPq7o8Ypyk3NHUU Dj8kTuY7Z4ji90cH5uuGImFzSuYkebqojGaaY+CucUwhs3vzQ3epQUeKLl2Z3Okb4AgI LsuNZVtNTduNL9Niru1UFLCXvOXxCEqo5KvDoY3znQitA79dedqHwpUQDFNzQCUlTRHW SbWhc791UrY5VUvdISzUdcz6RTRmBA+vlxKfLXn6x11t+v3FpUG1m7hblhxThtNA+fe7 26OA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-type:content-transfer-encoding; bh=IccK+MyvsvBTTfgZVkb81oMkuaVtzFqgldjQrTND+kQ=; b=msd3TS7xTH2LdTA+U9qQIw29+DIsjAYbsxStarZLa8YrgZBPPPtEZtX4DPobcxJpIb 4AIA3ENedY6w+AxXvDCU9nin+aZzJf9WP6ae4Kp7a0UwMsH7YRTSGTF1X5z44OagBOdr E4qN+lMBEp9OFNoon70xVlYBDEFyvrAG0Ab17NF9uO7wwoHNfskwvsCln0HL4FL34W+K PO+V4rOrKpVrQ4nM9L7iYArvDSQLdYPtb9oUHQ+an4oLKnT4v+nN4VKcmpKvkcp8Jivv ZXJtMb46I0Of9ZIWe4c7AP6CGhgLZANfj7oX+DVqRghVqQWIPDBsqIpA+YwVprXvPJz8 mBIw== X-Gm-Message-State: AG10YORri9/47/LoVnY9EvR+hQZsa6BsUrEnh39uEXAOShHQknHo1df+rJLBsS5Qi6hc1w== X-Received: by 10.25.144.12 with SMTP id s12mr16608138lfd.114.1456385894972; Wed, 24 Feb 2016 23:38:14 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id dt9sm943916lbc.47.2016.02.24.23.38.13 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 24 Feb 2016 23:38:13 -0800 (PST) Message-ID: <3C4D164CF08843258CE30B5B21363397@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" References: <46cc66173e324ae0b788f36cd58f5dfa@XCH-RCD-006.cisco.com><22220.36465.788794.855413@fireball.acr.fi> <22222.1834.892900.623823@fireball.acr.fi> Date: Thu, 25 Feb 2016 10:38:13 +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: Cc: ipsec@ietf.org, "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01 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, 25 Feb 2016 07:38:19 -0000 Hi Tero, >> I think this proposal is worse than presented in the draft. >> It leaves information in the IKE SA vulnerable to QC-based attacks. > > And what information do you think is there that is really worth of > protecting? If we are talking about the original IKEv2 as specified in the RFC 7296, then there are not much sensitive data inside the IKE SA - mostly identities, traffic selectors and configuration attributes (althouth I think all these items must still receive due protection). However, I've been always thinking that IKE SA can be used as a transport for low volume data (for example using Transaction exchange). I'm sure there are propriatory extensions out there and I wonder why nobody try to standardize it yet. There is also a draft describing IKEv2 based protocol for group key management (draft-yeung-g-ikev2) and it does tramsmit sensitive information (including session keys) inside IKE SA. It is a pity if QC protection mechanism won't work for these IKEv2 variants (as in your proposal). > My understanding is that when there really are attackers using > QC-based attacks in real, we need to change the IKEv2 again, to make > the authentication methods also protected against QC-based attacks. Note, that the proposed solution also protects authentication (since SK_px are used in calculation of the AUTH payload content). > What we are solving now is the fact that someone can save all the > IKEv2 / IPsec traffic now, and when they do get the quantum computers, > they can break the Diffie-Hellman and then get the traffic keys used > to protect the IPsec traffic. > > I.e. the saving of traffic happens now and breaking of the traffic > happens much later. > > What information there are in the IKEv2 SA which is important to > protect for that kind of attacks? See above. For some derivation of IKEv2 (like G-IKEv2) there are a lot of sensitive information to protect. >> Moreover, the way PPK is used in the draft is more clear and >> easier to implement. Note, that the only difference between the crypto >> formulas from RFC7296 and the draft is that every use of Nx (where x = [ir]) >> is replaced with PRF(PPK | Nx). It is simple and modular from >> implementer's point of view. > > The draft had all kind of talks about AES and SHA256, so I just assume > that was there to confuse people and it is not needed? Please, re-read the draft. In the last version it is not tied with any particular algorithms (AES, SHA256) and uses the negotiated PRF for SKEYSEED calculation. >> Moreover, in this case the PPK is used as the key for PRF, while in >> your proposal the PPK is used as additional data fetched into PRF. > > The reason I used that is that cryptographers who designed the IKEv2 > did that same thing with the share secret output from the > Diffie-Hellman, i.e., the g^ir. So I do assume that is safe, and if it > not then we need some proper cryptographer to tell me why not. > > Also using the PPK as key to the PRF will limit the size of the PPK to > match you PRF key length. Using it as a data is supposed to be better > if I remember right why this method was selected for the IKEv2. Most PRFs accept key of arbitrary length. And if some PRF is defined with a fixed length key, that there will be a problem with this PRF in IKEv2 anyway - with calculation of SKEYSEED, where key is a concatenation of the nonces. That's why an ugly hack for AES-XCBC-PRF-128 and AES-CMAC-PRF-128 is included in the protocol. > Anyways I am not cryptographer, I just assume that the people who are > and who said it is ok to do > > KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr) > > know what they were doing. I'm not a cryptographer either, but I think that from cryptography point of view your construction is sound. The problem resides in implementation, not in mathematics. See below. >> Using secret material (PPK) as a data is always a pain for the >> products that maintain "security core", while using secret as a key >> is simple and natural. > > But this what we do in IKEv2 for all cases, also the SKEYSEED is > calculated in same way: > > SKEYSEED = prf(Ni | Nr, g^ir) > > I.e. the public values Ni and Nr are used as key, and the shared > secret g^ir is used as data. > > If you think that is unsafe, I would like to get more information > about that, as that would mean that we need to change the > cryptographic protocol used in the IKEv2... I never meant that it is unsafe. I meant that sometimes it causes a headache for implementers when long-term secret is used as a data in cryptographic formulas. Consider the situation when you have a dedicated hardware (HSM, token) where long-term secrets reside. Very often this hardware has an API that never allows the secrets to be exposed and allows them to be used only as keys in cryptographic primitives (i.e. you can encrypt some data using these key). If you need to use these keys as data in cryptographic primitives then you must either contact the hardware manufacturer and ask him for a new API function specific for your needs or to find some workarounds, that are often based on undocumented features. Note that g^xy is a different beast - it is not a long-term secret, and usually APIs allow using session keys as a data in key derivation functions. Regards, Valery. From nobody Thu Feb 25 04:43:33 2016 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 64A0D1A8F4B for ; Thu, 25 Feb 2016 04:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.521 X-Spam-Level: X-Spam-Status: No, score=-0.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UBW8TC_hJx2A for ; Thu, 25 Feb 2016 04:43:29 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 608861A8BC2 for ; Thu, 25 Feb 2016 04:43:29 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u1PChINC019766 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 25 Feb 2016 14:43:18 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u1PChH63004963; Thu, 25 Feb 2016 14:43:17 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22222.63205.854356.14024@fireball.acr.fi> Date: Thu, 25 Feb 2016 14:43:17 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <3C4D164CF08843258CE30B5B21363397@buildpc> References: <46cc66173e324ae0b788f36cd58f5dfa@XCH-RCD-006.cisco.com> <22220.36465.788794.855413@fireball.acr.fi> <22222.1834.892900.623823@fireball.acr.fi> <3C4D164CF08843258CE30B5B21363397@buildpc> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 38 min X-Total-Time: 40 min Archived-At: Cc: ipsec@ietf.org, "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01 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, 25 Feb 2016 12:43:32 -0000 Valery Smyslov writes: > > And what information do you think is there that is really worth of > > protecting? > > If we are talking about the original IKEv2 as specified in the RFC > 7296, then there are not much sensitive data inside the IKE SA - > mostly identities, traffic selectors and configuration attributes And most of that information is derived from the configuration, which is usually static for the host. I.e. initiator most likely always offers same ID, traffic selectors and config attribute requests to responder. I.e. most of this data do not need protection. > (althouth I think all these items must still receive due > protection). They still will, but they will not receive full protection against the QC based attacks. Even when attackers have quantum computers, the attacks against the Diffie-Hellman most likely still will require time, so are they willing to use the machine to break Diffie-Hellmans of the QC resistant IKEv2 SAs just to get that information, when they still cannot get the actual traffic? > However, I've been always thinking that IKE SA can be used as a > transport for low volume data (for example using Transaction > exchange). I'm sure there are propriatory extensions out there and I > wonder why nobody try to standardize it yet. I think that is bad idea. IKEv2 is key exchange protocol. It is not meant to be data transfer protocol. The message flow system is not really suitable for the data transfers, for example the common window size is 1, so you can have only one request outstanding, i.e. each transfer takes full round trip before you can continue. Each request requires ACK, and you can not combine multiple ACKs to different requests to one reply. If you do make window size larger, the only way to lower it again is to rekey IKE SA. There is no congestion control for the IKE messages etc. So do not use IKEv2 SA to transfer data. Use it only to things which it is meant to, i.e., key exchange and key management. If you want to transfer data, create IPsec SA, and run TCP (or UDP) over it. > There is also a draft describing IKEv2 based protocol for group key > management (draft-yeung-g-ikev2) and it does tramsmit sensitive > information (including session keys) inside IKE SA. That is not IKEv2, it is separate protocol using same framing than IKEv2. It does not run on the same port than IKEv2 (500 vs 848). Things we define for IKEv2 do not automatically transfer to that anyways, thus if they want to use whatever method we define there, they do require to specify how it affects their protocol. For example they do not use IKE_AUTH exchange at all, they use GSA_AUTH exchange, which have different payloads than IKE_AUTH has. Also if they want to make that protocol QC resistant, they just need to define new key download type. This can be done in multiple different ways (either use PPK to encrypt the key transmitted, or use PPK and the key transmitted to derive actual traffic keys etc). > It is a pity if QC protection mechanism won't work for these IKEv2 > variants (as in your proposal). It wont. They are separate protocols, and they need to specify how they are going to make their protocol QC resistant. > > My understanding is that when there really are attackers using > > QC-based attacks in real, we need to change the IKEv2 again, to make > > the authentication methods also protected against QC-based attacks. > > Note, that the proposed solution also protects authentication > (since SK_px are used in calculation of the AUTH payload content). True, but when our whole certificate hierarchy is broken because signatures are broken we should still replace the authentication methods with something that is fully resistant to the QC. > See above. For some derivation of IKEv2 (like G-IKEv2) > there are a lot of sensitive information to protect. Which has nothing to do with this discussion, as G-IKEv2 is not IKEv2, nor it is work that is done in the IPsecME Wg at all. There used to be separate working group (Msec) working on those protocols, and their protocols were based on the IKE, but not really IKE. If they want to use things we define here they need to incorporate them to their protocols separately. > > The draft had all kind of talks about AES and SHA256, so I just assume > > that was there to confuse people and it is not needed? > > Please, re-read the draft. In the last version it is not tied with any > particular algorithms (AES, SHA256) and uses the negotiated > PRF for SKEYSEED calculation. >From the draft: ... The PPK Indicator Algorithm is a 4 byte word that states which PPK indicator to use. That is, it gives the encoding format for the PPK that should be used is given to the responder. At present, the only assigned encoding is 0x00000001, which indicates that AES256_SHA256 will be used (as explained below). ... And unfortunately I do not really have time to read the draft now as the mechanism looks too complicated to me with little gain, and will most likely not go forward, thus there is no point of me to waste my time on it now. > Most PRFs accept key of arbitrary length. And if some PRF > is defined with a fixed length key, that there will be a problem > with this PRF in IKEv2 anyway - with calculation of SKEYSEED, > where key is a concatenation of the nonces. That's why > an ugly hack for AES-XCBC-PRF-128 and AES-CMAC-PRF-128 > is included in the protocol. Most PRFs accept arbitrary length key, but they will convert it to suitable for the algorithm by hashing it first. For example AES-XCBC-PRF-128 will take the key and calculate the AES-XCBC-PRF-128 with zero key and will get 128 bit key out from that which is then used as the key to PRF. If the key contained 256 bits of entropy after that it will only contain 128-bits of entropy and if the rest of the inputs to the PRF is just (public) nonces, then the final keying material will have 128 bits of entropy. I think this was the reason why the KEYMAT and SKEYSEED in IKEv2 is calculated as how they are in the IKEv2. > > Anyways I am not cryptographer, I just assume that the people who are > > and who said it is ok to do > > > > KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr) > > > > know what they were doing. > > I'm not a cryptographer either, but I think that from cryptography > point of view your construction is sound. The problem resides > in implementation, not in mathematics. See below. That is not my construction, that is construction we currently have in the IKEv2. > > If you think that is unsafe, I would like to get more information > > about that, as that would mean that we need to change the > > cryptographic protocol used in the IKEv2... > > I never meant that it is unsafe. I meant that sometimes it causes > a headache for implementers when long-term secret is used > as a data in cryptographic formulas. Consider the situation when > you have a dedicated hardware (HSM, token) where long-term > secrets reside. Very often this hardware has an API that > never allows the secrets to be exposed and allows them to be used > only as keys in cryptographic primitives (i.e. you can encrypt > some data using these key). If you need to use these keys > as data in cryptographic primitives then you must either contact > the hardware manufacturer and ask him for a new API function > specific for your needs or to find some workarounds, that > are often based on undocumented features. That is actual real reason to do things differently. I.e. perhaps the KEYMAT generation then should be KEYMAT = prf+(SK_d, g^ir (new) | prf(PPK, Ni) | prf(PPK, Nr)) instead? Or something similar where we use PPK as key to PRF. -- kivinen@iki.fi From nobody Thu Feb 25 06:10:18 2016 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 1B60D1ACDCC for ; Thu, 25 Feb 2016 06:10:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rAAq6EVFXyas for ; Thu, 25 Feb 2016 06:10:15 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 8E27E1ACDAE for ; Thu, 25 Feb 2016 06:10:14 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u1PE9uDl023530 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 25 Feb 2016 16:09:56 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u1PE9tgl028823; Thu, 25 Feb 2016 16:09:55 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22223.2866.976241.499754@fireball.acr.fi> Date: Thu, 25 Feb 2016 16:09:54 +0200 From: Tero Kivinen To: ipsec@ietf.org, frederic.firmin@etsi.org X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 15 min X-Total-Time: 15 min Archived-At: Subject: [IPsec] IANA allocation of TIMEOUT_PERIOD_FOR_LIVENESS_CHECK 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, 25 Feb 2016 14:10:17 -0000 I as an IANA expert got request from 3gpp to allocate new configuration attribute called TIMEOUT_PERIOD_FOR_LIVENESS_CHECK for IKEv2. This is used to set the timeout after which the UE will do liveness check with other end if no cryptographically protected IKEv2 or IPSec messages are not received. I.e. it is mostly same procedure as RFC7296 but in this case the the parameter is not locally configured, but sent by the server end. I can see some merit for this as this allows the server to limit the number of liveness checks by sending larger number, for example 600 seconds. Some implementations use really short liveness check timeouts and send the liveness checks ever n seconds when connection is silent. Some implementaions simply do one liveness check after the connection goes silent, but after that assumes that connection is ok as long as there is no packets going out, and only redo the liveness check after they have sent something out and not received anything back. This is more in align with first use, i.e. the text asks to send liveness check this often even if the connection is completely silent. The IKEv2 text says we do liveness checks to avoid black holes, and there cannot be black holes for packets if we do not send packets, thus we are not supposed to send liveness checks if both ends are silent. I am thinking of saying "go ahead" for IANA for this allocation even when this do change the IKEv2 bit, as I think there are implementations using same interpretation out there, and I think this configuration attribute is mostly harmless. If we would have done it here in the IPsecME WG, I think we would have used notifications instead of configuration payloads, as this attribute do affect the whole IKE SA and is not configuration attribute related to IPsec SA. So unless people object I will say "go ahead" in few days. Ps, I still think it would be better for 3gpp to run their additions to IKEv2 through the IPsecME WG first to get some feedback for them before adding them to their drafts (i.e. send email to the list and ask for comments, no need to write internet drafts about proposals, but just explain why and what they plan to do). I at least would be more than happy to provide them feedback earlier, as I think this IANA allocation phase is too late phase to do such things. Original allocation request: === Contact Name: Frederic Firmin Contact Email: frederic.firmin@etsi.org Type of Assignment: New item in the "IKEv2 Configuration Payload Attribute Types" of the "Internet Key Exchange Version 2 (IKEv2) Parameters" as shown at http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-21 and as specified in IETF RFC 4306 and updated by IETF RFC 5996 and IETF RFC 7296. Registry: The "IKEv2 Configuration Payload Attribute Types" of the "Internet Key Exchange Version 2 (IKEv2) Parameters" as shown at http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-21 and as specified in IETF RFC 4306 and updated by IETF RFC 5996 and IETF RFC 7296. Description: This IKEv2 attribute is used to provide configuration for performing the liveness checks. Additional Info: ETF RFC 4306 defines the registry for the "IKEv2 Configuration Payload Attribute Types". IETF RFC 7296 and IETF RFC 5996 refer to IETF RFC 4306 for the definition of the registry. The following attribute is requested to be registered: - value: (number to be assigned by IANA) - attribute type: TIMEOUT_PERIOD_FOR_LIVENESS_CHECK - multi-valued: no - length: 4 octets - reference: 24.302 13.4.0 http://www.3gpp.org/ftp/Specs/html-info/24302.htm -- kivinen@iki.fi From nobody Thu Feb 25 06:25:41 2016 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 830541ACE67 for ; Thu, 25 Feb 2016 06:25:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.006] 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 anMQYTdxC4h1 for ; Thu, 25 Feb 2016 06:25:38 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 5AB4C1ACE68 for ; Thu, 25 Feb 2016 06:25:38 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3q9xH42tPxz1J5; Thu, 25 Feb 2016 15:25:36 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id z_e9Wqn54KOA; Thu, 25 Feb 2016 15:25:34 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 25 Feb 2016 15:25:34 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 3524A606625C; Thu, 25 Feb 2016 09:25:32 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca 3524A606625C Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 31558F6B2A; Thu, 25 Feb 2016 09:25:32 -0500 (EST) Date: Thu, 25 Feb 2016 09:25:32 -0500 (EST) From: Paul Wouters To: Tero Kivinen In-Reply-To: <22223.2866.976241.499754@fireball.acr.fi> Message-ID: References: <22223.2866.976241.499754@fireball.acr.fi> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: ipsec@ietf.org, frederic.firmin@etsi.org Subject: Re: [IPsec] IANA allocation of TIMEOUT_PERIOD_FOR_LIVENESS_CHECK 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, 25 Feb 2016 14:25:40 -0000 On Thu, 25 Feb 2016, Tero Kivinen wrote: > I as an IANA expert got request from 3gpp to allocate new > configuration attribute called TIMEOUT_PERIOD_FOR_LIVENESS_CHECK for > IKEv2. This is used to set the timeout after which the UE will do > liveness check with other end if no cryptographically protected IKEv2 > or IPSec messages are not received. > > I.e. it is mostly same procedure as RFC7296 but in this case the the > parameter is not locally configured, but sent by the server end. I am confused. Is this a notify of the server to the client, or a configuration item by the server instructing client behaviour? > I can see some merit for this as this allows the server to limit the > number of liveness checks by sending larger number, for example 600 > seconds. So this seems like it is a configuration dictated by the server for the client to use. What if the client disagrees? Does it ignore this and use its own local policy? > Some implementations use really short liveness check timeouts > and send the liveness checks ever n seconds when connection is silent. So with this option, is the server now allowed to not answer a liveness probe and should the client not close the connection if it receives no answer? > This is more in align with first use, i.e. the text asks to send > liveness check this often even if the connection is completely silent. That's something that could go into an 7296 update as it is a useful policy change in general (and likely already implemented by some. We do this already as well) > The IKEv2 text says we do liveness checks to avoid black holes, and > there cannot be black holes for packets if we do not send packets, > thus we are not supposed to send liveness checks if both ends are > silent. Sure, that text could use an update. > I am thinking of saying "go ahead" for IANA for this allocation even > when this do change the IKEv2 bit, as I think there are > implementations using same interpretation out there, and I think this > configuration attribute is mostly harmless. The text below cities still does not make it clear to me if this is a notification or an instruction. > If we would have done it > here in the IPsecME WG, I think we would have used notifications > instead of configuration payloads, as this attribute do affect the > whole IKE SA and is not configuration attribute related to IPsec SA. But a notify is something that is informative, not instructive. So now I am all confused again. > So unless people object I will say "go ahead" in few days. I would _really_ prefer a 2 page draft that states the problem and the solution, so that it becomes clear if these are local policy suggestions or actual configuration requirements the client has to accept or reject. > Ps, I still think it would be better for 3gpp to run their additions > to IKEv2 through the IPsecME WG first to get some feedback for them > before adding them to their drafts (i.e. send email to the list and > ask for comments, no need to write internet drafts about proposals, > but just explain why and what they plan to do). I at least would be > more than happy to provide them feedback earlier, as I think this IANA > allocation phase is too late phase to do such things. Yes. The IKEv2 registries are filling up with non-ikev2 entries. It would really make sense to run this through the working group. I'll bring this issue up in the TEG/TLC next week. Paul > Original allocation request: > > === > > Contact Name: > Frederic Firmin > > Contact Email: > frederic.firmin@etsi.org > > Type of Assignment: New item in the "IKEv2 Configuration Payload > Attribute Types" of the "Internet Key Exchange Version 2 (IKEv2) > Parameters" as shown at > http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-21 > and as specified in IETF RFC 4306 and updated by IETF RFC 5996 and > IETF RFC 7296. > > Registry: The "IKEv2 Configuration Payload Attribute Types" of the > "Internet Key Exchange Version 2 (IKEv2) Parameters" as shown at > http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-21 > and as specified in IETF RFC 4306 and updated by IETF RFC 5996 and > IETF RFC 7296. > > Description: > This IKEv2 attribute is used to provide configuration for performing the liveness checks. > > Additional Info: ETF RFC 4306 defines the registry for the "IKEv2 > Configuration Payload Attribute Types". IETF RFC 7296 and IETF RFC > 5996 refer to IETF RFC 4306 for the definition of the registry. The > following attribute is requested to be registered: - value: (number to > be assigned by IANA) - attribute type: > TIMEOUT_PERIOD_FOR_LIVENESS_CHECK - multi-valued: no - length: 4 > octets - reference: 24.302 13.4.0 > http://www.3gpp.org/ftp/Specs/html-info/24302.htm > -- > kivinen@iki.fi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From nobody Thu Feb 25 06:51:28 2016 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 82EB11AD068 for ; Thu, 25 Feb 2016 06:51:26 -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 MWotsORf-fvS for ; Thu, 25 Feb 2016 06:51:25 -0800 (PST) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 25E2D1A877A for ; Thu, 25 Feb 2016 06:51:25 -0800 (PST) Received: by mail-lf0-x232.google.com with SMTP id 78so34512645lfy.3 for ; Thu, 25 Feb 2016 06:51:25 -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=3IrbH3bN4iZs5YtFnZtI/cXgM+7x8M4xFlgoeUHXYw0=; b=AxA56njUwWUME1xiZXPAy9tr1oSXBjpBNi+D7lVeRLgwC0Gu2M/C7pvfK5NdK+UIfO hzp7TFRHYf8StBgZ8kYwFTE1vksoOlRvUPMGKDkQwJNpQLmql7tDsv2FKHeMt3i7bsdh 9VqEo/3WiWis5UrNL4mOW4GmsmklWvqFOoVkvmIWO3huAwd+4EXLqUszrsPcJRR1tn9x WHLG2xEi7ajviYBEsp9TTTPwjjwpquwW6OpCKI6DWF+pAaeOYXOmCVKS78XdPoNZ3IgB 6AOSjMhQ0hczamGWhc8zQosVDwPHhiWDuso8nt2w3N548J9x+Jx0g3dBlh+wObE3Nw2I BV9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:references:subject:date :mime-version:content-type:content-transfer-encoding; bh=3IrbH3bN4iZs5YtFnZtI/cXgM+7x8M4xFlgoeUHXYw0=; b=K9Glm+b4xiHsXHDWAbKCsp8FhUWhPjhaldvBhkJX9D1WQtB9pI2QASsAE5Q2geDkuL mY8PQhluzvvO8TkWPkiayktkxeUjgRNb6M29jybuj5XW2FDG6FTALG02dDh1Iu2MjsP/ kULziqfPxqBNLm7DnpEKz0Pf9xjuSsodqWobQKmwSqDvsqCC/s265a55pzZOwMgULCNj o3gz3zlLFHN4fo99QzEThs2THaUd6vCWFr5Xs2O1KERijOTa35Vfcm0WIxEJPzBKMAG3 ixj3YTm+9X8zndwVjXlxbGSPuKcLM97nprQTL9fIBynoBMBfxZj5cflL0fDeu0C4gfL/ lqJA== X-Gm-Message-State: AG10YOQuQvXV4D8HwJR87eKg6wOLq2gxyxpZBt9DUrtvXN/fnGIyFnlJ9MYIrYSuV5PjZQ== X-Received: by 10.25.206.132 with SMTP id e126mr3071398lfg.20.1456411883418; Thu, 25 Feb 2016 06:51:23 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id p124sm1196605lfe.31.2016.02.25.06.51.22 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Feb 2016 06:51:22 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Tero Kivinen" , , References: <22223.2866.976241.499754@fireball.acr.fi> Date: Thu, 25 Feb 2016 17:51:25 +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: Subject: Re: [IPsec] IANA allocation of TIMEOUT_PERIOD_FOR_LIVENESS_CHECK 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, 25 Feb 2016 14:51:26 -0000 Hi, >I as an IANA expert got request from 3gpp to allocate new > configuration attribute called TIMEOUT_PERIOD_FOR_LIVENESS_CHECK for > IKEv2. This is used to set the timeout after which the UE will do > liveness check with other end if no cryptographically protected IKEv2 > or IPSec messages are not received. > > I.e. it is mostly same procedure as RFC7296 but in this case the the > parameter is not locally configured, but sent by the server end. > > I can see some merit for this as this allows the server to limit the > number of liveness checks by sending larger number, for example 600 > seconds. Some implementations use really short liveness check timeouts > and send the liveness checks ever n seconds when connection is silent. > Some implementaions simply do one liveness check after the connection > goes silent, but after that assumes that connection is ok as long as > there is no packets going out, and only redo the liveness check after > they have sent something out and not received anything back. > > This is more in align with first use, i.e. the text asks to send > liveness check this often even if the connection is completely silent. > The IKEv2 text says we do liveness checks to avoid black holes, and > there cannot be black holes for packets if we do not send packets, > thus we are not supposed to send liveness checks if both ends are > silent. > > I am thinking of saying "go ahead" for IANA for this allocation even > when this do change the IKEv2 bit, as I think there are > implementations using same interpretation out there, and I think this > configuration attribute is mostly harmless. If we would have done it > here in the IPsecME WG, I think we would have used notifications > instead of configuration payloads, as this attribute do affect the > whole IKE SA and is not configuration attribute related to IPsec SA. > > So unless people object I will say "go ahead" in few days. I don't strongly object, however I have a concern: how server can enforce the timeout period it sent to the client? The client can ignore it and do liveness check more often (for a good reason, if it has some data to send and has no reply from server) or less often. It seems that this notification could be ignored by the client completely and the server cannot do anything about this (otherwise than tear down the connection with "bad boy", but is it an intention?). Or is this notification just a hint, not an enforcement? > Ps, I still think it would be better for 3gpp to run their additions > to IKEv2 through the IPsecME WG first to get some feedback for them > before adding them to their drafts (i.e. send email to the list and > ask for comments, no need to write internet drafts about proposals, > but just explain why and what they plan to do). I at least would be > more than happy to provide them feedback earlier, as I think this IANA > allocation phase is too late phase to do such things. Yes. Regards, Valery. From nobody Thu Feb 25 06:52:45 2016 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 1CE8F1AD21C for ; Thu, 25 Feb 2016 06:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xvZe_FqQN-El for ; Thu, 25 Feb 2016 06:52:42 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 C0B341AD26B for ; Thu, 25 Feb 2016 06:52:41 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u1PEqRea010829 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 25 Feb 2016 16:52:27 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u1PEqRmA010228; Thu, 25 Feb 2016 16:52:27 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22223.5419.528391.85358@fireball.acr.fi> Date: Thu, 25 Feb 2016 16:52:27 +0200 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <22223.2866.976241.499754@fireball.acr.fi> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 15 min X-Total-Time: 15 min Archived-At: Cc: ipsec@ietf.org, frederic.firmin@etsi.org Subject: Re: [IPsec] IANA allocation of TIMEOUT_PERIOD_FOR_LIVENESS_CHECK 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, 25 Feb 2016 14:52:44 -0000 Paul Wouters writes: > On Thu, 25 Feb 2016, Tero Kivinen wrote: > > > I as an IANA expert got request from 3gpp to allocate new > > configuration attribute called TIMEOUT_PERIOD_FOR_LIVENESS_CHECK for > > IKEv2. This is used to set the timeout after which the UE will do > > liveness check with other end if no cryptographically protected IKEv2 > > or IPSec messages are not received. > > > > I.e. it is mostly same procedure as RFC7296 but in this case the the > > parameter is not locally configured, but sent by the server end. > > I am confused. Is this a notify of the server to the client, or a > configuration item by the server instructing client behaviour? It is notify from the server to client. I.e. client sends empty TIMEOUT_PERIOD_FOR_LIVENESS_CHECK in the CFG_REQUEST and server will send value in seconds inside its TIMEOUT_PERIOD_FOR_LIVENESS_CHECK in CFG_REPLY. I.e. the server asks client to use following livenss timeout period. > > I can see some merit for this as this allows the server to limit the > > number of liveness checks by sending larger number, for example 600 > > seconds. > > So this seems like it is a configuration dictated by the server for > the client to use. What if the client disagrees? Does it ignore this > and use its own local policy? This is 3gpp, and what ePDG says is the law. No-one dares to disagree :-) I.e. their specification does not say anything about what happens if client disagrees. It do say that if it does not support this, then it will use whatever preconfigured value it has. On the other hand if client does not follow this request, there is nothing server can do. I.e. this only specifies how client sends those messages after timeout, it does not say that server should act on those messages. I.e., I do not think server can do anything based on the fact that it got them too often, or did not get them often enough... > > Some implementations use really short liveness check timeouts > > and send the liveness checks ever n seconds when connection is silent. > > So with this option, is the server now allowed to not answer a liveness > probe and should the client not close the connection if it receives no > answer? No. Server will respond to them as normally as this is normal mandatory behavior from IKEv2, and yes client will close the connection if server does not respond just like with normal IKEv2 liveness check. > > This is more in align with first use, i.e. the text asks to send > > liveness check this often even if the connection is completely silent. > > That's something that could go into an 7296 update as it is a useful > policy change in general (and likely already implemented by some. We > do this already as well) I think that is bad policy and I think it can be silently be allowed, but I do not really think we should encourage it. If connection is completely silent, i.e. no traffic flowing at all in either direction, there is no point of sending any liveness checks over it. In that case those liveness checks are just make dead packets. If your VPN is silent and no messages are going through (you are sleeping), and there is 30 minute network failure during the night, the make dead packets will kill your VPN and in the morning you need to retype your password even when the connection is working at that point. If you do not send make dead packets during the idle period, in the morning when you come to the keyboard and hit first time any key, that will send the packet to the other end and if other end is still up and running, VPN will continue stay up. If the other end has rebooted, it will reply with ICMP or IKE invalid SPI notify, which will trigger liveness check, and then the connection will be deleted quite soon, and new one connection is formed. > > The IKEv2 text says we do liveness checks to avoid black holes, and > > there cannot be black holes for packets if we do not send packets, > > thus we are not supposed to send liveness checks if both ends are > > silent. > > Sure, that text could use an update. > > > I am thinking of saying "go ahead" for IANA for this allocation even > > when this do change the IKEv2 bit, as I think there are > > implementations using same interpretation out there, and I think this > > configuration attribute is mostly harmless. > > The text below cities still does not make it clear to me if this is > a notification or an instruction. My understanding is that it is notification, i.e. there is no rules in the specification saying that server end should expect those liveness checks, and do something if it gets them or does not get them. > > If we would have done it > > here in the IPsecME WG, I think we would have used notifications > > instead of configuration payloads, as this attribute do affect the > > whole IKE SA and is not configuration attribute related to IPsec SA. > > But a notify is something that is informative, not instructive. So now > I am all confused again. That is my inderstanding what this is. You can go and download the http://www.3gpp.org/ftp/Specs/html-info/24302.htm and check yourself. > > So unless people object I will say "go ahead" in few days. > > I would _really_ prefer a 2 page draft that states the problem and > the solution, so that it becomes clear if these are local policy > suggestions or actual configuration requirements the client has to > accept or reject. If we could even get few paragraph explanation that would be really good, thats why I said it would be nice if 3gpp people would run their additions through this list before writing it in their draft. Now I have to check that 116 page document and find out what it is supposed to do :-) > > Ps, I still think it would be better for 3gpp to run their additions > > to IKEv2 through the IPsecME WG first to get some feedback for them > > before adding them to their drafts (i.e. send email to the list and > > ask for comments, no need to write internet drafts about proposals, > > but just explain why and what they plan to do). I at least would be > > more than happy to provide them feedback earlier, as I think this IANA > > allocation phase is too late phase to do such things. > > Yes. The IKEv2 registries are filling up with non-ikev2 entries. It > would really make sense to run this through the working group. I'll > bring this issue up in the TEG/TLC next week. What is TEG/TLC? > > Original allocation request: > > > > === > > > > Contact Name: > > Frederic Firmin > > > > Contact Email: > > frederic.firmin@etsi.org > > > > Type of Assignment: New item in the "IKEv2 Configuration Payload > > Attribute Types" of the "Internet Key Exchange Version 2 (IKEv2) > > Parameters" as shown at > > http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-21 > > and as specified in IETF RFC 4306 and updated by IETF RFC 5996 and > > IETF RFC 7296. > > > > Registry: The "IKEv2 Configuration Payload Attribute Types" of the > > "Internet Key Exchange Version 2 (IKEv2) Parameters" as shown at > > http://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-21 > > and as specified in IETF RFC 4306 and updated by IETF RFC 5996 and > > IETF RFC 7296. > > > > Description: > > This IKEv2 attribute is used to provide configuration for performing the liveness checks. > > > > Additional Info: ETF RFC 4306 defines the registry for the "IKEv2 > > Configuration Payload Attribute Types". IETF RFC 7296 and IETF RFC > > 5996 refer to IETF RFC 4306 for the definition of the registry. The > > following attribute is requested to be registered: - value: (number to > > be assigned by IANA) - attribute type: > > TIMEOUT_PERIOD_FOR_LIVENESS_CHECK - multi-valued: no - length: 4 > > octets - reference: 24.302 13.4.0 > > http://www.3gpp.org/ftp/Specs/html-info/24302.htm > > -- > > kivinen@iki.fi > > > > _______________________________________________ > > IPsec mailing list > > IPsec@ietf.org > > https://www.ietf.org/mailman/listinfo/ipsec > > -- kivinen@iki.fi From nobody Thu Feb 25 06:55:21 2016 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 5BE2E1AD351 for ; Thu, 25 Feb 2016 06:55:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p8O4P7m9Ndtk for ; Thu, 25 Feb 2016 06:55:19 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 D606D1AD277 for ; Thu, 25 Feb 2016 06:55:18 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u1PEt9sa005839 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 25 Feb 2016 16:55:09 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u1PEt9N8022909; Thu, 25 Feb 2016 16:55:09 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22223.5581.916730.962438@fireball.acr.fi> Date: Thu, 25 Feb 2016 16:55:09 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: References: <22223.2866.976241.499754@fireball.acr.fi> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 2 min X-Total-Time: 1 min Archived-At: Cc: ipsec@ietf.org, frederic.firmin@etsi.org Subject: Re: [IPsec] IANA allocation of TIMEOUT_PERIOD_FOR_LIVENESS_CHECK 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, 25 Feb 2016 14:55:20 -0000 Valery Smyslov writes: > > I am thinking of saying "go ahead" for IANA for this allocation even > > when this do change the IKEv2 bit, as I think there are > > implementations using same interpretation out there, and I think this > > configuration attribute is mostly harmless. If we would have done it > > here in the IPsecME WG, I think we would have used notifications > > instead of configuration payloads, as this attribute do affect the > > whole IKE SA and is not configuration attribute related to IPsec SA. > > > > So unless people object I will say "go ahead" in few days. > > I don't strongly object, however I have a concern: > how server can enforce the timeout period it sent to the client? > The client can ignore it and do liveness check more often > (for a good reason, if it has some data to send and has > no reply from server) or less often. It seems that this > notification could be ignored by the client completely and the server > cannot do anything about this (otherwise than tear down the > connection with "bad boy", but is it an intention?). > Or is this notification just a hint, not an enforcement? That is my understanding with this, and this is why I consider this "mostly harmless". Of course it would be easier to get information directly from people who are proposing this, and not just my interpretation of the issue. -- kivinen@iki.fi From nobody Thu Feb 25 07:04:16 2016 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 856881B29E6 for ; Thu, 25 Feb 2016 07:04:13 -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_12=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 tpROe-P5wjui for ; Thu, 25 Feb 2016 07:04:12 -0800 (PST) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 469821B29DD for ; Thu, 25 Feb 2016 07:04:12 -0800 (PST) Received: by mail-lf0-x22b.google.com with SMTP id m1so35014780lfg.0 for ; Thu, 25 Feb 2016 07:04:12 -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=MFjpoEdftFCji140HYDcnOmprNQ+jDp7myW137lb6g8=; b=e38COArk7HuSal9gaxSFk8v6EnDhv3x/AmPOjnwYWUmrr4CBvkK/CDF9eScVxJd6ZP dSAOEH0jIcL9FRSVeS25Atq4A/CSCkuSMoBRForJG0wqSfNUCl/X/WVES397SnKg7tXX QdjK43akn2+618/hc7b4a7OdrolwqdKvDTdCx6OTm0Y2crkDW50uWzRRAC0HMd875nIf GEqmroUiKulCEOTKb48xbKDVCMTrR1SJLLBKb7SU7G1qHU+MhlW6hm0zrFH4VHmlf+h5 Ek18/UykNt6FsCL2Op5SmU5cYx4qJ0npocFQzXVDYP++ckACxqe+qaYx+cW6PZWmScLl JGNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-type:content-transfer-encoding; bh=MFjpoEdftFCji140HYDcnOmprNQ+jDp7myW137lb6g8=; b=BwDLowNUF8VBSONyutrP/Om0ZYJd97goXd3HLm/673DeYliwNMSU5ROrBjSz+mQjKi ppzHo3zbrGtHijy5On0MsvMEso6oksdvlCMlrifnq9t7IVgqeF5pNtE9mEV36a/i7waF aBVsNh12g7L/3yIYkIzgu8JimTl0iRwmrBqMi4eH3hTawzfWfQuKgPOMg+zK3CP582m0 cKUQT0hzSfAXKbbqT1Nm59Izo18b+1fV8C59KFaNBkwKNmQcHzj4RqJn3j3RwFqWBe1a kpTtWOvfoJJRUTnQ5VrQGLE2L6tY0QYOv7J9asyJo+17zgtokYirq7aDI9bJw3hF+ZeH /+DA== X-Gm-Message-State: AG10YORslySqyUS9GZlzLYOJqkw28o19DY5z8Yz6ScylynzfrMJUo+1XPywd4daX5lSHhg== X-Received: by 10.25.19.220 with SMTP id 89mr12926794lft.33.1456412650397; Thu, 25 Feb 2016 07:04:10 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id e92sm1235233lfi.48.2016.02.25.07.04.09 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Feb 2016 07:04:09 -0800 (PST) Message-ID: <3D2B82DD711945AE8757ED0CE7E041E9@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" References: <46cc66173e324ae0b788f36cd58f5dfa@XCH-RCD-006.cisco.com><22220.36465.788794.855413@fireball.acr.fi><22222.1834.892900.623823@fireball.acr.fi><3C4D164CF08843258CE30B5B21363397@buildpc> <22222.63205.854356.14024@fireball.acr.fi> Date: Thu, 25 Feb 2016 18:04:12 +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: Cc: ipsec@ietf.org, "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01 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, 25 Feb 2016 15:04:13 -0000 >> It is a pity if QC protection mechanism won't work for these IKEv2 >> variants (as in your proposal). > > It wont. They are separate protocols, and they need to specify how > they are going to make their protocol QC resistant. > > Which has nothing to do with this discussion, as G-IKEv2 is not IKEv2, > nor it is work that is done in the IPsecME Wg at all. There used to be > separate working group (Msec) working on those protocols, and their > protocols were based on the IKE, but not really IKE. If they want to > use things we define here they need to incorporate them to their > protocols separately. We disagree on this. I think that if some solution can be re-used in a similar protocol, then it saves a lot of unnecessary work. G-IKEv2 is based on IKEv2 and they are very similar. Not only framing, but also the core crypto formulas are the same. >> Please, re-read the draft. In the last version it is not tied with any >> particular algorithms (AES, SHA256) and uses the negotiated >> PRF for SKEYSEED calculation. > > From the draft: > > ... > The PPK Indicator Algorithm is a 4 byte word that states which PPK > indicator to use. That is, it gives the encoding format for the PPK > that should be used is given to the responder. At present, the only > assigned encoding is 0x00000001, which indicates that AES256_SHA256 > will be used (as explained below). > ... This text is not concerned with SKEYSEED calculation, where the negotiated PRF is used. > That is actual real reason to do things differently. I.e. perhaps the > KEYMAT generation then should be > > KEYMAT = prf+(SK_d, g^ir (new) | prf(PPK, Ni) | prf(PPK, Nr)) > > instead? That's exactly how PPK is used in the draft (except that it is used there for SKEYSEED calculation). Regards, Valery. From nobody Thu Feb 25 07:06:36 2016 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 B2A5B1B29E3 for ; Thu, 25 Feb 2016 07:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.006] 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 yIWix1M6Pl_R for ; Thu, 25 Feb 2016 07:06:34 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (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 9050A1AD305 for ; Thu, 25 Feb 2016 07:06:34 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3q9yBJ5S1Bz1K4; Thu, 25 Feb 2016 16:06:32 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id LRIL2bjbIPJJ; Thu, 25 Feb 2016 16:06:31 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS; Thu, 25 Feb 2016 16:06:31 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id E28C4606625C; Thu, 25 Feb 2016 10:06:29 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca E28C4606625C Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id DECD1F6B2A; Thu, 25 Feb 2016 10:06:29 -0500 (EST) Date: Thu, 25 Feb 2016 10:06:29 -0500 (EST) From: Paul Wouters To: Tero Kivinen In-Reply-To: <22223.5419.528391.85358@fireball.acr.fi> Message-ID: References: <22223.2866.976241.499754@fireball.acr.fi> <22223.5419.528391.85358@fireball.acr.fi> User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Cc: ipsec@ietf.org, frederic.firmin@etsi.org Subject: Re: [IPsec] IANA allocation of TIMEOUT_PERIOD_FOR_LIVENESS_CHECK 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, 25 Feb 2016 15:06:35 -0000 On Thu, 25 Feb 2016, Tero Kivinen wrote: > It is notify from the server to client. I.e. client sends empty > TIMEOUT_PERIOD_FOR_LIVENESS_CHECK in the CFG_REQUEST and server will > send value in seconds inside its TIMEOUT_PERIOD_FOR_LIVENESS_CHECK in > CFG_REPLY. I.e. the server asks client to use following livenss > timeout period. Ok, then it should use NOTIFY and not CP. > I think that is bad policy and I think it can be silently be allowed, > but I do not really think we should encourage it. [ little off-topic. your arguments make sense and I will look at our implementation again :) ] > That is my inderstanding what this is. You can go and download the > http://www.3gpp.org/ftp/Specs/html-info/24302.htm and check yourself. > >>> So unless people object I will say "go ahead" in few days. >> >> I would _really_ prefer a 2 page draft that states the problem and >> the solution, so that it becomes clear if these are local policy >> suggestions or actual configuration requirements the client has to >> accept or reject. > > If we could even get few paragraph explanation that would be really > good, thats why I said it would be nice if 3gpp people would run their > additions through this list before writing it in their draft. > > Now I have to check that 116 page document and find out what it is > supposed to do :-) So this is a real problem. If we (implementors) want to implement these IKEv2 extensions, we need to have clear proper RFC's. I do not want to find 116 pages on third party websites (that may or may not be behind a registration or pay wall) >> Yes. The IKEv2 registries are filling up with non-ikev2 entries. It >> would really make sense to run this through the working group. I'll >> bring this issue up in the TEG/TLC next week. > > What is TEG/TLC? https://www.icann.org/resources/pages/tlg-73-2012-02-25-en It is a liaison group for the ICANN board consisting of various groups including ETSI, ITU, W3C and IETF. While this does not relate directly to ICANN (names/dns), it does have the right people there to talk about this kind of issue. Paul From nobody Thu Feb 25 07:21:15 2016 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 4BC601B2A12 for ; Thu, 25 Feb 2016 07:21:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 kp1yd7D-TZO1 for ; Thu, 25 Feb 2016 07:21:10 -0800 (PST) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CB8C1B2A4C for ; Thu, 25 Feb 2016 07:21:09 -0800 (PST) X-AuditID: c1b4fb25-f794e6d000003d15-c4-56cf1be37a6f Received: from ESESSHC008.ericsson.se (Unknown_Domain [153.88.183.42]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 9F.FE.15637.3EB1FC65; Thu, 25 Feb 2016 16:21:07 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.190]) by ESESSHC008.ericsson.se ([153.88.183.42]) with mapi id 14.03.0248.002; Thu, 25 Feb 2016 16:21:07 +0100 From: Ivo Sedlacek To: Tero Kivinen , Paul Wouters Thread-Topic: [IPsec] IANA allocation of TIMEOUT_PERIOD_FOR_LIVENESS_CHECK Thread-Index: AQHRb9ZEmL69MYW+c0mrQROWP3qUUJ88wFQAgAAHhYCAABbGAA== Date: Thu, 25 Feb 2016 15:21:06 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101162DAC83@ESESSMB301.ericsson.se> References: <22223.2866.976241.499754@fireball.acr.fi> <22223.5419.528391.85358@fireball.acr.fi> In-Reply-To: <22223.5419.528391.85358@fireball.acr.fi> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNIsWRmVeSWpSXmKPExsUyM2K7lu5j6fNhBl8+Glo0brnMbrF/yws2 i6Pnn7NZvL91icmBxePT0ulMHkuW/GTyOPx1IYvH93lMASxRXDYpqTmZZalF+nYJXBlHm1az FbwTrNj2fhtTA+Mnri5GTg4JAROJlnWT2SBsMYkL99YD2VwcQgKHGSXeTVjLDOEsYZRon/yL HaSKTUBPYuKWI6wgtoiAg8T6u1fAupkF4iRezZ3MBGILC3hKTP/6nA2ixktiw80GZgjbSeLN 4hYwm0VAVWLZr5NA9RwcvAK+Er3vBUDCQgIzGCXazueD2JwCZhJvtm1nBLEZBWQlrv7pZYRY JS5x68l8JoijBSSW7DnPDGGLSrx8/I8VwlaS+LHhEgtEvY7Egt2foM7Ulli28DVYPa+AoMTJ mU9YJjCKzUIydhaSlllIWmYhaVnAyLKKUbQ4tTgpN93IWC+1KDO5uDg/Ty8vtWQTIzDKDm75 rbqD8fIbx0OMAhyMSjy8G/6eDRNiTSwrrsw9xCjBwawkwisqdD5MiDclsbIqtSg/vqg0J7X4 EKM0B4uSOO8a5/VhQgLpiSWp2ampBalFMFkmDk6pBsb4AxeeXbY6Hrdlxxf2aY2ZL1KFtL55 yOV/b+BludL98nJfhbeF07YbYYc+FDw/8+6PGY+r4NsHO9Lu+cj3rba6Wq+SutBPZZJw1Nad wX4aJd1fLn87OMUkUnHv+cOJP563FLHtigxq3L1ggYqmBqOCu8Bx7eJLHdvu/xdY0x/TpsD7 9bXAAjklluKMREMt5qLiRABBCN7IrgIAAA== Archived-At: Cc: "ipsec@ietf.org" , "frederic.firmin@etsi.org" Subject: Re: [IPsec] IANA allocation of TIMEOUT_PERIOD_FOR_LIVENESS_CHECK 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, 25 Feb 2016 15:21:12 -0000 Hello, > > I am confused. Is this a notify of the server to the client, or a=20 > > configuration item by the server instructing client behaviour? >=20 > It is notify from the server to client. I.e. client sends empty TIMEOUT_P= ERIOD_FOR_LIVENESS_CHECK in the CFG_REQUEST and=20 > server will send value in seconds inside its TIMEOUT_PERIOD_FOR_LIVENESS_= CHECK in CFG_REPLY. I.e. the server asks client=20 > to use following livenss timeout period.=20 3GPP spec expects that if the client (User Equipment) supports the TIMEOUT_= PERIOD_FOR_LIVENESS_CHECK configuration attribute, then the client (User Eq= uipment) *enforces* the timer value indicated in the TIMEOUT_PERIOD_FOR_LIV= ENESS_CHECK configuration attribute in CFG_REPLY sent by server (Evolved Pa= cket Data Gateway). I.e. it is an intruction, not a suggestion. It is supposed to work as follows: first request --> IDi, [N(INITIAL_CONTACT)], [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], [IDr], [CP(CFG_REQUEST (*TIMEOUT_PERIOD_FOR_LIVENESS_CH= ECK with empty value*) )], [N(IPCOMP_SUPPORTED)+], [N(USE_TRANSPORT_MODE)], [N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(NON_FIRST_FRAGMENTS_ALSO)], SA, TSi, TSr, [V+][N+] first response <-- IDr, [CERT+], AUTH, EAP, [V+][N+] / --> EAP repeat 1..N times | \ <-- EAP last request --> AUTH last response <-- AUTH, [CP(CFG_REPLY(*TIMEOUT_PERIOD_FOR_LIVENESS_CHECK= with a value selected by server*))], [N(IPCOMP_SUPPORTED)], [N(USE_TRANSPORT_MODE)], [N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(NON_FIRST_FRAGMENTS_ALSO)], SA, TSi, TSr, [N(ADDITIONAL_TS_POSSIBLE)], [V+][N+] Kind regards Ivo Sedlacek From nobody Thu Feb 25 07:58:46 2016 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 252951B2B5A for ; Thu, 25 Feb 2016 07:58:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 n-5imRNqZReR for ; Thu, 25 Feb 2016 07:58:41 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 66BDD1B2B8D for ; Thu, 25 Feb 2016 07:58:37 -0800 (PST) X-AuditID: c1b4fb3a-f79ce6d000005138-bb-56cf24aac525 Received: from ESESSHC023.ericsson.se (Unknown_Domain [153.88.183.87]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 18.E5.20792.AA42FC65; Thu, 25 Feb 2016 16:58:35 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.190]) by ESESSHC023.ericsson.se ([153.88.183.87]) with mapi id 14.03.0248.002; Thu, 25 Feb 2016 16:58:34 +0100 From: Ivo Sedlacek To: Tero Kivinen , Paul Wouters Thread-Topic: [IPsec] IANA allocation of TIMEOUT_PERIOD_FOR_LIVENESS_CHECK Thread-Index: AQHRb9ZEmL69MYW+c0mrQROWP3qUUJ88wFQAgAAHhYCAABbGAA== Date: Thu, 25 Feb 2016 15:58:34 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101162DAD5D@ESESSMB301.ericsson.se> References: <22223.2866.976241.499754@fireball.acr.fi> <22223.5419.528391.85358@fireball.acr.fi> In-Reply-To: <22223.5419.528391.85358@fireball.acr.fi> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.146] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B31079006101162DAD5DESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGIsWRmVeSWpSXmKPExsUyM2J7uO5qlfNhBm1HOCwat1xmt9i/5QWb xdHzz9ks3t+6xOTA4vFp6XQmjyVLfjJ5HP66kMXj+zymAJYoLpuU1JzMstQifbsEroz/+18x FvSvZqqY27yetYGxvZepi5GTQ0LAROL86jZ2CFtM4sK99WxdjFwcQgKHGSW+njrJAuEsYZT4 ceoXWAebgJ7ExC1HWEFsEQEHifV3r7CB2MwCcRKv5k4GqxEW8JSY/vU5G0SNl8SGmw3MELaT xJvFLWA2i4CqROOJ72CbeQV8JWY92g7WKyQwg1Gi7Xw+iM0pYCbxZtt2RhCbUUBW4uqfXkaI XeISt57Mh/pAQGLJnvPMELaoxMvH/1ghbCWJHxsusUDU50ss7+9gg9glKHFy5hOWCYyis5CM moWkbBaSMoi4jsSC3Z/YIGxtiWULXzPD2GcOPGZCFl/AyL6KUbQ4tbg4N93ISC+1KDO5uDg/ Ty8vtWQTIzA2D275bbWD8eBzx0OMAhyMSjy8G/6eDRNiTSwrrsw9xCjBwawkwtuufD5MiDcl sbIqtSg/vqg0J7X4EKM0B4uSOO8a5/VhQgLpiSWp2ampBalFMFkmDk6pBkZ5fdtMRa03CeLX vbwX5sRkvf0xy/PqS5n5BYbCJoVtMXMD5pRNeOG2IpLv4BkXtflnMo73GZ34Ysw9Y+bmJNV/ WzXr7286/OnvpeDtq3Pbn84WWf9r8g+Om67r/r9xj17ZJyIgtq6S9V61Wa1wjeHh/bO8RGvV Nu2YPe/DVxXjNS+E24+5/vdVYinOSDTUYi4qTgQA/7k9dskCAAA= Archived-At: Cc: "ipsec@ietf.org" , "frederic.firmin@etsi.org" Subject: Re: [IPsec] IANA allocation of TIMEOUT_PERIOD_FOR_LIVENESS_CHECK 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, 25 Feb 2016 15:58:44 -0000 --_000_39B5E4D390E9BD4890E2B31079006101162DAD5DESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, In case you are interested in detailed procedures of the 3GPP specification= , I have copied them at the end of this mail. > > I am confused. Is this a notify of the server to the client, or a > > configuration item by the server instructing client behaviour? > > It is notify from the server to client. I.e. client sends empty TIMEOUT_P= ERIOD_FOR_LIVENESS_CHECK in the CFG_REQUEST and > server will send value in seconds inside its TIMEOUT_PERIOD_FOR_LIVENESS_= CHECK in CFG_REPLY. I.e. the server asks client > to use following livenss timeout period. 3GPP spec expects that if the client (User Equipment) supports the TIMEOUT_= PERIOD_FOR_LIVENESS_CHECK configuration attribute, then the client (User Eq= uipment) *enforces* the timer value indicated in the TIMEOUT_PERIOD_FOR_LIV= ENESS_CHECK configuration attribute in CFG_REPLY sent by server (Evolved Pa= cket Data Gateway). I.e. it is an intruction, not a suggestion. It is supposed to work as follows: first request --> IDi, [N(INITIAL_CONTACT)], [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], [IDr], [CP(CFG_REQUEST (*TIMEOUT_PERIOD_FOR_LIVENESS_CH= ECK with empty value*) )], [N(IPCOMP_SUPPORTED)+], [N(USE_TRANSPORT_MODE)], [N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(NON_FIRST_FRAGMENTS_ALSO)], SA, TSi, TSr, [V+][N+] first response <-- IDr, [CERT+], AUTH, EAP, [V+][N+] / --> EAP repeat 1..N times | \ <-- EAP last request --> AUTH last response <-- AUTH, [CP(CFG_REPLY(*TIMEOUT_PERIOD_FOR_LIVENESS_CHECK= with a value selected by server*))], [N(IPCOMP_SUPPORTED)], [N(USE_TRANSPORT_MODE)], [N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(NON_FIRST_FRAGMENTS_ALSO)], SA, TSi, TSr, [N(ADDITIONAL_TS_POSSIBLE)], [V+][N+] If the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK with a value selected by server is= received as shown above, the client (user equipment) must perform the live= ness check procedure with the timeout indicated by the TIMEOUT_PERIOD_FOR_L= IVENESS_CHECK configuration attribute. Detailed TS 24.302 client procedures related to the TIMEOUT_PERIOD_FOR_LIVE= NESS_CHECK attribute are: ------------- 7.2.2 Tunnel establishment 7.2.2.1 Tunnel establishment accepted by the network ..... The UE may support the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as speci= fied in subclause 8.2.4.2. If the UE supports the TIMEOUT_PERIOD_FOR_LIVENE= SS_CHECK attribute, the UE shall include the TIMEOUT_PERIOD_FOR_LIVENESS_CH= ECK attribute indicating support of receiving timeout period for liveness c= heck in the CFG_REQUEST configuration payload. If the TIMEOUT_PERIOD_FOR_LI= VENESS_CHECK attribute as specified in subclause 8.2.4.2 indicating the tim= eout period for the liveness check is included in the CFG_REPLY configurati= on payload or if the UE has a pre-configured timeout period, the UE shall p= erform the tunnel liveness checks as described in subclause 7.2.2A. NOTE: The timeout period for liveness check is pre-configured in the U= E in implementation-specific way. ..... 7.2.2A Liveness check If the UE supports the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as speci= fied in subclause 8.2.4.2 and the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribu= te as specified in subclause 8.2.4.2 was included in the CFG_REPLY configur= ation payload received in subclause 7.2.2 the UE shall set the timeout peri= od for the liveness check to the value of the TIMEOUT_PERIOD_FOR_LIVENESS_C= HECK attribute. If the UE does not support the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute = as specified in subclause 8.2.4.2 or the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK = attribute as specified in subclause 8.2.4.2 was not included in the CFG_REP= LY configuration payload received in subclause 7.2.2 then the UE shall use = the pre-configured value of the timeout period for liveness check. NOTE: The timeout period is pre-configured in the UE in implementation= -specific way. If the UE has not received any cryptographically protected IKEv2 or IPSec m= essage for the duration of the timeout period for liveness check, the UE sh= all send an INFORMATIONAL request with no payloads as per IETF RFC 5996 [28= ]. If an INFORMATIONAL response is not received, the UE shall deem the IKEv= 2 security association to have failed. ------------- Detailed TS 24.302 server procedures related to the TIMEOUT_PERIOD_FOR_LIVE= NESS_CHECK attribute are: ------------- The ePDG shall proceed with IPsec tunnel setup completion and shall relay i= n the IKEv2 Configuration Payload (CFG_REPLY) of the final IKE_AUTH respons= e message: ... - The ePDG may include the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute = as specified in subclause 8.2.4.2 indicating the timeout period for livenes= s check in the CFG_REPLY configuration payload. Presence of the TIMEOUT_PER= IOD_FOR_LIVENESS_CHECK attribute in the IKE_AUTH request can be used as inp= ut for decision on whether to include the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK= attribute. ... ------------- Kind regards Ivo Sedlacek --_000_39B5E4D390E9BD4890E2B31079006101162DAD5DESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

In case you are int= erested in detailed procedures of the 3GPP specification, I have copied the= m at the end of this mail.

 

> > I am confused. Is this a notify of the = server to the client, or a

> > configuration item by the server instru= cting client behaviour?

>

> It is notify from the server to client. I.e.= client sends empty TIMEOUT_PERIOD_FOR_LIVENESS_CHECK in the CFG_REQUEST an= d

> server will send value in seconds inside its= TIMEOUT_PERIOD_FOR_LIVENESS_CHECK in CFG_REPLY. I.e. the server asks clien= t

> to use following livenss timeout period.

 

3GPP spec expects that if the client (User Equipm= ent) supports the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK configuration attribute= , then the client (User Equipment) *enforces* the timer value indicated in = the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK configuration attribute in CFG_REPLY sent by server (Evolved Packet Data G= ateway).

 

I.e. it is an intruction, not a suggestion.<= /o:p>

 

It is supposed to work as follows:

 

   first request    = ;   --> IDi,

        &= nbsp;           &nbs= p;      [N(INITIAL_CONTACT)],

        &= nbsp;           &nbs= p;      [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ&= #43;],

        &= nbsp;           &nbs= p;      [IDr],

        &= nbsp;            &nb= sp;     [CP(CFG_REQUEST (*TIMEOUT_PERIOD_FOR_LIVEN= ESS_CHECK with empty value*) )],

        &= nbsp;           &nbs= p;      [N(IPCOMP_SUPPORTED)+],

        &= nbsp;           &nbs= p;      [N(USE_TRANSPORT_MODE)],

        &= nbsp;           &nbs= p;      [N(ESP_TFC_PADDING_NOT_SUPPORTED)],

        &= nbsp;           &nbs= p;      [N(NON_FIRST_FRAGMENTS_ALSO)],<= /p>

        &= nbsp;           &nbs= p;      SA, TSi, TSr,

        &= nbsp;           &nbs= p;      [V+][N+]

 

   first response   &nbs= p;  <-- IDr, [CERT+], AUTH,

        &= nbsp;           &nbs= p;      EAP,

        &= nbsp;           &nbs= p;      [V+][N+]

 

         =             / -= -> EAP

   repeat 1..N times |

        &= nbsp;            \ &= lt;-- EAP

 

   last request    =     --> AUTH

 

   last response    = ;   <-- AUTH,

        &= nbsp;           &nbs= p;      [CP(CFG_REPLY(*TIMEOUT_PERIOD_FOR_LIVENESS= _CHECK with a value selected by server*))],

        &= nbsp;           &nbs= p;      [N(IPCOMP_SUPPORTED)],

        &= nbsp;           &nbs= p;      [N(USE_TRANSPORT_MODE)],

        &= nbsp;           &nbs= p;      [N(ESP_TFC_PADDING_NOT_SUPPORTED)],

        &= nbsp;           &nbs= p;      [N(NON_FIRST_FRAGMENTS_ALSO)],<= /p>

        &= nbsp;           &nbs= p;      SA, TSi, TSr,

        &= nbsp;           &nbs= p;      [N(ADDITIONAL_TS_POSSIBLE)],

        &= nbsp;           &nbs= p;      [V+][N+]

 

 

If the TIMEOUT_PERI= OD_FOR_LIVENESS_CHECK with a value selected by server is received as shown = above, the client (user equipment) must perform the liveness check procedure with the timeout indicated by the TIM= EOUT_PERIOD_FOR_LIVENESS_CHECK configuration attribute.

 

 

Detailed TS 24.302 = client procedures related to the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribut= e are:

-------------<= /o:p>

7.2.2 &nbs= p;     Tunnel establishment

7.2.2.1 Tunnel establishment accepted by the network

.....

The UE may support the TIMEOUT_PERIOD_F= OR_LIVENESS_CHECK attr= ibute as specified in subclause <= /span>8.2.4.2. If t= he UE supports the TIMEOUT_PERIOD_F= OR_LIVENESS_CHECK attr= ibute, the UE shall include the TIMEOUT_PERIOD_F= OR_LIVENESS_CHECK attr= ibute indicating support of receiving timeout period for liveness check in t= he CFG_REQUEST c= onfiguration payload. If the TIMEOUT_PERIOD_F= OR_LIVENESS_CHECK attr= ibute as specified in subclause 8.2.4.2 indicating the timeout period for the liveness check is i= ncluded in the CFG_REPLY configuration payl= oad or if the UE has a pre-configured timeout period, the UE shall perform = the tunnel liveness check= s as described in subclause 7.2.2A= .

NOTE: =      The timeout period for liveness check is pre-confi= gured in the UE in implementation-specific way.

.....

7.2.2A    L= iveness check

If the UE supports the TIMEOUT_PERIOD_F= OR_LIVENESS_CHECK attr= ibute as specified in subclause <= /span>8.2.4.2 and = the TIMEOUT_PERIOD_F= OR_LIVENESS_CHECK attr= ibute as specified in subclause 8.2.4.2 was included in the CFG_REPLY configu= ration payl= oad received in subclause 7.2.2 the UE shall set the timeout period for the liveness check to the value of= the TIMEOUT_PERIOD_FOR_LIVE= NESS_CHECK attr= ibute.

If the UE does not support the TIMEOUT_PERIOD_FOR_LIVE= NESS_CHECK attribute a= s specified in subclause <= span lang=3D"EN-US" style=3D"color:#984807;mso-style-textfill-fill-color:#9= 84807;mso-style-textfill-fill-alpha:100.0%">8.2.4.2 or the TIMEOUT_PERIOD_FOR_LIVE= NESS_CHECK attribute a= s specified in subclause 8.2.4.2 was not included in the CFG_REPLY con= figuration payload rec= eived in subclause 7.2.2 then the UE shall use the pre-configured value of the timeout period for l= iveness check.

NOTE:      The timeout period is p= re-configured in the UE in implementation-specific way.

If the UE has not received any cryptographically protected IKEv2 or= IPSec message for the duration of the timeout period for liveness check, the UE shall send an INFORMATIONAL request with no payl= oads as per IETF=  RFC 5996 [28]. If an INFORMATIONAL response is not received, the UE shall deem the IKEv2 = security association to have failed.

-------------<= /o:p>

 

Detailed TS 24.302 = server procedures related to the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribut= e are:

-------------<= /o:p>

The ePDG sh= all proceed with IPsec tunnel setup completion and shall relay in the IKEv2= Configuration Payload (CFG_REPLY) of the final IKE_AUTH response message:

...=

- &nbs= p;   The ePDG may include the TIMEOUT_PERIOD_F= OR_LIVENESS_CHECK attribute as specified in subclause 8.2.4.2 indicating the timeout period for liveness check in the CFG_REPLY configuration payload. Presence= of the TIMEOUT_PERIOD_F= OR_LIVENESS_CHECK attribute in the IKE_AUTH request can be used as input for decision on whe= ther to include the TIMEOUT_PERIOD_F= OR_LIVENESS_CHECK attribute.<= /span>

...=

-------------<= /o:p>

 

 

Kind regards

 

Ivo Sedlacek

--_000_39B5E4D390E9BD4890E2B31079006101162DAD5DESESSMB301erics_-- From nobody Thu Feb 25 14:33:55 2016 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 248851B36A6 for ; Thu, 25 Feb 2016 14:33:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -13.907 X-Spam-Level: X-Spam-Status: No, score=-13.907 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_12=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 lV1OZLrunAyE for ; Thu, 25 Feb 2016 14:33:52 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AD1721B36A7 for ; Thu, 25 Feb 2016 14:33:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2039; q=dns/txt; s=iport; t=1456439632; x=1457649232; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=Hpvfi+V0T6IB+84oAy4iia/R30M7wwEJ87CFTP2DAks=; b=RXAs6WZmO4O0Vms6SA6K13RVBF1gBx761UuQLk7aUnrpJSv3FLu3vFHz Z9kW5WW2KVv9B+wYXB1xVUjdRS/Wu3cnmDHjoCleLznOTcvgx9cKjIH4i Rna3aVYJh1Bf/Q/Vkn4OZRT3SS5pB/bCwILlCdhkrGi3pO6lZaj+QiSWk A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CDBQAjgM9W/4sNJK1egzqBPwa8K4YNA?= =?us-ascii?q?oFGOxEBAQEBAQEBZCeEQQEBAQMBOj8MBAIBCBEEAQEfCQcyFAkIAgQBDQUIiA8?= =?us-ascii?q?IvSMBAQEBAQEBAQEBAQEBAQEBAQEBAQEVhhKEOoQmhEkBBJcIAY1XjnuOSAE2L?= =?us-ascii?q?INkaoZfO34BAQE?= X-IronPort-AV: E=Sophos;i="5.22,498,1449532800"; d="scan'208";a="75092950" Received: from alln-core-6.cisco.com ([173.36.13.139]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 25 Feb 2016 22:33:51 +0000 Received: from XCH-ALN-006.cisco.com (xch-aln-006.cisco.com [173.36.7.16]) by alln-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id u1PMXpQU001858 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 25 Feb 2016 22:33:51 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-ALN-006.cisco.com (173.36.7.16) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 25 Feb 2016 16:33:50 -0600 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Thu, 25 Feb 2016 16:33:50 -0600 From: "Scott Fluhrer (sfluhrer)" To: Tero Kivinen , Valery Smyslov Thread-Topic: [IPsec] draft-fluhrer-qr-ikev2-01 Thread-Index: AQHRbvi7p+TSA7HS2kmK991x6lVN5p87/Q4AgABj/diAALnLgIAAOICw Date: Thu, 25 Feb 2016 22:33:50 +0000 Message-ID: References: <46cc66173e324ae0b788f36cd58f5dfa@XCH-RCD-006.cisco.com> <22220.36465.788794.855413@fireball.acr.fi> <22222.1834.892900.623823@fireball.acr.fi> <3C4D164CF08843258CE30B5B21363397@buildpc> <22222.63205.854356.14024@fireball.acr.fi> In-Reply-To: <22222.63205.854356.14024@fireball.acr.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.70.233.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org" Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01 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, 25 Feb 2016 22:33:54 -0000 > -----Original Message----- > From: Tero Kivinen [mailto:kivinen@iki.fi] > Sent: Thursday, February 25, 2016 7:43 AM > To: Valery Smyslov > Cc: Scott Fluhrer (sfluhrer); ipsec@ietf.org > Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01 >=20 > Valery Smyslov writes: > > > And what information do you think is there that is really worth of > > > protecting? > > >=20 > > Most PRFs accept key of arbitrary length. And if some PRF is defined > > with a fixed length key, that there will be a problem with this PRF in > > IKEv2 anyway - with calculation of SKEYSEED, where key is a > > concatenation of the nonces. That's why an ugly hack for > > AES-XCBC-PRF-128 and AES-CMAC-PRF-128 is included in the protocol. >=20 > Most PRFs accept arbitrary length key, but they will convert it to suitab= le for > the algorithm by hashing it first. For example > AES-XCBC-PRF-128 will take the key and calculate the AES-XCBC-PRF-128 wit= h > zero key and will get 128 bit key out from that which is then used as the= key > to PRF. XCBC is already excluded by the guidance that recommends to use AES-256. H= owever, I would agree that the guidance needs to be more complete. >=20 > That is actual real reason to do things differently. I.e. perhaps the KEY= MAT > generation then should be >=20 > KEYMAT =3D prf+(SK_d, g^ir (new) | prf(PPK, Ni) | prf(PPK, Nr)) >=20 > instead? That would certainly be a more implementable suggestion, if the WG is OK wi= th the idea that the IKE SAs not being protected. It would make like livin= g with an HSM easier to deal with, while making the process of deciding whi= ch PPK to use simpler. We may end up including a simple notification schem= e (to help with a brownfield scenario, where the peer may or may not be upg= raded to use PPK yet), but we might also decide to omit that as well. So, is the protection of the IKE SA important? I would personally vote tha= t it is, but if the WG decides otherwise, then this is clearly a better pro= posal. From nobody Thu Feb 25 16:03:30 2016 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 D8D081B37DF for ; Thu, 25 Feb 2016 16:03:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-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 5volKbXApeVL for ; Thu, 25 Feb 2016 16:03:26 -0800 (PST) Received: from gcc01-CY1-obe.outbound.protection.outlook.com (mail-cy1gcc01on0101.outbound.protection.outlook.com [23.103.200.101]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D65941B31EB for ; Thu, 25 Feb 2016 16:03:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nistgov.onmicrosoft.com; s=selector1-nist-gov; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=pTKiB7UKHQtONocrbKA+KT6Mxf+Hm2HBqgfqvTeqrhM=; b=zUzVVgTCl8IZ9uj976M4kdi9fAPn9vhaEm4SFARzBplQ8FCPXixOGfmgUDW51mSLirBy6ml4oQpKEop+bkSJzOmk6sSmC40ZEL07QE2Q28WzoyAdT6wJuzhQOPkSD6T8EQ3GIna6fh63WBUQPez+bQyDOAhsIao1sqhmeqXkhkc= Received: from DM2PR09MB0365.namprd09.prod.outlook.com (10.160.247.18) by DM2PR09MB0365.namprd09.prod.outlook.com (10.160.247.18) with Microsoft SMTP Server (TLS) id 15.1.409.15; Fri, 26 Feb 2016 00:03:22 +0000 Received: from DM2PR09MB0365.namprd09.prod.outlook.com ([10.160.247.18]) by DM2PR09MB0365.namprd09.prod.outlook.com ([10.160.247.18]) with mapi id 15.01.0409.024; Fri, 26 Feb 2016 00:03:22 +0000 From: "Waltermire, David A." To: "ipsec@ietf.org WG" Thread-Topic: [IPsec] Textual changes to the DDoS draft Thread-Index: AQHRbWMiakRhWjG5V0W8hGiSgOCOwp89czsg Date: Fri, 26 Feb 2016 00:03:22 +0000 Message-ID: References: <9DC60612-D5BC-4D55-8364-90DA5CAEB41F@gmail.com> In-Reply-To: <9DC60612-D5BC-4D55-8364-90DA5CAEB41F@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=nist.gov; x-originating-ip: [129.6.224.58] x-microsoft-exchange-diagnostics: 1; DM2PR09MB0365; 5:DdO9K8YJubcfKePzavQDAT+tVZ34X2tYj//rsQA6BBPxyM9NVRdux9+3/Gf4RyXXfNa5nyx4yGF1Aej/iFcDVkToFKyrR8DiU2eXCvVUWkjyroc4m6XiuWuVWd2xFfYcqVAQlYBOC2KV4wK/O+QGvQ==; 24:pWBG55jSSoC2PF9HKSDUlMOO6CNa6rII1sMNolEjZCU7QmvzKHOP4tELVHiSNhT0Kt9v6RFPAd+cSclk14w+djXEjYbjdM9+IHVbqEk/sHI= x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR09MB0365; x-ms-office365-filtering-correlation-id: fee9d533-92e8-4d4d-8b6f-08d33e403df6 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:; x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001); SRVR:DM2PR09MB0365; BCL:0; PCL:0; RULEID:; SRVR:DM2PR09MB0365; x-forefront-prvs: 0864A36BBF x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(377454003)(52604005)(164054003)(53754006)(122556002)(1220700001)(92566002)(19617315012)(19609705001)(790700001)(74316001)(3660700001)(6116002)(40100003)(15975445007)(99286002)(19580405001)(77096005)(19580395003)(33656002)(450100001)(2950100001)(2900100001)(16236675004)(19625215002)(10400500002)(3280700002)(5003600100002)(5002640100001)(11100500001)(54356999)(19300405004)(107886002)(189998001)(50986999)(106116001)(110136002)(1096002)(87936001)(102836003)(3846002)(76176999)(5001960100002)(86362001)(5008740100001)(586003)(2906002)(76576001)(66066001)(5004730100002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR09MB0365; H:DM2PR09MB0365.namprd09.prod.outlook.com; FPR:; SPF:None; MLV:sfv; LANG:en; spamdiagnosticoutput: 1:23 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_DM2PR09MB0365CABFFA5C55BB6A637720F0A70DM2PR09MB0365namp_" MIME-Version: 1.0 X-OriginatorOrg: nist.gov X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Feb 2016 00:03:22.4022 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 2ab5d82f-d8fa-4797-a93e-054655c61dec X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR09MB0365 Archived-At: Subject: Re: [IPsec] Textual changes to the DDoS draft 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, 26 Feb 2016 00:03:30 -0000 --_000_DM2PR09MB0365CABFFA5C55BB6A637720F0A70DM2PR09MB0365namp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I haven't seen any additional feedback on the DDoS draft this week based on= Yoav's note about the PR [1]. It also looks like the discussion on chainin= g puzzles has wrapped up with no changes needed to the draft [2]. Unless there is any additional concerns with these issues, I believe we are= ready for a WGLC on an updated revision of the draft. Once Yoav posts the updated draft based on the PR, I'll issue the WGLC. Thanks for working through these last issues. Thanks, Dave [1] https://mailarchive.ietf.org/arch/msg/ipsec/XjuWvb9PvVjH1YMSzAMkAuC1zOQ [2] https://mailarchive.ietf.org/arch/msg/ipsec/yeS8ooGWfvnxfs8zS24LYYpr9QM From: IPsec [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Monday, February 22, 2016 6:21 AM To: ipsec@ietf.org WG Subject: [IPsec] Textual changes to the DDoS draft Hi all Valery submitted a new PR with a couple of textual changes, mostly based on= comments by Dave. https://github.com/ietf-ipsecme/drafts/pull/12 The changes (listed below) seem fine to me. If nobody objects, I will merge= them in on Friday. Yoav List of changes: #1: Change snarky reference to Starbucks to something less snarky and less = related to starbucks: OLD: For example, if a certain purveyor of beverages resembling coffee provides = Internet connectivity to its customers through an IPv4 NAT device, a single= malicious customer can create enough half-open SAs to fill the quota for t= he NAT device external IP address. Legitimate Initiators on the same networ= k will not be able to initiate IKE. NEW: For example, if an network service provider or some establishment offers In= ternet connectivity to its customers or employees through an IPv4 NAT devic= e, a single malicious customer can create enough half-open SAs to fill the = quota for the NAT device external IP address. Legitimate Initiators on the = same network will not be able to initiate IKE. #2: Purely textual change OLD: Regardless of the type of rate-limiting used, there is a huge advantage in = blocking the DoS attack using rate-limiting in that legitimate clients who = are away from the attacking nodes should not be adversely affected by eithe= r the attack or by the measures used to counteract it. NEW: Regardless of the type of rate-limiting used, there is a huge advantage in = blocking the DoS attack using rate-limiting for legitimate clients that are= away from the attacking nodes. In such cases, adverse impacts caused by th= e attack or by the measures used to counteract the attack can be avoided. --_000_DM2PR09MB0365CABFFA5C55BB6A637720F0A70DM2PR09MB0365namp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I haven’t seen any additional f= eedback on the DDoS draft this week based on Yoav’s note about the PR= [1]. It also looks like the discussion on chaining puzzles has wrapped up with no changes needed to the draft [2].<= /p>

 

Unless there is any additional concer= ns with these issues, I believe we are ready for a WGLC on an updated revis= ion of the draft.

 

Once Yoav posts the updated draft bas= ed on the PR, I’ll issue the WGLC.

 

Thanks for working through these last= issues.

 

Thanks,

Dave

 

[1] https://mailarchive.ietf.org/arch/msg/ipsec/XjuWvb9PvVjH1YMSzAMkAuC1zOQ=

[2] https://mailarchive.ietf.org/arch/msg/ipsec/yeS8ooGWfvnxfs8zS24LYYpr9QM=

 

From: IPsec [mailto:ipsec-bounces@ie= tf.org] On Behalf Of Yoav Nir
Sent: Monday, February 22, 2016 6:21 AM
To: ipsec@ietf.org WG <ipsec@ietf.org>
Subject: [IPsec] Textual changes to the DDoS draft=

 

Hi all

 

Valery submitted a new PR with a couple of textual c= hanges, mostly based on comments by Dave.

 

 

The changes (listed below) seem fine to me. If nobod= y objects, I will merge them in on Friday.

 

Yoav

 

List of changes:

 

#1: Change snarky reference to Starbucks to somethin= g less snarky and less related to starbucks:

OLD:

For example, if a certain purveyor of beverages rese= mbling coffee provides Internet connectivity to its customers through an IP= v4 NAT device, a single malicious customer can create enough half-open SAs = to fill the quota for the NAT device external IP address. Legitimate Initiators on the same network will not be= able to initiate IKE.

 

NEW:

For example, if an network service provider or some = establishment offers Internet connectivity to its customers or employees th= rough an IPv4 NAT device, a single malicious customer can create enough hal= f-open SAs to fill the quota for the NAT device external IP address. Legitimate Initiators on the same network = will not be able to initiate IKE.

 

 

#2: Purely textual change

OLD:

Regardless of the type of rate-limiting used, there = is a huge advantage in blocking the DoS attack using rate-limiting in that = legitimate clients who are away from the attacking nodes should not be adve= rsely affected by either the attack or by the measures used to counteract it.

 

NEW:

Regardless of the type of rate-limiting used, there = is a huge advantage in blocking the DoS attack using rate-limiting for legi= timate clients that are away from the attacking nodes. In such cases, adver= se impacts caused by the attack or by the measures used to counteract the attack can be avoided.

--_000_DM2PR09MB0365CABFFA5C55BB6A637720F0A70DM2PR09MB0365namp_-- From nobody Thu Feb 25 21:43:42 2016 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 3AB701A90E9 for ; Thu, 25 Feb 2016 21:43:40 -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 tkeUKQXp-AL5 for ; Thu, 25 Feb 2016 21:43:39 -0800 (PST) Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B4B041A90E1 for ; Thu, 25 Feb 2016 21:43:38 -0800 (PST) Received: by mail-wm0-x22a.google.com with SMTP id g62so58885387wme.0 for ; Thu, 25 Feb 2016 21:43:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=UQFw7UH7ShmtyRWwM37zwbjbQ1vNYRqkL/jim4hPzT0=; b=FAJGSgrYOZwZgAEP6Z9I3ifOSsyVPnmBIRWxA8WdgQwVwbido4QYdWcmeffWUcgln3 DdE1fhqbHT1K3E7he4ruC/K7+7i3zCjagMIScXp+Xbadz0FE0calBXyIxIIrACYsLGay nULCR7Pyn7QKxtR06OINK9vnMO8zNMVcOmb23YBDyHbOL5S8MgEn7xlv6uKIMnaiXjNQ otCWcwXIGHxnZ1ztyeh03VeYAmi3/3YjUgvHGCsMQ8R6MvGSAvbC7b8wCThwu/CiWzLJ Q56KuysENO7ewM2R51NfigLLmab7Je3obKDMWT+ibi+zOQb1b7ow9pH07KyCac2uRyK/ g6BQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=UQFw7UH7ShmtyRWwM37zwbjbQ1vNYRqkL/jim4hPzT0=; b=avFzashBF5daQZg8NZzYU3lrwe+pYP0AoPClc31J+KjBJMLdcWSrcQsBMjjzHD7Iu/ ZfBVPpMJRV4n+ywTSApIFV0lU1/12e+B/wZy8wddxC7Eardk33ij6ck2C53p4d2cpQKM +BNGH5GZm6juAXUN1j5TRAiWt2V3/9TV3XZ2vBO5/k6N1faSCXURmfmMobcge5seLRxc fqzhj+hFoyfP3c64oSkTiq9t+pk6h1ZdbEnert28U7rG6PyLk8t7A50b9e8ytlcXpLfc KmD8aoF2CRwKogak3U4igWGFDBu6ZChWUeaM0zluFfcYflM1p/WyCikP9d+ROx8MMlGo jrPQ== X-Gm-Message-State: AD7BkJIr7K1RQCfUYQU9UgIqqPC47a77rJhgC8Em8ZeWJBT+r7Pa4s/dUr+XrzYC8yiWDg== X-Received: by 10.28.140.202 with SMTP id o193mr1140104wmd.102.1456465417303; Thu, 25 Feb 2016 21:43:37 -0800 (PST) Received: from [192.168.1.13] ([46.120.13.132]) by smtp.gmail.com with ESMTPSA id l7sm10895429wjx.14.2016.02.25.21.43.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 25 Feb 2016 21:43:36 -0800 (PST) Content-Type: multipart/alternative; boundary="Apple-Mail=_D5BB28FB-CCDA-4683-8D57-855E7512E5AB" Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Yoav Nir In-Reply-To: Date: Fri, 26 Feb 2016 07:43:34 +0200 Message-Id: <7480BF86-4EAD-4651-97B5-3B318FA010BA@gmail.com> References: <9DC60612-D5BC-4D55-8364-90DA5CAEB41F@gmail.com> To: "Waltermire, David A." X-Mailer: Apple Mail (2.3112) Archived-At: Cc: "ipsec@ietf.org WG" Subject: Re: [IPsec] Textual changes to the DDoS draft 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, 26 Feb 2016 05:43:40 -0000 --Apple-Mail=_D5BB28FB-CCDA-4683-8D57-855E7512E5AB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On 26 Feb 2016, at 2:03 AM, Waltermire, David A. = wrote: >=20 > I haven=E2=80=99t seen any additional feedback on the DDoS draft this = week based on Yoav=E2=80=99s note about the PR [1]. It also looks like = the discussion on chaining puzzles has wrapped up with no changes needed = to the draft [2]. Oh. My impression of [2] was that Valery and I were in agreement that = this change was a good idea, with Scott and Yaron supporting (not quite = as enthusiastically) and with not opinions to the contrary. Valery and I = thought we=E2=80=99d make this change over the weekend. Yoav --Apple-Mail=_D5BB28FB-CCDA-4683-8D57-855E7512E5AB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
On 26 Feb 2016, at 2:03 AM, Waltermire, David A. <david.waltermire@nist.gov> wrote:

I = haven=E2=80=99t seen any additional feedback on the DDoS draft this week = based on Yoav=E2=80=99s note about the PR [1]. It also looks like the = discussion on chaining puzzles has wrapped up with no changes needed to = the draft [2].

Oh. My impression of [2] was that Valery and I = were in agreement that this change was a good idea, with Scott and Yaron = supporting (not quite as enthusiastically) and with not opinions to the = contrary. Valery and I thought we=E2=80=99d make this change over the = weekend.

Yoav

= --Apple-Mail=_D5BB28FB-CCDA-4683-8D57-855E7512E5AB-- From nobody Thu Feb 25 21:50:11 2016 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 58E3A1A6F5A for ; Thu, 25 Feb 2016 21:50:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.229 X-Spam-Level: X-Spam-Status: No, score=-1.229 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, 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 SXgEWmZZhxqn for ; Thu, 25 Feb 2016 21:50:08 -0800 (PST) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8C8F91A21A4 for ; Thu, 25 Feb 2016 21:50:07 -0800 (PST) Received: by mail-lf0-x235.google.com with SMTP id l143so46889920lfe.2 for ; Thu, 25 Feb 2016 21:50:07 -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; bh=Ab/IbHQPQL9vUqs6wHO8cltFVxZjAE4FBP5+KoXitkk=; b=SwN2x0x1t/g/nZSSfTRYbZjCG4TKiZmoW93TCSy0CQfeax6T76HVGThxekMOHmKTUT UOxRk4ERzCRNbr9SOTgXfMdnEbyDrKV0zEpQzkGSmNdiTvN8b04svmhmAzsRId5AuqX5 DFjA9yYeWRfyPGfKYlx+SMFBZI/XmWvxyy1iRbuZ2ajm7zeIhofTMHFgnxaQobgPXevd eqKzMBeLm8FhyH6z6LgzvdqFJVrYVDC6sXvfvwhAeMdYbY46+D1GCQpnQu2vSgaJKU+o 4eCP27zLgVlT5qCEW6Fj4IEVez2czflvHWCU7rjmumqaYE5e3qKU/i116lDiES1kBEx5 BWsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-type; bh=Ab/IbHQPQL9vUqs6wHO8cltFVxZjAE4FBP5+KoXitkk=; b=WJXV8+Xw26wOMBFl9OX2PlxtJ7SVKGvkRfjRO9gph5e7hXo1cJEKCYDahKBXkOkwYJ 8O5xAwf+/Sr/2hzVjePCvtdl2/q3xloQFINzZyf+AB3MjZMCywh1IpljKadOZlN5RggF Yfe8AaUkJJ5uqdetDVkn3V2fTQVbN9/ZcTZBA4DmuTnGNd9WgZh4st/yltbdP5wjvhD5 CDptDqfc9hoQoV1P6tVbDsDr8vmYANXmsR7/0ttrxbBNNySqNE7UkGASM9IYzZ45jv30 ZfTIQNwoPYm2hCvHVPQwiLihP+kMnfqHXOCP+o7bOZNWr4pkr3kqSpcitlnblIqQJ8qn MMow== X-Gm-Message-State: AG10YOSdnnOmAtoSfQKT5Zh0x4ZxIy68/USr+R0brqYtTFn01dO5DdHekbSypbs4bA0eeQ== X-Received: by 10.25.80.6 with SMTP id e6mr18852983lfb.91.1456465805826; Thu, 25 Feb 2016 21:50:05 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id vq10sm1574522lbb.14.2016.02.25.21.50.04 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 25 Feb 2016 21:50:04 -0800 (PST) Message-ID: <70EEDD2843564D589DCE9E96C84CB236@buildpc> From: "Valery Smyslov" To: "Yoav Nir" , "Waltermire, David A." References: <9DC60612-D5BC-4D55-8364-90DA5CAEB41F@gmail.com> <7480BF86-4EAD-4651-97B5-3B318FA010BA@gmail.com> Date: Fri, 26 Feb 2016 08:50:08 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0416_01D17072.B1ADE000" 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: Cc: ipsec@ietf.org Subject: Re: [IPsec] Textual changes to the DDoS draft 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, 26 Feb 2016 05:50:09 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0416_01D17072.B1ADE000 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable That was also my impression. And the draft is already being edited to = include multiple puzzles. Valery. ----- Original Message -----=20 From: Yoav Nir=20 To: Waltermire, David A.=20 Cc: ipsec@ietf.org WG=20 Sent: Friday, February 26, 2016 8:43 AM Subject: Re: [IPsec] Textual changes to the DDoS draft On 26 Feb 2016, at 2:03 AM, Waltermire, David A. = wrote: I haven=E2=80=99t seen any additional feedback on the DDoS draft = this week based on Yoav=E2=80=99s note about the PR [1]. It also looks = like the discussion on chaining puzzles has wrapped up with no changes = needed to the draft [2]. Oh. My impression of [2] was that Valery and I were in agreement that = this change was a good idea, with Scott and Yaron supporting (not quite = as enthusiastically) and with not opinions to the contrary. Valery and I = thought we=E2=80=99d make this change over the weekend. Yoav -------------------------------------------------------------------------= ----- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0416_01D17072.B1ADE000 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
That was also my impression. And the draft is = already being=20 edited to include multiple puzzles.
 
Valery.
----- Original Message -----
From:=20 Yoav Nir=20
Sent: Friday, February 26, 2016 = 8:43=20 AM
Subject: Re: [IPsec] Textual = changes to=20 the DDoS draft


On 26 Feb 2016, at 2:03 AM, Waltermire, David A. <david.waltermire@nist.gov&g= t;=20 wrote:

I=20 haven=E2=80=99t seen any additional feedback on the DDoS draft this = week based on=20 Yoav=E2=80=99s note about the PR [1]. It also looks like the = discussion on chaining=20 puzzles has wrapped up with no changes needed to the draft=20 [2].

Oh. My impression of [2] was that Valery and I = were in=20 agreement that this change was a good idea, with Scott and Yaron = supporting=20 (not quite as enthusiastically) and with not opinions to the contrary. = Valery=20 and I thought we=E2=80=99d make this change over the weekend.

Yoav

_______________________________________________
IPsec = mailing=20 = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
= ------=_NextPart_000_0416_01D17072.B1ADE000-- From nobody Fri Feb 26 02:15:11 2016 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 35C531A700B for ; Fri, 26 Feb 2016 02:15:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.521 X-Spam-Level: X-Spam-Status: No, score=-0.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RX7gySFpTlSg for ; Fri, 26 Feb 2016 02:15:08 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 C2C491A700A for ; Fri, 26 Feb 2016 02:15:06 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u1QAEubC002092 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 26 Feb 2016 12:14:56 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u1QAEuMw020163; Fri, 26 Feb 2016 12:14:56 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22224.9632.764980.200971@fireball.acr.fi> Date: Fri, 26 Feb 2016 12:14:56 +0200 From: Tero Kivinen To: "Valery Smyslov" In-Reply-To: <3D2B82DD711945AE8757ED0CE7E041E9@buildpc> References: <46cc66173e324ae0b788f36cd58f5dfa@XCH-RCD-006.cisco.com> <22220.36465.788794.855413@fireball.acr.fi> <22222.1834.892900.623823@fireball.acr.fi> <3C4D164CF08843258CE30B5B21363397@buildpc> <22222.63205.854356.14024@fireball.acr.fi> <3D2B82DD711945AE8757ED0CE7E041E9@buildpc> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 7 min X-Total-Time: 7 min Archived-At: Cc: ipsec@ietf.org, "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01 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, 26 Feb 2016 10:15:10 -0000 Valery Smyslov writes: > > Which has nothing to do with this discussion, as G-IKEv2 is not IKEv2, > > nor it is work that is done in the IPsecME Wg at all. There used to be > > separate working group (Msec) working on those protocols, and their > > protocols were based on the IKE, but not really IKE. If they want to > > use things we define here they need to incorporate them to their > > protocols separately. > > We disagree on this. I think that if some solution can be re-used in > a similar protocol, then it saves a lot of unnecessary work. > G-IKEv2 is based on IKEv2 and they are very similar. Not only framing, > but also the core crypto formulas are the same. But as you pointed out key distribution and generation are not same. Yes, the method we define here should be easily re-used in there, but it still do require some work, and that is something thta the G-IKEv2 people needs to do. > >> Please, re-read the draft. In the last version it is not tied with any > >> particular algorithms (AES, SHA256) and uses the negotiated > >> PRF for SKEYSEED calculation. > > > > From the draft: > > > > ... > > The PPK Indicator Algorithm is a 4 byte word that states which PPK > > indicator to use. That is, it gives the encoding format for the PPK > > that should be used is given to the responder. At present, the only > > assigned encoding is 0x00000001, which indicates that AES256_SHA256 > > will be used (as explained below). > > ... > > This text is not concerned with SKEYSEED calculation, where the negotiated > PRF is used. True, but unless you do that you never get to the SKEYSEED calculation, so the above system is needed, to know which PPK is to be used and this is the complication caused by the fact that SK_e depends on the PPK. Of course you can do the same stupid thing that was done on IKEv1, and say that you just use the source IP-address and fetch PPK based on that, but that method simply does not work well. > > That is actual real reason to do things differently. I.e. perhaps the > > KEYMAT generation then should be > > > > KEYMAT = prf+(SK_d, g^ir (new) | prf(PPK, Ni) | prf(PPK, Nr)) > > > > instead? > > That's exactly how PPK is used in the draft (except that > it is used there for SKEYSEED calculation). And because it is used in the SKEYSEED it means we need to know which PPK is used BEFORE we can decrypt IKE_AUTH, which means that we cannot use identity to pick it. And because of that we need to make complicated method of telling which PPK is used in the IKE_SA_INIT using fixed ciphers that are not implemented on all devices (for example IoT). All this limits the use of this quite a much, which mostly makes this only usable in special cases. I instead want to get good enough protection for current IKEv2 which is very widely usable even when it does leak out identities, traffic selectors and configuration payloads to attacker who can break Diffie-Hellman (or anybody who is willing to do active attack). -- kivinen@iki.fi From nobody Fri Feb 26 03:11:48 2016 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 916561AD36F for ; Fri, 26 Feb 2016 03:11:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IuZ4HlbkCHvU for ; Fri, 26 Feb 2016 03:11:45 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 F13F71AD28D for ; Fri, 26 Feb 2016 03:11:41 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u1QBBXsr007105 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 26 Feb 2016 13:11:33 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u1QBBWMo010276; Fri, 26 Feb 2016 13:11:32 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22224.13028.187502.196480@fireball.acr.fi> Date: Fri, 26 Feb 2016 13:11:32 +0200 From: Tero Kivinen To: Paul Wouters In-Reply-To: References: <22223.2866.976241.499754@fireball.acr.fi> <22223.5419.528391.85358@fireball.acr.fi> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 18 min Archived-At: Cc: ipsec@ietf.org, frederic.firmin@etsi.org Subject: Re: [IPsec] IANA allocation of TIMEOUT_PERIOD_FOR_LIVENESS_CHECK 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, 26 Feb 2016 11:11:46 -0000 Paul Wouters writes: > On Thu, 25 Feb 2016, Tero Kivinen wrote: > > > It is notify from the server to client. I.e. client sends empty > > TIMEOUT_PERIOD_FOR_LIVENESS_CHECK in the CFG_REQUEST and server will > > send value in seconds inside its TIMEOUT_PERIOD_FOR_LIVENESS_CHECK in > > CFG_REPLY. I.e. the server asks client to use following livenss > > timeout period. > > Ok, then it should use NOTIFY and not CP. That is my understanding too, but I do not really think this issue is big enough to require them to change their document, i.e., not to approve their IANA allocation request. > > If we could even get few paragraph explanation that would be really > > good, thats why I said it would be nice if 3gpp people would run their > > additions through this list before writing it in their draft. > > > > Now I have to check that 116 page document and find out what it is > > supposed to do :-) > > So this is a real problem. If we (implementors) want to implement these > IKEv2 extensions, we need to have clear proper RFC's. I do not want to > find 116 pages on third party websites (that may or may not be behind > a registration or pay wall) Most of that 116 pages is not related to the IKEv2 extensions, there is perhaps few tens of pages of IKEv2 related things in there. The documents can be downloaded from their web page, and as they do cover the 3gpp Evolved Packet Core (EPC) issues, I do not think they need to be RFCs. This is the reason why the IANA registries for IKEv2 are not RFC required... Anyways making suggestions like in the beginning of this email (i.e. use notify instead of configuration payload) is something that would be good to do before people define extensions to the IKEv2, and thats why I do encourage people to at least tell what they are doing, and why and how in the ipsec list while making the protocol, so we can give them hints and feedback how to do it properly. -- kivinen@iki.fi From nobody Fri Feb 26 03:24:39 2016 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 6D6BA1B29C4 for ; Fri, 26 Feb 2016 03:24:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GzAsuDUosCZq for ; Fri, 26 Feb 2016 03:24:36 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 5840A1B29B0 for ; Fri, 26 Feb 2016 03:24:36 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u1QBOEBQ006968 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 26 Feb 2016 13:24:14 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u1QBOEP2009928; Fri, 26 Feb 2016 13:24:14 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22224.13789.927759.77718@fireball.acr.fi> Date: Fri, 26 Feb 2016 13:24:13 +0200 From: Tero Kivinen To: Ivo Sedlacek In-Reply-To: <39B5E4D390E9BD4890E2B31079006101162DAD5D@ESESSMB301.ericsson.se> References: <22223.2866.976241.499754@fireball.acr.fi> <22223.5419.528391.85358@fireball.acr.fi> <39B5E4D390E9BD4890E2B31079006101162DAD5D@ESESSMB301.ericsson.se> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 9 min X-Total-Time: 9 min Archived-At: Cc: "ipsec@ietf.org" , "frederic.firmin@etsi.org" , Paul Wouters Subject: Re: [IPsec] IANA allocation of TIMEOUT_PERIOD_FOR_LIVENESS_CHECK 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, 26 Feb 2016 11:24:38 -0000 Ivo Sedlacek writes: > 3GPP spec expects that if the client (User Equipment) supports the > TIMEOUT_PERIOD_FOR_LIVENESS_CHECK configuration attribute, then the client > (User Equipment) *enforces* the timer value indicated in the > TIMEOUT_PERIOD_FOR_LIVENESS_CHECK configuration attribute in CFG_REPLY sent by > server (Evolved Packet Data Gateway). > > I.e. it is an intruction, not a suggestion. Yes, but there is nothing there to say what the server will do if the UE misbehavies. I.e. if the UE simply ignores the timeout period it received and instead of the server requested 300 seconds uses 30 seconds for the timeout period. Is the server going to detect this? Is the server going to kick the UE out because it misbehaves and sends liveness checks too often? On the other hand IKEv2 RFC also allows sending liveness checks at any time when client thinks there might be issues (for example it receives ICMP message), so server cannot kick UE out just because it does liveness checks too often. On the other hand if server asks for 30 seconds, and UE uses 300 seconds, is the server going to assume that UE is dead as it didn't send liveness check in last 30 seconds? Is it going to free the resources of the UE after some amount of time when it should have received liveness check etc. So as there is no server side behavior described in the 3gpp EPC specification, this is more like suggestion than actual requirement. It is similar than laws we have where you must do something, but even if you do not there is no penalty, i.e. it is unenforceable law. Of course in most cases the UE will follow the liveness check timeout period requested by the EPC, as it does not have any reason not to, but UE might still want to have some limits for those, i.e. even if the server asks liveness checks every second, it might be good idea to make the lower limit to something like 30 seconds... -- kivinen@iki.fi From nobody Fri Feb 26 03:49:16 2016 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 8FEDB1B2A65 for ; Fri, 26 Feb 2016 03:49:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.521 X-Spam-Level: X-Spam-Status: No, score=-0.521 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_12=0.6, SPF_NEUTRAL=0.779] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXQfPNc_HGG6 for ; Fri, 26 Feb 2016 03:49:14 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) (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 4A4F61B2A64 for ; Fri, 26 Feb 2016 03:49:14 -0800 (PST) Received: from fireball.acr.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.15.2/8.14.8) with ESMTPS id u1QBn5t6011426 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 26 Feb 2016 13:49:05 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.15.2/8.14.8/Submit) id u1QBn5UC028297; Fri, 26 Feb 2016 13:49:05 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <22224.15281.370570.680804@fireball.acr.fi> Date: Fri, 26 Feb 2016 13:49:05 +0200 From: Tero Kivinen To: "Scott Fluhrer \(sfluhrer\)" In-Reply-To: References: <46cc66173e324ae0b788f36cd58f5dfa@XCH-RCD-006.cisco.com> <22220.36465.788794.855413@fireball.acr.fi> <22222.1834.892900.623823@fireball.acr.fi> <3C4D164CF08843258CE30B5B21363397@buildpc> <22222.63205.854356.14024@fireball.acr.fi> X-Mailer: VM 8.2.0b under 24.5.1 (x86_64--netbsd) X-Edit-Time: 3 min X-Total-Time: 2 min Archived-At: Cc: "ipsec@ietf.org" , Valery Smyslov Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01 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, 26 Feb 2016 11:49:15 -0000 Scott Fluhrer (sfluhrer) writes: > > That is actual real reason to do things differently. I.e. perhaps the KEYMAT > > generation then should be > > > > KEYMAT = prf+(SK_d, g^ir (new) | prf(PPK, Ni) | prf(PPK, Nr)) > > > > instead? > > That would certainly be a more implementable suggestion, if the WG > is OK with the idea that the IKE SAs not being protected. It would > make like living with an HSM easier to deal with, while making the > process of deciding which PPK to use simpler. We may end up > including a simple notification scheme (to help with a brownfield > scenario, where the peer may or may not be upgraded to use PPK yet), > but we might also decide to omit that as well. > > So, is the protection of the IKE SA important? I would personally > vote that it is, but if the WG decides otherwise, then this is > clearly a better proposal. I agree that having protection of the IKE SA would be nice to have, but I am scared that the complication of deciding which PPK to use will cause issues, and not protecting IKE SA is good compromize, i.e. provides the most important thing (protectiong to the actual IPsec traffic against the QC attacks), while still being so easy to implement and use that everybody can start using it (even the smallest IoT device can do this provided it has PPK somehow available). -- kivinen@iki.fi From nobody Fri Feb 26 04:28:05 2016 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 79E951A1A12 for ; Fri, 26 Feb 2016 04:28:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.201 X-Spam-Level: X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y4RtFhq7Lbj0 for ; Fri, 26 Feb 2016 04:27:59 -0800 (PST) Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E69291A0BE8 for ; Fri, 26 Feb 2016 04:27:58 -0800 (PST) X-AuditID: c1b4fb3a-f79ce6d000005138-10-56d044cc4527 Received: from ESESSHC010.ericsson.se (Unknown_Domain [153.88.183.48]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id BC.63.20792.CC440D65; Fri, 26 Feb 2016 13:27:57 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.190]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.03.0248.002; Fri, 26 Feb 2016 13:27:56 +0100 From: Ivo Sedlacek To: Tero Kivinen Thread-Topic: [IPsec] IANA allocation of TIMEOUT_PERIOD_FOR_LIVENESS_CHECK Thread-Index: AQHRb9ZEmL69MYW+c0mrQROWP3qUUJ88wFQAgAAHhYCAABbGAIABQWGAgAAa31A= Date: Fri, 26 Feb 2016 12:27:56 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101162DBB11@ESESSMB301.ericsson.se> References: <22223.2866.976241.499754@fireball.acr.fi> <22223.5419.528391.85358@fireball.acr.fi> <39B5E4D390E9BD4890E2B31079006101162DAD5D@ESESSMB301.ericsson.se> <22224.13789.927759.77718@fireball.acr.fi> In-Reply-To: <22224.13789.927759.77718@fireball.acr.fi> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprDIsWRmVeSWpSXmKPExsUyM2K7ge5ZlwthBmdncVk0brnMbrF/yws2 i6Pnn7NZvL91icmBxePT0ulMHkuW/GTyOPx1IYvH93lMASxRXDYpqTmZZalF+nYJXBmn7zWy FZyQqTiy7xhjA+NE8S5GTg4JAROJFWs3MkLYYhIX7q1nA7GFBA4zSlxa5tnFyAVkL2GUaN32 GayITUBPYuKWI6wgtoiAosTuJ1uZQGxmgVqJpdfXgtnCAp4S078+Z4Oo8ZLYcLOBGcL2k7jT PQvMZhFQldi36wWYzSvgK3Fx4iJWiGWdTBIP5lwFW8ApYC7xpuEV2CBGAVmJq396GSGWiUvc ejKfCeJqAYkle84zQ9iiEi8f/2OFsBUlPr7aB1WvI7Fg9yc2CFtbYtnC11CLBSVOznzCMoFR bBaSsbOQtMxC0jILScsCRpZVjKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIFxdnDLb6sdjAef Ox5iFOBgVOLh/fD9fJgQa2JZcWXuIUYJDmYlEd652hfChHhTEiurUovy44tKc1KLDzFKc7Ao ifOucV4fJiSQnliSmp2aWpBaBJNl4uCUamBMZPerTuFnm/7VaOfko4InzXOXCIVyqjFv4in0 13x/d/Yb8WA+m0NvHOSDLW9aPSn+ry123vrHJMmDl6Va/x41v7zuannAuvYClTfP+0+f/y72 Ss1A7LTuxmlNjU7OUWGLl/edL8xcxjazp/3b9/hT3M8Czcor2zp2LVowqTUs7d/TxbdrJsoq sRRnJBpqMRcVJwIAsjsKtq8CAAA= Archived-At: Cc: "ipsec@ietf.org" , "frederic.firmin@etsi.org" , Paul Wouters Subject: Re: [IPsec] IANA allocation of TIMEOUT_PERIOD_FOR_LIVENESS_CHECK 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, 26 Feb 2016 12:28:02 -0000 Hello, 3GPP mostly focuses on specifying the correct behaviour of nodes, on defini= ng compliance test cases and relying on vendor's declaration of compliance = to the test cases. I agree that it is possible that a UE (client) can misbehave as you stated = below but so far none reported this yet. So, there was no need to specify n= etwork countermeasures in 3GPP. IMO (and this is really my speculation only as 3GPP does not say anything o= n this), if misbehaving UEs (clients) appear: - the ePDG (server) could detect the misbehaving UE (client) since ePDG (se= rver) can measure frequency of reception of the INFORMATIONAL requests with= out payloads. If this is a constant pattern, the operator can request vendo= r of the UE (client) to update firmware/software of the misbehaving UEs (cl= ients). - under normal circumstances, I would not expect ePDG (server) to kick misb= ehaving UEs (clients). - if the ePDG (server) is overloaded with a lot of INFORMATIONAL requests w= ithout payloads, and needs to reduce the load then perhaps ePDG (server) co= uld consider whether the UE (client) sends too frequent INFORMATION request= s when reducing the load by kicking some UEs (clients) out. In any case, the above is just internal ePDG (server) handling and can be d= eployed without further standardization. Kind regards Ivo Sedlacek -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi]=20 Sent: Friday, February 26, 2016 12:24 PM To: Ivo Sedlacek Cc: Paul Wouters; ipsec@ietf.org; frederic.firmin@etsi.org Subject: Re: [IPsec] IANA allocation of TIMEOUT_PERIOD_FOR_LIVENESS_CHECK Ivo Sedlacek writes: > 3GPP spec expects that if the client (User Equipment) supports the=20 > TIMEOUT_PERIOD_FOR_LIVENESS_CHECK configuration attribute, then the=20 > client (User Equipment) *enforces* the timer value indicated in the=20 > TIMEOUT_PERIOD_FOR_LIVENESS_CHECK configuration attribute in CFG_REPLY=20 > sent by server (Evolved Packet Data Gateway). >=20 > I.e. it is an intruction, not a suggestion. Yes, but there is nothing there to say what the server will do if the UE mi= sbehavies. I.e. if the UE simply ignores the timeout period it received and= instead of the server requested 300 seconds uses 30 seconds for the timeou= t period. Is the server going to detect this? Is the server going to kick the UE out = because it misbehaves and sends liveness checks too often? On the other han= d IKEv2 RFC also allows sending liveness checks at any time when client thi= nks there might be issues (for example it receives ICMP message), so server= cannot kick UE out just because it does liveness checks too often.=20 On the other hand if server asks for 30 seconds, and UE uses 300 seconds, i= s the server going to assume that UE is dead as it didn't send liveness che= ck in last 30 seconds? Is it going to free the resources of the UE after so= me amount of time when it should have received liveness check etc. So as there is no server side behavior described in the 3gpp EPC specificat= ion, this is more like suggestion than actual requirement. It is similar than laws we have where you must do something, but even if yo= u do not there is no penalty, i.e. it is unenforceable law. Of course in most cases the UE will follow the liveness check timeout perio= d requested by the EPC, as it does not have any reason not to, but UE might= still want to have some limits for those, i.e. even if the server asks liv= eness checks every second, it might be good idea to make the lower limit to= something like 30 seconds...=20 -- kivinen@iki.fi From nobody Fri Feb 26 05:00:45 2016 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 26DAC1A8AE2 for ; Fri, 26 Feb 2016 05:00:44 -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 TP2LQXBc10mp for ; Fri, 26 Feb 2016 05:00:43 -0800 (PST) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 969D71A8AE7 for ; Fri, 26 Feb 2016 05:00:42 -0800 (PST) Received: by mail-lf0-x22b.google.com with SMTP id m1so52990444lfg.0 for ; Fri, 26 Feb 2016 05:00:42 -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-transfer-encoding; bh=8EV7b/IQR1nTcDAgvbzcts969k1yiBNRwMN7qQQmxMg=; b=ijG00DuHb6yT7ykmropzAjzpOvWyJZ/Dk5ZEtLi8aRUiYwrB2BjTrCfsFx5LHqHjsq /untI4rR6Kc7lCdk2osp+dCClccywDQT0F2HdmsfaZ9sknYH5c7zk/GZmt5ftr/YlHCk s7bqkx18tnmDb/Jotw97fKK9FwHYwq4WK3joTWZV8jKywoBQfd3FITMOkJik7SWm6e8C YWN7UUIgcBHe7WKm5bo39GZFDWDnRMnz6PS7UyOasRErhwam0E8UVXjQheKI/Wqj0paj 6rzs2y6HmV24dUVje4OhdRuKpev3u1ciUXxyZU9P1YNZOo3rPZ4W++pKbOww61Lj6pDD DmAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=8EV7b/IQR1nTcDAgvbzcts969k1yiBNRwMN7qQQmxMg=; b=JLvXLduyj8wyT+yOFjCUsdFypQ8DXXgoaWEH715ekg1SvUvNMxGw45MFWkDt0iJPxt 4AnDHyKsYCEYUVCXCDJV4RN7nGElQ7mIS2V4sQo5AoJap+gZZfZwDIR/3bmi4fdT1741 STOR+QdDMe/KOuoOLkuiySa9UovVjwFNARDVN6xTmU7oREmkJmg+MugaQ0ojHr3ArACA DwnqROYtXTigmRob9l9Jt66oKXQxK5jCLaK7divY48+y1rCTEvzYXxQi6p7Uh3gUtXtA ERp+kjcYQ5ACuwvdJRF9J2nMarMJkW42zoN337zWD909OqtAriBIbwBLBEm8dWbFGbVT 2UEg== X-Gm-Message-State: AD7BkJICG1layDCS5oSSD0N2+ClPvBu/IcPqmruvlAsf4rfusRMljCXBYZBA7DPCi6nP5Q== X-Received: by 10.25.161.131 with SMTP id k125mr582689lfe.83.1456491640699; Fri, 26 Feb 2016 05:00:40 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id nv8sm1806272lbb.7.2016.02.26.05.00.39 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Feb 2016 05:00:39 -0800 (PST) Message-ID: <0EE04509DF854D45B113D3E0ADEDD048@buildpc> From: "Valery Smyslov" To: "Tero Kivinen" References: <46cc66173e324ae0b788f36cd58f5dfa@XCH-RCD-006.cisco.com><22220.36465.788794.855413@fireball.acr.fi><22222.1834.892900.623823@fireball.acr.fi><3C4D164CF08843258CE30B5B21363397@buildpc><22222.63205.854356.14024@fireball.acr.fi><3D2B82DD711945AE8757ED0CE7E041E9@buildpc> <22224.9632.764980.200971@fireball.acr.fi> Date: Fri, 26 Feb 2016 16:00:40 +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: Cc: ipsec@ietf.org, "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01 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, 26 Feb 2016 13:00:44 -0000 >> We disagree on this. I think that if some solution can be re-used in >> a similar protocol, then it saves a lot of unnecessary work. >> G-IKEv2 is based on IKEv2 and they are very similar. Not only framing, >> but also the core crypto formulas are the same. > > But as you pointed out key distribution and generation are not same. > Yes, the method we define here should be easily re-used in there, but > it still do require some work, and that is something thta the G-IKEv2 > people needs to do. As far as I understand, the method from the draft can be reused in G-IKEv2 as-is. And if we choose not to protect IKE SA, then they will need to reinvent the wheel. > And because it is used in the SKEYSEED it means we need to know which > PPK is used BEFORE we can decrypt IKE_AUTH, which means that we cannot > use identity to pick it. And because of that we need to make > complicated method of telling which PPK is used in the IKE_SA_INIT > using fixed ciphers that are not implemented on all devices (for > example IoT). The ciphers are not really fixed. There is a kind of negotiation during cookie exchanhe. Abd the draft can be easily modified to re-use existing IKEv2 registries for the crypto primitives - see https://mailarchive.ietf.org/arch/msg/ipsec/r4I5SCIEt4BmXsROCDXZXTbVuIc The support for the cookie exchange is mandatory in the IKEv2, adding a couple notification to it doesn't add much complexity. Regards, Valery. From nobody Fri Feb 26 05:14:56 2016 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 C0AFF1A8AEA for ; Fri, 26 Feb 2016 05:14:55 -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 Nf5-EO_pa56D for ; Fri, 26 Feb 2016 05:14:55 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 905F01A8AE7 for ; Fri, 26 Feb 2016 05:14:54 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id j78so53016990lfb.1 for ; Fri, 26 Feb 2016 05:14:54 -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-transfer-encoding; bh=KkntcabndnlowR/tbKfXnXB4Be5kItNt/MIeIPXXxR4=; b=LJfLB78xhqrsjv6kBJ+406L2KkiaPsngarJ6ww/PODm9SESPAJ6zgv+D7sWE0naKUY V39204KGeiYbAWPuj7gWs//8TIlA93wcuAkV4NALZWSteGFqARsJrYaUXqF8PYDNR4jU bL+oNWRAn1TFS764lrSi2jzMQ7dDBIydqKpHJPsVpHRDPAPQOKzmFzetL44tmhpQUvw+ txouK9A2VpYBgVhoYewvoY8e+LVVkfpbOmksbLxbSKOh8LaIe5VJ9lB2L7o/23FAfQ8t tdBRoe9YxXuo88XPF2VMRZtNq8ekITCtWAE2d9z8isInEAhB/3JdksUfcADzzjAeEmB3 O8Mg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=KkntcabndnlowR/tbKfXnXB4Be5kItNt/MIeIPXXxR4=; b=DRNwm+jGkLGaWseO39bLHk0lDS/KEK7OTmj51F3e+wCjlW/CogoLocFc+Vcx1zUazh VGv/KUXf0+dJGpiWpQyaoyQDcvYzxi5fJtkvs8cExpwxSNXWeLgX6CQ3r0akcaIwh2yL f8S1ogSRAJD35AkDDhuYvx5ek6qLHWg8w22Ql/Kmzn5yQl2MqvwsXhXyw7v8dLPudp+i MEI2s1k++tHPqFtCeOU5K+gZHji+Nc5W6jGCmiOGJzqQFKpk5kq2bQkeQe5KxX9yDiKG bqRuUVPt8ekQzA/coSNAYt/OWTS3JUERq/3o0xt5RR5XfB9G/VVTGbpsYIEniAVEenYf fp/g== X-Gm-Message-State: AD7BkJIB+BL29WyV0TTM33AWkT2oed/tnK5LlRlEqKVOgEZ6pOz3eBZH3ZU0HKVpWEqMSg== X-Received: by 10.25.157.79 with SMTP id g76mr654097lfe.93.1456492492815; Fri, 26 Feb 2016 05:14:52 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id 88sm1878965lfr.44.2016.02.26.05.14.51 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Feb 2016 05:14:51 -0800 (PST) Message-ID: <7C69D4636A2541A686420EE56831F10B@buildpc> From: "Valery Smyslov" To: "Scott Fluhrer \(sfluhrer\)" , "Tero Kivinen" References: <46cc66173e324ae0b788f36cd58f5dfa@XCH-RCD-006.cisco.com><22220.36465.788794.855413@fireball.acr.fi><22222.1834.892900.623823@fireball.acr.fi><3C4D164CF08843258CE30B5B21363397@buildpc> <22222.63205.854356.14024@fireball.acr.fi> Date: Fri, 26 Feb 2016 16:14:55 +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: Cc: ipsec@ietf.org Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01 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, 26 Feb 2016 13:14:55 -0000 > That would certainly be a more implementable suggestion, if the WG is OK with the idea > that the IKE SAs not being protected. It would make like living with an HSM easier to deal with, > while making the process of deciding which PPK to use simpler. We may end up including a simple > notification scheme (to help with a brownfield scenario, where the peer may or may not be upgraded > to use PPK yet), but we might also decide to omit that as well. > > So, is the protection of the IKE SA important? I would personally vote that it is, > but if the WG decides otherwise, then this is clearly a better proposal. I think that the protection of IKE SA is important. This would preserve IKEv2 security properties (like protecting identities against passive attacker) and would allow to re-use the solution in G-IKEv2 and other IKEv2 derivations that do transfer sensitive information within IKE SA. Otherwise we'll end up with a solution that is very limited to use while still sustantially modifying the IKEv2 (for example core crypto calculations must be changed in any case). Regards, Valery. From nobody Fri Feb 26 05:26:55 2016 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 4B5F51ACE6B for ; Fri, 26 Feb 2016 05:26:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.229 X-Spam-Level: X-Spam-Status: No, score=-1.229 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, 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 lAkGJsWrB4MO for ; Fri, 26 Feb 2016 05:26:50 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BC28A1AC3BA for ; Fri, 26 Feb 2016 05:26:49 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id l83so6145482lfd.3 for ; Fri, 26 Feb 2016 05:26:49 -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; bh=6lslyDEn972Td2EX6sCp5/GQ7ZcsCJ7+iCjm7Skxt8s=; b=fo0pF+w2R+hqhL5Kwx+R+MPf8xC5nwtiGJiR2l5VHdA0wlzz+VxOvhCX3wMOjwjmO7 OuPu8jA9/TjMZD4Sua0N30n9LVFFc4VjdFyhfR0wpMr0No1ov1PZuWhZtv6uhiqOT0L3 mQVSaqLH9nTezZW0I6Z34Q3roUxmnVzlgG3u89dZ9YcvYHF3HZWnbPivUEhtPHV+mf5z gxpxEdDeU+3yqE4crbQMztsGQ1O+6JprV17EqNgOivL5mq8r2l4e7kcYCJU6tA7c6upk v4q6hjo5XG2fsGmjYrx8MIMyzl1j4egypixarPC8rEA7vID5JWmqQgGFkKrH5Ymy262q 68ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version; bh=6lslyDEn972Td2EX6sCp5/GQ7ZcsCJ7+iCjm7Skxt8s=; b=EfQNoaOSh6V0BYPI/OgdVbfCimUxHYV5O2uTTKHyGqW/SNV/gfguSDrGK/3ebC0iO0 jFYWSyjm0w2vgHlnpThbUKX0IZJo1Hjn1iPFKM2OBB2DM82uFYnG6qYY6aROrUgJWQvP L3Du6RKqDBCk7vi3VIaAWpKbE/kmaAFg/CHmLLS+W2WH7AIDzkhyqJd2zwBWjalm4+i1 1z++EgJPFiMoLbqPzLLDkgIeoXVjdPmXxTob0rGtYxIZwbP1UxQS7H7FjCXQ9afdFd3E caygU4AUIvQW23KE779BRJiKDLZecafNAlVOtOFwTYHmV0JVvm1InjfZVjFfs+haH29B Kjrw== X-Gm-Message-State: AD7BkJIa7uXd9nk+3zqHgyKaFh5lJ6A6LDQNMwadLS3yJm5S1X7s2ZJKpMzcIuKNa/fj5A== X-Received: by 10.25.22.214 with SMTP id 83mr642632lfw.2.1456493207905; Fri, 26 Feb 2016 05:26:47 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id 84sm1826500lfp.17.2016.02.26.05.26.46 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Feb 2016 05:26:46 -0800 (PST) Message-ID: <70D0144557154722A10599DAD6742F8C@buildpc> From: "Valery Smyslov" To: "Ivo Sedlacek" , "Tero Kivinen" , "Paul Wouters" References: <22223.2866.976241.499754@fireball.acr.fi> <22223.5419.528391.85358@fireball.acr.fi> <39B5E4D390E9BD4890E2B31079006101162DAD5D@ESESSMB301.ericsson.se> Date: Fri, 26 Feb 2016 16:26:50 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_04BD_01D170B2.7E9BE2D0" 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: Cc: ipsec@ietf.org, frederic.firmin@etsi.org Subject: Re: [IPsec] IANA allocation of TIMEOUT_PERIOD_FOR_LIVENESS_CHECK 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, 26 Feb 2016 13:26:53 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_04BD_01D170B2.7E9BE2D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Ivo, thank you for providing more details.=20 However, it is not clear from this description what UE should do if it = has a data to be sent, but it received no protected data for some perion of time. Section 2.4. = of RFC 7296 suggests that=20 the IKEv2 implementation performs a Liveness Check in this case: If no cryptographically protected messages have been received on an IKE SA or any of its Child SAs recently, the system needs to perform a liveness check in order to prevent sending messages to a dead peer. It is not clear how this text is supposed to align with = TIMEOUT_PERIOD_FOR_LIVENESS_CHECK. In other words - should UE in this situation perform a Liveness Check, = ignoring=20 the ePDG provided interval? Or should it ignore the possibility to send=20 data to a dead peer and perform Liveness Checks only on the specified = interval? Regards, Valery Smyslov. ----- Original Message -----=20 From: Ivo Sedlacek=20 To: Tero Kivinen ; Paul Wouters=20 Cc: ipsec@ietf.org ; frederic.firmin@etsi.org=20 Sent: Thursday, February 25, 2016 6:58 PM Subject: Re: [IPsec] IANA allocation of = TIMEOUT_PERIOD_FOR_LIVENESS_CHECK Hello, =20 In case you are interested in detailed procedures of the 3GPP = specification, I have copied them at the end of this mail. =20 > > I am confused. Is this a notify of the server to the client, or a=20 > > configuration item by the server instructing client behaviour? >=20 > It is notify from the server to client. I.e. client sends empty = TIMEOUT_PERIOD_FOR_LIVENESS_CHECK in the CFG_REQUEST and=20 > server will send value in seconds inside its = TIMEOUT_PERIOD_FOR_LIVENESS_CHECK in CFG_REPLY. I.e. the server asks = client=20 > to use following livenss timeout period.=20 =20 3GPP spec expects that if the client (User Equipment) supports the = TIMEOUT_PERIOD_FOR_LIVENESS_CHECK configuration attribute, then the = client (User Equipment) *enforces* the timer value indicated in the = TIMEOUT_PERIOD_FOR_LIVENESS_CHECK configuration attribute in CFG_REPLY = sent by server (Evolved Packet Data Gateway). =20 I.e. it is an intruction, not a suggestion. =20 It is supposed to work as follows: =20 first request --> IDi, [N(INITIAL_CONTACT)], [[N(HTTP_CERT_LOOKUP_SUPPORTED)], = CERTREQ+], [IDr], [CP(CFG_REQUEST = (*TIMEOUT_PERIOD_FOR_LIVENESS_CHECK with empty value*) )], [N(IPCOMP_SUPPORTED)+], [N(USE_TRANSPORT_MODE)], [N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(NON_FIRST_FRAGMENTS_ALSO)], SA, TSi, TSr, [V+][N+] =20 first response <-- IDr, [CERT+], AUTH, EAP, [V+][N+] =20 / --> EAP repeat 1..N times | \ <-- EAP =20 last request --> AUTH =20 last response <-- AUTH, = [CP(CFG_REPLY(*TIMEOUT_PERIOD_FOR_LIVENESS_CHECK with a value selected = by server*))], [N(IPCOMP_SUPPORTED)], [N(USE_TRANSPORT_MODE)], [N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(NON_FIRST_FRAGMENTS_ALSO)], SA, TSi, TSr, [N(ADDITIONAL_TS_POSSIBLE)], [V+][N+] =20 =20 If the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK with a value selected by = server is received as shown above, the client (user equipment) must = perform the liveness check procedure with the timeout indicated by the = TIMEOUT_PERIOD_FOR_LIVENESS_CHECK configuration attribute. =20 =20 Detailed TS 24.302 client procedures related to the = TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute are: ------------- 7.2.2 Tunnel establishment 7.2.2.1 Tunnel establishment accepted by the network ..... The UE may support the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as = specified in subclause 8.2.4.2. If the UE supports the = TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute, the UE shall include the = TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute indicating support of = receiving timeout period for liveness check in the CFG_REQUEST = configuration payload. If the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK = attribute as specified in subclause 8.2.4.2 indicating the timeout = period for the liveness check is included in the CFG_REPLY configuration = payload or if the UE has a pre-configured timeout period, the UE shall = perform the tunnel liveness checks as described in subclause 7.2.2A. NOTE: The timeout period for liveness check is pre-configured in = the UE in implementation-specific way. ..... 7.2.2A Liveness check If the UE supports the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as = specified in subclause 8.2.4.2 and the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK = attribute as specified in subclause 8.2.4.2 was included in the = CFG_REPLY configuration payload received in subclause 7.2.2 the UE shall = set the timeout period for the liveness check to the value of the = TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute. If the UE does not support the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK = attribute as specified in subclause 8.2.4.2 or the = TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in subclause = 8.2.4.2 was not included in the CFG_REPLY configuration payload received = in subclause 7.2.2 then the UE shall use the pre-configured value of the = timeout period for liveness check. NOTE: The timeout period is pre-configured in the UE in = implementation-specific way. If the UE has not received any cryptographically protected IKEv2 or = IPSec message for the duration of the timeout period for liveness check, = the UE shall send an INFORMATIONAL request with no payloads as per IETF = RFC 5996 [28]. If an INFORMATIONAL response is not received, the UE = shall deem the IKEv2 security association to have failed. ------------- =20 Detailed TS 24.302 server procedures related to the = TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute are: ------------- The ePDG shall proceed with IPsec tunnel setup completion and shall = relay in the IKEv2 Configuration Payload (CFG_REPLY) of the final = IKE_AUTH response message: ... - The ePDG may include the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK = attribute as specified in subclause 8.2.4.2 indicating the timeout = period for liveness check in the CFG_REPLY configuration payload. = Presence of the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute in the = IKE_AUTH request can be used as input for decision on whether to include = the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute. ... ------------- =20 =20 Kind regards =20 Ivo Sedlacek -------------------------------------------------------------------------= ----- _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_04BD_01D170B2.7E9BE2D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi Ivo,
 
thank you for providing more details.
 
However, it is not clear from this description what = UE should=20 do if it has a data to be sent,
but it received no protected data for some perion of = time.=20 Section 2.4. of RFC 7296 suggests that
the IKEv2 implementation performs a Liveness Check = in this=20 case:
 
   If no
   = cryptographically=20 protected messages have been received on an IKE SA
   or = any of its=20 Child SAs recently, the system needs to perform a
   = liveness check=20 in order to prevent sending messages to a dead peer.
It is not clear how this text is supposed to align = with=20 TIMEOUT_PERIOD_FOR_LIVENESS_CHECK.
In other words - should UE in this = situation perform a=20 Liveness Check, ignoring
the ePDG provided interval? Or should it ignore the=20 possibility to send
data to a dead peer and perform Liveness Checks = only on=20 the specified interval?
 
Regards,
Valery Smyslov.
 
 
----- Original Message -----
From:=20 Ivo=20 Sedlacek
Cc: ipsec@ietf.org ; frederic.firmin@etsi.org =
Sent: Thursday, February 25, = 2016 6:58=20 PM
Subject: Re: [IPsec] IANA = allocation of=20 TIMEOUT_PERIOD_FOR_LIVENESS_CHECK

Hello,

 

In=20 case you are interested in detailed procedures of the 3GPP = specification, I=20 have copied them at the end of this mail.

 

> > I am confused. Is this a notify of = the server=20 to the client, or a

> > configuration item by the server = instructing=20 client behaviour?

>

> It is notify from the server to client. = I.e. client=20 sends empty TIMEOUT_PERIOD_FOR_LIVENESS_CHECK in the CFG_REQUEST and=20

> server will send value in seconds inside = its=20 TIMEOUT_PERIOD_FOR_LIVENESS_CHECK in CFG_REPLY. I.e. the server asks = client=20

> to use following livenss timeout period.=20

 

3GPP spec expects that if the client (User = Equipment)=20 supports the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK configuration = attribute, then=20 the client (User Equipment) *enforces* the timer value indicated in = the=20 TIMEOUT_PERIOD_FOR_LIVENESS_CHECK configuration attribute in CFG_REPLY = sent by=20 server (Evolved Packet Data Gateway).

 

I.e. it is an intruction, not a=20 suggestion.

 

It is supposed to work as = follows:

 

   first=20 request       --> IDi,

        &nbs= p;            = ;     =20 [N(INITIAL_CONTACT)],

        &nbs= p;            = ;     =20 [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+],

        &nbs= p;            = ;     =20 [IDr],

        &nbs= p;=20 =             &= nbsp;    [CP(CFG_REQUEST=20 (*TIMEOUT_PERIOD_FOR_LIVENESS_CHECK with empty value*) = )],

        &nbs= p;            = ;     =20 [N(IPCOMP_SUPPORTED)+],

        &nbs= p;            = ;     =20 [N(USE_TRANSPORT_MODE)],

        &nbs= p;            = ;     =20 [N(ESP_TFC_PADDING_NOT_SUPPORTED)],

        &nbs= p;            = ;     =20 [N(NON_FIRST_FRAGMENTS_ALSO)],

        &nbs= p;            = ;     =20 SA, TSi, TSr,

        &nbs= p;            = ;     =20 [V+][N+]

 

   first=20 response      <-- IDr, [CERT+],=20 AUTH,

        &nbs= p;            = ;     =20 EAP,

        &nbs= p;            = ;     =20 [V+][N+]

 

 =20 =             &= nbsp;      /=20 --> EAP

   repeat 1..N times = |

        &nbs= p;           =20 \ <-- EAP

 

   last=20 request        --> = AUTH

 

   last=20 response       <-- = AUTH,

        &nbs= p;            = ;     =20 [CP(CFG_REPLY(*TIMEOUT_PERIOD_FOR_LIVENESS_CHECK with a value selected = by=20 server*))],

        &nbs= p;            = ;     =20 [N(IPCOMP_SUPPORTED)],

        &nbs= p;            = ;     =20 [N(USE_TRANSPORT_MODE)],

        &nbs= p;            = ;     =20 [N(ESP_TFC_PADDING_NOT_SUPPORTED)],

        &nbs= p;            = ;     =20 [N(NON_FIRST_FRAGMENTS_ALSO)],

        &nbs= p;            = ;     =20 SA, TSi, TSr,

        &nbs= p;            = ;     =20 [N(ADDITIONAL_TS_POSSIBLE)],

        &nbs= p;            = ;     =20 [V+][N+]

 

 

If=20 the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK with a value selected by server = is=20 received as shown above, the client (user equipment) must perform the = liveness=20 check procedure with the timeout indicated by the=20 TIMEOUT_PERIOD_FOR_LIVENESS_CHECK configuration=20 attribute.

 

 

Detailed=20 TS 24.302 client procedures related to the = TIMEOUT_PERIOD_FOR_LIVENESS_CHECK=20 attribute are:

-------------

7.2.2       Tunnel=20 establishment

7.2.2.1 Tunnel establishment accepted by the=20 network

.....

The=20 UE may support the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute=20 as specified in subclause 8.2.4.2. If=20 the UE supports the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute,=20 the UE shall include the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute=20 indicating support of receiving timeout period for liveness = check=20 in=20 the CFG_REQUEST configuration payload.=20 If the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute=20 as specified in subclause 8.2.4.2=20 indicating the timeout period for the liveness check=20 is=20 included in the CFG_REPLY configuration=20 payload=20 or if the UE has a pre-configured timeout period, the UE shall = perform the=20 tunnel=20 liveness checks=20 as described in subclause 7.2.2A.

NOTE:      The timeout period = for liveness=20 check is pre-configured in the UE in implementation-specific=20 way.

.....

7.2.2A    Liveness check

If=20 the UE supports the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute=20 as specified in subclause 8.2.4.2 and=20 the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute=20 as specified in subclause 8.2.4.2=20 was included in the CFG_REPLY configuration=20 payload=20 received in subclause 7.2.2=20 the UE shall set the timeout period for the liveness check to the = value of the=20 TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute.

If=20 the UE does not support the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute=20 as specified in subclause 8.2.4.2 or=20 the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute=20 as specified in subclause 8.2.4.2=20 was not included in the CFG_REPLY configuration=20 payload=20 received in subclause 7.2.2=20 then the UE shall use the pre-configured value of the timeout period = for=20 liveness check.

NOTE:      The timeout period is pre-configured in the UE in=20 implementation-specific way.

If=20 the UE has not received any cryptographically protected IKEv2 or IPSec = message=20 for the duration of the timeout period for liveness check, the UE=20 shall send an INFORMATIONAL request with no payloads as = per=20 IETF RFC 5996 [28]. If an INFORMATIONAL response is not received, the UE = shall deem=20 the IKEv2 security association to have failed.

-------------

 

Detailed=20 TS 24.302 server procedures related to the = TIMEOUT_PERIOD_FOR_LIVENESS_CHECK=20 attribute are:

-------------

The ePDG shall proceed with IPsec tunnel setup completion = and shall=20 relay in the IKEv2 Configuration Payload (CFG_REPLY) of the final = IKE_AUTH=20 response message:

...

-     The ePDG may include the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in subclause 8.2.4.2 indicating the timeout period for liveness = check in the CFG_REPLY configuration payload. Presence of=20 the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute in the IKE_AUTH request can be used as input = for=20 decision on whether to include the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute.

...

-------------

 

 

Kind regards

 

Ivo Sedlacek

_______________________________________________
IPsec = mailing=20 = list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
= ------=_NextPart_000_04BD_01D170B2.7E9BE2D0-- From nobody Fri Feb 26 05:55:48 2016 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 472AB1A8BC3 for ; Fri, 26 Feb 2016 05:55:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aj1aScUirVLP for ; Fri, 26 Feb 2016 05:55:42 -0800 (PST) Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6011E1A1BD9 for ; Fri, 26 Feb 2016 05:55:41 -0800 (PST) X-AuditID: c1b4fb30-f79ec6d000002212-1a-56d0595b7e2e Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 75.8C.08722.B5950D65; Fri, 26 Feb 2016 14:55:39 +0100 (CET) Received: from ESESSMB301.ericsson.se ([169.254.1.190]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.03.0248.002; Fri, 26 Feb 2016 14:54:38 +0100 From: Ivo Sedlacek To: Valery Smyslov , Tero Kivinen , "Paul Wouters" Thread-Topic: [IPsec] IANA allocation of TIMEOUT_PERIOD_FOR_LIVENESS_CHECK Thread-Index: AQHRb9ZEmL69MYW+c0mrQROWP3qUUJ88wFQAgAAHhYCAABbGAIABdGepgAAA0ZA= Date: Fri, 26 Feb 2016 13:54:38 +0000 Message-ID: <39B5E4D390E9BD4890E2B31079006101162DCC6A@ESESSMB301.ericsson.se> References: <22223.2866.976241.499754@fireball.acr.fi> <22223.5419.528391.85358@fireball.acr.fi> <39B5E4D390E9BD4890E2B31079006101162DAD5D@ESESSMB301.ericsson.se> <70D0144557154722A10599DAD6742F8C@buildpc> In-Reply-To: <70D0144557154722A10599DAD6742F8C@buildpc> Accept-Language: en-US, cs-CZ Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: multipart/alternative; boundary="_000_39B5E4D390E9BD4890E2B31079006101162DCC6AESESSMB301erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPIsWRmVeSWpSXmKPExsUyM2K7h2505IUwg+8NihaNWy6zW+zf8oLN 4uj552wW729dYrK48WEmmwOrx6el05k8ds66y+6xZMlPJo/DXxeyeHyfxxTAGsVlk5Kak1mW WqRvl8CV8bN1AWPBpN9MFW9b77A3MJ46x9TFyMkhIWAiMWn7U2YIW0ziwr31bCC2kMBhRol9 D/27GLmA7CWMEkvurQYrYhPQk5i45QgriC0ikC6xZ8I0dhCbWSBO4tXcyWBDhQU8JaZ/fc4G UeMlseFmAzOE7Scx++YJsBoWAVWJtnPLwWxeAV+J1etPM0Es62SSaDy7grGLkYODU8BcYnG/ N0gNo4CsxNU/vYwQu8Qlbj2ZD/WAgMSSPeehHhCVePn4HyuErSjx8dU+qPp8iQNHN7FC7BKU ODnzCcsERtFZSEbNQlI2C0kZRFxHYsHuT2wQtrbEsoWvmWHsMwceMyGLL2BkX8UoWpxanJSb bmSkl1qUmVxcnJ+nl5dasokRGK0Ht/w22MH48rnjIUYBDkYlHt4P38+HCbEmlhVX5h5ilOBg VhLhdQ28ECbEm5JYWZValB9fVJqTWnyIUZqDRUmcd7Xz+jAhgfTEktTs1NSC1CKYLBMHp1QD Y4LnpmX17csqZQxdGf9zbhe1az/Jf+H48p3nCrWXtO6SL/u5Uf6bwtzHkoo7t+nV3RNRfbxw 5aer/3n5DZyX9URov9Yxbunbv/Lio5c3NmVGFx9cfXbTkkOzZrBxfzE2vNT6QOrTXzOT6Xpc VcGfp1ZlOfkVf3a3XqaRL/uh/PTR8zdsb1vViSqxFGckGmoxFxUnAgDOQayR0gIAAA== Archived-At: Cc: "ipsec@ietf.org" , "frederic.firmin@etsi.org" Subject: Re: [IPsec] IANA allocation of TIMEOUT_PERIOD_FOR_LIVENESS_CHECK 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, 26 Feb 2016 13:55:46 -0000 --_000_39B5E4D390E9BD4890E2B31079006101162DCC6AESESSMB301erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello, 3GPP TS 24.302 states: If the UE has not received any cryptographically protected IKEv2 or IPSec m= essage for the duration of the timeout period for liveness check, the UE sh= all send an INFORMATIONAL request with no payloads as per IETF RFC 5996 [28= ]. If an INFORMATIONAL response is not received, the UE shall deem the IKEv= 2 security association to have failed. I.e. if the UE (client) follows the above, the UE (client) will always rece= ive a cryptographically protected message within duration of (the timeout p= eriod for liveness check + one INFORMATIONAL transaction duration) - either= an IPSec message, or an IKEv2 message, or an INFORMATIONAL response trigge= red by the sent INFORMATIONAL request. The above procedure intentionally does not depend on whether the UE (client= ) has any data to be sent or not. The reason is that when the UE (client) w= aits for incoming call setup request, the UE (client) still needs to be sur= e that ePDG is alive else incoming calls might be lost. This is true even i= f the UE (client) does not actually send any outgoing IP packets, just wait= ing for incoming IP packets carrying the incoming call setup request. > In other words - should UE in this situation perform a Liveness Check, ig= noring the ePDG provided interval? Liveness of ePDG is important regardless whether the UE (client) has data t= o be sent or not - see explanation above. Thus, why to perform an additional liveness check just because the UE (clie= nt) has data to be sent? > Or should it ignore the possibility to send data to a dead peer and perf= orm Liveness Checks only on the specified interval? The UE (client) should send the data immediately. The UE (client) should perform the liveness check regularly. Kind regards Ivo Sedlacek From: Valery Smyslov [mailto:svanru@gmail.com] Sent: Friday, February 26, 2016 2:27 PM To: Ivo Sedlacek; Tero Kivinen; Paul Wouters Cc: ipsec@ietf.org; frederic.firmin@etsi.org Subject: Re: [IPsec] IANA allocation of TIMEOUT_PERIOD_FOR_LIVENESS_CHECK Hi Ivo, thank you for providing more details. However, it is not clear from this description what UE should do if it has = a data to be sent, but it received no protected data for some perion of time. Section 2.4. of = RFC 7296 suggests that the IKEv2 implementation performs a Liveness Check in this case: If no cryptographically protected messages have been received on an IKE SA or any of its Child SAs recently, the system needs to perform a liveness check in order to prevent sending messages to a dead peer. It is not clear how this text is supposed to align with TIMEOUT_PERIOD_FOR_= LIVENESS_CHECK. In other words - should UE in this situation perform a Liveness Check, igno= ring the ePDG provided interval? Or should it ignore the possibility to send data to a dead peer and perform Liveness Checks only on the specified inter= val? Regards, Valery Smyslov. ----- Original Message ----- From: Ivo Sedlacek To: Tero Kivinen ; Paul Wouters Cc: ipsec@ietf.org ; frederic.firmin@etsi.org Sent: Thursday, February 25, 2016 6:58 PM Subject: Re: [IPsec] IANA allocation of TIMEOUT_PERIOD_FOR_LIVENESS_CHECK Hello, In case you are interested in detailed procedures of the 3GPP specification= , I have copied them at the end of this mail. > > I am confused. Is this a notify of the server to the client, or a > > configuration item by the server instructing client behaviour? > > It is notify from the server to client. I.e. client sends empty TIMEOUT_P= ERIOD_FOR_LIVENESS_CHECK in the CFG_REQUEST and > server will send value in seconds inside its TIMEOUT_PERIOD_FOR_LIVENESS_= CHECK in CFG_REPLY. I.e. the server asks client > to use following livenss timeout period. 3GPP spec expects that if the client (User Equipment) supports the TIMEOUT_= PERIOD_FOR_LIVENESS_CHECK configuration attribute, then the client (User Eq= uipment) *enforces* the timer value indicated in the TIMEOUT_PERIOD_FOR_LIV= ENESS_CHECK configuration attribute in CFG_REPLY sent by server (Evolved Pa= cket Data Gateway). I.e. it is an intruction, not a suggestion. It is supposed to work as follows: first request --> IDi, [N(INITIAL_CONTACT)], [[N(HTTP_CERT_LOOKUP_SUPPORTED)], CERTREQ+], [IDr], [CP(CFG_REQUEST (*TIMEOUT_PERIOD_FOR_LIVENESS_CH= ECK with empty value*) )], [N(IPCOMP_SUPPORTED)+], [N(USE_TRANSPORT_MODE)], [N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(NON_FIRST_FRAGMENTS_ALSO)], SA, TSi, TSr, [V+][N+] first response <-- IDr, [CERT+], AUTH, EAP, [V+][N+] / --> EAP repeat 1..N times | \ <-- EAP last request --> AUTH last response <-- AUTH, [CP(CFG_REPLY(*TIMEOUT_PERIOD_FOR_LIVENESS_CHECK= with a value selected by server*))], [N(IPCOMP_SUPPORTED)], [N(USE_TRANSPORT_MODE)], [N(ESP_TFC_PADDING_NOT_SUPPORTED)], [N(NON_FIRST_FRAGMENTS_ALSO)], SA, TSi, TSr, [N(ADDITIONAL_TS_POSSIBLE)], [V+][N+] If the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK with a value selected by server is= received as shown above, the client (user equipment) must perform the live= ness check procedure with the timeout indicated by the TIMEOUT_PERIOD_FOR_L= IVENESS_CHECK configuration attribute. Detailed TS 24.302 client procedures related to the TIMEOUT_PERIOD_FOR_LIVE= NESS_CHECK attribute are: ------------- 7.2.2 Tunnel establishment 7.2.2.1 Tunnel establishment accepted by the network ..... The UE may support the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as speci= fied in subclause 8.2.4.2. If the UE supports the TIMEOUT_PERIOD_FOR_LIVENE= SS_CHECK attribute, the UE shall include the TIMEOUT_PERIOD_FOR_LIVENESS_CH= ECK attribute indicating support of receiving timeout period for liveness c= heck in the CFG_REQUEST configuration payload. If the TIMEOUT_PERIOD_FOR_LI= VENESS_CHECK attribute as specified in subclause 8.2.4.2 indicating the tim= eout period for the liveness check is included in the CFG_REPLY configurati= on payload or if the UE has a pre-configured timeout period, the UE shall p= erform the tunnel liveness checks as described in subclause 7.2.2A. NOTE: The timeout period for liveness check is pre-configured in the U= E in implementation-specific way. ..... 7.2.2A Liveness check If the UE supports the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as speci= fied in subclause 8.2.4.2 and the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribu= te as specified in subclause 8.2.4.2 was included in the CFG_REPLY configur= ation payload received in subclause 7.2.2 the UE shall set the timeout peri= od for the liveness check to the value of the TIMEOUT_PERIOD_FOR_LIVENESS_C= HECK attribute. If the UE does not support the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute = as specified in subclause 8.2.4.2 or the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK = attribute as specified in subclause 8.2.4.2 was not included in the CFG_REP= LY configuration payload received in subclause 7.2.2 then the UE shall use = the pre-configured value of the timeout period for liveness check. NOTE: The timeout period is pre-configured in the UE in implementation= -specific way. If the UE has not received any cryptographically protected IKEv2 or IPSec m= essage for the duration of the timeout period for liveness check, the UE sh= all send an INFORMATIONAL request with no payloads as per IETF RFC 5996 [28= ]. If an INFORMATIONAL response is not received, the UE shall deem the IKEv= 2 security association to have failed. ------------- Detailed TS 24.302 server procedures related to the TIMEOUT_PERIOD_FOR_LIVE= NESS_CHECK attribute are: ------------- The ePDG shall proceed with IPsec tunnel setup completion and shall relay i= n the IKEv2 Configuration Payload (CFG_REPLY) of the final IKE_AUTH respons= e message: ... - The ePDG may include the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute = as specified in subclause 8.2.4.2 indicating the timeout period for livenes= s check in the CFG_REPLY configuration payload. Presence of the TIMEOUT_PER= IOD_FOR_LIVENESS_CHECK attribute in the IKE_AUTH request can be used as inp= ut for decision on whether to include the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK= attribute. ... ------------- Kind regards Ivo Sedlacek ________________________________ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --_000_39B5E4D390E9BD4890E2B31079006101162DCC6AESESSMB301erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello,

 

3GPP TS 24.302 states:

 

If the UE has not received any cryptographically protec= ted IKEv2 or IPSec message for the duration of the timeout period for liven= ess check, the UE shall send an INFORMATIONAL req= uest with no payloads as per IETF RFC 5996 [28]. If an INFORMATIONAL response is not received, the UE shall deem= the IKEv2 security association to have failed.

 

 

I.e. if the UE (client) follows the above, the UE (c= lient) will always receive a cryptographically protected message within dur= ation of (the timeout period for liveness check + one INFORMATIONAL tra= nsaction duration) - either an IPSec message, or an IKEv2 message, or an INFORMATIONAL response triggered by the sent IN= FORMATIONAL request.

 

The above procedure intentionally does not depend on= whether the UE (client) has any data to be sent or not. The reason is that= when the UE (client) waits for incoming call setup request, the UE (client= ) still needs to be sure that ePDG is alive else incoming calls might be lost. This is true even if the UE (c= lient) does not actually send any outgoing IP packets, just waiting for inc= oming IP packets carrying the incoming call setup request.

 

> In other words - should UE in= this situation perform a Liveness Check, ignoring the ePDG provided i= nterval?

 

Liveness of ePDG is important rega= rdless whether the UE (client) has data to be sent or not - see explanat= ion above.

 

Thus, why to perform an additional= liveness check just because the UE (client) has data to be sent?

 

> Or should it ignore the possi= bility to send  data to a dead peer and perform Liveness Checks o= nly on the specified interval?

 

The UE (client) should send the data immediately.

The UE (client) should perform the liveness check re= gularly.

 

Kind regards

 

Ivo Sedlacek

 

 

From: Valery S= myslov [mailto:svanru@gmail.com]
Sent: Friday, February 26, 2016 2:27 PM
To: Ivo Sedlacek; Tero Kivinen; Paul Wouters
Cc: ipsec@ietf.org; frederic.firmin@etsi.org
Subject: Re: [IPsec] IANA allocation of TIMEOUT_PERIOD_FOR_LIVENESS_= CHECK

 

Hi Ivo,

 =

thank you for providing = more details.

 =

However, it is not clear= from this description what UE should do if it has a data to be sent,

but it received no prote= cted data for some perion of time. Section 2.4. of RFC 7296 suggests that

the IKEv2 implementation= performs a Liveness Check in this case:=

 =

   If no<= br>    cryptographically protected messages have been received on an = IKE SA
   or any of its Child SAs recently, the system needs to perform = a
   liveness check in order to prevent sending messages to a dead = peer.

It is not clear how this= text is supposed to align with TIMEOUT_PERIOD_FOR_LIVENESS_CHECK.

In other words - should = UE in this situation perform a Liveness Check, ignoring

the ePDG provided interv= al? Or should it ignore the possibility to send

data to a dead peer= and perform Liveness Checks only on the specified interval?

 =

Regards,

Valery Smyslov.

 =

 =

----- Original Message -----

From: Ivo Sedlacek

Sent: Thursday, February 25, 2016 6:58 PM

Subject: Re: [IPsec] IANA allocation of TIMEOUT_PERIOD_FOR_LIVENESS= _CHECK

 =

Hello,

 

In case= you are interested in detailed procedures of the 3GPP specification, I hav= e copied them at the end of this mail.

 

> > I am confused. Is thi= s a notify of the server to the client, or a

> > configuration item by= the server instructing client behaviour?

>

> It is notify from the serv= er to client. I.e. client sends empty TIMEOUT_PERIOD_FOR_LIVENESS_CHECK in = the CFG_REQUEST and

> server will send value in = seconds inside its TIMEOUT_PERIOD_FOR_LIVENESS_CHECK in CFG_REPLY. I.e. the= server asks client

> to use following livenss t= imeout period.

 

3GPP spec expects that if the c= lient (User Equipment) supports the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK confi= guration attribute, then the client (User Equipment) *enforces* the timer v= alue indicated in the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK configuration attribute in CFG_REPLY sent by server (Evolved Packet Data G= ateway).

 

I.e. it is an intruction, not a= suggestion.

 

It is supposed to work as follo= ws:

 

   first request = ;      --> IDi,

     &= nbsp;           &nbs= p;         [N(INITIAL_CONTACT)],

     &= nbsp;           &nbs= p;         [[N(HTTP_CERT_LOOKUP_SUP= PORTED)], CERTREQ+],

     &= nbsp;           &nbs= p;         [IDr],=

     &= nbsp;            &nb= sp;        [CP(CFG_REQUEST (*TIMEOU= T_PERIOD_FOR_LIVENESS_CHECK with empty value*) )],

     &= nbsp;           &nbs= p;         [N(IPCOMP_SUPPORTED)+= ;],

     &= nbsp;           &nbs= p;         [N(USE_TRANSPORT_MODE)],=

     &= nbsp;           &nbs= p;         [N(ESP_TFC_PADDING_NOT_S= UPPORTED)],

     &= nbsp;           &nbs= p;         [N(NON_FIRST_FRAGMENTS_A= LSO)],

     &= nbsp;           &nbs= p;         SA, TSi, TSr,=

     &= nbsp;           &nbs= p;         [V+][N+]

 

   first response&nbs= p;     <-- IDr, [CERT+], AUTH,=

     &= nbsp;           &nbs= p;         EAP,

     &= nbsp;           &nbs= p;         [V+][N+]

 

      =             &nb= sp;  / --> EAP

   repeat 1..N times = |

     &= nbsp;           &nbs= p;   \ <-- EAP

 

   last request =        --> AUTH

 

   last response = ;      <-- AUTH,

     &= nbsp;           &nbs= p;         [CP(CFG_REPLY(*TIMEOUT_P= ERIOD_FOR_LIVENESS_CHECK with a value selected by server*))],

     &= nbsp;           &nbs= p;         [N(IPCOMP_SUPPORTED)],

     &= nbsp;           &nbs= p;         [N(USE_TRANSPORT_MODE)],=

     &= nbsp;           &nbs= p;         [N(ESP_TFC_PADDING_NOT_S= UPPORTED)],

     &= nbsp;           &nbs= p;         [N(NON_FIRST_FRAGMENTS_A= LSO)],

     &= nbsp;           &nbs= p;         SA, TSi, TSr,=

     &= nbsp;           &nbs= p;         [N(ADDITIONAL_TS_POSSIBL= E)],

     &= nbsp;           &nbs= p;         [V+][N+]

 

 

If the = TIMEOUT_PERIOD_FOR_LIVENESS_CHECK with a value selected by server is receiv= ed as shown above, the client (user equipment) must perform the liveness ch= eck procedure with the timeout indicated by the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK configuration attribute.

&n= bsp;

&n= bsp;

Detaile= d TS 24.302 client procedures related to the TIMEOUT_PERIOD_FOR_LIVENESS_CH= ECK attribute are:

-------= ------

7.2.2 =       Tunnel establishment

7<= /span>.2.2.1 Tunnel establishment accepted by the network

.....

The UE may support the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in subclause 8.2.4.2. If the UE supports the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute, the UE shall include the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute indicating support of receiving timeout period for liveness c= heck in the CFG_REQUEST configurati= on payload. If the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in subclause 8.2.4.2 indicating the timeout period for the liveness check is included in the CFG_REPLY configuration payload or if the UE has a pre-configured timeout period, the UE shall perform the tunnel liveness checks as described in su= bclause 7.2.2A= .

NOTE: =      The timeout period for liveness check is pre-confi= gured in the UE in implementation-specific way.

.....

7.2.2A    L= iveness check

If the UE supports the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in subclause 8.2.4.2 and the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in subclause 8.2.4.2 was included in the CFG_REPLY configuration payload received in subclause 7.2.2 the UE shall set the timeout period for the = liveness check to the value of the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute.

If the UE does not support the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK att= ribute as specified in subclause 8.2.4.2 or the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute = as specified in subclause 8.2.4.2= was not included in the CFG_REPLY configuration payload received in subclause 7.2.2 then the UE shall use the pre-configured value of the timeout period for liveness check.

NOTE:      The timeout period is p= re-configured in the UE in implementation-specific way.

If the UE has not received any cryptographically protec= ted IKEv2 or IPSec message for the duration of the timeout period for liven= ess check, the UE shall send an INFORMATIONAL request wi= th no payloads as per IETF RFC 5996 [28]. If an INFORMATIONAL response is not received, the UE shall deem the IK= Ev2 security association to have failed.

-------= ------

 

Detaile= d TS 24.302 server procedures related to the TIMEOUT_PERIOD_FOR_LIVENESS_CH= ECK attribute are:

-------= ------

The ePDG sh= all proceed with IPsec tunnel setup completion and shall relay in the IKEv2= Configuration Payload (CFG_REPLY) of the final IKE_AUTH response message:<= o:p>

...=

- &nbs= p;   The ePDG may include the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute as specified in subclause 8.2.4.2 indicating the time= out period for liveness check in the CFG_REPLY configuration payload. Presence of the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute in the IKE_AUTH request can be used as input for decision = on whether to include the TIMEOUT_PERIOD_FOR_LIVENESS_CHECK attribute= .

...=

-------= ------

&n= bsp;

 

Kind regards<= /p>

 

Ivo Sedlacek<= /p>

________________________= _______________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.or= g/mailman/listinfo/ipsec

--_000_39B5E4D390E9BD4890E2B31079006101162DCC6AESESSMB301erics_-- From nobody Fri Feb 26 06:05:37 2016 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 635151B2BFB for ; Fri, 26 Feb 2016 06:05:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.907 X-Spam-Level: X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.006, 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 uFgOAWLfEhBs for ; Fri, 26 Feb 2016 06:05:35 -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 D9A801B2BF9 for ; Fri, 26 Feb 2016 06:05:34 -0800 (PST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id 29B99200A5; Fri, 26 Feb 2016 09:06:46 -0500 (EST) Received: from obiwan.sandelman.ca (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id 595296374E; Fri, 26 Feb 2016 09:05:33 -0500 (EST) From: Michael Richardson To: "Valery Smyslov" In-Reply-To: <7C69D4636A2541A686420EE56831F10B@buildpc> References: <46cc66173e324ae0b788f36cd58f5dfa@XCH-RCD-006.cisco.com><22220.36465.788794.855413@fireball.acr.fi><22222.1834.892900.623823@fireball.acr.fi><3C4D164CF08843258CE30B5B21363397@buildpc> <22222.63205.854356.14024@fireball.acr.fi> <7C69D4636A2541A686420EE56831F10B@buildpc> X-Mailer: MH-E 8.6; nmh 1.6+dev; GNU Emacs 24.4.2 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 Archived-At: Cc: ipsec@ietf.org, Tero Kivinen , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01 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, 26 Feb 2016 14:05:36 -0000 --=-=-= Content-Type: text/plain Valery Smyslov wrote: > I think that the protection of IKE SA is important. This would preserve > IKEv2 security properties (like protecting identities against passive > attacker) and would allow to re-use the solution in G-IKEv2 and other > IKEv2 derivations that do transfer sensitive information within IKE SA. If the protection of the IKE SA means that we wind up in an IKEv1-like situation with Main Mode and group PSKs, then the result will be that IKE is not used. -- Michael Richardson , Sandelman Software Works -= IPv6 IoT consulting =- --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEVAwUBVtBbqYCLcPvd0N1lAQIBQwgAvkux/JypxJx+LFz0q6sWFf3f7GUUBqun +uu9uziRsixibk13HJ9zwd+63T0587Hu09+Ldn2F/uZwha+Dt8tmNr73LPf7Fw5m qJWNcIR/hB+zQCn/7JMUr4OMnEmZcW9qqdnYtAFCVN1i/8hbLXcyOzBHBahKQ548 iV0QIRLtQJaeHh146TldRrwb/I2Te7E5PxbnQqvZ43pK8gSOybf8ebsfHlnSWul3 +jyIRucwpEcWgz7H6GM1QoBDI9nZB5AZXYCiJWIsOU51/jvVIaqx2BLFNSHZ8v6s dyS4zBGYxwgkXYaA0B7WTEV/un7B3kwYCCIngBXkZAXsJI29XbyPgg== =ujog -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Feb 26 06:19:27 2016 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 22D5D1B2C78 for ; Fri, 26 Feb 2016 06:19:27 -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 3Wof_Fo6JDBN for ; Fri, 26 Feb 2016 06:19:25 -0800 (PST) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AA991B2C79 for ; Fri, 26 Feb 2016 06:19:25 -0800 (PST) Received: by mail-lf0-x22b.google.com with SMTP id l143so54207099lfe.2 for ; Fri, 26 Feb 2016 06:19:25 -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-transfer-encoding; bh=v78ID8MVtAN9E84DSKCW+5+eYn//kyvY/UZ1poQ9CM8=; b=EFqxc4A1ftRoz89RBNB1Ks9JnJR9PE+IBincboXvRj/YaCxvlcGjQ6nUSC7KtdR4Oo tgL6IV2uXPpm1idHwC0rjLJGle1zGMgVRMfiVOLsWvZYt/Jw/FTx2VkKpid1vHyOFnv6 clNMs/D0o+oZYTRhQccVWP6abuAfdPvtddy0kZ/rnTgAqVVflXnnvo3ZWkNNff19Krnz 5n5RnuWlzHtthrzKYVQdSNTI7me2Wm4CHtMVF5a1rpbZsNLy5dDQahPGby8HHvi5CG2N JumrzWgWu6uNL3nKFXD3UKKZuSn3Pn04JoTCA8ngdA/1yhweSqaEKAkoZP4e8V5H8mt6 EAFA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version:content-transfer-encoding; bh=v78ID8MVtAN9E84DSKCW+5+eYn//kyvY/UZ1poQ9CM8=; b=K8mtCmH7mkOBQOAQgfINn1yiZBhG4ydttnVRCgWZrRTGWX8u0H09CKT4rDspuHKVXq u0Pn4lZNzyzskRo/TpVC2KWpjg3HcUcIWVkK/8mfYScp8xwj06ps8mj5R35g3rYw1cYm W8uZhSAuEZdM8yAT92ij4Fnme6+Bf4Kaen5KdqKqU3fr83Kar3CyjgpEeiKNJH0ucsS1 RZ+fVd9r3tw24N6be3/JLq9xSgSOe2mU2I+kSRfIk2LIxiUnEAKaYS3jLWZJ8800IbY/ +N+f0allE5SDKS6d4XOFGNcH1QD3ptxy5ZNQEKqLrIin8eKbUAa8p/VVRN2jcUuOcoDJ c0Kw== X-Gm-Message-State: AD7BkJKgA+qrZjElzlwvpR14QnYtQV7UlKAS9R62G+kJdmFclScVRbP76yGg+BRij4DUHQ== X-Received: by 10.25.16.30 with SMTP id f30mr788245lfi.126.1456496363748; Fri, 26 Feb 2016 06:19:23 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id zk9sm1847104lbb.3.2016.02.26.06.19.22 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Feb 2016 06:19:22 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Michael Richardson" References: <46cc66173e324ae0b788f36cd58f5dfa@XCH-RCD-006.cisco.com><22220.36465.788794.855413@fireball.acr.fi><22222.1834.892900.623823@fireball.acr.fi><3C4D164CF08843258CE30B5B21363397@buildpc> <22222.63205.854356.14024@fireball.acr.fi> <7C69D4636A2541A686420EE56831F10B@buildpc> <4963.1456495533@obiwan.sandelman.ca> Date: Fri, 26 Feb 2016 17:19:26 +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: Cc: ipsec@ietf.org, Tero Kivinen , "Scott Fluhrer \(sfluhrer\)" Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01 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, 26 Feb 2016 14:19:27 -0000 Hi Michael, > > I think that the protection of IKE SA is important. This would preserve > > IKEv2 security properties (like protecting identities against passive > > attacker) and would allow to re-use the solution in G-IKEv2 and other > > IKEv2 derivations that do transfer sensitive information within IKE SA. > > If the protection of the IKE SA means that we wind up in an IKEv1-like > situation with Main Mode and group PSKs, then the result will be that IKE is > not used. Agree. But it is my understanding of the draft that it doesn't imply any IKEv1 like group PSKs. It allows proper selection of pair-wise PSK. Regards, Valery. From nobody Fri Feb 26 08:32:44 2016 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 7FED01ACDA6 for ; Fri, 26 Feb 2016 08:32:43 -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 lE-oZctSnHR3 for ; Fri, 26 Feb 2016 08:32:41 -0800 (PST) Received: from mail-vk0-x230.google.com (mail-vk0-x230.google.com [IPv6:2607:f8b0:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 755A91ACDB6 for ; Fri, 26 Feb 2016 08:32:41 -0800 (PST) Received: by mail-vk0-x230.google.com with SMTP id c3so81935304vkb.3 for ; Fri, 26 Feb 2016 08:32:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to; bh=+b40xKvwabuAhN+PaEDV5dkww2ZN2WOUiNyqipBFklE=; b=QXLmqFvhscPdDrHSojVZzFE6+ZED7HgCCpGTSfQHrNDdN1iBsKK4YElGnrF71rrT9P DRsC2gRn2o2VkfGbmG74B9zS6h2zWsu9xBHJPBCW2IlKm85qJgdQtm19XL4+VMD2ydPM CdOfJBaXanLczm0Xwb/MpQq4WzANd05VmJ1kcscygKsS17XPMdV7Hsn0WXQqpdwjP0Qk Qt2KsKX2udHBiPZjVkvGqqkxYe2DRHl3g41/ZZuDlp2YXrtjF2GaqB5Jrbvc3IKXwxdy I3DkwSb8p54iotNWwvnnLTcm+gZqBxKVszD1RYjtgfMqqnbdLJahsvyf928al5sZL1vI qk7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:cc:from:message-id:date :user-agent:mime-version:in-reply-to; bh=+b40xKvwabuAhN+PaEDV5dkww2ZN2WOUiNyqipBFklE=; b=Gwc8Sk2BsNEYVYfRRcweFv4LKJD5B0BHILpPZ6FuR9fympXQcgAiO3C0Q88qvEMWNw W8yzIeyCEnM20SczgPwukJn6rGi/N0GF1zVKqHXx74j+tfythPLymwNsVlMxpyZRSZRQ 532JZqh9mcDk06W2L8q1aFWxsUQjA3h18RRdBo/nVdculifDeP8z+LoLD2+UlkwzbSZ9 5u8R0jaGCBDp3P+8UVrFBrGyxJLGKkWiCr/N53mCPziKGjjfCrENGclje/03k0zHzrBB tUKtgAHL3NT94L21f4odoXbwv6cwNKfAArAaeFzznhjKNqFlKcYgUC1zwhAvvd6HAiw9 javA== X-Gm-Message-State: AD7BkJLB1X1g9N7b06UileT0JAHfzrMVCfv18Fh+X8bNlABRuk2UYNXUyGQu9P6HdDTDLw== X-Received: by 10.31.14.195 with SMTP id 186mr1836805vko.2.1456504360539; Fri, 26 Feb 2016 08:32:40 -0800 (PST) Received: from [100.46.236.144] ([100.46.236.144]) by smtp.gmail.com with ESMTPSA id p126sm1429204vkd.25.2016.02.26.08.32.37 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 26 Feb 2016 08:32:38 -0800 (PST) To: Valery Smyslov , Yoav Nir , "Waltermire, David A." References: <9DC60612-D5BC-4D55-8364-90DA5CAEB41F@gmail.com> <7480BF86-4EAD-4651-97B5-3B318FA010BA@gmail.com> <70EEDD2843564D589DCE9E96C84CB236@buildpc> From: Yaron Sheffer Message-ID: <56D07E24.1040805@gmail.com> Date: Fri, 26 Feb 2016 08:32:36 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <70EEDD2843564D589DCE9E96C84CB236@buildpc> Content-Type: multipart/alternative; boundary="------------040402050504020704000704" Archived-At: Cc: ipsec@ietf.org Subject: Re: [IPsec] Textual changes to the DDoS draft 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, 26 Feb 2016 16:32:43 -0000 This is a multi-part message in MIME format. --------------040402050504020704000704 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit After reading the pull request, I suggest that we require the responder to verify all 4 puzzles. Although I don't have a proof why this is better (e.g. a game theoretic cost/benefit analysis), it would remove an unnecessary design decision from implementations at a trivial cost in performance. Thanks, Yaron On 02/25/2016 09:50 PM, Valery Smyslov wrote: > That was also my impression. And the draft is already being edited to > include multiple puzzles. > Valery. > > ----- Original Message ----- > *From:* Yoav Nir > *To:* Waltermire, David A. > *Cc:* ipsec@ietf.org WG > *Sent:* Friday, February 26, 2016 8:43 AM > *Subject:* Re: [IPsec] Textual changes to the DDoS draft > > >> On 26 Feb 2016, at 2:03 AM, Waltermire, David A. >> > wrote: >> >> I haven’t seen any additional feedback on the DDoS draft this >> week based on Yoav’s note about the PR [1]. It also looks like >> the discussion on chaining puzzles has wrapped up with no changes >> needed to the draft [2]. > > Oh. My impression of [2] was that Valery and I were in agreement > that this change was a good idea, with Scott and Yaron supporting > (not quite as enthusiastically) and with not opinions to the > contrary. Valery and I thought we’d make this change over the > weekend. > > Yoav > > ------------------------------------------------------------------------ > _______________________________________________ > 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 --------------040402050504020704000704 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit After reading the pull request, I suggest that we require the responder to verify all 4 puzzles. Although I don't have a proof why this is better (e.g. a game theoretic cost/benefit analysis), it would remove an unnecessary design decision from implementations at a trivial cost in performance.

Thanks,
    Yaron

On 02/25/2016 09:50 PM, Valery Smyslov wrote:
That was also my impression. And the draft is already being edited to include multiple puzzles.
 
Valery.
----- Original Message -----
From: Yoav Nir
Sent: Friday, February 26, 2016 8:43 AM
Subject: Re: [IPsec] Textual changes to the DDoS draft


On 26 Feb 2016, at 2:03 AM, Waltermire, David A. <david.waltermire@nist.gov> wrote:

I haven’t seen any additional feedback on the DDoS draft this week based on Yoav’s note about the PR [1]. It also looks like the discussion on chaining puzzles has wrapped up with no changes needed to the draft [2].

Oh. My impression of [2] was that Valery and I were in agreement that this change was a good idea, with Scott and Yaron supporting (not quite as enthusiastically) and with not opinions to the contrary. Valery and I thought we’d make this change over the weekend.

Yoav

_______________________________________________
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

--------------040402050504020704000704-- From nobody Fri Feb 26 08:40:39 2016 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 A10E91ACE6E for ; Fri, 26 Feb 2016 08:40:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.106 X-Spam-Level: X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_ALL=0.8, RP_MATCHES_RCVD=-0.006] 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 wCzEu7xfM4US for ; Fri, 26 Feb 2016 08:40:36 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [193.110.157.68]) (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 329C61ACE68 for ; Fri, 26 Feb 2016 08:40:36 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 3qBcDK2h5zz1HH for ; Fri, 26 Feb 2016 17:40:33 +0100 (CET) X-OPENPGPKEY: Message passed unmodified X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id 8mLLWmn_kTb6 for ; Fri, 26 Feb 2016 17:40:32 +0100 (CET) Received: from bofh.nohats.ca (206-248-139-105.dsl.teksavvy.com [206.248.139.105]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Fri, 26 Feb 2016 17:40:32 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id D139E606625D; Fri, 26 Feb 2016 11:40:31 -0500 (EST) DKIM-Filter: OpenDKIM Filter v2.10.3 bofh.nohats.ca D139E606625D Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id D04756243B for ; Fri, 26 Feb 2016 11:40:31 -0500 (EST) Date: Fri, 26 Feb 2016 11:40:31 -0500 (EST) From: Paul Wouters To: "ipsec@ietf.org WG" Message-ID: User-Agent: Alpine 2.20 (LFD 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Content-Transfer-Encoding: 8BIT Archived-At: Subject: Re: [IPsec] IANA allocation of TIMEOUT_PERIOD_FOR_LIVENESS_CHECK (fwd) 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, 26 Feb 2016 16:40:37 -0000 On Fri, 26 Feb 2016, Valery Smyslov wrote: > thank you for providing more details. >   > However, it is not clear from this description what UE should do if it has a > data to be sent, > but it received no protected data for some perion of time. Section 2.4. of > RFC 7296 suggests that > the IKEv2 implementation performs a Liveness Check in this case: >   >    If no >    cryptographically protected messages have been received on an IKE SA >    or any of its Child SAs recently, the system needs to perform a >    liveness check in order to prevent sending messages to a dead peer. > It is not clear how this text is supposed to align with > TIMEOUT_PERIOD_FOR_LIVENESS_CHECK. > In other words - should UE in this situation perform a Liveness Check, > ignoring > the ePDG provided interval? Or should it ignore the possibility to send > data to a dead peer and perform Liveness Checks only on the specified > interval? While Ivo since did explain things a bit more, I think this does illustrate the point that IKEv2 implementors need enough guidance on these matters. That is really what an RFC does, even if it is not an ipsecme RFC and some independant stream submission. So I would like to urge the 3gpp world to reach out more to the ipsecme group and try to write up documentation in draft/RFC form. Because in the end, the IKE implementors will have to implement 3gpp requirements as well. Paul From nobody Mon Feb 29 04:59:17 2016 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 8F3611A883C for ; Mon, 29 Feb 2016 04:59:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.507 X-Spam-Level: X-Spam-Status: No, score=-14.507 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, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, 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 Dl1vT47GLWoW for ; Mon, 29 Feb 2016 04:59:15 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 229EB1A8838 for ; Mon, 29 Feb 2016 04:59:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1029; q=dns/txt; s=iport; t=1456750755; x=1457960355; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-transfer-encoding:mime-version; bh=gxbnPwORRduOMOIjk/a2CJuw3J06XQZaTAi3tNCsgPs=; b=BPSZbmYSRjN/5JAwS57/uF+P1l5aTkIa0qWbZkTqieClLPegCrUzUel9 8zVH5eXgTibxY/aL+MWsTaiILyI/VpSxgLUhTyNUqTtVtfDEctwoM/2bl zMPJP/8R8CYRuln2qElizzk5jLZGM2rnX216gEDz8qMY6fjXHFtbZZ5+z I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AOAgChP9RW/4oNJK1egzqBPwa6ZQENg?= =?us-ascii?q?WeGEwKBMDgUAQEBAQEBAWQnhEEBAQEEOj8MBAIBCA4DBAEBHwkHIREUCQgCBAE?= =?us-ascii?q?JBAUIE4dvAxK6Jw2EPQEBAQEBAQEBAQEBAQEBAQEBAQEBARWGEoQ6gjqGNQEEl?= =?us-ascii?q?wwBi22BbY57hwaHQwEeAQFCg2Rqh0V+AQEB?= X-IronPort-AV: E=Sophos;i="5.22,520,1449532800"; d="scan'208";a="77855430" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 29 Feb 2016 12:59:14 +0000 Received: from XCH-RCD-007.cisco.com (xch-rcd-007.cisco.com [173.37.102.17]) by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u1TCxE0R031549 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 29 Feb 2016 12:59:14 GMT Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-RCD-007.cisco.com (173.37.102.17) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Mon, 29 Feb 2016 06:59:13 -0600 Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1104.009; Mon, 29 Feb 2016 06:59:13 -0600 From: "Scott Fluhrer (sfluhrer)" To: Valery Smyslov , Michael Richardson Thread-Topic: [IPsec] draft-fluhrer-qr-ikev2-01 Thread-Index: AQHRcJ7EjFr+yeUwN0ep42DyONZ5ip8+YCgqgASgH5A= Date: Mon, 29 Feb 2016 12:59:13 +0000 Message-ID: <3a8cb4576b6b4b6da565496095e7f3dd@XCH-RCD-006.cisco.com> References: <46cc66173e324ae0b788f36cd58f5dfa@XCH-RCD-006.cisco.com><22220.36465.788794.855413@fireball.acr.fi><22222.1834.892900.623823@fireball.acr.fi><3C4D164CF08843258CE30B5B21363397@buildpc> <22222.63205.854356.14024@fireball.acr.fi> <7C69D4636A2541A686420EE56831F10B@buildpc> <4963.1456495533@obiwan.sandelman.ca> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.98.2.61] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: "ipsec@ietf.org" , Tero Kivinen Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01 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, 29 Feb 2016 12:59:16 -0000 > -----Original Message----- > From: Valery Smyslov [mailto:svanru@gmail.com] > Sent: Friday, February 26, 2016 9:19 AM > To: Michael Richardson > Cc: Scott Fluhrer (sfluhrer); Tero Kivinen; ipsec@ietf.org > Subject: Re: [IPsec] draft-fluhrer-qr-ikev2-01 >=20 > Hi Michael, >=20 > > > I think that the protection of IKE SA is important. This would pr= eserve > > > IKEv2 security properties (like protecting identities against pas= sive > > > attacker) and would allow to re-use the solution in G-IKEv2 and o= ther > > > IKEv2 derivations that do transfer sensitive information within I= KE SA. > > > > If the protection of the IKE SA means that we wind up in an IKEv1-like > > situation with Main Mode and group PSKs, then the result will be that > > IKE is not used. >=20 > Agree. But it is my understanding of the draft that it doesn't imply any > IKEv1 like group PSKs. It allows proper selection of pair-wise PSK. Yes, the intention is to allow someone to set up pairwise PPK's. From nobody Mon Feb 29 22:07:59 2016 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 50F4D1ACED7 for ; Mon, 29 Feb 2016 22:07:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.229 X-Spam-Level: X-Spam-Status: No, score=-1.229 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, 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 401eaCE8k2TK for ; Mon, 29 Feb 2016 22:07:56 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26F411ACED6 for ; Mon, 29 Feb 2016 22:07:56 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id j78so106275516lfb.1 for ; Mon, 29 Feb 2016 22:07:56 -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; bh=WwsURYDmd9Vake9bf4dJYSbWjwqFgnoxXZpHFEV8xnk=; b=MRPiOKXmSoyyyWW2quOBHTFD3OcbNUSq/afeLyz9tg9gi/t2El+OUcDdAJkTTKavSr 94solVOSNXgi3OU7BsXrOwZqnTN1vRGu7QiIH7P6akRhe0T8Nxb1gLRrswSuMO8utwxg Jj3FMnGIfaHv27DscAwj6yu8QrH5GH+JH0CIzly2dpDBkFoE2FdBHUB/YiVVJMX9xexw J/nhsvnI27NinujWuULBBNTnq3fo62Y5KdbYByi/IDZPTQdVVucCBStYn3pEUgvgSCrL 7sjHfqMf/CDcEBjvMmaBbxrwtVrmo0jvbroTlpepU9mCszW2nBH0/51r2K7bL04603/P JkQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:from:to:cc:references:subject:date :mime-version; bh=WwsURYDmd9Vake9bf4dJYSbWjwqFgnoxXZpHFEV8xnk=; b=YZzOA76kgAfLtG7PQFSGOVLZPRAnzFcKA8tn+jsRYQB+FuPijvezfs5CPDHhfkuO4y TvDaqZiPwnMuqqyv/uMBxFoHfZTCVJlVvAdXwRMjwhy8WfTB6zdb5hrB4E0ytLrHIduR S/CYk8L7ctglx+2EvMwvWYi0GQUnyA0IVW6ydv68hVwqAqBgggx6Xhoort6j8J/jizvL xfR5p7MGa/CNs0EZhoXJr/HXSIlReO0+2BHC0/l9U8uefOEdTzHAyTjXZC/LRe+ivTfS hwwniwjy8FmI4yyjiUtXdcEutf0WW77A9gtwS4BYDeRuIIPKFM49bUv9RIw+nrAmI7YP xLmw== X-Gm-Message-State: AD7BkJKiE92PKw3rQGBeKmeAG+iFT1l0oH0YL91O38sRNkzxYS3YiJU78YhU5G3VUCdvnw== X-Received: by 10.25.211.73 with SMTP id k70mr3145243lfg.119.1456812474274; Mon, 29 Feb 2016 22:07:54 -0800 (PST) Received: from buildpc ([82.138.51.4]) by smtp.gmail.com with ESMTPSA id h72sm4688098lfe.33.2016.02.29.22.07.53 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 29 Feb 2016 22:07:53 -0800 (PST) Message-ID: From: "Valery Smyslov" To: "Yoav Nir" , "Waltermire, David A." , "Yaron Sheffer" References: <9DC60612-D5BC-4D55-8364-90DA5CAEB41F@gmail.com> <7480BF86-4EAD-4651-97B5-3B318FA010BA@gmail.com> <70EEDD2843564D589DCE9E96C84CB236@buildpc> <56D07E24.1040805@gmail.com> Date: Tue, 1 Mar 2016 09:07:55 +0300 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_061B_01D17399.D7D77FF0" 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: Cc: ipsec@ietf.org Subject: Re: [IPsec] Textual changes to the DDoS draft 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, 01 Mar 2016 06:07:58 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_061B_01D17399.D7D77FF0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable Hi Yaron, I also think that it's more safe to verify all 4 results (that's why = it's SHOULD).=20 If nobody objects we can make it MUST for the sake of security and = simplicity. Regards, Valery. ----- Original Message -----=20 From: Yaron Sheffer=20 To: Valery Smyslov ; Yoav Nir ; Waltermire, David A.=20 Cc: ipsec@ietf.org=20 Sent: Friday, February 26, 2016 7:32 PM Subject: Re: [IPsec] Textual changes to the DDoS draft After reading the pull request, I suggest that we require the = responder to verify all 4 puzzles. Although I don't have a proof why = this is better (e.g. a game theoretic cost/benefit analysis), it would = remove an unnecessary design decision from implementations at a trivial = cost in performance. Thanks, Yaron On 02/25/2016 09:50 PM, Valery Smyslov wrote: That was also my impression. And the draft is already being edited = to include multiple puzzles. Valery. ----- Original Message -----=20 From: Yoav Nir=20 To: Waltermire, David A.=20 Cc: ipsec@ietf.org WG=20 Sent: Friday, February 26, 2016 8:43 AM Subject: Re: [IPsec] Textual changes to the DDoS draft On 26 Feb 2016, at 2:03 AM, Waltermire, David A. = wrote: I haven=92t seen any additional feedback on the DDoS draft this = week based on Yoav=92s note about the PR [1]. It also looks like the = discussion on chaining puzzles has wrapped up with no changes needed to = the draft [2]. Oh. My impression of [2] was that Valery and I were in agreement = that this change was a good idea, with Scott and Yaron supporting (not = quite as enthusiastically) and with not opinions to the contrary. Valery = and I thought we=92d make this change over the weekend.=20 Yoav -------------------------------------------------------------------------= - _______________________________________________ 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 ------=_NextPart_000_061B_01D17399.D7D77FF0 Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: quoted-printable
Hi Yaron,
 
I also think that it's more safe to verify all 4 = results=20 (that's why it's SHOULD).
If nobody objects we can make it MUST for the sake = of security=20 and simplicity.
 
Regards,
Valery.
 
----- Original Message -----
From:=20 Yaron=20 Sheffer
To: Valery Smyslov ; Yoav = Nir ; Waltermire, David A. =
Sent: Friday, February 26, 2016 = 7:32=20 PM
Subject: Re: [IPsec] Textual = changes to=20 the DDoS draft

After reading the pull request, I suggest that we = require the=20 responder to verify all 4 puzzles. Although I don't have a proof why = this is=20 better (e.g. a game theoretic cost/benefit analysis), it would remove = an=20 unnecessary design decision from implementations at a trivial cost in=20 performance.

Thanks,
    Yaron

On 02/25/2016 09:50 PM, Valery Smyslov=20 wrote:
That was also my impression. And the draft is = already=20 being edited to include multiple puzzles.
 
Valery.
----- Original Message ----- =
From:=20 Yoav Nir
To: Waltermire, David A.
Sent: Friday, February 26, = 2016 8:43=20 AM
Subject: Re: [IPsec] = Textual changes=20 to the DDoS draft


On 26 Feb 2016, at 2:03 AM, Waltermire, David A. <david.waltermire@nist.gov>=20 wrote:

I=20 haven=92t seen any additional feedback on the DDoS draft this = week based=20 on Yoav=92s note about the PR [1]. It also looks like the = discussion on=20 chaining puzzles has wrapped up with no changes needed to the = draft=20 [2].

Oh. My impression of [2] was that Valery and = I were=20 in agreement that this change was a good idea, with Scott and = Yaron=20 supporting (not quite as enthusiastically) and with not opinions = to the=20 contrary. Valery and I thought we=92d make this change over the = weekend.=20

Yoav

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


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

------=_NextPart_000_061B_01D17399.D7D77FF0--