From Internet-Drafts@ietf.org Wed Mar 2 12:00:02 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C7D13A6882; Wed, 2 Mar 2011 12:00:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.584 X-Spam-Level: X-Spam-Status: No, score=-102.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ImOdXt5RdQUc; Wed, 2 Mar 2011 12:00:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 92A7E3A687D; Wed, 2 Mar 2011 12:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110302200001.23854.49950.idtracker@localhost> Date: Wed, 02 Mar 2011 12:00:01 -0800 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ipsecha-protocol-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 20:00:02 -0000 --NextPart 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 : Protocol Support for High Availability of IKEv2/IPsec Author(s) : R. Jenwar, et al. Filename : draft-ietf-ipsecme-ipsecha-protocol-04.txt Pages : 23 Date : 2011-03-02 The IPsec protocol suite is widely used for business-critical network traffic. In order to make IPsec deployments highly available, more scalable and failure-resistant, they are often implemented as IPsec High Availability (HA) clusters. However there are many issues in IPsec HA clustering, and in particular in IKEv2 clustering. An earlier document, "IPsec Cluster Problem Statement", enumerates the issues encountered in the IKEv2/IPsec HA cluster environment. This document attempts to resolve these issues with the least possible change to the protocol. This document proposes an extension to the IKEv2 protocol to solve the main issues of "IPsec Cluster Problem Statement" in the commonly deployed hot-standby cluster, and provides implementation advice for other issues. The main issues to be solved are the synchronization of IKEv2 Message ID counters, and of IPsec Replay Counters. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ipsecha-protocol-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-ipsecha-protocol-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-02115918.I-D@ietf.org> --NextPart-- From yaronf.ietf@gmail.com Wed Mar 2 12:07:56 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C245C3A6831 for ; Wed, 2 Mar 2011 12:07:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vzhhfxIE3ZF5 for ; Wed, 2 Mar 2011 12:07:55 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 9A2083A6888 for ; Wed, 2 Mar 2011 12:07:55 -0800 (PST) Received: by bwz13 with SMTP id 13so602950bwz.31 for ; Wed, 02 Mar 2011 12:09:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=aLdrpodMW7IYR8KrmUM1jfbrPvD1YP3PsJPqkZkOklE=; b=iCS2pVB2hxMhkxfn+ZttuZci1NnRlYvMJjdTebphFcKGlQbWSCEP9LR4N/kSOl01Eq naFeGbigiwpxf44DN370M6AhgYf8NM+fP0QUA/rFVgd09P8XUyx+qUZf9i9rMtR2hzHn /MsXyY02V6ZIVUoHL5jIb0WJkslNhcyPQVzKU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=JbwHF9smRLbxWpiyKNDyC45eeYeSZTCeO3EkAidv/TebzJhD8I52+8hxp/1UIYi+uW 9JFyOOWgsUGTrEZBnTtgMJYiIUvIBWjMQDUlKbXQcvtV8W4Qn0EMGJCknDtNAQSu11SW N03TcP0uFXi5uJT9wz39o/v0wUWPTaS/6dzE4= Received: by 10.204.73.160 with SMTP id q32mr452500bkj.155.1299096541262; Wed, 02 Mar 2011 12:09:01 -0800 (PST) Received: from [10.0.0.5] ([109.66.6.124]) by mx.google.com with ESMTPS id b16sm237364bkw.14.2011.03.02.12.08.59 (version=SSLv3 cipher=OTHER); Wed, 02 Mar 2011 12:09:00 -0800 (PST) Message-ID: <4D6EA3DA.9020301@gmail.com> Date: Wed, 02 Mar 2011 22:08:58 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Lightning/1.0b2 Thunderbird/3.1.7 MIME-Version: 1.0 To: ipsec@ietf.org References: <20110302200001.23854.49950.idtracker@localhost> In-Reply-To: <20110302200001.23854.49950.idtracker@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-ipsecha-protocol-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Mar 2011 20:07:56 -0000 Hi, version -04 of the draft adds more discussion to Sec. 3, which deals with cluster-related issues *than than* synchronization of the SA counters. Enjoy! Yaron On 03/02/2011 10:00 PM, Internet-Drafts@ietf.org wrote: > 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 : Protocol Support for High Availability of IKEv2/IPsec > Author(s) : R. Jenwar, et al. > Filename : draft-ietf-ipsecme-ipsecha-protocol-04.txt > Pages : 23 > Date : 2011-03-02 > > The IPsec protocol suite is widely used for business-critical network > traffic. In order to make IPsec deployments highly available, more > scalable and failure-resistant, they are often implemented as IPsec > High Availability (HA) clusters. However there are many issues in > IPsec HA clustering, and in particular in IKEv2 clustering. An > earlier document, "IPsec Cluster Problem Statement", enumerates the > issues encountered in the IKEv2/IPsec HA cluster environment. This > document attempts to resolve these issues with the least possible > change to the protocol. > > This document proposes an extension to the IKEv2 protocol to solve > the main issues of "IPsec Cluster Problem Statement" in the commonly > deployed hot-standby cluster, and provides implementation advice for > other issues. The main issues to be solved are the synchronization > of IKEv2 Message ID counters, and of IPsec Replay Counters. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ipsecha-protocol-04.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From ynir@checkpoint.com Sun Mar 6 01:24:45 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 84E1D28C102 for ; Sun, 6 Mar 2011 01:24:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.571 X-Spam-Level: X-Spam-Status: No, score=-10.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6YLA4LEacDqL for ; Sun, 6 Mar 2011 01:24:44 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 20EE428C0FD for ; Sun, 6 Mar 2011 01:24:43 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p269Prbe014185; Sun, 6 Mar 2011 11:25:53 +0200 X-CheckPoint: {4D735319-D-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 6 Mar 2011 11:25:53 +0200 From: Yoav Nir To: "ipsec@ietf.org" , "draft-ietf-hokey-rfc5296bis@tools.ietf.org" Date: Sun, 6 Mar 2011 11:25:54 +0200 Thread-Topic: HOKEY draft draft-ietf-hokey-rfc5296bis Thread-Index: Acvb4H0S/jNuevgbQNavW5hOTBk76Q== Message-ID: <52DB5B6C-9E80-4C38-9BAF-30C883526952@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] HOKEY draft draft-ietf-hokey-rfc5296bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 09:24:45 -0000 Hi all I have just read the subject draft, and found this in section 6 (and simila= r text in the introduction): Note that to support ERP, lower-layer specifications may need to be revised. Specifically, the IEEE802.1x specification must be revised to allow carrying EAP messages of the new codes defined in this document in order to support ERP. Similarly, RFC 4306 must be updated to include EAP code values higher than 4 in order to use ERP with Internet Key Exchange Protocol version 2 (IKEv2). IKEv2 may also be updated to support peer-initiated ERP for optimized operation. Other lower layers may need similar revisions. Note that this is not new text, and it appears pretty much the same way in = RFC 5296. There's the obvious nit with this text, that RFC 4306 is not a reference. I= f it was, the id-nits would warn about this RFC being obsolete. But that's = the small problem here.=20 A bigger problem is that this text says that IKEv2 needs to be updated, but= there is no draft for this update, nor has there been any message to this = list about this proposed change.=20 The simple change they require is to section 3.16: o Code (1 octet) indicates whether this message is a Request (1), Response (2), Success (3), or Failure (4). I think this could be done with an errata or a 1-page draft, if all that wa= s required was pass-through of codes (5) and (6). But I think it's more inv= olved than that. There's peer-initiated ERP (which would require peer-initiated IKE?) and mu= ltiple simultaneous operations. I think it may come to a somewhat larger dr= aft. I think there should be at least a work-in-progress reference for 802.1x an= d IKEv2 before the hokey draft progresses. Yoav From ynir@checkpoint.com Sun Mar 6 01:44:34 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC0A63A6892 for ; Sun, 6 Mar 2011 01:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.273 X-Spam-Level: X-Spam-Status: No, score=-10.273 tagged_above=-999 required=5 tests=[AWL=-0.274, BAYES_00=-2.599, J_CHICKENPOX_46=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eU8OnVygEz6o for ; Sun, 6 Mar 2011 01:44:34 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 9BCB33A688C for ; Sun, 6 Mar 2011 01:44:33 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p269jiE5017317; Sun, 6 Mar 2011 11:45:44 +0200 X-CheckPoint: {4D7357C0-3-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 6 Mar 2011 11:45:44 +0200 From: Yoav Nir To: "ipsec@ietf.org" , "draft-ietf-hokey-rfc5296bis@tools.ietf.org" Date: Sun, 6 Mar 2011 11:45:45 +0200 Thread-Topic: [IPsec] HOKEY draft draft-ietf-hokey-rfc5296bis Thread-Index: Acvb40M5qW0V/yS+SmOuPZgsuS/qjQ== Message-ID: <32AEE889-483F-40F6-B089-6BD613C735D4@checkpoint.com> References: <52DB5B6C-9E80-4C38-9BAF-30C883526952@checkpoint.com> In-Reply-To: <52DB5B6C-9E80-4C38-9BAF-30C883526952@checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] HOKEY draft draft-ietf-hokey-rfc5296bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 06 Mar 2011 09:44:34 -0000 On Mar 6, 2011, at 11:25 AM, Yoav Nir wrote: >=20 > There's peer-initiated ERP (which would require peer-initiated IKE?) and = multiple simultaneous operations. I think it may come to a somewhat larger = draft. Sorry. peer=3Dremote access client, so peer-initiated IKE is the norm. They= real changes would be either allowing two EAP messages in a single IKE_AUT= H response, or something that's more lock-step than this: The authenticator MAY initiate the ERP exchange by sending the EAP-Initiate/Re-auth-Start message, and if there is no response, it will send the EAP-Request/ Identity message. =20 IKEv2 doesn't do "no response", so we'd have to respond either within EAP o= r in an IKE notification. Then we have a problem with how to communicate th= is to the back-end authentication server. Definitely looking like a big draft. From ynir@checkpoint.com Mon Mar 7 06:24:21 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 68BCF3A6962 for ; Mon, 7 Mar 2011 06:24:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.56 X-Spam-Level: X-Spam-Status: No, score=-10.56 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lrpQNxNDasHh for ; Mon, 7 Mar 2011 06:24:20 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id A7C6C3A67CF for ; Mon, 7 Mar 2011 06:24:19 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p27EPVYo003715 for ; Mon, 7 Mar 2011 16:25:32 +0200 X-CheckPoint: {4D74EACD-2-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 7 Mar 2011 16:25:31 +0200 From: Yoav Nir To: "ipsec@ietf.org" Date: Mon, 7 Mar 2011 16:25:34 +0200 Thread-Topic: SHA-512/256 Thread-Index: Acvc04Op1kYMf1CISiyI+AKiJwArXQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] SHA-512/256 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 14:24:21 -0000 Hi all RFC 4868 specifies some HMAC-SHA2 algorithms for IPsec: 12 AUTH_HMAC_SHA2_256_128 [RFC4868] 13 AUTH_HMAC_SHA2_384_192 [RFC4868] 14 AUTH_HMAC_SHA2_512_256 [RFC4868] Last year some researchers working for Intel published this report: http://eprint.iacr.org/2010/548.pdf It shows that optimized implementation of SHA-512 on 64-bit processors out-= perform SHA-256 implementations on the same processors. This would mean tha= t AUTH_HMAC_SHA2_512_256 could be faster than AUTH_HMAC_SHA2_256_128 (on 64= -bit Intel platforms if you have an optimized implementation) Now NIST has published this document update, that adds a new hash function:= SHA-512/256. That's SHA-512 (with the IV changed) truncated to 256 bits. http://csrc.nist.gov/publications/drafts/fips180-4/Draft-FIPS180-4_Feb2011.= pdf Is anyone interested in defining an AUTH_HMAC_SHA2_512_128, that would be e= ither SHA-512 truncated to 128 bits, or SHA-512/256 truncated to 128 bits? = From kivinen@iki.fi Mon Mar 7 07:57:52 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3095E3A67EE for ; Mon, 7 Mar 2011 07:57:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.562 X-Spam-Level: X-Spam-Status: No, score=-102.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S8Tj0Es117na for ; Mon, 7 Mar 2011 07:57:51 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 083BA3A67EC for ; Mon, 7 Mar 2011 07:57:50 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p27FwtcI003729 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 7 Mar 2011 17:58:55 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p27FwrFo019424; Mon, 7 Mar 2011 17:58:53 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19829.189.936439.449456@fireball.kivinen.iki.fi> Date: Mon, 7 Mar 2011 17:58:53 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: <52DB5B6C-9E80-4C38-9BAF-30C883526952@checkpoint.com> References: <52DB5B6C-9E80-4C38-9BAF-30C883526952@checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 6 min Cc: "ipsec@ietf.org" , "draft-ietf-hokey-rfc5296bis@tools.ietf.org" Subject: [IPsec] HOKEY draft draft-ietf-hokey-rfc5296bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 15:57:52 -0000 Yoav Nir writes: > A bigger problem is that this text says that IKEv2 needs to be > updated, but there is no draft for this update, nor has there been > any message to this list about this proposed change. > > The simple change they require is to section 3.16: > o Code (1 octet) indicates whether this message is a Request (1), > Response (2), Success (3), or Failure (4). Note also that section 2.16 says: While this document references [EAP] with the intent that new methods can be added in the future without updating this specification, some simpler variations are documented here. and section 3.16 says: Many of these methods have been defined, specifying the protocol's use with various authentication mechanisms. EAP method types are listed in [EAP-IANA]. A short summary of the EAP format is included here for clarity. meaning that the rfc5996 does not even try to be definite guide for EAP, it just includes some information about EAP protocol for clarity. > I think this could be done with an errata or a 1-page draft, if all > that was required was pass-through of codes (5) and (6). But I think > it's more involved than that. If it just for pass-through then I do not think even errata is needed, as it does not change the protocol. The EAP payload contains full EAP payloads inside, and the EAP payload format listed in the RFC5996 is only there for clarity and is not mean to be definite protocol description. If it changes anything else than pass-through codes not listed in the RFC5996 then new draft is needed. We should not make same mistakes again and do techinal changes in errata. -- kivinen@iki.fi From ynir@checkpoint.com Mon Mar 7 13:02:29 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D9D23A67E5 for ; Mon, 7 Mar 2011 13:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.564 X-Spam-Level: X-Spam-Status: No, score=-10.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MRJSdxZlyLne for ; Mon, 7 Mar 2011 13:02:28 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 305633A67CF for ; Mon, 7 Mar 2011 13:02:27 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p27L3eSa009084; Mon, 7 Mar 2011 23:03:40 +0200 X-CheckPoint: {4D75481C-0-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Mon, 7 Mar 2011 23:03:40 +0200 From: Yoav Nir To: Tero Kivinen Date: Mon, 7 Mar 2011 23:03:38 +0200 Thread-Topic: [IPsec] HOKEY draft draft-ietf-hokey-rfc5296bis Thread-Index: AcvdCyIrIX5vlMNaQTmRknRjXdbxSg== Message-ID: <475676D2-4382-44C1-BC69-46D555193CD0@checkpoint.com> References: <52DB5B6C-9E80-4C38-9BAF-30C883526952@checkpoint.com> <19829.189.936439.449456@fireball.kivinen.iki.fi> In-Reply-To: <19829.189.936439.449456@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" , "draft-ietf-hokey-rfc5296bis@tools.ietf.org" Subject: Re: [IPsec] HOKEY draft draft-ietf-hokey-rfc5296bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Mar 2011 21:02:29 -0000 On Mar 7, 2011, at 5:58 PM, Tero Kivinen wrote: > Yoav Nir writes: >> A bigger problem is that this text says that IKEv2 needs to be >> updated, but there is no draft for this update, nor has there been >> any message to this list about this proposed change. =20 >>=20 >> The simple change they require is to section 3.16: >> o Code (1 octet) indicates whether this message is a Request (1), >> Response (2), Success (3), or Failure (4). >=20 > Note also that section 2.16 says: >=20 > While this document references [EAP] with the intent that new methods > can be added in the future without updating this specification, some > simpler variations are documented here. >=20 > and section 3.16 says: >=20 > Many > of these methods have been defined, specifying the protocol's use > with various authentication mechanisms. EAP method types are listed > in [EAP-IANA]. A short summary of the EAP format is included here > for clarity. >=20 > meaning that the rfc5996 does not even try to be definite guide for > EAP, it just includes some information about EAP protocol for clarity.=20 Yes, and we got rid of the list of types that we had in 4306, but still, th= ere is text there that says that only requests and responses have types. No= t so under 5296. >=20 >> I think this could be done with an errata or a 1-page draft, if all >> that was required was pass-through of codes (5) and (6). But I think >> it's more involved than that. >=20 > If it just for pass-through then I do not think even errata is needed, > as it does not change the protocol. The EAP payload contains full EAP > payloads inside, and the EAP payload format listed in the RFC5996 is > only there for clarity and is not mean to be definite protocol > description. >=20 > If it changes anything else than pass-through codes not listed in the > RFC5996 then new draft is needed. We should not make same mistakes > again and do techinal changes in errata.=20 Unfortunately the changes are much more involved. the first IKE_AUTH respon= se would have to have not one, but two EAP messages, one for "initiate" and= one for "request identity". This conflicts with the usual practice in IKEv= 2 to have the identity in the first IKE_AUTH request, so you would be more = likely to have two EAP messages, one for "initiate", while the other is for= a specific EAP method. Alternatively, you could send just the "initiate" message. With EAP you wai= t, and if you get no response, you revert to "request identity" or "request= MSChapv2". There is no negative response to the "initiate" in ERP. But in = IKE, we can't wait, so we'd have to add an IKE-level notification that says= "no ERP response". Either way, it's a major enough change that you can't do it without negotia= ting the capability in either IKE_INIT or the IKE_AUTH request. So this becomes a big change, and AFAIK nobody's working on such a draft fo= r either IKEv2 or for 802.1x, which would require similar changes. From yaronf.ietf@gmail.com Mon Mar 7 23:34:26 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 33B0A3A6914; Mon, 7 Mar 2011 23:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nG-K3MePsIdu; Mon, 7 Mar 2011 23:34:25 -0800 (PST) Received: from mail-ww0-f44.google.com (mail-ww0-f44.google.com [74.125.82.44]) by core3.amsl.com (Postfix) with ESMTP id 6CA4C3A690F; Mon, 7 Mar 2011 23:34:24 -0800 (PST) Received: by wwa36 with SMTP id 36so386445wwa.13 for ; Mon, 07 Mar 2011 23:35:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=4XudQRBVXEBhmdFlucipV91/MGOcUc4A6J65lCV1zio=; b=nVUFR664LGF2bTsIqv5jXJZ54M+7qNeh6WvWAg8x0ehCF8l9j0N1YrndHjt0Zut58S OAJb2IwDqdWD7CNpG4rZ8i4JKUKT81mSWWjK25bmIvhfH4JqMRDc1A2Rxe2RWlsF2Wy0 Wx/sKzSNsadM/+bfln0TCPinObdS5Y3yw399U= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=NehwCKFg2ZMvwhBAGN+83CXtz1NYeSK2nhwuQtvNPpktdDeW4yBUL69ouZxLzpdb4q o58H5xAixkRHLXQhF9qPzme7bSC5aaKukJaJByMKMwQyq4XoX6xhLbHu/GtSHejf1O28 AoIpCe/Me84hHtCwBCLwizFu93VLcmIFozO1E= Received: by 10.227.199.210 with SMTP id et18mr428604wbb.227.1299569738258; Mon, 07 Mar 2011 23:35:38 -0800 (PST) Received: from [10.0.0.2] (93-173-136-159.bb.netvision.net.il [93.173.136.159]) by mx.google.com with ESMTPS id bd8sm364848wbb.13.2011.03.07.23.35.35 (version=SSLv3 cipher=OTHER); Mon, 07 Mar 2011 23:35:37 -0800 (PST) Message-ID: <4D75DC45.6080309@gmail.com> Date: Tue, 08 Mar 2011 09:35:33 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Glen Zorn References: <4D73575C.6090808@gmail.com> <4D75B5ED.1050108@net-zen.net> In-Reply-To: <4D75B5ED.1050108@net-zen.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG , Yoav Nir , Paul Hoffman , hokey@ietf.org, Stephen Farrell Subject: Re: [IPsec] Fwd: HOKEY draft draft-ietf-hokey-rfc5296bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 07:34:26 -0000 Hi Glen, thank you for your kind words. It is always a pleasure to help a fellow security working group, and your positive and helpful feedback makes it doubly so. Back to the subject at hand: EAP is one of the rare security protocols that are truly reusable. And in fact it is used by multiple protocols, including 802.1X, IKE and the TNC protocols. With success comes responsibility. If your working group makes significant, architectural changes to the protocol, it is *your responsibility* to ensure they can be accommodated by users of the protocol. And in the case of IETF working groups, it is indeed the job of the Security AD to ensure such coordination takes place. ERP is such a major change because (correct me if I am wrong): - Its transport behavior is different from the base EAP, allowing multiple exchanges to be in flight at the same time. - ERP peers actually *degrade* the behavior of EAP, because of timeouts/retransmissions introduced when talking to non-ERP auth servers, and similarly for ERP auth servers with non-ERP peers (this behavior is spelled out quite clearly on p. 8 of the bis draft). PS: I'm glad to hear that 802.1X-2010 supports ERP. I just wonder why the bis draft does not recognize this fact. Best regards, Yaron On 03/08/2011 06:51 AM, Glen Zorn wrote: > On 3/6/2011 4:43 PM, Yaron Sheffer wrote: >> Hi Stephen, >> >> I gather you are the incoming responsible AD for HOKEY. >> >> ERP (RFC 5296, now reincarnated as a bis document) is one of HOKEY's >> principal work items. The document is making major changes to EAP, and >> seems to have gotten a life of its own, despite the fact that AFAIU >> neither of its protocol users (802.1X and IKEv2) has been changed to >> accommodate it. It seems to me at best like wasted effort, more likely a >> disconnect between the working groups. > > > First of all, I'd like to express my deep appreciation (& I think that I > can speak for all the members of the hokey WG) for you kind concern for > the use of our time. It is especially wonderful since AFAIK you have > heretofore shown no interest at all in our activities; to extend > yourself in this way for a group with which you have essentially no > connection is truly magnanimous; and to go straight to the Area > Director, the one person who might be able to save us from this terrible > waste of effort & time! I must say that I find it hard to express in > words how it makes me feel. Nonetheless, I admit to some puzzlement as > to the rationale for this action: the referenced draft is a chartered > work item of the hokey WG, adopted after a call for consensus from the > members. Of course, you could not know about the call since you aren't a > WG member but it did occur. So while I do appreciate your obviously deep > and selfless concern, I am inclined to let the actual members of the WG > decide what (if anything) they deem worthy of effort. But, thanks again! > > P.S. > I'm pretty sure that IEEE 802.1X-2010 supports ERP. > >> >> Am I missing anything? >> >> Thanks, >> Yaron >> >> -------- Original Message -------- >> Subject: [IPsec] HOKEY draft draft-ietf-hokey-rfc5296bis >> Date: Sun, 6 Mar 2011 11:25:54 +0200 >> From: Yoav Nir >> To: ipsec@ietf.org , >> draft-ietf-hokey-rfc5296bis@tools.ietf.org >> >> >> Hi all >> >> I have just read the subject draft, and found this in section 6 (and >> similar text in the introduction): >> >> Note that to support ERP, lower-layer specifications may need to be >> revised. Specifically, the IEEE802.1x specification must be revised >> to allow carrying EAP messages of the new codes defined in this >> document in order to support ERP. Similarly, RFC 4306 must be >> updated to include EAP code values higher than 4 in order to use ERP >> with Internet Key Exchange Protocol version 2 (IKEv2). IKEv2 may >> also be updated to support peer-initiated ERP for optimized >> operation. Other lower layers may need similar revisions. >> >> Note that this is not new text, and it appears pretty much the same way >> in RFC 5296. >> >> There's the obvious nit with this text, that RFC 4306 is not a >> reference. If it was, the id-nits would warn about this RFC being >> obsolete. But that's the small problem here. >> >> A bigger problem is that this text says that IKEv2 needs to be updated, >> but there is no draft for this update, nor has there been any message to >> this list about this proposed change. >> >> The simple change they require is to section 3.16: >> o Code (1 octet) indicates whether this message is a Request (1), >> Response (2), Success (3), or Failure (4). >> >> I think this could be done with an errata or a 1-page draft, if all that >> was required was pass-through of codes (5) and (6). But I think it's >> more involved than that. >> >> There's peer-initiated ERP (which would require peer-initiated IKE?) and >> multiple simultaneous operations. I think it may come to a somewhat >> larger draft. >> >> I think there should be at least a work-in-progress reference for 802.1x >> and IKEv2 before the hokey draft progresses. >> >> Yoav >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> From sakane@tanu.org Mon Mar 7 17:18:47 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E24983A6971 for ; Mon, 7 Mar 2011 17:18:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.723 X-Spam-Level: X-Spam-Status: No, score=-0.723 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_EQ_JP=1.265] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyEaOYHG9n-9 for ; Mon, 7 Mar 2011 17:18:47 -0800 (PST) Received: from mama.tanu.org (z189134.ppp.asahi-net.or.jp [110.4.189.134]) by core3.amsl.com (Postfix) with ESMTP id ABCDB3A6926 for ; Mon, 7 Mar 2011 17:18:46 -0800 (PST) Received: from mactanu.local (dhcp-156-107.life.camp.wide.ad.jp [203.178.156.107]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by mama.tanu.org (Postfix) with ESMTPSA id 67FA216B07 for ; Tue, 8 Mar 2011 10:19:51 +0900 (JST) Message-ID: <4D7584D6.5020106@tanu.org> Date: Tue, 08 Mar 2011 10:22:30 +0900 From: Shoichi Sakane User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.14) Gecko/20110221 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: ipsec@ietf.org References: <19813.7472.338629.315817@fireball.kivinen.iki.fi> In-Reply-To: <19813.7472.338629.315817@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 08 Mar 2011 08:05:55 -0800 Subject: Re: [IPsec] New Version Notification for draft-kivinen-ipsecme-ikev2-minimal-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 01:18:48 -0000 I strongly support this draft. It must be useful for the implementers to develop IKEv2 to enable a kind of m2m communication with IPsec. This draft describes a scenario to use IKEv2 for a minimum specification. The document only allows one side to be a responder. I would like to a little extend it. That means it allows both sides to be a responder. Here is an example scenario, in a scenario of smart metering, both a meter and a server have a power line, but the power consumption should be lesser as much as possible. The network is lossy. The resource of the device is typically constrained, for example, memory or physical size. Shoichi Sakane On 2/23/11 11:44 PM, Tero Kivinen wrote: > I wrote draft about the minimal IKEv2 implementation. It does not try > to change anything in the RFC5996, it just explains what kind of > implementation would be useful in some machine to machine > communication scenarios and which would still be complient to the > RFC5996 (with an exception of not supporting certificates). > > The document contains 44 pages, from which the actual protocol > description is about 5 pages (IKE_SA_INIT and IKE_AUTH). Half of the > document is payload format diagrams copied from RFC5996. > > This document is meant for people who are not using IPsec for VPNs or > similar, but are thinking whether IPsec and IKEv2 could be used in for > small devices for machine to machine communications. > > ---------------------------------------------------------------------- > A new version of I-D, draft-kivinen-ipsecme-ikev2-minimal-00.txt has > been successfully submitted by Tero Kivinen and posted to the IETF > repository. > > Filename: draft-kivinen-ipsecme-ikev2-minimal > Revision: 00 > Title: Minimal IKEv2 > Creation_date: 2011-02-23 > WG ID: Independent Submission > Number_of_pages: 44 > > Abstract: > This document describes minimal version of the Internet Key Exchange > version 2 (IKEv2) protocol. IKEv2 is a component of IPsec used for > performing mutual authentication and establishing and maintaining > Security Associations (SAs). IKEv2 includes several optional > features, which are not needed in minimal implementations. This > document describes what is required from the minimal implementation, > and also describes various optimizations which can be done. The > protocol described here is compliant with full IKEv2 with exception > that this document only describes shared secret authentication (IKEv2 > requires support for certificate authentication in addition to shared > secret authentication). > > This document does not update or modify RFC 5996, but provides more > compact description of the minimal version of the protocol. If this > document and RFC 5996 conflicts then RFC 5996 is the authoritative > description. From stephen.farrell@cs.tcd.ie Tue Mar 8 01:40:51 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A0BD3A67EB; Tue, 8 Mar 2011 01:40:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.909 X-Spam-Level: X-Spam-Status: No, score=-102.909 tagged_above=-999 required=5 tests=[AWL=-0.310, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSa21PD003ZH; Tue, 8 Mar 2011 01:40:49 -0800 (PST) Received: from scss.tcd.ie (hermes.cs.tcd.ie [IPv6:2001:770:10:200:21b:21ff:fe3a:3d50]) by core3.amsl.com (Postfix) with ESMTP id 7A2D73A6774; Tue, 8 Mar 2011 01:40:48 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hermes.scss.tcd.ie (Postfix) with ESMTP id A8D803E4083; Tue, 8 Mar 2011 09:42:01 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; h= content-transfer-encoding:content-type:in-reply-to:references :subject:mime-version:user-agent:from:date:message-id:received :received:x-virus-scanned; s=cs; t=1299577321; bh=6WsKwcIZi+36Vb UytmQh89uSaPLGwKBShvn7V2HWAZY=; b=o1LYALnmtiX+5AenmRRKm6maxw5vWl 6aUNzKxBEvA9tINHIDS7dL/EbV1tOCepcAiKXyOK2wJqRzWoYUrRa76kuPv7VLwA 5FYdswmnvLr1OsPA0dwcQHhVZ2PTGgP5rEA3L93v7zX5g43zCvcX2FWzTxqCbz0F E8I/soF3VCX0Qc1YTAj+gRNOUfB5NABClGgu6dTLASujAo2Rdw7hQFe2OW+fXSXR pswaZoelgpu64ht1OLG3m739pnPWj8lltFrcNftCPKKA5D3Wk0whoqh2KABUAvUb wkgpmgY/MXId8NYTBb0euyI6P8oGDncn1wwjp8od7B44gU058DLlb+bA== X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from scss.tcd.ie ([127.0.0.1]) by localhost (scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10027) with ESMTP id 2F7yZDJqIM9c; Tue, 8 Mar 2011 09:42:01 +0000 (GMT) Received: from [10.87.48.7] (dsl-102-234.cust.imagine.ie [87.232.102.234]) by smtp.scss.tcd.ie (Postfix) with ESMTPSA id 78F943E4080; Tue, 8 Mar 2011 09:41:58 +0000 (GMT) Message-ID: <4D75F9E5.7060302@cs.tcd.ie> Date: Tue, 08 Mar 2011 09:41:57 +0000 From: Stephen Farrell User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: hokey@ietf.org, IPsecme WG References: <4D73575C.6090808@gmail.com> <4D75B5ED.1050108@net-zen.net> <4D75DC45.6080309@gmail.com> In-Reply-To: <4D75DC45.6080309@gmail.com> X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Mailman-Approved-At: Tue, 08 Mar 2011 08:05:55 -0800 Cc: Yoav Nir , Glen Zorn , Paul Hoffman Subject: Re: [IPsec] Fwd: HOKEY draft draft-ietf-hokey-rfc5296bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 09:40:51 -0000 In case anyone wonders, my reply to Yaron was basically: "I dunno & will be interested to find out if you're missing something or not" S. On 08/03/11 07:35, Yaron Sheffer wrote: > Hi Glen, > > thank you for your kind words. It is always a pleasure to help a fellow > security working group, and your positive and helpful feedback makes it > doubly so. > > Back to the subject at hand: EAP is one of the rare security protocols > that are truly reusable. And in fact it is used by multiple protocols, > including 802.1X, IKE and the TNC protocols. With success comes > responsibility. If your working group makes significant, architectural > changes to the protocol, it is *your responsibility* to ensure they can > be accommodated by users of the protocol. And in the case of IETF > working groups, it is indeed the job of the Security AD to ensure such > coordination takes place. > > ERP is such a major change because (correct me if I am wrong): > > - Its transport behavior is different from the base EAP, allowing > multiple exchanges to be in flight at the same time. > - ERP peers actually *degrade* the behavior of EAP, because of > timeouts/retransmissions introduced when talking to non-ERP auth > servers, and similarly for ERP auth servers with non-ERP peers (this > behavior is spelled out quite clearly on p. 8 of the bis draft). > > PS: I'm glad to hear that 802.1X-2010 supports ERP. I just wonder why > the bis draft does not recognize this fact. > > Best regards, > > Yaron > > On 03/08/2011 06:51 AM, Glen Zorn wrote: >> On 3/6/2011 4:43 PM, Yaron Sheffer wrote: >>> Hi Stephen, >>> >>> I gather you are the incoming responsible AD for HOKEY. >>> >>> ERP (RFC 5296, now reincarnated as a bis document) is one of HOKEY's >>> principal work items. The document is making major changes to EAP, and >>> seems to have gotten a life of its own, despite the fact that AFAIU >>> neither of its protocol users (802.1X and IKEv2) has been changed to >>> accommodate it. It seems to me at best like wasted effort, more likely a >>> disconnect between the working groups. >> >> >> First of all, I'd like to express my deep appreciation (& I think that I >> can speak for all the members of the hokey WG) for you kind concern for >> the use of our time. It is especially wonderful since AFAIK you have >> heretofore shown no interest at all in our activities; to extend >> yourself in this way for a group with which you have essentially no >> connection is truly magnanimous; and to go straight to the Area >> Director, the one person who might be able to save us from this terrible >> waste of effort & time! I must say that I find it hard to express in >> words how it makes me feel. Nonetheless, I admit to some puzzlement as >> to the rationale for this action: the referenced draft is a chartered >> work item of the hokey WG, adopted after a call for consensus from the >> members. Of course, you could not know about the call since you aren't a >> WG member but it did occur. So while I do appreciate your obviously deep >> and selfless concern, I am inclined to let the actual members of the WG >> decide what (if anything) they deem worthy of effort. But, thanks again! >> >> P.S. >> I'm pretty sure that IEEE 802.1X-2010 supports ERP. >> >>> >>> Am I missing anything? >>> >>> Thanks, >>> Yaron >>> >>> -------- Original Message -------- >>> Subject: [IPsec] HOKEY draft draft-ietf-hokey-rfc5296bis >>> Date: Sun, 6 Mar 2011 11:25:54 +0200 >>> From: Yoav Nir >>> To: ipsec@ietf.org , >>> draft-ietf-hokey-rfc5296bis@tools.ietf.org >>> >>> >>> Hi all >>> >>> I have just read the subject draft, and found this in section 6 (and >>> similar text in the introduction): >>> >>> Note that to support ERP, lower-layer specifications may need to be >>> revised. Specifically, the IEEE802.1x specification must be revised >>> to allow carrying EAP messages of the new codes defined in this >>> document in order to support ERP. Similarly, RFC 4306 must be >>> updated to include EAP code values higher than 4 in order to use ERP >>> with Internet Key Exchange Protocol version 2 (IKEv2). IKEv2 may >>> also be updated to support peer-initiated ERP for optimized >>> operation. Other lower layers may need similar revisions. >>> >>> Note that this is not new text, and it appears pretty much the same way >>> in RFC 5296. >>> >>> There's the obvious nit with this text, that RFC 4306 is not a >>> reference. If it was, the id-nits would warn about this RFC being >>> obsolete. But that's the small problem here. >>> >>> A bigger problem is that this text says that IKEv2 needs to be updated, >>> but there is no draft for this update, nor has there been any message to >>> this list about this proposed change. >>> >>> The simple change they require is to section 3.16: >>> o Code (1 octet) indicates whether this message is a Request (1), >>> Response (2), Success (3), or Failure (4). >>> >>> I think this could be done with an errata or a 1-page draft, if all that >>> was required was pass-through of codes (5) and (6). But I think it's >>> more involved than that. >>> >>> There's peer-initiated ERP (which would require peer-initiated IKE?) and >>> multiple simultaneous operations. I think it may come to a somewhat >>> larger draft. >>> >>> I think there should be at least a work-in-progress reference for 802.1x >>> and IKEv2 before the hokey draft progresses. >>> >>> Yoav >>> >>> _______________________________________________ >>> IPsec mailing list >>> IPsec@ietf.org >>> https://www.ietf.org/mailman/listinfo/ipsec >>> >>> > From ynir@checkpoint.com Tue Mar 8 13:29:28 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E9EB3A659B for ; Tue, 8 Mar 2011 13:29:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.566 X-Spam-Level: X-Spam-Status: No, score=-10.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goJIMPM1zHYC for ; Tue, 8 Mar 2011 13:29:27 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 23BCC3A6405 for ; Tue, 8 Mar 2011 13:29:25 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p28LUcE2017557; Tue, 8 Mar 2011 23:30:38 +0200 X-CheckPoint: {4D769FE8-12-1B221DC2-FFFF} Received: from il-ex03.ad.checkpoint.com (194.29.34.71) by il-ex01.ad.checkpoint.com (194.29.34.26) with Microsoft SMTP Server (TLS) id 8.2.255.0; Tue, 8 Mar 2011 23:30:38 +0200 Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex03.ad.checkpoint.com ([194.29.34.71]) with mapi; Tue, 8 Mar 2011 23:30:37 +0200 From: Yoav Nir To: Shoichi Sakane Date: Tue, 8 Mar 2011 23:30:36 +0200 Thread-Topic: [IPsec] New Version Notification for draft-kivinen-ipsecme-ikev2-minimal-00 Thread-Index: Acvd2BDUoJIya03ZTcS4L5O5O30ECg== Message-ID: <40B4A2F1-6D6E-4CFA-8053-999A069BE025@checkpoint.com> References: <19813.7472.338629.315817@fireball.kivinen.iki.fi> <4D7584D6.5020106@tanu.org> In-Reply-To: <4D7584D6.5020106@tanu.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] New Version Notification for draft-kivinen-ipsecme-ikev2-minimal-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 08 Mar 2011 21:29:28 -0000 I also agree that this draft is useful, and I support its going forward, ei= ther as a WG document or as an individual document.=20 While data communications may originate from either side (sensor notifies c= ontroller, controller queries sensor, controller sends command to actuator)= , I think it is reasonable to require that IKE be initiated from the "thing= ", for two reasons: 1. It cuts down the required code almost in half 2. The "things" often sleep for extended periods of time, so you can't dep= end on them being able to respond. There are two things I'm wondering about, though. Why is this draft written= like a mini-RFC5996, instead of just referencing 5996 and describing a pro= file. You could skip all of Appendix A and much of the explanation in secti= on 2.=20 Also, what happens with SA expiry? According to section 2.1, the "thing" C= annot send delete payloads in Informational exchanges. I guess it could jus= t create a new IKE SA if its policy says that the old one has expired. But = if the SA expires first on the controller, either the "thing" is sleeping a= nd will miss the DELETE payload, or it's not sleeping, and will ignore the = DELETE payload. Either way, you're stuck with an SA that exists on the "thi= ng" but not on the controller. I can think of three ways to avoid this: You can require that SA lifetimes = be always shorter on the "thing" than on the controller. You can require th= em to explicitly send SA lifetimes. Or you can require them to implement fa= ilure detection. Yoav On Mar 8, 2011, at 3:22 AM, Shoichi Sakane wrote: > I strongly support this draft. It must be useful for the implementers > to develop IKEv2 to enable a kind of m2m communication with IPsec. >=20 > This draft describes a scenario to use IKEv2 for a minimum specification. > The document only allows one side to be a responder. I would like to a > little extend it. That means it allows both sides to be a responder. > Here is an example scenario, in a scenario of smart metering, both a > meter and a server have a power line, but the power consumption should > be lesser as much as possible. The network is lossy. The resource of > the device is typically constrained, for example, memory or physical size= . >=20 > Shoichi Sakane >=20 > On 2/23/11 11:44 PM, Tero Kivinen wrote: >> I wrote draft about the minimal IKEv2 implementation. It does not try >> to change anything in the RFC5996, it just explains what kind of >> implementation would be useful in some machine to machine >> communication scenarios and which would still be complient to the >> RFC5996 (with an exception of not supporting certificates). >>=20 >> The document contains 44 pages, from which the actual protocol >> description is about 5 pages (IKE_SA_INIT and IKE_AUTH). Half of the >> document is payload format diagrams copied from RFC5996. >>=20 >> This document is meant for people who are not using IPsec for VPNs or >> similar, but are thinking whether IPsec and IKEv2 could be used in for >> small devices for machine to machine communications. >>=20 >> ---------------------------------------------------------------------- >> A new version of I-D, draft-kivinen-ipsecme-ikev2-minimal-00.txt has >> been successfully submitted by Tero Kivinen and posted to the IETF >> repository. >>=20 >> Filename: draft-kivinen-ipsecme-ikev2-minimal >> Revision: 00 >> Title: Minimal IKEv2 >> Creation_date: 2011-02-23 >> WG ID: Independent Submission >> Number_of_pages: 44 >>=20 >> Abstract: >> This document describes minimal version of the Internet Key Exchange >> version 2 (IKEv2) protocol. IKEv2 is a component of IPsec used for >> performing mutual authentication and establishing and maintaining >> Security Associations (SAs). IKEv2 includes several optional >> features, which are not needed in minimal implementations. This >> document describes what is required from the minimal implementation, >> and also describes various optimizations which can be done. The >> protocol described here is compliant with full IKEv2 with exception >> that this document only describes shared secret authentication (IKEv2 >> requires support for certificate authentication in addition to shared >> secret authentication). >>=20 >> This document does not update or modify RFC 5996, but provides more >> compact description of the minimal version of the protocol. If this >> document and RFC 5996 conflicts then RFC 5996 is the authoritative >> description. > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec >=20 > Scanned by Check Point Total Security Gateway. From kivinen@iki.fi Wed Mar 9 06:51:12 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC33E3A6874 for ; Wed, 9 Mar 2011 06:51:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.566 X-Spam-Level: X-Spam-Status: No, score=-102.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i6v0xdeSu6X5 for ; Wed, 9 Mar 2011 06:51:12 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 989163A6A02 for ; Wed, 9 Mar 2011 06:51:11 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p29EqNPp011299 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Mar 2011 16:52:23 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p29EqK5U017383; Wed, 9 Mar 2011 16:52:20 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19831.37923.942183.579998@fireball.kivinen.iki.fi> Date: Wed, 9 Mar 2011 16:52:19 +0200 From: Tero Kivinen To: Shoichi Sakane In-Reply-To: <4D7584D6.5020106@tanu.org> References: <19813.7472.338629.315817@fireball.kivinen.iki.fi> <4D7584D6.5020106@tanu.org> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 7 min Cc: ipsec@ietf.org Subject: Re: [IPsec] New Version Notification for draft-kivinen-ipsecme-ikev2-minimal-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 14:51:13 -0000 Shoichi Sakane writes: > This draft describes a scenario to use IKEv2 for a minimum specification. > The document only allows one side to be a responder. More correct way is to say, that this document only describes the node which is always the initiator of the communication. > I would like to a little extend it. That means it allows both sides > to be a responder. To be able to act as responder requires to take more features from the full IKEv2, and very soon you are better of with full IKEv2 implementation. For example to be able to act as responder usually means that you need to have some kind of policy decision module, i.e. which when given the identity of the initiator will check whether that peer is allowed to create connections, use specific algorithms, or do other things. In the initiator end it is usually simple, as you simply only offer the things you support, and when you are initiating the connection you already have your policy specified. > Here is an example scenario, in a scenario of smart metering, both a > meter and a server have a power line, but the power consumption > should be lesser as much as possible. The network is lossy. The > resource of the device is typically constrained, for example, memory > or physical size. I would except that the smart meter meter would be the one using implementation like described in draft-kivinen-ipsecme-ikev2-minimal, and the server where that meter connects to needs to support full IKEv2. For example usually there is multiple meters for each server meaning that the server needs to support multiple simultaneous IKEv2 SAs, IPsec SAs, and it needs to do policy lookups based on the identity of the meter device etc. In the server end there is also some features of the IKEv2 which can be left out (for example configuration mode, nat traversal (depending on the network), etc), but in this document I tried to concentrate on the very minimal implementation. -- kivinen@iki.fi From kivinen@iki.fi Wed Mar 9 07:05:54 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5984C3A6821 for ; Wed, 9 Mar 2011 07:05:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.569 X-Spam-Level: X-Spam-Status: No, score=-102.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cbkAh0fFcGU8 for ; Wed, 9 Mar 2011 07:05:52 -0800 (PST) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id A11763A69DC for ; Wed, 9 Mar 2011 07:05:50 -0800 (PST) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p29F73cX027501 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 9 Mar 2011 17:07:03 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p29F72Ae028700; Wed, 9 Mar 2011 17:07:02 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19831.38806.774182.971399@fireball.kivinen.iki.fi> Date: Wed, 9 Mar 2011 17:07:02 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: <40B4A2F1-6D6E-4CFA-8053-999A069BE025@checkpoint.com> References: <19813.7472.338629.315817@fireball.kivinen.iki.fi> <4D7584D6.5020106@tanu.org> <40B4A2F1-6D6E-4CFA-8053-999A069BE025@checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 8 min Cc: Shoichi Sakane , "ipsec@ietf.org" Subject: Re: [IPsec] New Version Notification for draft-kivinen-ipsecme-ikev2-minimal-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 15:05:54 -0000 Yoav Nir writes: > There are two things I'm wondering about, though. Why is this draft > written like a mini-RFC5996, instead of just referencing 5996 and > describing a profile. You could skip all of Appendix A and much of > the explanation in section 2. One of the reasons is that I wanted the document to include things that implementor needs. If I would require implementor to read RFC5996 in addition to this draft, that would not help them to make implementations. Now the current document tries to be short enough that people will see that "ok, this is something we can implement" especially when they see that the most of the pages is simply payload format descriptions, which they can simply read when they are actually writing that payload encoding/decoding, and otherwise skip over. > Also, what happens with SA expiry? According to section 2.1, the > "thing" Cannot send delete payloads in Informational exchanges. SA expiry is not an required feature of IKEv2. It is completely possible that IKEv2 node looses IKE SA without sending delete notification, and starts from the beginning. For the minimal devices they can completely forget the IKEv2 SA (and IPsec SA) when they go to sleep, and recreate it every time they wake up, i.e. the sleeping is more less a "turning off" and "booting up again". Or they can keep the IKE SA and Child SA up and assume the server will is configured so it will keep it up, and do not expire the SA based on the time. Those SAs usually has so little data going through them that there is no need to rekey SA based on the time. For some cases there might be more data (for example video feed from camera), but in that case minimal implementation is not enough anymore, as in that case you do usually need support for rekeys. > I guess it could just create a new IKE SA if its policy says that > the old one has expired. But if the SA expires first on the > controller, either the "thing" is sleeping and will miss the DELETE > payload, or it's not sleeping, and will ignore the DELETE payload. > Either way, you're stuck with an SA that exists on the "thing" but > not on the controller. If the "thing" is configured so that it keeps IKE SA up, then the server should configured so that it does not expire the SA. Most of those protocols include reply anyways, so if no reply is received the "thing" can start over, i.e remove the IKE SA and recrete it from the scratch and then try again. > I can think of three ways to avoid this: You can require that SA > lifetimes be always shorter on the "thing" than on the controller. Or remove the concept of lifetimes, as they are not needed here. > You can require them to explicitly send SA lifetimes. Lifetimes in IKEv2 is local matter, and they are never transmitted. > Or you can require them to implement failure detection. No need for that. -- kivinen@iki.fi From yaronf.ietf@gmail.com Wed Mar 9 11:32:59 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 824F63A6892 for ; Wed, 9 Mar 2011 11:32:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qah1P4sg2-8F for ; Wed, 9 Mar 2011 11:32:58 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 528303A692B for ; Wed, 9 Mar 2011 11:32:58 -0800 (PST) Received: by bwz13 with SMTP id 13so1104261bwz.31 for ; Wed, 09 Mar 2011 11:34:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:content-type:content-transfer-encoding; bh=5RMcZoBoNzlDBxOBm69EliiNND5+9FclRBQNF1vM4EI=; b=OEn3dtlSDBC3AHRtNLEr4LuhaLJ8XXk6CF4CycE11Hfbav/0hWojDWksbX/jNJWFIh yf599RkKLOADl/e5tNMYfDkzuGkmPqbhXEYu/Ta3TiS9OKEeo7OoDKIJ+MICkmDhOjf0 8WjyxdiTkSXohDRTmJFooMym6W/Bee+8fJGbY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject :content-type:content-transfer-encoding; b=Hb15MFAyUmUWCT+DQeGl5u8t23GWE0wtFJhLUldo7wWspmfkZfv9ApbG5ItF3bxUe0 v6OuZVxt6y4xerbbyNffTrXbUGLdX5DpVANu2mOIlRj2VJy+eZ/sx95XAtoCHVCHNKpj mlBu0ZJDGERElRXhxYE2NytK35NJTm6+oM+jM= Received: by 10.204.82.143 with SMTP id b15mr5945257bkl.118.1299699254073; Wed, 09 Mar 2011 11:34:14 -0800 (PST) Received: from [10.0.0.5] ([109.66.23.223]) by mx.google.com with ESMTPS id z18sm1568305bkf.8.2011.03.09.11.34.12 (version=SSLv3 cipher=OTHER); Wed, 09 Mar 2011 11:34:13 -0800 (PST) Message-ID: <4D77D633.8070903@gmail.com> Date: Wed, 09 Mar 2011 21:34:11 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: IPsecme WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [IPsec] WG Last Call on draft-ietf-ipsecme-ipsecha-protocol X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Mar 2011 19:32:59 -0000 This begins a two-week Working Group Last Call on draft-ietf-ipsecme-ipsecha-protocol. You can find the current version at http://tools.ietf.org/html/draft-ietf-ipsecme-ipsecha-protocol-04. We want everyone in the WG to read the document and comment on it, even if the comment is "I support this" or "I am neutral on this". If you oppose moving the draft forwards, or you have technical changes you want made, please be explicit in your message. Feel free to start new threads if you are objecting or suggesting changes. The authors will manage any such discussions using the issue tracker. The WG previously reached consensus on a problem statement for IPsec High Availability, http://tools.ietf.org/html/rfc6027. You may wish to refer to that RFC, first, to frame the problem, and second, to convince yourselves that the current document actually addresses it in full. Thanks, Yaron From Internet-Drafts@ietf.org Thu Mar 10 12:15:04 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EF0943A6A82; Thu, 10 Mar 2011 12:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DAgT2pmEv0ot; Thu, 10 Mar 2011 12:15:03 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EEC013A6A12; Thu, 10 Mar 2011 12:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110310201501.27968.18959.idtracker@localhost> Date: Thu, 10 Mar 2011 12:15:01 -0800 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 20:15:04 -0000 --NextPart 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 : A Quick Crash Detection Method for IKE Author(s) : Y. Nir, et al. Filename : draft-ietf-ipsecme-failure-detection-06.txt Pages : 23 Date : 2011-03-10 This document describes an extension to the IKEv2 protocol that allows for faster detection of SA desynchronization using a saved token. When an IPsec tunnel between two IKEv2 peers is disconnected due to a restart of one peer, it can take as much as several minutes for the other peer to discover that the reboot has occurred, thus delaying recovery. In this text we propose an extension to the protocol, that allows for recovery immediately following the restart. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-failure-detection-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-failure-detection-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-10121401.I-D@ietf.org> --NextPart-- From ynir@checkpoint.com Thu Mar 10 12:34:44 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2BC253A692B for ; Thu, 10 Mar 2011 12:34:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.564 X-Spam-Level: X-Spam-Status: No, score=-10.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5n72XUnbBU0b for ; Thu, 10 Mar 2011 12:34:43 -0800 (PST) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id C22933A67F8 for ; Thu, 10 Mar 2011 12:34:42 -0800 (PST) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p2AKZx0i031167 for ; Thu, 10 Mar 2011 22:35:59 +0200 X-CheckPoint: {4D79360F-0-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Thu, 10 Mar 2011 22:35:59 +0200 From: Yoav Nir To: "ipsec@ietf.org" Date: Thu, 10 Mar 2011 22:35:58 +0200 Thread-Topic: I-D Action:draft-ietf-ipsecme-failure-detection-06.txt Thread-Index: AcvfYsP8WDLScRcpQQuwMMMjqhvsyw== Message-ID: <7CE49FEA-CE42-46C2-8B39-F4DE2AAA8FE4@checkpoint.com> References: <20110310201501.27968.18959.idtracker@localhost> In-Reply-To: <20110310201501.27968.18959.idtracker@localhost> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 20:34:44 -0000 Hi all. This version includes remarks by Magnus Nystr=F6m. To see the differences, follow this link: http://tools.ietf.org/rfcdiff?url= 2=3Ddraft-ietf-ipsecme-failure-detection-06 Yoav On Mar 10, 2011, at 10:15 PM, wrote: > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the IP Security Maintenance and Extensions W= orking Group of the IETF. >=20 >=20 > Title : A Quick Crash Detection Method for IKE > Author(s) : Y. Nir, et al. > Filename : draft-ietf-ipsecme-failure-detection-06.txt > Pages : 23 > Date : 2011-03-10 >=20 > This document describes an extension to the IKEv2 protocol that > allows for faster detection of SA desynchronization using a saved > token. >=20 > When an IPsec tunnel between two IKEv2 peers is disconnected due to a > restart of one peer, it can take as much as several minutes for the > other peer to discover that the reboot has occurred, thus delaying > recovery. In this text we propose an extension to the protocol, that > allows for recovery immediately following the restart. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-failure-detection-= 06.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > From wwwrun@core3.amsl.com Thu Mar 10 09:02:04 2011 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 8DA7D3A6920; Thu, 10 Mar 2011 09:02:04 -0800 (PST) To: yaronf.ietf@gmail.com, ynir@checkpoint.com, zhangdacheng@huawei.com, rsj@cisco.com, kagarigi@cisco.com From: IETF Secretariat Message-Id: <20110310170204.8DA7D3A6920@core3.amsl.com> Date: Thu, 10 Mar 2011 09:02:04 -0800 (PST) X-Mailman-Approved-At: Fri, 11 Mar 2011 08:02:33 -0800 Cc: tim.polk@nist.gov, paul.hoffman@vpnc.org, ipsec@ietf.org, turners@ieca.com, ipr-announce@ietf.org, stephen.farrell@cs.tcd.ie Subject: [IPsec] IPR Disclosure: Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-ipsecme-ipsecha-protocol-04 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Mar 2011 17:02:04 -0000 Dear Yaron Sheffer, Yoav Nir, Dacheng Zhang, Rajeshwar Jenwar, Kalyani Garigipati: An IPR disclosure that pertains to your Internet-Draft entitled "Protocol Support for High Availability of IKEv2/IPsec" (draft-ietf-ipsecme-ipsecha-protocol) was submitted to the IETF Secretariat on 2011-03-10 and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/1515/). The title of the IPR disclosure is "Telefonaktiebolaget LM Ericsson (publ)'s Statement about IPR related to draft-ietf-ipsecme-ipsecha-protocol-04." The IETF Secretariat From sunseawq@huawei.com Sun Mar 13 23:54:38 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDA173A6BA9 for ; Sun, 13 Mar 2011 23:54:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.628 X-Spam-Level: X-Spam-Status: No, score=-3.628 tagged_above=-999 required=5 tests=[AWL=0.867, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXLezrzreLyb for ; Sun, 13 Mar 2011 23:54:36 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 2E9703A6C31 for ; Sun, 13 Mar 2011 23:54:36 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LI10004TCHV9M@szxga03-in.huawei.com> for ipsec@ietf.org; Mon, 14 Mar 2011 14:53:56 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LI100MJRCHVNZ@szxga03-in.huawei.com> for ipsec@ietf.org; Mon, 14 Mar 2011 14:53:55 +0800 (CST) Received: from w53375 ([10.138.41.70]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LI100G3YCHT7L@szxml04-in.huawei.com> for ipsec@ietf.org; Mon, 14 Mar 2011 14:53:55 +0800 (CST) Date: Mon, 14 Mar 2011 14:53:53 +0800 From: Qin Wu To: Yoav Nir , ipsec@ietf.org, draft-ietf-hokey-rfc5296bis@tools.ietf.org Message-id: <033001cbe214$96067520$46298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <52DB5B6C-9E80-4C38-9BAF-30C883526952@checkpoint.com> Subject: Re: [IPsec] HOKEY draft draft-ietf-hokey-rfc5296bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 06:54:38 -0000 Hi, Yoav: Sorry for my late feedback. Thank for your reviewing this document and catching this nits. I will update rfc5296bis to get alignment with RFC5996. Also I think it will be good to see the update of RFC5996 to support ERP. Regards! -Qin ----- Original Message ----- From: "Yoav Nir" To: ; Sent: Sunday, March 06, 2011 5:25 PM Subject: [IPsec] HOKEY draft draft-ietf-hokey-rfc5296bis > Hi all > > I have just read the subject draft, and found this in section 6 (and similar text in the introduction): > > Note that to support ERP, lower-layer specifications may need to be > revised. Specifically, the IEEE802.1x specification must be revised > to allow carrying EAP messages of the new codes defined in this > document in order to support ERP. Similarly, RFC 4306 must be > updated to include EAP code values higher than 4 in order to use ERP > with Internet Key Exchange Protocol version 2 (IKEv2). IKEv2 may > also be updated to support peer-initiated ERP for optimized > operation. Other lower layers may need similar revisions. > > Note that this is not new text, and it appears pretty much the same way in RFC 5296. > > There's the obvious nit with this text, that RFC 4306 is not a reference. If it was, the id-nits would warn about this RFC being obsolete. But that's the small problem here. > > A bigger problem is that this text says that IKEv2 needs to be updated, but there is no draft for this update, nor has there been any message to this list about this proposed change. > > The simple change they require is to section 3.16: > o Code (1 octet) indicates whether this message is a Request (1), > Response (2), Success (3), or Failure (4). > > I think this could be done with an errata or a 1-page draft, if all that was required was pass-through of codes (5) and (6). But I think it's more involved than that. > > There's peer-initiated ERP (which would require peer-initiated IKE?) and multiple simultaneous operations. I think it may come to a somewhat larger draft. > > I think there should be at least a work-in-progress reference for 802.1x and IKEv2 before the hokey draft progresses. > > Yoav > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From sunseawq@huawei.com Sun Mar 13 23:58:06 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6EAC43A67FF; Sun, 13 Mar 2011 23:58:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.724 X-Spam-Level: X-Spam-Status: No, score=-3.724 tagged_above=-999 required=5 tests=[AWL=0.771, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4, RDNS_NONE=0.1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cpgv9fsdBSAV; Sun, 13 Mar 2011 23:58:05 -0700 (PDT) Received: from szxga03-in.huawei.com (unknown [119.145.14.66]) by core3.amsl.com (Postfix) with ESMTP id 3EDBA3A6A60; Sun, 13 Mar 2011 23:58:05 -0700 (PDT) Received: from huawei.com (szxga03-in [172.24.2.9]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LI100AQ7COZ72@szxga03-in.huawei.com>; Mon, 14 Mar 2011 14:58:11 +0800 (CST) Received: from huawei.com ([172.24.2.119]) by szxga03-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0LI100MI6COZNZ@szxga03-in.huawei.com>; Mon, 14 Mar 2011 14:58:11 +0800 (CST) Received: from w53375 ([10.138.41.70]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0LI100LLGCOZVS@szxml06-in.huawei.com>; Mon, 14 Mar 2011 14:58:11 +0800 (CST) Date: Mon, 14 Mar 2011 14:58:11 +0800 From: Qin Wu To: hokey@ietf.org Message-id: <033901cbe215$2ecf4fc0$46298a0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3664 X-Mailer: Microsoft Outlook Express 6.00.2900.3664 Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: 7BIT X-Priority: 3 X-MSMail-priority: Normal References: <20110314063002.28048.8408.idtracker@localhost> Cc: ipsec@ietf.org, Sebastien Decugis Subject: Re: [IPsec] [HOKEY] I-D Action:draft-ietf-hokey-rfc5296bis-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 06:58:06 -0000 Hi, folks: We submit the new version of draft-ietf-hokey-rfc5296bis to reflect our discussion on the list after the last meeting which is available at: http://www.ietf.org/id/draft-ietf-hokey-rfc5296bis-02.txt Here is the diff: http://tools.ietf.org/rfcdiff?url1=draft-ietf-hokey-rfc5296bis-01&difftype=--html&submit=Go%21&url2=draft-ietf-hokey-rfc5296bis-02 The major changes compared to the previous version 00 are: o Change using MAY in section 5.3.1.1 to using SHOULD o Mandate sending the EAP-Initiate/Re-auth-Start message instead of optional o Update obsolete reference RFC4306 into RFC5996 o Allow local server respond to the peer directly without forwarding the ERP message to the home domain Thanks for Sebastien and Andy valuable comments. Some of them have been taken in the updating. As for the remaining issues in Sebastien's proposals for simplying bootstapping and remove local and home distinction, I think the problem does exist. The proposals are some kind of ERP optimization, but I am suspecting whether they are the only ways. Let's discuss and solicit the consesus in the upcoming Prague meeting. Also your comments are welcome before the meeting! Regards! -Qin ----- Original Message ----- From: To: Cc: Sent: Monday, March 14, 2011 2:30 PM Subject: [HOKEY] I-D Action:draft-ietf-hokey-rfc5296bis-02.txt >A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Handover Keying Working Group of the IETF. > > > Title : EAP Extensions for EAP Re-authentication Protocol (ERP) > Author(s) : W. Wu, et al. > Filename : draft-ietf-hokey-rfc5296bis-02.txt > Pages : 44 > Date : 2011-03-13 > > The Extensible Authentication Protocol (EAP) is a generic framework > supporting multiple types of authentication methods. In systems > where EAP is used for authentication, it is desirable to not repeat > the entire EAP exchange with another authenticator. This document > specifies extensions to EAP and the EAP keying hierarchy to support > an EAP method-independent protocol for efficient re-authentication > between the peer and an EAP re-authentication server through any > authenticator. The re-authentication server may be in the home > network or in the local network to which the peer is connecting. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-hokey-rfc5296bis-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > -------------------------------------------------------------------------------- > _______________________________________________ > HOKEY mailing list > HOKEY@ietf.org > https://www.ietf.org/mailman/listinfo/hokey > From smoonen@us.ibm.com Mon Mar 14 04:39:21 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 117BE3A6A12; Mon, 14 Mar 2011 04:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.635 X-Spam-Level: X-Spam-Status: No, score=-4.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2i1E1s5xrdv; Mon, 14 Mar 2011 04:39:20 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by core3.amsl.com (Postfix) with ESMTP id DD11A3A690A; Mon, 14 Mar 2011 04:39:19 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p2EBY02E019712; Mon, 14 Mar 2011 05:34:00 -0600 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p2EBeWc1121808; Mon, 14 Mar 2011 05:40:32 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p2EBjIbg018268; Mon, 14 Mar 2011 05:45:18 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p2EBjInO018263; Mon, 14 Mar 2011 05:45:18 -0600 In-Reply-To: <7CE49FEA-CE42-46C2-8B39-F4DE2AAA8FE4@checkpoint.com> References: <20110310201501.27968.18959.idtracker@localhost> <7CE49FEA-CE42-46C2-8B39-F4DE2AAA8FE4@checkpoint.com> X-KeepSent: 2737AA57:6BB01D17-85257853:003FE05F; type=4; name=$KeepSent To: Yoav Nir X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Scott C Moonen Date: Mon, 14 Mar 2011 07:37:56 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 03/14/2011 05:40:31 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBF2C0DFAC66CF8f9e8a93df938690918c0ABBF2C0DFAC66CF" Cc: "ipsec@ietf.org" , ipsec-bounces@ietf.org Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 11:39:21 -0000 --0__=0ABBF2C0DFAC66CF8f9e8a93df938690918c0ABBF2C0DFAC66CF Content-type: multipart/alternative; Boundary="1__=0ABBF2C0DFAC66CF8f9e8a93df938690918c0ABBF2C0DFAC66CF" --1__=0ABBF2C0DFAC66CF8f9e8a93df938690918c0ABBF2C0DFAC66CF Content-type: text/plain; charset=ISO-8859-1 Content-transfer-encoding: quoted-printable The changes look ok to me, Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Yoav Nir To: "ipsec@ietf.org" Date: 03/10/2011 03:37 PM Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-06.txt Sent by: ipsec-bounces@ietf.org Hi all. This version includes remarks by Magnus Nystr=F6m. To see the differences, follow this link: http://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-failure-detecti= on-06 Yoav On Mar 10, 2011, at 10:15 PM, wrote: > 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 Extensio= ns Working Group of the IETF. > > > Title : A Quick Crash Detection Method for IKE > Author(s) : Y. Nir, et al. > Filename : draft-ietf-ipsecme-failure-detection-06.txt > Pages : 23 > Date : 2011-03-10 > > This document describes an extension to the IKEv2 protocol that > allows for faster detection of SA desynchronization using a saved > token. > > When an IPsec tunnel between two IKEv2 peers is disconnected due to a= > restart of one peer, it can take as much as several minutes for the > other peer to discover that the reboot has occurred, thus delaying > recovery. In this text we propose an extension to the protocol, that= > allows for recovery immediately following the restart. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-failure-detectio= n-06.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec = --1__=0ABBF2C0DFAC66CF8f9e8a93df938690918c0ABBF2C0DFAC66CF Content-type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-transfer-encoding: quoted-printable

The changes look ok to me,

Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/= in/smoonen

3D"InactiveYoav Nir ---03/10/2011 03:= 37:02 PM---Hi all. This version includes remarks by Magnus Nystr=F6m.

From: Yoav N= ir <ynir@checkpoint.com>
To: "ip= sec@ietf.org" <ipsec@ietf.org>
Date: 03/10/= 2011 03:37 PM
Subject: Re:= [IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-06.txt<= br> Sent by: ips= ec-bounces@ietf.org




Hi all.

This version includes remarks by Magnus Nystr=F6m.

To see the differences, follow this link: ht= tp://tools.ietf.org/rfcdiff?url2=3Ddraft-ietf-ipsecme-failure-detection= -06

Yoav

On Mar 10, 2011, at 10:15 PM, <Internet-Drafts@ietf.org> <Inte= rnet-Drafts@ietf.org> wrote:

> 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 Exten= sions Working Group of the IETF.
>
>
> Title           : A Quick Crash Detect= ion Method for IKE
> Author(s)       : Y. Nir, et al.
> Filename        : draft-ietf-ipsecme-failur= e-detection-06.txt
> Pages           : 23
> Date            : 2011-03-10
>
> This document describes an extension to the IKEv2 protocol that > allows for faster detection of SA desynchronization using a saved<= br> > token.
>
> When an IPsec tunnel between two IKEv2 peers is disconnected due t= o a
> restart of one peer, it can take as much as several minutes for th= e
> other peer to discover that the reboot has occurred, thus delaying=
> recovery.  In this text we propose an extension to the protoc= ol, that
> allows for recovery immediately following the restart.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/= draft-ietf-ipsecme-failure-detection-06.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp= .ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the<= br> > Internet-Draft.
> <draft-ietf-ipsecme-failure-detection-06.url><ATT00001..t= xt>

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

= --1__=0ABBF2C0DFAC66CF8f9e8a93df938690918c0ABBF2C0DFAC66CF-- --0__=0ABBF2C0DFAC66CF8f9e8a93df938690918c0ABBF2C0DFAC66CF Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBF2C0DFAC66CF8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBF2C0DFAC66CF8f9e8a93df938690918c0ABBF2C0DFAC66CF-- From priikone@iki.fi Mon Mar 14 13:21:36 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44A8D3A6EAB for ; Mon, 14 Mar 2011 13:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4EUPXbUStlAQ for ; Mon, 14 Mar 2011 13:21:33 -0700 (PDT) Received: from otaku.Xtrmntr.org (sauna.silcnet.org [IPv6:2001:4118:10:4000::2205]) by core3.amsl.com (Postfix) with ESMTP id E4EC23A6B71 for ; Mon, 14 Mar 2011 13:21:31 -0700 (PDT) Received: by otaku.Xtrmntr.org (Postfix, from userid 201) id 64E694946; Mon, 14 Mar 2011 21:23:22 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by otaku.Xtrmntr.org (Postfix) with ESMTP id 5F4F448AE; Mon, 14 Mar 2011 21:23:22 +0100 (CET) Date: Mon, 14 Mar 2011 21:23:21 +0100 (CET) From: Pekka Riikonen X-X-Sender: priikone@otaku.Xtrmntr.org To: Yaron Sheffer In-Reply-To: <4D77D633.8070903@gmail.com> Message-ID: References: <4D77D633.8070903@gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: IPsecme WG Subject: Re: [IPsec] WG Last Call on draft-ietf-ipsecme-ipsecha-protocol X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Mar 2011 20:21:36 -0000 On Wed, 9 Mar 2011, Yaron Sheffer wrote: : This begins a two-week Working Group Last Call on : draft-ietf-ipsecme-ipsecha-protocol. You can find the current version at : http://tools.ietf.org/html/draft-ietf-ipsecme-ipsecha-protocol-04. We : want everyone in the WG to read the document and comment on it, even if : the comment is "I support this" or "I am neutral on this". If you oppose : moving the draft forwards, or you have technical changes you want made, : please be explicit in your message. Feel free to start new threads if : you are objecting or suggesting changes. The authors will manage any : such discussions using the issue tracker. : It's ok by me, but I'd still like it to address the issues I listed earlier in this email: http://www.ietf.org/mail-archive/web/ipsec/current/msg06763.html Pekka From yaronf.ietf@gmail.com Wed Mar 16 12:23:03 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 55F543A6A93 for ; Wed, 16 Mar 2011 12:23:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JkOhYIjGNzkQ for ; Wed, 16 Mar 2011 12:23:02 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 36E013A6A85 for ; Wed, 16 Mar 2011 12:23:02 -0700 (PDT) Received: by bwz13 with SMTP id 13so2022590bwz.31 for ; Wed, 16 Mar 2011 12:24:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=d3TAe+LHKh3eOa3lM4km3E8/SlHoJiQVVA27G/yFpzc=; b=S/B9SxgLKDchCHBH9ZhIJTuXHdHjUEmkdB4mAYPVo+DYQt5xmP0O+dqIlvWFJJgD5H eF596x2kLghxkgQSNPDzTC7pntVSVp0E2KUJ1yVSh1LN1tX3blncigtqlxa2XDW1KwJg 7BDh0xZDoIBojxJsarEOv/aJpEAiLD28zeIZs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=PTvM6JelAbEGnvJoJXmQOs3116n5ETDZ90Jig+OC5CtoM48f0AJ46Hs2BHu3st8+jk 4Bsr2ImmDA8oYYGRmHwatB/4XTb+ncYqjKBlLZOP/ibFjhNz6i340bsBLhrYAGRtbQwR xRRL/LadPkmunIJxfnj+N1th1mQRnISSYIldo= Received: by 10.204.141.17 with SMTP id k17mr389952bku.41.1300303468359; Wed, 16 Mar 2011 12:24:28 -0700 (PDT) Received: from [10.0.0.5] (bzq-79-176-35-88.red.bezeqint.net [79.176.35.88]) by mx.google.com with ESMTPS id t1sm851341bkx.7.2011.03.16.12.24.24 (version=SSLv3 cipher=OTHER); Wed, 16 Mar 2011 12:24:26 -0700 (PDT) Message-ID: <4D810E65.6050908@gmail.com> Date: Wed, 16 Mar 2011 21:24:21 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Pekka Riikonen References: <4D77D633.8070903@gmail.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: Re: [IPsec] WG Last Call on draft-ietf-ipsecme-ipsecha-protocol X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 19:23:03 -0000 Thanks Pekka, we will look at these comments for the next rev. In the meantime, I would appreciate more comments (or just support) from the list - we are still in Last Call. Best, Yaron On 03/14/2011 10:23 PM, Pekka Riikonen wrote: > On Wed, 9 Mar 2011, Yaron Sheffer wrote: > > : This begins a two-week Working Group Last Call on > : draft-ietf-ipsecme-ipsecha-protocol. You can find the current version at > : http://tools.ietf.org/html/draft-ietf-ipsecme-ipsecha-protocol-04. We > : want everyone in the WG to read the document and comment on it, even if > : the comment is "I support this" or "I am neutral on this". If you oppose > : moving the draft forwards, or you have technical changes you want made, > : please be explicit in your message. Feel free to start new threads if > : you are objecting or suggesting changes. The authors will manage any > : such discussions using the issue tracker. > : > It's ok by me, but I'd still like it to address the issues I listed > earlier in this email: > > http://www.ietf.org/mail-archive/web/ipsec/current/msg06763.html > > Pekka From ynir@checkpoint.com Wed Mar 16 13:57:14 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 506823A6A21 for ; Wed, 16 Mar 2011 13:57:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.568 X-Spam-Level: X-Spam-Status: No, score=-10.568 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0t1LHGe7ktpK for ; Wed, 16 Mar 2011 13:57:13 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id 2D85F3A6A14 for ; Wed, 16 Mar 2011 13:57:12 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p2GKwb84016425; Wed, 16 Mar 2011 22:58:37 +0200 X-CheckPoint: {4D81243C-13-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Wed, 16 Mar 2011 22:58:37 +0200 From: Yoav Nir To: Tero Kivinen Date: Wed, 16 Mar 2011 22:58:35 +0200 Thread-Topic: [IPsec] New Version Notification for draft-kivinen-ipsecme-ikev2-minimal-00 Thread-Index: AcvkHOtxAh4BAewgQtC5NZpZgI2ATw== Message-ID: <164667AC-7102-41A2-9300-7BAF79647ED2@checkpoint.com> References: <19813.7472.338629.315817@fireball.kivinen.iki.fi> <4D7584D6.5020106@tanu.org> <40B4A2F1-6D6E-4CFA-8053-999A069BE025@checkpoint.com> <19831.38806.774182.971399@fireball.kivinen.iki.fi> In-Reply-To: <19831.38806.774182.971399@fireball.kivinen.iki.fi> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: Shoichi Sakane , "ipsec@ietf.org" Subject: Re: [IPsec] New Version Notification for draft-kivinen-ipsecme-ikev2-minimal-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 16 Mar 2011 20:57:14 -0000 Hi Tero. IKEv2 has an underlying assumption that peers are always available to respo= nd (for example to liveness check). If you're doing a special profile for m= inimal implementation that are not always available (because they're in a l= ow-power mode), you should also profile the server that talks to them. Thes= e should include: - no liveness checks, as these would lead to timeouts and dropping of SAs. - no initiating (this I think violates 4301, but it's OK if IKE retransmits= a couple of times and fails) One of the use cases that we hear about is small battery-powered sensors an= d actuators communicating via 802.15.4 at rates of 10-20 kbps with 6lowpan.= At those rates, it takes several seconds to set up an IKE and child SA, an= d that is not fast enough for many uses. So I think the general way of doin= g things should be that the "things" keep the SAs when they go to sleep. Most IKE products that I know of don't keep SAs forever. Looking at the Str= ongSwan code, it looks like the longest time you can keep an IKE or IPsec S= A is 1 day. The problem is that the peer might be sleeping when the SA expi= res on the server, and we don't want to wait for a timeout when it wakes. S= o there has to be a pre-agreement on lifetime. This doesn't have to be nego= tiated using AUTH_LT, though. You can specify in your draft that SAs last 2= 4 hours. Then you have to deal with failure detection. A failure of the server would= mean that for 24 hours all devices that try to communicate time out using = the old SA, before they restart. It may be OK to live with it, but this sho= uld be stated in the draft. Anyway, the thing that's really missing is requirements or profile for the = server, as you can't take a normal IKE implementation and have it work well= with those minimal implementations. Yoav From kivinen@iki.fi Thu Mar 17 08:05:30 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ED2073A6A55 for ; Thu, 17 Mar 2011 08:05:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.572 X-Spam-Level: X-Spam-Status: No, score=-102.572 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oChuDxh5sOCP for ; Thu, 17 Mar 2011 08:05:29 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 2F0D23A69A8 for ; Thu, 17 Mar 2011 08:05:28 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p2HF6nA1019064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 17 Mar 2011 17:06:49 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p2HF6kjB017626; Thu, 17 Mar 2011 17:06:46 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19842.9094.357221.595037@fireball.kivinen.iki.fi> Date: Thu, 17 Mar 2011 17:06:46 +0200 From: Tero Kivinen To: Yoav Nir In-Reply-To: <164667AC-7102-41A2-9300-7BAF79647ED2@checkpoint.com> References: <19813.7472.338629.315817@fireball.kivinen.iki.fi> <4D7584D6.5020106@tanu.org> <40B4A2F1-6D6E-4CFA-8053-999A069BE025@checkpoint.com> <19831.38806.774182.971399@fireball.kivinen.iki.fi> <164667AC-7102-41A2-9300-7BAF79647ED2@checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 33 min X-Total-Time: 43 min Cc: Shoichi Sakane , "ipsec@ietf.org" Subject: Re: [IPsec] New Version Notification for draft-kivinen-ipsecme-ikev2-minimal-00 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Mar 2011 15:05:31 -0000 Yoav Nir writes: > IKEv2 has an underlying assumption that peers are always available > to respond (for example to liveness check). Can you point me to that in RFC5996, I think I might have missed that. I am under the understanding that either end of the IKEv2 protocol can crash/shutdown/go silent at any point and after that point it will not answer to any IKEv2 messages anymore and this is allowed by the protocol and all complient implementations should be able to cope with it. > If you're doing a special profile for minimal implementation that > are not always available (because they're in a low-power mode), you > should also profile the server that talks to them. Note, that the draft-kivinen-ipsecme-ikev2-minimal-00 does explicilty mention how to respond to the DPD etc message, i.e. the minimal implementation implemented based on the draft do know how to answer to requests sent by the server, provided the device is still active. After the device is powered off, it of course cannot answer anymore. For example the appendix B.1 describes one additional useful feature for such devices, i.e the ability to send delete notification to the IKEv2 SA before going to sleep so server end does not waste resources while trying to do DPD, and then noticing that other end has disappeared, and tearing down the IKEv2 SA. > These should > include: > - no liveness checks, as these would lead to timeouts and dropping > of SAs. Liveness checks are optional anyways and only performed if the device thinks there is some reason to belive that the other end is no longer up. No sane IKEv2 implementation should ever implement periodic liveness checks, and I do agree that using periodic liveness checks breaks lots of other things too, and in my opinion rfc5996 should have prohibited them. Unfortunately some people go for the easy implementation route, and do implement them and then we do have all kind of problems. > - no initiating (this I think violates 4301, but it's OK if IKE > retransmits a couple of times and fails) I do not think RFC4301 forbids to have responder only setups. For most cases that is the most common setup anyways, as for road warriors the SGW cannot initiate to the road warrior as it does not know its IP address. If the device is up and server tries to create new IPsec SA, then it will answer NO_ADDITIONAL_SAS as is allowed by the RFC5996. Anyways neither one of those affects the implementation of the other end at all, only to their policy setup and configuration, and in general configuration of the SGW depends so heavily about the scenario that I see no point of start documenting or dictating what kind of policy is allowed or not allowed in the different scenarios. > One of the use cases that we hear about is small battery-powered > sensors and actuators communicating via 802.15.4 at rates of 10-20 > kbps with 6lowpan. At those rates, it takes several seconds to set > up an IKE and child SA, and that is not fast enough for many uses. > So I think the general way of doing things should be that the > "things" keep the SAs when they go to sleep. Speed of 10-20kbps means the IKEv2 setup time is will be less than second (not counting crypto calculations), as the actual data transmitted during the initial setup is less than 1kB. Anyways I would except that in such environments the minimal device could be configured to keep the IKEv2 SA and IPsec SA up, and the other end should be configured accordingly for that environment. > Most IKE products that I know of don't keep SAs forever. Looking at > the StrongSwan code, it looks like the longest time you can keep an > IKE or IPsec SA is 1 day. And I assume it would be around few lines of code change to remove that limit if someone is forced to use such implementation. At least our product can be configured to keep SAs up for long time (even years depending on the platform). Also RFC4301 mandates support for both time and byte count based lifetimes, and allows either one of them or both of them to be configured. If you have configured SA to use only byte lifetimes, then the time lifetime should not be active at all. > The problem is that the peer might be sleeping when the SA expires > on the server, and we don't want to wait for a timeout when it > wakes. So there has to be a pre-agreement on lifetime. This doesn't > have to be negotiated using AUTH_LT, though. You can specify in your > draft that SAs last 24 hours. 24 hours is way too short for some uses. I would expect it to be around month or a year or so. The data transfer on those links is so slow that before they reach for example 2^32 bytes it takes long time (more than month with your example link). To reach byte count where AES cipher really needs to be rekeyed because we have transmitted too much data over it it takes almost forever :-) > Then you have to deal with failure detection. A failure of the > server would mean that for 24 hours all devices that try to > communicate time out using the old SA, before they restart. It may > be OK to live with it, but this should be stated in the draft. As my draft does not specify any lifetime nor does it assume that SA is up all the time, I do not think there is need to add text specific to one scenario, especially when most of that would be text describing what kind of configuration might be required in some scenarios. I think that text belongs more or less to the exact profile document for that specific environment, i.e. for example the smartmetering profile document or similar could specify that no server initiated DPD is ever done, and lifetime of the SA should be assumed to be more than a year. > Anyway, the thing that's really missing is requirements or profile > for the server, as you can't take a normal IKE implementation and > have it work well with those minimal implementations. The idea of the draft is that it DOES NOT require any requirements or profiling of the server. It works with standard normal complient IKEv2 implementation without any changes. Depending on the scenario some specific configuration of the server is REQUIRED, for example it needs to be configured to allow pre-shared key authentication using the ID sent by the minimal node, and it must be configured to support AES, and its lifetime policy needs to be configured to match the environment where this setup is used. None of those affect the protocol, they are only configuration options which usually are already there in the complient full implementation of IKEv2. -- kivinen@iki.fi From anyamramesh@gmail.com Tue Mar 22 02:58:59 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1C163A67F9 for ; Tue, 22 Mar 2011 02:58:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WUoBS50eTThM for ; Tue, 22 Mar 2011 02:58:59 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id A779D3A67F6 for ; Tue, 22 Mar 2011 02:58:58 -0700 (PDT) Received: by bwz13 with SMTP id 13so6270741bwz.31 for ; Tue, 22 Mar 2011 03:00:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=SVl2XbD+0oA3AFso6D2Zw8xQQ8TT71d5aUnb2NM7K3U=; b=Js4uBIuxjCZwuYtePeCfeohLVUZ1k/72dDqLNg0EcYxtjlSw3ZdE8ulv9oY/gFMdQn KTGzoCFLURxkIlUQtebe5ToK3gABZ9lVQjBe58QYT2/nRpt1sKWmuIU5HO4v4KH/SenZ FWulJeQGm6TqJuOuNy7VwuuETr/yvp2RUTknY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=WbV31BkV1HPK0y5F/HD6sal2Vhlrqy9rOAhewoWHJWv9ZyZjHDL0BUdWGzZBmH7QIJ zEuyBDR2Zcw3hTsNY/jer0tsA4nEKoAdh6yr+mBM9AyRCzJ+ItE8ITqaEJFv7uOiHuYG vpoPJ+j59p/nmu3NbjWcN5kDrHBUBvH+t2G7Y= MIME-Version: 1.0 Received: by 10.205.33.194 with SMTP id sp2mr4947882bkb.27.1300788030739; Tue, 22 Mar 2011 03:00:30 -0700 (PDT) Received: by 10.204.33.84 with HTTP; Tue, 22 Mar 2011 03:00:30 -0700 (PDT) Date: Tue, 22 Mar 2011 06:00:30 -0400 Message-ID: From: Ramesh To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [IPsec] XFRM X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 10:00:46 -0000 Hi, I wanted to know about xfrm messages to configure IP sec. Is it old tradition compared to PF_KEY mechanism ? What is the current status of XFRM framework for IPsec Thanks , Ramesh From ramaswamy.bm@globaledgesoft.com Tue Mar 22 03:44:43 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6686928C0DE for ; Tue, 22 Mar 2011 03:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.005 X-Spam-Level: X-Spam-Status: No, score=-1.005 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_62=0.6, RELAY_IS_203=0.994] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oUk5ivHus0dE for ; Tue, 22 Mar 2011 03:44:42 -0700 (PDT) Received: from gesmail.globaledgesoft.com (gesmail.globaledgesoft.com [203.76.137.4]) by core3.amsl.com (Postfix) with ESMTP id 6CBAF28C0DD for ; Tue, 22 Mar 2011 03:44:41 -0700 (PDT) Received: from [127.0.0.1] (ramaswamy_sm.globaledgesoft.com [172.16.8.54]) by gesmail.globaledgesoft.com (Postfix) with ESMTP id 30ECD588303; Tue, 22 Mar 2011 16:15:59 +0530 (IST) Message-ID: <4D887F10.607@globaledgesoft.com> Date: Tue, 22 Mar 2011 16:20:56 +0530 From: Ramaswamy BM User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Ramesh References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, "???? \(Ram\)" Subject: Re: [IPsec] XFRM X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Mar 2011 10:44:43 -0000 pf_key api originates from BSD , and was implemented in linux too. However, there were several problems with the API: it did not support all things needed and most importantly it never gained the standardization it was intended to have. There are many variants of this API. Linux people decided to ditch this API and implemented the same things in Netlink XFRM API in a more robust manner with additional features. Consequently pf_key got deprecated in Linux. However, it is still the only option in *BSD. The BSD variants allow the port numbers. There used to be quite a bit of differences on details, but it's supposedly better now. After Linux developer deprecated the pf_key api they are refusing to add new features to it. So to get the functionality you want in Linux you need to use the native Linux API: Netlink XFRM. Or implement the same things in Linux pf_key code (but these will not get accepted to mainline kernel due to policy). If you just need static IPsec SA's with port specific stuff in Linux, you should be able to create them with "ip xfrm" command from iproute2 package. If you need IKE keying, you need to use some IKE daemon that talks to kernel with Linux Netlink XFRM as I told before. There are some option on the Linux IKE implementations. Ii is generally preferd that ipsec-tools since it uses openssl: but , {open,strong}swan seem to implement the XFRM API and IKEv2 amongst other interesting things not supported by ipsec-tools. One more thing , the port number(in SA) is not settable via pf_key programming API in Linux. This kind of functionality is possible via XFRM API Best Regards , Ram . Ramesh wrote: > Hi, > > I wanted to know about xfrm messages to configure IP sec. > Is it old tradition compared to PF_KEY mechanism ? > What is the current status of XFRM framework for IPsec > > > Thanks , > Ramesh > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > > From yaronf.ietf@gmail.com Wed Mar 23 14:58:34 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB8703A6957 for ; Wed, 23 Mar 2011 14:58:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cmJwQ0+ZjJ-o for ; Wed, 23 Mar 2011 14:58:33 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id BE15E3A68B3 for ; Wed, 23 Mar 2011 14:58:32 -0700 (PDT) Received: by fxm15 with SMTP id 15so8436921fxm.31 for ; Wed, 23 Mar 2011 15:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=6yLVhl0J6ztgUFvqTdQaUWwEEjAsh2t9f4VnN3e6tew=; b=NbD5TiBEUAI5rTir/GaEV516VdiiBiCx1EkqsJk2rNtsJry3bZ7WOjS/AW/iw1U7dl HJgcTnMnSP/pwncz6HquPYQmc4tkNrYCWB8OuiKrLJu5KfOBVKiinA/vwasEdJPwE0gz DbFfolxugQv0KzXHetLLz7zZ8Y/0PUtT/eLxo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=SvEwowqAS8bXae5H6fQTqXuYnYhdrjhoP4abljgPLda8ajj410gMvtxbK4/+4JWv9w NUOD+rkL7IQR7LgAWv1B21J1oKW5AeRG75dgD7xwzeffo5uNVHU1+tDRPGdwAyR6PZYb T8oRTYTKDsn29isDypOOcg0MsKawB7I0k4dII= Received: by 10.223.55.12 with SMTP id s12mr3634985fag.124.1300917606480; Wed, 23 Mar 2011 15:00:06 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-177-11-1.red.bezeqint.net [79.177.11.1]) by mx.google.com with ESMTPS id 21sm3653995fav.41.2011.03.23.15.00.04 (version=SSLv3 cipher=OTHER); Wed, 23 Mar 2011 15:00:04 -0700 (PDT) Message-ID: <4D8A6D63.5070204@gmail.com> Date: Thu, 24 Mar 2011 00:00:03 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: IPsecme WG References: <4D77D633.8070903@gmail.com> In-Reply-To: <4D77D633.8070903@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] WG Last Call on draft-ietf-ipsecme-ipsecha-protocol X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Mar 2011 21:58:34 -0000 Hi everyone, The 2-week LC period is up today. I'm afraid we got much less review than we would have liked, and further review/comments would be very welcome. However since we've had good WG input on earlier iterations of this document, we are asking Sean, the security AD, to progress the draft. Thanks, Yaron On 03/09/2011 09:34 PM, Yaron Sheffer wrote: > This begins a two-week Working Group Last Call on > draft-ietf-ipsecme-ipsecha-protocol. You can find the current version at > http://tools.ietf.org/html/draft-ietf-ipsecme-ipsecha-protocol-04. We > want everyone in the WG to read the document and comment on it, even if > the comment is "I support this" or "I am neutral on this". If you oppose > moving the draft forwards, or you have technical changes you want made, > please be explicit in your message. Feel free to start new threads if > you are objecting or suggesting changes. The authors will manage any > such discussions using the issue tracker. > > The WG previously reached consensus on a problem statement for IPsec > High Availability, http://tools.ietf.org/html/rfc6027. You may wish to > refer to that RFC, first, to frame the problem, and second, to convince > yourselves that the current document actually addresses it in full. > > Thanks, > Yaron > From ynir@checkpoint.com Sun Mar 27 04:38:39 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 37C983A67C0; Sun, 27 Mar 2011 04:38:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.553 X-Spam-Level: X-Spam-Status: No, score=-10.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TiLUvCBrMxdH; Sun, 27 Mar 2011 04:38:38 -0700 (PDT) Received: from michael.checkpoint.com (smtp.checkpoint.com [194.29.34.68]) by core3.amsl.com (Postfix) with ESMTP id CE76E3A67B4; Sun, 27 Mar 2011 04:38:37 -0700 (PDT) Received: from il-ex01.ad.checkpoint.com (il-ex01.ad.checkpoint.com [194.29.34.26]) by michael.checkpoint.com (8.13.8/8.13.8) with ESMTP id p2RBeDSW023091; Sun, 27 Mar 2011 13:40:13 +0200 X-CheckPoint: {4D8F21A1-6-1B221DC2-FFFF} Received: from il-ex01.ad.checkpoint.com ([126.0.0.2]) by il-ex01.ad.checkpoint.com ([126.0.0.2]) with mapi; Sun, 27 Mar 2011 13:40:13 +0200 From: Yoav Nir To: "ietf@ietf.org list" , "ipsec@ietf.org" Date: Sun, 27 Mar 2011 13:40:13 +0200 Thread-Topic: PSK with IKEv2 Thread-Index: Acvsc7wOdnjTOxN8SVGqsJvcel+ZnQ== Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: [IPsec] PSK with IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 11:38:39 -0000 Hi all Yesterday, the IESG has started last call on three documents: - draft-harkins-ipsecme-spsk-auth-03 - draft-shin-augmented-pake-03 - draft-kuegler-ipsecme-pace-ikev2-05 All three seek to improve the authentication in IKEv2 when using pre-shared= keys, as compared with RFC 5996. The IPsecME working group was unable to c= hoose between them, but I don't think this attempt to throw this decision a= t the IESG is going to help much.=20 Specifically, I don't think that publishing all three is a positive outcome= for this. Moreover, I don't think there's a way for the poor developer to support all= four methods, and interoperate with implementations that support just one,= without wasting some round-trips on testing whether the peer supports one = implementation or the other.=20 If they at least all had something like a notification that says that the i= nitiator supports *this* method in the Initial exchange, and the responder = could reply with just one, it would be somewhat better, but still it's a ba= d outcome for the IETF process. Yoav From yaronf.ietf@gmail.com Sun Mar 27 05:47:50 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 408ED3A6823; Sun, 27 Mar 2011 05:47:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tKBUHM-v1eTn; Sun, 27 Mar 2011 05:47:49 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id DD9283A6820; Sun, 27 Mar 2011 05:47:48 -0700 (PDT) Received: by fxm15 with SMTP id 15so2275196fxm.31 for ; Sun, 27 Mar 2011 05:49:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=RwP6HCGoYP0z8O+6fZ5d07TBUkD1ZxxSv04hO9zK/6o=; b=nWRyfJ0jLs7Y6v9ZYucwYEbF8bVhrfUXYsR6Bygu0tTwZNHm0ed7Yr41xLz2d3vYNR E7ZNAtXsd4rI/iQTGv85ZeGhfvkNuc+DXo5nL8K0zq4JyidWC/hVHKpLk/FExnsRIpSF MFZZdnLzgcNdszWZwKthPWGEES6yuU+njs9Hk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=ck0c5plP4BX8uF6n+4ovem5pVwvT0uf3R/HQ+MyMyFopRXoRt3uSISVOdOxPbNMile Mk8B5D9wVePgRk+9hj2FO0c79VFv+ZvFTUgnFmrvqhWQ6DgATcbMbJoRt0tzvMDtwawT mdIGTD43qrPEqn5gb2jcug5i7HSKnfPKDONpg= Received: by 10.223.54.213 with SMTP id r21mr3203961fag.54.1301230164943; Sun, 27 Mar 2011 05:49:24 -0700 (PDT) Received: from [10.0.0.5] (85-250-59-87.bb.netvision.net.il [85.250.59.87]) by mx.google.com with ESMTPS id p16sm1076934fax.21.2011.03.27.05.49.23 (version=SSLv3 cipher=OTHER); Sun, 27 Mar 2011 05:49:24 -0700 (PDT) Message-ID: <4D8F3252.7080705@gmail.com> Date: Sun, 27 Mar 2011 14:49:22 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: Yoav Nir References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: "ipsec@ietf.org" , "ietf@ietf.org list" Subject: Re: [IPsec] PSK with IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 27 Mar 2011 12:47:50 -0000 (Co-author hat on) PACE (draft-kuegler-ipsecme-pace-ikev2-05) negotiates its own use during IKE_SA_INIT by exchanging a notification that signifies that both peers support the extension. I would recommend that the other two protocols be extended with a similar exchange of notifications. Then the responder can decide which (if any) of them it supports and respond accordingly, and the initiator can start the next exchange already knowing how it can proceed. However let's not forget that falling back to PSK authentication using a short password would be vulnerable to a MITM+dictionary attacker. (WG co-chair hat on) I share your disappointment with this outcome. Thanks, Yaron On 03/27/2011 01:40 PM, Yoav Nir wrote: > Hi all > > Yesterday, the IESG has started last call on three documents: > - draft-harkins-ipsecme-spsk-auth-03 > - draft-shin-augmented-pake-03 > - draft-kuegler-ipsecme-pace-ikev2-05 > > All three seek to improve the authentication in IKEv2 when using pre-shared keys, as compared with RFC 5996. The IPsecME working group was unable to choose between them, but I don't think this attempt to throw this decision at the IESG is going to help much. > > Specifically, I don't think that publishing all three is a positive outcome for this. > > > Moreover, I don't think there's a way for the poor developer to support all four methods, and interoperate with implementations that support just one, without wasting some round-trips on testing whether the peer supports one implementation or the other. > > If they at least all had something like a notification that says that the initiator supports *this* method in the Initial exchange, and the responder could reply with just one, it would be somewhat better, but still it's a bad outcome for the IETF process. > > > Yoav > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From anyamramesh@gmail.com Sun Mar 27 22:55:07 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 464C33A6822 for ; Sun, 27 Mar 2011 22:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFEG6qzHeVHq for ; Sun, 27 Mar 2011 22:55:02 -0700 (PDT) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id F2C673A67D0 for ; Sun, 27 Mar 2011 22:55:01 -0700 (PDT) Received: by bwz13 with SMTP id 13so2346648bwz.31 for ; Sun, 27 Mar 2011 22:56:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to :content-type; bh=zHVz6YHxP7t8CDFjtGGSJzw0xcARKVBSSJM3HKWDPl0=; b=AyetVtnU6dn5hj0eqx1t3OlJ6KzP8xU96qkkKDtSMgV0e+Lz5QmLs+PdOl5DzSktf1 CxoglpX1SzeN6aIux+CTs33iHvBhyNptOdPWfgEuyVURa5S6BD6zEZrYfD+HXfRlwHr4 R3/weSjhDft7m4Uwk2/rfztD3eCZVMp/p5vB8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:content-type; b=gw0LilXDbL1PDzMNLgpzACyQSl0Pw7n8p6Kq5xgZetpyVdkVutaNxlT1aIRuQta9Uw TmEN2MJ9GJYjZG+8PwsYfoxp9on0wpWjU791Ku4kjNvbHYt8Ygzjx76qwdpfuScZZCdq ckE86/r9KIqcHNcGO0sKds4FkWwZg1lIvvVaQ= MIME-Version: 1.0 Received: by 10.204.23.81 with SMTP id q17mr3303027bkb.2.1301291798108; Sun, 27 Mar 2011 22:56:38 -0700 (PDT) Received: by 10.204.115.131 with HTTP; Sun, 27 Mar 2011 22:56:38 -0700 (PDT) Date: Mon, 28 Mar 2011 01:56:38 -0400 Message-ID: From: Ramesh To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1 Subject: [IPsec] hI X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 05:55:07 -0000 Hi, I am planning to write kernel module similar to af_key (kernel/key/af_key.c). Please help me does it have any documentation on how to write af_key related modules. I am interested in finding the internal api understanding, Thanks, Ramesh. From Internet-Drafts@ietf.org Mon Mar 28 01:15:03 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47F993A68A6; Mon, 28 Mar 2011 01:15:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.547 X-Spam-Level: X-Spam-Status: No, score=-102.547 tagged_above=-999 required=5 tests=[AWL=0.052, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YgUIvo523yxy; Mon, 28 Mar 2011 01:15:02 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0323E3A6914; Mon, 28 Mar 2011 01:15:02 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.13 Message-ID: <20110328081502.5600.28609.idtracker@localhost> Date: Mon, 28 Mar 2011 01:15:02 -0700 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-failure-detection-07.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Mar 2011 08:15:03 -0000 --NextPart 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 : A Quick Crash Detection Method for IKE Author(s) : Y. Nir, et al. Filename : draft-ietf-ipsecme-failure-detection-07.txt Pages : 24 Date : 2011-03-28 This document describes an extension to the IKEv2 protocol that allows for faster detection of Security Association (SA) desynchronization using a saved token. When an IPsec tunnel between two IKEv2 peers is disconnected due to a restart of one peer, it can take as much as several minutes for the other peer to discover that the reboot has occurred, thus delaying recovery. In this text we propose an extension to the protocol, that allows for recovery immediately following the restart. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-failure-detection-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-failure-detection-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-28010536.I-D@ietf.org> --NextPart-- From yaronf.ietf@gmail.com Tue Mar 29 06:10:14 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C77663A6811; Tue, 29 Mar 2011 06:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3BzZc0j4A7g7; Tue, 29 Mar 2011 06:10:14 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id B19FF3A6784; Tue, 29 Mar 2011 06:10:13 -0700 (PDT) Received: by fxm15 with SMTP id 15so208259fxm.31 for ; Tue, 29 Mar 2011 06:11:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :cc:subject:content-type:content-transfer-encoding; bh=VFv4KQU+9KOWfrMIp3y13VLv4voFmQVpQHx+F46WKNg=; b=GUCuI134YaD5wUDyt8ZLXlwU2aXijmSJxJUBEB62cVMCWDgHamrv5HYKHN+bHSV9xR BUMkm3BJkOXGTwy0tB31V0lvRQOmiycrZtAuxNDN/lp9U3WA1XRSJQ1+NGNIM7EPHY8N b0ehiIQu/OK1Sf07fenK2uZD1Rcfyoafj5JcM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :content-type:content-transfer-encoding; b=RUIGL06d8N2xEHH0YC+X++2uwOdYP6BYquB3okXzGTIoaIWCqcIHSGDwAzICVK/CaX t+PAUDh8B1naBil6BAX/9xN6q4xZ+ntgxhoyeSIQlZACV8MQDe8Cf6y9WoISWVn+5SiC mnPO75Omdo5gzZ/hAETAgXaFMA0Jek1WaUgvQ= Received: by 10.223.159.142 with SMTP id j14mr5861455fax.40.1301404294372; Tue, 29 Mar 2011 06:11:34 -0700 (PDT) Received: from [10.0.0.5] (85-250-59-87.bb.netvision.net.il [85.250.59.87]) by mx.google.com with ESMTPS id n15sm1967418fam.12.2011.03.29.06.11.33 (version=SSLv3 cipher=OTHER); Tue, 29 Mar 2011 06:11:33 -0700 (PDT) Message-ID: <4D91DA83.1030506@gmail.com> Date: Tue, 29 Mar 2011 15:11:31 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 To: "saag@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: IPsecme WG Subject: [IPsec] IPsecME summary for SAAG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 13:10:14 -0000 The IPsecME WG is not meeting in Prague this week. We sent our "failure detection" draft to the IESG, and it should be moving to the RFC Editor soon. Our last chartered document, the "high availability protocol" extension, recently left WG Last Call and should be in IETF Last Call in the near future. Regards, Paul and Yaron From Internet-Drafts@ietf.org Tue Mar 29 10:30:05 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB92F3A6A8B; Tue, 29 Mar 2011 10:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rsgJqL-cQTaD; Tue, 29 Mar 2011 10:30:04 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E810D3A67A6; Tue, 29 Mar 2011 10:30:04 -0700 (PDT) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.14 Message-ID: <20110329173004.28098.35666.idtracker@localhost> Date: Tue, 29 Mar 2011 10:30:04 -0700 Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ipsecha-protocol-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 17:30:05 -0000 --NextPart 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 : Protocol Support for High Availability of IKEv2/IPsec Author(s) : R. Jenwar, et al. Filename : draft-ietf-ipsecme-ipsecha-protocol-05.txt Pages : 23 Date : 2011-03-29 The IPsec protocol suite is widely used for business-critical network traffic. In order to make IPsec deployments highly available, more scalable and failure-resistant, they are often implemented as IPsec High Availability (HA) clusters. However there are many issues in IPsec HA clustering, and in particular in IKEv2 clustering. An earlier document, "IPsec Cluster Problem Statement", enumerates the issues encountered in the IKEv2/IPsec HA cluster environment. This document resolves these issues with the least possible change to the protocol. This document defines an extension to the IKEv2 protocol to solve the main issues of "IPsec Cluster Problem Statement" in the commonly deployed hot-standby cluster, and provides implementation advice for other issues. The main issues solved are the synchronization of IKEv2 Message ID counters, and of IPsec Replay Counters. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ipsecha-protocol-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-ipsecha-protocol-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-03-29102330.I-D@ietf.org> --NextPart-- From yaronf.ietf@gmail.com Tue Mar 29 12:15:14 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 577B33A6A53 for ; Tue, 29 Mar 2011 12:15:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.855 X-Spam-Level: X-Spam-Status: No, score=-101.855 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, MISSING_HEADERS=1.292, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hATw2Uz3N4NK for ; Tue, 29 Mar 2011 12:15:13 -0700 (PDT) Received: from mail-ww0-f42.google.com (mail-ww0-f42.google.com [74.125.82.42]) by core3.amsl.com (Postfix) with ESMTP id 5AC7B3A6A1E for ; Tue, 29 Mar 2011 12:15:13 -0700 (PDT) Received: by wwk4 with SMTP id 4so3244630wwk.1 for ; Tue, 29 Mar 2011 12:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=G0j7f+F27jwXq3u90Bz4EEvlTgfVVNJnemyKKxzSS+o=; b=qVWu121Gv4uPrzgoW/CUULD82jMr5d19uX5E3CI0I/2fkAdBFAQJLApA8sbPvZ7i2a nBTclwdqzhSaDm76WHY+Kg5VYXLEh8Eu/VQVQfi/VXMpEIUk7TzlhcR4ilvcAPiFev5O eS19wGzVxtYvuLrr9HgKWX5L3IFKKzyojHE7Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:cc:subject:references :in-reply-to:content-type:content-transfer-encoding; b=IPhiQT68MEzak7yvfXZKRG8k5nFnuNuhwj3thmwuY1e1uBzge42vCirIlnB0yqNnzb a2YEihV+TSV3EQi0cJ6ZWfWZttUvJL8cL+3xrI9W38CnpFAgIJkVpyOY8J53xwLhRwVE F7+BDs57kUJWTQ17DIXaGeYIFisT0Cw5FUfmk= Received: by 10.216.9.199 with SMTP id 49mr4923363wet.45.1301426211113; Tue, 29 Mar 2011 12:16:51 -0700 (PDT) Received: from [10.0.0.1] (bzq-79-179-47-236.red.bezeqint.net [79.179.47.236]) by mx.google.com with ESMTPS id y12sm2594241wby.42.2011.03.29.12.16.48 (version=SSLv3 cipher=OTHER); Tue, 29 Mar 2011 12:16:50 -0700 (PDT) Message-ID: <4D92301E.6040504@gmail.com> Date: Tue, 29 Mar 2011 21:16:46 +0200 From: Yaron Sheffer User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.14) Gecko/20110223 Lightning/1.0b2 Thunderbird/3.1.8 MIME-Version: 1.0 CC: ipsec@ietf.org References: <20110329173004.28098.35666.idtracker@localhost> In-Reply-To: <20110329173004.28098.35666.idtracker@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-ipsecha-protocol-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2011 19:15:14 -0000 For those who were wondering: this version corrects a few very small issues which were raised by Sean in his AD review. Next up is IETF Last Call. Thanks, Yaron On 03/29/2011 07:30 PM, Internet-Drafts@ietf.org wrote: > 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 : Protocol Support for High Availability of IKEv2/IPsec > Author(s) : R. Jenwar, et al. > Filename : draft-ietf-ipsecme-ipsecha-protocol-05.txt > Pages : 23 > Date : 2011-03-29 > > The IPsec protocol suite is widely used for business-critical network > traffic. In order to make IPsec deployments highly available, more > scalable and failure-resistant, they are often implemented as IPsec > High Availability (HA) clusters. However there are many issues in > IPsec HA clustering, and in particular in IKEv2 clustering. An > earlier document, "IPsec Cluster Problem Statement", enumerates the > issues encountered in the IKEv2/IPsec HA cluster environment. This > document resolves these issues with the least possible change to the > protocol. > > This document defines an extension to the IKEv2 protocol to solve the > main issues of "IPsec Cluster Problem Statement" in the commonly > deployed hot-standby cluster, and provides implementation advice for > other issues. The main issues solved are the synchronization of > IKEv2 Message ID counters, and of IPsec Replay Counters. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ipsecha-protocol-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec From iesg-secretary@ietf.org Wed Mar 30 09:00:05 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4CBE3A6B84; Wed, 30 Mar 2011 09:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fth3kZO-IGsR; Wed, 30 Mar 2011 09:00:04 -0700 (PDT) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1E1F3A6B80; Wed, 30 Mar 2011 09:00:03 -0700 (PDT) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.14 Message-ID: <20110330160003.10732.15708.idtracker@localhost> Date: Wed, 30 Mar 2011 09:00:03 -0700 Cc: ipsec@ietf.org Subject: [IPsec] Last Call: (Protocol Support for High Availability of IKEv2/IPsec) to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Mar 2011 16:00:06 -0000 The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'Protocol Support for High Availability of IKEv2/IPsec' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-04-13. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ipsecha-protocol/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-ipsecme-ipsecha-protocol/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1515/ From kivinen@iki.fi Thu Mar 31 07:52:31 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7830328C0E7 for ; Thu, 31 Mar 2011 07:52:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.44 X-Spam-Level: X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[AWL=0.159, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OFfLJlz769-2 for ; Thu, 31 Mar 2011 07:52:29 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 3201128C107 for ; Thu, 31 Mar 2011 07:52:28 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p2VEs4gw025049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 31 Mar 2011 17:54:04 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p2VEs4nt000359; Thu, 31 Mar 2011 17:54:04 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19860.38284.384287.292413@fireball.kivinen.iki.fi> Date: Thu, 31 Mar 2011 17:54:04 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 1 min Subject: [IPsec] IANA allocations for combined mode ciphers and IKEv1. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 14:52:31 -0000 In early 2009 there was discussion in the IPsec list that the RFC4543 was supposed to allocate numbers also for IKEv1, not only for IKEv2. There was some discussion on the list and then there was errata 1821 was submitted to the RFC4543 which said those numbers should also be allocated for the IKEv1 IANA registry. At that point we didn't really realize that ESPv2 which is implied by using IKEv1 does not support combined mode ciphers. In the end of 2009 we started to discuss about the IPsec roadmap document, and then this item came out again. We had open ticket #111 (http://tools.ietf.org/wg/ipsecme/trac/ticket/111) about the issue and the final wording in the roadmap (now RFC6071) document was: ---------------------------------------------------------------------- 5.4. Combined Mode Algorithms IKEv1 and ESP-v2 use separate algorithms to provide encryption and integrity protection, and IKEv1 can negotiate different combinations of algorithms for different SAs. In ESP-v3, a new class of algorithms was introduced, in which a single algorithm can provide both encryption and integrity protection. [RFC5996] describes how IKEv2 can negotiate combined mode algorithms to be used in ESP-v3 SAs. [RFC5282] adds that capability to IKEv2, enabling IKEv2 to negotiate and use combined mode algorithms for its own traffic. When properly designed, these algorithms can provide increased efficiency in both implementation and execution. Although ESP-v2 did not originally include combined mode algorithms, some IKEv1 implementations have added the capability to negotiate combined mode algorithms for use in IPsec SAs; these implementations do not include the capability to use combined mode algorithms to protect IKE SAs. IANA numbers for combined mode algorithms have been added to the IKEv1 registry. 5.4.1. RFC 4309, Using Advanced Encryption Standard (AES) CCM Mode with IPsec Encapsulating Security Payload (ESP) (S, December 2005) ... Requirement levels for AES-CCM: IKEv1 - N/A IKEv2 - optional ESP-v2 - N/A ESP-v3 - optional [RFC4835] NOTE: The IPsec-v2 IANA registry includes values for AES-CCM, but combined mode algorithms are not a feature of IPsec-v2. Although some IKEv1/IPsec-v2 implementations include this capability (see Section 5.4), it is not part of the protocol. 5.4.2. RFC 4106, The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP) (S, June 2005) ... Requirement levels for AES-GCM: IKEv1 - N/A IKEv2 - optional ESP-v2 - N/A ESP-v3 - optional [RFC4835] NOTE: The IPsec-v2 IANA registry includes values for AES-GCM, but combined mode algorithms are not a feature of IPsec-v2. Although some IKEv1/IPsec-v2 implementations include this capability (see Section 5.4), it is not part of the protocol. 5.4.3. RFC 4543, The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH (S, May 2006) ... Requirement levels for AES-GMAC: IKEv1 - N/A IKEv2 - N/A IPsec-v2 - N/A IPsec-v3 - optional NOTE: The IPsec-v2 IANA registry includes values for AES-GMAC, but combined mode algorithms are not a feature of IPsec-v2. Although some IKEv1/IPsec-v2 implementations include this capability (see Section 5.4), it is not part of the protocol. ---------------------------------------------------------------------- Listing all those combined ciphers as N/A for IPsec-v2. As I think the RFC6071 do reflect the concensus of the IPsecME workgroup, and because of this I think we should fix the IANA allocations for the combined mode ciphers (this includes AES-CCM (RFC4835), AES-GCM (RFC4835) and AES-GMAC (RFC4543)) and change them to be RESERVED and add note that they are not really part of IKEv1 protocol. This whole issue comes mostly because there is no version number in the ESP, meaning only way to know whether ESPv2 or ESPv3 is used is by implying that from whether IKEv1 or IKEv2 was used (which do have version numbers). This affects following IANA entries in the isakmp-registry (http://www.iana.org/assignments/isakmp-registry): ---------------------------------------------------------------------- IPSEC ESP Transform Identifiers =============================== Transform ID Value Reference ------------ ----- --------- ESP_AES-CCM_8 14 [RFC4309] ESP_AES-CCM_12 15 [RFC4309] ESP_AES-CCM_16 16 [RFC4309] ESP_AES-GCM_8 18 [RFC4106] ESP_AES-GCM_12 19 [RFC4106] ESP_AES-GCM_16 20 [RFC4106] ESP_NULL_AUTH_AES-GMAC 23 [RFC4543][Errata1821] IPSEC AH Transform Identifiers ============================== Transform ID Value Reference ------------ ----- --------- AH_AES-128-GMAC 11 [RFC4543][Errata1821] AH_AES-192-GMAC 12 [RFC4543][Errata1821] AH_AES-256-GMAC 13 [RFC4543][Errata1821] IPSEC Security Association Attributes ===================================== Authentication Algorithm Name Value Reference ---- ----- --------- AES-128-GMAC 11 [RFC4543][Errata1821] AES-192-GMAC 12 [RFC4543][Errata1821] AES-256-GMAC 13 [RFC4543][Errata1821] ---------------------------------------------------------------------- I am not really sure what should be done for the AH transform identifiers, as I think the AH_AES-*-GMAC can actually be used without problems in the IPsec-v2 AH, but I am not sure. We have few options: 1) Leave things as they are as this is only for obsoleted protocol that nobody uses... Unfortunately there are still people using this obsoleted protocol and if the numbers are there in the IANA registry as they are now, some implementors might think they can actually implement and then they do end up mixed mode version of IPsec-v2 and IPsec-v3. 2) Change all those entries to be "RESERVED (was xxx)" and add note saying that they are not really a feature of IPsec-v2 and even when there is implementations using them that is not standard way to do it. If those algorithms is needed then ESPv3 (and IKEv2, and RFC4301 architecture) is needed. 3) Change ESP entries to "RESERVED (was xxx)" and add similar note than in 2, but leave AH entries intact. I think the option 2 is the best, i.e clearly mark them that you should not do this, but if you see these numbers you do know that it is some implementation using some wierd mixed IPsec-v2 / v3 feature set. -- kivinen@iki.fi From smoonen@us.ibm.com Thu Mar 31 08:06:17 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7971A3A67FC; Thu, 31 Mar 2011 08:06:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.635 X-Spam-Level: X-Spam-Status: No, score=-4.635 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, SARE_GIF_ATTACH=1.42, TVD_FW_GRAPHIC_NAME_MID=0.543] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OoA+scXK92Qw; Thu, 31 Mar 2011 08:06:15 -0700 (PDT) Received: from e37.co.us.ibm.com (e37.co.us.ibm.com [32.97.110.158]) by core3.amsl.com (Postfix) with ESMTP id 45F6A3A6A34; Thu, 31 Mar 2011 08:06:15 -0700 (PDT) Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e37.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id p2VF5Ee6015766; Thu, 31 Mar 2011 09:05:14 -0600 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id p2VF7eEF101114; Thu, 31 Mar 2011 09:07:53 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id p2VFCXMV022653; Thu, 31 Mar 2011 09:12:33 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av06.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with ESMTP id p2VFCX7G022645; Thu, 31 Mar 2011 09:12:33 -0600 In-Reply-To: <19860.38284.384287.292413@fireball.kivinen.iki.fi> References: <19860.38284.384287.292413@fireball.kivinen.iki.fi> X-KeepSent: BD1839B3:070EC226-85257864:0052584C; type=4; name=$KeepSent To: Tero Kivinen X-Mailer: Lotus Notes Release 8.5.1FP5 SHF29 November 12, 2010 Message-ID: From: Scott C Moonen Date: Thu, 31 Mar 2011 11:07:27 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP4|July 25, 2010) at 03/31/2011 09:07:39 MIME-Version: 1.0 Content-type: multipart/related; Boundary="0__=0ABBF2F7DFC1DEDC8f9e8a93df938690918c0ABBF2F7DFC1DEDC" Cc: ipsec@ietf.org, ipsec-bounces@ietf.org Subject: Re: [IPsec] IANA allocations for combined mode ciphers and IKEv1. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 15:06:17 -0000 --0__=0ABBF2F7DFC1DEDC8f9e8a93df938690918c0ABBF2F7DFC1DEDC Content-type: multipart/alternative; Boundary="1__=0ABBF2F7DFC1DEDC8f9e8a93df938690918c0ABBF2F7DFC1DEDC" --1__=0ABBF2F7DFC1DEDC8f9e8a93df938690918c0ABBF2F7DFC1DEDC Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: quoted-printable Tero, the existence of RFC 4304 represents an even more direct way in w= hich ESPv3 and AHv3 have leaked into IKEv1. I'm inclined to take your option 1, though I would quibble with "nobody= uses." :) Considering both ESN and combined-mode algorithms, it seems t= hat in practice we have general agreement that it is legitimate for two IKE= v1 implementations to mutually agree to use ESPv3 and AHv3 without importi= ng all of IPsec-v3. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://www.linkedin.com/in/smoonen From: Tero Kivinen To: ipsec@ietf.org Date: 03/31/2011 10:54 AM Subject: [IPsec] IANA allocations for combined mode ciphers and IKEv1. Sent by: ipsec-bounces@ietf.org In early 2009 there was discussion in the IPsec list that the RFC4543 was supposed to allocate numbers also for IKEv1, not only for IKEv2. There was some discussion on the list and then there was errata 1821 was submitted to the RFC4543 which said those numbers should also be allocated for the IKEv1 IANA registry. At that point we didn't really realize that ESPv2 which is implied by using IKEv1 does not support combined mode ciphers. In the end of 2009 we started to discuss about the IPsec roadmap document, and then this item came out again. We had open ticket #111 (http://tools.ietf.org/wg/ipsecme/trac/ticket/111) about the issue and the final wording in the roadmap (now RFC6071) document was: ---------------------------------------------------------------------- 5.4. Combined Mode Algorithms IKEv1 and ESP-v2 use separate algorithms to provide encryption and integrity protection, and IKEv1 can negotiate different combinations= of algorithms for different SAs. In ESP-v3, a new class of algorithms was introduced, in which a single algorithm can provide both encryption and integrity protection. [RFC5996] describes how IKEv2 can negotiate combined mode algorithms to be used in ESP-v3 SAs. [RFC5282] adds that capability to IKEv2, enabling IKEv2 to negotiate and use combined mode algorithms for its own traffic. Whe= n properly designed, these algorithms can provide increased efficiency= in both implementation and execution. Although ESP-v2 did not originally include combined mode algorithms,= some IKEv1 implementations have added the capability to negotiate combined mode algorithms for use in IPsec SAs; these implementations= do not include the capability to use combined mode algorithms to protect IKE SAs. IANA numbers for combined mode algorithms have bee= n added to the IKEv1 registry. 5.4.1. RFC 4309, Using Advanced Encryption Standard (AES) CCM Mode wit= h IPsec Encapsulating Security Payload (ESP) (S, December 2005) ... Requirement levels for AES-CCM: IKEv1 - N/A IKEv2 - optional ESP-v2 - N/A ESP-v3 - optional [RFC4835] NOTE: The IPsec-v2 IANA registry includes values for AES-CCM, but combined mode algorithms are not a feature of IPsec-v2. Although some IKEv1/IPsec-v2 implementations include this capability (see Section 5.4), it is not part of the protocol. 5.4.2. RFC 4106, The Use of Galois/Counter Mode (GCM) in IPsec Encapsulating Security Payload (ESP) (S, June 2005) ... Requirement levels for AES-GCM: IKEv1 - N/A IKEv2 - optional ESP-v2 - N/A ESP-v3 - optional [RFC4835] NOTE: The IPsec-v2 IANA registry includes values for AES-GCM, but combined mode algorithms are not a feature of IPsec-v2. Although some IKEv1/IPsec-v2 implementations include this capability (see Section 5.4), it is not part of the protocol. 5.4.3. RFC 4543, The Use of Galois Message Authentication Code (GMAC) in IPsec ESP and AH (S, May 2006) ... Requirement levels for AES-GMAC: IKEv1 - N/A IKEv2 - N/A IPsec-v2 - N/A IPsec-v3 - optional NOTE: The IPsec-v2 IANA registry includes values for AES-GMAC, but combined mode algorithms are not a feature of IPsec-v2. Although some IKEv1/IPsec-v2 implementations include this capability (see Section 5.4), it is not part of the protocol. ---------------------------------------------------------------------- Listing all those combined ciphers as N/A for IPsec-v2. As I think the RFC6071 do reflect the concensus of the IPsecME workgroup, and because of this I think we should fix the IANA allocations for the combined mode ciphers (this includes AES-CCM (RFC4835), AES-GCM (RFC4835) and AES-GMAC (RFC4543)) and change them to be RESERVED and add note that they are not really part of IKEv1 protocol. This whole issue comes mostly because there is no version number in the ESP, meaning only way to know whether ESPv2 or ESPv3 is used is by implying that from whether IKEv1 or IKEv2 was used (which do have version numbers). This affects following IANA entries in the isakmp-registry (http://www.iana.org/assignments/isakmp-registry): ---------------------------------------------------------------------- IPSEC ESP Transform Identifiers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Transform ID Value Reference ------------ ----- --------- ESP_AES-CCM_8 14 [RFC4309] ESP_AES-CCM_12 15 [RFC4309] ESP_AES-CCM_16 16 [RFC4309] ESP_AES-GCM_8 18 [RFC4106] ESP_AES-GCM_12 19 [RFC4106] ESP_AES-GCM_16 20 [RFC4106] ESP_NULL_AUTH_AES-GMAC 23 [RFC4543][Errata1821] IPSEC AH Transform Identifiers =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D Transform ID Value Reference ------------ ----- --------- AH_AES-128-GMAC 11 [RFC4543][Errata1821] AH_AES-192-GMAC 12 [RFC4543][Errata1821] AH_AES-256-GMAC 13 [RFC4543][Errata1821] IPSEC Security Association Attributes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Authentication Algorithm Name Value Reference ---- ----- --------- AES-128-GMAC 11 [RFC4543][Errata1821] AES-192-GMAC 12 [RFC4543][Errata1821] AES-256-GMAC 13 [RFC4543][Errata1821] ---------------------------------------------------------------------- I am not really sure what should be done for the AH transform identifiers, as I think the AH_AES-*-GMAC can actually be used without problems in the IPsec-v2 AH, but I am not sure. We have few options: 1) Leave things as they are as this is only for obsoleted protocol that nobody uses... Unfortunately there are still people using this obsoleted protocol and if the numbers are there in the IANA registry as they are now, some implementors might think they can actually implement and then they do end up mixed mode version of IPsec-v2 and IPsec-v3. 2) Change all those entries to be "RESERVED (was xxx)" and add note saying that they are not really a feature of IPsec-v2 and even when there is implementations using them that is not standard way to do it. If those algorithms is needed then ESPv3 (and IKEv2, and RFC4301 architecture) is needed. 3) Change ESP entries to "RESERVED (was xxx)" and add similar note than in 2, but leave AH entries intact. I think the option 2 is the best, i.e clearly mark them that you should not do this, but if you see these numbers you do know that it is some implementation using some wierd mixed IPsec-v2 / v3 feature set. -- kivinen@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec = --1__=0ABBF2F7DFC1DEDC8f9e8a93df938690918c0ABBF2F7DFC1DEDC Content-type: text/html; charset=US-ASCII Content-Disposition: inline Content-transfer-encoding: quoted-printable

Tero, the existence of RFC 4304 represents an even more direct way i= n which ESPv3 and AHv3 have leaked into IKEv1.

I'm inclined to take your option 1, though I would quibble with "n= obody uses." :) Considering both ESN and combined-mode algorithms,= it seems that in practice we have general agreement that it is legitim= ate for two IKEv1 implementations to mutually agree to use ESPv3 and AH= v3 without importing all of IPsec-v3.


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://www.linkedin.com/= in/smoonen

3D"InactiveTero Kivinen ---03/3= 1/2011 10:54:23 AM---In early 2009 there was discussion in the IPsec li= st that the RFC4543 was supposed to allocate numbe

From: Tero K= ivinen <kivinen@iki.fi>
To: ipsec@ie= tf.org
Date: 03/31/= 2011 10:54 AM
Subject: [IP= sec] IANA allocations for combined mode ciphers and IKEv1.
Sent by: ips= ec-bounces@ietf.org




In early 2009 there was discussion in the IPsec list that the RFC45= 43
was supposed to allocate numbers also for IKEv1, not only for IKEv2. There was some discussion on the list and then there was errata 1821 was submitted to the RFC4543 which said those numbers should also be allocated for the IKEv1 IANA registry. At that point we didn't really realize that ESPv2 which is implied by using IKEv1 does not support
= combined mode ciphers.

In the end of 2009 we started to discuss about the IPsec roadmap
document, and then this item came out again. We had open ticket #111 (= http://tools.ietf.org/wg/ipsecme/trac/ticket/111) about th= e issue and
the final wording in the roadmap (now RFC6071) document was:

----------------------------------------------------------------------<= br> 5.4.  Combined Mode Algorithms

  IKEv1 and ESP-v2 use separate algorithms to provide encryption = and
  integrity protection, and IKEv1 can negotiate different combina= tions
  of algorithms for different SAs.  In ESP-v3, a new class o= f
  algorithms was introduced, in which a single algorithm can prov= ide
  both encryption and integrity protection.  [RFC5996] descr= ibes how
  IKEv2 can negotiate combined mode algorithms to be used in ESP-= v3
  SAs.  [RFC5282] adds that capability to IKEv2, enabling IK= Ev2 to
  negotiate and use combined mode algorithms for its own traffic.=  When
  properly designed, these algorithms can provide increased effic= iency
  in both implementation and execution.

  Although ESP-v2 did not originally include combined mode algori= thms,
  some IKEv1 implementations have added the capability to negotia= te
  combined mode algorithms for use in IPsec SAs; these implementa= tions
  do not include the capability to use combined mode algorithms t= o
  protect IKE SAs.  IANA numbers for combined mode algorithm= s have been
  added to the IKEv1 registry.

5.4.1.  RFC 4309, Using Advanced Encryption Standard (AES) CCM Mod= e with
       IPsec Encapsulating Security Payload (ESP) = (S, December 2005)
...
  Requirement levels for AES-CCM:

    IKEv1 - N/A
    IKEv2 - optional
    ESP-v2 - N/A
    ESP-v3 - optional [RFC4835]

  NOTE: The IPsec-v2 IANA registry includes values for AES-CCM, b= ut
  combined mode algorithms are not a feature of IPsec-v2.  A= lthough
  some IKEv1/IPsec-v2 implementations include this capability (se= e
  Section 5.4), it is not part of the protocol.

5.4.2.  RFC 4106, The Use of Galois/Counter Mode (GCM) in IPsec        Encapsulating Security Payload (ESP) (S, Ju= ne 2005)
...
  Requirement levels for AES-GCM:

    IKEv1 - N/A
    IKEv2 - optional
    ESP-v2 - N/A
    ESP-v3 - optional [RFC4835]

  NOTE: The IPsec-v2 IANA registry includes values for AES-GCM, b= ut
  combined mode algorithms are not a feature of IPsec-v2.  A= lthough
  some IKEv1/IPsec-v2 implementations include this capability (se= e
  Section 5.4), it is not part of the protocol.

5.4.3.  RFC 4543, The Use of Galois Message Authentication Code (G= MAC)
       in IPsec ESP and AH (S, May 2006)
...
  Requirement levels for AES-GMAC:

    IKEv1 - N/A
    IKEv2 - N/A
    IPsec-v2 - N/A
    IPsec-v3 - optional

  NOTE: The IPsec-v2 IANA registry includes values for AES-GMAC, = but
  combined mode algorithms are not a feature of IPsec-v2.  A= lthough
  some IKEv1/IPsec-v2 implementations include this capability (se= e
  Section 5.4), it is not part of the protocol.
----------------------------------------------------------------------<= br>
Listing all those combined ciphers as N/A for IPsec-v2.

As I think the RFC6071 do reflect the concensus of the IPsecME
workgroup, and because of this I think we should fix the IANA
allocations for the combined mode ciphers (this includes AES-CCM
(RFC4835), AES-GCM (RFC4835) and AES-GMAC (RFC4543)) and change them to be RESERVED and add note that they are not really part of IKEv1
protocol.

This whole issue comes mostly because there is no version number in
= the ESP, meaning only way to know whether ESPv2 or ESPv3 is used is by<= br> implying that from whether IKEv1 or IKEv2 was used (which do have
version numbers).

This affects following IANA entries in the isakmp-registry
(h= ttp://www.iana.org/assignments/isakmp-registry):

----------------------------------------------------------------------<= br> IPSEC ESP Transform Identifiers
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D

Transform ID         Value       &nb= sp;      Reference
------------         -----       &nb= sp;      ---------
ESP_AES-CCM_8           14      = ;        [RFC4309]
ESP_AES-CCM_12          15      = ;        [RFC4309]
ESP_AES-CCM_16          16      = ;        [RFC4309]
ESP_AES-GCM_8           18      = ;        [RFC4106]
ESP_AES-GCM_12          19      = ;        [RFC4106]
ESP_AES-GCM_16          20      = ;        [RFC4106]
ESP_NULL_AUTH_AES-GMAC  23           &nbs= p;  [RFC4543][Errata1821]

IPSEC AH Transform Identifiers
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D

Transform ID       Value        Refe= rence
------------       -----        ----= -----
AH_AES-128-GMAC       11        [RFC= 4543][Errata1821]
AH_AES-192-GMAC       12        [RFC= 4543][Errata1821]
AH_AES-256-GMAC       13        [RFC= 4543][Errata1821]

IPSEC Security Association Attributes
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 Authentication Algorithm

   Name               &nb= sp;   Value           Reference
   ----               &nb= sp;   -----           ---------
   AES-128-GMAC           11  =            [RFC4543][Errata1821]
   AES-192-GMAC           12  =            [RFC4543][Errata1821]
   AES-256-GMAC           13  =            [RFC4543][Errata1821]
----------------------------------------------------------------------<= br>
I am not really sure what should be done for the AH transform
identifiers, as I think the AH_AES-*-GMAC can actually be used without<= br> problems in the IPsec-v2 AH, but I am not sure.

We have few options:

1) Leave things as they are as this is only for obsoleted protocol
  that nobody uses...

  Unfortunately there are still people using this obsoleted proto= col
  and if the numbers are there in the IANA registry as they are n= ow,
  some implementors might think they can actually implement and t= hen
  they do end up mixed mode version of IPsec-v2 and IPsec-v3.
=
2) Change all those entries to be "RESERVED (was xxx)" and ad= d note
  saying that they are not really a feature of IPsec-v2 and even = when
  there is implementations using them that is not standard way to= do
  it. If those algorithms is needed then ESPv3 (and IKEv2, and   RFC4301 architecture) is needed.

3) Change ESP entries to "RESERVED (was xxx)" and add similar= note
  than in 2, but leave AH entries intact.

I think the option 2 is the best, i.e clearly mark them that you
should not do this, but if you see these numbers you do know that it is some implementation using some wierd mixed IPsec-v2 / v3 feature
= set.
--
kivinen@iki.fi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https:= //www.ietf.org/mailman/listinfo/ipsec

= --1__=0ABBF2F7DFC1DEDC8f9e8a93df938690918c0ABBF2F7DFC1DEDC-- --0__=0ABBF2F7DFC1DEDC8f9e8a93df938690918c0ABBF2F7DFC1DEDC Content-type: image/gif; name="graycol.gif" Content-Disposition: inline; filename="graycol.gif" Content-ID: <1__=0ABBF2F7DFC1DEDC8f9e8a93df938@us.ibm.com> Content-transfer-encoding: base64 R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7 --0__=0ABBF2F7DFC1DEDC8f9e8a93df938690918c0ABBF2F7DFC1DEDC-- From kivinen@iki.fi Thu Mar 31 08:17:48 2011 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CEBB73A6B20 for ; Thu, 31 Mar 2011 08:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.45 X-Spam-Level: X-Spam-Status: No, score=-102.45 tagged_above=-999 required=5 tests=[AWL=0.149, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CnwcUHbqfoqM for ; Thu, 31 Mar 2011 08:17:48 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id BB8153A680E for ; Thu, 31 Mar 2011 08:17:47 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.14.3) with ESMTP id p2VFJQ9k022159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 31 Mar 2011 18:19:26 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id p2VFJQF3009136; Thu, 31 Mar 2011 18:19:26 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19860.39806.597112.802193@fireball.kivinen.iki.fi> Date: Thu, 31 Mar 2011 18:19:26 +0300 From: Tero Kivinen To: Scott C Moonen In-Reply-To: References: <19860.38284.384287.292413@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 7 min Cc: ipsec@ietf.org Subject: Re: [IPsec] IANA allocations for combined mode ciphers and IKEv1. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 31 Mar 2011 15:17:48 -0000 Scott C Moonen writes: > Tero, the existence of RFC 4304 represents an even more direct way in which > ESPv3 and AHv3 have leaked into IKEv1. True. On the other hand that is feature that is explictly negotiated in the IKEv1, which only enables the one specific feature of the ESPv3 to the IKEv1 and IPsec-v2. If you use that option, I do not expect that you are allowed to use traffic flow confidentiality even if you send that option. And we did make our mind when we decided to have the current wording on the RFC6071. > I'm inclined to take your option 1, though I would quibble with "nobody > uses." :) Considering both ESN and combined-mode algorithms, it seems that > in practice we have general agreement that it is legitimate for two IKEv1 > implementations to mutually agree to use ESPv3 and AHv3 without importing > all of IPsec-v3. Which features of IPsec-v3 is imported? Do using any of the features from the ESPv3 mean that all features of ESPv3 are available. Do we take any changes from the RFC4301 too? Perhaps we have 4th option, i.e. just add note saying that this is not really feature which should be used here as it is only defined for ESPv3. Or at least mark those ciphers separately which require (and perhaps imply) ESPv3. But do to that I would really need more text than what would be useful in the IANA footnote, and having new RFC for obsolete IKEv1 would be quite useless... -- kivinen@iki.fi