From ipsec-bounces@ietf.org Sun Jun 1 13:35:22 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7E553A6E6C; Sun, 1 Jun 2008 13:35:22 -0700 (PDT) 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 C4E8F28C28D for ; Sun, 1 Jun 2008 13:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 tFk0gPXXpl9t for ; Sun, 1 Jun 2008 13:32:01 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 165733A6EC2 for ; Sun, 1 Jun 2008 11:12:48 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m51ICiJP027768 for ; Sun, 1 Jun 2008 21:12:44 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 1 Jun 2008 21:12:43 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 1 Jun 2008 21:12:43 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 1 Jun 2008 21:12:41 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: First charter draft Thread-Index: AcjEExTZpsVqNQpLQiGysF5KelF4Pw== From: To: X-OriginalArrivalTime: 01 Jun 2008 18:12:43.0771 (UTC) FILETIME=[164E44B0:01C8C413] X-Nokia-AV: Clean Subject: [IPsec] First charter draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Thanks to everyone who replied to the poll! Based on the responses, I've put together a first draft of charter text, which has IMHO quite reasonable balance between maintenance (ikev2bis, roadmap, ipv6) and the extensions with widest interest (session resumption and redirect). I also tried to come up with some text describing the work items, to make it clear what's in scope and what is not. (Comments on that text are welcome!) This list doesn't include draft-black-ipsec-ikev2-aead-modes, since it's basically read to be published now, and might be out before the WG gets created. Please send comments (either privately or on the list) as soon as possible -- to have the first WG meeting in Dublin, we need to converge on charter text soon (since there are several process steps it needs to go through before the WG is officially approved). Best regards, Pasi ========== IP Security Maintenance and Extensions (ipsecme) DRAFT 2008-06-01 Chair(s): TBD Security Area Director(s): TBD Mailing Lists: General Discussion: ipsec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: http://www.ietf.org/mail-archive/web/ipsec/ Description of Working Group: The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs), IKEv2 (RFC 4106, RFC 4718, and associated RFCs), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group will continue the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions and improvements to IPsec, mostly to IKEv2. The working group will also be a focus point for other IETF Working Groups who use IPsec in their own protocols. The initial set of work items is: o A revision to IKEv2 (RFC 4306) that incorporates the clarifications from RFC 4718, and otherwise improves the quality of the specification, taking into account implementation and interoperability experience. In some cases, the revision may include small technical corrections; however, impact on existing implementations must be considered. Major changes and adding new features is beyond the scope of this work item. The starting point for this work is draft-hoffman-ikev2bis. o An IPsec document roadmap that describes the various RFC documents covering IPsec, including both the core RFC 240x and RFC 430x versions of IPsec, and extensions specified in other documents. Sections 2 and 3 of RFC 2411 can provide useful material, but the expected scope is slightly different from RFC 2411. This document will be informational. o A standards-track extension to IKEv2 that provides full IPv6 support for IPsec remote access clients that use configuration payloads. This work will be based on draft-eronen-ipsec-ikev2-ipv6-config. o A standards-track extension that allows an IPsec remote access client to "resume" a session with a gateway; that is, to skip certain parts of IKE negotation when connecting again to the same gateway (or possibly a cluster of closely cooperating gateways). The idea is similar to TLS session resumption without server-side state, specified in RFC 5077. The main goals for this extension are to avoid public-key computations (to reduce VPN gateway load when a large number of clients reconnect to the geteway within a short period of time, such as following a network outage), and remove the need for user interaction for authentication (which may be required by some authentication mechanisms). The extension shall not have negative impact on IKEv2 security features. Failover from one gateway to another, mechanisms for detecting when a session should be resumed, and specifying communication mechanisms between gateways are beyond the scope of this work item. Specifying the detailed contents of the "session ticket" is also beyond the scope of this document; if there is sufficient interest, this could be specified later in a separate document. To the degree its content falls within the scope of this work item, text and ideas from draft-sheffer-ipsec-failover will be used as a starting point. o A standards-track extension to IPsec that allows an IPsec remote access gateway to redirect VPN clients to another gateway. This extension should be aligned with the session resumption extension, (the previous work item), and if so decided by the WG, could be specified in the same document. The starting point will be draft-devarapalli-ipsec-ikev2-redirect. The initial scope of the WG is restricted to the work items listed above. The WG shall not consider adding new work items until one or more of its documents progress to IESG evaluation. At that time, the WG can propose rechartering. Chartering this WG is not intended to have effect on documents that beyond the initial scope. In particular, work on IPsec extensions that are not included in this charter can happen as usual in other WGs (and there are currently several other WGs working on IPsec extensions; for example, BTNS and ROHC), or as individual submissions. This charter will expire in June 2010 (24 months from approval). If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Goals and Milestones: Dec 2008 WG last call on IPv6 configuration payloads Dec 2008 WG last call on IPsec roadmap Mar 2009 WG last call on IKEv2bis Jan 2009 WG last call on session resumption Feb 2009 WG last call on redirect ================ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 2 06:27:00 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2A6BF3A6887; Mon, 2 Jun 2008 06:27:00 -0700 (PDT) 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 B285E3A6887 for ; Mon, 2 Jun 2008 06:26:58 -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 i-I3tkajG32Z for ; Mon, 2 Jun 2008 06:26:57 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.184]) by core3.amsl.com (Postfix) with ESMTP id 2D1B33A65A6 for ; Mon, 2 Jun 2008 06:26:53 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so445489tib.25 for ; Mon, 02 Jun 2008 06:26:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; bh=ShHKTYizzwt+3IZP1AtP+oQbxVi1juk9T76+G35xDHA=; b=Usvt2m9xI2bh+syLXEstzuTutDk5AdDaKJY8eL8xYR3gUhn1feOK5pAahjTOrx3tadyUIb9TWwaezc0/6oOtBzHu6f9jdvGwlcdF5RgjgdrlqPR4OsL5fUP1a0+s3dsgQwjHpYXuNR6OB7gOptWsclufI0ngcQSgm6mFuGNnzQA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WrgCcrhY79TIgU5UjdcPaZl7MDB3LRYSbuz056D9dLjwCpM8fwBfrEYRNddETnw7NQPBNhVNzNVSKmfU0kKLQ/6yQAOmO4paGQlabZ4Ept1IhSrhihAhA6b5qB1wTLiD5UAu5C9dkdy4apcJGQPP+tocg9wRte2CecB9ep11OpA= Received: by 10.110.26.20 with SMTP id 20mr1395028tiz.23.1212413213634; Mon, 02 Jun 2008 06:26:53 -0700 (PDT) Received: by 10.110.53.11 with HTTP; Mon, 2 Jun 2008 06:26:53 -0700 (PDT) Message-ID: <1d38a3350806020626p77e19435k60ac2dcb014348d6@mail.gmail.com> Date: Mon, 2 Jun 2008 21:26:53 +0800 From: "Hui Deng" To: Pasi.Eronen@nokia.com In-Reply-To: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com> MIME-Version: 1.0 Content-Disposition: inline References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com> Cc: ipsec@ietf.org, "denghui@chinamobile.com" Subject: Re: [IPsec] First charter draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hello, Pasi, Thanks for your hard work to collect these information. Based on mailing list discussion, what we find is GRE key traffic selector is No.6 popularity, there are several different parties from different places interesting in this work, and there are one mobile operator having this requirement. and two experts had reviewed the draft and had deep discussion already. Current charter only list top 5 popular work items, here may I suggest that shall we take the GRE key traffic selector in this phase. It will be appreciate if you could kindly help to consider it, Best regards, -Hui 2008/6/2 : > Thanks to everyone who replied to the poll! > > Based on the responses, I've put together a first draft > of charter text, which has IMHO quite reasonable balance > between maintenance (ikev2bis, roadmap, ipv6) and the > extensions with widest interest (session resumption and redirect). > > I also tried to come up with some text describing the > work items, to make it clear what's in scope and what is not. > (Comments on that text are welcome!) > > This list doesn't include draft-black-ipsec-ikev2-aead-modes, > since it's basically read to be published now, and might be out > before the WG gets created. > > Please send comments (either privately or on the list) > as soon as possible -- to have the first WG meeting in Dublin, > we need to converge on charter text soon (since there are > several process steps it needs to go through before the WG > is officially approved). > > Best regards, > Pasi > > ========== > > IP Security Maintenance and Extensions (ipsecme) > DRAFT 2008-06-01 > > Chair(s): TBD > > Security Area Director(s): TBD > > Mailing Lists: > > General Discussion: ipsec@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec > Archive: http://www.ietf.org/mail-archive/web/ipsec/ > > Description of Working Group: > > The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated > RFCs), IKEv2 (RFC 4106, RFC 4718, and associated RFCs), and the IPsec > security architecture (RFC 4301). IPsec is widely deployed in VPN > gateways, VPN remote access clients, and as a substrate for > host-to-host, host-to-network, and network-to-network security. > > The IPsec Maintenance and Extensions Working Group will continue the > work of the earlier IPsec Working Group which was concluded in > 2005. Its purpose is to maintain the IPsec standard and to facilitate > discussion of clarifications, improvements, and extensions and > improvements to IPsec, mostly to IKEv2. The working group will also > be a focus point for other IETF Working Groups who use IPsec in their > own protocols. > > The initial set of work items is: > > o A revision to IKEv2 (RFC 4306) that incorporates the > clarifications from RFC 4718, and otherwise improves the quality > of the specification, taking into account implementation and > interoperability experience. In some cases, the revision may > include small technical corrections; however, impact on existing > implementations must be considered. Major changes and adding new > features is beyond the scope of this work item. The starting > point for this work is draft-hoffman-ikev2bis. > > o An IPsec document roadmap that describes the various RFC > documents covering IPsec, including both the core RFC 240x > and RFC 430x versions of IPsec, and extensions specified in > other documents. Sections 2 and 3 of RFC 2411 can provide > useful material, but the expected scope is slightly different > from RFC 2411. This document will be informational. > > o A standards-track extension to IKEv2 that provides full IPv6 > support for IPsec remote access clients that use configuration > payloads. This work will be based on > draft-eronen-ipsec-ikev2-ipv6-config. > > o A standards-track extension that allows an IPsec remote access > client to "resume" a session with a gateway; that is, to skip > certain parts of IKE negotation when connecting again to the > same gateway (or possibly a cluster of closely cooperating gateways). > The idea is similar to TLS session resumption without > server-side state, specified in RFC 5077. > > The main goals for this extension are to avoid public-key > computations (to reduce VPN gateway load when a large number of > clients reconnect to the geteway within a short period of time, > such as following a network outage), and remove the need for > user interaction for authentication (which may be required by > some authentication mechanisms). The extension shall not have > negative impact on IKEv2 security features. > > Failover from one gateway to another, mechanisms for detecting > when a session should be resumed, and specifying communication > mechanisms between gateways are beyond the scope of this work > item. Specifying the detailed contents of the "session ticket" > is also beyond the scope of this document; if there is sufficient > interest, this could be specified later in a separate document. > > To the degree its content falls within the scope of this work > item, text and ideas from draft-sheffer-ipsec-failover will be > used as a starting point. > > o A standards-track extension to IPsec that allows an IPsec remote > access gateway to redirect VPN clients to another gateway. This > extension should be aligned with the session resumption extension, > (the previous work item), and if so decided by the WG, could be > specified in the same document. The starting point will be > draft-devarapalli-ipsec-ikev2-redirect. > > The initial scope of the WG is restricted to the work items listed > above. The WG shall not consider adding new work items until one or > more of its documents progress to IESG evaluation. At that time, the > WG can propose rechartering. > > Chartering this WG is not intended to have effect on documents that > beyond the initial scope. In particular, work on IPsec extensions that > are not included in this charter can happen as usual in other WGs (and > there are currently several other WGs working on IPsec extensions; for > example, BTNS and ROHC), or as individual submissions. > > This charter will expire in June 2010 (24 months from approval). If > the charter is not updated before that time, the WG will be closed and > any remaining documents revert back to individual Internet-Drafts. > > Goals and Milestones: > > Dec 2008 WG last call on IPv6 configuration payloads > Dec 2008 WG last call on IPsec roadmap > Mar 2009 WG last call on IKEv2bis > Jan 2009 WG last call on session resumption > Feb 2009 WG last call on redirect > > ================ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 4 10:42:02 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F0AED3A6CE2; Wed, 4 Jun 2008 10:42:01 -0700 (PDT) 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 648FD3A6CC7 for ; Wed, 4 Jun 2008 10:42:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 DRxb2SgoWvsE for ; Wed, 4 Jun 2008 10:41:59 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by core3.amsl.com (Postfix) with ESMTP id 18E653A6CE1 for ; Wed, 4 Jun 2008 10:41:59 -0700 (PDT) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by fmsmga102.fm.intel.com with ESMTP; 04 Jun 2008 10:41:27 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.27,590,1204531200"; d="scan'208";a="256670513" Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by azsmga001.ch.intel.com with ESMTP; 04 Jun 2008 10:42:02 -0700 Received: from fmsmsx881.amr.corp.intel.com ([10.19.19.13]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 4 Jun 2008 10:42:01 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 4 Jun 2008 10:42:00 -0700 Message-ID: In-Reply-To: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] First charter draft Thread-Index: AcjEExTZpsVqNQpLQiGysF5KelF4PwCU67xQ References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com> From: "Grewal, Ken" To: , X-OriginalArrivalTime: 04 Jun 2008 17:42:01.0148 (UTC) FILETIME=[4B418FC0:01C8C66A] Subject: Re: [IPsec] First charter draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Pasi, All, Although I agree with pursuing these items, I would like the group to also consider extensions for IPsec traffic visibility. There are two drafts that are proposing some of these extensions and I am working with some colleagues on submitting an update to one of these shortly. These are: http://www.ietf.org/internet-drafts/draft-hoffman-esp-null-protocol-00.t xt. and http://www.ietf.org/internet-drafts/draft-grewal-ipsec-traffic-visibilit y-00.txt In your draft charter, there are two items related to IPsec VPNs. Although VPN is the predominant use of IPsec today for remote access / site-to-site, I believe one of the reasons that IPsec end-to-end is not widely employed today is due to the lack of traffic visibility in managed environments such as Enterprises. AH is not practical and ESP does not offer enough flexibility. I would like the group to consider a small modification to the charter and include text on using IPsec in real world, end-to-end solutions where practical considerations such as network management tools / intrusion detection / malware scanning tools are unable to operate when the data is encrypted. Having IPsec extensions to accommodate these tools will greatly increase the viability of using IPsec beyond just VPN and remote access. I will be happy to present some of these findings / ideas at the next IETF. Thanks for your consideration... Thanks, - Ken -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Pasi.Eronen@nokia.com Sent: Sunday, June 01, 2008 11:13 AM To: ipsec@ietf.org Subject: [IPsec] First charter draft Thanks to everyone who replied to the poll! Based on the responses, I've put together a first draft of charter text, which has IMHO quite reasonable balance between maintenance (ikev2bis, roadmap, ipv6) and the extensions with widest interest (session resumption and redirect). I also tried to come up with some text describing the work items, to make it clear what's in scope and what is not. (Comments on that text are welcome!) This list doesn't include draft-black-ipsec-ikev2-aead-modes, since it's basically read to be published now, and might be out before the WG gets created. Please send comments (either privately or on the list) as soon as possible -- to have the first WG meeting in Dublin, we need to converge on charter text soon (since there are several process steps it needs to go through before the WG is officially approved). Best regards, Pasi ========== IP Security Maintenance and Extensions (ipsecme) DRAFT 2008-06-01 Chair(s): TBD Security Area Director(s): TBD Mailing Lists: General Discussion: ipsec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: http://www.ietf.org/mail-archive/web/ipsec/ Description of Working Group: The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs), IKEv2 (RFC 4106, RFC 4718, and associated RFCs), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group will continue the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions and improvements to IPsec, mostly to IKEv2. The working group will also be a focus point for other IETF Working Groups who use IPsec in their own protocols. The initial set of work items is: o A revision to IKEv2 (RFC 4306) that incorporates the clarifications from RFC 4718, and otherwise improves the quality of the specification, taking into account implementation and interoperability experience. In some cases, the revision may include small technical corrections; however, impact on existing implementations must be considered. Major changes and adding new features is beyond the scope of this work item. The starting point for this work is draft-hoffman-ikev2bis. o An IPsec document roadmap that describes the various RFC documents covering IPsec, including both the core RFC 240x and RFC 430x versions of IPsec, and extensions specified in other documents. Sections 2 and 3 of RFC 2411 can provide useful material, but the expected scope is slightly different from RFC 2411. This document will be informational. o A standards-track extension to IKEv2 that provides full IPv6 support for IPsec remote access clients that use configuration payloads. This work will be based on draft-eronen-ipsec-ikev2-ipv6-config. o A standards-track extension that allows an IPsec remote access client to "resume" a session with a gateway; that is, to skip certain parts of IKE negotation when connecting again to the same gateway (or possibly a cluster of closely cooperating gateways). The idea is similar to TLS session resumption without server-side state, specified in RFC 5077. The main goals for this extension are to avoid public-key computations (to reduce VPN gateway load when a large number of clients reconnect to the geteway within a short period of time, such as following a network outage), and remove the need for user interaction for authentication (which may be required by some authentication mechanisms). The extension shall not have negative impact on IKEv2 security features. Failover from one gateway to another, mechanisms for detecting when a session should be resumed, and specifying communication mechanisms between gateways are beyond the scope of this work item. Specifying the detailed contents of the "session ticket" is also beyond the scope of this document; if there is sufficient interest, this could be specified later in a separate document. To the degree its content falls within the scope of this work item, text and ideas from draft-sheffer-ipsec-failover will be used as a starting point. o A standards-track extension to IPsec that allows an IPsec remote access gateway to redirect VPN clients to another gateway. This extension should be aligned with the session resumption extension, (the previous work item), and if so decided by the WG, could be specified in the same document. The starting point will be draft-devarapalli-ipsec-ikev2-redirect. The initial scope of the WG is restricted to the work items listed above. The WG shall not consider adding new work items until one or more of its documents progress to IESG evaluation. At that time, the WG can propose rechartering. Chartering this WG is not intended to have effect on documents that beyond the initial scope. In particular, work on IPsec extensions that are not included in this charter can happen as usual in other WGs (and there are currently several other WGs working on IPsec extensions; for example, BTNS and ROHC), or as individual submissions. This charter will expire in June 2010 (24 months from approval). If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Goals and Milestones: Dec 2008 WG last call on IPv6 configuration payloads Dec 2008 WG last call on IPsec roadmap Mar 2009 WG last call on IKEv2bis Jan 2009 WG last call on session resumption Feb 2009 WG last call on redirect ================ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 4 16:31:32 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD5283A6880; Wed, 4 Jun 2008 16:31:32 -0700 (PDT) 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 C58F83A6949 for ; Wed, 4 Jun 2008 16:31:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 CY9P0Rx2f7yq for ; Wed, 4 Jun 2008 16:31:29 -0700 (PDT) Received: from web81901.mail.mud.yahoo.com (web81901.mail.mud.yahoo.com [68.142.207.180]) by core3.amsl.com (Postfix) with SMTP id 901573A696D for ; Wed, 4 Jun 2008 16:31:29 -0700 (PDT) Received: (qmail 5663 invoked by uid 60001); 4 Jun 2008 23:31:23 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=hpkEqtZbojD57W9llv2VfGwRgbWsofOMTYf94rTI+G6JftyVZjP6eSNH8VTuN8+mXncbM2PoeRb/RhZUYv/qPZaefn9OXowG8VxOIFt4ObLD5TFndiyj+o+Ean4auUaTB6L1knnd1R7ajkRN901z4Wzh60eANVpEnWNmA+/84XI=; X-YMail-OSG: .xxU5.kVM1mNHpq6vsZDK.ubRLZbNZNhD7DJ8AmSKUtPIWj8_bRgUD7YAn4bi3arSpp.6jwcrrRMpiPZb_NX5HcZAMgk82uxO69JYWZxLjJnKxb.mQfNFg-- Received: from [131.107.0.103] by web81901.mail.mud.yahoo.com via HTTP; Wed, 04 Jun 2008 16:31:23 PDT X-Mailer: YahooMailRC/975.41 YahooMailWebService/0.7.185 Date: Wed, 4 Jun 2008 16:31:23 -0700 (PDT) From: gabriel montenegro To: "Grewal, Ken" , Pasi.Eronen@nokia.com, ipsec@ietf.org MIME-Version: 1.0 Message-ID: <535271.4153.qm@web81901.mail.mud.yahoo.com> Subject: Re: [IPsec] First charter draft 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: , Content-Type: multipart/mixed; boundary="===============0154437313==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0154437313== Content-Type: multipart/alternative; boundary="0-39615867-1212622283=:4153" --0-39615867-1212622283=:4153 Content-Type: text/plain; charset=us-ascii I agree with Ken. The proposed charter seems adequate for VPN applications, but not for enterprise applications, so his proposed item makes sense. -gabriel ----- Original Message ---- From: "Grewal, Ken" To: Pasi.Eronen@nokia.com; ipsec@ietf.org Sent: Wednesday, June 4, 2008 10:42:00 AM Subject: Re: [IPsec] First charter draft Hi Pasi, All, Although I agree with pursuing these items, I would like the group to also consider extensions for IPsec traffic visibility. There are two drafts that are proposing some of these extensions and I am working with some colleagues on submitting an update to one of these shortly. These are: http://www.ietf.org/internet-drafts/draft-hoffman-esp-null-protocol-00.t xt. and http://www.ietf.org/internet-drafts/draft-grewal-ipsec-traffic-visibilit y-00.txt In your draft charter, there are two items related to IPsec VPNs. Although VPN is the predominant use of IPsec today for remote access / site-to-site, I believe one of the reasons that IPsec end-to-end is not widely employed today is due to the lack of traffic visibility in managed environments such as Enterprises. AH is not practical and ESP does not offer enough flexibility. I would like the group to consider a small modification to the charter and include text on using IPsec in real world, end-to-end solutions where practical considerations such as network management tools / intrusion detection / malware scanning tools are unable to operate when the data is encrypted. Having IPsec extensions to accommodate these tools will greatly increase the viability of using IPsec beyond just VPN and remote access. I will be happy to present some of these findings / ideas at the next IETF. Thanks for your consideration... Thanks, - Ken -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Pasi.Eronen@nokia.com Sent: Sunday, June 01, 2008 11:13 AM To: ipsec@ietf.org Subject: [IPsec] First charter draft Thanks to everyone who replied to the poll! Based on the responses, I've put together a first draft of charter text, which has IMHO quite reasonable balance between maintenance (ikev2bis, roadmap, ipv6) and the extensions with widest interest (session resumption and redirect). I also tried to come up with some text describing the work items, to make it clear what's in scope and what is not. (Comments on that text are welcome!) This list doesn't include draft-black-ipsec-ikev2-aead-modes, since it's basically read to be published now, and might be out before the WG gets created. Please send comments (either privately or on the list) as soon as possible -- to have the first WG meeting in Dublin, we need to converge on charter text soon (since there are several process steps it needs to go through before the WG is officially approved). Best regards, Pasi ========== IP Security Maintenance and Extensions (ipsecme) DRAFT 2008-06-01 Chair(s): TBD Security Area Director(s): TBD Mailing Lists: General Discussion: ipsec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: http://www.ietf.org/mail-archive/web/ipsec/ Description of Working Group: The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs), IKEv2 (RFC 4106, RFC 4718, and associated RFCs), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. The IPsec Maintenance and Extensions Working Group will continue the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions and improvements to IPsec, mostly to IKEv2. The working group will also be a focus point for other IETF Working Groups who use IPsec in their own protocols. The initial set of work items is: o A revision to IKEv2 (RFC 4306) that incorporates the clarifications from RFC 4718, and otherwise improves the quality of the specification, taking into account implementation and interoperability experience. In some cases, the revision may include small technical corrections; however, impact on existing implementations must be considered. Major changes and adding new features is beyond the scope of this work item. The starting point for this work is draft-hoffman-ikev2bis. o An IPsec document roadmap that describes the various RFC documents covering IPsec, including both the core RFC 240x and RFC 430x versions of IPsec, and extensions specified in other documents. Sections 2 and 3 of RFC 2411 can provide useful material, but the expected scope is slightly different from RFC 2411. This document will be informational. o A standards-track extension to IKEv2 that provides full IPv6 support for IPsec remote access clients that use configuration payloads. This work will be based on draft-eronen-ipsec-ikev2-ipv6-config. o A standards-track extension that allows an IPsec remote access client to "resume" a session with a gateway; that is, to skip certain parts of IKE negotation when connecting again to the same gateway (or possibly a cluster of closely cooperating gateways). The idea is similar to TLS session resumption without server-side state, specified in RFC 5077. The main goals for this extension are to avoid public-key computations (to reduce VPN gateway load when a large number of clients reconnect to the geteway within a short period of time, such as following a network outage), and remove the need for user interaction for authentication (which may be required by some authentication mechanisms). The extension shall not have negative impact on IKEv2 security features. Failover from one gateway to another, mechanisms for detecting when a session should be resumed, and specifying communication mechanisms between gateways are beyond the scope of this work item. Specifying the detailed contents of the "session ticket" is also beyond the scope of this document; if there is sufficient interest, this could be specified later in a separate document. To the degree its content falls within the scope of this work item, text and ideas from draft-sheffer-ipsec-failover will be used as a starting point. o A standards-track extension to IPsec that allows an IPsec remote access gateway to redirect VPN clients to another gateway. This extension should be aligned with the session resumption extension, (the previous work item), and if so decided by the WG, could be specified in the same document. The starting point will be draft-devarapalli-ipsec-ikev2-redirect. The initial scope of the WG is restricted to the work items listed above. The WG shall not consider adding new work items until one or more of its documents progress to IESG evaluation. At that time, the WG can propose rechartering. Chartering this WG is not intended to have effect on documents that beyond the initial scope. In particular, work on IPsec extensions that are not included in this charter can happen as usual in other WGs (and there are currently several other WGs working on IPsec extensions; for example, BTNS and ROHC), or as individual submissions. This charter will expire in June 2010 (24 months from approval). If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. Goals and Milestones: Dec 2008 WG last call on IPv6 configuration payloads Dec 2008 WG last call on IPsec roadmap Mar 2009 WG last call on IKEv2bis Jan 2009 WG last call on session resumption Feb 2009 WG last call on redirect ================ _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --0-39615867-1212622283=:4153 Content-Type: text/html; charset=us-ascii
I agree with Ken. The proposed charter seems adequate for VPN applications,
but not for enterprise applications, so his proposed item makes sense.

-gabriel
----- Original Message ----
From: "Grewal, Ken" <ken.grewal@intel.com>
To: Pasi.Eronen@nokia.com; ipsec@ietf.org
Sent: Wednesday, June 4, 2008 10:42:00 AM
Subject: Re: [IPsec] First charter draft

Hi Pasi, All,
Although I agree with pursuing these items, I would like the group to
also consider extensions for IPsec traffic visibility. There are two
drafts that are proposing some of these extensions and I am working with
some colleagues on submitting an update to one of these shortly. These
are:

http://www.ietf.org/internet-drafts/draft-hoffman-esp-null-protocol-00.t
xt.

and

http://www.ietf.org/internet-drafts/draft-grewal-ipsec-traffic-visibilit
y-00.txt

In your draft charter, there are two items related to IPsec VPNs.
Although VPN is the predominant use of IPsec today for remote access /
site-to-site, I believe one of the reasons that IPsec end-to-end is not
widely employed today is due to the lack of traffic visibility in
managed environments such as Enterprises. AH is not practical and ESP
does not offer enough flexibility.

I would like the group to consider a small modification to the charter
and include text on using IPsec in real world, end-to-end solutions
where practical considerations such as network management tools /
intrusion detection / malware scanning tools are unable to operate when
the data is encrypted. Having IPsec extensions to accommodate these
tools will greatly increase the viability of using IPsec beyond just VPN
and remote access.

I will be happy to present some of these findings / ideas at the next
IETF.

Thanks for your consideration...

Thanks,
- Ken


-----Original Message-----
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
Of Pasi.Eronen@nokia.com
Sent: Sunday, June 01, 2008 11:13 AM
To: ipsec@ietf.org
Subject: [IPsec] First charter draft

Thanks to everyone who replied to the poll!

Based on the responses, I've put together a first draft
of charter text, which has IMHO quite reasonable balance
between maintenance (ikev2bis, roadmap, ipv6) and the
extensions with widest interest (session resumption and redirect).

I also tried to come up with some text describing the
work items, to make it clear what's in scope and what is not.
(Comments on that text are welcome!)

This list doesn't include draft-black-ipsec-ikev2-aead-modes,
since it's basically read to be published now, and might be out
before the WG gets created.

Please send comments (either privately or on the list)
as soon as possible -- to have the first WG meeting in Dublin,
we need to converge on charter text soon (since there are
several process steps it needs to go through before the WG
is officially approved).

Best regards,
Pasi

==========

IP Security Maintenance and Extensions (ipsecme)
DRAFT 2008-06-01

Chair(s): TBD

Security Area Director(s): TBD

Mailing Lists:

General Discussion: ipsec@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec
Archive: http://www.ietf.org/mail-archive/web/ipsec/

Description of Working Group:

The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated
RFCs), IKEv2 (RFC 4106, RFC 4718, and associated RFCs), and the IPsec
security architecture (RFC 4301). IPsec is widely deployed in VPN
gateways, VPN remote access clients, and as a substrate for
host-to-host, host-to-network, and network-to-network security.

The IPsec Maintenance and Extensions Working Group will continue the
work of the earlier IPsec Working Group which was concluded in
2005. Its purpose is to maintain the IPsec standard and to facilitate
discussion of clarifications, improvements, and extensions and
improvements to IPsec, mostly to IKEv2. The working group will also
be a focus point for other IETF Working Groups who use IPsec in their
own protocols.

The initial set of work items is:

o  A revision to IKEv2 (RFC 4306) that incorporates the
  clarifications from RFC 4718, and otherwise improves the quality
  of the specification, taking into account implementation and
  interoperability experience.  In some cases, the revision may
  include small technical corrections; however, impact on existing
  implementations must be considered. Major changes and adding new
  features is beyond the scope of this work item. The starting
  point for this work is draft-hoffman-ikev2bis.

o  An IPsec document roadmap that describes the various RFC
  documents covering IPsec, including both the core RFC 240x
  and RFC 430x versions of IPsec, and extensions specified in
  other documents. Sections 2 and 3 of RFC 2411 can provide 
  useful material, but the expected scope is slightly different
  from RFC 2411. This document will be informational.

o  A standards-track extension to IKEv2 that provides full IPv6
  support for IPsec remote access clients that use configuration
  payloads. This work will be based on
  draft-eronen-ipsec-ikev2-ipv6-config.

o  A standards-track extension that allows an IPsec remote access
  client to "resume" a session with a gateway; that is, to skip
  certain parts of IKE negotation when connecting again to the
  same gateway (or possibly a cluster of closely cooperating gateways).

  The idea is similar to TLS session resumption without
  server-side state, specified in RFC 5077.

  The main goals for this extension are to avoid public-key
  computations (to reduce VPN gateway load when a large number of
  clients reconnect to the geteway within a short period of time,
  such as following a network outage), and remove the need for
  user interaction for authentication (which may be required by
  some authentication mechanisms). The extension shall not have
  negative impact on IKEv2 security features.

  Failover from one gateway to another, mechanisms for detecting
  when a session should be resumed, and specifying communication
  mechanisms between gateways are beyond the scope of this work
  item.  Specifying the detailed contents of the "session ticket"
  is also beyond the scope of this document; if there is sufficient
  interest, this could be specified later in a separate document.

  To the degree its content falls within the scope of this work
  item, text and ideas from draft-sheffer-ipsec-failover will be
  used as a starting point.

o  A standards-track extension to IPsec that allows an IPsec remote
  access gateway to redirect VPN clients to another gateway. This
  extension should be aligned with the session resumption extension,
  (the previous work item), and if so decided by the WG, could be
  specified in the same document. The starting point will be
  draft-devarapalli-ipsec-ikev2-redirect.

The initial scope of the WG is restricted to the work items listed
above. The WG shall not consider adding new work items until one or
more of its documents progress to IESG evaluation. At that time, the
WG can propose rechartering.

Chartering this WG is not intended to have effect on documents that
beyond the initial scope. In particular, work on IPsec extensions that
are not included in this charter can happen as usual in other WGs (and
there are currently several other WGs working on IPsec extensions; for
example, BTNS and ROHC), or as individual submissions.

This charter will expire in June 2010 (24 months from approval).  If
the charter is not updated before that time, the WG will be closed and
any remaining documents revert back to individual Internet-Drafts.

Goals and Milestones:

Dec 2008  WG last call on IPv6 configuration payloads
Dec 2008  WG last call on IPsec roadmap
Mar 2009  WG last call on IKEv2bis
Jan 2009  WG last call on session resumption
Feb 2009  WG last call on redirect

================

_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--0-39615867-1212622283=:4153-- --===============0154437313== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============0154437313==-- From ipsec-bounces@ietf.org Wed Jun 4 23:52:25 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39ADF3A6BF0; Wed, 4 Jun 2008 23:52:25 -0700 (PDT) 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 073D13A6BF0 for ; Wed, 4 Jun 2008 23:52:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.15 X-Spam-Level: * X-Spam-Status: No, score=1.15 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_TW=1.335] 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 JvkmFJs0xMpK for ; Wed, 4 Jun 2008 23:52:24 -0700 (PDT) Received: from vfe4.seed.net.tw (vfe4.seed.net.tw [139.175.252.119]) by core3.amsl.com (Postfix) with ESMTP id 0F9883A6802 for ; Wed, 4 Jun 2008 23:52:23 -0700 (PDT) Received: from [203.70.83.89] (port=40825 helo=[10.29.2.32]) by vfe4.seed.net.tw with esmtp (Seednet 4.14:3) id 1K49Kl-00076T-9Z for ipsec@ietf.org; Thu, 05 Jun 2008 14:52:27 +0800 Message-ID: <48478D2B.6060309@cipherium.com.tw> Date: Thu, 05 Jun 2008 14:52:27 +0800 From: mix User-Agent: Thunderbird 2.0.0.14 (X11/20080505) MIME-Version: 1.0 To: ipsec@ietf.org Subject: [IPsec] ipsec rekey issue 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi all, I have a rekey problem reference from http://www.kame.net/racoon/racoon-ml/msg00874.html I use 2.6.21.7 kernel with ipsec-tools 0.6.5 as the server, and Windows XP as the client. Setup a road warrior mode Windows XP <---------------> VPN server <-----------> Internet VPN Tunnel The problem is when the tunnel is built, Windows XP try to download a big file about 200MB. When download progress reached about 120~130MB, Windows XP can not access internet anymore. After about 5 minutes, the tunnel seems work, Windows can access internet again. Any advice will be appreciated _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jun 5 12:42:04 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EB67C3A69CD; Thu, 5 Jun 2008 12:42:03 -0700 (PDT) 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 B23973A69CD for ; Thu, 5 Jun 2008 12:42:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 LW7Fpv96zHMB for ; Thu, 5 Jun 2008 12:41:56 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 936AF3A65A5 for ; Thu, 5 Jun 2008 12:41:56 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m55JeiwQ018498; Thu, 5 Jun 2008 14:42:02 -0500 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Jun 2008 22:42:00 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 5 Jun 2008 22:41:59 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 5 Jun 2008 22:41:58 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] First charter draft Thread-Index: AcjEExTZpsVqNQpLQiGysF5KelF4PwCU67xQADdN7vA= References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com> From: To: , X-OriginalArrivalTime: 05 Jun 2008 19:41:59.0805 (UTC) FILETIME=[386732D0:01C8C744] X-Nokia-AV: Clean Subject: Re: [IPsec] First charter draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I do agree that the current extensions (session resumption and redirect) are mostly targeted to "remote access VPN" use, and having a broader base could be useful. However, we also need to prioritize -- not everything that is useful can be in the *first* charter -- and make sure every work item has sufficient interest (so it actually gets used) and people willing to work on it (so it gets done). If we decide to take more than five items, "GRE key traffic selector" and "ESP NULL traffic visibility" would be the ones with most support. Both also look reasonably simple technically (the actual technical details an implementor would need are probably less than five pages each -- with additional text explaining the motivation, security considerations, etc.), so this could be feasible. However, I'd like to get some more opinions about these work items, especially from people who participated in the discussions about "ESP NULL traffic visibility" earlier. Here's a short summary about these proposed work items: o A standards-track extension to IKEv2 to support using the "Key" field of Generic Routing Encapsulation (GRE) packets, specified in RFC 2890, as a traffic selector (in similar fashion as TCP/UDP port number or ICMP type/code fields). This allows different GRE traffic flows to be mapped to different IPsec SAs. Any further extensions related to the use of IPsec with GRE are beyond the scope of this work item. o A standards-track mechanism that allows an intermediary device, such as a firewall or intrusion detection system, to easily and reliably determine whether an ESP packet is encrypted with the NULL cipher; and if it is, determine the location of the actual payload data inside the packet. The starting points for this work item are draft-grewal-ipsec-traffic-visibility and draft-hoffman- esp-null-protocol. Best regards, Pasi > -----Original Message----- > From: ext Grewal, Ken [mailto:ken.grewal@intel.com] > Sent: 04 June, 2008 20:42 > To: Eronen Pasi (Nokia-NRC/Helsinki); ipsec@ietf.org > Subject: RE: [IPsec] First charter draft > > Hi Pasi, All, > Although I agree with pursuing these items, I would like the group to > also consider extensions for IPsec traffic visibility. There are two > drafts that are proposing some of these extensions and I am > working with > some colleagues on submitting an update to one of these shortly. These > are: > > http://www.ietf.org/internet-drafts/draft-hoffman-esp-null-pro tocol-00.t > xt. > > and > > http://www.ietf.org/internet-drafts/draft-grewal-ipsec-traffic -visibilit > y-00.txt > > In your draft charter, there are two items related to IPsec VPNs. > Although VPN is the predominant use of IPsec today for remote access / > site-to-site, I believe one of the reasons that IPsec > end-to-end is not > widely employed today is due to the lack of traffic visibility in > managed environments such as Enterprises. AH is not practical and ESP > does not offer enough flexibility. > > I would like the group to consider a small modification to the charter > and include text on using IPsec in real world, end-to-end solutions > where practical considerations such as network management tools / > intrusion detection / malware scanning tools are unable to > operate when > the data is encrypted. Having IPsec extensions to accommodate these > tools will greatly increase the viability of using IPsec > beyond just VPN > and remote access. > > I will be happy to present some of these findings / ideas at the next > IETF. > > Thanks for your consideration... > > Thanks, > - Ken > > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Pasi.Eronen@nokia.com > Sent: Sunday, June 01, 2008 11:13 AM > To: ipsec@ietf.org > Subject: [IPsec] First charter draft > > Thanks to everyone who replied to the poll! > > Based on the responses, I've put together a first draft > of charter text, which has IMHO quite reasonable balance > between maintenance (ikev2bis, roadmap, ipv6) and the > extensions with widest interest (session resumption and redirect). > > I also tried to come up with some text describing the > work items, to make it clear what's in scope and what is not. > (Comments on that text are welcome!) > > This list doesn't include draft-black-ipsec-ikev2-aead-modes, > since it's basically read to be published now, and might be out > before the WG gets created. > > Please send comments (either privately or on the list) > as soon as possible -- to have the first WG meeting in Dublin, > we need to converge on charter text soon (since there are > several process steps it needs to go through before the WG > is officially approved). > > Best regards, > Pasi > > ========== > > IP Security Maintenance and Extensions (ipsecme) > DRAFT 2008-06-01 > > Chair(s): TBD > > Security Area Director(s): TBD > > Mailing Lists: > > General Discussion: ipsec@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec > Archive: http://www.ietf.org/mail-archive/web/ipsec/ > > Description of Working Group: > > The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated > RFCs), IKEv2 (RFC 4106, RFC 4718, and associated RFCs), and the IPsec > security architecture (RFC 4301). IPsec is widely deployed in VPN > gateways, VPN remote access clients, and as a substrate for > host-to-host, host-to-network, and network-to-network security. > > The IPsec Maintenance and Extensions Working Group will continue the > work of the earlier IPsec Working Group which was concluded in > 2005. Its purpose is to maintain the IPsec standard and to facilitate > discussion of clarifications, improvements, and extensions and > improvements to IPsec, mostly to IKEv2. The working group will also > be a focus point for other IETF Working Groups who use IPsec in their > own protocols. > > The initial set of work items is: > > o A revision to IKEv2 (RFC 4306) that incorporates the > clarifications from RFC 4718, and otherwise improves the quality > of the specification, taking into account implementation and > interoperability experience. In some cases, the revision may > include small technical corrections; however, impact on existing > implementations must be considered. Major changes and adding new > features is beyond the scope of this work item. The starting > point for this work is draft-hoffman-ikev2bis. > > o An IPsec document roadmap that describes the various RFC > documents covering IPsec, including both the core RFC 240x > and RFC 430x versions of IPsec, and extensions specified in > other documents. Sections 2 and 3 of RFC 2411 can provide > useful material, but the expected scope is slightly different > from RFC 2411. This document will be informational. > > o A standards-track extension to IKEv2 that provides full IPv6 > support for IPsec remote access clients that use configuration > payloads. This work will be based on > draft-eronen-ipsec-ikev2-ipv6-config. > > o A standards-track extension that allows an IPsec remote access > client to "resume" a session with a gateway; that is, to skip > certain parts of IKE negotation when connecting again to the > same gateway (or possibly a cluster of closely cooperating > gateways). > > The idea is similar to TLS session resumption without > server-side state, specified in RFC 5077. > > The main goals for this extension are to avoid public-key > computations (to reduce VPN gateway load when a large number of > clients reconnect to the geteway within a short period of time, > such as following a network outage), and remove the need for > user interaction for authentication (which may be required by > some authentication mechanisms). The extension shall not have > negative impact on IKEv2 security features. > > Failover from one gateway to another, mechanisms for detecting > when a session should be resumed, and specifying communication > mechanisms between gateways are beyond the scope of this work > item. Specifying the detailed contents of the "session ticket" > is also beyond the scope of this document; if there is sufficient > interest, this could be specified later in a separate document. > > To the degree its content falls within the scope of this work > item, text and ideas from draft-sheffer-ipsec-failover will be > used as a starting point. > > o A standards-track extension to IPsec that allows an IPsec remote > access gateway to redirect VPN clients to another gateway. This > extension should be aligned with the session resumption extension, > (the previous work item), and if so decided by the WG, could be > specified in the same document. The starting point will be > draft-devarapalli-ipsec-ikev2-redirect. > > The initial scope of the WG is restricted to the work items listed > above. The WG shall not consider adding new work items until one or > more of its documents progress to IESG evaluation. At that time, the > WG can propose rechartering. > > Chartering this WG is not intended to have effect on documents that > beyond the initial scope. In particular, work on IPsec extensions that > are not included in this charter can happen as usual in other WGs (and > there are currently several other WGs working on IPsec extensions; for > example, BTNS and ROHC), or as individual submissions. > > This charter will expire in June 2010 (24 months from approval). If > the charter is not updated before that time, the WG will be closed and > any remaining documents revert back to individual Internet-Drafts. > > Goals and Milestones: > > Dec 2008 WG last call on IPv6 configuration payloads > Dec 2008 WG last call on IPsec roadmap > Mar 2009 WG last call on IKEv2bis > Jan 2009 WG last call on session resumption > Feb 2009 WG last call on redirect > > ================ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jun 5 20:25:16 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 695803A6A82; Thu, 5 Jun 2008 20:25:16 -0700 (PDT) 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 DBA753A6A7D for ; Thu, 5 Jun 2008 20:25:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.022 X-Spam-Level: X-Spam-Status: No, score=0.022 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HOST_EQ_STATIC=1.172, MSGID_MULTIPLE_AT=1.449] 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 sbgzJuXap2ST for ; Thu, 5 Jun 2008 20:25:13 -0700 (PDT) Received: from mail.zteusa.com (28.2a.0540.static.theplanet.com [64.5.42.40]) by core3.amsl.com (Postfix) with ESMTP id D771A3A69C8 for ; Thu, 5 Jun 2008 20:25:12 -0700 (PDT) Received: from ywu (ip72-192-167-236.sd.sd.cox.net [72.192.167.236]) by mail.zteusa.com (8.13.4/8.13.4/SuSE Linux 0.7) with ESMTP id m563PlES017978 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 5 Jun 2008 22:25:48 -0500 From: "Yingzhe Wu" To: , , References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com> Date: Thu, 5 Jun 2008 20:25:18 -0700 Message-ID: <000601c8c784$f2fa9ca0$d8efd5e0$@wu@zteusa.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcjEExTZpsVqNQpLQiGysF5KelF4PwCU67xQADdN7vAAEBDXUA== Content-Language: en-us Subject: Re: [IPsec] First charter draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Pasi, Since these are relatively simple techniques, including those shouldn't impact the work group schedule. I fully support including the "GRE key traffic selector" in the work group charter. Thanks, Yingzhe -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Pasi.Eronen@nokia.com Sent: Thursday, June 05, 2008 12:42 PM To: ken.grewal@intel.com; ipsec@ietf.org Subject: Re: [IPsec] First charter draft I do agree that the current extensions (session resumption and redirect) are mostly targeted to "remote access VPN" use, and having a broader base could be useful. However, we also need to prioritize -- not everything that is useful can be in the *first* charter -- and make sure every work item has sufficient interest (so it actually gets used) and people willing to work on it (so it gets done). If we decide to take more than five items, "GRE key traffic selector" and "ESP NULL traffic visibility" would be the ones with most support. Both also look reasonably simple technically (the actual technical details an implementor would need are probably less than five pages each -- with additional text explaining the motivation, security considerations, etc.), so this could be feasible. However, I'd like to get some more opinions about these work items, especially from people who participated in the discussions about "ESP NULL traffic visibility" earlier. Here's a short summary about these proposed work items: o A standards-track extension to IKEv2 to support using the "Key" field of Generic Routing Encapsulation (GRE) packets, specified in RFC 2890, as a traffic selector (in similar fashion as TCP/UDP port number or ICMP type/code fields). This allows different GRE traffic flows to be mapped to different IPsec SAs. Any further extensions related to the use of IPsec with GRE are beyond the scope of this work item. o A standards-track mechanism that allows an intermediary device, such as a firewall or intrusion detection system, to easily and reliably determine whether an ESP packet is encrypted with the NULL cipher; and if it is, determine the location of the actual payload data inside the packet. The starting points for this work item are draft-grewal-ipsec-traffic-visibility and draft-hoffman- esp-null-protocol. Best regards, Pasi > -----Original Message----- > From: ext Grewal, Ken [mailto:ken.grewal@intel.com] > Sent: 04 June, 2008 20:42 > To: Eronen Pasi (Nokia-NRC/Helsinki); ipsec@ietf.org > Subject: RE: [IPsec] First charter draft > > Hi Pasi, All, > Although I agree with pursuing these items, I would like the group to > also consider extensions for IPsec traffic visibility. There are two > drafts that are proposing some of these extensions and I am > working with > some colleagues on submitting an update to one of these shortly. These > are: > > http://www.ietf.org/internet-drafts/draft-hoffman-esp-null-pro tocol-00.t > xt. > > and > > http://www.ietf.org/internet-drafts/draft-grewal-ipsec-traffic -visibilit > y-00.txt > > In your draft charter, there are two items related to IPsec VPNs. > Although VPN is the predominant use of IPsec today for remote access / > site-to-site, I believe one of the reasons that IPsec > end-to-end is not > widely employed today is due to the lack of traffic visibility in > managed environments such as Enterprises. AH is not practical and ESP > does not offer enough flexibility. > > I would like the group to consider a small modification to the charter > and include text on using IPsec in real world, end-to-end solutions > where practical considerations such as network management tools / > intrusion detection / malware scanning tools are unable to > operate when > the data is encrypted. Having IPsec extensions to accommodate these > tools will greatly increase the viability of using IPsec > beyond just VPN > and remote access. > > I will be happy to present some of these findings / ideas at the next > IETF. > > Thanks for your consideration... > > Thanks, > - Ken > > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Pasi.Eronen@nokia.com > Sent: Sunday, June 01, 2008 11:13 AM > To: ipsec@ietf.org > Subject: [IPsec] First charter draft > > Thanks to everyone who replied to the poll! > > Based on the responses, I've put together a first draft > of charter text, which has IMHO quite reasonable balance > between maintenance (ikev2bis, roadmap, ipv6) and the > extensions with widest interest (session resumption and redirect). > > I also tried to come up with some text describing the > work items, to make it clear what's in scope and what is not. > (Comments on that text are welcome!) > > This list doesn't include draft-black-ipsec-ikev2-aead-modes, > since it's basically read to be published now, and might be out > before the WG gets created. > > Please send comments (either privately or on the list) > as soon as possible -- to have the first WG meeting in Dublin, > we need to converge on charter text soon (since there are > several process steps it needs to go through before the WG > is officially approved). > > Best regards, > Pasi > > ========== > > IP Security Maintenance and Extensions (ipsecme) > DRAFT 2008-06-01 > > Chair(s): TBD > > Security Area Director(s): TBD > > Mailing Lists: > > General Discussion: ipsec@ietf.org > To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec > Archive: http://www.ietf.org/mail-archive/web/ipsec/ > > Description of Working Group: > > The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated > RFCs), IKEv2 (RFC 4106, RFC 4718, and associated RFCs), and the IPsec > security architecture (RFC 4301). IPsec is widely deployed in VPN > gateways, VPN remote access clients, and as a substrate for > host-to-host, host-to-network, and network-to-network security. > > The IPsec Maintenance and Extensions Working Group will continue the > work of the earlier IPsec Working Group which was concluded in > 2005. Its purpose is to maintain the IPsec standard and to facilitate > discussion of clarifications, improvements, and extensions and > improvements to IPsec, mostly to IKEv2. The working group will also > be a focus point for other IETF Working Groups who use IPsec in their > own protocols. > > The initial set of work items is: > > o A revision to IKEv2 (RFC 4306) that incorporates the > clarifications from RFC 4718, and otherwise improves the quality > of the specification, taking into account implementation and > interoperability experience. In some cases, the revision may > include small technical corrections; however, impact on existing > implementations must be considered. Major changes and adding new > features is beyond the scope of this work item. The starting > point for this work is draft-hoffman-ikev2bis. > > o An IPsec document roadmap that describes the various RFC > documents covering IPsec, including both the core RFC 240x > and RFC 430x versions of IPsec, and extensions specified in > other documents. Sections 2 and 3 of RFC 2411 can provide > useful material, but the expected scope is slightly different > from RFC 2411. This document will be informational. > > o A standards-track extension to IKEv2 that provides full IPv6 > support for IPsec remote access clients that use configuration > payloads. This work will be based on > draft-eronen-ipsec-ikev2-ipv6-config. > > o A standards-track extension that allows an IPsec remote access > client to "resume" a session with a gateway; that is, to skip > certain parts of IKE negotation when connecting again to the > same gateway (or possibly a cluster of closely cooperating > gateways). > > The idea is similar to TLS session resumption without > server-side state, specified in RFC 5077. > > The main goals for this extension are to avoid public-key > computations (to reduce VPN gateway load when a large number of > clients reconnect to the geteway within a short period of time, > such as following a network outage), and remove the need for > user interaction for authentication (which may be required by > some authentication mechanisms). The extension shall not have > negative impact on IKEv2 security features. > > Failover from one gateway to another, mechanisms for detecting > when a session should be resumed, and specifying communication > mechanisms between gateways are beyond the scope of this work > item. Specifying the detailed contents of the "session ticket" > is also beyond the scope of this document; if there is sufficient > interest, this could be specified later in a separate document. > > To the degree its content falls within the scope of this work > item, text and ideas from draft-sheffer-ipsec-failover will be > used as a starting point. > > o A standards-track extension to IPsec that allows an IPsec remote > access gateway to redirect VPN clients to another gateway. This > extension should be aligned with the session resumption extension, > (the previous work item), and if so decided by the WG, could be > specified in the same document. The starting point will be > draft-devarapalli-ipsec-ikev2-redirect. > > The initial scope of the WG is restricted to the work items listed > above. The WG shall not consider adding new work items until one or > more of its documents progress to IESG evaluation. At that time, the > WG can propose rechartering. > > Chartering this WG is not intended to have effect on documents that > beyond the initial scope. In particular, work on IPsec extensions that > are not included in this charter can happen as usual in other WGs (and > there are currently several other WGs working on IPsec extensions; for > example, BTNS and ROHC), or as individual submissions. > > This charter will expire in June 2010 (24 months from approval). If > the charter is not updated before that time, the WG will be closed and > any remaining documents revert back to individual Internet-Drafts. > > Goals and Milestones: > > Dec 2008 WG last call on IPv6 configuration payloads > Dec 2008 WG last call on IPsec roadmap > Mar 2009 WG last call on IKEv2bis > Jan 2009 WG last call on session resumption > Feb 2009 WG last call on redirect > > ================ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jun 5 22:53:56 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC99228C131; Thu, 5 Jun 2008 22:53:56 -0700 (PDT) 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 8BB8E28C131 for ; Thu, 5 Jun 2008 22:53:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 RdFfQL2BGm+m for ; Thu, 5 Jun 2008 22:53:53 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 8D62B3A6B74 for ; Thu, 5 Jun 2008 22:53:49 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 7455B294006; Fri, 6 Jun 2008 08:53:56 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id F3AC7294004; Fri, 6 Jun 2008 08:53:54 +0300 (IDT) Received: from [172.16.10.236] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m565rqjI029717; Fri, 6 Jun 2008 08:53:53 +0300 (IDT) Message-ID: <4848D0E7.4030306@checkpoint.com> Date: Fri, 06 Jun 2008 08:53:43 +0300 From: Yaron Sheffer User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com> Cc: ipsec@ietf.org, ken.grewal@intel.com Subject: Re: [IPsec] First charter draft 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: , Content-Type: multipart/mixed; boundary="===============0253671824==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0253671824== Content-Type: multipart/alternative; boundary="------------060508050003000808060204" This is a multi-part message in MIME format. --------------060508050003000808060204 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Pasi, looking back at the mailing list around Sep. 2007, most of the ESP-NULL discussion was around the implementation issues (1 vs. 2 protocol numbers etc.). Only a few people commented on the utility of this solution. And I find Tero's arguments rather convincing: you need to implement stateful protocol inspection anyway, and the new marking buys you very little. I believe the ONLY thing you gain is deterministic parsing of ESP packets in deployments where different ESP packets contain IV values of different lengths. I doubt that this is a good enough justification. Thanks, Yaron Pasi.Eronen@nokia.com wrote: > I do agree that the current extensions (session resumption and > redirect) are mostly targeted to "remote access VPN" use, and > having a broader base could be useful. > > However, we also need to prioritize -- not everything that is > useful can be in the *first* charter -- and make sure every work > item has sufficient interest (so it actually gets used) and people > willing to work on it (so it gets done). > > If we decide to take more than five items, "GRE key traffic selector" > and "ESP NULL traffic visibility" would be the ones with most support. > > Both also look reasonably simple technically (the actual technical > details an implementor would need are probably less than five pages > each -- with additional text explaining the motivation, security > considerations, etc.), so this could be feasible. > > However, I'd like to get some more opinions about these work > items, especially from people who participated in the discussions > about "ESP NULL traffic visibility" earlier. > > Here's a short summary about these proposed work items: > > o A standards-track extension to IKEv2 to support using the "Key" > field of Generic Routing Encapsulation (GRE) packets, specified > in RFC 2890, as a traffic selector (in similar fashion as TCP/UDP > port number or ICMP type/code fields). This allows different GRE > traffic flows to be mapped to different IPsec SAs. Any further > extensions related to the use of IPsec with GRE are beyond the > scope of this work item. > > o A standards-track mechanism that allows an intermediary device, > such as a firewall or intrusion detection system, to easily and > reliably determine whether an ESP packet is encrypted with the > NULL cipher; and if it is, determine the location of the actual > payload data inside the packet. The starting points for this work > item are draft-grewal-ipsec-traffic-visibility and draft-hoffman- > esp-null-protocol. > > Best regards, > Pasi > > >> -----Original Message----- >> From: ext Grewal, Ken [mailto:ken.grewal@intel.com] >> Sent: 04 June, 2008 20:42 >> To: Eronen Pasi (Nokia-NRC/Helsinki); ipsec@ietf.org >> Subject: RE: [IPsec] First charter draft >> >> Hi Pasi, All, >> Although I agree with pursuing these items, I would like the group to >> also consider extensions for IPsec traffic visibility. There are two >> drafts that are proposing some of these extensions and I am >> working with >> some colleagues on submitting an update to one of these shortly. These >> are: >> >> http://www.ietf.org/internet-drafts/draft-hoffman-esp-null-pro >> > tocol-00.t > >> xt. >> >> and >> >> http://www.ietf.org/internet-drafts/draft-grewal-ipsec-traffic >> > -visibilit > >> y-00.txt >> >> In your draft charter, there are two items related to IPsec VPNs. >> Although VPN is the predominant use of IPsec today for remote access / >> site-to-site, I believe one of the reasons that IPsec >> end-to-end is not >> widely employed today is due to the lack of traffic visibility in >> managed environments such as Enterprises. AH is not practical and ESP >> does not offer enough flexibility. >> >> I would like the group to consider a small modification to the charter >> and include text on using IPsec in real world, end-to-end solutions >> where practical considerations such as network management tools / >> intrusion detection / malware scanning tools are unable to >> operate when >> the data is encrypted. Having IPsec extensions to accommodate these >> tools will greatly increase the viability of using IPsec >> beyond just VPN >> and remote access. >> >> I will be happy to present some of these findings / ideas at the next >> IETF. >> >> Thanks for your consideration... >> >> Thanks, >> - Ken >> >> >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >> Of Pasi.Eronen@nokia.com >> Sent: Sunday, June 01, 2008 11:13 AM >> To: ipsec@ietf.org >> Subject: [IPsec] First charter draft >> >> Thanks to everyone who replied to the poll! >> >> Based on the responses, I've put together a first draft >> of charter text, which has IMHO quite reasonable balance >> between maintenance (ikev2bis, roadmap, ipv6) and the >> extensions with widest interest (session resumption and redirect). >> >> I also tried to come up with some text describing the >> work items, to make it clear what's in scope and what is not. >> (Comments on that text are welcome!) >> >> This list doesn't include draft-black-ipsec-ikev2-aead-modes, >> since it's basically read to be published now, and might be out >> before the WG gets created. >> >> Please send comments (either privately or on the list) >> as soon as possible -- to have the first WG meeting in Dublin, >> we need to converge on charter text soon (since there are >> several process steps it needs to go through before the WG >> is officially approved). >> >> Best regards, >> Pasi >> >> ========== >> >> IP Security Maintenance and Extensions (ipsecme) >> DRAFT 2008-06-01 >> >> Chair(s): TBD >> >> Security Area Director(s): TBD >> >> Mailing Lists: >> >> General Discussion: ipsec@ietf.org >> To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec >> Archive: http://www.ietf.org/mail-archive/web/ipsec/ >> >> Description of Working Group: >> >> The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated >> RFCs), IKEv2 (RFC 4106, RFC 4718, and associated RFCs), and the IPsec >> security architecture (RFC 4301). IPsec is widely deployed in VPN >> gateways, VPN remote access clients, and as a substrate for >> host-to-host, host-to-network, and network-to-network security. >> >> The IPsec Maintenance and Extensions Working Group will continue the >> work of the earlier IPsec Working Group which was concluded in >> 2005. Its purpose is to maintain the IPsec standard and to facilitate >> discussion of clarifications, improvements, and extensions and >> improvements to IPsec, mostly to IKEv2. The working group will also >> be a focus point for other IETF Working Groups who use IPsec in their >> own protocols. >> >> The initial set of work items is: >> >> o A revision to IKEv2 (RFC 4306) that incorporates the >> clarifications from RFC 4718, and otherwise improves the quality >> of the specification, taking into account implementation and >> interoperability experience. In some cases, the revision may >> include small technical corrections; however, impact on existing >> implementations must be considered. Major changes and adding new >> features is beyond the scope of this work item. The starting >> point for this work is draft-hoffman-ikev2bis. >> >> o An IPsec document roadmap that describes the various RFC >> documents covering IPsec, including both the core RFC 240x >> and RFC 430x versions of IPsec, and extensions specified in >> other documents. Sections 2 and 3 of RFC 2411 can provide >> useful material, but the expected scope is slightly different >> from RFC 2411. This document will be informational. >> >> o A standards-track extension to IKEv2 that provides full IPv6 >> support for IPsec remote access clients that use configuration >> payloads. This work will be based on >> draft-eronen-ipsec-ikev2-ipv6-config. >> >> o A standards-track extension that allows an IPsec remote access >> client to "resume" a session with a gateway; that is, to skip >> certain parts of IKE negotation when connecting again to the >> same gateway (or possibly a cluster of closely cooperating >> gateways). >> >> The idea is similar to TLS session resumption without >> server-side state, specified in RFC 5077. >> >> The main goals for this extension are to avoid public-key >> computations (to reduce VPN gateway load when a large number of >> clients reconnect to the geteway within a short period of time, >> such as following a network outage), and remove the need for >> user interaction for authentication (which may be required by >> some authentication mechanisms). The extension shall not have >> negative impact on IKEv2 security features. >> >> Failover from one gateway to another, mechanisms for detecting >> when a session should be resumed, and specifying communication >> mechanisms between gateways are beyond the scope of this work >> item. Specifying the detailed contents of the "session ticket" >> is also beyond the scope of this document; if there is sufficient >> interest, this could be specified later in a separate document. >> >> To the degree its content falls within the scope of this work >> item, text and ideas from draft-sheffer-ipsec-failover will be >> used as a starting point. >> >> o A standards-track extension to IPsec that allows an IPsec remote >> access gateway to redirect VPN clients to another gateway. This >> extension should be aligned with the session resumption extension, >> (the previous work item), and if so decided by the WG, could be >> specified in the same document. The starting point will be >> draft-devarapalli-ipsec-ikev2-redirect. >> >> The initial scope of the WG is restricted to the work items listed >> above. The WG shall not consider adding new work items until one or >> more of its documents progress to IESG evaluation. At that time, the >> WG can propose rechartering. >> >> Chartering this WG is not intended to have effect on documents that >> beyond the initial scope. In particular, work on IPsec extensions that >> are not included in this charter can happen as usual in other WGs (and >> there are currently several other WGs working on IPsec extensions; for >> example, BTNS and ROHC), or as individual submissions. >> >> This charter will expire in June 2010 (24 months from approval). If >> the charter is not updated before that time, the WG will be closed and >> any remaining documents revert back to individual Internet-Drafts. >> >> Goals and Milestones: >> >> Dec 2008 WG last call on IPv6 configuration payloads >> Dec 2008 WG last call on IPsec roadmap >> Mar 2009 WG last call on IKEv2bis >> Jan 2009 WG last call on session resumption >> Feb 2009 WG last call on redirect >> >> ================ >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. > > --------------060508050003000808060204 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Pasi,

looking back at the mailing list around Sep. 2007, most of the ESP-NULL discussion was around the implementation issues (1 vs. 2 protocol numbers etc.). Only a few people commented on the utility of this solution. And I find Tero's arguments rather convincing: you need to implement stateful protocol inspection anyway, and the new marking buys you very little.

I believe the ONLY thing you gain is deterministic parsing of ESP packets in deployments where different ESP packets contain IV values of different lengths. I doubt that this is a good enough justification.

Thanks,
    Yaron

Pasi.Eronen@nokia.com wrote: 
I do agree that the current extensions (session resumption and
redirect) are mostly targeted to "remote access VPN" use, and 
having a broader base could be useful.

However, we also need to prioritize -- not everything that is 
useful can be in the *first* charter -- and make sure every work 
item has sufficient interest (so it actually gets used) and people 
willing to work on it (so it gets done).

If we decide to take more than five items, "GRE key traffic selector"
and "ESP NULL traffic visibility" would be the ones with most support.

Both also look reasonably simple technically (the actual technical
details an implementor would need are probably less than five pages
each -- with additional text explaining the motivation, security
considerations, etc.), so this could be feasible.

However, I'd like to get some more opinions about these work
items, especially from people who participated in the discussions
about "ESP NULL traffic visibility" earlier.

Here's a short summary about these proposed work items:

o  A standards-track extension to IKEv2 to support using the "Key" 
   field of Generic Routing Encapsulation (GRE) packets, specified 
   in RFC 2890, as a traffic selector (in similar fashion as TCP/UDP 
   port number or ICMP type/code fields). This allows different GRE 
   traffic flows to be mapped to different IPsec SAs.  Any further 
   extensions related to the use of IPsec with GRE are beyond the 
   scope of this work item.

o  A standards-track mechanism that allows an intermediary device,
   such as a firewall or intrusion detection system, to easily and
   reliably determine whether an ESP packet is encrypted with the 
   NULL cipher; and if it is, determine the location of the actual 
   payload data inside the packet. The starting points for this work 
   item are draft-grewal-ipsec-traffic-visibility and draft-hoffman-
   esp-null-protocol.

Best regards,
Pasi 

  
-----Original Message-----
From: ext Grewal, Ken [mailto:ken.grewal@intel.com] 
Sent: 04 June, 2008 20:42
To: Eronen Pasi (Nokia-NRC/Helsinki); ipsec@ietf.org
Subject: RE: [IPsec] First charter draft

Hi Pasi, All, 
Although I agree with pursuing these items, I would like the group to
also consider extensions for IPsec traffic visibility. There are two
drafts that are proposing some of these extensions and I am 
working with
some colleagues on submitting an update to one of these shortly. These
are:

http://www.ietf.org/internet-drafts/draft-hoffman-esp-null-pro
    
tocol-00.t
  
xt.

and

http://www.ietf.org/internet-drafts/draft-grewal-ipsec-traffic
    
-visibilit
  
y-00.txt

In your draft charter, there are two items related to IPsec VPNs.
Although VPN is the predominant use of IPsec today for remote access /
site-to-site, I believe one of the reasons that IPsec 
end-to-end is not
widely employed today is due to the lack of traffic visibility in
managed environments such as Enterprises. AH is not practical and ESP
does not offer enough flexibility. 

I would like the group to consider a small modification to the charter
and include text on using IPsec in real world, end-to-end solutions
where practical considerations such as network management tools /
intrusion detection / malware scanning tools are unable to 
operate when
the data is encrypted. Having IPsec extensions to accommodate these
tools will greatly increase the viability of using IPsec 
beyond just VPN
and remote access.

I will be happy to present some of these findings / ideas at the next
IETF.

Thanks for your consideration... 

Thanks, 
- Ken
 

-----Original Message-----
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf
Of Pasi.Eronen@nokia.com
Sent: Sunday, June 01, 2008 11:13 AM
To: ipsec@ietf.org
Subject: [IPsec] First charter draft

Thanks to everyone who replied to the poll!

Based on the responses, I've put together a first draft 
of charter text, which has IMHO quite reasonable balance 
between maintenance (ikev2bis, roadmap, ipv6) and the 
extensions with widest interest (session resumption and redirect).

I also tried to come up with some text describing the 
work items, to make it clear what's in scope and what is not.
(Comments on that text are welcome!)

This list doesn't include draft-black-ipsec-ikev2-aead-modes,
since it's basically read to be published now, and might be out
before the WG gets created.

Please send comments (either privately or on the list) 
as soon as possible -- to have the first WG meeting in Dublin,
we need to converge on charter text soon (since there are
several process steps it needs to go through before the WG
is officially approved).

Best regards,
Pasi

==========

IP Security Maintenance and Extensions (ipsecme)
DRAFT 2008-06-01

Chair(s): TBD

Security Area Director(s): TBD

Mailing Lists:

General Discussion: ipsec@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec
Archive: http://www.ietf.org/mail-archive/web/ipsec/

Description of Working Group:

The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated
RFCs), IKEv2 (RFC 4106, RFC 4718, and associated RFCs), and the IPsec
security architecture (RFC 4301). IPsec is widely deployed in VPN
gateways, VPN remote access clients, and as a substrate for
host-to-host, host-to-network, and network-to-network security.

The IPsec Maintenance and Extensions Working Group will continue the
work of the earlier IPsec Working Group which was concluded in
2005. Its purpose is to maintain the IPsec standard and to facilitate
discussion of clarifications, improvements, and extensions and
improvements to IPsec, mostly to IKEv2. The working group will also 
be a focus point for other IETF Working Groups who use IPsec in their 
own protocols.

The initial set of work items is:

o  A revision to IKEv2 (RFC 4306) that incorporates the
   clarifications from RFC 4718, and otherwise improves the quality
   of the specification, taking into account implementation and
   interoperability experience.  In some cases, the revision may
   include small technical corrections; however, impact on existing
   implementations must be considered. Major changes and adding new
   features is beyond the scope of this work item. The starting
   point for this work is draft-hoffman-ikev2bis. 

o  An IPsec document roadmap that describes the various RFC 
   documents covering IPsec, including both the core RFC 240x 
   and RFC 430x versions of IPsec, and extensions specified in 
   other documents. Sections 2 and 3 of RFC 2411 can provide  
   useful material, but the expected scope is slightly different 
   from RFC 2411. This document will be informational.

o  A standards-track extension to IKEv2 that provides full IPv6
   support for IPsec remote access clients that use configuration
   payloads. This work will be based on
   draft-eronen-ipsec-ikev2-ipv6-config.

o  A standards-track extension that allows an IPsec remote access
   client to "resume" a session with a gateway; that is, to skip 
   certain parts of IKE negotation when connecting again to the 
   same gateway (or possibly a cluster of closely cooperating 
gateways).

   The idea is similar to TLS session resumption without
   server-side state, specified in RFC 5077.

   The main goals for this extension are to avoid public-key
   computations (to reduce VPN gateway load when a large number of
   clients reconnect to the geteway within a short period of time,
   such as following a network outage), and remove the need for
   user interaction for authentication (which may be required by
   some authentication mechanisms). The extension shall not have 
   negative impact on IKEv2 security features.

   Failover from one gateway to another, mechanisms for detecting
   when a session should be resumed, and specifying communication
   mechanisms between gateways are beyond the scope of this work
   item.  Specifying the detailed contents of the "session ticket"
   is also beyond the scope of this document; if there is sufficient 
   interest, this could be specified later in a separate document.

   To the degree its content falls within the scope of this work
   item, text and ideas from draft-sheffer-ipsec-failover will be
   used as a starting point.

o  A standards-track extension to IPsec that allows an IPsec remote
   access gateway to redirect VPN clients to another gateway. This
   extension should be aligned with the session resumption extension,
   (the previous work item), and if so decided by the WG, could be
   specified in the same document. The starting point will be
   draft-devarapalli-ipsec-ikev2-redirect.

The initial scope of the WG is restricted to the work items listed
above. The WG shall not consider adding new work items until one or
more of its documents progress to IESG evaluation. At that time, the
WG can propose rechartering.

Chartering this WG is not intended to have effect on documents that
beyond the initial scope. In particular, work on IPsec extensions that
are not included in this charter can happen as usual in other WGs (and
there are currently several other WGs working on IPsec extensions; for
example, BTNS and ROHC), or as individual submissions.

This charter will expire in June 2010 (24 months from approval).  If
the charter is not updated before that time, the WG will be closed and
any remaining documents revert back to individual Internet-Drafts.

Goals and Milestones:

Dec 2008  WG last call on IPv6 configuration payloads
Dec 2008  WG last call on IPsec roadmap
Mar 2009  WG last call on IKEv2bis
Jan 2009  WG last call on session resumption
Feb 2009  WG last call on redirect

================

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

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

Scanned by Check Point Total Security Gateway.
--------------060508050003000808060204-- --===============0253671824== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============0253671824==-- From ipsec-bounces@ietf.org Fri Jun 6 00:28:29 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E48093A6ADC; Fri, 6 Jun 2008 00:28:29 -0700 (PDT) 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 E9A583A6AF9 for ; Fri, 6 Jun 2008 00:28:28 -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 15Y19RJwV8qp for ; Fri, 6 Jun 2008 00:28:28 -0700 (PDT) Received: from mail.kivinen.iki.fi (unknown [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id A97133A6ADC for ; Fri, 6 Jun 2008 00:28:27 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.13.8/8.13.8) with ESMTP id m567SXeT011529 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 6 Jun 2008 10:28:33 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.8/8.12.11) id m567SVsl012217; Fri, 6 Jun 2008 10:28:31 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18504.59167.826685.44808@fireball.kivinen.iki.fi> Date: Fri, 6 Jun 2008 10:28:31 +0300 From: Tero Kivinen To: In-Reply-To: <1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com> References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 6 min Cc: ipsec@ietf.org, ken.grewal@intel.com Subject: Re: [IPsec] First charter draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Pasi.Eronen@nokia.com writes: > If we decide to take more than five items, "GRE key traffic selector" > and "ESP NULL traffic visibility" would be the ones with most support. I think both of these need more discussion before they should be accepted as charter items, and I am not sure we should be doing that now, as it might delay the creation of the WG. I think we can start discussing whether those should be added as working item after we get at least one of the original items out from the WG. The GRE key traffic selector itself is not that hard thing, but there is all kind of other things related to it. When we added the protocol selectors on the IPsec architecture we didn't really realize that there is problems with fragments, and I think the gre key field has same problem, thus it might require stateful fragment checking and so on. Also I am not sure why different gre key values needs to be put on the separate SA. I have not really seen good reason why this is needed. For the ESP NULL traffic visibility there is the problem that firewalls cannot really trust the bit saying "I am nice, I am authenticated only packet, there is no need to block me", meaning the firewalls needs to inspect the packet inside the ESP packet anyways, so I am not sure if that is right way to do that thing either. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 6 00:39:08 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E732E3A6AB4; Fri, 6 Jun 2008 00:39:08 -0700 (PDT) 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 661C93A6AF8 for ; Fri, 6 Jun 2008 00:39:08 -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 HyNR8-H1Zoj5 for ; Fri, 6 Jun 2008 00:39:07 -0700 (PDT) Received: from netasq.netasq.com (netasq.netasq.com [213.30.137.178]) by core3.amsl.com (Postfix) with ESMTP id 067733A6AB4 for ; Fri, 6 Jun 2008 00:39:06 -0700 (PDT) Received: from darkstar.netasq.com (unknown [10.0.0.126]) by netasq.netasq.com (Postfix) with ESMTP id CDB642474D; Fri, 6 Jun 2008 09:39:13 +0200 (CEST) Received: by darkstar.netasq.com (Postfix, from userid 1001) id A1D13F7473; Fri, 6 Jun 2008 09:39:13 +0200 (CEST) Date: Fri, 6 Jun 2008 09:39:13 +0200 From: VANHULLEBUS Yvan To: mix Message-ID: <20080606073913.GA8777@darkstar.netasq.com> References: <48478D2B.6060309@cipherium.com.tw> MIME-Version: 1.0 In-Reply-To: <48478D2B.6060309@cipherium.com.tw> User-Agent: All mail clients suck. This one just sucks less. Cc: ipsec@ietf.org Subject: Re: [IPsec] ipsec rekey issue 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: , Content-Type: multipart/mixed; boundary="===============0678958677==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0678958677== Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="ReaqsoxgOBHFXBhH" Content-Disposition: inline --ReaqsoxgOBHFXBhH Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jun 05, 2008 at 02:52:27PM +0800, mix wrote: > Hi all, Hi. > I have a rekey problem reference from > http://www.kame.net/racoon/racoon-ml/msg00874.html > I use 2.6.21.7 kernel with ipsec-tools 0.6.5 as the server, and Windows > XP as the client. >=20 > Setup a road warrior mode >=20 > Windows XP <---------------> VPN server <-----------> Internet > VPN Tunnel >=20 > The problem is when the tunnel is built, Windows XP try to download a > big file about 200MB. > When download progress reached about 120~130MB, Windows XP can not > access internet anymore. > After about 5 minutes, the tunnel seems work, Windows can access > internet again. > Any advice will be appreciated If your problem occurs when you try to download a big file, you should better have a look at your client's MTU / TCPMSS. If your problems occurs every 80% of IPSec-SA's lifetime, you're probably experiencing a problem similar to the one explained in the link you provided, which have been fixed in most recents kernels (I don't know exactly in which version). You may also consider posting to ipsec-tools-users mailing list, which is probably more appropriate for such request. Yvan. --=20 NETASQ http://www.netasq.com --ReaqsoxgOBHFXBhH Content-Type: application/x-pkcs7-signature Content-Disposition: attachment; filename="smime.p7s" Content-Transfer-Encoding: base64 MIINOgYJKoZIhvcNAQcCoIINKzCCDScCAQExCzAJBgUrDgMCGgUAMAsGCSqGSIb3DQEHAaCC CoYwggZ8MIIFZKADAgECAgpwxrFIFmvykGpdMA0GCSqGSIb3DQEBBAUAMIGRMQswCQYDVQQG EwJGUjENMAsGA1UECBMETm9yZDEaMBgGA1UEBxMRVmlsbGVuZXV2ZSBkJ0FzY3ExLjAsBgNV BAoTJU5FVEFTUSAtIFNlY3VyZSBJbnRlcm5ldCBDb25uZWN0aXZpdHkxJzAlBgNVBAsTHk5F VEFTUSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAeFw0wNzA3MTYwOTU4MDhaFw0wOTA3MTUw OTU4MDhaMIHYMQswCQYDVQQGFAJGUjENMAsGA1UECBQETm9yZDEuMCwGA1UEChQlTkVUQVNR IC0gU2VjdXJlIEludGVybmV0IENvbm5lY3Rpdml0eTEnMCUGA1UECxQeTkVUQVNRIENlcnRp ZmljYXRpb24gQXV0aG9yaXR5MRowGAYDVQQHFBFWaWxsZW5ldXZlIGQnQXNjcTEZMBcGA1UE AxQQeXZhbiBWQU5IVUxMRUJVUzEqMCgGCSqGSIb3DQEJARYbeXZhbi52YW5odWxsZWJ1c0Bu ZXRhc3EuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEArqZ+vhct7xUvoDOL yI6I/WS8H1qx5M31ECuEzMpO7dNEAeEnjQ0SsmgqJi0IUvlsnHQaOuMhzLMACThad5Z9cA2B tg7d9qk9cOU40BNL3L14qROaoowCKqPG9uNMtCaQM3p5iMnIbud4Z+gvoezjlOSVzLH6Brcp HC1iKAfPb2JI0xqWlvVRT+nOhdG+hEtPSKeGQaniSCcUFRsdyKB20qZVNCXNXskOiJoAohp6 mPopsAEnuitFE+u8ps9Pdly8N+BLMIKGzO5aEg0vxUX2UMN0kBBrLopmIj1ed+NOZKEshiKS 20Bqz24725Uh0Fn/9PftjFiBY6hFiJKU4CQ2QwIDAQABo4ICizCCAocwDAYDVR0TAQH/BAIw ADAdBgNVHQ4EFgQUq8DCXoQV2AIeiRLvzDPubbew5Dgwgb4GA1UdIwSBtjCBs4AUJyrrHdlE 2joXc2oJICDJJaj5f7KhgZekgZQwgZExCzAJBgNVBAYTAkZSMQ0wCwYDVQQIEwROb3JkMRow GAYDVQQHExFWaWxsZW5ldXZlIGQnQXNjcTEuMCwGA1UEChMlTkVUQVNRIC0gU2VjdXJlIElu dGVybmV0IENvbm5lY3Rpdml0eTEnMCUGA1UECxMeTkVUQVNRIENlcnRpZmljYXRpb24gQXV0 aG9yaXR5ggEAMA4GA1UdDwEB/wQEAwIF4DARBglghkgBhvhCAQEEBAMCBaAwKwYJKwYBBAGC NxQCBB4eHABTAG0AYQByAHQAYwBhAHIAZABMAG8AZwBvAG4wKQYDVR0lBCIwIAYIKwYBBQUH AwQGCCsGAQUFBwMCBgorBgEEAYI3FAICMCsGA1UdEQQkMCKgIAYKKwYBBAGCNxQCA6ASDBB5 dmFudkBuZXRhc3EuY29tMIHNBgNVHR8EgcUwgcIwWqBYoFaGVGxkYXA6Ly9wa2kubmV0YXNx LmNvbS9jbj1md2NhLG91PWNhcyxvPW5ldGFzcSxkYz1mcj9jZXJ0aWZpY2F0ZVJldm9jYXRp b25MaXN0O2JpbmFyeTA4oDagNIYyaHR0cDovL2ludHJhbmV0Lm5ldGFzcS5jb20vaW50cmFu ZXQvcGtpL25ldGFzcS5jcmwwKqAooCaGJGh0dHA6Ly93d3cubmV0YXNxLmNvbS9wa2kvbmV0 YXNxLmNybDAfBglghkgBhvhCAQ0EEhYQVXNlciBDZXJ0aWZpY2F0ZTANBgkqhkiG9w0BAQQF AAOCAQEAUiSvrad7pGSGQblLF8U9SwjSelyRYicqihVnWKHoHZ3kRYI6QoVRcZlStDegZ+yU CLOoRGF+KCMnZzP7YfxqucdB06i/deP26R7YHK/4vjOSvIyfT2Z/wspPQqYCkqq3BwcbJ4Fz 3KK1mqkxcevTuLSugcaaYC6csbxfVa12UN47+3Cd37ViHU2L1z1GunY5dzCW1CaZEqJ5YvD4 x0ylsCDuxifp7uEw1bc1fXMC3XPO1Nlf6SAVcqn4u+jNL812jwndPg6C6WdUXDwAV6KHzxCA dVH+6AoV5tU2TScdXGCk8/AzwxVKCo9SdwvQut57ko20FFx5xFRJV7F49k/EWjCCBAIwggLq oAMCAQICAQAwDQYJKoZIhvcNAQEEBQAwgZExCzAJBgNVBAYTAkZSMQ0wCwYDVQQIEwROb3Jk MRowGAYDVQQHExFWaWxsZW5ldXZlIGQnQXNjcTEuMCwGA1UEChMlTkVUQVNRIC0gU2VjdXJl IEludGVybmV0IENvbm5lY3Rpdml0eTEnMCUGA1UECxMeTkVUQVNRIENlcnRpZmljYXRpb24g QXV0aG9yaXR5MB4XDTAyMDIxOTEyMzQ1NVoXDTIyMDIxNDEyMzQ1NVowgZExCzAJBgNVBAYT AkZSMQ0wCwYDVQQIEwROb3JkMRowGAYDVQQHExFWaWxsZW5ldXZlIGQnQXNjcTEuMCwGA1UE ChMlTkVUQVNRIC0gU2VjdXJlIEludGVybmV0IENvbm5lY3Rpdml0eTEnMCUGA1UECxMeTkVU QVNRIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIB CgKCAQEAwYBPi3ref6t0tuJMoj5R4H7sa+WMSZwDh4XHjZV5e6P6LObyrleC6oNFDZJrgBtK k9Swzfnnf4m3xc0QS9kKCPLFwLpmIK3RCx0K4YYi+uBrrL347kH4UPfrI6KvrYcFpG3YwFZU K+7LZn/Y9HSB6n4gvdiCk7cmkuFr1ifFtDYZqktNUss9yQCPqh0d9dXfuhRV8vyggvVkcfTZ cCyVpRaDYaDm0j30Urba62KsKxfh6cEAt6kmPUxviGVaoEiiaABDZVSu6PjS17qDcZaQzlnw hLacKyM1zR7+lvfFR03/h6m8JYGBPMP7zccH2uJfufh+Of3AvOfCFZFcNhzHCwIDAQABo2Mw YTAdBgNVHQ4EFgQUJyrrHdlE2joXc2oJICDJJaj5f7IwHwYDVR0jBBgwFoAUJyrrHdlE2joX c2oJICDJJaj5f7IwDwYDVR0TAQH/BAUwAwEB/zAOBgNVHQ8BAf8EBAMCAQYwDQYJKoZIhvcN AQEEBQADggEBAJclqFN/WqYmhcZlXabrw6KJQNq/TK6TLDHzwZVcyjn0QhujHRr+EcVpaE1p IS4fjsywzpINE3fe9DSlC4IzyeqDq3EtM4eQDSXm4YRGLZp8X2M5TdccmxlElDgZzlVXMOlo /Ehhh4vqzSbc1M4FEfETiEV+vLX5MaWEHH8dmzlEL632mOme19QJN6BQKJPmCCj1VbxJDrJS pF01kXFJUtyrA0ilrEG0mA+FLFjfsWuZXzYEPjv1/FIPMlSnCCiW8ZSzwstQX2BhLEi0ugZJ RpakVMY/TkdoLEErYt0mjZD+d/oXFR7QNzMxAHpDEPmlZRotP1W7sO6kpBP7lyh/Yc4xggJ8 MIICeAIBATCBoDCBkTELMAkGA1UEBhMCRlIxDTALBgNVBAgTBE5vcmQxGjAYBgNVBAcTEVZp bGxlbmV1dmUgZCdBc2NxMS4wLAYDVQQKEyVORVRBU1EgLSBTZWN1cmUgSW50ZXJuZXQgQ29u bmVjdGl2aXR5MScwJQYDVQQLEx5ORVRBU1EgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkCCnDG sUgWa/KQal0wCQYFKw4DAhoFAKCBsTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0wODA2MDYwNzM5MTNaMCMGCSqGSIb3DQEJBDEWBBRZOCBjSf9LrY3aZKMv qdh8Y/NaPDBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAN BggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDANBgkqhkiG9w0BAQEFAASC AQAiewl+/8OEb7uGsAsE5oV6ycdGRdEQWVY93y1qB79frWDm5rnH0G8gl9SF7MWhK7F5CRK8 VUcwlSY5BaC6Zrhy6uuLir4f7B89r3NEeXDbt0LVxkCwUcxE3bZa2mVIz+m2qd2pnfHm7rvp OH4KkB2B79AZ364IRHiRpbUwefrJBTkodBNs3gI/QKjo37napD5NsmqQCxdr00SH5u7c/GHp JxEMASi4uhCf3mZ3nuwi5zOJWhXK84zpe3Fktaar/+Sj4N7HQai/IxtaQ6rmzWWbeDtHRwIx bU7MEa3r5WQPQ4jWq/ElX9sm0yUhsSG9m8EWjCg/QMmWbCtsfDoo4aWy --ReaqsoxgOBHFXBhH-- --===============0678958677== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============0678958677==-- From ipsec-bounces@ietf.org Fri Jun 6 03:37:07 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 948213A6B0E; Fri, 6 Jun 2008 03:37:07 -0700 (PDT) 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 978E93A6B0E for ; Fri, 6 Jun 2008 03:37:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ZDIBabcyUE7y for ; Fri, 6 Jun 2008 03:37:05 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 60BE23A6A8D for ; Fri, 6 Jun 2008 03:37:05 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m56AanrB011125; Fri, 6 Jun 2008 13:37:12 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Jun 2008 13:36:58 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Jun 2008 13:36:57 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 6 Jun 2008 13:36:57 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72D54D1F@vaebe104.NOE.Nokia.com> In-Reply-To: <18504.59167.826685.44808@fireball.kivinen.iki.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] First charter draft Thread-Index: AcjHpvaT8wN13Z0lS3CpdDXacBUnzwAGY2sw References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com><1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com> <18504.59167.826685.44808@fireball.kivinen.iki.fi> From: To: X-OriginalArrivalTime: 06 Jun 2008 10:36:57.0814 (UTC) FILETIME=[3EE91F60:01C8C7C1] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] First charter draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Tero Kivinen wrote: > I think both of these need more discussion before they should be > accepted as charter items, and I am not sure we should be doing that > now, as it might delay the creation of the WG. I think we can start > discussing whether those should be added as working item after we > get at least one of the original items out from the WG. That is possible. On the other hand, the current charter is very much skewed towards "remote access VPN" use of IPsec... > The GRE key traffic selector itself is not that hard thing, but there > is all kind of other things related to it. When we added the protocol > selectors on the IPsec architecture we didn't really realize that > there is problems with fragments, and I think the gre key field has > same problem, thus it might require stateful fragment checking and > so on. To me, it seems GRE key would not be significantly different from other selectors (ICMP type/code, TCP port, etc.) -- you need to consider fragments, yes, but probably don't need to do anything significantly different from what was done for other protocols. > Also I am not sure why different gre key values needs to be put on > the separate SA. I have not really seen good reason why this is > needed. Apparently, other folks have scenarios where they'd like to do this. > For the ESP NULL traffic visibility there is the problem that > firewalls cannot really trust the bit saying "I am nice, I am > authenticated only packet, there is no need to block me", meaning > the firewalls needs to inspect the packet inside the ESP packet > anyways, so I am not sure if that is right way to do that thing > either. I think one main motivation here was to help inspecting the packet, by telling where exactly the payload is (e.g. how long the IV and ICV are). So no, you can't really trust the "evil bit" -- you do packet inspection as you'd do for non-IPsec packets. Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 6 09:15:32 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6D883A6A2C; Fri, 6 Jun 2008 09:15:32 -0700 (PDT) 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 43FE43A6A2C for ; Fri, 6 Jun 2008 09:15:31 -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 ZqBa8XDNzcEV for ; Fri, 6 Jun 2008 09:15:30 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 1F1C03A6A0C for ; Fri, 6 Jun 2008 09:15:30 -0700 (PDT) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1K4ebL-0004HN-3q; Fri, 06 Jun 2008 12:15:39 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com> References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com> Date: Fri, 6 Jun 2008 12:10:30 -0400 To: From: Stephen Kent Cc: ipsec@ietf.org Subject: Re: [IPsec] First charter draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Pasi, The I-D draft-grewal-ipsec-traffic-visibility has a number of presentation problems. The text refers to IVs and ICVs, without noting that only for combined mode algorithms would an IV be used in the context of null-encryption. Moreover, combined mode algorithm support was introduced only in ESPv2 (RFC 4303), but the I-D cites only ESP v1 (RFC 2406). Similarly, the text cites 2301, not 4301. In 2301, AH support is mandated, and so one could argue that in an enterprise context where intermediate systems need to examine packet contents, the enterprise could just mandate use of AH. In 4301, support for AH is no longer mandated, and so the encapsulation mechanism proposed in this I-D makes more sense. Thus I think that 4301 is the appropriate cite here. Also, IKEv2 is cited, and it is used only in the 4301 context, so ... The I-D doesn't explain how an intermediate system will determine the end of the real payload, to enable it to "further parse the packet to extract the data portion." That system needs to know the pad length. True, this can be determined by working back from the ICV length and the next header field, but the text fails to mention that. Moreover, if you have to do that processing, you could grab the next header field then, and not have it in the UDP encapsulation header. Finally, the explanation how to validate a UDP-encapsulated ESP-NULL packet, in the face of possible port conflicts appears to be underspecified. One can argue that if there is a viable heuristic to deal with this case, an intermediate system could perform these checks on ESP traffic, cache the SA info (by S/D host addresses and SPI values) and avoid the need for the encapsulation proposed here! This seems especially true given that the scope of this I-D appears to be traffic within an enterprise net, not the more general case of any intermediate system along a path, perhaps at the boundary between an enterprise net and the public internet. In contrast, the draft-hoffman-esp-null-protocol I-D is very simple and does not impose the burden of an extra encapsulation layer. However it consumes two protocol numbers from a space that has traditionally been consider relatively scarce. Also, these two numbers might not suffice if additional combined mode algorithms, with different IV lengths, are adopted in the future. This I-D needs more details discussing exactly how an intermediate system will perform the necessary packet inspection. Finally, because this I-D tries to address the more general case of an intermediate system along a path (anywhere?), it require more discussion of what set of policies make sense in the more general context. (I think this is needed to that folks don't jump to inaccurate conclusions about what such a facility will buy them.) So, like Tero, I am not convinced that this topic should be a high priority for the new IPsec WG. I have not yet looked at the GRE proposal, but I do not that defining additional selector values may pose problems for folks who have designed hardware that relies on the fact that the set of selectors has remained fairly static for many years. Also, I agree with Tero that we need to understand very thoroughly why there is a need to use additional data as traffic selectors, so that we don't set a precedent that will haunt us in the future. If we create a number of application-specific variants of IPsec for different contexts, we run the risk of undermining interoperability. Steve _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 6 14:11:51 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BBAA728C1C4; Fri, 6 Jun 2008 14:11:51 -0700 (PDT) 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 29C843A6C8B for ; Fri, 6 Jun 2008 14:11:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.598 X-Spam-Level: X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 YOkUuAIuANZQ for ; Fri, 6 Jun 2008 14:11:47 -0700 (PDT) Received: from DE08IP008.honeywell.com (de08ip008.honeywell.com [199.61.24.27]) by core3.amsl.com (Postfix) with ESMTP id 4F6E63A6AFB for ; Fri, 6 Jun 2008 14:11:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,602,1204527600"; d="scan'208,217";a="4001969" Received: from unknown (HELO DE08CN850.global.ds.honeywell.com) ([10.216.13.39]) by DE08IP008.honeywell.com with ESMTP; 06 Jun 2008 14:05:59 -0700 Received: from DE08EV803.global.ds.honeywell.com ([10.216.13.27]) by DE08CN850.global.ds.honeywell.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 6 Jun 2008 17:11:54 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 6 Jun 2008 17:11:06 -0400 Message-ID: <21B723FB5CC281419BEA1CF988966ED9E9BB36@DE08EV803.global.ds.honeywell.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: question about RFC 4303 section 3.3.2.1 Thread-Index: AcjIGdXzaSB5q5IRTJasafK4QouaOQ== From: "Green, Mike" To: X-OriginalArrivalTime: 06 Jun 2008 21:11:54.0957 (UTC) FILETIME=[F293CFD0:01C8C819] Subject: [IPsec] question about RFC 4303 section 3.3.2.1 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: , Content-Type: multipart/mixed; boundary="===============0404030879==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0404030879== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8C819.D79D32A9" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8C819.D79D32A9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sorry if this is the wrong forum: =20 Are the steps outlined in this section a MUST from an order of operations standpoint? In other words, if you're encrypted the packet using a non-chaining algorithm, is it possible to construct an ESP IPsec packet by encrypting the payload before the header? Is possible even using a chaining cipher algorithm to do that? Thanks. =20 Mike Green ph 602.822.4360 mike.a.green@honeywell.com =20 =20 ------_=_NextPart_001_01C8C819.D79D32A9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Sorry if this is the wrong = forum:

 

Are the steps outlined in this section a MUST from an = order of operations standpoint? In other words, if you’re encrypted the = packet using a non-chaining algorithm, is it possible to construct an ESP IPsec = packet by encrypting the payload before the header? Is possible even using a = chaining cipher algorithm to do that?  Thanks.

 

Mike = Green

ph = 602.822.4360

mike.a.green@honeywell.com

 

------_=_NextPart_001_01C8C819.D79D32A9-- --===============0404030879== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============0404030879==-- From ipsec-bounces@ietf.org Fri Jun 6 14:37:47 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1D2C3A6BEE; Fri, 6 Jun 2008 14:37:47 -0700 (PDT) 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 695333A6BEE for ; Fri, 6 Jun 2008 14:37:46 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Yydv5E9Tjc7r for ; Fri, 6 Jun 2008 14:37:45 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 842DB3A6B8F for ; Fri, 6 Jun 2008 14:37:45 -0700 (PDT) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1K4jdB-0003sj-4f; Fri, 06 Jun 2008 17:37:53 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <21B723FB5CC281419BEA1CF988966ED9E9BB36@DE08EV803.global.ds.honeywell.com> References: <21B723FB5CC281419BEA1CF988966ED9E9BB36@DE08EV803.global.ds.honeywell.com> Date: Fri, 6 Jun 2008 17:27:54 -0400 To: "Green, Mike" From: Stephen Kent Cc: ipsec@ietf.org Subject: Re: [IPsec] question about RFC 4303 section 3.3.2.1 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: , Content-Type: multipart/mixed; boundary="===============2081945675==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============2081945675== Content-Type: multipart/alternative; boundary="============_-999334212==_ma============" --============_-999334212==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 5:11 PM -0400 6/6/08, Green, Mike wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/alternative; > boundary="----_=_NextPart_001_01C8C819.D79D32A9" > >Sorry if this is the wrong forum: > >Are the steps outlined in this section a MUST from an order of >operations standpoint? In other words, if you're encrypted the >packet using a non-chaining algorithm, is it possible to construct >an ESP IPsec packet by encrypting the payload before the header? Is >possible even using a chaining cipher algorithm to do that? Thanks. One MUST perform encryption before the integrity check is applied, because the received will verify the integrity check before performing decryption. If one can perform the two in parallel, that's OK, so long as the receiver can perform the integrity check first. But, yes you could construct the ESP header after encrypting the payload (and the ESP trailer), so long as the ESP header is constructed before the integrity check is computed. Steve --============_-999334212==_ma============ Content-Type: text/html; charset="us-ascii" Re: [IPsec] question about RFC 4303 section 3.3.2.1
At 5:11 PM -0400 6/6/08, Green, Mike wrote:
Content-class: urn:content-classes:message
Content-Type: multipart/alternative;
  boundary="----_=_NextPart_001_01C8C819.D79D32A9"
Sorry if this is the wrong forum:
 
Are the steps outlined in this section a MUST from an order of operations standpoint? In other words, if you're encrypted the packet using a non-chaining algorithm, is it possible to construct an ESP IPsec packet by encrypting the payload before the header? Is possible even using a chaining cipher algorithm to do that?  Thanks.
 

One MUST perform encryption before the integrity check is applied, because the received will verify the integrity check before performing decryption. If one can perform the two in parallel, that's OK, so long as the receiver can perform the integrity check first. But, yes you could construct the ESP header after encrypting the payload (and the ESP trailer), so long as the ESP header is constructed before the integrity check is computed.

Steve
--============_-999334212==_ma============-- --===============2081945675== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============2081945675==-- From ipsec-bounces@ietf.org Fri Jun 6 15:20:44 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 25C043A6C09; Fri, 6 Jun 2008 15:20:44 -0700 (PDT) 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 805743A6BF6 for ; Fri, 6 Jun 2008 15:20:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Ra1xlGdrVGIj for ; Fri, 6 Jun 2008 15:20:39 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by core3.amsl.com (Postfix) with ESMTP id ECA933A6967 for ; Fri, 6 Jun 2008 15:20:38 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 06 Jun 2008 15:18:27 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.27,602,1204531200"; d="scan'208";a="391597028" Received: from fmsmsx334.amr.corp.intel.com ([132.233.42.1]) by orsmga001.jf.intel.com with ESMTP; 06 Jun 2008 15:20:39 -0700 Received: from fmsmsx881.amr.corp.intel.com ([10.19.19.13]) by fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jun 2008 15:20:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 6 Jun 2008 15:20:41 -0700 Message-ID: In-Reply-To: <18504.59167.826685.44808@fireball.kivinen.iki.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] First charter draft Thread-Index: AcjHpvJVyfruKq93S2SBhfwCJ6DKbwAbRzgw References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com><1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com> <18504.59167.826685.44808@fireball.kivinen.iki.fi> From: "Grewal, Ken" To: "Tero Kivinen" , X-OriginalArrivalTime: 06 Jun 2008 22:20:48.0657 (UTC) FILETIME=[92746010:01C8C823] Cc: ipsec@ietf.org Subject: Re: [IPsec] First charter draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Tero, Some comments below... Thanks, - Ken -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi] Sent: Friday, June 06, 2008 12:29 AM To: Pasi.Eronen@nokia.com Cc: Grewal, Ken; ipsec@ietf.org Subject: Re: [IPsec] First charter draft --- snip --- For the ESP NULL traffic visibility there is the problem that firewalls cannot really trust the bit saying "I am nice, I am authenticated only packet, there is no need to block me", meaning the firewalls needs to inspect the packet inside the ESP packet anyways, so I am not sure if that is right way to do that thing either. [Ken] I agree that one cannot just trust the bit, but it can provide the firewall (or IDS/IPS system) with enough knowledge to determine if it can successfully scan the payload inside the packet. This can allow for a more informed policy decision in certain environments. E.g. My enterprise policy is that all data within the enterprise is owned by the Enterprise, hence should be scanned by the some network service (IDS/IPS). For the enterprise, I would also like data integrity/authenticity to mitigate any threats for data modification / injection. Based on this policy, the enterprise can choose to disallow any encrypted communication in the enterprise, while allowing authenticated traffic, without encryption. The proposed extensions would allow an Enterprise to have the flexibility of providing and enforcing such a granular policy, which it could not easily do today. AH is a non-starter due to NAT and ESP needs some extensions to allow this. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 6 15:21:00 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0DFC28C231; Fri, 6 Jun 2008 15:20:59 -0700 (PDT) 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 B1F5A28C1BA for ; Fri, 6 Jun 2008 15:20:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 EnzdJW07mPbj for ; Fri, 6 Jun 2008 15:20:40 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by core3.amsl.com (Postfix) with ESMTP id 21A613A6BE5 for ; Fri, 6 Jun 2008 15:20:39 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 06 Jun 2008 15:18:27 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.27,602,1204531200"; d="scan'208,217";a="391597024" Received: from fmsmsx334.amr.corp.intel.com ([132.233.42.1]) by orsmga001.jf.intel.com with ESMTP; 06 Jun 2008 15:20:39 -0700 Received: from fmsmsx881.amr.corp.intel.com ([10.19.19.13]) by fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jun 2008 15:20:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 6 Jun 2008 15:20:09 -0700 Message-ID: In-Reply-To: <4848D0E7.4030306@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] First charter draft Thread-Index: AcjHmbfnfnzuxm8WQfSl0mN0na7NEAAeIRIA References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com> <4848D0E7.4030306@checkpoint.com> From: "Grewal, Ken" To: "Yaron Sheffer" , X-OriginalArrivalTime: 06 Jun 2008 22:20:48.0438 (UTC) FILETIME=[9252F560:01C8C823] Cc: ipsec@ietf.org Subject: Re: [IPsec] First charter draft 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: , Content-Type: multipart/mixed; boundary="===============0976854651==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0976854651== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8C823.7B907952" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8C823.7B907952 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Yaron,=20 I was not involved in the discussion on this topic last September and have not reviewed those threads sufficiently to provide comments.=20 The main purpose of this proposal is to differentiate between encrypted and non-encrypted data in environments that care about further inspection of the payloads (e.g. Enterprises) and we cannot do this today with the existing ESP packet format definitions. Furthermore, optimization hints can be provided allowing the intermediate devices to easily extract and parse the payloads, when the data is not encrypted.=20 The IVs lengths could be the same - e.g. You could run a combined mode algorithm such as AES-GCM used for encryption/integrity of the data and GMAC for just integrity and they both have the same IV lengths, but the intermediate device is unable to deterministically differentiate between packets that are encrypted Vs. integrity only.=20 =20 I totally agree that you still need stateful inspection, but this is a decision prior to inspecting the packet - i.e. Can the firewall do meaningful stateful inspection or is the data encrypted? =20 Thanks,=20 - Ken =20 ________________________________ From: Yaron Sheffer [mailto:yaronf@checkpoint.com]=20 Sent: Thursday, June 05, 2008 10:54 PM To: Pasi.Eronen@nokia.com Cc: Grewal, Ken; ipsec@ietf.org Subject: Re: [IPsec] First charter draft =20 Hi Pasi, looking back at the mailing list around Sep. 2007, most of the ESP-NULL discussion was around the implementation issues (1 vs. 2 protocol numbers etc.). Only a few people commented on the utility of this solution. And I find Tero's arguments rather convincing: you need to implement stateful protocol inspection anyway, and the new marking buys you very little. I believe the ONLY thing you gain is deterministic parsing of ESP packets in deployments where different ESP packets contain IV values of different lengths. I doubt that this is a good enough justification. Thanks, Yaron Pasi.Eronen@nokia.com wrote:=20 I do agree that the current extensions (session resumption and redirect) are mostly targeted to "remote access VPN" use, and=20 having a broader base could be useful. =20 However, we also need to prioritize -- not everything that is=20 useful can be in the *first* charter -- and make sure every work=20 item has sufficient interest (so it actually gets used) and people=20 willing to work on it (so it gets done). =20 If we decide to take more than five items, "GRE key traffic selector" and "ESP NULL traffic visibility" would be the ones with most support. =20 Both also look reasonably simple technically (the actual technical details an implementor would need are probably less than five pages each -- with additional text explaining the motivation, security considerations, etc.), so this could be feasible. =20 However, I'd like to get some more opinions about these work items, especially from people who participated in the discussions about "ESP NULL traffic visibility" earlier. =20 Here's a short summary about these proposed work items: =20 o A standards-track extension to IKEv2 to support using the "Key"=20 field of Generic Routing Encapsulation (GRE) packets, specified=20 in RFC 2890, as a traffic selector (in similar fashion as TCP/UDP=20 port number or ICMP type/code fields). This allows different GRE=20 traffic flows to be mapped to different IPsec SAs. Any further=20 extensions related to the use of IPsec with GRE are beyond the=20 scope of this work item. =20 o A standards-track mechanism that allows an intermediary device, such as a firewall or intrusion detection system, to easily and reliably determine whether an ESP packet is encrypted with the=20 NULL cipher; and if it is, determine the location of the actual=20 payload data inside the packet. The starting points for this work=20 item are draft-grewal-ipsec-traffic-visibility and draft-hoffman- esp-null-protocol. =20 Best regards, Pasi=20 =20 =20 -----Original Message----- From: ext Grewal, Ken [mailto:ken.grewal@intel.com]=20 Sent: 04 June, 2008 20:42 To: Eronen Pasi (Nokia-NRC/Helsinki); ipsec@ietf.org =20 Subject: RE: [IPsec] First charter draft =20 Hi Pasi, All,=20 Although I agree with pursuing these items, I would like the group to also consider extensions for IPsec traffic visibility. There are two drafts that are proposing some of these extensions and I am=20 working with some colleagues on submitting an update to one of these shortly. These are: =20 http://www.ietf.org/internet-drafts/draft-hoffman-esp-null-pro =20 tocol-00.t =20 xt. =20 and =20 http://www.ietf.org/internet-drafts/draft-grewal-ipsec-traffic =20 =20 -visibilit =20 y-00.txt =20 In your draft charter, there are two items related to IPsec VPNs. Although VPN is the predominant use of IPsec today for remote access / site-to-site, I believe one of the reasons that IPsec=20 end-to-end is not widely employed today is due to the lack of traffic visibility in managed environments such as Enterprises. AH is not practical and ESP does not offer enough flexibility.=20 =20 I would like the group to consider a small modification to the charter and include text on using IPsec in real world, end-to-end solutions where practical considerations such as network management tools / intrusion detection / malware scanning tools are unable to=20 operate when the data is encrypted. Having IPsec extensions to accommodate these tools will greatly increase the viability of using IPsec=20 beyond just VPN and remote access. =20 I will be happy to present some of these findings / ideas at the next IETF. =20 Thanks for your consideration...=20 =20 Thanks,=20 - Ken =20 =20 -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Pasi.Eronen@nokia.com Sent: Sunday, June 01, 2008 11:13 AM To: ipsec@ietf.org Subject: [IPsec] First charter draft =20 Thanks to everyone who replied to the poll! =20 Based on the responses, I've put together a first draft=20 of charter text, which has IMHO quite reasonable balance=20 between maintenance (ikev2bis, roadmap, ipv6) and the=20 extensions with widest interest (session resumption and redirect). =20 I also tried to come up with some text describing the=20 work items, to make it clear what's in scope and what is not. (Comments on that text are welcome!) =20 This list doesn't include draft-black-ipsec-ikev2-aead-modes, since it's basically read to be published now, and might be out before the WG gets created. =20 Please send comments (either privately or on the list)=20 as soon as possible -- to have the first WG meeting in Dublin, we need to converge on charter text soon (since there are several process steps it needs to go through before the WG is officially approved). =20 Best regards, Pasi =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 IP Security Maintenance and Extensions (ipsecme) DRAFT 2008-06-01 =20 Chair(s): TBD =20 Security Area Director(s): TBD =20 Mailing Lists: =20 General Discussion: ipsec@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec Archive: http://www.ietf.org/mail-archive/web/ipsec/ =20 =20 Description of Working Group: =20 The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated RFCs), IKEv2 (RFC 4106, RFC 4718, and associated RFCs), and the IPsec security architecture (RFC 4301). IPsec is widely deployed in VPN gateways, VPN remote access clients, and as a substrate for host-to-host, host-to-network, and network-to-network security. =20 The IPsec Maintenance and Extensions Working Group will continue the work of the earlier IPsec Working Group which was concluded in 2005. Its purpose is to maintain the IPsec standard and to facilitate discussion of clarifications, improvements, and extensions and improvements to IPsec, mostly to IKEv2. The working group will also=20 be a focus point for other IETF Working Groups who use IPsec in their=20 own protocols. =20 The initial set of work items is: =20 o A revision to IKEv2 (RFC 4306) that incorporates the clarifications from RFC 4718, and otherwise improves the quality of the specification, taking into account implementation and interoperability experience. In some cases, the revision may include small technical corrections; however, impact on existing implementations must be considered. Major changes and adding new features is beyond the scope of this work item. The starting point for this work is draft-hoffman-ikev2bis.=20 =20 o An IPsec document roadmap that describes the various RFC=20 documents covering IPsec, including both the core RFC 240x=20 and RFC 430x versions of IPsec, and extensions specified in=20 other documents. Sections 2 and 3 of RFC 2411 can provide =20 useful material, but the expected scope is slightly different from RFC 2411. This document will be informational. =20 o A standards-track extension to IKEv2 that provides full IPv6 support for IPsec remote access clients that use configuration payloads. This work will be based on draft-eronen-ipsec-ikev2-ipv6-config. =20 o A standards-track extension that allows an IPsec remote access client to "resume" a session with a gateway; that is, to skip certain parts of IKE negotation when connecting again to the=20 same gateway (or possibly a cluster of closely cooperating=20 gateways). =20 The idea is similar to TLS session resumption without server-side state, specified in RFC 5077. =20 The main goals for this extension are to avoid public-key computations (to reduce VPN gateway load when a large number of clients reconnect to the geteway within a short period of time, such as following a network outage), and remove the need for user interaction for authentication (which may be required by some authentication mechanisms). The extension shall not have negative impact on IKEv2 security features. =20 Failover from one gateway to another, mechanisms for detecting when a session should be resumed, and specifying communication mechanisms between gateways are beyond the scope of this work item. Specifying the detailed contents of the "session ticket" is also beyond the scope of this document; if there is sufficient=20 interest, this could be specified later in a separate document. =20 To the degree its content falls within the scope of this work item, text and ideas from draft-sheffer-ipsec-failover will be used as a starting point. =20 o A standards-track extension to IPsec that allows an IPsec remote access gateway to redirect VPN clients to another gateway. This extension should be aligned with the session resumption extension, (the previous work item), and if so decided by the WG, could be specified in the same document. The starting point will be draft-devarapalli-ipsec-ikev2-redirect. =20 The initial scope of the WG is restricted to the work items listed above. The WG shall not consider adding new work items until one or more of its documents progress to IESG evaluation. At that time, the WG can propose rechartering. =20 Chartering this WG is not intended to have effect on documents that beyond the initial scope. In particular, work on IPsec extensions that are not included in this charter can happen as usual in other WGs (and there are currently several other WGs working on IPsec extensions; for example, BTNS and ROHC), or as individual submissions. =20 This charter will expire in June 2010 (24 months from approval). If the charter is not updated before that time, the WG will be closed and any remaining documents revert back to individual Internet-Drafts. =20 Goals and Milestones: =20 Dec 2008 WG last call on IPv6 configuration payloads Dec 2008 WG last call on IPsec roadmap Mar 2009 WG last call on IKEv2bis Jan 2009 WG last call on session resumption Feb 2009 WG last call on redirect =20 =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =20 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 =20 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 Scanned by Check Point Total Security Gateway. =20 =20 ------_=_NextPart_001_01C8C823.7B907952 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Yaron, =

I was not involved in the = discussion on this topic last September and have not reviewed those threads = sufficiently to provide comments.

The main purpose of this proposal = is to differentiate between encrypted and non-encrypted data in environments = that care about further inspection of the payloads (e.g. Enterprises) and we = cannot do this today with the existing ESP packet format definitions. = Furthermore, optimization hints can be provided allowing the intermediate devices to = easily extract and parse the payloads, when the data is not encrypted. =

The IVs lengths could be the same = – e.g. You could run a combined mode algorithm such as AES-GCM used for encryption/integrity of the data and GMAC for just integrity and they = both have the same IV lengths, but the intermediate device is unable to = deterministically differentiate between packets that are encrypted Vs. integrity only. =

 

I totally agree that you still need stateful inspection, but this is a decision prior to inspecting the = packet – i.e. Can the firewall do meaningful stateful inspection or is = the data encrypted?

 

Thanks,

- Ken

 

From: Yaron Sheffer [mailto:yaronf@checkpoint.com]
Sent: Thursday, June 05, = 2008 10:54 PM
To: = Pasi.Eronen@nokia.com
Cc: Grewal, Ken; = ipsec@ietf.org
Subject: Re: [IPsec] = First charter draft

 

Hi Pasi,

looking back at the mailing list around Sep. 2007, most of the ESP-NULL discussion was around the implementation issues (1 vs. 2 protocol = numbers etc.). Only a few people commented on the utility of this solution. And = I find Tero's arguments rather convincing: you need to implement stateful = protocol inspection anyway, and the new marking buys you very little.

I believe the ONLY thing you gain is deterministic parsing of ESP = packets in deployments where different ESP packets contain IV values of different = lengths. I doubt that this is a good enough justification.

Thanks,
    Yaron

Pasi.Eronen@nokia.com = wrote: 

I do agree that the current extensions =
(session resumption and
redirect) are mostly targeted to "remote =
access VPN" use, and 
having a broader base could be =
useful.
 
However, we also need to prioritize -- not =
everything that is 
useful can be in the *first* charter -- and =
make sure every work 
item has sufficient interest (so it actually =
gets used) and people 
willing to work on it (so it gets =
done).
 
If we decide to take more than five items, =
"GRE key traffic =
selector"
and "ESP NULL traffic visibility" =
would be the ones with most =
support.
 
Both also look reasonably simple technically =
(the actual technical
details an implementor would need are =
probably less than five pages
each -- with additional text explaining the =
motivation, security
considerations, etc.), so this could be =
feasible.
 
However, I'd like to get some more opinions =
about these work
items, especially from people who =
participated in the discussions
about "ESP NULL traffic visibility" =
earlier.
 
Here's a short summary about these proposed =
work items:
 
o  A standards-track extension to IKEv2 =
to support using the "Key" =

   field of Generic Routing =
Encapsulation (GRE) packets, specified =

   in RFC 2890, as a traffic =
selector (in similar fashion as TCP/UDP =

   port number or ICMP =
type/code fields). This allows different GRE =

   traffic flows to be mapped =
to different IPsec SAs.  Any further =

   extensions related to the =
use of IPsec with GRE are beyond the =

   scope of this work =
item.
 
o  A standards-track mechanism that =
allows an intermediary device,
   such as a firewall or intrusion =
detection system, to easily and
   reliably determine whether an =
ESP packet is encrypted with the =

   NULL cipher; and if it is, =
determine the location of the actual =

   payload data inside the =
packet. The starting points for this work =

   item are =
draft-grewal-ipsec-traffic-visibility and =
draft-hoffman-
   =
esp-null-protocol.
 
Best =
regards,
Pasi =

 
  
-----Original =
Message-----
From: ext Grewal, Ken [mailto:ken.grewal@intel.com] =

Sent: 04 June, 2008 =
20:42
To: Eronen Pasi (Nokia-NRC/Helsinki); =
ipsec@ietf.org
Subject: RE: [IPsec] First charter =
draft
 
Hi Pasi, All, =

Although I agree with pursuing these items, I =
would like the group to
also consider extensions for IPsec traffic =
visibility. There are two
drafts that are proposing some of these =
extensions and I am 
working =
with
some colleagues on submitting an update to =
one of these shortly. These
are:
 
h=
ttp://www.ietf.org/internet-drafts/draft-hoffman-esp-null-pro
    =

tocol-00.t
=
  
xt.
 
and
 
<=
span
lang=3DDE>http://www.ietf.org/internet-drafts/draft-grewal-ipsec-traffic<=
/span>
    =

-visibilit
=
  
y-00.txt
 
In your draft charter, there are two items =
related to IPsec VPNs.
Although VPN is the predominant use of IPsec =
today for remote access /
site-to-site, I believe one of the reasons =
that IPsec 
end-to-end is =
not
widely employed today is due to the lack of =
traffic visibility in
managed environments such as Enterprises. AH =
is not practical and ESP
does not offer enough flexibility. =

 
I would like the group to consider a small =
modification to the charter
and include text on using IPsec in real =
world, end-to-end solutions
where practical considerations such as =
network management tools /
intrusion detection / malware scanning tools =
are unable to 
operate =
when
the data is encrypted. Having IPsec =
extensions to accommodate these
tools will greatly increase the viability of =
using IPsec 
beyond just =
VPN
and remote =
access.
 
I will be happy to present some of these =
findings / ideas at the next
IETF.
 
Thanks for your consideration... =

 
Thanks, =

- =
Ken
 
 
-----Original =
Message-----
From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]=
 On Behalf
Of Pasi.Eronen@nokia.com
Sent: Sunday, June 01, 2008 11:13 =
AM
To: ipsec@ietf.org
Subject: [IPsec] First charter =
draft
 
Thanks to everyone who replied to the =
poll!
 
Based on the responses, I've put together a =
first draft 
of charter text, which has IMHO quite =
reasonable balance 
between maintenance (ikev2bis, roadmap, ipv6) =
and the 
extensions with widest interest (session =
resumption and redirect).
 
I also tried to come up with some text =
describing the 
work items, to make it clear what's in scope =
and what is not.
(Comments on that text are =
welcome!)
 
This list doesn't include =
draft-black-ipsec-ikev2-aead-modes,
since it's basically read to be published =
now, and might be out
before the WG gets =
created.
 
Please send comments (either privately or on =
the list) 
as soon as possible -- to have the first WG =
meeting in Dublin,
= 
we need to converge on charter text soon =
(since there are
several process steps it needs to go through =
before the WG
is officially =
approved).
 
Best =
regards,
Pasi
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
 
IP Security Maintenance and Extensions =
(ipsecme)
DRAFT =
2008-06-01
 
Chair(s): =
TBD
 
Security Area Director(s): =
TBD
 
Mailing =
Lists:
 
General Discussion: ipsec@ietf.org
To Subscribe: https://www.ietf.org=
/mailman/listinfo/ipsec
Archive: http://www.ietf.org/mail-archive/web/ipsec/
 
Description of Working =
Group:
 
The IPsec suite of protocols includes IKEv1 =
(RFC 2409 and associated
RFCs), IKEv2 (RFC 4106, RFC 4718, and =
associated RFCs), and the IPsec
security architecture (RFC 4301). IPsec is =
widely deployed in VPN
gateways, VPN remote access clients, and as a =
substrate for
host-to-host, host-to-network, and =
network-to-network security.
 
The IPsec Maintenance and Extensions Working =
Group will continue the
work of the earlier IPsec Working Group which =
was concluded in
2005. Its purpose is to maintain the IPsec =
standard and to facilitate
discussion of clarifications, improvements, =
and extensions and
improvements to IPsec, mostly to IKEv2. The =
working group will also 
be a focus point for other IETF Working =
Groups who use IPsec in their 
own =
protocols.
 
The initial set of work items =
is:
 
o  A revision to IKEv2 (RFC 4306) that =
incorporates the
   clarifications from RFC 4718, =
and otherwise improves the =
quality
   of the specification, taking =
into account implementation and
   interoperability =
experience.  In some cases, the revision =
may
   include small technical =
corrections; however, impact on =
existing
   implementations must be =
considered. Major changes and adding =
new
   features is beyond the scope of =
this work item. The starting
   point for this work is =
draft-hoffman-ikev2bis. 
 
o  An IPsec document roadmap that =
describes the various RFC 
   documents covering IPsec, =
including both the core RFC 240x =

   and RFC 430x versions of =
IPsec, and extensions specified in =

   other documents. Sections 2 =
and 3 of RFC 2411 can provide  =

   useful material, but the =
expected scope is slightly different =

   from RFC 2411. This =
document will be informational.
 
o  A standards-track extension to IKEv2 =
that provides full IPv6
   support for IPsec remote access =
clients that use configuration
   payloads. This work will be =
based on
   =
draft-eronen-ipsec-ikev2-ipv6-config.
=
 
o  A standards-track extension that =
allows an IPsec remote access
   client to "resume" a =
session with a gateway; that is, to skip =

   certain parts of IKE =
negotation when connecting again to the =

   same gateway (or possibly a =
cluster of closely cooperating 
gateways).
=
 
   The idea is similar to TLS =
session resumption without
   server-side state, specified in =
RFC 5077.
 
   The main goals for this =
extension are to avoid =
public-key
   computations (to reduce VPN =
gateway load when a large number =
of
   clients reconnect to the geteway =
within a short period of time,
   such as following a network =
outage), and remove the need =
for
   user interaction for =
authentication (which may be required =
by
   some authentication mechanisms). =
The extension shall not have 
   negative impact on IKEv2 =
security features.
 
   Failover from one gateway to =
another, mechanisms for =
detecting
   when a session should be =
resumed, and specifying =
communication
   mechanisms between gateways are =
beyond the scope of this work
   item.  Specifying the =
detailed contents of the "session =
ticket"
   is also beyond the scope of this =
document; if there is sufficient =

   interest, this could be =
specified later in a separate =
document.
 
   To the degree its content falls =
within the scope of this work
   item, text and ideas from =
draft-sheffer-ipsec-failover will =
be
   used as a starting =
point.
 
o  A standards-track extension to IPsec =
that allows an IPsec remote
   access gateway to redirect VPN =
clients to another gateway. =
This
   extension should be aligned with =
the session resumption =
extension,
   (the previous work item), and if =
so decided by the WG, could be
   specified in the same document. =
The starting point will be
   =
draft-devarapalli-ipsec-ikev2-redirect.
 
The initial scope of the WG is restricted to =
the work items listed
above. The WG shall not consider adding new =
work items until one or
more of its documents progress to IESG =
evaluation. At that time, the
WG can propose =
rechartering.
 
Chartering this WG is not intended to have =
effect on documents that
beyond the initial scope. In particular, work =
on IPsec extensions that
are not included in this charter can happen =
as usual in other WGs (and
there are currently several other WGs working =
on IPsec extensions; for
example, BTNS and ROHC), or as individual =
submissions.
 
This charter will expire in June 2010 (24 =
months from approval).  If
the charter is not updated before that time, =
the WG will be closed and
any remaining documents revert back to =
individual Internet-Drafts.
 
Goals and =
Milestones:
 
Dec 2008  WG last call on IPv6 =
configuration payloads
Dec 2008  WG last call on IPsec =
roadmap
Mar 2009  WG last call on =
IKEv2bis
Jan 2009  WG last call on session =
resumption
Feb 2009  WG last call on =
redirect
 
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

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

______________________________________________=
_
IPsec mailing =
list
IPsec@ietf.org
https://www.ietf.org=
/mailman/listinfo/ipsec
 
Scanned by Check Point Total Security =
Gateway.
 
 
------_=_NextPart_001_01C8C823.7B907952-- --===============0976854651== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============0976854651==-- From ipsec-bounces@ietf.org Fri Jun 6 15:21:47 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 463A428C1C4; Fri, 6 Jun 2008 15:21:47 -0700 (PDT) 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 ACF5A28C1C4 for ; Fri, 6 Jun 2008 15:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 csJoQ6u5u2F8 for ; Fri, 6 Jun 2008 15:21:44 -0700 (PDT) Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by core3.amsl.com (Postfix) with ESMTP id 7681128C184 for ; Fri, 6 Jun 2008 15:21:44 -0700 (PDT) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga102.fm.intel.com with ESMTP; 06 Jun 2008 15:21:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.27,602,1204531200"; d="scan'208";a="337183629" Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by fmsmga002.fm.intel.com with ESMTP; 06 Jun 2008 15:19:49 -0700 Received: from fmsmsx881.amr.corp.intel.com ([10.19.19.13]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jun 2008 15:21:48 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 6 Jun 2008 15:20:56 -0700 Message-ID: In-Reply-To: <1696498986EFEC4D9153717DA325CB72D54D1F@vaebe104.NOE.Nokia.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] First charter draft Thread-Index: AcjHpvaT8wN13Z0lS3CpdDXacBUnzwAGY2swABUux0A= References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com><1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com><18504.59167.826685.44808@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB72D54D1F@vaebe104.NOE.Nokia.com> From: "Grewal, Ken" To: , X-OriginalArrivalTime: 06 Jun 2008 22:21:48.0789 (UTC) FILETIME=[B64BCA50:01C8C823] Cc: ipsec@ietf.org Subject: Re: [IPsec] First charter draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Totally Agree! Thanks, - Ken -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Pasi.Eronen@nokia.com Sent: Friday, June 06, 2008 3:37 AM To: kivinen@iki.fi Cc: ipsec@ietf.org Subject: Re: [IPsec] First charter draft Tero Kivinen wrote: > I think both of these need more discussion before they should be > accepted as charter items, and I am not sure we should be doing that > now, as it might delay the creation of the WG. I think we can start > discussing whether those should be added as working item after we > get at least one of the original items out from the WG. That is possible. On the other hand, the current charter is very much skewed towards "remote access VPN" use of IPsec... > The GRE key traffic selector itself is not that hard thing, but there > is all kind of other things related to it. When we added the protocol > selectors on the IPsec architecture we didn't really realize that > there is problems with fragments, and I think the gre key field has > same problem, thus it might require stateful fragment checking and > so on. To me, it seems GRE key would not be significantly different from other selectors (ICMP type/code, TCP port, etc.) -- you need to consider fragments, yes, but probably don't need to do anything significantly different from what was done for other protocols. > Also I am not sure why different gre key values needs to be put on > the separate SA. I have not really seen good reason why this is > needed. Apparently, other folks have scenarios where they'd like to do this. > For the ESP NULL traffic visibility there is the problem that > firewalls cannot really trust the bit saying "I am nice, I am > authenticated only packet, there is no need to block me", meaning > the firewalls needs to inspect the packet inside the ESP packet > anyways, so I am not sure if that is right way to do that thing > either. I think one main motivation here was to help inspecting the packet, by telling where exactly the payload is (e.g. how long the IV and ICV are). So no, you can't really trust the "evil bit" -- you do packet inspection as you'd do for non-IPsec packets. Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 6 15:33:45 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 462A33A681D; Fri, 6 Jun 2008 15:33:45 -0700 (PDT) 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 7C6213A681D for ; Fri, 6 Jun 2008 15:33:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ug+dkCfYKpth for ; Fri, 6 Jun 2008 15:33:42 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by core3.amsl.com (Postfix) with ESMTP id 55B2C3A681C for ; Fri, 6 Jun 2008 15:33:42 -0700 (PDT) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 06 Jun 2008 15:31:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.27,602,1204531200"; d="scan'208";a="289255359" Received: from fmsmsx334.amr.corp.intel.com ([132.233.42.1]) by orsmga002.jf.intel.com with ESMTP; 06 Jun 2008 15:35:02 -0700 Received: from fmsmsx881.amr.corp.intel.com ([10.19.19.13]) by fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 6 Jun 2008 15:33:52 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Fri, 6 Jun 2008 15:33:46 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] First charter draft Thread-Index: AcjH8JeOrzL/sIOuT8at7UzKCni9SwAJOJTA References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com><1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com> From: "Grewal, Ken" To: "Stephen Kent" , X-OriginalArrivalTime: 06 Jun 2008 22:33:52.0891 (UTC) FILETIME=[65E4FCB0:01C8C825] Cc: ipsec@ietf.org Subject: Re: [IPsec] First charter draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Steve, Many thanks for your observations. The initial draft was put together relatively quickly to solicit initial feedback and as you correctly point out, there are some obvious inconsistencies with citations and implicit inferences, instead of explicitly calling out the operations. I have had other similar responses and suggestions (some outside of the IPsec reflector) and am actively incorporating these into an updated version of the draft, which I will publish shortly. Hopefully, this will help to simplify the payload parsing and essentially combine some of the ideas from both of the current drafts into a single place. The motivation here is primarily inside the Enterprise and specifically transport mode, which are not the predominant uses of IPsec today. Having some of these capabilities will help to promote these usage models, hence expanding the scope of IPsec - at least IMHO! Thanks, - Ken -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Stephen Kent Sent: Friday, June 06, 2008 9:11 AM To: Pasi.Eronen@nokia.com Cc: ipsec@ietf.org Subject: Re: [IPsec] First charter draft Pasi, The I-D draft-grewal-ipsec-traffic-visibility has a number of presentation problems. The text refers to IVs and ICVs, without noting that only for combined mode algorithms would an IV be used in the context of null-encryption. Moreover, combined mode algorithm support was introduced only in ESPv2 (RFC 4303), but the I-D cites only ESP v1 (RFC 2406). Similarly, the text cites 2301, not 4301. In 2301, AH support is mandated, and so one could argue that in an enterprise context where intermediate systems need to examine packet contents, the enterprise could just mandate use of AH. In 4301, support for AH is no longer mandated, and so the encapsulation mechanism proposed in this I-D makes more sense. Thus I think that 4301 is the appropriate cite here. Also, IKEv2 is cited, and it is used only in the 4301 context, so ... The I-D doesn't explain how an intermediate system will determine the end of the real payload, to enable it to "further parse the packet to extract the data portion." That system needs to know the pad length. True, this can be determined by working back from the ICV length and the next header field, but the text fails to mention that. Moreover, if you have to do that processing, you could grab the next header field then, and not have it in the UDP encapsulation header. Finally, the explanation how to validate a UDP-encapsulated ESP-NULL packet, in the face of possible port conflicts appears to be underspecified. One can argue that if there is a viable heuristic to deal with this case, an intermediate system could perform these checks on ESP traffic, cache the SA info (by S/D host addresses and SPI values) and avoid the need for the encapsulation proposed here! This seems especially true given that the scope of this I-D appears to be traffic within an enterprise net, not the more general case of any intermediate system along a path, perhaps at the boundary between an enterprise net and the public internet. In contrast, the draft-hoffman-esp-null-protocol I-D is very simple and does not impose the burden of an extra encapsulation layer. However it consumes two protocol numbers from a space that has traditionally been consider relatively scarce. Also, these two numbers might not suffice if additional combined mode algorithms, with different IV lengths, are adopted in the future. This I-D needs more details discussing exactly how an intermediate system will perform the necessary packet inspection. Finally, because this I-D tries to address the more general case of an intermediate system along a path (anywhere?), it require more discussion of what set of policies make sense in the more general context. (I think this is needed to that folks don't jump to inaccurate conclusions about what such a facility will buy them.) So, like Tero, I am not convinced that this topic should be a high priority for the new IPsec WG. I have not yet looked at the GRE proposal, but I do not that defining additional selector values may pose problems for folks who have designed hardware that relies on the fact that the set of selectors has remained fairly static for many years. Also, I agree with Tero that we need to understand very thoroughly why there is a need to use additional data as traffic selectors, so that we don't set a precedent that will haunt us in the future. If we create a number of application-specific variants of IPsec for different contexts, we run the risk of undermining interoperability. Steve _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 6 15:41:26 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 441AC3A689E; Fri, 6 Jun 2008 15:41:26 -0700 (PDT) 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 842033A689E for ; Fri, 6 Jun 2008 15:41:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 yVHeudWVRULT for ; Fri, 6 Jun 2008 15:41:19 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id D3A343A681C for ; Fri, 6 Jun 2008 15:41:18 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,602,1204531200"; d="scan'208,217";a="109646883" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 06 Jun 2008 15:41:29 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id m56MfT83009108; Fri, 6 Jun 2008 15:41:29 -0700 Received: from sfluhrerwxp (stealth-10-32-244-83.cisco.com [10.32.244.83]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m56MfSp4013564; Fri, 6 Jun 2008 22:41:28 GMT From: "Scott Fluhrer" To: "'Green, Mike'" , References: <21B723FB5CC281419BEA1CF988966ED9E9BB36@DE08EV803.global.ds.honeywell.com> Date: Fri, 6 Jun 2008 18:41:28 -0400 Message-ID: <00c801c8c826$75fd8300$53f4200a@amer.cisco.com> MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook 11 x-mimeole: Produced By Microsoft MimeOLE V6.00.2900.3198 In-Reply-To: <21B723FB5CC281419BEA1CF988966ED9E9BB36@DE08EV803.global.ds.honeywell.com> Thread-Index: AcjIGdXzaSB5q5IRTJasafK4QouaOQACe8bQ DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7791; t=1212792089; x=1213656089; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sfluhrer@cisco.com; z=From:=20=22Scott=20Fluhrer=22=20 |Subject:=20RE=3A=20[IPsec]=20question=20about=20RFC=204303 =20section=203.3.2.1 |Sender:=20; bh=amOqbdejMirZ+vuFeW0PfywPAP0pVGEonrirjfpq2rY=; b=nKJVa/Rkm4gifmicGZS7qddIctAMt/Jcx3xFDnhtzwyAFpGsYMa4IM8T0G Bwk75v8+xzvkMoLyNHMl2nmARwpZ0U+I4GABfElLyDRm1b06R8Z3ty8rV37L HM8HZOqiY7; Authentication-Results: sj-dkim-3; header.From=sfluhrer@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [IPsec] question about RFC 4303 section 3.3.2.1 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: , Content-Type: multipart/mixed; boundary="===============0281471282==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0281471282== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00C9_01C8C804.EEEBE300" This is a multi-part message in MIME format. ------=_NextPart_000_00C9_01C8C804.EEEBE300 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit _____ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Green, Mike Sent: Friday, June 06, 2008 5:11 PM To: ipsec@ietf.org Subject: [IPsec] question about RFC 4303 section 3.3.2.1 Sorry if this is the wrong forum: Are the steps outlined in this section a MUST from an order of operations standpoint? In other words, if you're encrypted the packet using a non-chaining algorithm, is it possible to construct an ESP IPsec packet by encrypting the payload before the header? Is possible even using a chaining cipher algorithm to do that? Thanks. As Steve pointed out, you must do step 4 (the ICV computation) over the encrypted packet, forcing you to do step 3 (the actual encryption) first (or, if you're careful, in parallel). However, you appear to be asking "do I have to add the ESP header (and the outer IP header if tunnel mode) first, or can I do that step after encrypting". Well, nothing in step 3 depends on the header data. You will need to know exactly what you're encrypting (the padded packet in tunnel mode, the padding packet minus the IP header in transport mode). In addition, if your encryption mode uses an IV or a nonce, then you'll need to select it before encrypting, and then insert the selected value between the ESP header (SPI and sequence number) and the actual encrypted data. I also don't see any security weaknesses introduced by changing this order. Mike Green ph 602.822.4360 mike.a.green@honeywell.com ------=_NextPart_000_00C9_01C8C804.EEEBE300 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
 

From: ipsec-bounces@ietf.org=20 [mailto:ipsec-bounces@ietf.org] On Behalf Of Green,=20 Mike
Sent: Friday, June 06, 2008 5:11 PM
To:=20 ipsec@ietf.org
Subject: [IPsec] question about RFC 4303 = section=20 3.3.2.1

Sorry if this is the = wrong=20 forum:

 

Are the=20 steps outlined in this section a MUST from an order of operations = standpoint?=20 In other words, if you’re encrypted the packet using a = non-chaining algorithm,=20 is it possible to construct an ESP IPsec packet by encrypting the = payload=20 before the header? Is possible even using a chaining cipher algorithm = to do=20 that?  Thanks. 

As Steve pointed out, you must do step 4 (the = ICV=20 computation) over the encrypted packet, forcing you to do step 3 (the = actual=20 encryption) first (or, if you're careful, in parallel).  However, = you=20 appear to be asking "do I have to add the ESP header (and the outer IP = header if=20 tunnel mode) first, or can I do that step after=20 encrypting".

 

Well, nothing in step 3 depends on the header = data.  You will need to know exactly what you're encrypting (the = padded=20 packet in tunnel mode, the padding packet minus the IP header in = transport=20 mode).  In addition, if your encryption mode uses an IV or a = nonce,=20 then you'll need to select it before encrypting, and then insert the = selected=20 value between the ESP header (SPI and sequence number) and the = actual=20 encrypted data.

 

I also don't see any security weaknesses = introduced by=20 changing this order.

 

 

Mike=20 Green

ph=20 602.822.4360

mike.a.green@honeywell.com

 

------=_NextPart_000_00C9_01C8C804.EEEBE300-- --===============0281471282== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============0281471282==-- From ipsec-bounces@ietf.org Sat Jun 7 03:00:56 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C10413A6948; Sat, 7 Jun 2008 03:00:56 -0700 (PDT) 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 47AB13A6934 for ; Sat, 7 Jun 2008 03:00:55 -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 5pjXFJW6V4LW for ; Sat, 7 Jun 2008 03:00:54 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.189]) by core3.amsl.com (Postfix) with ESMTP id 154463A6A44 for ; Sat, 7 Jun 2008 03:00:53 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so618328tib.25 for ; Sat, 07 Jun 2008 03:01:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=1tdbcyhrr0lkTI48FCpa4PQSGkmid88aHA3uEz4cE/k=; b=YhwiE5S1dzjzvVl4gzpim5pkrpneA9i0YBrmIZtrnfns+Bd5a7Ttz9Zfy2iduYdlzS J+1mFI/60e1ED/ELCsI6TwcYJtMbMNbIbE3wSXq8SHFuouH+bfjmx9/oSPtzm1/pxWGc 3UODTp5OOEdzyUH/aY3sJ4MQgFSp7P6YTPoiw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=C8M55mttIBT4+TOOs0c1lEq1MRHTqHwJnjPs6JI4vq5N6Bnxb290FTbefmpY2FImyr JXijXjfUwjpFmzL6NCCgowbM3fCohk+SGvHmeUBElWDbs3Xnp0eH3/dpfXVEFJUFtuyk YUtvzLRwVqeZr9mTob6jg+UxfYv7rPP4qtww4= Received: by 10.110.84.2 with SMTP id h2mr239096tib.47.1212832861105; Sat, 07 Jun 2008 03:01:01 -0700 (PDT) Received: by 10.110.53.11 with HTTP; Sat, 7 Jun 2008 03:01:01 -0700 (PDT) Message-ID: <1d38a3350806070301q4046e545t1e2231c3a0c8acf5@mail.gmail.com> Date: Sat, 7 Jun 2008 18:01:01 +0800 From: "Hui Deng" To: Pasi.Eronen@nokia.com, "denghui@chinamobile.com" In-Reply-To: <1696498986EFEC4D9153717DA325CB72D54D1F@vaebe104.NOE.Nokia.com> MIME-Version: 1.0 Content-Disposition: inline References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com> <18504.59167.826685.44808@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB72D54D1F@vaebe104.NOE.Nokia.com> Cc: ipsec@ietf.org, kivinen@iki.fi Subject: Re: [IPsec] First charter draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Dear Tero Many thanks for your previous discussion, those comments are really helpful for our next version revision, >> Also I am not sure why different gre key values needs to be put on >> the separate SA. I have not really seen good reason why this is >> needed. > > Apparently, other folks have scenarios where they'd like to do this. There are several scenarios we would like to do this, one of example, you could find from 3GPP TS 23.402, GRE key has been used to encapsulate traffic to the PDN GW. When operator connected to different level enterprise customer and each had different security requirements(for example, some require AH, others need ESP), more and more specifically each enterprise has more small granunarity, we'd better handle them differently. Moreover operator also could specify more virtual groups among them. Appreciate your comments. Best regards, -Hui _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 9 06:29:01 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 526CB3A6C5F; Mon, 9 Jun 2008 06:29:01 -0700 (PDT) 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 CAFA23A6C5F for ; Mon, 9 Jun 2008 06:28:59 -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 xvcAEbC+7CwJ for ; Mon, 9 Jun 2008 06:28:58 -0700 (PDT) Received: from mail.kivinen.iki.fi (unknown [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 0AC0D28C15B for ; Mon, 9 Jun 2008 06:28:57 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.13.8/8.13.8) with ESMTP id m59DTDjF002948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 16:29:13 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.8/8.12.11) id m59DTCjl003227; Mon, 9 Jun 2008 16:29:12 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18509.12328.427110.610804@fireball.kivinen.iki.fi> Date: Mon, 9 Jun 2008 16:29:12 +0300 From: Tero Kivinen To: In-Reply-To: <1696498986EFEC4D9153717DA325CB72D54D1F@vaebe104.NOE.Nokia.com> References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com> <18504.59167.826685.44808@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB72D54D1F@vaebe104.NOE.Nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 13 min X-Total-Time: 15 min Cc: ipsec@ietf.org Subject: Re: [IPsec] First charter draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Pasi.Eronen@nokia.com writes: > > The GRE key traffic selector itself is not that hard thing, but there > > is all kind of other things related to it. When we added the protocol > > selectors on the IPsec architecture we didn't really realize that > > there is problems with fragments, and I think the gre key field has > > same problem, thus it might require stateful fragment checking and > > so on. > > To me, it seems GRE key would not be significantly different from > other selectors (ICMP type/code, TCP port, etc.) -- you need to > consider fragments, yes, but probably don't need to do anything > significantly different from what was done for other protocols. It has significant difference to the other selectors, as it is designed to hide the real traffic selectors which are inside the GRE encapsulated packet, i.e. it will cause packets to bypass the IPsec checks. This could be acceptable and useful, but it is quite big difference to the other selectors. Of course you can tunnel IP-packets over http to get the same effect, but that is bit different case for architecture point of view. > > Also I am not sure why different gre key values needs to be put on > > the separate SA. I have not really seen good reason why this is > > needed. > > Apparently, other folks have scenarios where they'd like to do this. Those two GRE / IPsec draft I read didn't give any good reason for the need for separate SAs. We have used the example for port selectors that you protect SMTP with 3DES and all other traffic with AES, but I think that is actually very weak reason. The biggest reason we have for traffic selectors is the filtering capabilities, i.e.we can say only HTTP traffic or only SMTP traffic, not the capability of using different algorithms for different traffic. That reason is not there in the GRE as we do not check inside the GRE packets. Anyways I still think that GRE case do need more discussion before it should be accepted. For example neither of the drafts I read is really about just using the GRE key as traffic selector. > > For the ESP NULL traffic visibility there is the problem that > > firewalls cannot really trust the bit saying "I am nice, I am > > authenticated only packet, there is no need to block me", meaning > > the firewalls needs to inspect the packet inside the ESP packet > > anyways, so I am not sure if that is right way to do that thing > > either. > > I think one main motivation here was to help inspecting the packet, > by telling where exactly the payload is (e.g. how long the IV and ICV > are). So no, you can't really trust the "evil bit" -- you do packet > inspection as you'd do for non-IPsec packets. But the traffic you are inspecting is already supposed to come from "friendly" source, thus you will most likely already know what algorithms and such are used (there are not that many different possibilities there). But now we are going to the discussion part, which I was saying we would need before accepting those as charter item :-) Perhaps we should add those in the charter, but make the text so that it is very clear that not making a document about that item is also completely acceptable outcome from the charter item, and doing so would be considered as success for the WG (i.e it has successfully removed one item from its charter by deciding not to do that item, thus can recharter and take something else instead). -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 9 06:38:30 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6BA9428C175; Mon, 9 Jun 2008 06:38:30 -0700 (PDT) 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 BB02328C16B for ; Mon, 9 Jun 2008 06:38:29 -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 nXWlUYXrFyeu for ; Mon, 9 Jun 2008 06:38:28 -0700 (PDT) Received: from mail.kivinen.iki.fi (unknown [IPv6:2001:1bc8:100d::2]) by core3.amsl.com (Postfix) with ESMTP id 68D1328C16A for ; Mon, 9 Jun 2008 06:38:28 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.13.8/8.13.8) with ESMTP id m59Dcja3027783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 16:38:45 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.8/8.12.11) id m59DciXj003218; Mon, 9 Jun 2008 16:38:44 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18509.12900.397034.403607@fireball.kivinen.iki.fi> Date: Mon, 9 Jun 2008 16:38:44 +0300 From: Tero Kivinen To: "Grewal, Ken" In-Reply-To: References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com> <18504.59167.826685.44808@fireball.kivinen.iki.fi> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 6 min Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com Subject: Re: [IPsec] First charter draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Grewal, Ken writes: > [Ken] I agree that one cannot just trust the bit, but it can provide the > firewall (or IDS/IPS system) with enough knowledge to determine if it > can successfully scan the payload inside the packet. As there cannot be any encrypted traffic you would like the get through in that case, you can simply continue inspecting the traffic. There is very few different valid ESP-NULL algorithms commonly in use, and in enterprice case you most likely enforce exactly one (or perhaps two) algorithms, thus you already know offset and such for the legimite traffic. So you simply start inspecting data from there, and if it does not look like plain text IP-packet you throw the packet away based on the fact that it was either encrypted, or used non-approved ESP-NULL algorithm or it was just some kind of attack. As the algorithms for the same SPI + IP-address pair cannot change on the fly, you can also do this heuristic check only for the first packet for each seen SPI + IP-address pairs (and perhaps after IKE SA creation, just in case other end decided to select exactly IPsec SPI for the first child SA they are creating after crash, reusing same SPI for rekeys is not allowed). As the device will most likely do stateful inspection anyways, it will be storing much more state information from the TCP sessions run inside the ESP-NULL SA than what it needs to store for the SPI... -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 9 08:45:45 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B40B83A6B21; Mon, 9 Jun 2008 08:45:45 -0700 (PDT) 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 47FD03A6C51 for ; Mon, 9 Jun 2008 08:45:43 -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=[AWL=0.000, 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 x75s9XXhjDpi for ; Mon, 9 Jun 2008 08:45:37 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.186]) by core3.amsl.com (Postfix) with ESMTP id 3CA8E28C190 for ; Mon, 9 Jun 2008 08:45:33 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so906768tib.25 for ; Mon, 09 Jun 2008 08:45:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=0FLRKf5cHrNsQWA52dF5IdYIGc6/GFPWimJjuIFyrqw=; b=fg3qxeNHZ3FGBAbzlYGE5oqHdiIPL3aXcQwe9niQxv+UyUdZXXPDavnpW4xizY61Da Rfdl43eRjBcBml1dmsgzfO4SsJDyDT00FVG0R7T2I3oQLb3XQW2LNedhp+XQiJlY9g0h JetSLc6KmAVa1qXxJ4tGkLnLk0y9D5Jj049vI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=hD26wlg1b89zoqPTVA3yS7YS9B4wTqbB+jxTdiXlnUqHjrE5pIK70/NZ8pHFX3OgJ6 XzQmyZDMTqqG6ngZiu6DnsCYALJh62dtrQ71s4SR7MfqDdQ8FkO2GZwKw1D4GeEzJVX4 B0Iqg3LxjTlKIOeZ8sLUjZNPjQWaRdNeozH2s= Received: by 10.110.50.19 with SMTP id x19mr835562tix.36.1213026347371; Mon, 09 Jun 2008 08:45:47 -0700 (PDT) Received: by 10.110.53.11 with HTTP; Mon, 9 Jun 2008 08:45:47 -0700 (PDT) Message-ID: <1d38a3350806090845s5c45305ft5247ffcd1508eda3@mail.gmail.com> Date: Mon, 9 Jun 2008 23:45:47 +0800 From: "Hui Deng" To: "Tero Kivinen" In-Reply-To: <18509.12328.427110.610804@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com> <18504.59167.826685.44808@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB72D54D1F@vaebe104.NOE.Nokia.com> <18509.12328.427110.610804@fireball.kivinen.iki.fi> Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com Subject: Re: [IPsec] First charter draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Dear Tero, The email which I replied the day before yesterday has some error message, Please kind help to check the link here http://www.ietf.org/mail-archive/web/ipsec/current/msg02839.html other reply inline below Thanks for your kind discussion 2008/6/9 Tero Kivinen : > Pasi.Eronen@nokia.com writes: >> > The GRE key traffic selector itself is not that hard thing, but there >> > is all kind of other things related to it. When we added the protocol >> > selectors on the IPsec architecture we didn't really realize that >> > there is problems with fragments, and I think the gre key field has >> > same problem, thus it might require stateful fragment checking and >> > so on. >> >> To me, it seems GRE key would not be significantly different from >> other selectors (ICMP type/code, TCP port, etc.) -- you need to >> consider fragments, yes, but probably don't need to do anything >> significantly different from what was done for other protocols. > > It has significant difference to the other selectors, as it is > designed to hide the real traffic selectors which are inside the GRE > encapsulated packet, i.e. it will cause packets to bypass the IPsec > checks. This could be acceptable and useful, but it is quite big > difference to the other selectors. Of course you can tunnel IP-packets > over http to get the same effect, but that is bit different case for > architecture point of view. ==> the incentive of our work is not checking other IPsec, what we want to do is just GRE key check. > >> > Also I am not sure why different gre key values needs to be put on >> > the separate SA. I have not really seen good reason why this is >> > needed. >> >> Apparently, other folks have scenarios where they'd like to do this. > > Those two GRE / IPsec draft I read didn't give any good reason for the > need for separate SAs. > > We have used the example for port selectors that you protect SMTP with > 3DES and all other traffic with AES, but I think that is actually very > weak reason. The biggest reason we have for traffic selectors is the > filtering capabilities, i.e.we can say only HTTP traffic or only SMTP > traffic, not the capability of using different algorithms for > different traffic. That reason is not there in the GRE as we do not > check inside the GRE packets. > > Anyways I still think that GRE case do need more discussion before it > should be accepted. For example neither of the drafts I read is really > about just using the GRE key as traffic selector. We are working on the new updated version, please help to wait a moment many thanks -Hui > >> > For the ESP NULL traffic visibility there is the problem that >> > firewalls cannot really trust the bit saying "I am nice, I am >> > authenticated only packet, there is no need to block me", meaning >> > the firewalls needs to inspect the packet inside the ESP packet >> > anyways, so I am not sure if that is right way to do that thing >> > either. >> >> I think one main motivation here was to help inspecting the packet, >> by telling where exactly the payload is (e.g. how long the IV and ICV >> are). So no, you can't really trust the "evil bit" -- you do packet >> inspection as you'd do for non-IPsec packets. > > But the traffic you are inspecting is already supposed to come from > "friendly" source, thus you will most likely already know what > algorithms and such are used (there are not that many different > possibilities there). > > But now we are going to the discussion part, which I was saying we > would need before accepting those as charter item :-) > > Perhaps we should add those in the charter, but make the text so that > it is very clear that not making a document about that item is also > completely acceptable outcome from the charter item, and doing so > would be considered as success for the WG (i.e it has successfully > removed one item from its charter by deciding not to do that item, > thus can recharter and take something else instead). > -- > kivinen@safenet-inc.com > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 9 09:55:05 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8E9B83A6A84; Mon, 9 Jun 2008 09:55:05 -0700 (PDT) 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 9B5203A6A84 for ; Mon, 9 Jun 2008 09:55:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 yNPdMNaVxYck for ; Mon, 9 Jun 2008 09:55:03 -0700 (PDT) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by core3.amsl.com (Postfix) with ESMTP id BE1EA3A6A6C for ; Mon, 9 Jun 2008 09:55:03 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga101.jf.intel.com with ESMTP; 09 Jun 2008 09:52:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.27,613,1204531200"; d="scan'208";a="392572890" Received: from fmsmsx333.amr.corp.intel.com ([132.233.42.2]) by orsmga001.jf.intel.com with ESMTP; 09 Jun 2008 09:55:12 -0700 Received: from fmsmsx881.amr.corp.intel.com ([10.19.19.13]) by fmsmsx333.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 09:55:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Jun 2008 09:55:07 -0700 Message-ID: In-Reply-To: <18509.12328.427110.610804@fireball.kivinen.iki.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] First charter draft Thread-Index: AcjKNQlyBFgsNewFQbmf8uXVGSCFfwAG8pGw References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com><1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com><18504.59167.826685.44808@fireball.kivinen.iki.fi><1696498986EFEC4D9153717DA325CB72D54D1F@vaebe104.NOE.Nokia.com> <18509.12328.427110.610804@fireball.kivinen.iki.fi> From: "Grewal, Ken" To: "Tero Kivinen" , X-OriginalArrivalTime: 09 Jun 2008 16:55:21.0251 (UTC) FILETIME=[9A73EF30:01C8CA51] Cc: ipsec@ietf.org Subject: Re: [IPsec] First charter draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Tero, I agree that a further discussion on this is useful to ensure the usage models and extensions are better understood by all, before dismissing the work item. Thanks, - Ken -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Tero Kivinen Sent: Monday, June 09, 2008 6:29 AM To: Pasi.Eronen@nokia.com Cc: ipsec@ietf.org Subject: Re: [IPsec] First charter draft But now we are going to the discussion part, which I was saying we would need before accepting those as charter item :-) Perhaps we should add those in the charter, but make the text so that it is very clear that not making a document about that item is also completely acceptable outcome from the charter item, and doing so would be considered as success for the WG (i.e it has successfully removed one item from its charter by deciding not to do that item, thus can recharter and take something else instead). -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 9 10:17:09 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E30E53A69CF; Mon, 9 Jun 2008 10:17:09 -0700 (PDT) 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 007573A69CF for ; Mon, 9 Jun 2008 10:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[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 3xSlZ6bzOhuF for ; Mon, 9 Jun 2008 10:17:07 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 402453A6910 for ; Mon, 9 Jun 2008 10:17:07 -0700 (PDT) Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59HHO7L044240 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 9 Jun 2008 10:17:25 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 9 Jun 2008 10:17:22 -0700 To: IPsec WG From: The IESG (by way of Paul Hoffman) Subject: [IPsec] Last Call: draft-black-ipsec-ikev2-aead-modes (Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol) to Proposed Standard 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org The IESG has received a request from an individual submitter to consider the following document: - 'Using Authenticated Encryption Algorithms with the Encrypted Payload of the Internet Key Exchange version 2 (IKEv2) Protocol ' 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 2008-07-07. 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://www.ietf.org/internet-drafts/draft-black-ipsec-ikev2-aead-modes-01.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17056&rfc_flag=0 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 9 10:25:04 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 36C573A6A6E; Mon, 9 Jun 2008 10:25:04 -0700 (PDT) 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 96DB13A6B07 for ; Mon, 9 Jun 2008 10:25:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.488 X-Spam-Level: X-Spam-Status: No, score=-2.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 qfVFcsgiTuNI for ; Mon, 9 Jun 2008 10:24:56 -0700 (PDT) Received: from balder-227.proper.com (properopus-pt.tunnel.tserv3.fmt2.ipv6.he.net [IPv6:2001:470:1f04:392::2]) by core3.amsl.com (Postfix) with ESMTP id 568173A6784 for ; Mon, 9 Jun 2008 10:24:56 -0700 (PDT) Received: from [10.20.30.162] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id m59HPCWv045902 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Jun 2008 10:25:13 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com><1696498986EFE C4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com><18504.59167.826685.44808 @fireball.kivinen.iki.fi><1696498986EFEC4D9153717DA325CB72D54D1F@vaebe104. NOE.Nokia.com> <18509.12328.427110.610804@fireball.kivinen.iki.fi> Date: Mon, 9 Jun 2008 10:25:11 -0700 To: "Grewal, Ken" , "Tero Kivinen" , From: Paul Hoffman Cc: ipsec@ietf.org Subject: Re: [IPsec] First charter draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This thread finally came back around to the subject line! :-) At 9:55 AM -0700 6/9/08, Grewal, Ken wrote: >I agree that a further discussion on this is useful to ensure the usage >models and extensions are better understood by all, before dismissing >the work item. Pasi's original message on this thread said: At 9:12 PM +0300 6/1/08, wrote: >Chartering this WG is not intended to have effect on documents that >beyond the initial scope. In particular, work on IPsec extensions that >are not included in this charter can happen as usual in other WGs (and >there are currently several other WGs working on IPsec extensions; for >example, BTNS and ROHC), or as individual submissions. It is hard to read that paragraph as "dismissing" any work item. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 9 10:37:48 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FD9F3A69E1; Mon, 9 Jun 2008 10:37:48 -0700 (PDT) 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 15A223A691F for ; Mon, 9 Jun 2008 10:37:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 scH+XwDlKnOs for ; Mon, 9 Jun 2008 10:37:46 -0700 (PDT) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by core3.amsl.com (Postfix) with ESMTP id 3F7A13A69E1 for ; Mon, 9 Jun 2008 10:37:46 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 09 Jun 2008 10:34:44 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.27,613,1204531200"; d="scan'208";a="574583456" Received: from fmsmsx334.amr.corp.intel.com ([132.233.42.1]) by fmsmga001.fm.intel.com with ESMTP; 09 Jun 2008 10:39:25 -0700 Received: from fmsmsx881.amr.corp.intel.com ([10.19.19.13]) by fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 10:38:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Jun 2008 10:37:32 -0700 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] First charter draft Thread-Index: AcjKVc7V5eWif76PTAq7VgpJXBqOBwAAE5aA References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com><1696498986EFE C4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com><18504.59167.826685.44808 @fireball.kivinen.iki.fi><1696498986EFEC4D9153717DA325CB72D54D1F@vaebe104. NOE.Nokia.com> <18509.12328.427110.610804@fireball.kivinen.iki.fi> From: "Grewal, Ken" To: "Paul Hoffman" , "Tero Kivinen" , X-OriginalArrivalTime: 09 Jun 2008 17:38:05.0650 (UTC) FILETIME=[92F42B20:01C8CA57] Cc: ipsec@ietf.org Subject: Re: [IPsec] First charter draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Tero, I was agreeing with your suggestion of adding these items to the IPsec charter, with some conditions if necessary, which would at least facilitate the discussions within the charter & group. Specifically... "Perhaps we should add those in the charter, but make the text so that it is very clear that not making a document about that item is also completely acceptable outcome from the charter item, and doing so would be considered as success for the WG (i.e it has successfully removed one item from its charter by deciding not to do that item, thus can recharter and take something else instead)" Thanks, - Ken -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] Sent: Monday, June 09, 2008 10:25 AM To: Grewal, Ken; Tero Kivinen; Pasi.Eronen@nokia.com Cc: ipsec@ietf.org Subject: Re: [IPsec] First charter draft This thread finally came back around to the subject line! :-) At 9:55 AM -0700 6/9/08, Grewal, Ken wrote: >I agree that a further discussion on this is useful to ensure the usage >models and extensions are better understood by all, before dismissing >the work item. Pasi's original message on this thread said: At 9:12 PM +0300 6/1/08, wrote: >Chartering this WG is not intended to have effect on documents that >beyond the initial scope. In particular, work on IPsec extensions that >are not included in this charter can happen as usual in other WGs (and >there are currently several other WGs working on IPsec extensions; for >example, BTNS and ROHC), or as individual submissions. It is hard to read that paragraph as "dismissing" any work item. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 9 10:38:55 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F3DA3A6AB4; Mon, 9 Jun 2008 10:38:55 -0700 (PDT) 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 29BEB3A6AB4 for ; Mon, 9 Jun 2008 10:38:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 uwLbHwyFHyqJ for ; Mon, 9 Jun 2008 10:38:53 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by core3.amsl.com (Postfix) with ESMTP id 4A7823A691F for ; Mon, 9 Jun 2008 10:38:53 -0700 (PDT) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by orsmga102.jf.intel.com with ESMTP; 09 Jun 2008 02:36:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.27,613,1204531200"; d="scan'208";a="257993954" Received: from fmsmsx334.amr.corp.intel.com ([132.233.42.1]) by azsmga001.ch.intel.com with ESMTP; 09 Jun 2008 10:39:08 -0700 Received: from fmsmsx881.amr.corp.intel.com ([10.19.19.13]) by fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 9 Jun 2008 10:39:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 9 Jun 2008 10:39:07 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] First charter draft Thread-Index: AcjKVc7V5eWif76PTAq7VgpJXBqOBwAAE5aAAABb/nA= References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com><1696498986EFE C4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com><18504.59167.826685.44808 @fireball.kivinen.iki.fi><1696498986EFEC4D9153717DA325CB72D54D1F@vaebe104. NOE.Nokia.com> <18509.12328.427110.610804@fireball.kivinen.iki.fi> From: "Grewal, Ken" To: "Paul Hoffman" , "Tero Kivinen" , X-OriginalArrivalTime: 09 Jun 2008 17:39:06.0150 (UTC) FILETIME=[B703BC60:01C8CA57] Cc: ipsec@ietf.org Subject: Re: [IPsec] First charter draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org The previous message was a response to Paul's comments and not Tero - my apologies. Thanks, - Ken -----Original Message----- From: Grewal, Ken Sent: Monday, June 09, 2008 10:38 AM To: Paul Hoffman; Tero Kivinen; Pasi.Eronen@nokia.com Cc: ipsec@ietf.org Subject: RE: [IPsec] First charter draft Tero, I was agreeing with your suggestion of adding these items to the IPsec charter, with some conditions if necessary, which would at least facilitate the discussions within the charter & group. Specifically... "Perhaps we should add those in the charter, but make the text so that it is very clear that not making a document about that item is also completely acceptable outcome from the charter item, and doing so would be considered as success for the WG (i.e it has successfully removed one item from its charter by deciding not to do that item, thus can recharter and take something else instead)" Thanks, - Ken -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] Sent: Monday, June 09, 2008 10:25 AM To: Grewal, Ken; Tero Kivinen; Pasi.Eronen@nokia.com Cc: ipsec@ietf.org Subject: Re: [IPsec] First charter draft This thread finally came back around to the subject line! :-) At 9:55 AM -0700 6/9/08, Grewal, Ken wrote: >I agree that a further discussion on this is useful to ensure the usage >models and extensions are better understood by all, before dismissing >the work item. Pasi's original message on this thread said: At 9:12 PM +0300 6/1/08, wrote: >Chartering this WG is not intended to have effect on documents that >beyond the initial scope. In particular, work on IPsec extensions that >are not included in this charter can happen as usual in other WGs (and >there are currently several other WGs working on IPsec extensions; for >example, BTNS and ROHC), or as individual submissions. It is hard to read that paragraph as "dismissing" any work item. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 10 01:14:46 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7B72B3A6913; Tue, 10 Jun 2008 01:14:46 -0700 (PDT) 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 9274A3A6913 for ; Tue, 10 Jun 2008 01:14:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 hJiCCcMNe38M for ; Tue, 10 Jun 2008 01:14:41 -0700 (PDT) Received: from web81903.mail.mud.yahoo.com (web81903.mail.mud.yahoo.com [68.142.207.182]) by core3.amsl.com (Postfix) with SMTP id 697FE3A6908 for ; Tue, 10 Jun 2008 01:14:41 -0700 (PDT) Received: (qmail 44615 invoked by uid 60001); 10 Jun 2008 08:14:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=X-YMail-OSG:Received:X-Mailer:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=tUyEH+A3xSxVR4NHsiLKp8rH7kpsFfQhhI6VBSx4j/vOfe9IWUBE9bolYzAWMoEFoefav1RWUDOJeGUrL6+sgq7uI3YEMPcs7K5TBrCccgPdaziCQ2v0yBhpiDHYmliqOHdDqCPcouSlfKYpkFCADbHZEYRj0lMQld7UzwdEaBU=; X-YMail-OSG: PQ9qrpQVM1nTnWlr5cOr1Wx.kjL6MLzua08USYWfKQLVJyx_SFeFNUK0IXUiEz7qKQeEGbT_d_T.mWmZCyd6qub87rVCVw5477zloxUn0qliGedRvgW7xg-- Received: from [131.107.0.103] by web81903.mail.mud.yahoo.com via HTTP; Tue, 10 Jun 2008 01:14:57 PDT X-Mailer: YahooMailRC/975.41 YahooMailWebService/0.7.185 Date: Tue, 10 Jun 2008 01:14:57 -0700 (PDT) From: gabriel montenegro To: "Grewal, Ken" , Paul Hoffman , Tero Kivinen , Pasi.Eronen@nokia.com MIME-Version: 1.0 Message-ID: <353745.42697.qm@web81903.mail.mud.yahoo.com> Cc: ipsec@ietf.org Subject: Re: [IPsec] First charter draft 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: , Content-Type: multipart/mixed; boundary="===============0343852963==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0343852963== Content-Type: multipart/alternative; boundary="0-682683196-1213085697=:42697" --0-682683196-1213085697=:42697 Content-Type: text/plain; charset=us-ascii Such a caveat sounds reasonable, but, again, I do think it is important to include this item in the charter. Rechartering operations I've been involved with (e.g., MIP4, MIP6, MIPSHOP, CSI, 6lowpan, etc) have always had as one of the highest priority items to remove deployment blockers for the technology in question. This is what we're talking about here in terms of deployment blockers for IPsec in enterprise scenarios. tnx, -gabriel ----- Original Message ---- From: "Grewal, Ken" To: Paul Hoffman ; Tero Kivinen ; Pasi.Eronen@nokia.com Cc: ipsec@ietf.org Sent: Monday, June 9, 2008 10:37:32 AM Subject: Re: [IPsec] First charter draft Tero, I was agreeing with your suggestion of adding these items to the IPsec charter, with some conditions if necessary, which would at least facilitate the discussions within the charter & group. Specifically... "Perhaps we should add those in the charter, but make the text so that it is very clear that not making a document about that item is also completely acceptable outcome from the charter item, and doing so would be considered as success for the WG (i.e it has successfully removed one item from its charter by deciding not to do that item, thus can recharter and take something else instead)" Thanks, - Ken -----Original Message----- From: Paul Hoffman [mailto:paul.hoffman@vpnc.org] Sent: Monday, June 09, 2008 10:25 AM To: Grewal, Ken; Tero Kivinen; Pasi.Eronen@nokia.com Cc: ipsec@ietf.org Subject: Re: [IPsec] First charter draft This thread finally came back around to the subject line! :-) At 9:55 AM -0700 6/9/08, Grewal, Ken wrote: >I agree that a further discussion on this is useful to ensure the usage >models and extensions are better understood by all, before dismissing >the work item. Pasi's original message on this thread said: At 9:12 PM +0300 6/1/08, wrote: >Chartering this WG is not intended to have effect on documents that >beyond the initial scope. In particular, work on IPsec extensions that >are not included in this charter can happen as usual in other WGs (and >there are currently several other WGs working on IPsec extensions; for >example, BTNS and ROHC), or as individual submissions. It is hard to read that paragraph as "dismissing" any work item. --Paul Hoffman, Director --VPN Consortium _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --0-682683196-1213085697=:42697 Content-Type: text/html; charset=us-ascii
Such a caveat sounds reasonable, but, again, I do think it is important to include
this item in the charter. Rechartering operations I've been involved with
(e.g., MIP4, MIP6, MIPSHOP, CSI, 6lowpan, etc) have always
had as one of the highest priority items to remove deployment blockers for the
technology in question.

This is what we're talking about here in terms of deployment blockers for IPsec
in enterprise scenarios.

tnx,

-gabriel

----- Original Message ----
From: "Grewal, Ken" <ken.grewal@intel.com>
To: Paul Hoffman <paul.hoffman@vpnc.org>; Tero Kivinen <kivinen@iki.fi>; Pasi.Eronen@nokia.com
Cc: ipsec@ietf.org
Sent: Monday, June 9, 2008 10:37:32 AM
Subject: Re: [IPsec] First charter draft

Tero,
I was agreeing with your suggestion of adding these items to the IPsec
charter, with some conditions if necessary, which would at least
facilitate the discussions within the charter & group.

Specifically...

"Perhaps we should add those in the charter, but make the text so that
it is very clear that not making a document about that item is also
completely acceptable outcome from the charter item, and doing so
would be considered as success for the WG (i.e it has successfully
removed one item from its charter by deciding not to do that item,
thus can recharter and take something else instead)"

Thanks,
- Ken


-----Original Message-----
From: Paul Hoffman [mailto:paul.hoffman@vpnc.org]
Sent: Monday, June 09, 2008 10:25 AM
To: Grewal, Ken; Tero Kivinen; Pasi.Eronen@nokia.com
Cc: ipsec@ietf.org
Subject: Re: [IPsec] First charter draft

This thread finally came back around to the subject line! :-)

At 9:55 AM -0700 6/9/08, Grewal, Ken wrote:
>I agree that a further discussion on this is useful to ensure the usage
>models and extensions are better understood by all, before dismissing
>the work item.

Pasi's original message on this thread said:

At 9:12 PM +0300 6/1/08, <Pasi.Eronen@nokia.com> wrote:
>Chartering this WG is not intended to have effect on documents that
>beyond the initial scope. In particular, work on IPsec extensions that
>are not included in this charter can happen as usual in other WGs (and
>there are currently several other WGs working on IPsec extensions; for
>example, BTNS and ROHC), or as individual submissions.

It is hard to read that paragraph as "dismissing" any work item.

--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec
--0-682683196-1213085697=:42697-- --===============0343852963== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============0343852963==-- From ipsec-bounces@ietf.org Tue Jun 10 05:48:40 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 39EB43A6918; Tue, 10 Jun 2008 05:48:40 -0700 (PDT) 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 D5D3E3A6918; Tue, 10 Jun 2008 05:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, 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 KOnpAzWExGMs; Tue, 10 Jun 2008 05:48:36 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id 42FEB3A68BD; Tue, 10 Jun 2008 05:48:33 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1K63HN-0002Dl-Ut; Tue, 10 Jun 2008 14:48:50 +0200 X-Hashcash: 1:20:080610:mext@ietf.org::1XHiXbQLG6GsfE95:0000AGdz X-Hashcash: 1:20:080610:ipsec@ietf.org::C8ChjT5ErotwvdBg:00029FY From: arno@natisbad.org (Arnaud Ebalard) To: IETF MEXT WG X-GnuPG-Key: 0x047A5026 Date: Tue, 10 Jun 2008 14:48:42 +0200 Message-ID: <87d4mp5uc5.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: IETF IPsec WG Subject: [IPsec] Clarifications on dynamic HoA assignment by IKE (RFC 4877 and 5026) 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: , Content-Type: multipart/mixed; boundary="===============1235527168==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1235527168== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Content-Transfer-Encoding: quoted-printable Hi, I just read again RFC 4877 and RFC 5026 (and related sections of RFC 4306) and I have questions. IPsec WG is in Cc; sorry if you receive the mail twice and also for its length. In RFC 4877, it is written that "the home agent and the mobile node MAY support remote configuration of the home address". This is specifically covered in Section 9 but there are related notes in other parts of the document. Simply put, my questions would be: "What are the *detailed* steps by which IKE negotiation will be *triggered* on the Mobile Node in the process of getting a HoA dynamically assigned? How is the address provided to the MIPv6 module?". More precisely, I'd like to clarify the following points: SPD entries provided in section 7.2.1 make use of home_address_1 which might not be available yet (at least on the mobile node). This is commented after the SPD entries: "In the examples shown above, the home address of the mobile node might not be available all the time. For instance, the mobile node might not have configured a home address yet. When the mobile node acquires a new home address, it must either add the address to the corresponding SPD entries or create the SPD entries for the home address." Associated questions are: o Which address should be used meanwhile (in the SPD entries on the MN, for instance)? o how will the IKE negotiation be triggered, i.e. by which packet? o how can the SPD entries be added afterwhile if they are supposed to trigger IKE negotiation? I think I have missed something in the reference documents because I am under the impression that *something* makes IKE start a negotiation without any SPD related event (like a packet matching a SP and asking for protection) to get a HoA, but I am unable to find what. Is it implicitly expected that the IKE daemon starts an IKE_AUTH exchange to grab a HoA on its own? What is controlled by MIPv6 / what is not? How? I'll appreciate some feedback on that. Now, regarding RFC 5026, there are 7 references to RFC 4877: the use of previous HoA assignement is also listed based on content of RFC 4877 and another mechanism (section 5.3.2, HoA Auto-Configuration by the Mobile Node) which allows the MN to get the prefix it should use to autoconfigure an address it will then send back to the HA. Like previous HoA assignment, the prefix is obtained using IKEv2 during IKE_AUTH exchange. Basically, I have the same questions as for dynamic HoA assignement above. How are things triggered? Who controls what? How is the synchronization between IKE and MIPv6 performed? In the end, after reading those 2 documents, I am under the impression (do not hesitate to correct me) that the MIPv6 process on the MN has the ability to *trigger* an IKE negotiation with the IKE daemon on its HA for the purpose of configuring its HoA. I am also under the impression that this neogiation is not the result of an SPD lookup indicating that a queued packet requires protection.=20 Then I looked at RFC 4306 to find some answers. There are some elements on the topic in Section 1.1.3, at the end of section 2.9, in section 2.19 and in section 3.15 but the scenario where IKE starts negotiation and gets the HoA on its own just looks odd. In RFC 3776 (for static and dynamic keying) and for statically assigned HoA in RFC 4877, MIPv6 module handles HoA, and IKE acts accordingly (yes, it needs some modification to bootstrap) but in the dynamic assignment case, the scenario is reversed and IKE starts and "configures" MIPv6 (at least for the HoA part). This is not explicitly stated (if my understanding and descriptions are correct) and the details are missing in associated document (AFAICT).=20=20 When reading RFC 4877 and RFC 5026, I was under the impression that MIPv6 and IKE are expected to be one unique entity. I wonder how it will be possible in that context to have separate IKEv2 and MIPv6 implementations interoperate on the same MN, HA or MR. If I missed some documents, don't hesitate to tell. Thanks, a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFITngwAlWVfAR6UCYRAhwtAJ96meg1qMHo83whhuSKCBnK0QnEYQCdGCgs I3qX1Ng6UOBQrF4VBsUpD/4= =JVoV -----END PGP SIGNATURE----- --=-=-=-- --===============1235527168== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============1235527168==-- From ipsec-bounces@ietf.org Tue Jun 10 10:15:02 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 922993A67F3; Tue, 10 Jun 2008 10:15:02 -0700 (PDT) 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 1FB343A67F3 for ; Tue, 10 Jun 2008 10:15:02 -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=[AWL=0.000, 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 4SWsPn0zmGBd for ; Tue, 10 Jun 2008 10:14:47 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id B1E193A67E2 for ; Tue, 10 Jun 2008 10:14:45 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.13.8/8.13.8) with ESMTP id m5A8WVmf003972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 10 Jun 2008 11:32:32 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.8/8.12.11) id m5A8WVPA029420; Tue, 10 Jun 2008 11:32:31 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18510.15391.118860.166483@fireball.kivinen.iki.fi> Date: Tue, 10 Jun 2008 11:32:31 +0300 From: Tero Kivinen To: "Grewal, Ken" In-Reply-To: References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com> <4848D0E7.4030306@checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 7 min Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com Subject: Re: [IPsec] First charter draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Grewal, Ken writes: > I totally agree that you still need stateful inspection, but this is a > decision prior to inspecting the packet - i.e. Can the firewall do > meaningful stateful inspection or is the data encrypted? What is the point of doing that deterministic inspection if the policy are going to follow is: Drop all encrypted packets. Drop all corrupted packets. Drop all packets not passing stateful inspection. Pass all packets passsing stateful inspection. If that is the policy then you can simply skip the drop all encrypted packets part and directly skip to the stateful inspection part. If the SPI is known you know the IV/ICV lengths are known, thus you can inspect the packet normally. If the SPI is not known, you do bit more of inspection for the first packet, i.e. you inspect the packet using the few possible IV/ICV length combinations and see which of them results valid IP packet which also passes the other stateful inspection checks (i.e. is part of existing TCP/IP flow, or is a SYN packet creating it from right direction etc). If you find the IV/ICV length combination that passes all those checks you add new state with SPI + IP addresses and those lengths to your state information table. If the packet cannot be parsed using any of the IV/ICV combinations you assume that either the packet is encrypted (and should be dropped), or it is corrupted (and should be dropped), or using so IV/ICV length combination which is not allowed (and should be dropped). As you can see all of those would result dropping of the packet, so you simply drop the packet. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 10 15:28:49 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B20E3A6AA7; Tue, 10 Jun 2008 15:28:49 -0700 (PDT) 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 4464E3A68A6 for ; Tue, 10 Jun 2008 15:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.389 X-Spam-Level: X-Spam-Status: No, score=-2.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 73cOUOJ40Rj6 for ; Tue, 10 Jun 2008 15:28:47 -0700 (PDT) Received: from an-out-0708.google.com (an-out-0708.google.com [209.85.132.246]) by core3.amsl.com (Postfix) with ESMTP id B926E3A6AE0 for ; Tue, 10 Jun 2008 15:28:46 -0700 (PDT) Received: by an-out-0708.google.com with SMTP id d18so1111353and.122 for ; Tue, 10 Jun 2008 15:29:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=zyQ0VfHH4KvHE0Hx2YRpPvFI46i/p6WYkYCmcX70/VU=; b=EDIMLpwoq9iFqqzGStl3a8AFma1cPctXqqucGiTFLNd+15rlHDtFPnfLc77ZAOI9od muAY0NPoGzV04N3SuXaC0YqavPRRtWh7vEZKpzSbZyfiyZz5DBjf4GMeb3//M9K4iZXQ V4P65bYQyaDpSvAgswy5fBP4NNLzvhz/CD+RA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=BpMZLXCSW+aFrgjbSagXv/t/1om3IsQIqQlKxTDXHocPGNpOQR3yM6Mt8hdsiogau+ arSAVjR8LNju9NFyVG/ODumVAopeVw1JqQXGR9/nRgj+b8P8SkwAvz0XifzkxO0CaiCI t+IM12NjJ8h9BlsEbiB4uMGc9xnVzTqdXXV50= Received: by 10.100.41.4 with SMTP id o4mr6364736ano.136.1213136945834; Tue, 10 Jun 2008 15:29:05 -0700 (PDT) Received: by 10.100.141.11 with HTTP; Tue, 10 Jun 2008 15:29:05 -0700 (PDT) Message-ID: Date: Tue, 10 Jun 2008 15:29:05 -0700 From: "fan zhao" To: "Arnaud Ebalard" In-Reply-To: <87d4mp5uc5.fsf@natisbad.org> MIME-Version: 1.0 Content-Disposition: inline References: <87d4mp5uc5.fsf@natisbad.org> Cc: IETF IPsec WG , IETF MEXT WG Subject: Re: [IPsec] Clarifications on dynamic HoA assignment by IKE (RFC 4877 and 5026) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Arnaud, IMO, before the MN gets a HoA, the corresponding SPD entry does not have the HoA. Such entry may contain the mobility header type or may be even not created until the HoA is allocated. The IKE can be triggered by the configuration/ selection of the mobility protocol to be used. Your impression is correct and I agree with you: the initialization of the MIP is embedded into the IKE and their logical functions are tightly correlated. Sincerely, fan On Tue, Jun 10, 2008 at 5:48 AM, Arnaud Ebalard wrote: > Hi, > > I just read again RFC 4877 and RFC 5026 (and related sections of RFC > 4306) and I have questions. IPsec WG is in Cc; sorry if you receive the > mail twice and also for its length. > > In RFC 4877, it is written that "the home agent and the mobile node MAY > support remote configuration of the home address". This is specifically > covered in Section 9 but there are related notes in other parts of the > document. > > Simply put, my questions would be: "What are the *detailed* steps by > which IKE negotiation will be *triggered* on the Mobile Node in the > process of getting a HoA dynamically assigned? How is the address > provided to the MIPv6 module?". > > More precisely, I'd like to clarify the following points: > > SPD entries provided in section 7.2.1 make use of home_address_1 which > might not be available yet (at least on the mobile node). This is > commented after the SPD entries: "In the examples shown above, the > home address of the mobile node might not be available all the time. > For instance, the mobile node might not have configured a home address > yet. When the mobile node acquires a new home address, it must either > add the address to the corresponding SPD entries or create the SPD > entries for the home address." Associated questions are: > > o Which address should be used meanwhile (in the SPD entries on the > MN, for instance)? > o how will the IKE negotiation be triggered, i.e. by which packet? > o how can the SPD entries be added afterwhile if they are supposed to > trigger IKE negotiation? > > I think I have missed something in the reference documents because I am > under the impression that *something* makes IKE start a negotiation > without any SPD related event (like a packet matching a SP and asking > for protection) to get a HoA, but I am unable to find what. Is it > implicitly expected that the IKE daemon starts an IKE_AUTH exchange to > grab a HoA on its own? What is controlled by MIPv6 / what is not? How? > I'll appreciate some feedback on that. > > > Now, regarding RFC 5026, there are 7 references to RFC 4877: the use > of previous HoA assignement is also listed based on content of RFC 4877 > and another mechanism (section 5.3.2, HoA Auto-Configuration by the > Mobile Node) which allows the MN to get the prefix it should use to > autoconfigure an address it will then send back to the HA. Like previous > HoA assignment, the prefix is obtained using IKEv2 during IKE_AUTH > exchange. Basically, I have the same questions as for dynamic HoA > assignement above. How are things triggered? Who controls what? How is > the synchronization between IKE and MIPv6 performed? > > > In the end, after reading those 2 documents, I am under the impression > (do not hesitate to correct me) that the MIPv6 process on the MN has the > ability to *trigger* an IKE negotiation with the IKE daemon on its HA > for the purpose of configuring its HoA. I am also under the impression > that this neogiation is not the result of an SPD lookup indicating that > a queued packet requires protection. > > Then I looked at RFC 4306 to find some answers. There are some elements > on the topic in Section 1.1.3, at the end of section 2.9, in section > 2.19 and in section 3.15 but the scenario where IKE starts negotiation > and gets the HoA on its own just looks odd. > > In RFC 3776 (for static and dynamic keying) and for statically assigned > HoA in RFC 4877, MIPv6 module handles HoA, and IKE acts accordingly > (yes, it needs some modification to bootstrap) but in the dynamic > assignment case, the scenario is reversed and IKE starts and > "configures" MIPv6 (at least for the HoA part). This is not explicitly > stated (if my understanding and descriptions are correct) and the > details are missing in associated document (AFAICT). > > When reading RFC 4877 and RFC 5026, I was under the impression that > MIPv6 and IKE are expected to be one unique entity. I wonder how it will > be possible in that context to have separate IKEv2 and MIPv6 > implementations interoperate on the same MN, HA or MR. > > If I missed some documents, don't hesitate to tell. > > Thanks, > > a+ > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 11 00:23:57 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD2073A67B4; Wed, 11 Jun 2008 00:23:57 -0700 (PDT) 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 4F2513A67B4; Wed, 11 Jun 2008 00:23:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.849 X-Spam-Level: X-Spam-Status: No, score=-2.849 tagged_above=-999 required=5 tests=[AWL=-0.250, 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 CAjB+z+KDVmv; Wed, 11 Jun 2008 00:23:55 -0700 (PDT) Received: from moog.chdir.org (moog.chdir.org [88.191.42.160]) by core3.amsl.com (Postfix) with ESMTP id CC4143A679F; Wed, 11 Jun 2008 00:23:51 -0700 (PDT) Received: from [2001:7a8:78df:2:20d:93ff:fe55:8f78] (helo=localhost.localdomain) by moog.chdir.org with esmtpsa (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.63) (envelope-from ) id 1K6Kgd-0006h1-Lq; Wed, 11 Jun 2008 09:24:03 +0200 X-Hashcash: 1:20:080611:francis.dupont@fdupont.fr::tAC9IoiAY9QkEfb4:0000000000000000000000000000000000000ZO4 X-Hashcash: 1:20:080611:vijay.devarapalli@azairenet.com::7SMWcy9LfHp8/IbV:000000000000000000000000000000EZI4 X-Hashcash: 1:20:080611:marcelo@it.uc3m.es::RUsgJu/V7vR0wiGz:00000000000000000000000000000000000000000004yUD X-Hashcash: 1:20:080611:julien.ietf@laposte.net::A+aq5EdFfrt5Pwpj:000000000000000000000000000000000000002nr0 From: arno@natisbad.org (Arnaud Ebalard) To: "fan zhao" References: <87d4mp5uc5.fsf@natisbad.org> X-GnuPG-Key: 0x047A5026 X-Hashcash: 1:20:080611:fanzhao828@gmail.com::PvLOXHKI2hBPPzk1:000000000000000000000000000000000000000001YEC X-Hashcash: 1:20:080611:ipsec@ietf.org::K0tINuPn8Lc1T1e6:0003XMH X-Hashcash: 1:20:080611:mext@ietf.org::39sagdw4yXgYaBxD:00004Nfy Date: Wed, 11 Jun 2008 09:23:55 +0200 Message-ID: <87iqwgtoxg.fsf@natisbad.org> User-Agent: Gnus/5.110009 (No Gnus v0.9) Emacs/22.2 (gnu/linux) MIME-Version: 1.0 Cc: Francis Dupont , IETF IPsec WG , Vijay Devarapalli , IETF MEXT WG , marcelo bagnulo braun , Julien Laganier Subject: Re: [IPsec] Clarifications on dynamic HoA assignment by IKE (RFC 4877 and 5026) 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: , Content-Type: multipart/mixed; boundary="===============1482041389==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1482041389== Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha1; protocol="application/pgp-signature" --=-=-= Hi, "fan zhao" writes: > Your impression is correct and I agree with you: the initialization of > the MIP is embedded into the IKE and their logical functions are > tightly correlated. If that is the case, this is IMHO a kind of regression compared to RFC 3776 which did not lead to such strong requirements. Of course, IKE module requires some changes to support mobility but requiring IKE to be implemented in MIPv6 module or the opposite looks like an issue. Francis, Vijeay, Marcelo, Julien, can you comment our understanding of RFC 4877 and RFC 5026 implications? In the end, can IKE module and MIPv6 module be implemented separately and how is that supposed to work? I have left my initial analysis below. >> I just read again RFC 4877 and RFC 5026 (and related sections of RFC >> 4306) and I have questions. IPsec WG is in Cc; sorry if you receive the >> mail twice and also for its length. >> >> In RFC 4877, it is written that "the home agent and the mobile node MAY >> support remote configuration of the home address". This is specifically >> covered in Section 9 but there are related notes in other parts of the >> document. >> >> Simply put, my questions would be: "What are the *detailed* steps by >> which IKE negotiation will be *triggered* on the Mobile Node in the >> process of getting a HoA dynamically assigned? How is the address >> provided to the MIPv6 module?". >> >> More precisely, I'd like to clarify the following points: >> >> SPD entries provided in section 7.2.1 make use of home_address_1 which >> might not be available yet (at least on the mobile node). This is >> commented after the SPD entries: "In the examples shown above, the >> home address of the mobile node might not be available all the time. >> For instance, the mobile node might not have configured a home address >> yet. When the mobile node acquires a new home address, it must either >> add the address to the corresponding SPD entries or create the SPD >> entries for the home address." Associated questions are: >> >> o Which address should be used meanwhile (in the SPD entries on the >> MN, for instance)? >> o how will the IKE negotiation be triggered, i.e. by which packet? >> o how can the SPD entries be added afterwhile if they are supposed to >> trigger IKE negotiation? >> >> I think I have missed something in the reference documents because I am >> under the impression that *something* makes IKE start a negotiation >> without any SPD related event (like a packet matching a SP and asking >> for protection) to get a HoA, but I am unable to find what. Is it >> implicitly expected that the IKE daemon starts an IKE_AUTH exchange to >> grab a HoA on its own? What is controlled by MIPv6 / what is not? How? >> I'll appreciate some feedback on that. >> >> >> Now, regarding RFC 5026, there are 7 references to RFC 4877: the use >> of previous HoA assignement is also listed based on content of RFC 4877 >> and another mechanism (section 5.3.2, HoA Auto-Configuration by the >> Mobile Node) which allows the MN to get the prefix it should use to >> autoconfigure an address it will then send back to the HA. Like previous >> HoA assignment, the prefix is obtained using IKEv2 during IKE_AUTH >> exchange. Basically, I have the same questions as for dynamic HoA >> assignement above. How are things triggered? Who controls what? How is >> the synchronization between IKE and MIPv6 performed? >> >> >> In the end, after reading those 2 documents, I am under the impression >> (do not hesitate to correct me) that the MIPv6 process on the MN has the >> ability to *trigger* an IKE negotiation with the IKE daemon on its HA >> for the purpose of configuring its HoA. I am also under the impression >> that this neogiation is not the result of an SPD lookup indicating that >> a queued packet requires protection. >> >> Then I looked at RFC 4306 to find some answers. There are some elements >> on the topic in Section 1.1.3, at the end of section 2.9, in section >> 2.19 and in section 3.15 but the scenario where IKE starts negotiation >> and gets the HoA on its own just looks odd. >> >> In RFC 3776 (for static and dynamic keying) and for statically assigned >> HoA in RFC 4877, MIPv6 module handles HoA, and IKE acts accordingly >> (yes, it needs some modification to bootstrap) but in the dynamic >> assignment case, the scenario is reversed and IKE starts and >> "configures" MIPv6 (at least for the HoA part). This is not explicitly >> stated (if my understanding and descriptions are correct) and the >> details are missing in associated document (AFAICT). >> >> When reading RFC 4877 and RFC 5026, I was under the impression that >> MIPv6 and IKE are expected to be one unique entity. I wonder how it will >> be possible in that context to have separate IKEv2 and MIPv6 >> implementations interoperate on the same MN, HA or MR. >> >> If I missed some documents, don't hesitate to tell. >> >> Thanks, >> >> a+ a+ --=-=-= Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFIT32RAlWVfAR6UCYRAkr+AJ97WRoilCCM5agGrsvSDNPX0Q3ZRgCdE0cy 6iuQcrxFNvLM2WI3ffhSMBo= =7rcK -----END PGP SIGNATURE----- --=-=-=-- --===============1482041389== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============1482041389==-- From ipsec-bounces@ietf.org Wed Jun 11 00:56:31 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 818C83A68E8; Wed, 11 Jun 2008 00:56:31 -0700 (PDT) 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 40CEF3A6845; Wed, 11 Jun 2008 00:56:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 bHDZa1FYCFXw; Wed, 11 Jun 2008 00:56:28 -0700 (PDT) Received: from ws000774.tietoenator.com (ws000774.tietoenator.com [193.12.181.129]) by core3.amsl.com (Postfix) with ESMTP id 9EB173A6835; Wed, 11 Jun 2008 00:56:27 -0700 (PDT) X-AuditID: c10cb581-00000efc000004dc-c5-484f853f6e05 Received: from camaro.eu.tieto.com ([192.176.143.43]) by ws000774.tietoenator.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Jun 2008 09:56:47 +0200 Received: from corvette.eu.tieto.com ([192.176.143.143]) by camaro.eu.tieto.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jun 2008 09:56:48 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 11 Jun 2008 09:56:47 +0200 Message-ID: In-Reply-To: <87d4mp5uc5.fsf@natisbad.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] Clarifications on dynamic HoA assignment by IKE (RFC 4877and 5026) thread-index: AcjK+G/bHVgdcOk1TNSO//tJbG8UmQAoAolg References: <87d4mp5uc5.fsf@natisbad.org> From: To: , X-OriginalArrivalTime: 11 Jun 2008 07:56:48.0264 (UTC) FILETIME=[B33CE880:01C8CB98] X-Brightmail-Tracker: AAAAAA== Cc: IPsec@ietf.org Subject: Re: [IPsec] Clarifications on dynamic HoA assignment by IKE (RFC 4877and 5026) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Some coordination between IKE and MIP is required, but in my view, IKE and MIP can be implemented separately. Assume a node has a single mobile application/process, which requires uninterrupted IP connectivity. As long as this application is not started, all other applications just use the addresses as available, and have to give up/restart when addresses are removed. When the mobile application is to be started, whoever starts the mobile application has to ensure a mobile address is available; if no mobile address is available, it must be created (bootstrapping), namely by running IKE from one of the available addresses on one of the interfaces towards the home agent, and if from IKE is received an address in a CFG payload which differs from the available address used, then a BU/BA exchange to set up the tunnels. Thus, someone has to coordinate IKE and MIP, but they can be implemented as separate modules. Christian > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Arnaud Ebalard > Sent: 10. juni 2008 14:49 > To: IETF MEXT WG > Cc: IETF IPsec WG > Subject: [IPsec] Clarifications on dynamic HoA assignment by > IKE (RFC 4877and 5026) > > Hi, > > I just read again RFC 4877 and RFC 5026 (and related sections of RFC > 4306) and I have questions. IPsec WG is in Cc; sorry if you > receive the mail twice and also for its length. > > In RFC 4877, it is written that "the home agent and the > mobile node MAY support remote configuration of the home > address". This is specifically covered in Section 9 but there > are related notes in other parts of the document. > > Simply put, my questions would be: "What are the *detailed* > steps by which IKE negotiation will be *triggered* on the > Mobile Node in the process of getting a HoA dynamically > assigned? How is the address provided to the MIPv6 module?". > > More precisely, I'd like to clarify the following points: > > SPD entries provided in section 7.2.1 make use of > home_address_1 which might not be available yet (at least on > the mobile node). This is commented after the SPD entries: > "In the examples shown above, the home address of the mobile > node might not be available all the time. > For instance, the mobile node might not have configured a > home address yet. When the mobile node acquires a new home > address, it must either add the address to the corresponding > SPD entries or create the SPD entries for the home address." > Associated questions are: > > o Which address should be used meanwhile (in the SPD entries on the > MN, for instance)? > o how will the IKE negotiation be triggered, i.e. by which packet? > o how can the SPD entries be added afterwhile if they are supposed to > trigger IKE negotiation? > > I think I have missed something in the reference documents > because I am under the impression that *something* makes IKE > start a negotiation without any SPD related event (like a > packet matching a SP and asking for protection) to get a HoA, > but I am unable to find what. Is it implicitly expected that > the IKE daemon starts an IKE_AUTH exchange to grab a HoA on > its own? What is controlled by MIPv6 / what is not? How? > I'll appreciate some feedback on that. > > > Now, regarding RFC 5026, there are 7 references to RFC 4877: > the use of previous HoA assignement is also listed based on > content of RFC 4877 and another mechanism (section 5.3.2, HoA > Auto-Configuration by the Mobile Node) which allows the MN to > get the prefix it should use to autoconfigure an address it > will then send back to the HA. Like previous HoA assignment, > the prefix is obtained using IKEv2 during IKE_AUTH exchange. > Basically, I have the same questions as for dynamic HoA > assignement above. How are things triggered? Who controls > what? How is the synchronization between IKE and MIPv6 performed? > > > In the end, after reading those 2 documents, I am under the > impression (do not hesitate to correct me) that the MIPv6 > process on the MN has the ability to *trigger* an IKE > negotiation with the IKE daemon on its HA for the purpose of > configuring its HoA. I am also under the impression that this > neogiation is not the result of an SPD lookup indicating that > a queued packet requires protection. > > Then I looked at RFC 4306 to find some answers. There are > some elements on the topic in Section 1.1.3, at the end of > section 2.9, in section > 2.19 and in section 3.15 but the scenario where IKE starts > negotiation and gets the HoA on its own just looks odd. > > In RFC 3776 (for static and dynamic keying) and for > statically assigned HoA in RFC 4877, MIPv6 module handles > HoA, and IKE acts accordingly (yes, it needs some > modification to bootstrap) but in the dynamic assignment > case, the scenario is reversed and IKE starts and > "configures" MIPv6 (at least for the HoA part). This is not > explicitly stated (if my understanding and descriptions are > correct) and the details are missing in associated document > (AFAICT). > > When reading RFC 4877 and RFC 5026, I was under the impression that > MIPv6 and IKE are expected to be one unique entity. I wonder > how it will be possible in that context to have separate > IKEv2 and MIPv6 implementations interoperate on the same MN, HA or MR. > > If I missed some documents, don't hesitate to tell. > > Thanks, > > a+ > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 11 03:26:03 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 214663A6A1F; Wed, 11 Jun 2008 03:26:03 -0700 (PDT) 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 C445D3A6A1F for ; Wed, 11 Jun 2008 03:26:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.474 X-Spam-Level: X-Spam-Status: No, score=-6.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 DH8q6DZ1yAs8 for ; Wed, 11 Jun 2008 03:25:55 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 674523A68C8 for ; Wed, 11 Jun 2008 03:25:54 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5BAQAi8013942; Wed, 11 Jun 2008 13:26:14 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Jun 2008 13:26:03 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Jun 2008 13:26:02 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 11 Jun 2008 13:26:06 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72DF195F@vaebe104.NOE.Nokia.com> In-Reply-To: <18509.12328.427110.610804@fireball.kivinen.iki.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] First charter draft Thread-Index: AcjKNNXTqeSPmovbTm2VJx1/YbhiqgBdUFEw References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com><1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com><18504.59167.826685.44808@fireball.kivinen.iki.fi><1696498986EFEC4D9153717DA325CB72D54D1F@vaebe104.NOE.Nokia.com> <18509.12328.427110.610804@fireball.kivinen.iki.fi> From: To: X-OriginalArrivalTime: 11 Jun 2008 10:26:02.0935 (UTC) FILETIME=[8CA34470:01C8CBAD] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] First charter draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Tero Kivinen wrote: > > To me, it seems GRE key would not be significantly different from > > other selectors (ICMP type/code, TCP port, etc.) -- you need to > > consider fragments, yes, but probably don't need to do anything > > significantly different from what was done for other protocols. > > It has significant difference to the other selectors, as it is > designed to hide the real traffic selectors which are inside the GRE > encapsulated packet, i.e. it will cause packets to bypass the IPsec > checks. This could be acceptable and useful, but it is quite big > difference to the other selectors. Of course you can tunnel > IP-packets over http to get the same effect, but that is bit > different case for architecture point of view. Architecturally, it's not that different to tunneling IP-over-UDP (which is common in various IETF specs). In those cases, IPsec does not inspect the inner packet, but only the outer header. > > > Also I am not sure why different gre key values needs to be put > > > on the separate SA. I have not really seen good reason why this > > > is needed. > > > > Apparently, other folks have scenarios where they'd like to do this. > > Those two GRE / IPsec draft I read didn't give any good reason for > the need for separate SAs. > > We have used the example for port selectors that you protect SMTP > with 3DES and all other traffic with AES, but I think that is > actually very weak reason. The biggest reason we have for traffic > selectors is the filtering capabilities, i.e.we can say only HTTP > traffic or only SMTP traffic, not the capability of using different > algorithms for different traffic. That reason is not there in the > GRE as we do not check inside the GRE packets. The drafts talk about various types of tunnels between routers (operated by a carrier), where different tunnels carry traffic for different customers. Presumably, the distinction here would not be SMTP vs. HTTP, but "my (company's) traffic" vs. "someone else's traffic". I do agree that for me (or any single entity), having a policy to protect SMTP with 3DES and all other traffic with AES sounds a bit far-fetched, but different companies having different policies sounds much more plausible to me. > Anyways I still think that GRE case do need more discussion before it > should be accepted. For example neither of the drafts I read is really > about just using the GRE key as traffic selector. I agree that the scope of the current drafts is slightly different; that's why the proposed text didn't list either of them as starting point, and explicitly said that other GRE-related work is beyond the scope. However, to make your objection actionable, could you slightly clarify what kind of outcome you'd wish to get from having more discussion? (It's quite obvious that not everyone using IPsec needs this particular extension -- but this is the case for *all* extensions we're considering -- so unanimous agreement that this is needed is not a reasonable goal.) > Perhaps we should add those in the charter, but make the text so that > it is very clear that not making a document about that item is also > completely acceptable outcome from the charter item, and doing so > would be considered as success for the WG (i.e it has successfully > removed one item from its charter by deciding not to do that item, > thus can recharter and take something else instead). Well, with any work item, we always have the possibility that people lose interest (or move elsewhere for other reasons) -- I wouldn't perhaps call it "success", but certainly items the WG decides to stop working on can be removed from the charter (especially since there aren't much dependencies between the work items in the proposed charter). Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 11 03:40:04 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 76C4A3A6824; Wed, 11 Jun 2008 03:40:04 -0700 (PDT) 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 0E9AF3A6781 for ; Wed, 11 Jun 2008 03:40:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.482 X-Spam-Level: X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 R4T5BekTox9Q for ; Wed, 11 Jun 2008 03:40:01 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 481EE3A63EC for ; Wed, 11 Jun 2008 03:40:01 -0700 (PDT) Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5BAdisd030280; Wed, 11 Jun 2008 13:40:08 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Jun 2008 13:39:51 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 11 Jun 2008 13:39:51 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 11 Jun 2008 13:39:57 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72DF198E@vaebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] First charter draft Thread-Index: AcjH8JfZArea9xL9Sl29Bie8NE3/mQDvc6oA References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com> From: To: X-OriginalArrivalTime: 11 Jun 2008 10:39:51.0529 (UTC) FILETIME=[7A84AD90:01C8CBAF] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: Re: [IPsec] First charter draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Stephen, I fully agree that neither draft-grewal-ipsec-traffic-visibility nor draft-hoffman-esp-null-protocol is complete as is. The charter draft intentionally listed both of them as starting points to allow te WG to decide the technical details (and I think the mailing list discussions earlier also came up with some other alternatives, not documented in either draft). Best regards, Pasi > -----Original Message----- > From: ext Stephen Kent [mailto:kent@bbn.com] > Sent: 06 June, 2008 19:11 > To: Eronen Pasi (Nokia-NRC/Helsinki) > Cc: ipsec@ietf.org > Subject: Re: [IPsec] First charter draft > > Pasi, > > The I-D draft-grewal-ipsec-traffic-visibility has a number of > presentation problems. The text refers to IVs and ICVs, without > noting that only for combined mode algorithms would an IV be used in > the context of null-encryption. Moreover, combined mode algorithm > support was introduced only in ESPv2 (RFC 4303), but the I-D cites > only ESP v1 (RFC 2406). Similarly, the text cites 2301, not 4301. In > 2301, AH support is mandated, and so one could argue that in an > enterprise context where intermediate systems need to examine packet > contents, the enterprise could just mandate use of AH. In 4301, > support for AH is no longer mandated, and so the encapsulation > mechanism proposed in this I-D makes more sense. Thus I think that > 4301 is the appropriate cite here. Also, IKEv2 is cited, and it is > used only in the 4301 context, so ... The I-D doesn't explain how an > intermediate system will determine the end of the real payload, to > enable it to "further parse the packet to extract the data portion." > That system needs to know the pad length. True, this can be > determined by working back from the ICV length and the next header > field, but the text fails to mention that. Moreover, if you have to > do that processing, you could grab the next header field then, and > not have it in the UDP encapsulation header. Finally, the explanation > how to validate a UDP-encapsulated ESP-NULL packet, in the face of > possible port conflicts appears to be underspecified. One can argue > that if there is a viable heuristic to deal with this case, an > intermediate system could perform these checks on ESP traffic, cache > the SA info (by S/D host addresses and SPI values) and avoid the need > for the encapsulation proposed here! This seems especially true given > that the scope of this I-D appears to be traffic within an enterprise > net, not the more general case of any intermediate system along a > path, perhaps at the boundary between an enterprise net and the > public internet. > > In contrast, the draft-hoffman-esp-null-protocol I-D is very simple > and does not impose the burden of an extra encapsulation layer. > However it consumes two protocol numbers from a space that has > traditionally been consider relatively scarce. Also, these two > numbers might not suffice if additional combined mode algorithms, > with different IV lengths, are adopted in the future. This I-D needs > more details discussing exactly how an intermediate system will > perform the necessary packet inspection. Finally, because this I-D > tries to address the more general case of an intermediate system > along a path (anywhere?), it require more discussion of what set of > policies make sense in the more general context. (I think this is > needed to that folks don't jump to inaccurate conclusions about what > such a facility will buy them.) > > So, like Tero, I am not convinced that this topic should be a high > priority for the new IPsec WG. I have not yet looked at the GRE > proposal, but I do not that defining additional selector values may > pose problems for folks who have designed hardware that relies on the > fact that the set of selectors has remained fairly static for many > years. Also, I agree with Tero that we need to understand very > thoroughly why there is a need to use additional data as traffic > selectors, so that we don't set a precedent that will haunt us in the > future. If we create a number of application-specific variants of > IPsec for different contexts, we run the risk of undermining > interoperability. > > Steve > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 11 04:49:50 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B08233A6AE0; Wed, 11 Jun 2008 04:49:50 -0700 (PDT) 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 0C2193A6AE0 for ; Wed, 11 Jun 2008 04:49:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.414 X-Spam-Level: X-Spam-Status: No, score=-2.414 tagged_above=-999 required=5 tests=[AWL=0.185, 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 8xyRHAIGWWzL for ; Wed, 11 Jun 2008 04:49:49 -0700 (PDT) Received: from ik-out-1112.google.com (ik-out-1112.google.com [66.249.90.180]) by core3.amsl.com (Postfix) with ESMTP id B87BB3A6AA1 for ; Wed, 11 Jun 2008 04:49:48 -0700 (PDT) Received: by ik-out-1112.google.com with SMTP id c28so2143183ika.5 for ; Wed, 11 Jun 2008 04:50:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:sender; bh=tXQcH1Lg1rlEmLlMVxfEsa33/QYkstdZToi7Ztmkre0=; b=Clsp0UZrP3chuux1hrl1CI4gE09qhlbPjoLdUf2s6YcZOSzjzbO61Cd0Brkov6QWwc sviW7jpGOru1/cjD6sETy8Qvk2ZSN6PODZYCESb2oHKsBRtld9M+tx/0Md13peybA74m dfF2HQfg26LqsWisnLapwDk1TFfDSjL6QkBCU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id:sender; b=KufTm9FOaQ85ETlJbwNfgmK9aRs5WKjSsGaSZgZnDTtFgb0v3kQ2XdVnmcsdtnS0rp 4BoO2EJR6/4IpBeRxGHWPSeYDBgQd/ZRuvI71Eh//eXHAmU21a8ytBeS1sraAQwd920N 4Lrvvo372uG1kFKZUfzbFK/NeObBphyymsTDI= Received: by 10.210.54.15 with SMTP id c15mr5081106eba.128.1213185009113; Wed, 11 Jun 2008 04:50:09 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id u14sm1792939gvf.6.2008.06.11.04.50.07 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 11 Jun 2008 04:50:08 -0700 (PDT) From: Julien Laganier To: ipsec@ietf.org Date: Wed, 11 Jun 2008 13:50:08 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com> <18509.12328.427110.610804@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB72DF195F@vaebe104.NOE.Nokia.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB72DF195F@vaebe104.NOE.Nokia.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200806111350.08219.julien.IETF@laposte.net> Cc: Pasi.Eronen@nokia.com, kivinen@iki.fi Subject: Re: [IPsec] First charter draft 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: , Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Wednesday 11 June 2008, Pasi.Eronen@nokia.com wrote: > Tero Kivinen wrote: > > > To me, it seems GRE key would not be significantly different from > > > other selectors (ICMP type/code, TCP port, etc.) -- you need to > > > consider fragments, yes, but probably don't need to do anything > > > significantly different from what was done for other protocols. > > > > It has significant difference to the other selectors, as it is > > designed to hide the real traffic selectors which are inside the > > GRE encapsulated packet, i.e. it will cause packets to bypass the > > IPsec checks. This could be acceptable and useful, but it is quite > > big difference to the other selectors. Of course you can tunnel > > IP-packets over http to get the same effect, but that is bit > > different case for architecture point of view. > > Architecturally, it's not that different to tunneling IP-over-UDP > (which is common in various IETF specs). =A0In those cases, IPsec does > not inspect the inner packet, but only the outer header. FWIW, it's the same when IPsec transport mode protection is applied to = an IP-within-IP tunnel -- IPsec does not inspect the inner header, only = the outer. --julien _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 11 09:07:34 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BFD183A6878; Wed, 11 Jun 2008 09:07:34 -0700 (PDT) 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 7D1AA3A6886 for ; Wed, 11 Jun 2008 09:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 B-BK3T9enOQ2 for ; Wed, 11 Jun 2008 09:07:29 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 1D3693A6878 for ; Wed, 11 Jun 2008 09:07:29 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id C71F7294003; Wed, 11 Jun 2008 19:07:50 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 08FCB294001; Wed, 11 Jun 2008 19:07:50 +0300 (IDT) Received: from [91.90.139.89] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m5BG7njI024682; Wed, 11 Jun 2008 19:07:49 +0300 (IDT) Message-ID: <484FF855.8020206@checkpoint.com> Date: Wed, 11 Jun 2008 19:07:49 +0300 From: Yaron Sheffer User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com><1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com><18504.59167.826685.44808@fireball.kivinen.iki.fi><1696498986EFEC4D9153717DA325CB72D54D1F@vaebe104.NOE.Nokia.com> <18509.12328.427110.610804@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB72DF195F@vaebe104.NOE.Nokia.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB72DF195F@vaebe104.NOE.Nokia.com> Cc: ipsec@ietf.org, kivinen@iki.fi Subject: Re: [IPsec] First charter draft 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: , Content-Type: multipart/mixed; boundary="===============0992076262==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0992076262== Content-Type: multipart/alternative; boundary="------------050203010503000705010105" This is a multi-part message in MIME format. --------------050203010503000705010105 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Pasi, IMHO we are having exactly the right kind of charter discussion, so we can decide as a group whether either or both work items should go into the charter with the goal of becoming an RFC. We have two questions: 1. Is {GRE traffic selectors, ESP-NULL marking} technically sound and provides improved security for real-life usage? 2. Given the group's workload, is there a large enough constituency for each of the work items, to see it through until it is published? I cannot comment on GRE. But for ESP-NULL, we have the strange situation where we do have a constituency, but there are people (including myself) expressing doubt on the technical soundness. I'd prefer to have a conclusive discussion now, rather than putting either of the work items "tentatively" into the charter. As Paul noted, we will not be "dismissing" any of them no matter what we decide. On the other hand, I would be happy to have presentations on non-chartered (or not-yet-chartered) work items in Dublin. Thanks, Yaron > > >> Perhaps we should add those in the charter, but make the text so that >> it is very clear that not making a document about that item is also >> completely acceptable outcome from the charter item, and doing so >> would be considered as success for the WG (i.e it has successfully >> removed one item from its charter by deciding not to do that item, >> thus can recharter and take something else instead). >> > > Well, with any work item, we always have the possibility that people > lose interest (or move elsewhere for other reasons) -- I wouldn't > perhaps call it "success", but certainly items the WG decides to stop > working on can be removed from the charter (especially since there > aren't much dependencies between the work items in the proposed > charter). > > Best regards, > Pasi > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. > > --------------050203010503000705010105 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Pasi,

IMHO we are having exactly the right kind of charter discussion, so we can decide as a group whether either or both work items should go into the charter with the goal of becoming an RFC. We have two questions:
1. Is {GRE traffic selectors, ESP-NULL marking} technically sound and provides improved security for real-life usage?
2. Given the group's workload, is there a large enough constituency for each of the work items, to see it through until it is published?

I cannot comment on GRE. But for ESP-NULL, we have the strange situation where we do have a constituency, but there are people (including myself) expressing doubt on the technical soundness.

I'd prefer to have a conclusive discussion now, rather than putting either of the work items "tentatively" into the charter. As Paul noted, we will not be "dismissing" any of them no matter what we decide.

On the other hand, I would be happy to have presentations on non-chartered (or not-yet-chartered) work items in Dublin.

Thanks,
    Yaron
<snip>
  
Perhaps we should add those in the charter, but make the text so that
it is very clear that not making a document about that item is also
completely acceptable outcome from the charter item, and doing so
would be considered as success for the WG (i.e it has successfully
removed one item from its charter by deciding not to do that item,
thus can recharter and take something else instead).
    

Well, with any work item, we always have the possibility that people
lose interest (or move elsewhere for other reasons) -- I wouldn't
perhaps call it "success", but certainly items the WG decides to stop
working on can be removed from the charter (especially since there
aren't much dependencies between the work items in the proposed
charter).

Best regards,
Pasi
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec

Scanned by Check Point Total Security Gateway.
--------------050203010503000705010105-- --===============0992076262== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============0992076262==-- From ipsec-bounces@ietf.org Wed Jun 11 10:09:14 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C8853A6813; Wed, 11 Jun 2008 10:09:14 -0700 (PDT) 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 902DB3A6845 for ; Wed, 11 Jun 2008 10:09:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 s0NqP51YRf0Z for ; Wed, 11 Jun 2008 10:09:08 -0700 (PDT) Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by core3.amsl.com (Postfix) with ESMTP id 4FC743A6813 for ; Wed, 11 Jun 2008 10:09:08 -0700 (PDT) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 11 Jun 2008 02:07:02 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.27,625,1204531200"; d="scan'208,217";a="393696016" Received: from fmsmsx334.amr.corp.intel.com ([132.233.42.1]) by orsmga001.jf.intel.com with ESMTP; 11 Jun 2008 10:09:10 -0700 Received: from fmsmsx881.amr.corp.intel.com ([10.19.19.13]) by fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 11 Jun 2008 10:09:21 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 11 Jun 2008 10:09:20 -0700 Message-ID: In-Reply-To: <484FF855.8020206@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] First charter draft Thread-Index: AcjL3VdeYB/zzXiuTLGhUL6QJRpxYQAB27KQ References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com><1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com><18504.59167.826685.44808@fireball.kivinen.iki.fi><1696498986EFEC4D9153717DA325CB72D54D1F@vaebe104.NOE.Nokia.com> <18509.12328.427110.610804@fireball.kivinen.iki.fi><1696498986EFEC4D9153717DA325CB72DF195F@vaebe104.NOE.Nokia.com> <484FF855.8020206@checkpoint.com> From: "Grewal, Ken" To: "Yaron Sheffer" , X-OriginalArrivalTime: 11 Jun 2008 17:09:21.0493 (UTC) FILETIME=[E41A3050:01C8CBE5] Cc: ipsec@ietf.org, kivinen@iki.fi Subject: Re: [IPsec] First charter draft 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: , Content-Type: multipart/mixed; boundary="===============0855696764==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0855696764== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C8CBE5.E3F446E4" This is a multi-part message in MIME format. ------_=_NextPart_001_01C8CBE5.E3F446E4 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi Yaron,=20 As we do have a constituency/interest, this is one of the reasons to follow-up in the WG charter and have an active debate on alternative viable solutions to find the right one.=20 Separately, I am happy to present some of the usage models / details in Dublin, assuming I can get a timeslot. =20 Thanks,=20 - Ken =20 ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer Sent: Wednesday, June 11, 2008 9:08 AM To: Pasi.Eronen@nokia.com Cc: ipsec@ietf.org; kivinen@iki.fi Subject: Re: [IPsec] First charter draft =20 Hi Pasi, IMHO we are having exactly the right kind of charter discussion, so we can decide as a group whether either or both work items should go into the charter with the goal of becoming an RFC. We have two questions: 1. Is {GRE traffic selectors, ESP-NULL marking} technically sound and provides improved security for real-life usage? 2. Given the group's workload, is there a large enough constituency for each of the work items, to see it through until it is published? I cannot comment on GRE. But for ESP-NULL, we have the strange situation where we do have a constituency, but there are people (including myself) expressing doubt on the technical soundness. I'd prefer to have a conclusive discussion now, rather than putting either of the work items "tentatively" into the charter. As Paul noted, we will not be "dismissing" any of them no matter what we decide. On the other hand, I would be happy to have presentations on non-chartered (or not-yet-chartered) work items in Dublin. Thanks, Yaron =20 Perhaps we should add those in the charter, but make the text so that it is very clear that not making a document about that item is also completely acceptable outcome from the charter item, and doing so would be considered as success for the WG (i.e it has successfully removed one item from its charter by deciding not to do that item, thus can recharter and take something else instead). =20 =20 Well, with any work item, we always have the possibility that people lose interest (or move elsewhere for other reasons) -- I wouldn't perhaps call it "success", but certainly items the WG decides to stop working on can be removed from the charter (especially since there aren't much dependencies between the work items in the proposed charter). =20 Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec =20 Scanned by Check Point Total Security Gateway. =20 =20 ------_=_NextPart_001_01C8CBE5.E3F446E4 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Hi Yaron, =

As we do have a = constituency/interest, this is one of the reasons to follow-up in the WG charter and have an = active debate on alternative viable solutions to find the right one. =

Separately, I am happy to present = some of the usage models / details in Dublin, assuming I can get a timeslot.

 

Thanks,

- Ken

 

From: ipsec-bounces@ietf.org = [mailto:ipsec-bounces@ietf.org] On Behalf Of Yaron Sheffer
Sent: Wednesday, June 11, = 2008 9:08 AM
To: = Pasi.Eronen@nokia.com
Cc: ipsec@ietf.org; = kivinen@iki.fi
Subject: Re: [IPsec] = First charter draft

 

Hi Pasi,

IMHO we are having exactly the right kind of charter discussion, so we = can decide as a group whether either or both work items should go into the = charter with the goal of becoming an RFC. We have two questions:
1. Is {GRE traffic selectors, ESP-NULL marking} technically sound and = provides improved security for real-life usage?
2. Given the group's workload, is there a large enough constituency for = each of the work items, to see it through until it is published?

I cannot comment on GRE. But for ESP-NULL, we have the strange situation = where we do have a constituency, but there are people (including myself) = expressing doubt on the technical soundness.

I'd prefer to have a conclusive discussion now, rather than putting = either of the work items "tentatively" into the charter. As Paul noted, = we will not be "dismissing" any of them no matter what we decide.

On the other hand, I would be happy to have presentations on = non-chartered (or not-yet-chartered) work items in Dublin.

Thanks,
    Yaron

<snip>
  
Perhaps we should add those in the charter, =
but make the text so that
it is very clear that not making a document =
about that item is also
completely acceptable outcome from the =
charter item, and doing so
would be considered as success for the WG =
(i.e it has successfully
removed one item from its charter by deciding =
not to do that item,
thus can recharter and take something else =
instead).
    =

 
Well, with any work item, we always have the =
possibility that people
lose interest (or move elsewhere for other =
reasons) -- I wouldn't
perhaps call it "success", but =
certainly items the WG decides to =
stop
working on can be removed from the charter =
(especially since there
aren't much dependencies between the work =
items in the proposed
charter).
<=
font
size=3D2 color=3Dblack face=3D"Courier New"> 
Best =
regards,
Pasi
______________________________________________=
_
IPsec mailing =
list
IPsec@ietf.org
https://www.ietf.org=
/mailman/listinfo/ipsec
 
Scanned by Check Point Total Security =
Gateway.
 
 
------_=_NextPart_001_01C8CBE5.E3F446E4-- --===============0855696764== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============0855696764==-- From ipsec-bounces@ietf.org Wed Jun 11 22:14:50 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA3FF3A689B; Wed, 11 Jun 2008 22:14:50 -0700 (PDT) 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 932FC3A689B for ; Wed, 11 Jun 2008 22:14:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 rduHF77VqkGt for ; Wed, 11 Jun 2008 22:14:48 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 1C8BD3A67AA for ; Wed, 11 Jun 2008 22:14:48 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id A8466294002; Thu, 12 Jun 2008 08:15:14 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id C1B7D294001; Thu, 12 Jun 2008 08:13:17 +0300 (IDT) Received: from localhost (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with SMTP id m5C5DHjJ004628; Thu, 12 Jun 2008 08:13:17 +0300 (IDT) Message-Id: From: Yoav Nir To: Yaron Sheffer In-Reply-To: <484FF855.8020206@checkpoint.com> Mime-Version: 1.0 (Apple Message framework v924) Date: Thu, 12 Jun 2008 08:12:50 +0300 References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com><1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com><18504.59167.826685.44808@fireball.kivinen.iki.fi><1696498986EFEC4D9153717DA325CB72D54D1F@vaebe104.NOE.Nokia.com> <18509.12328.427110.610804@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB72DF195F@vaebe104.NOE.Nokia.com> <484FF855.8020206@checkpoint.com> X-Mailer: Apple Mail (2.924) Cc: ipsec@ietf.org, "Pasi.Eronen@nokia.com>" Subject: Re: [IPsec] First charter draft 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: , Content-Type: multipart/mixed; boundary="===============0931487751==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0931487751== Content-Type: multipart/alternative; boundary=Apple-Mail-1-864652651 --Apple-Mail-1-864652651 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit With GRE we have another kind of strange situation. The work item that is now proposed is very different from the work item that the people who suggested GRE had in mind - it's more limited. So the question about GRE is whether there is enough of a consistuency for the amended version. As for presentations, I would be happy to present QCD, and I'd like to hear one about IKE-over-TCP or IPsec-over-TCP. On Jun 11, 2008, at 7:07 PM, Yaron Sheffer wrote: > Hi Pasi, > > IMHO we are having exactly the right kind of charter discussion, so > we can decide as a group whether either or both work items should go > into the charter with the goal of becoming an RFC. We have two > questions: > 1. Is {GRE traffic selectors, ESP-NULL marking} technically sound > and provides improved security for real-life usage? > 2. Given the group's workload, is there a large enough constituency > for each of the work items, to see it through until it is published? > > I cannot comment on GRE. But for ESP-NULL, we have the strange > situation where we do have a constituency, but there are people > (including myself) expressing doubt on the technical soundness. > > I'd prefer to have a conclusive discussion now, rather than putting > either of the work items "tentatively" into the charter. As Paul > noted, we will not be "dismissing" any of them no matter what we > decide. > > On the other hand, I would be happy to have presentations on non- > chartered (or not-yet-chartered) work items in Dublin. > > Thanks, > Yaron >> >> >>> Perhaps we should add those in the charter, but make the text so >>> that >>> it is very clear that not making a document about that item is also >>> completely acceptable outcome from the charter item, and doing so >>> would be considered as success for the WG (i.e it has successfully >>> removed one item from its charter by deciding not to do that item, >>> thus can recharter and take something else instead). >>> >> Well, with any work item, we always have the possibility that people >> lose interest (or move elsewhere for other reasons) -- I wouldn't >> perhaps call it "success", but certainly items the WG decides to stop >> working on can be removed from the charter (especially since there >> aren't much dependencies between the work items in the proposed >> charter). >> >> Best regards, >> Pasi >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> Scanned by Check Point Total Security Gateway. >> >> > > > Scanned by Check Point Total Security Gateway. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec --Apple-Mail-1-864652651 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable With GRE we have another kind = of strange situation.  The work item that is now proposed is very = different from the work item that the people who suggested GRE had in = mind - it's more limited. 

So the question about = GRE is whether there is enough of a consistuency for the amended = version.

As for presentations, I would be happy = to present QCD, and I'd like to hear one about IKE-over-TCP or = IPsec-over-TCP.

On Jun 11, 2008, at 7:07 PM, = Yaron Sheffer wrote:

Hi = Pasi,

IMHO we are having exactly the right kind of charter = discussion, so we can decide as a group whether either or both work = items should go into the charter with the goal of becoming an RFC. We = have two questions:
1. Is {GRE traffic selectors, ESP-NULL marking} = technically sound and provides improved security for real-life = usage?
2. Given the group's workload, is there a large enough = constituency for each of the work items, to see it through until it is = published?

I cannot comment on GRE. But for ESP-NULL, we have = the strange situation where we do have a constituency, but there are = people (including myself) expressing doubt on the technical = soundness.

I'd prefer to have a conclusive discussion now, = rather than putting either of the work items "tentatively" into the = charter. As Paul noted, we will not be "dismissing" any of them no = matter what we decide.

On the other hand, I would be happy to = have presentations on non-chartered (or not-yet-chartered) work items in = Dublin.

Thanks,
    Yaron
<snip>
  
Perhaps we should =
add those in the charter, but make the text so that
it is very clear that not making a document about that item is also
completely acceptable outcome from the charter item, and doing so
would be considered as success for the WG (i.e it has successfully
removed one item from its charter by deciding not to do that item,
thus can recharter and take something else instead).
    
Well, with any work =
item, we always have the possibility that people
lose interest (or move elsewhere for other reasons) -- I wouldn't
perhaps call it "success", but certainly items the WG decides to stop
working on can be removed from the charter (especially since there
aren't much dependencies between the work items in the proposed
charter).

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

Scanned by Check Point Total Security Gateway.


Scanned by Check Point Total Security = Gateway.

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

= --Apple-Mail-1-864652651-- --===============0931487751== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============0931487751==-- From ipsec-bounces@ietf.org Thu Jun 12 01:05:17 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F057A3A6852; Thu, 12 Jun 2008 01:05:16 -0700 (PDT) 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 C1CB93A6852 for ; Thu, 12 Jun 2008 01:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.419 X-Spam-Level: X-Spam-Status: No, score=-2.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 EgFrdMzI2VHU for ; Thu, 12 Jun 2008 01:05:14 -0700 (PDT) Received: from hu-out-0506.google.com (hu-out-0506.google.com [72.14.214.225]) by core3.amsl.com (Postfix) with ESMTP id 3D74B3A6843 for ; Thu, 12 Jun 2008 01:05:14 -0700 (PDT) Received: by hu-out-0506.google.com with SMTP id 24so5055158hud.14 for ; Thu, 12 Jun 2008 01:05:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:sender; bh=hD/oU8Lea5EkeImxRtXkUYciScejVdd0qJNTxjwtgXA=; b=nx3if7dYZudswLvhwdg7TV4adFw7uJ2qEla/FY3nIkPVNxMQPsrq15afGU5yaQnDuO qeljna0GLGVym7AN/fAJ2EBe+6kMGnPYZPdSftkU38lfuJZ22TD150u3xonku/DTVvYK fpeWYhjwq+PeVaf8wWO/QzR5RDaFGfpS7CUPQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id:sender; b=x3glEpqoocaQ6Swle6zgljD85rreXXabvOZIQfjlns2dg8GXkRnpyU6JvchJwzUBrt BbjFVkRhTYXV2NfvePT0D6ZWfsTUsbR/drQBpNIsijqzs/72e/hXnd2P9bGEMP3YYhrL yU5XCmMnr0w2gbnrSjnD6vHCzGckQo9QRfVBk= Received: by 10.210.51.18 with SMTP id y18mr806254eby.160.1213257937092; Thu, 12 Jun 2008 01:05:37 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id g11sm1675198gve.8.2008.06.12.01.05.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 12 Jun 2008 01:05:36 -0700 (PDT) From: Julien Laganier To: ipsec@ietf.org Date: Thu, 12 Jun 2008 10:05:34 +0200 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com> In-Reply-To: <1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200806121005.35774.julien.IETF@laposte.net> Cc: Pasi.Eronen@nokia.com, kivinen@iki.fi Subject: [IPsec] GRE key Traffic Selector (Was: First charter draft) 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: , Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Thursday 05 June 2008, Pasi.Eronen@nokia.com wrote: > However, I'd like to get some more opinions about these work > items, especially from people who participated in the discussions > about "ESP NULL traffic visibility" earlier. > > Here's a short summary about these proposed work items: > > o =A0A standards-track extension to IKEv2 to support using the "Key" > =A0 =A0field of Generic Routing Encapsulation (GRE) packets, specified > =A0 =A0in RFC 2890, as a traffic selector (in similar fashion as TCP/UDP > =A0 =A0port number or ICMP type/code fields). This allows different GRE > =A0 =A0traffic flows to be mapped to different IPsec SAs. =A0Any further > =A0 =A0extensions related to the use of IPsec with GRE are beyond the > =A0 =A0scope of this work item. A last observation on this work item. I think the analogy between TCP/UDP port number and ICMP type/code = fields on one hand, and the GRE key on the other hand, isn't reflective = of their different nature. ICMP type/code are assigned via IANA and thus given an ICMP type/code = pair in a traffic selector there's global knowledge of what kind of = traffic is matched, e.g. if any two entities negotiate an ICMPv6 = traffic selector for type 1, they both know they're negotiating a = traffic selector for ICMPv6 Destination Unreachable packets. The same goes with well known and registered port numbers. If a client = and a server negotiate a traffic selector for source client, = destination server on port 80 they both known they're talking about = HTTP traffic sent by the client to the server. In other words, a TCP/UDP port number and ICMP type/code traffic = selector does allow to select a specific *kind* of traffic. For GRE keys the situation is IMHO entirely different since a GRE key = has no significance beyond a local arrangement between a pair of nodes = and doesn't say anything about the kind of traffic that travel marked = with a given GRE key. Given that, the receiver has to trust entirely = the sender to encapsulate with a given GRE key a kind of traffic that = is appropriate for the IPsec protection afforded by that GRE key -- the = receiver can't perform any sort of tunnel exit check to verify that = inbound GRE traffic is what was expected. In other words, a GRE key traffic selector does not allow to select a = specific *kind* of traffic. Thus I question the value of using the GRE key as a traffic selector. = >From a security perspective I am under the impression that the same = level of access control is provided by simply using the GRE protocol = number as a traffic selector. --julien _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jun 12 03:00:53 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E4283A69EC; Thu, 12 Jun 2008 03:00:53 -0700 (PDT) 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 A165A3A69EC for ; Thu, 12 Jun 2008 03:00:52 -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=[AWL=0.000, 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 mXzMLoNKc5z3 for ; Thu, 12 Jun 2008 03:00:51 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.190]) by core3.amsl.com (Postfix) with ESMTP id 474E13A69E4 for ; Thu, 12 Jun 2008 03:00:51 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so1526109tib.25 for ; Thu, 12 Jun 2008 03:01:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=yAPW6r65UkaoQbNjO7sdOWiFGlXcIAQtiGfGMy04f3Q=; b=fHcSLEwXnA70fE6SaeSAlJMSkaLudhTSrVwSGtNaeeN1M1eIXbPjC+zZed5z06d/SJ o6oxh1G5Cen0EFzlklUbuOcq/oEPb77DP5d94+I+W6SpHylynBoiNvh1BCvP0GPnpPXj Kp2mFHKvCTF2HNc4bcxSlbIjhpleeD8hc3z/o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=KtDKP33C27XqnAVLuv4wWc3tgQJyAf1616M0vpKYgiY+17byZs0kmIF+Z6FE0LSoIc AwE63a7ZNeQEtmx//nzr2E2xDQBx6e25pambXuVlUSYZc1RKTX5xRbyq3/joZj6WOGTz U+Y9ACTSp3Ee/1KUKK1om+p1ng5TmCIa5tMEg= Received: by 10.110.40.8 with SMTP id n8mr624756tin.7.1213264876451; Thu, 12 Jun 2008 03:01:16 -0700 (PDT) Received: by 10.110.53.11 with HTTP; Thu, 12 Jun 2008 03:01:16 -0700 (PDT) Message-ID: <1d38a3350806120301j79df2b39sd3f79288b650fc2f@mail.gmail.com> Date: Thu, 12 Jun 2008 18:01:16 +0800 From: "Hui Deng" To: "Julien Laganier" In-Reply-To: <200806121005.35774.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Disposition: inline References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com> <200806121005.35774.julien.IETF@laposte.net> Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com, kivinen@iki.fi Subject: Re: [IPsec] GRE key Traffic Selector (Was: First charter draft) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, Julien, Thanks for your insight analysis, you are correct, GRE key doesn't identify any kind of traffic, it is more service level consideration, this is what we are going to do it. Thanks again. -Hui 2008/6/12 Julien Laganier : > On Thursday 05 June 2008, Pasi.Eronen@nokia.com wrote: >> However, I'd like to get some more opinions about these work >> items, especially from people who participated in the discussions >> about "ESP NULL traffic visibility" earlier. >> >> Here's a short summary about these proposed work items: >> >> o A standards-track extension to IKEv2 to support using the "Key" >> field of Generic Routing Encapsulation (GRE) packets, specified >> in RFC 2890, as a traffic selector (in similar fashion as TCP/UDP >> port number or ICMP type/code fields). This allows different GRE >> traffic flows to be mapped to different IPsec SAs. Any further >> extensions related to the use of IPsec with GRE are beyond the >> scope of this work item. > > A last observation on this work item. > > I think the analogy between TCP/UDP port number and ICMP type/code > fields on one hand, and the GRE key on the other hand, isn't reflective > of their different nature. > > ICMP type/code are assigned via IANA and thus given an ICMP type/code > pair in a traffic selector there's global knowledge of what kind of > traffic is matched, e.g. if any two entities negotiate an ICMPv6 > traffic selector for type 1, they both know they're negotiating a > traffic selector for ICMPv6 Destination Unreachable packets. > > The same goes with well known and registered port numbers. If a client > and a server negotiate a traffic selector for source client, > destination server on port 80 they both known they're talking about > HTTP traffic sent by the client to the server. > > In other words, a TCP/UDP port number and ICMP type/code traffic > selector does allow to select a specific *kind* of traffic. > > For GRE keys the situation is IMHO entirely different since a GRE key > has no significance beyond a local arrangement between a pair of nodes > and doesn't say anything about the kind of traffic that travel marked > with a given GRE key. Given that, the receiver has to trust entirely > the sender to encapsulate with a given GRE key a kind of traffic that > is appropriate for the IPsec protection afforded by that GRE key -- the > receiver can't perform any sort of tunnel exit check to verify that > inbound GRE traffic is what was expected. > > In other words, a GRE key traffic selector does not allow to select a > specific *kind* of traffic. > > Thus I question the value of using the GRE key as a traffic selector. > From a security perspective I am under the impression that the same > level of access control is provided by simply using the GRE protocol > number as a traffic selector. > > --julien > > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jun 12 05:51:21 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 755693A67E2; Thu, 12 Jun 2008 05:51:21 -0700 (PDT) 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 76FED3A695C for ; Thu, 12 Jun 2008 05:51:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.43 X-Spam-Level: X-Spam-Status: No, score=-2.43 tagged_above=-999 required=5 tests=[AWL=0.169, 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 E4XJqhKzFpSN for ; Thu, 12 Jun 2008 05:51:19 -0700 (PDT) Received: from hu-out-0506.google.com (hu-out-0506.google.com [72.14.214.231]) by core3.amsl.com (Postfix) with ESMTP id 26DB53A67B7 for ; Thu, 12 Jun 2008 05:51:18 -0700 (PDT) Received: by hu-out-0506.google.com with SMTP id 24so5169761hud.14 for ; Thu, 12 Jun 2008 05:51:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :user-agent:cc:references:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:message-id:sender; bh=6NROEKVe52HZw/ieQW9cPQcmMwj4inXaLXkE3avzAo4=; b=W5bm/NHcfds1C+S8wctOmOaskcdNNghBxZS+Q8RcF0Ov5TbzU35+LH2If9IsY4G9oc oJV1QMw0Vcfn/eM78lG4tUepwGTpPjGOOET7drklX0UsJdDiNVdg76mVqMG9foDJOKOw 1+iuFbYIEtcLjW8SgyW4dN8pdTvShmUev5gEQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=from:to:subject:date:user-agent:cc:references:in-reply-to :mime-version:content-type:content-transfer-encoding :content-disposition:message-id:sender; b=cX4P416/tCtis3ZtJiJYIuQ8tTNIEQhrCR85pOQAMyDT/FSZoATDoX4xNpxoEqjR9+ TBCT3NtMdwBiWxoKfY6WK2gTUoUsrqm9VDWeeBBCeegijCbBUPylU3gSR5xSrkK8iguQ CDcTOmUnq+hCT2BMThmK+2Es/RlhLtbb9M6ng= Received: by 10.210.50.5 with SMTP id x5mr1106872ebx.117.1213275105202; Thu, 12 Jun 2008 05:51:45 -0700 (PDT) Received: from klee.local ( [212.119.9.178]) by mx.google.com with ESMTPS id g11sm2174835gve.8.2008.06.12.05.51.43 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 12 Jun 2008 05:51:44 -0700 (PDT) From: Julien Laganier To: Tero Kivinen Date: Thu, 12 Jun 2008 14:51:41 +0200 User-Agent: KMail/1.9.9 References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com> <200806111350.08219.julien.IETF@laposte.net> <18513.5968.284329.88435@fireball.kivinen.iki.fi> In-Reply-To: <18513.5968.284329.88435@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline Message-Id: <200806121451.41738.julien.IETF@laposte.net> Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com Subject: Re: [IPsec] First charter draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Thursday 12 June 2008, Tero Kivinen wrote: > Julien Laganier writes: > > FWIW, it's the same when IPsec transport mode protection is applied > > to an IP-within-IP tunnel -- IPsec does not inspect the inner > > header, only the outer. > > Yes, and RFC4301 has warning about that: Yes, tunneled traffic escape IPsec access control. The same applies if one configures IPsec transport mode to protect traffic sent from SRC to DST and protocol number GRE. And adding the GRE key as a traffic selector would not change the situation, as I'm arguing in another note on the topic. --julien > --------------------------------------------------------------------- >- 4.1. Definition and Scope > ... > ... To clarify, the use of > transport mode by an intermediate system (e.g., a security > gateway) is permitted only when applied to packets whose source > address (for outbound packets) or destination address (for inbound > packets) is an address belonging to the intermediate system itself. > The access control functions that are an important part of IPsec are > significantly limited in this context, as they cannot be applied to > the end-to-end headers of the packets that traverse a transport mode > SA used in this fashion. Thus, this way of using transport mode > should be evaluated carefully before being employed in a specific > context. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jun 12 07:37:03 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 81E6A3A6AF2; Thu, 12 Jun 2008 07:37:03 -0700 (PDT) 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 003123A6AF2 for ; Thu, 12 Jun 2008 07:37:03 -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=[AWL=0.000, 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 aOCiuA2K2g+1 for ; Thu, 12 Jun 2008 07:36:59 -0700 (PDT) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id 33C6F3A6999 for ; Thu, 12 Jun 2008 07:36:59 -0700 (PDT) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1K6nvY-000245-3g; Thu, 12 Jun 2008 10:37:24 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200806121005.35774.julien.IETF@laposte.net> References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com> <200806121005.35774.julien.IETF@laposte.net> Date: Thu, 12 Jun 2008 10:36:15 -0400 To: Julien Laganier From: Stephen Kent Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com, kivinen@iki.fi Subject: Re: [IPsec] GRE key Traffic Selector (Was: First charter draft) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Julien, I still have not found time to review the GRE key proposal, but your comments were very helpful to me. The fact that thus value does not have a globally-defined semantics makes it less appropriate as a traffic selector, in my opinion. As you noted, it is no to analogous to the use of ports, protocol, and ICMP type/code values in the SPD. Steve _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jun 12 08:06:36 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1941E3A6834; Thu, 12 Jun 2008 08:06:36 -0700 (PDT) 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 405E53A6834 for ; Thu, 12 Jun 2008 08:06:35 -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=[AWL=0.001, 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 d8EvfAnW02KB for ; Thu, 12 Jun 2008 08:06:34 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 2568C3A67F7 for ; Thu, 12 Jun 2008 08:06:34 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 5BE58294009; Thu, 12 Jun 2008 18:06:58 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 80A3D294001; Thu, 12 Jun 2008 18:06:57 +0300 (IDT) Received: from [91.90.139.89] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m5CF6ujI004627; Thu, 12 Jun 2008 18:06:56 +0300 (IDT) Message-ID: <48513B8F.4030606@checkpoint.com> Date: Thu, 12 Jun 2008 18:06:55 +0300 From: Yaron Sheffer User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) MIME-Version: 1.0 To: Stephen Kent References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com> <200806121005.35774.julien.IETF@laposte.net> In-Reply-To: Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com, kivinen@iki.fi, Julien Laganier Subject: Re: [IPsec] GRE key Traffic Selector (Was: First charter draft) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Steve, in a managed-security setting, it seems reasonable to have different security policies, and separate Security Associations, for the different customers' traffic. Even though both may be running the same type of traffic. I understand that this is one of the use cases for the GRE draft. Thanks, Yaron Stephen Kent wrote: > Julien, > > I still have not found time to review the GRE key proposal, but your > comments were very helpful to me. The fact that thus value does not > have a globally-defined semantics makes it less appropriate as a > traffic selector, in my opinion. As you noted, it is no to analogous > to the use of ports, protocol, and ICMP type/code values in the SPD. > > Steve > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > Scanned by Check Point Total Security Gateway. > > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jun 12 08:13:46 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51B393A6834; Thu, 12 Jun 2008 08:13:46 -0700 (PDT) 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 A2F333A6834 for ; Thu, 12 Jun 2008 08:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 zJ-noUG-grc6 for ; Thu, 12 Jun 2008 08:13:44 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 113EE3A67F7 for ; Thu, 12 Jun 2008 08:13:43 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 19B5A294009; Thu, 12 Jun 2008 18:14:12 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 3EED3294001; Thu, 12 Jun 2008 18:14:11 +0300 (IDT) Received: from [172.31.24.139] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id m5CFE9jI008087; Thu, 12 Jun 2008 18:14:10 +0300 (IDT) Message-Id: <0B9C800E-4E08-4841-90C2-8FE74B784B4B@checkpoint.com> From: Yoav Nir To: Julien Laganier In-Reply-To: <200806121005.35774.julien.IETF@laposte.net> Mime-Version: 1.0 (Apple Message framework v924) Date: Thu, 12 Jun 2008 18:14:08 +0300 References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com> <200806121005.35774.julien.IETF@laposte.net> X-Mailer: Apple Mail (2.924) Cc: ipsec@ietf.org Subject: Re: [IPsec] GRE key Traffic Selector (Was: First charter draft) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Jun 12, 2008, at 11:05 AM, Julien Laganier wrote: > > The same goes with well known and registered port numbers. If a client > and a server negotiate a traffic selector for source client, > destination server on port 80 they both known they're talking about > HTTP traffic sent by the client to the server. > > In other words, a TCP/UDP port number and ICMP type/code traffic > selector does allow to select a specific *kind* of traffic. > > For GRE keys the situation is IMHO entirely different since a GRE key > has no significance beyond a local arrangement between a pair of nodes > and doesn't say anything about the kind of traffic that travel marked > with a given GRE key. Given that, the receiver has to trust entirely > the sender to encapsulate with a given GRE key a kind of traffic that > is appropriate for the IPsec protection afforded by that GRE key -- > the > receiver can't perform any sort of tunnel exit check to verify that > inbound GRE traffic is what was expected. > > In other words, a GRE key traffic selector does not allow to select a > specific *kind* of traffic. > > Thus I question the value of using the GRE key as a traffic selector. > From a security perspective I am under the impression that the same > level of access control is provided by simply using the GRE protocol > number as a traffic selector. > > --julien Negotiating port 80 doesn't really tell you that it's going to be HTTP in there, because lots of "firewall-traversing" applications like web telephony and instant messaging do the "everything over port 80" thing to get through firewalls. When we configure an SPD entry for port 80 (and certain addresses) we rely on the servers at those addresses being real web servers, or else we have some kind of firewall the deeply inspects the traffic to make sure it's web, not Skype. The same is true for GRE. If we have a local policy that GRE traffic marked with a certain key is one kind of traffic, than we can either trust the endpoints to enforce it, or use firewalls to make sure. I don't see a great difference in this case between a local policy and a policy that's specified in IANA registries. Neither offers real security. _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jun 12 12:39:01 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C0F753A691F; Thu, 12 Jun 2008 12:39:01 -0700 (PDT) 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 118033A691F for ; Thu, 12 Jun 2008 12:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.508 X-Spam-Level: X-Spam-Status: No, score=-6.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 yQ30exEakIj3 for ; Thu, 12 Jun 2008 12:39:00 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id D33FE3A67AE for ; Thu, 12 Jun 2008 12:38:59 -0700 (PDT) Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id m5CJdA6H026747; Thu, 12 Jun 2008 22:39:24 +0300 Received: from vaebh103.NOE.Nokia.com ([10.160.244.24]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Jun 2008 22:37:52 +0300 Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by vaebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 12 Jun 2008 22:37:52 +0300 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Thu, 12 Jun 2008 22:37:51 +0300 Message-ID: <1696498986EFEC4D9153717DA325CB72E49B18@vaebe104.NOE.Nokia.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: GRE key Traffic Selector (Was: First charter draft) Thread-Index: AcjMS08jfO9A8EDHQm+nTcD/bDk1uAAdrsOQ References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com><1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com><18504.59167.826685.44808@fireball.kivinen.iki.fi><1696498986EFEC4D9153717DA325CB72D54D1F@vaebe104.NOE.Nokia.com> <18509.12328.427110.610804@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB72DF195F@vaebe104.NOE.Nokia.com> <484FF855.8020206@checkpoint.com> From: To: X-OriginalArrivalTime: 12 Jun 2008 19:37:52.0055 (UTC) FILETIME=[CD9FCC70:01C8CCC3] X-Nokia-AV: Clean Cc: ipsec@ietf.org Subject: [IPsec] GRE key Traffic Selector (Was: First charter draft) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I agree that the work item description sent earlier is *significantly* different from the two individual drafts related to this topic. Several folks have also expressed major concerns with those drafts, and it's not quite clear whether those concerns apply to this part or not. Stephen also raised the question about what fields are architecturally suitable to be used as traffic selectors, and the implementation impact for hardware IPSec implementations. Given this, I'm getting the impression that this work item probably isn't yet mature enough for us to say "yes, this is a good idea, let's do it".... Best regards, Pasi > -----Original Message----- > From: ext Yoav Nir [mailto:ynir@checkpoint.com] > Sent: 12 June, 2008 08:13 > To: Yaron Sheffer > Cc: Eronen Pasi (Nokia-NRC/Helsinki); ipsec@ietf.org > Subject: Re: [IPsec] First charter draft > > With GRE we have another kind of strange situation. The work item > that is now proposed is very different from the work item that the > people who suggested GRE had in mind - it's more limited. > > So the question about GRE is whether there is enough of a > consistuency for the amended version. > > As for presentations, I would be happy to present QCD, and I'd like > to hear one about IKE-over-TCP or IPsec-over-TCP. > > On Jun 11, 2008, at 7:07 PM, Yaron Sheffer wrote: > > > Hi Pasi, > > > > IMHO we are having exactly the right kind of charter discussion, > > so we can decide as a group whether either or both work items > > should go into the charter with the goal of becoming an RFC. We > > have two questions: 1. Is {GRE traffic selectors, ESP-NULL > > marking} technically sound and provides improved security for > > real-life usage? 2. Given the group's workload, is there a large > > enough constituency for each of the work items, to see it through > > until it is published? > > > > I cannot comment on GRE. But for ESP-NULL, we have the strange > > situation where we do have a constituency, but there are people > > (including myself) expressing doubt on the technical soundness. > > > > I'd prefer to have a conclusive discussion now, rather than > > putting either of the work items "tentatively" into the > > charter. As Paul noted, we will not be "dismissing" any of them no > > matter what we decide. > > > > On the other hand, I would be happy to have presentations on > > non-chartered (or not-yet-chartered) work items in Dublin. > > > > Thanks, > > Yaron _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 13 04:49:55 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBE4D3A682A; Fri, 13 Jun 2008 04:49:55 -0700 (PDT) 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 7F1E53A6881 for ; Fri, 13 Jun 2008 04:49:54 -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=[AWL=0.000, 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 qfIy-HzkiHsV for ; Fri, 13 Jun 2008 04:49:45 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 0FEAE3A682A for ; Fri, 13 Jun 2008 04:49:44 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.13.8/8.13.8) with ESMTP id m5CCQf5l022869 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2008 15:26:41 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.8/8.12.11) id m5CCQcQE017247; Thu, 12 Jun 2008 15:26:38 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18513.5630.730704.57085@fireball.kivinen.iki.fi> Date: Thu, 12 Jun 2008 15:26:38 +0300 From: Tero Kivinen To: In-Reply-To: <1696498986EFEC4D9153717DA325CB72DF195F@vaebe104.NOE.Nokia.com> References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com> <18504.59167.826685.44808@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB72D54D1F@vaebe104.NOE.Nokia.com> <18509.12328.427110.610804@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB72DF195F@vaebe104.NOE.Nokia.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 15 min X-Total-Time: 14 min Cc: ipsec@ietf.org Subject: Re: [IPsec] First charter draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Pasi.Eronen@nokia.com writes: > The drafts talk about various types of tunnels between routers > (operated by a carrier), where different tunnels carry traffic for > different customers. Presumably, the distinction here would not be > SMTP vs. HTTP, but "my (company's) traffic" vs. "someone else's > traffic". To get any real benefits for the traffic separation it would be much better to use separate authentication information for the different virtual IPsec links too, i.e. use separate IKE SA for each company. That would also allow setting of the required authentication material to only those devices which really need it. > I do agree that for me (or any single entity), having a policy to > protect SMTP with 3DES and all other traffic with AES sounds a bit > far-fetched, but different companies having different policies sounds > much more plausible to me. In most cases those companies then have different policies for the IKE SA traffic too, i.e. what Diffie-Hellman groups to use, what authentication method to use and so on, thus making separate IKE SA + IPsec SA for each company. That would also allow both ends to really know from the authentication that this IPsec SA belongs to the company X as the IKE SA was created using company X authentication information. > However, to make your objection actionable, could you slightly clarify > what kind of outcome you'd wish to get from having more discussion? I would like to really see that the architectural affects of the GRE tunneling (and ESP-NULL marking) are considered, and my current take is that unless someone really makes some new better reasons why they cannot be done with the current already standardized methods we would be better to not to make new protocols or change protocols for them. > (It's quite obvious that not everyone using IPsec needs this > particular extension -- but this is the case for *all* extensions > we're considering -- so unanimous agreement that this is needed is > not a reasonable goal.) I do not think we want to repeat the mistake we did for the traffic selectors with port and protocol numbers (i.e. overlapping traffic selectors and decorrelation and so on). One of the things we MUST make sure is that the gre keys are expressed as ranges, as that is required for the decorrelating them (i.e. if host has policy saying GRE key x MUST use AES, and all other GRE keys must use 3DES, we need GRE key ranges to express the all other GRE keys except key x). We did make mistake in that for the protocol field already (which is single field, not range). > Well, with any work item, we always have the possibility that people > lose interest (or move elsewhere for other reasons) -- I wouldn't > perhaps call it "success", but certainly items the WG decides to stop > working on can be removed from the charter (especially since there > aren't much dependencies between the work items in the proposed > charter). It might be good idea to have one milestone where the WG decides whether it will consider this item as such that needs to be processed forward. I.e. "adopt some draft as WG draft for this item or drop the whole item from charter" milestone. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 13 04:49:56 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 514FA3A6953; Fri, 13 Jun 2008 04:49:56 -0700 (PDT) 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 4622C3A6810 for ; Fri, 13 Jun 2008 04:49:54 -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 pDZPizti8p1j for ; Fri, 13 Jun 2008 04:49:47 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 6879A3A6881 for ; Fri, 13 Jun 2008 04:49:46 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.13.8/8.13.8) with ESMTP id m5CCWG05020768 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 12 Jun 2008 15:32:16 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.8/8.12.11) id m5CCWGif021386; Thu, 12 Jun 2008 15:32:16 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18513.5968.284329.88435@fireball.kivinen.iki.fi> Date: Thu, 12 Jun 2008 15:32:16 +0300 From: Tero Kivinen To: Julien Laganier In-Reply-To: <200806111350.08219.julien.IETF@laposte.net> References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com> <18509.12328.427110.610804@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB72DF195F@vaebe104.NOE.Nokia.com> <200806111350.08219.julien.IETF@laposte.net> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 4 min X-Total-Time: 4 min Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com Subject: Re: [IPsec] First charter draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Julien Laganier writes: > FWIW, it's the same when IPsec transport mode protection is applied to > an IP-within-IP tunnel -- IPsec does not inspect the inner header, only > the outer. Yes, and RFC4301 has warning about that: ---------------------------------------------------------------------- 4.1. Definition and Scope ... ... To clarify, the use of transport mode by an intermediate system (e.g., a security gateway) is permitted only when applied to packets whose source address (for outbound packets) or destination address (for inbound packets) is an address belonging to the intermediate system itself. The access control functions that are an important part of IPsec are significantly limited in this context, as they cannot be applied to the end-to-end headers of the packets that traverse a transport mode SA used in this fashion. Thus, this way of using transport mode should be evaluated carefully before being employed in a specific context. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 13 07:30:50 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0FAF53A693A; Fri, 13 Jun 2008 07:30:50 -0700 (PDT) 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 834333A693A for ; Fri, 13 Jun 2008 07:30:49 -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=[AWL=0.000, 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 3hE5bA98DYAp for ; Fri, 13 Jun 2008 07:30:48 -0700 (PDT) Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by core3.amsl.com (Postfix) with ESMTP id 8A62C3A676A for ; Fri, 13 Jun 2008 07:30:48 -0700 (PDT) Received: from dhcp89-089-071.bbn.com ([128.89.89.71]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1K7AJB-00014R-4n; Fri, 13 Jun 2008 10:31:17 -0400 Mime-Version: 1.0 Message-Id: Date: Fri, 13 Jun 2008 10:24:55 -0400 To: From: Stephen Kent Cc: ipsec@ietf.org Subject: [IPsec] multi-subscriber use of Ipsec 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Pasi, Reading Tero's note from yesterday I was reminded that we specifically introduced the notion of multiple SPDs to accommodate this situation. Specificallty, we note that outbound traffic may use the (physical or logical) interface via which it was received to select the appropriate SPD. This is step 1 of outbound processing, in section 5.1 of 4301. This suggests that using the GRE key as a logical interface ID (to select an appropriate SPD) would be one way to separate traffic for different subscribers, consistent with the current architecture. Steve _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 13 08:21:22 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D98FD3A6969; Fri, 13 Jun 2008 08:21:22 -0700 (PDT) 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 AB9743A6825 for ; Fri, 13 Jun 2008 08:21:21 -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=[AWL=0.000, 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 DGRzd343FJJZ for ; Fri, 13 Jun 2008 08:21:17 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.184]) by core3.amsl.com (Postfix) with ESMTP id 6EBC03A6969 for ; Fri, 13 Jun 2008 08:21:17 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so1925459tib.25 for ; Fri, 13 Jun 2008 08:21:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=lUIRI4JiY47C5jkqg2Hw//waidc9EojTQ6scRntgu70=; b=l9MtrCBmCNU1l51YUTpCrjqgq1IKjYGemLKttpDi8ZJ+d2hY+CJXohStOjrPCYWH3W xDp2UHkgLnKXWRTD0AywwBpdnga9z2vjfzgQqkS4unA/u86tWCLbH31fnNZZWfTfGESm cmEj08N2IvbLGDzEsGR3nY+qjRF5PDRViDgC8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=ewWhfvnfVWVHrgvu8Mdd0l2cEuNhGx1lY20hpKTOyvqG9xB93q10lNDKgvUphIVIcC b60pjzvqgIj0BiGwi1NBP8GoMOYZ7VMKQVlsJJs8F4x5A4QM0fYTjc60AMgkA+7vrePK gWnepgAqN1+EZS8lF4DTQfN6JDeD2J/l1rCUw= Received: by 10.110.70.17 with SMTP id s17mr1786736tia.55.1213370508208; Fri, 13 Jun 2008 08:21:48 -0700 (PDT) Received: by 10.110.53.11 with HTTP; Fri, 13 Jun 2008 08:21:48 -0700 (PDT) Message-ID: <1d38a3350806130821j56c1fa1ewbe66226958cc129d@mail.gmail.com> Date: Fri, 13 Jun 2008 23:21:48 +0800 From: "Hui Deng" To: "Julien Laganier" In-Reply-To: <200806121451.41738.julien.IETF@laposte.net> MIME-Version: 1.0 Content-Disposition: inline References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com> <200806111350.08219.julien.IETF@laposte.net> <18513.5968.284329.88435@fireball.kivinen.iki.fi> <200806121451.41738.julien.IETF@laposte.net> Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com, Tero Kivinen Subject: Re: [IPsec] First charter draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Dear Julien, Thanks for your comments, see inline. 2008/6/12 Julien Laganier : > On Thursday 12 June 2008, Tero Kivinen wrote: >> Julien Laganier writes: >> > FWIW, it's the same when IPsec transport mode protection is applied >> > to an IP-within-IP tunnel -- IPsec does not inspect the inner >> > header, only the outer. >> >> Yes, and RFC4301 has warning about that: > > Yes, tunneled traffic escape IPsec access control. The same applies if > one configures IPsec transport mode to protect traffic sent from SRC to > DST and protocol number GRE. And adding the GRE key as a traffic > selector would not change the situation, as I'm arguing in another note > on the topic. Here GRE key has been used for some special purpose, the incentive will be more than protection of GRE protocol. thanks again. -Hui _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 13 08:24:48 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 65A703A6825; Fri, 13 Jun 2008 08:24:48 -0700 (PDT) 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 6E8043A6825 for ; Fri, 13 Jun 2008 08:24:46 -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=[AWL=0.000, 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 VV8s0HTeSmkS for ; Fri, 13 Jun 2008 08:24:42 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.187]) by core3.amsl.com (Postfix) with ESMTP id E6E753A681E for ; Fri, 13 Jun 2008 08:24:41 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so1926009tib.25 for ; Fri, 13 Jun 2008 08:25:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=tHyZL42EKA16Dc6lrNy/Ngz/THUqaQmQqRYMBi3o9o8=; b=MDsLOTTc+6g492FA1ip5wmep2DOA9hrnHf09cMceSSGGRqlwXZ0Z0Mc1/OPXcIK0y/ tT9bPZunbTH+os01DQUz4tkDLvKIVxwDaQk9Q3vjwFD1VsYQuWFcmQb90twUnqmaTtnM p19MkDMdCH0DJvhV7PsoeR2v08POfPL9eMkh0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=E4VQbHO0GEIF+yHhcupVAuoRhVoU5ilmE1NA1ZQk+nxKEboO9mz0TByrJ2+ha2eQNi riWJSSZ8kJiRJq1fg1jIhebrw2btzAzvJjuJhZkdtC4Lq+GCRA45fofRVZ+25bxMjxdn 9rwiepTLb2eqSqvKLJ3JTCsTDa6gKtlo6CmFo= Received: by 10.110.41.17 with SMTP id o17mr1793024tio.18.1213370711208; Fri, 13 Jun 2008 08:25:11 -0700 (PDT) Received: by 10.110.53.11 with HTTP; Fri, 13 Jun 2008 08:25:11 -0700 (PDT) Message-ID: <1d38a3350806130825o495bf901w228c97a9454aeec4@mail.gmail.com> Date: Fri, 13 Jun 2008 23:25:11 +0800 From: "Hui Deng" To: "Tero Kivinen" In-Reply-To: <18513.5630.730704.57085@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com> <18504.59167.826685.44808@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB72D54D1F@vaebe104.NOE.Nokia.com> <18509.12328.427110.610804@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB72DF195F@vaebe104.NOE.Nokia.com> <18513.5630.730704.57085@fireball.kivinen.iki.fi> Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com Subject: Re: [IPsec] First charter draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Dear Tero, Thanks for your comments, inline reply, > I would like to really see that the architectural affects of the GRE > tunneling (and ESP-NULL marking) are considered, and my current take > is that unless someone really makes some new better reasons why they > cannot be done with the current already standardized methods we would > be better to not to make new protocols or change protocols for them. Please kind help to check, I am swamped to figure out this draft so short. http://www.ietf.org/internet-drafts/draft-deng-ipsec-gre-key-ts-00.txt > I do not think we want to repeat the mistake we did for the traffic > selectors with port and protocol numbers (i.e. overlapping traffic > selectors and decorrelation and so on). One of the things we MUST make > sure is that the gre keys are expressed as ranges, as that is required > for the decorrelating them (i.e. if host has policy saying GRE key x > MUST use AES, and all other GRE keys must use 3DES, we need GRE key > ranges to express the all other GRE keys except key x). We did make > mistake in that for the protocol field already (which is single field, > not range). Currently, we haven't consider the range of all others, we have limited configuration here. Thanks for your comments -Hui _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 13 08:30:05 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C8073A69BE; Fri, 13 Jun 2008 08:30:05 -0700 (PDT) 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 C76283A6825 for ; Fri, 13 Jun 2008 08:30:03 -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=[AWL=0.000, 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 BnY41HUEuFJI for ; Fri, 13 Jun 2008 08:30:02 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.185]) by core3.amsl.com (Postfix) with ESMTP id 3D21C3A681E for ; Fri, 13 Jun 2008 08:30:02 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so1926993tib.25 for ; Fri, 13 Jun 2008 08:30:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=fmvmmPvIESVEjGRVCOI5Na9CXkrDHVvzUVe8cmqj/Sg=; b=JPsMmyKf1YfGOM5W3AWpNCK1/D3wx1h7nb3e++r7oJWfIi2wZrpi5xnA/HZHdMu164 dCmL8YRrxkejOmoSt1owtkgcK3bu0iz5rgtN9u0TLovx/X0JMciTdk8cgA0gGMt6X/s8 qmMqh66QTz2YwQM+uf3mirePOb+JA4yq65mQ8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Vupit0N63AesQiq7RCe+sVZcAIAllzk++37D0jN0A3GPD7FgFoZTDRp0q2nGZWoZyV J5BWCLGLKCHC/uOt1djKvhwJUzP4QqS6+634pNcIs3uFvLe7hmuCLVUlfgO3XzjOtSmz EdctcYXYMET2/Re6QKfticwDUO5jXn90xNYwQ= Received: by 10.110.3.15 with SMTP id 15mr1816583tic.10.1213371033398; Fri, 13 Jun 2008 08:30:33 -0700 (PDT) Received: by 10.110.53.11 with HTTP; Fri, 13 Jun 2008 08:30:33 -0700 (PDT) Message-ID: <1d38a3350806130830u1ecaa54dwd69d5de18731fec5@mail.gmail.com> Date: Fri, 13 Jun 2008 23:30:33 +0800 From: "Hui Deng" To: Pasi.Eronen@nokia.com In-Reply-To: <1696498986EFEC4D9153717DA325CB72E49B18@vaebe104.NOE.Nokia.com> MIME-Version: 1.0 Content-Disposition: inline References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com> <18504.59167.826685.44808@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB72D54D1F@vaebe104.NOE.Nokia.com> <18509.12328.427110.610804@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB72DF195F@vaebe104.NOE.Nokia.com> <484FF855.8020206@checkpoint.com> <1696498986EFEC4D9153717DA325CB72E49B18@vaebe104.NOE.Nokia.com> Cc: ipsec@ietf.org, ynir@checkpoint.com Subject: Re: [IPsec] GRE key Traffic Selector (Was: First charter draft) 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hello, Pasi, Thanks for your pointing out. I do express what we exactly want with other two draft's author, we may have some deviation for those drafts. I figure out one draft shortly and wish this could be clearly expressed for our intention. Hope people in the ML could kind help to review them and give more comments. http://www.ietf.org/internet-drafts/draft-deng-ipsec-gre-key-ts-00.txt Thanks again. -Hui 2008/6/13 : > > I agree that the work item description sent earlier is *significantly* > different from the two individual drafts related to this topic. > > Several folks have also expressed major concerns with those drafts, > and it's not quite clear whether those concerns apply to this part or > not. Stephen also raised the question about what fields are > architecturally suitable to be used as traffic selectors, and the > implementation impact for hardware IPSec implementations. > > Given this, I'm getting the impression that this work item probably > isn't yet mature enough for us to say "yes, this is a good idea, > let's do it".... > > Best regards, > Pasi > >> -----Original Message----- >> From: ext Yoav Nir [mailto:ynir@checkpoint.com] >> Sent: 12 June, 2008 08:13 >> To: Yaron Sheffer >> Cc: Eronen Pasi (Nokia-NRC/Helsinki); ipsec@ietf.org >> Subject: Re: [IPsec] First charter draft >> >> With GRE we have another kind of strange situation. The work item >> that is now proposed is very different from the work item that the >> people who suggested GRE had in mind - it's more limited. >> >> So the question about GRE is whether there is enough of a >> consistuency for the amended version. >> >> As for presentations, I would be happy to present QCD, and I'd like >> to hear one about IKE-over-TCP or IPsec-over-TCP. >> >> On Jun 11, 2008, at 7:07 PM, Yaron Sheffer wrote: >> >> > Hi Pasi, >> > >> > IMHO we are having exactly the right kind of charter discussion, >> > so we can decide as a group whether either or both work items >> > should go into the charter with the goal of becoming an RFC. We >> > have two questions: 1. Is {GRE traffic selectors, ESP-NULL >> > marking} technically sound and provides improved security for >> > real-life usage? 2. Given the group's workload, is there a large >> > enough constituency for each of the work items, to see it through >> > until it is published? >> > >> > I cannot comment on GRE. But for ESP-NULL, we have the strange >> > situation where we do have a constituency, but there are people >> > (including myself) expressing doubt on the technical soundness. >> > >> > I'd prefer to have a conclusive discussion now, rather than >> > putting either of the work items "tentatively" into the >> > charter. As Paul noted, we will not be "dismissing" any of them no >> > matter what we decide. >> > >> > On the other hand, I would be happy to have presentations on >> > non-chartered (or not-yet-chartered) work items in Dublin. >> > >> > Thanks, >> > Yaron > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Jun 15 13:31:00 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A29A3A685C; Sun, 15 Jun 2008 13:31:00 -0700 (PDT) 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 789543A685C for ; Sun, 15 Jun 2008 13:30:59 -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=[AWL=0.000, 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 BwsM9bYDQNoV for ; Sun, 15 Jun 2008 13:30:58 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 5076C3A67A1 for ; Sun, 15 Jun 2008 13:30:58 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.13.8/8.13.8) with ESMTP id m5FKU4Fs010530 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 15 Jun 2008 23:30:04 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.8/8.12.11) id m5FKU3XL011296; Sun, 15 Jun 2008 23:30:03 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Message-ID: <18517.31691.517963.577187@fireball.kivinen.iki.fi> Date: Sun, 15 Jun 2008 23:30:03 +0300 From: Tero Kivinen To: "Hui Deng" In-Reply-To: <1d38a3350806130825o495bf901w228c97a9454aeec4@mail.gmail.com> References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com> <18504.59167.826685.44808@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB72D54D1F@vaebe104.NOE.Nokia.com> <18509.12328.427110.610804@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB72DF195F@vaebe104.NOE.Nokia.com> <18513.5630.730704.57085@fireball.kivinen.iki.fi> <1d38a3350806130825o495bf901w228c97a9454aeec4@mail.gmail.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 2 min Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com Subject: Re: [IPsec] First charter draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hui Deng writes: > > I would like to really see that the architectural affects of the GRE > > tunneling (and ESP-NULL marking) are considered, and my current take > > is that unless someone really makes some new better reasons why they > > cannot be done with the current already standardized methods we would > > be better to not to make new protocols or change protocols for them. > Please kind help to check, I am swamped to figure out this draft so short. > http://www.ietf.org/internet-drafts/draft-deng-ipsec-gre-key-ts-00.txt That does not examplain why you do not create one IKE SA for each of those different enterprices, as they might have different policies for the IKE SA too (and different authentication tokens). And creating different IKE SA removes the requirement for the GRE keys in ts. > > I do not think we want to repeat the mistake we did for the traffic > > selectors with port and protocol numbers (i.e. overlapping traffic > > selectors and decorrelation and so on). One of the things we MUST make > > sure is that the gre keys are expressed as ranges, as that is required > > for the decorrelating them (i.e. if host has policy saying GRE key x > > MUST use AES, and all other GRE keys must use 3DES, we need GRE key > > ranges to express the all other GRE keys except key x). We did make > > mistake in that for the protocol field already (which is single field, > > not range). > Currently, we haven't consider the range of all others, we have > limited configuration > here. Ranges are needed for the decorrelation of the policy provided you have any overlapping in there. Thus if you have GRE key notion of ANY, then you need ranges. -- kivinen@safenet-inc.com _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 16 03:03:23 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 286F23A6841; Mon, 16 Jun 2008 03:03:23 -0700 (PDT) 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 EF6B53A6841 for ; Mon, 16 Jun 2008 03:03:21 -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 MknDLoArgGxI for ; Mon, 16 Jun 2008 03:03:16 -0700 (PDT) Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.191]) by core3.amsl.com (Postfix) with ESMTP id 0AF7A3A67F8 for ; Mon, 16 Jun 2008 03:03:15 -0700 (PDT) Received: by ti-out-0910.google.com with SMTP id a6so2507860tib.25 for ; Mon, 16 Jun 2008 03:03:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=b8a6eJ66GP9iWaSmnjxuHriJXBzVGPWRwk/TAeZaJrw=; b=BfCfcaaMsV2exaAiLwGuTw4g34u6pn9IxV8FfsaN8jc63oi7C/GyQQPD0R3aQA8BT1 jt5XuPGG6O/tktDMoO/0GaZnIOJOlFn24pYsqSznKHl06dWI5/y1/OepILwbEzV/plKS Sd2xsJaGhl2feRwPUSQdk6Zl9polWIxk9K/JE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Usy1f2hYt1k0JmgRDu97g3KmaM0aEAYbOJs4TTqJETZvw3d2uDByVIBYNDf1vGQ0Zc ySkfGDVHCNIeCjm8u9XTHP45f/LNrQbDsXt7bT351AlWpgUTxIs43xzvf1eAnJNTN8fR l+p2IqEXxCCihzYTQuNlLK0Ap+Cy/4DwQVUZQ= Received: by 10.110.8.5 with SMTP id 5mr4217416tih.3.1213610632381; Mon, 16 Jun 2008 03:03:52 -0700 (PDT) Received: by 10.110.53.11 with HTTP; Mon, 16 Jun 2008 03:03:52 -0700 (PDT) Message-ID: <1d38a3350806160303q566aaf9dy47a22afd50e75838@mail.gmail.com> Date: Mon, 16 Jun 2008 18:03:52 +0800 From: "Hui Deng" To: "Tero Kivinen" In-Reply-To: <18517.31691.517963.577187@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Disposition: inline References: <1696498986EFEC4D9153717DA325CB72C63466@vaebe104.NOE.Nokia.com> <1696498986EFEC4D9153717DA325CB72D5485B@vaebe104.NOE.Nokia.com> <18504.59167.826685.44808@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB72D54D1F@vaebe104.NOE.Nokia.com> <18509.12328.427110.610804@fireball.kivinen.iki.fi> <1696498986EFEC4D9153717DA325CB72DF195F@vaebe104.NOE.Nokia.com> <18513.5630.730704.57085@fireball.kivinen.iki.fi> <1d38a3350806130825o495bf901w228c97a9454aeec4@mail.gmail.com> <18517.31691.517963.577187@fireball.kivinen.iki.fi> Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com Subject: Re: [IPsec] First charter draft 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: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, Tero, Thanks for your discussion, reply inline. 2008/6/16 Tero Kivinen : > Hui Deng writes: >> > I would like to really see that the architectural affects of the GRE >> > tunneling (and ESP-NULL marking) are considered, and my current take >> > is that unless someone really makes some new better reasons why they >> > cannot be done with the current already standardized methods we would >> > be better to not to make new protocols or change protocols for them. >> Please kind help to check, I am swamped to figure out this draft so short. >> http://www.ietf.org/internet-drafts/draft-deng-ipsec-gre-key-ts-00.txt > > That does not examplain why you do not create one IKE SA for each of > those different enterprices, as they might have different policies for > the IKE SA too (and different authentication tokens). And creating > different IKE SA removes the requirement for the GRE keys in ts. Please forgive me that we didn't explain it in detail, current LMA and MAG architecture deploy IPsec tunnel only between MAG and LMA devices, it is not enterprise edge to enterprise edge IPsec tunnel. IKE SA is only used between LMA and MAG, and GRE key based IPsec SA will be used to differentiate each traffic flow. > >> > I do not think we want to repeat the mistake we did for the traffic >> > selectors with port and protocol numbers (i.e. overlapping traffic >> > selectors and decorrelation and so on). One of the things we MUST make >> > sure is that the gre keys are expressed as ranges, as that is required >> > for the decorrelating them (i.e. if host has policy saying GRE key x >> > MUST use AES, and all other GRE keys must use 3DES, we need GRE key >> > ranges to express the all other GRE keys except key x). We did make >> > mistake in that for the protocol field already (which is single field, >> > not range). >> Currently, we haven't consider the range of all others, we have >> limited configuration >> here. > > Ranges are needed for the decorrelation of the policy provided you > have any overlapping in there. Thus if you have GRE key notion of ANY, > then you need ranges. Thanks for your comments, we will consider ANY for our GRE key notion. Best regards, -Hui _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jun 19 04:38:11 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A1FC63A6A1A; Thu, 19 Jun 2008 04:38:11 -0700 (PDT) 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 2FBC83A69C3 for ; Thu, 19 Jun 2008 04:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 Pe6bkc3xMp1Z for ; Thu, 19 Jun 2008 04:38:08 -0700 (PDT) Received: from web51702.mail.re2.yahoo.com (web51702.mail.re2.yahoo.com [206.190.38.220]) by core3.amsl.com (Postfix) with SMTP id A73353A67F8 for ; Thu, 19 Jun 2008 04:38:08 -0700 (PDT) Received: (qmail 50648 invoked by uid 60001); 19 Jun 2008 11:38:57 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Received:X-Mailer:Date:From:Subject:To:MIME-Version:Content-Type:Message-ID; b=KL2FLlq4kATxtCNjKKBS6ROn7zs1jgQsfcAbIR+niGBktaECNGjDSTrhVj3L4b0v1ah4S8adqFqQzfUmPtgLPV6J2TeRh6LnYtwrEDry2nr1c6JE8+yvF2KCjHatlmvethbP9cYtMEUedXksMrL0sMzG57NUsszpncSi00lfD1g=; Received: from [134.91.241.65] by web51702.mail.re2.yahoo.com via HTTP; Thu, 19 Jun 2008 04:38:57 PDT X-Mailer: YahooMailRC/975.45 YahooMailWebService/0.7.199 Date: Thu, 19 Jun 2008 04:38:57 -0700 (PDT) From: Andrei Iarus To: ipsec@ietf.org MIME-Version: 1.0 Message-ID: <816830.50381.qm@web51702.mail.re2.yahoo.com> Subject: [IPsec] IPsec and multicast 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: , Content-Type: multipart/mixed; boundary="===============2035776435==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============2035776435== Content-Type: multipart/alternative; boundary="0-1007221669-1213875537=:50381" --0-1007221669-1213875537=:50381 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Hello, everyone.=0AI have to secure some multicast UDP transmission of a ap= plication=A0and I got a little bit confussed. The IPsec specifications publ= ished in 1998 (RFC 2401)=A0seem not to support the multicast delivery (tran= sport mode), but the 2005 issue (RFC 4301) does seem. So, is that possible = to use IPsec to secure&delivery (ESP) only the multicast UDP traffic in a m= ulticast group? If so, what is the current status of its implemetation in W= indows XP, for example (or other operating systems).=0AI am sorry if the em= ail is OT.=0AThank you very much,=0AAndrei=0A=0A=0A --0-1007221669-1213875537=:50381 Content-Type: text/html; charset=us-ascii
Hello, everyone.
 
I have to secure some multicast UDP transmission of a application and I got a little bit confussed. The IPsec specifications published in 1998 (RFC 2401) seem not to support the multicast delivery (transport mode), but the 2005 issue (RFC 4301) does seem. So, is that possible to use IPsec to secure&delivery (ESP) only the multicast UDP traffic in a multicast group? If so, what is the current status of its implemetation in Windows XP, for example (or other operating systems).
 
I am sorry if the email is OT.
 
Thank you very much,
Andrei

--0-1007221669-1213875537=:50381-- --===============2035776435== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec --===============2035776435==-- From ipsec-bounces@ietf.org Sun Jun 22 22:49:44 2008 Return-Path: X-Original-To: ipsec-archive@megatron.ietf.org Delivered-To: ietfarch-ipsec-archive@core3.amsl.com Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0891E3A68C7; Sun, 22 Jun 2008 22:49:44 -0700 (PDT) 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 374D93A68C7 for ; Sun, 22 Jun 2008 22:49:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 LTPSxSEJrKL7 for ; Sun, 22 Jun 2008 22:49:42 -0700 (PDT) Received: from ind-iport-2.cisco.com (ind-iport-2.cisco.com [64.104.129.219]) by core3.amsl.com (Postfix) with ESMTP id 492683A689B for ; Sun, 22 Jun 2008 22:49:41 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.27,688,1204482600"; d="scan'208,217";a="9207280" Received: from ind-dkim-1.cisco.com ([64.104.140.57]) by ind-iport-2.cisco.com with ESMTP; 23 Jun 2008 11:18:59 +0530 Received: from india-core-1.cisco.com (india-core-1.cisco.com [64.104.129.221]) by ind-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id m5N5mxB3029941; Mon, 23 Jun 2008 11:18:59 +0530 Received: from xbh-blr-412.apac.cisco.com (xbh-blr-412.cisco.com [64.104.140.149]) by india-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id m5N5mvIe021618; Mon, 23 Jun 2008 05:48:58 GMT Received: from xfe-blr-412.apac.cisco.com ([64.104.140.152]) by xbh-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jun 2008 11:18:58 +0530 Received: from [64.104.133.192] ([64.104.133.192]) by xfe-blr-412.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 Jun 2008 11:18:57 +0530 Message-ID: <485F394A.1090804@cisco.com> Date: Mon, 23 Jun 2008 11:18:58 +0530 From: Pratima Sethi User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: ipsec@ietf.org X-OriginalArrivalTime: 23 Jun 2008 05:48:57.0887 (UTC) FILETIME=[D44B42F0:01C8D4F4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3535; t=1214200139; x=1215064139; c=relaxed/simple; s=inddkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=psethi@cisco.com; z=From:=20Pratima=20Sethi=20 |Subject:=20[Fwd=3A=20New=20Version=20Notification=20for=20 draft-detienne-ikev2-recovery-00] |Sender:=20; bh=AULDQfb+rpV/VSA+zk0AclLTqy4wPp4eG0v084RUxwA=; b=WcZkcE5OxxcMZzJsVh7LOUUzjhlHdZeIgDZ1W8BGkSyT71gGU0HVFIWFOs Fr234HiNmBnzb8u3IgH9GowVPURq1VUTW+MKsTgxLjhaoqVmUEkpKqzS0h18 UgQjeT/lnY; Authentication-Results: ind-dkim-1; header.From=psethi@cisco.com; dkim=pass ( sig from cisco.com/inddkim1002 verified; ); Cc: Frederic Detienne Subject: [IPsec] [Fwd: New Version Notification for draft-detienne-ikev2-recovery-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: , Content-Type: multipart/mixed; boundary="===============1161129811==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1161129811== Content-Type: multipart/alternative; boundary="------------030901000402020100080301" This is a multi-part message in MIME format. --------------030901000402020100080301 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit We have posted a new draft that proposes a new mechanism for secure recovery of IKE and IPsec SAs, after a failure. Please review the draft and send us your comments. thaks, - prati ============================================================================= A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Safe IKE Recovery Author(s) : F. Detienne, P. Sethi Filename : draft-detienne-ikev2-recovery-00.txt Pages : 19 Date : 2008-06-20 The Internet Key Exchange protocol version 2 (IKEv2) suffers from the limitation of not having a means to quickly recover from a stale state known as dangling Security Associations (SA's) where one side has SA's that the corresponding party does not have anymore. This Draft proposes to address the limitation by offering an immediate, DoS-free recovery mechanism for IKE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-detienne-ikev2-recovery-00.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. --------------030901000402020100080301 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

We have posted a new draft that proposes a new mechanism for secure recovery of IKE and IPsec SAs, after a failure.
Please review the draft and send us your comments.

thaks,
- prati
=============================================================================
A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title           : Safe IKE Recovery
	Author(s)       : F. Detienne, P. Sethi
	Filename        : draft-detienne-ikev2-recovery-00.txt
	Pages           : 19
	Date            : 2008-06-20

The Internet Key Exchange protocol version 2 (IKEv2) suffers from the
limitation of not having a means to quickly recover from a stale
state known as dangling Security Associations (SA's) where one side
has SA's that the corresponding party does not have anymore.

This Draft proposes to address the limitation by offering an
immediate, DoS-free recovery mechanism for IKE.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-detienne-ikev2-recovery-00.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.
<ftp://ftp.ietf.org/internet-drafts/draft-detienne-ikev2-recovery-00.txt>






--------------030901000402020100080301--

--===============1161129811==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1161129811==--


From ipsec-bounces@ietf.org  Mon Jun 23 03:35:22 2008
Return-Path: 
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 810033A694C;
	Mon, 23 Jun 2008 03:35:22 -0700 (PDT)
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 98A0B3A67FB
	for ; Mon, 23 Jun 2008 03:35:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6]
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 4klwzJdV5nJ5 for ;
	Mon, 23 Jun 2008 03:35:17 -0700 (PDT)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54])
	by core3.amsl.com (Postfix) with ESMTP id 651A73A694C
	for ; Mon, 23 Jun 2008 03:35:17 -0700 (PDT)
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105)
	id 6E538294021; Mon, 23 Jun 2008 13:35:16 +0300 (IDT)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68])
	by dlpdemo.checkpoint.com (Postfix) with ESMTP id 690A6294003;
	Mon, 23 Jun 2008 13:35:15 +0300 (IDT)
Received: from MBP.checkpoint.com (localhost [127.0.0.1])
	by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id
	m5NAZFjI007590; Mon, 23 Jun 2008 13:35:15 +0300 (IDT)
Message-Id: <5326E5DF-0D3E-4ADD-9647-785274E8A2A2@checkpoint.com>
From: Yoav Nir 
To: ipsec@ietf.org
In-Reply-To: <485F394A.1090804@cisco.com>
Mime-Version: 1.0 (Apple Message framework v924)
Date: Mon, 23 Jun 2008 13:35:14 +0300
References: <485F394A.1090804@cisco.com>
X-Mailer: Apple Mail (2.924)
Cc: Frederic Detienne , Pratima Sethi 
Subject: Re: [IPsec] [Fwd: New Version Notification for
	draft-detienne-ikev2-recovery-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: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

Hi Prati

I've read your draft.  As I see it, it is supposed to solve the same  
problem as my http://www.ietf.org/internet-drafts/draft-nir-ike-qcd-00.txt 
  . Both solve the case of a mismatched state between peers, where one  
has a live SA while the other has lost the SA (for example, due to a  
crash)

Your draft solves the problem by an unprotected query-response  
protocol on top of IKE, typically like this:

Alice                                    Bob
        HDR*(A,B)....
   <----------------------------------------

      HDR(A,B) N(INVALID-IKE_SA)
   ----------------------------------------->

      HDR(A,B) N(CHECK-SPI Query) N(Cookie)
   <-----------------------------------------

      HDR(A,B) N(CHECK-SPI Nack) N(Cookie)
   ----------------------------------------->

I'm not sure I understand what the security benefit of the CHECK-SPI  
notification. The INVALID-IKE-SA already indicates that Alice does not  
have the IKE SA. It is true that the packet could be spoofed, but in  
the absence of any protection, the same could be said for the packet  
carrying the CHECK-SPI NACK notification.


On Jun 23, 2008, at 8:48 AM, Pratima Sethi wrote:

>
>
> We have posted a new draft that proposes a new mechanism for secure  
> recovery of IKE and IPsec SAs, after a failure.
> Please review the draft and send us your comments.
>
> thaks,
> - prati
> = 
> = 
> = 
> = 
> = 
> = 
> = 
> ======================================================================
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
> 	Title           : Safe IKE Recovery
> 	Author(s)       : F. Detienne, P. Sethi
> 	Filename        : draft-detienne-ikev2-recovery-00.txt
> 	Pages           : 19
> 	Date            : 2008-06-20
>
> The Internet Key Exchange protocol version 2 (IKEv2) suffers from the
> limitation of not having a means to quickly recover from a stale
> state known as dangling Security Associations (SA's) where one side
> has SA's that the corresponding party does not have anymore.
>
> This Draft proposes to address the limitation by offering an
> immediate, DoS-free recovery mechanism for IKE.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-detienne-ikev2-recovery-00.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.
>  >
>
>
>
> Scanned by Check Point Total Security Gateway.
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

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


From ipsec-bounces@ietf.org  Mon Jun 23 05:21:38 2008
Return-Path: 
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 025AB3A6859;
	Mon, 23 Jun 2008 05:21:38 -0700 (PDT)
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 B9E023A6812
	for ; Mon, 23 Jun 2008 05:21:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, J_CHICKENPOX_31=0.6]
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 OQ6JsFyjQ4+A for ;
	Mon, 23 Jun 2008 05:21:35 -0700 (PDT)
Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119])
	by core3.amsl.com (Postfix) with ESMTP id 1759A3A6969
	for ; Mon, 23 Jun 2008 05:21:34 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1])
	by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id
	m5NCLRU15226; Mon, 23 Jun 2008 14:21:27 +0200 (CEST)
Received: from [64.103.134.171] ([64.103.134.171])
	by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id
	m5NCLLA15400; Mon, 23 Jun 2008 14:21:26 +0200 (CEST)
From: Frederic Detienne 
To: Yoav Nir 
In-Reply-To: <5326E5DF-0D3E-4ADD-9647-785274E8A2A2@checkpoint.com>
References: <485F394A.1090804@cisco.com>
	<5326E5DF-0D3E-4ADD-9647-785274E8A2A2@checkpoint.com>
Organization: Cisco
Date: Mon, 23 Jun 2008 14:09:02 +0200
Message-Id: <1214222942.6828.205.camel@fdetienn-laptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.2 
Cc: ipsec@ietf.org, Pratima Sethi 
Subject: Re: [IPsec] [Fwd: New Version Notification
	for	draft-detienne-ikev2-recovery-00]
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: fd@cisco.com
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

Hi Yoav,

One of the intended features of the SIR protocol is statelessness. SIR
is stateless during the exchange and across reboots.

The unauthenticated INVALID_SPI message can be spoofed. The CHECK_SPI
test is a stateless anti-spoof, liveness, peer validation test by virtue
of a QUERY/RESPONSE test.

CHECK_SPI(QUERY) carries an N(Cookie) that is reflected in
CHECK_SPI(NACK/ACK). Thanks to the strong cryptographic properties of
N(COOKIE), remote-spoofing CHECK_SPI(NACK/ACK) is hard.

This is the ground on which IKEv2 is built and we placed our protocol at
the same level of protection.

Finally, SIR can be implemented on existing small hardware or large
clusters without changing hardware requirements.

regards,

	fred


On Mon, 2008-06-23 at 13:35 +0300, Yoav Nir wrote:
> Hi Prati
> 
> I've read your draft.  As I see it, it is supposed to solve the same  
> problem as my http://www.ietf.org/internet-drafts/draft-nir-ike-qcd-00.txt 
>   . Both solve the case of a mismatched state between peers, where one  
> has a live SA while the other has lost the SA (for example, due to a  
> crash)
> 
> Your draft solves the problem by an unprotected query-response  
> protocol on top of IKE, typically like this:
> 
> Alice                                    Bob
>         HDR*(A,B)....
>    <----------------------------------------
> 
>       HDR(A,B) N(INVALID-IKE_SA)
>    ----------------------------------------->
> 
>       HDR(A,B) N(CHECK-SPI Query) N(Cookie)
>    <-----------------------------------------
> 
>       HDR(A,B) N(CHECK-SPI Nack) N(Cookie)
>    ----------------------------------------->
> 
> I'm not sure I understand what the security benefit of the CHECK-SPI  
> notification. The INVALID-IKE-SA already indicates that Alice does not  
> have the IKE SA. It is true that the packet could be spoofed, but in  
> the absence of any protection, the same could be said for the packet  
> carrying the CHECK-SPI NACK notification.
> 
> 
> On Jun 23, 2008, at 8:48 AM, Pratima Sethi wrote:
> 
> >
> >
> > We have posted a new draft that proposes a new mechanism for secure  
> > recovery of IKE and IPsec SAs, after a failure.
> > Please review the draft and send us your comments.
> >
> > thaks,
> > - prati
> > = 
> > = 
> > = 
> > = 
> > = 
> > = 
> > = 
> > ======================================================================
> > A New Internet-Draft is available from the on-line Internet-Drafts  
> > directories.
> >
> > 	Title           : Safe IKE Recovery
> > 	Author(s)       : F. Detienne, P. Sethi
> > 	Filename        : draft-detienne-ikev2-recovery-00.txt
> > 	Pages           : 19
> > 	Date            : 2008-06-20
> >
> > The Internet Key Exchange protocol version 2 (IKEv2) suffers from the
> > limitation of not having a means to quickly recover from a stale
> > state known as dangling Security Associations (SA's) where one side
> > has SA's that the corresponding party does not have anymore.
> >
> > This Draft proposes to address the limitation by offering an
> > immediate, DoS-free recovery mechanism for IKE.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-detienne-ikev2-recovery-00.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.
> >  > >
> >
> >
> >
> > Scanned by Check Point Total Security Gateway.
> >
> > _______________________________________________
> > IPsec mailing list
> > IPsec@ietf.org
> > https://www.ietf.org/mailman/listinfo/ipsec
> 
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

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


From ipsec-bounces@ietf.org  Tue Jun 24 00:15:05 2008
Return-Path: 
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 7B5773A68EF;
	Tue, 24 Jun 2008 00:15:05 -0700 (PDT)
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 571CA3A68EF
	for ; Tue, 24 Jun 2008 00:15:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 
	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 nZwnRJtVw2LO for ;
	Tue, 24 Jun 2008 00:15:03 -0700 (PDT)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54])
	by core3.amsl.com (Postfix) with ESMTP id 160CF3A6836
	for ; Tue, 24 Jun 2008 00:15:02 -0700 (PDT)
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105)
	id E24FF294013; Tue, 24 Jun 2008 10:14:58 +0300 (IDT)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68])
	by dlpdemo.checkpoint.com (Postfix) with ESMTP id 0420B294001;
	Tue, 24 Jun 2008 10:14:58 +0300 (IDT)
Received: from MBP.checkpoint.com (localhost [127.0.0.1])
	by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id
	m5O7EvjI023608; Tue, 24 Jun 2008 10:14:57 +0300 (IDT)
Message-Id: 
From: Yoav Nir 
To: ipsec@ietf.org
In-Reply-To: <1214222942.6828.205.camel@fdetienn-laptop>
Mime-Version: 1.0 (Apple Message framework v924)
Date: Tue, 24 Jun 2008 10:14:56 +0300
References: <485F394A.1090804@cisco.com>
	<5326E5DF-0D3E-4ADD-9647-785274E8A2A2@checkpoint.com>
	<1214222942.6828.205.camel@fdetienn-laptop>
X-Mailer: Apple Mail (2.924)
Cc: Frederic Detienne , Pratima Sethi 
Subject: Re: [IPsec] [Fwd: New Version Notification for
	draft-detienne-ikev2-recovery-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: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

Hi Frederic,

Comments inline

On Jun 23, 2008, at 3:09 PM, Frederic Detienne wrote:

> Hi Yoav,
>
> One of the intended features of the SIR protocol is statelessness. SIR
> is stateless during the exchange and across reboots.

SIR is a protocol for validation of a specific IKE SA. The peer that  
performs this validation has a live IKE SA, so I don't believe it can  
be called stateless. It is possible to perform the CHECK_SPI query  
itself in a stateless manner, but seeing as you already hold an IKE SA  
with all its associated keys and information, I don't see what that  
buys you. Specifically, the number of CHECK_SPI queries is limited by  
the number of active IKE SAs, so I don't see why statelessness is an  
advantage here.

> The unauthenticated INVALID_SPI message can be spoofed. The CHECK_SPI
> test is a stateless anti-spoof, liveness, peer validation test by  
> virtue
> of a QUERY/RESPONSE test.

Stateless cookies only provide a protection against a flood of initial  
packets with spoofed origins, such as SYN-flood attacks or multiple  
INITIAL exchange packets. They protect the responder against a  
malicious initiator. This is not the case here.

> CHECK_SPI(QUERY) carries an N(Cookie) that is reflected in
> CHECK_SPI(NACK/ACK). Thanks to the strong cryptographic properties of
> N(COOKIE), remote-spoofing CHECK_SPI(NACK/ACK) is hard.

The cryptographic properties of N(COOKIE) make it hard to guess in  
advance what it is going to be. However, since Peer Y sends that  
cookie in the clear, an eavesdropping attacker should have no problem  
in seeing the cookie and creating a valid CHECK_SPI(NACK)

> This is the ground on which IKEv2 is built and we placed our  
> protocol at
> the same level of protection.

Again, stateless cookies serve a different purpose in IKEv2. They  
prevent DoS attacks by limiting the amount of D-H calculations you can  
force a server to do. Here we're protecting against the forced  
deletion of an existing IKE SA. These are two very different problems.

> Finally, SIR can be implemented on existing small hardware or large
> clusters without changing hardware requirements.

I agree that this is an advantage of SIR

> regards,
>
> 	fred

Yoav

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


From ipsec-bounces@ietf.org  Tue Jun 24 01:02:02 2008
Return-Path: 
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 41C143A684C;
	Tue, 24 Jun 2008 01:02:02 -0700 (PDT)
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 54E8F3A684C
	for ; Tue, 24 Jun 2008 01:02:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level: 
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 
	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 hxVqwm2JySPH for ;
	Tue, 24 Jun 2008 01:02:00 -0700 (PDT)
Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119])
	by core3.amsl.com (Postfix) with ESMTP id 049E83A6836
	for ; Tue, 24 Jun 2008 01:01:59 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1])
	by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id
	m5O81je19112; Tue, 24 Jun 2008 10:01:45 +0200 (CEST)
Received: from [64.103.134.171] ([64.103.134.171])
	by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id
	m5O81gA05007; Tue, 24 Jun 2008 10:01:42 +0200 (CEST)
From: Frederic Detienne 
To: Yoav Nir 
In-Reply-To: 
References: <485F394A.1090804@cisco.com>
	<5326E5DF-0D3E-4ADD-9647-785274E8A2A2@checkpoint.com>
	<1214222942.6828.205.camel@fdetienn-laptop>
	
Organization: Cisco
Date: Tue, 24 Jun 2008 10:01:43 +0200
Message-Id: <1214294503.6654.23.camel@fdetienn-laptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.2 
Cc: ipsec@ietf.org, Pratima Sethi 
Subject: Re: [IPsec] [Fwd: New Version Notification
	for	draft-detienne-ikev2-recovery-00]
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: fd@cisco.com
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

SGkgWW9hdiwKCkkgbWF5IGJlIG1pc3Npbmcgc29tZXRoaW5nIGJ1dCBsZXQncyBwYXJ0aXRpb24g
dGhlIHNpdHVhdGlvbiBpbiB0d28KY2FzZXM6CgoxKSB0aGUgYXR0YWNrZXIgSVMgTk9UIGluIHRo
ZSBtaWRkbGUKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCkNhbiB5b3UgZXhw
bGFpbiBob3cgeW91IHJlbW90ZS1zcG9vZiBhIHZhbGlkIENIRUNLX1NQSShOQUNLKXxOKENPT0tJ
RSkKYW5kIGZvcmNlIGRlbGV0aW9uID8KCjIpIHRoZSBhdHRhY2tlciBJUyBpbiB0aGUgbWlkZGxl
IChlYXZlc2Ryb3BwaW5nIG9yIGluamVjdGluZykK77u/LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQpUaGUgYXR0YWNrZXIgY2FuIGp1
c3Qgc3dhbXAgb25lIG9mIHRoZSBJS0UgcGVlcnMgd2l0aCBvZmZlcnMgYW5kIGZvcmNlCm1hbnkg
REggY29tcHV0YXRpb25zLiBSZWdhcmRsZXNzIG9mIFNJUi4KCgpBcyBmb3IgdGhlIHN0YXRlbGVz
c25lc3MsIFNJUiBkb2VzIG5vdCBjb25zdW1lIF9hZGRpdGlvbmFsXyBzdGF0ZSB3aGVuCnRoZSBw
cm9jZWR1cmUgaXMgdHJpZ2dlcmVkLiBUaGUgcHJvY2VzcyBpcyBzZWxmLXN1c3RhaW5lZCBhbmQg
ZG9lcyBub3QKcmVxdWlyZSBzdG9yYWdlIGZvciBsb25nZXIgdGhhbiB0aGUgcHJvY2Vzc2luZyBv
ZiBhIHBhY2tldC4g77u/Tm8gdGltZXJzLApubyByZXRyYW5zbWlzc2lvbnMuLi4gVGhpcyBpcyBh
cyBsaXR0bGUgY29uc3VtcHRpb25zIGFzIHdlIGNvdWxkCmltYWdpbmUuCgpyZWdhcmRzLAoKCWZy
ZWQKCk9uIFR1ZSwgMjAwOC0wNi0yNCBhdCAxMDoxNCArMDMwMCwgWW9hdiBOaXIgd3JvdGU6Cj4g
SGkgRnJlZGVyaWMsCj4gCj4gQ29tbWVudHMgaW5saW5lCj4gCj4gT24gSnVuIDIzLCAyMDA4LCBh
dCAzOjA5IFBNLCBGcmVkZXJpYyBEZXRpZW5uZSB3cm90ZToKPiAKPiA+IEhpIFlvYXYsCj4gPgo+
ID4gT25lIG9mIHRoZSBpbnRlbmRlZCBmZWF0dXJlcyBvZiB0aGUgU0lSIHByb3RvY29sIGlzIHN0
YXRlbGVzc25lc3MuIFNJUgo+ID4gaXMgc3RhdGVsZXNzIGR1cmluZyB0aGUgZXhjaGFuZ2UgYW5k
IGFjcm9zcyByZWJvb3RzLgo+IAo+IFNJUiBpcyBhIHByb3RvY29sIGZvciB2YWxpZGF0aW9uIG9m
IGEgc3BlY2lmaWMgSUtFIFNBLiBUaGUgcGVlciB0aGF0ICAKPiBwZXJmb3JtcyB0aGlzIHZhbGlk
YXRpb24gaGFzIGEgbGl2ZSBJS0UgU0EsIHNvIEkgZG9uJ3QgYmVsaWV2ZSBpdCBjYW4gIAo+IGJl
IGNhbGxlZCBzdGF0ZWxlc3MuIEl0IGlzIHBvc3NpYmxlIHRvIHBlcmZvcm0gdGhlIENIRUNLX1NQ
SSBxdWVyeSAgCj4gaXRzZWxmIGluIGEgc3RhdGVsZXNzIG1hbm5lciwgYnV0IHNlZWluZyBhcyB5
b3UgYWxyZWFkeSBob2xkIGFuIElLRSBTQSAgCj4gd2l0aCBhbGwgaXRzIGFzc29jaWF0ZWQga2V5
cyBhbmQgaW5mb3JtYXRpb24sIEkgZG9uJ3Qgc2VlIHdoYXQgdGhhdCAgCj4gYnV5cyB5b3UuIFNw
ZWNpZmljYWxseSwgdGhlIG51bWJlciBvZiBDSEVDS19TUEkgcXVlcmllcyBpcyBsaW1pdGVkIGJ5
ICAKPiB0aGUgbnVtYmVyIG9mIGFjdGl2ZSBJS0UgU0FzLCBzbyBJIGRvbid0IHNlZSB3aHkgc3Rh
dGVsZXNzbmVzcyBpcyBhbiAgCj4gYWR2YW50YWdlIGhlcmUuCj4gCj4gPiBUaGUgdW5hdXRoZW50
aWNhdGVkIElOVkFMSURfU1BJIG1lc3NhZ2UgY2FuIGJlIHNwb29mZWQuIFRoZSBDSEVDS19TUEkK
PiA+IHRlc3QgaXMgYSBzdGF0ZWxlc3MgYW50aS1zcG9vZiwgbGl2ZW5lc3MsIHBlZXIgdmFsaWRh
dGlvbiB0ZXN0IGJ5ICAKPiA+IHZpcnR1ZQo+ID4gb2YgYSBRVUVSWS9SRVNQT05TRSB0ZXN0Lgo+
IAo+IFN0YXRlbGVzcyBjb29raWVzIG9ubHkgcHJvdmlkZSBhIHByb3RlY3Rpb24gYWdhaW5zdCBh
IGZsb29kIG9mIGluaXRpYWwgIAo+IHBhY2tldHMgd2l0aCBzcG9vZmVkIG9yaWdpbnMsIHN1Y2gg
YXMgU1lOLWZsb29kIGF0dGFja3Mgb3IgbXVsdGlwbGUgIAo+IElOSVRJQUwgZXhjaGFuZ2UgcGFj
a2V0cy4gVGhleSBwcm90ZWN0IHRoZSByZXNwb25kZXIgYWdhaW5zdCBhICAKPiBtYWxpY2lvdXMg
aW5pdGlhdG9yLiBUaGlzIGlzIG5vdCB0aGUgY2FzZSBoZXJlLgo+IAo+ID4gQ0hFQ0tfU1BJKFFV
RVJZKSBjYXJyaWVzIGFuIE4oQ29va2llKSB0aGF0IGlzIHJlZmxlY3RlZCBpbgo+ID4gQ0hFQ0tf
U1BJKE5BQ0svQUNLKS4gVGhhbmtzIHRvIHRoZSBzdHJvbmcgY3J5cHRvZ3JhcGhpYyBwcm9wZXJ0
aWVzIG9mCj4gPiBOKENPT0tJRSksIHJlbW90ZS1zcG9vZmluZyBDSEVDS19TUEkoTkFDSy9BQ0sp
IGlzIGhhcmQuCj4gCj4gVGhlIGNyeXB0b2dyYXBoaWMgcHJvcGVydGllcyBvZiBOKENPT0tJRSkg
bWFrZSBpdCBoYXJkIHRvIGd1ZXNzIGluICAKPiBhZHZhbmNlIHdoYXQgaXQgaXMgZ29pbmcgdG8g
YmUuIEhvd2V2ZXIsIHNpbmNlIFBlZXIgWSBzZW5kcyB0aGF0ICAKPiBjb29raWUgaW4gdGhlIGNs
ZWFyLCBhbiBlYXZlc2Ryb3BwaW5nIGF0dGFja2VyIHNob3VsZCBoYXZlIG5vIHByb2JsZW0gIAo+
IGluIHNlZWluZyB0aGUgY29va2llIGFuZCBjcmVhdGluZyBhIHZhbGlkIENIRUNLX1NQSShOQUNL
KQo+IAo+ID4gVGhpcyBpcyB0aGUgZ3JvdW5kIG9uIHdoaWNoIElLRXYyIGlzIGJ1aWx0IGFuZCB3
ZSBwbGFjZWQgb3VyICAKPiA+IHByb3RvY29sIGF0Cj4gPiB0aGUgc2FtZSBsZXZlbCBvZiBwcm90
ZWN0aW9uLgo+IAo+IEFnYWluLCBzdGF0ZWxlc3MgY29va2llcyBzZXJ2ZSBhIGRpZmZlcmVudCBw
dXJwb3NlIGluIElLRXYyLiBUaGV5ICAKPiBwcmV2ZW50IERvUyBhdHRhY2tzIGJ5IGxpbWl0aW5n
IHRoZSBhbW91bnQgb2YgRC1IIGNhbGN1bGF0aW9ucyB5b3UgY2FuICAKPiBmb3JjZSBhIHNlcnZl
ciB0byBkby4gSGVyZSB3ZSdyZSBwcm90ZWN0aW5nIGFnYWluc3QgdGhlIGZvcmNlZCAgCj4gZGVs
ZXRpb24gb2YgYW4gZXhpc3RpbmcgSUtFIFNBLiBUaGVzZSBhcmUgdHdvIHZlcnkgZGlmZmVyZW50
IHByb2JsZW1zLgo+IAo+ID4gRmluYWxseSwgU0lSIGNhbiBiZSBpbXBsZW1lbnRlZCBvbiBleGlz
dGluZyBzbWFsbCBoYXJkd2FyZSBvciBsYXJnZQo+ID4gY2x1c3RlcnMgd2l0aG91dCBjaGFuZ2lu
ZyBoYXJkd2FyZSByZXF1aXJlbWVudHMuCj4gCj4gSSBhZ3JlZSB0aGF0IHRoaXMgaXMgYW4gYWR2
YW50YWdlIG9mIFNJUgo+IAo+ID4gcmVnYXJkcywKPiA+Cj4gPiAJZnJlZAo+IAo+IFlvYXYKCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCklQc2VjIG1haWxp
bmcgbGlzdApJUHNlY0BpZXRmLm9yZwpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp
bmZvL2lwc2VjCg==


From ipsec-bounces@ietf.org  Tue Jun 24 01:33:42 2008
Return-Path: 
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id F220F3A68C8;
	Tue, 24 Jun 2008 01:33:41 -0700 (PDT)
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 BD93A3A6845
	for ; Tue, 24 Jun 2008 01:33:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 
	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 P5o4UtmwwvJc for ;
	Tue, 24 Jun 2008 01:33:40 -0700 (PDT)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54])
	by core3.amsl.com (Postfix) with ESMTP id 936513A68C8
	for ; Tue, 24 Jun 2008 01:33:39 -0700 (PDT)
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105)
	id 76EDE294016; Tue, 24 Jun 2008 11:33:39 +0300 (IDT)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68])
	by dlpdemo.checkpoint.com (Postfix) with ESMTP id A01C7294001;
	Tue, 24 Jun 2008 11:33:38 +0300 (IDT)
Received: from MBP.checkpoint.com (localhost [127.0.0.1])
	by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id
	m5O8XcjI029321; Tue, 24 Jun 2008 11:33:38 +0300 (IDT)
Message-Id: <9ED51A04-61B5-43D2-B93C-D356C0365E16@checkpoint.com>
From: Yoav Nir 
To: fd@cisco.com
In-Reply-To: <1214294503.6654.23.camel@fdetienn-laptop>
Mime-Version: 1.0 (Apple Message framework v924)
Date: Tue, 24 Jun 2008 11:33:37 +0300
References: <485F394A.1090804@cisco.com>
	<5326E5DF-0D3E-4ADD-9647-785274E8A2A2@checkpoint.com>
	<1214222942.6828.205.camel@fdetienn-laptop>
	
	<1214294503.6654.23.camel@fdetienn-laptop>
X-Mailer: Apple Mail (2.924)
Cc: ipsec@ietf.org, Pratima Sethi 
Subject: Re: [IPsec] [Fwd: New Version Notification for
	draft-detienne-ikev2-recovery-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: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

Hi Fred,

I think the first case is not interesting, because if the attacker  
can't see our packets, what's the point of encrypting them with  
IPsec.  So we need to assume at least eavesdropping.

There are ways to protect a server against being swamped with offers.  
The stateless cookie forces returnable addresses, and that allows us  
to rate-limit requests by peer. It's not like all hope is lost the  
moment an attacker can eavesdrop and send spoofed packets. Regular IKE  
and IPsec can continue with no problem. SIR allows the attacker, by  
spoofing one INVALID_SPI packet and one CHECK_SPI(NACK) packet, to  
force the gateway to delete an IKE SA.

I agree that the CHECK_SPI protocol does not require additional state,  
but considering that the number of active CHECK_SPI exchanges is  
limited by the number of active IKE SAs, I'm not sure that's an  
important advantage.

Yoav

On Jun 24, 2008, at 11:01 AM, Frederic Detienne wrote:

> Hi Yoav,
>
> I may be missing something but let's partition the situation in two
> cases:
>
> 1) the attacker IS NOT in the middle
> ------------------------------------
> Can you explain how you remote-spoof a valid CHECK_SPI(NACK)|N(COOKIE)
> and force deletion ?
>
> 2) the attacker IS in the middle (eavesdropping or injecting)
> -------------------------------------------------------------
> The attacker can just swamp one of the IKE peers with offers and force
> many DH computations. Regardless of SIR.
>
>
> As for the statelessness, SIR does not consume _additional_ state when
> the procedure is triggered. The process is self-sustained and does not
> require storage for longer than the processing of a packet. No timers,
> no retransmissions... This is as little consumptions as we could
> imagine.
>
> regards,
>
> 	fred

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


From ipsec-bounces@ietf.org  Tue Jun 24 02:27:11 2008
Return-Path: 
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 250E73A693C;
	Tue, 24 Jun 2008 02:27:11 -0700 (PDT)
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 09F833A6962
	for ; Tue, 24 Jun 2008 02:27:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.499
X-Spam-Level: 
X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 
	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 9-p81oMthbSk for ;
	Tue, 24 Jun 2008 02:27:09 -0700 (PDT)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54])
	by core3.amsl.com (Postfix) with ESMTP id 166FF3A693C
	for ; Tue, 24 Jun 2008 02:27:09 -0700 (PDT)
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105)
	id CBA01294009; Tue, 24 Jun 2008 12:27:08 +0300 (IDT)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68])
	by dlpdemo.checkpoint.com (Postfix) with ESMTP id 07821294001;
	Tue, 24 Jun 2008 12:27:08 +0300 (IDT)
Received: from MBP.checkpoint.com (localhost [127.0.0.1])
	by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id
	m5O9R7jI025200; Tue, 24 Jun 2008 12:27:07 +0300 (IDT)
Message-Id: 
From: Yoav Nir 
To: ipsec@ietf.org, "Pasi.Eronen@nokia.com>" 
In-Reply-To: <9ED51A04-61B5-43D2-B93C-D356C0365E16@checkpoint.com>
Mime-Version: 1.0 (Apple Message framework v924)
Date: Tue, 24 Jun 2008 12:27:06 +0300
References: <485F394A.1090804@cisco.com>
	<5326E5DF-0D3E-4ADD-9647-785274E8A2A2@checkpoint.com>
	<1214222942.6828.205.camel@fdetienn-laptop>
	
	<1214294503.6654.23.camel@fdetienn-laptop>
	<9ED51A04-61B5-43D2-B93C-D356C0365E16@checkpoint.com>
X-Mailer: Apple Mail (2.924)
Subject: [IPsec] IPsec in Dublin?
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: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

Hi Pasi, all.

There was a lot of traffic on this mailing list lately about the  
possible formation of an IPsec extensions and maintenance working group.

However, I've just looked at the agenda for Dublin ( https://datatracker.ietf.org/meeting/72/agenda.html 
  ) and the active BoFs page ( http://www3.tools.ietf.org/bof/trac/ 
wiki ). Neither shows anything related to IPsec.

What gives?  Is there going to be a meeting in Dublin?

Yoav

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


From ipsec-bounces@ietf.org  Tue Jun 24 07:18:23 2008
Return-Path: 
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id EA5C43A6808;
	Tue, 24 Jun 2008 07:18:22 -0700 (PDT)
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 7EEDA3A6808
	for ; Tue, 24 Jun 2008 07:18:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 
	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 x39cV2FFuwpP for ;
	Tue, 24 Jun 2008 07:18:18 -0700 (PDT)
Received: from av-tac-bru.cisco.com (odd-brew.cisco.com [144.254.15.119])
	by core3.amsl.com (Postfix) with ESMTP id DFB1B3A67E6
	for ; Tue, 24 Jun 2008 07:18:17 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from strange-brew.cisco.com (localhost [127.0.0.1])
	by av-tac-bru.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id
	m5OEI5821646; Tue, 24 Jun 2008 16:18:05 +0200 (CEST)
Received: from [64.103.134.171] ([64.103.134.171])
	by strange-brew.cisco.com (8.11.7p3+Sun/8.11.7) with ESMTP id
	m5OEI3A23998; Tue, 24 Jun 2008 16:18:04 +0200 (CEST)
From: Frederic Detienne 
To: Yoav Nir 
In-Reply-To: <9ED51A04-61B5-43D2-B93C-D356C0365E16@checkpoint.com>
References: <485F394A.1090804@cisco.com>
	<5326E5DF-0D3E-4ADD-9647-785274E8A2A2@checkpoint.com>
	<1214222942.6828.205.camel@fdetienn-laptop>
	
	<1214294503.6654.23.camel@fdetienn-laptop>
	<9ED51A04-61B5-43D2-B93C-D356C0365E16@checkpoint.com>
Organization: Cisco
Date: Tue, 24 Jun 2008 16:18:05 +0200
Message-Id: <1214317086.6654.139.camel@fdetienn-laptop>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.2 
Cc: ipsec@ietf.org, Pratima Sethi 
Subject: Re: [IPsec] [Fwd: New Version Notification
	for	draft-detienne-ikev2-recovery-00]
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: fd@cisco.com
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

SGkgWW9hdiwKClJlYWRpbmcgdGhyb3VnaCwgSSB0aGluayB3ZSBuZWVkIHRvIGV4cG9zZSBhIGxp
dHRsZSBtb3JlIG9mIG91cgpyYXRpb25hbGUuCgpUaGUgdmVyaWZpY2F0aW9uIGV4Y2hhbmdlIChD
SEVDS19TUEkpIF9jb3VsZF8gaGF2ZSBiZWVuIGVtYmVkZGVkIGludG8gYW4KSUtFIG5lZ290aWF0
aW9uLiBJdCBpcyBub25ldGhlbGVzcyBuZWNlc3NhcnkgZm9yIHRoZSBzZWN1cml0eSBvZiB0aGUK
cHJvdG9jb2wuCgpCeSBzZXBhcmF0aW5nIHRoZSBDSEVDS19TUEkgZXhjaGFuZ2UgZnJvbSB0aGUg
SUtFIG5lZ290aWF0aW9uLCB3ZSB0aGluawp0aGUgcHJvdG9jb2wgaXMgY2xlYXJlciB0byB1bmRl
cnN0YW5kIGJ1dCBhbHNvIG1vcmUgbW9kdWxhci4gRm9yCmluc3RhbmNlLCBpdCBhbGxvd3MgdXNp
bmcgSUtFIFJlc3VtcHRpb24gb3IgYW55IGZ1cnRoZXIgZXh0ZW5zaW9uLgoKQW5zd2VycyBpbmxp
bmUuCgpPbiBUdWUsIDIwMDgtMDYtMjQgYXQgMTE6MzMgKzAzMDAsIFlvYXYgTmlyIHdyb3RlOgo+
IEhpIEZyZWQsCj4gCj4gSSB0aGluayB0aGUgZmlyc3QgY2FzZSBpcyBub3QgaW50ZXJlc3Rpbmcs
IGJlY2F1c2UgaWYgdGhlIGF0dGFja2VyICAKPiBjYW4ndCBzZWUgb3VyIHBhY2tldHMsIHdoYXQn
cyB0aGUgcG9pbnQgb2YgZW5jcnlwdGluZyB0aGVtIHdpdGggIAo+IElQc2VjLiAgU28gd2UgbmVl
ZCB0byBhc3N1bWUgYXQgbGVhc3QgZWF2ZXNkcm9wcGluZy4KCkJlY2F1c2UgdGhlcmUgYXJlIHNl
dmVyYWwgdHlwZXMgb2YgYXR0YWNrZXJzOiB0aG9zZSB3aG8gd2FudCB5b3VyIGRhdGEKYW5kIHRo
b3NlIHdobyB3YW50IHRvIHByZXZlbnQgeW91IGZyb20gY29uZHVjdGluZyBidXNpbmVzcy4gWW91
IG5lZWQKZW5jcnlwdGlvbiBhZ2FpbnN0IHRoZSBmb3JtZXIgYW5kIChyZW1vdGUpIERvUyBwcm90
ZWN0aW9uIGFnYWluc3QgdGhlCmxhdHRlci4KClJlbW90ZSBEb1MgYXJlIGNvbW1vbiBlbm91Z2gg
dG8gYmUgdGFrZW4gY2FyZSBvZi4KCkJ1dCBTSVIgaXMgc2FmZSBoZXJlIGFueXdheSBzbyBsZXQn
cyBpZ25vcmUgdGhpcyBjYXNlIGZvciBub3cuIDopCgo+IFRoZXJlIGFyZSB3YXlzIHRvIHByb3Rl
Y3QgYSBzZXJ2ZXIgYWdhaW5zdCBiZWluZyBzd2FtcGVkIHdpdGggb2ZmZXJzLiAgCj4gVGhlIHN0
YXRlbGVzcyBjb29raWUgZm9yY2VzIHJldHVybmFibGUgYWRkcmVzc2VzLCBhbmQgdGhhdCBhbGxv
d3MgdXMgIAo+IHRvIHJhdGUtbGltaXQgcmVxdWVzdHMgYnkgcGVlci7vu78gSXQncyBub3QgbGlr
ZSBhbGwgaG9wZSBpcyBsb3N0IHRoZSAgCj4gbW9tZW50IGFuIGF0dGFja2VyIGNhbiBlYXZlc2Ry
b3AgYW5kIHNlbmQgc3Bvb2ZlZCBwYWNrZXRzLiBSZWd1bGFyIElLRSAgCj4gYW5kIElQc2VjIGNh
biBjb250aW51ZSB3aXRoIG5vIHByb2JsZW0uCgpJZiB5b3VyIGF0dGFja2VyIChNaXRNKSBpcyBj
bG9zZSB0byB0aGUgZ2F0ZXdheSBhbmQgY2FuIHNub29wIGFuZCBzcG9vZiwKaGUgd2lsbCBhcHBl
YXIgYXMgaGF2aW5nIHJldHVybmFibGUgYWRkcmVzc2VzLiBJbiBmYWN0LCB0aGUgYXR0YWNrZXIg
Y2FuCnNwb29mIHRoZSBlbnRpcmUgImNvbmUiIG9mIGFkZHJlc3NlcyBpbiBmcm9udCBvZiB3aGlj
aCBoZSBpcyBsb2NhdGVkLgoKQWdhaW4sIGxldCdzIGFueXdheSB0YWtlIHlvdXIgYXNzdW1wdGlv
biB0aGF0IElLRSBhbmQgSVBzZWMgY2FuIGNvbnRpbnVlCmRlc3BpdGUgdGhyb3R0bGVkIGtleWlu
Zy4KCj4gIFNJUiBhbGxvd3MgdGhlIGF0dGFja2VyLCBieSAgCj4gc3Bvb2Zpbmcgb25lIElOVkFM
SURfU1BJIHBhY2tldCBhbmQgb25lIENIRUNLX1NQSShOQUNLKSBwYWNrZXQsIHRvICAKPiBmb3Jj
ZSB0aGUgZ2F0ZXdheSB0byBkZWxldGUgYW4gSUtFIFNBLgoKVGhpcyBpcyB3aGVyZSBkYW1wZW5p
bmcgY29tZXMgaW50byBwbGF5LiBJIGFkbWl0IFNJUiBkcmFmdCBsYWNrcyBjbGFyaXR5CmFib3V0
IGhhbmRsaW5nIG1hbi1pbi10aGUtbWlkZGxlLiBXZSB3aWxsIGVtcGhhc2l6ZSB0aGlzLgoKPkZy
b20gdGhlIHByZXZpb3VzIG1haWwsIHdlIGFyZSBpbiBhIHNpdHVhdGlvbiBhc3N1bWluZyB0aGUg
YXR0YWNrZXIgaXMKY2FuIGVhdmVzZHJvcCAoc25vb3ApIGFuZCBpbmplY3QgKHNwb29mKS4KCkxl
dCdzIHBhcnRpdGlvbiB0aGUgc2l0dWF0aW9uICgyIGNhc2VzKToKCu+7vzEpIHRoZSBhdHRhY2tl
ciBDQU4gYmxvY2sgcGFja2V0cwotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KSW4g
Y2xlYXI6IHRoZSBhdHRhY2tlciBjYW4gc3Bvb2YgYW5kIHNub29wIGFuZCBjYW4gZGlzY2FyZCBw
YWNrZXRzIGluCnRyYW5zaXQuCgpUaGVuIHRoZSBhdHRhY2tlciBjYW4ganVzdCBkcm9wIGFsbCBF
U1AvSUtFIHBhY2tldHMuIExldCdzIGp1c3QgYmUgZG9uZQp3aXRoIHRoYXQgOikKCjIpIHRoZSBh
dHRhY2tlciBDQU4gTk9UIGJsb2NrIHBhY2tldHMKLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLQoKMi4xKSBQb3NzaWJsZSBsaW5lIG9mIGRlZmVuc2UKLi4uLi4uLi4uLi4uLi4u
Li4uLi4uLi4uLi4uLi4KQW4gSU5WQUxJRF9TUEkgY2FuIGJlIHNwb29mZWQgYnkgdGhlIGF0dGFj
a2VyIChhbGxlZ2VkbHkgZnJvbSBBbGljZSksCmZvcmNpbmcgYSBDSEVDS19TUEkoUVVFUlkpIGZy
b20gQm9iLiBUaGUgYXR0YWNrZXIgc3Bvb2ZzIGJhY2sKQ0hFQ0tfU1BJKE5BQ0spLiBTaW5jZSB0
aGUgYXR0YWNrZXIgY2FuIG5vdCBibG9jayBwYWNrZXRzLCB0aGUKSU5WQUxJRF9TUEkgd2lsbCBh
bHNvIHJlYWNoIEFsaWNlLCB3aG8gd2lsbCByZXBseSB3aXRoIENIRUNLX1NQSShBQ0spLgoKQm9i
IHJlY2VpdmVzIENIRUNLX1NQSShOQUNLKSBmaXJzdCBidXQgaWYgaGUgd2FpdHMgZm9yIGEgZmV3
IG1zZWMgYmVmb3JlCmNyZWF0aW5nIGEgbmV3IFNBLCBoZSB3aWxsIHJlY2VpdmUgQk9USCBhIENI
RUNLX1NQSShBQ0spIGFuZCBhCkNIRUNLX1NQSShOQUNLKS4gV2hpY2ggaXMgZHViaW91cy4gVGhl
IFNJUiBwcm9jZXNzIHNob3VsZCB0aGVuIHN0b3AgYW5kCmxvZyBhbiBlcnJvci4uLiBzYXZpbmcg
dGhlIFNBLgoKVGhlIHByb2Nlc3MgaXMgaWxsdXN0cmF0ZWQgYmVsb3c6CgogICBBbGljZSAgICAg
ICAgICAgICBNYWxsZXQgICAgICAgICAgICAgICAgIEJvYgogICAgICAgICAgICAgICAgICAgICAg
ICAgSW52IFNQSQogICAgICAgICAgICAgICAgICAgICAgICAgLS0tLS0tLS0tLS0tLS0tLS0tPgoK
ICAgICAgICAgICAgICAgICAgICAgICAgICAgIENIRUNLX1NQSShRVUVSWSkKICAgICAgPC0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0KCu+7vyAgICAgICAgICAgICAgICAgICAg
ICAgICBDSEVDS19TUEkoTkFDSykKICAgICAgICAgICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0t
LS0tLS0tLT4gU2hvdWxkIHJla2V5IGJ1dCB3YWl0CiAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGEgZmV3IG1zZWMKCiAgICAgIENIRUNLX1NQSShBQ0spCiAgICAg
IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+IEhpbnQgb2YgYXR0YWNrID0+
IG5vIHJla2V5CgpXZSBmZWx0IHRoaXMgbWVjaGFuaXNtIHdhcyByZWR1bmRhbnQgYW5kIGhhcyBi
ZWVuIHJlbW92ZWQgZnJvbSBvdXIKZHJhZnQuIFdlIGNvdWxkIGRldmVsb3AgaXQgaWYgbmVjZXNz
YXJ5LgoKMi4yKSBTZWNvbmQgbGluZSBvZiBkZWZlbnNlCi4uLi4uLi4uLi4uLi4uLi4uLi4uLi4u
Li4uLgpJZiB0aGUgYXR0YWNrIG1ha2VzIGl0IHRocm91Z2ggbm9uZXRoZWxlc3MsIHRoZSBTQSBp
cyBnb2luZyB0byByZW1haW4KZGFtcGVuZWQgZm9yIGEgY29uZmlndXJhYmxlIGFtb3VudCBvZiB0
aW1lLiBJLmUuIFNJUiBmb3JiaWRzIHRoYXQgd2UKbWFrZSBhIHN1YnNlcXVlbnQgcmVjb3Zlcnkg
aW4gdGhhdCAic2FmZSIgdGltZSBzbyB0aGVyZSBpcyBubyB3YXkgdG8KZm9yY2UgcmVwZXRpdGl2
ZSByZWtleXMuIEFsbCB0aGUgYXR0YWNrZXIgZ2FpbnMgaXMgYSBzaW5nbGUgImJ1bXAiIGluCnRo
ZSBjb250cm9sIHBsYW5lLgoKMi4zKSBVbHRpbWF0ZWx5Ci4uLi4uLi4uLi4uLi4uLgpNb3N0IGlt
cG9ydGFudGx5LCBpdCBpcyBvbmx5IGF0IHRoZSBlbmQgb2YgdGhlIHJla2V5IHRoYXQgdGhlIG9s
ZCBTQSdzCnNob3VsZCBiZSBkaXNjYXJkZWQuIFdoaWNoIG1lYW5zIHRoYXQgYSBkYXRhIHBsYW5l
IChDSElMRF9TQSdzKSBpcwphdmFpbGFibGUgYWxsIHRoZSB3YXkgdGhyb3VnaCBhbmQgd2Ugc2hv
dWxkIG5vdCBoYXZlIGxvc3QgZGF0YSBwYWNrZXRzLgoKU28gaWYgQm9iIGNhbiBjb3BlIHdpdGgg
SUtFIHRocm90dGxlZCBmbG9vZGluZyB3aGlsZSBzdGlsbCBwcm9jZXNzaW5nCmRhdGEgdHJhZmZp
YywgdGhlbiAyLjIgYW5kIDIuMyBjYW4gZGVhbCB3aXRoIHRoZSBldmVuLW1vcmUtdGhyb3R0bGVk
CiJ1bmR1ZSByZWNvdmVyeSIgY2FzZSBieSB0aGUgTWl0TS4gQWxsIHRoaXMgd2l0aG91dCBpbnRl
cnJ1cHRpb24uCgo+IEkgYWdyZWUgdGhhdCB0aGUgQ0hFQ0tfU1BJIHByb3RvY29sIGRvZXMgbm90
IHJlcXVpcmUgYWRkaXRpb25hbCBzdGF0ZSwgIAo+IGJ1dCBjb25zaWRlcmluZyB0aGF0IHRoZSBu
dW1iZXIgb2YgYWN0aXZlIENIRUNLX1NQSSBleGNoYW5nZXMgaXMgIAo+IGxpbWl0ZWQgYnkgdGhl
IG51bWJlciBvZiBhY3RpdmUgSUtFIFNBcywgSSdtIG5vdCBzdXJlIHRoYXQncyBhbiAgCj4gaW1w
b3J0YW50IGFkdmFudGFnZS4KClRoaXMgaXMgdHJ1ZSBpbiBzb21lIGNhc2VzIGJ1dCBub3QgYWxs
IGRldmljZXMgYXJlIGhpZ2ggZW5kIHdpdGggbG9hZHMKb2YgQ1BVIGFuZCBtZW1vcnkuIFNvbWUg
aGlnaCBlbmQgZGV2aWNlcyBhbHNvIGhhcHBlbiB0byBiZSBmYWlybHkgYnVzeS4gCgpXZSBjb3Vs
ZCBzYXZlIHJlc291cmNlIHNvIHdlIGRpZCBpdC4gQW55d2F5LCB0aGUgY29va2llIGNhbiBiZSBh
bnl0aGluZwoobGlrZSBhIGdvb2QgcmFuZG9tIG51bWJlcikgYW5kIHRoZSBpbXBsZW1lbnRhdGlv
biBjb3VsZCBkZWNpZGUgdG8ga2VlcApzdGF0ZSB3aXRob3V0IGJyZWFraW5nIHRoZSBwcm90b2Nv
bCBpZiB5b3UgbGlrZSBpdCB0by4KCu+7v3JlZ2FyZHMsCgogICAgZnJlZAoKCj4gWW9hdgo+IAo+
IE9uIEp1biAyNCwgMjAwOCwgYXQgMTE6MDEgQU0sIEZyZWRlcmljIERldGllbm5lIHdyb3RlOgo+
IAo+ID4gSGkgWW9hdiwKPiA+Cj4gPiBJIG1heSBiZSBtaXNzaW5nIHNvbWV0aGluZyBidXQgbGV0
J3MgcGFydGl0aW9uIHRoZSBzaXR1YXRpb24gaW4gdHdvCj4gPiBjYXNlczoKPiA+Cj4gPiAxKSB0
aGUgYXR0YWNrZXIgSVMgTk9UIGluIHRoZSBtaWRkbGUKPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLQo+ID4gQ2FuIHlvdSBleHBsYWluIGhvdyB5b3UgcmVtb3RlLXNwb29m
IGEgdmFsaWQgQ0hFQ0tfU1BJKE5BQ0spfE4oQ09PS0lFKQo+ID4gYW5kIGZvcmNlIGRlbGV0aW9u
ID8KPiA+Cj4gPiAyKSB0aGUgYXR0YWNrZXIgSVMgaW4gdGhlIG1pZGRsZSAoZWF2ZXNkcm9wcGlu
ZyBvciBpbmplY3RpbmcpCj4gPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tCj4gPiBUaGUgYXR0YWNrZXIgY2FuIGp1c3Qgc3dhbXAg
b25lIG9mIHRoZSBJS0UgcGVlcnMgd2l0aCBvZmZlcnMgYW5kIGZvcmNlCj4gPiBtYW55IERIIGNv
bXB1dGF0aW9ucy4gUmVnYXJkbGVzcyBvZiBTSVIuCj4gPgo+ID4KPiA+IEFzIGZvciB0aGUgc3Rh
dGVsZXNzbmVzcywgU0lSIGRvZXMgbm90IGNvbnN1bWUgX2FkZGl0aW9uYWxfIHN0YXRlIHdoZW4K
PiA+IHRoZSBwcm9jZWR1cmUgaXMgdHJpZ2dlcmVkLiBUaGUgcHJvY2VzcyBpcyBzZWxmLXN1c3Rh
aW5lZCBhbmQgZG9lcyBub3QKPiA+IHJlcXVpcmUgc3RvcmFnZSBmb3IgbG9uZ2VyIHRoYW4gdGhl
IHByb2Nlc3Npbmcgb2YgYSBwYWNrZXQuIE5vIHRpbWVycywKPiA+IG5vIHJldHJhbnNtaXNzaW9u
cy4uLiBUaGlzIGlzIGFzIGxpdHRsZSBjb25zdW1wdGlvbnMgYXMgd2UgY291bGQKPiA+IGltYWdp
bmUuCj4gPgo+ID4gcmVnYXJkcywKPiA+Cj4gPiAJZnJlZAoKX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX18KSVBzZWMgbWFpbGluZyBsaXN0CklQc2VjQGlldGYu
b3JnCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMK


From ipsec-bounces@ietf.org  Tue Jun 24 09:16:12 2008
Return-Path: 
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 38D773A6A6F;
	Tue, 24 Jun 2008 09:16:12 -0700 (PDT)
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 43B6928C13B
	for ; Tue, 24 Jun 2008 09:16:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level: 
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 v06xm4wRIrcy for ;
	Tue, 24 Jun 2008 09:16:09 -0700 (PDT)
Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.145])
	by core3.amsl.com (Postfix) with ESMTP id 0B2273A6A68
	for ; Tue, 24 Jun 2008 09:16:08 -0700 (PDT)
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234])
	by e5.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m5OGG9n7020185
	for ; Tue, 24 Jun 2008 12:16:09 -0400
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id
	m5OGFsEP168734 for ; Tue, 24 Jun 2008 12:15:54 -0400
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1])
	by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id
	m5OGFsS8019229 for ; Tue, 24 Jun 2008 12:15:54 -0400
Received: from d01mll83.pok.ibm.com (d01mll83.pok.ibm.com [9.57.160.143])
	by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id
	m5OGFsRc019223 for ; Tue, 24 Jun 2008 12:15:54 -0400
To: ipsec@ietf.org
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
Message-ID: 
From: David Wierbowski 
Date: Tue, 24 Jun 2008 12:15:52 -0400
X-MIMETrack: Serialize by Router on D01MLL83/01/M/IBM(Release 7.0.2FP2|April
	16, 2007) at 06/24/2008 12:15:54
MIME-Version: 1.0
Subject: [IPsec] Simultaneous re-authentication of an IKE_SA
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: ,
	
Content-Type: multipart/mixed; boundary="===============1169115584=="
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

--===============1169115584==
Content-type: multipart/alternative; 
	Boundary="0__=0ABBFEE1DFC0E6598f9e8a93df938690918c0ABBFEE1DFC0E659"
Content-Disposition: inline

--0__=0ABBFEE1DFC0E6598f9e8a93df938690918c0ABBFEE1DFC0E659
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: quoted-printable



RFC 4718 highlights the difference between re-keying an IKE_SA and
re-authenticating an IKE_SA; however, it does not address the issue of =
both
peers simultaneously re-authenticating an IKE_SA.

Re-authentication of an IKE_SA involves creating a new IKE_SA from scra=
tch
(using the initial exchanges), creating new CHILD_SAs within the new
IKE_SA, and finally deleting the old IKE_SA.  The window between sendin=
g
the SA_INIT request and deleting the IKE_SA is relatively significant i=
n
size.

Unlike the re-keying, there is nothing that ties the IKE_SA being
re-authenticated to the new IKE_SA.  How can one even detect that a
simultaneous re-authentication has even occurred?

Much of the previous discussion on the mailing list about re-authentica=
tion
of the IKE_SA was in an EAP context.  I am asking this question is in a=

non-EAP context.

The concern is that if a simultaneous re-authentication goes undetected=

that both peers will end up with 2 identical IKE_SAs.  In a worst case
scenario the peers will simultaneously re-authenticate both the new IKE=
_SAs
and then end up with 4  identical IKE_SAs, and so on.


Dave Wierbowski

z/OS Comm Server Developer=

--0__=0ABBFEE1DFC0E6598f9e8a93df938690918c0ABBFEE1DFC0E659
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline
Content-transfer-encoding: quoted-printable



RFC 4718 highlights the difference between re-keying an IKE_SA and r=
e-authenticating an IKE_SA; however, it does not address the issue of b=
oth peers simultaneously re-authenticating an IKE_SA. 



Re-authentication of an IKE_SA involves creating a new IKE_SA from scra=
tch (using the initial exchanges), creating new CHILD_SAs within the ne=
w IKE_SA, and finally deleting the old IKE_SA.  The window between send=
ing the SA_INIT request and deleting the IKE_SA is relatively significa=
nt in size.



Unlike the re-keying, there is nothing that ties the IKE_SA being re-au=
thenticated to the new IKE_SA.  How can one even detect that a  simulta=
neous re-authentication has even occurred?  



Much of the previous discussion on the mailing list about re-authentica=
tion of the IKE_SA was in an EAP context.  I am asking this question is=
 in a non-EAP context.



The concern is that if a simultaneous re-authentication goes undetected=
 that both peers will end up with 2 identical IKE_SAs.  In a worst case=
 scenario the peers will simultaneously re-authenticate both the new IK=
E_SAs and then end up with 4  identical IKE_SAs, and so on. 





Dave Wierbowski 



z/OS Comm Server Developer =

--0__=0ABBFEE1DFC0E6598f9e8a93df938690918c0ABBFEE1DFC0E659--


--===============1169115584==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1169115584==--



From ipsec-bounces@ietf.org  Tue Jun 24 09:30:04 2008
Return-Path: 
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 772BD28C124;
	Tue, 24 Jun 2008 09:30:04 -0700 (PDT)
X-Original-To: ipsec@ietf.org
Delivered-To: ipsec@core3.amsl.com
Received: by core3.amsl.com (Postfix, from userid 0)
	id 66CF63A6A69; Tue, 24 Jun 2008 09:30:01 -0700 (PDT)
From: IESG Secretary 
To: ietf-announce@ietf.org
Mime-Version: 1.0
Message-Id: <20080624163001.66CF63A6A69@core3.amsl.com>
Date: Tue, 24 Jun 2008 09:30:01 -0700 (PDT)
Cc: ipsec@ietf.org
Subject: [IPsec] WG Review: IP Security Maintenance and Extensions (ipsecme)
X-BeenThere: ipsec@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: iesg@ietf.org
List-Id: Discussion of IPsec protocols 
List-Unsubscribe: ,
	
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

A new IETF working group has been proposed in the Security Area.  The IESG
has not made any determination as yet.  The following draft charter was
submitted, and is provided for informational purposes only.  Please send
your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, July 1,
2008.


IP Security Maintenance and Extensions (ipsecme)
------------------------------------------------
Last Modified: June 19, 2008

Current Status: Proposed Working Group

Chair(s): TBD

Mailing Lists:

General Discussion: ipsec@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec
Archive: http://www.ietf.org/mail-archive/web/ipsec/

The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated
RFCs), IKEv2 (RFC 4106, RFC 4718, and associated RFCs), and the IPsec
security architecture (RFC 4301). IPsec is widely deployed in VPN
gateways, VPN remote access clients, and as a substrate for
host-to-host, host-to-network, and network-to-network security.

The IPsec Maintenance and Extensions Working Group will continue the
work of the earlier IPsec Working Group which was concluded in 2005. Its
purpose is to maintain the IPsec standard and to facilitate discussion
of clarifications, improvements, and extensions and improvements to
IPsec, mostly to IKEv2. The working group will also be a focus point for
other IETF Working Groups who use IPsec in their own protocols.

The initial set of work items is:

- A revision to IKEv2 (RFC 4306) that incorporates the clarifications
from RFC 4718, and otherwise improves the quality of the specification,
taking into account implementation and interoperability experience. In
some cases, the revision may include small technical corrections;
however, impact on existing implementations must be considered. Major
changes and adding new features is beyond the scope of this work
item. The starting point for this work is draft-hoffman-ikev2bis.

- An IPsec document roadmap that describes the various RFC documents
covering IPsec, including both the core RFC 240x and RFC 430x versions
of IPsec, and extensions specified in other documents. Sections 2 and 3
of RFC 2411 can provide useful material, but the expected scope is
slightly different from RFC 2411. This document will be informational.

- A standards-track extension to IKEv2 that provides full IPv6 support
for IPsec remote access clients that use configuration payloads. This
work will be based on draft-eronen-ipsec-ikev2-ipv6-config. The WG shall
solicit help and reviews from the 6MAN WG to ensure that all aspects of
IPv6 are properly considered.

- A standards-track extension that allows an IPsec remote access client
to "resume" a session with a gateway; that is, to skip certain parts of
IKE negotation when connecting again to the same gateway (or possibly a
cluster of closely cooperating gateways). The idea is similar to TLS
session resumption without server-side state, specified in RFC 5077.

The main goals for this extension are to avoid public-key computations
(to reduce VPN gateway load when a large number of clients reconnect to
the geteway within a short period of time, such as following a network
outage), and remove the need for user interaction for authentication
(which may be required by some authentication mechanisms). The extension
shall not have negative impact on IKEv2 security features.

Failover from one gateway to another, mechanisms for detecting when a
session should be resumed, and specifying communication mechanisms
between gateways are beyond the scope of this work item. Specifying the
detailed contents of the "session ticket" is also beyond the scope of
this document; if there is sufficient interest, this could be specified
later in a separate document.

To the degree its content falls within the scope of this work item, text
and ideas from draft-sheffer-ipsec-failover will be used as a starting
point.

- A standards-track extension to IPsec that allows an IPsec remote
access gateway to redirect VPN clients to another gateway. This
extension should be aligned with the session resumption extension,
(the previous work item), and if so decided by the WG, could be
specified in the same document. The starting point will be
draft-devarapalli-ipsec-ikev2-redirect.

- A standards-track mechanism that allows an intermediary device, such
as a firewall or intrusion detection system, to easily and reliably
determine whether an ESP packet is encrypted with the NULL cipher; and
if it is, determine the location of the actual payload data inside the
packet. The starting points for this work item are
draft-grewal-ipsec-traffic-visibility and draft-hoffman-
esp-null-protocol.

The initial scope of the WG is restricted to the work items listed
above. The WG shall not consider adding new work items until one or more
of its documents progress to IESG evaluation. At that time, the WG can
propose rechartering.

Chartering this WG is not intended to have effect on documents that
beyond the initial scope. In particular, work on IPsec extensions that
are not included in this charter can happen as usual in other WGs (and
there are currently several other WGs working on IPsec extensions; for
example, BTNS and ROHC), or as individual submissions.

This charter will expire in July 2010 (24 months from approval). If
the charter is not updated before that time, the WG will be closed and
any remaining documents revert back to individual Internet-Drafts.

Milestones:

Dec 2008 WG last call on IPv6 configuration payloads
Dec 2008 WG last call on IPsec roadmap
Jan 2009 WG last call on session resumption
Feb 2009 WG last call on redirect
Mar 2009 WG last call on IKEv2bis
Apr 2009 WG last call on ESP NULL traffic visibility
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


From ipsec-bounces@ietf.org  Tue Jun 24 09:46:08 2008
Return-Path: 
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 3C2193A68DC;
	Tue, 24 Jun 2008 09:46:08 -0700 (PDT)
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 1F5783A680D
	for ; Tue, 24 Jun 2008 09:46:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 L2oDAR-8ArVM for ;
	Tue, 24 Jun 2008 09:46:06 -0700 (PDT)
Received: from mga09.intel.com (mga09.intel.com [134.134.136.24])
	by core3.amsl.com (Postfix) with ESMTP id ACD553A682A
	for ; Tue, 24 Jun 2008 09:46:05 -0700 (PDT)
Received: from orsmga001.jf.intel.com ([10.7.209.18])
	by orsmga102.jf.intel.com with ESMTP; 24 Jun 2008 01:43:21 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.27,697,1204531200"; d="scan'208";a="401435120"
Received: from fmsmsx334.amr.corp.intel.com ([132.233.42.1])
	by orsmga001.jf.intel.com with ESMTP; 24 Jun 2008 09:45:50 -0700
Received: from fmsmsx881.amr.corp.intel.com ([10.19.19.13]) by
	fmsmsx334.amr.corp.intel.com with Microsoft SMTPSVC(6.0.3790.1830); 
	Tue, 24 Jun 2008 09:46:05 -0700
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Tue, 24 Jun 2008 09:46:04 -0700
Message-ID: 
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IPsec ESP traffic visibility
Thread-Index: AcjV3IksPELVaQ7uTjaL+BD3ZAAdNgAOxmRw
References: <485F394A.1090804@cisco.com><5326E5DF-0D3E-4ADD-9647-785274E8A2A2@checkpoint.com><1214222942.6828.205.camel@fdetienn-laptop><1214294503.6654.23.camel@fdetienn-laptop><9ED51A04-61B5-43D2-B93C-D356C0365E16@checkpoint.com>
	
From: "Grewal, Ken" 
To: ,
	
X-OriginalArrivalTime: 24 Jun 2008 16:46:05.0511 (UTC)
	FILETIME=[CB66FD70:01C8D619]
Subject: [IPsec] IPsec ESP traffic visibility
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: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

Pasi, All, 

An updated draft on IPsec ESP traffic visibility is now available. This
is to support the IPsec traffic visibility deliverable in the proposed
IP Security Maintenance and Extensions (ipsecme) charter. 

http://tools.ietf.org/html/draft-grewal-ipsec-traffic-visibility-01

Look forward to your feedback.

Thanks, 
- Ken
 
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


From ipsec-bounces@ietf.org  Wed Jun 25 00:37:30 2008
Return-Path: 
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id E43193A6830;
	Wed, 25 Jun 2008 00:37:30 -0700 (PDT)
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 3D2163A6830
	for ; Wed, 25 Jun 2008 00:37:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level: 
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5
	tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 fEEGwJLnBOKE for ;
	Wed, 25 Jun 2008 00:37:29 -0700 (PDT)
Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230])
	by core3.amsl.com (Postfix) with ESMTP id 328AC3A679F
	for ; Wed, 25 Jun 2008 00:37:29 -0700 (PDT)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com
	[10.160.244.31])
	by mgw-mx03.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id
	m5P7b6Lm019393; Wed, 25 Jun 2008 10:37:27 +0300
Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by
	vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); 
	Wed, 25 Jun 2008 10:37:26 +0300
Received: from vaebe104.NOE.Nokia.com ([10.160.244.59]) by
	esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); 
	Wed, 25 Jun 2008 10:37:26 +0300
x-mimeole: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Date: Wed, 25 Jun 2008 10:37:25 +0300
Message-ID: <1696498986EFEC4D9153717DA325CB72FD36D4@vaebe104.NOE.Nokia.com>
In-Reply-To: 
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: IPsec in Dublin?
Thread-Index: AcjV3Hz2cqbcpkLqSGiEkqrrZMaSowAuTTsA
References: <485F394A.1090804@cisco.com>
	<5326E5DF-0D3E-4ADD-9647-785274E8A2A2@checkpoint.com>
	<1214222942.6828.205.camel@fdetienn-laptop>
	
	<1214294503.6654.23.camel@fdetienn-laptop>
	<9ED51A04-61B5-43D2-B93C-D356C0365E16@checkpoint.com>
	
From: 
To: , 
X-OriginalArrivalTime: 25 Jun 2008 07:37:26.0433 (UTC)
	FILETIME=[50841110:01C8D696]
X-Nokia-AV: Clean
Subject: Re: [IPsec] IPsec in Dublin?
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: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

It's not a BOF, and the WG hasn't been approved yet (the
charter text was sent to ietf-announce for public review
yesterday, so the earliest possibility for approval is 
the IESG telechat on July 3rd). 

If it gets approved in time (where "in time" partly 
depends on goodwill from the secretariat :-), it will
meet in Dublin.

Best regards,
Pasi 

> -----Original Message-----
> From: ext Yoav Nir [mailto:ynir@checkpoint.com] 
> Sent: 24 June, 2008 12:27
> To: ipsec@ietf.org; Eronen Pasi (Nokia-NRC/Helsinki)
> Subject: IPsec in Dublin?
> 
> Hi Pasi, all.
> 
> There was a lot of traffic on this mailing list lately about the  
> possible formation of an IPsec extensions and maintenance 
> working group.
> 
> However, I've just looked at the agenda for Dublin ( 
> https://datatracker.ietf.org/meeting/72/agenda.html 
>   ) and the active BoFs page ( http://www3.tools.ietf.org/bof/trac/ 
> wiki ). Neither shows anything related to IPsec.
> 
> What gives?  Is there going to be a meeting in Dublin?
> 
> Yoav
> 
> 
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec


From ipsec-bounces@ietf.org  Wed Jun 25 03:17:09 2008
Return-Path: 
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 742C63A68A2;
	Wed, 25 Jun 2008 03:17:09 -0700 (PDT)
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 27FD63A6995
	for ; Wed, 25 Jun 2008 03:17:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.524
X-Spam-Level: 
X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.075, 
	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 zaxC3WpO1S4t for ;
	Wed, 25 Jun 2008 03:17:08 -0700 (PDT)
Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54])
	by core3.amsl.com (Postfix) with ESMTP id CE1C53A68A2
	for ; Wed, 25 Jun 2008 03:17:07 -0700 (PDT)
Received: by dlpdemo.checkpoint.com (Postfix, from userid 105)
	id ECA36294015; Wed, 25 Jun 2008 13:17:04 +0300 (IDT)
Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68])
	by dlpdemo.checkpoint.com (Postfix) with ESMTP id 96DF2294004;
	Wed, 25 Jun 2008 13:17:03 +0300 (IDT)
Received: from MBP.checkpoint.com (localhost [127.0.0.1])
	by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id
	m5PAH2jI024331; Wed, 25 Jun 2008 13:17:02 +0300 (IDT)
Message-Id: <0632EFA9-177D-4A52-92B2-80CCA3A52D2F@checkpoint.com>
From: Yoav Nir 
To: David Wierbowski 
In-Reply-To: 
Mime-Version: 1.0 (Apple Message framework v924)
Date: Wed, 25 Jun 2008 13:17:02 +0300
References: 
X-Mailer: Apple Mail (2.924)
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Simultaneous re-authentication of an IKE_SA
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: ,
	
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

Hi David.

I agree that RFC 4718 is silent about simultaneous re-authentication.   
I guess the jitter recommendation should extend to re-authentication  
as well.

I guess we can recommend some text in the revision document saying  
that an IKE peer MUST NOT re-authenticate multiple IKE SAs with the  
same peer.  This should limit the amount of IKE SAs to (at most) two  
at a time.

If you're following the list, you will have noticed that a revision  
document for IKEv2 is planned for the hopefully-soon-to-be-formed  
IPsec extensions and maintenance working groups, so we can hope to fix  
this.

Yoav

On Jun 24, 2008, at 7:15 PM, David Wierbowski wrote:

> RFC 4718 highlights the difference between re-keying an IKE_SA and  
> re-authenticating an IKE_SA; however, it does not address the issue  
> of both peers simultaneously re-authenticating an IKE_SA.
>
> Re-authentication of an IKE_SA involves creating a new IKE_SA from  
> scratch (using the initial exchanges), creating new CHILD_SAs within  
> the new IKE_SA, and finally deleting the old IKE_SA. The window  
> between sending the SA_INIT request and deleting the IKE_SA is  
> relatively significant in size.
>
> Unlike the re-keying, there is nothing that ties the IKE_SA being re- 
> authenticated to the new IKE_SA. How can one even detect that a  
> simultaneous re-authentication has even occurred?
>
> Much of the previous discussion on the mailing list about re- 
> authentication of the IKE_SA was in an EAP context. I am asking this  
> question is in a non-EAP context.
>
> The concern is that if a simultaneous re-authentication goes  
> undetected that both peers will end up with 2 identical IKE_SAs. In  
> a worst case scenario the peers will simultaneously re-authenticate  
> both the new IKE_SAs and then end up with 4 identical IKE_SAs, and  
> so on.
>
>
> Dave Wierbowski
>
> z/OS Comm Server Developer
>
> Scanned by Check Point Total Security Gateway.
>
>
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec

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


From ipsec-bounces@ietf.org  Thu Jun 26 02:41:34 2008
Return-Path: 
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 80D063A69F7;
	Thu, 26 Jun 2008 02:41:34 -0700 (PDT)
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 190553A697C
	for ; Thu, 26 Jun 2008 02:41:33 -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=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 Iy7qow+8Ar2W for ;
	Thu, 26 Jun 2008 02:41:31 -0700 (PDT)
Received: from ti-out-0910.google.com (ti-out-0910.google.com [209.85.142.188])
	by core3.amsl.com (Postfix) with ESMTP id D26E53A6A65
	for ; Thu, 26 Jun 2008 02:41:30 -0700 (PDT)
Received: by ti-out-0910.google.com with SMTP id a6so2777092tib.25
	for ; Thu, 26 Jun 2008 02:41:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;
	h=domainkey-signature:received:received:message-id:date:from:to
	:subject:cc:in-reply-to:mime-version:content-type:references;
	bh=ZnEFNj7ck6qpkLEZrYYYeet0xEvRYkD3hsdZiIEpWvM=;
	b=VPs1rZlOgDgIcy1IESj1co5Vsvphxc6kA+UQmK3bYkZacOeVVyE2evLtfzEsh5nP9l
	r6+Y3NUnAYiOkcGEpiUCOmLrC9J0wUb7sF4JAXeNWV2t7jt/3uWSn+YffHMU5EpLV21p
	txYMtBOGDgvlwd/uwW2vBo4IrdiLjtsTEtXe0=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=message-id:date:from:to:subject:cc:in-reply-to:mime-version
	:content-type:references;
	b=vRFus+oVXtMXP4ipf/i6U+cvWa8MKSWBMT6Fy+f4PgQaCxyiuKFkD3bcKM+sTOQyPp
	q3OcDM5WW0BA1AjnvLhj3C8DObxDyXNxk+rOTXudSnkJzyOdbix8ky/LUktUhZOqUp7L
	xby5e6ueqW1E5XnAIVI34jxSgz5cvhN9PfNuE=
Received: by 10.110.49.6 with SMTP id w6mr9503007tiw.6.1214473289042;
	Thu, 26 Jun 2008 02:41:29 -0700 (PDT)
Received: by 10.110.53.11 with HTTP; Thu, 26 Jun 2008 02:41:28 -0700 (PDT)
Message-ID: <1d38a3350806260241y5579517br65c9265ec5ee6898@mail.gmail.com>
Date: Thu, 26 Jun 2008 17:41:28 +0800
From: "Hui Deng" 
To: iesg@ietf.org
In-Reply-To: <20080624163001.66CF63A6A69@core3.amsl.com>
MIME-Version: 1.0
References: <20080624163001.66CF63A6A69@core3.amsl.com>
Cc: ipsec@ietf.org
Subject: Re: [IPsec] WG Review: IP Security Maintenance and Extensions
	(ipsecme)
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: ,
	
Content-Type: multipart/mixed; boundary="===============1702505991=="
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

--===============1702505991==
Content-Type: multipart/alternative; 
	boundary="----=_Part_13621_29868835.1214473288989"

------=_Part_13621_29868835.1214473288989
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

Hello, all

There were some concern about the proposed "GRE key" work item
description sent earlier is *significantly* different from the
two individual drafts related to this topic.

We have updated the draft below and had several constructive
discussion in the ML later.
http://tools.ietf.org/id/draft-deng-ipsec-gre-key-ts-00.txt

In that case, we propose to consider the below work item
description which was writen by our AD, thanks.

o  A standards-track extension to IKEv2 to support using the "Key"
   field of Generic Routing Encapsulation (GRE) packets, specified
   in RFC 2890, as a traffic selector (in similar fashion as TCP/UDP
   port number or ICMP type/code fields). This allows different GRE
   traffic flows to be mapped to different IPsec SAs.  Any further
   extensions related to the use of IPsec with GRE are beyond the
   scope of this work item.

Regards,

-Hui

2008/6/25 IESG Secretary :

> A new IETF working group has been proposed in the Security Area.  The IESG
> has not made any determination as yet.  The following draft charter was
> submitted, and is provided for informational purposes only.  Please send
> your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, July 1,
> 2008.
>
>
> IP Security Maintenance and Extensions (ipsecme)
> ------------------------------------------------
> Last Modified: June 19, 2008
>
> Current Status: Proposed Working Group
>
> Chair(s): TBD
>
> Mailing Lists:
>
> General Discussion: ipsec@ietf.org
> To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec
> Archive: http://www.ietf.org/mail-archive/web/ipsec/
>
> The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated
> RFCs), IKEv2 (RFC 4106, RFC 4718, and associated RFCs), and the IPsec
> security architecture (RFC 4301). IPsec is widely deployed in VPN
> gateways, VPN remote access clients, and as a substrate for
> host-to-host, host-to-network, and network-to-network security.
>
> The IPsec Maintenance and Extensions Working Group will continue the
> work of the earlier IPsec Working Group which was concluded in 2005. Its
> purpose is to maintain the IPsec standard and to facilitate discussion
> of clarifications, improvements, and extensions and improvements to
> IPsec, mostly to IKEv2. The working group will also be a focus point for
> other IETF Working Groups who use IPsec in their own protocols.
>
> The initial set of work items is:
>
> - A revision to IKEv2 (RFC 4306) that incorporates the clarifications
> from RFC 4718, and otherwise improves the quality of the specification,
> taking into account implementation and interoperability experience. In
> some cases, the revision may include small technical corrections;
> however, impact on existing implementations must be considered. Major
> changes and adding new features is beyond the scope of this work
> item. The starting point for this work is draft-hoffman-ikev2bis.
>
> - An IPsec document roadmap that describes the various RFC documents
> covering IPsec, including both the core RFC 240x and RFC 430x versions
> of IPsec, and extensions specified in other documents. Sections 2 and 3
> of RFC 2411 can provide useful material, but the expected scope is
> slightly different from RFC 2411. This document will be informational.
>
> - A standards-track extension to IKEv2 that provides full IPv6 support
> for IPsec remote access clients that use configuration payloads. This
> work will be based on draft-eronen-ipsec-ikev2-ipv6-config. The WG shall
> solicit help and reviews from the 6MAN WG to ensure that all aspects of
> IPv6 are properly considered.
>
> - A standards-track extension that allows an IPsec remote access client
> to "resume" a session with a gateway; that is, to skip certain parts of
> IKE negotation when connecting again to the same gateway (or possibly a
> cluster of closely cooperating gateways). The idea is similar to TLS
> session resumption without server-side state, specified in RFC 5077.
>
> The main goals for this extension are to avoid public-key computations
> (to reduce VPN gateway load when a large number of clients reconnect to
> the geteway within a short period of time, such as following a network
> outage), and remove the need for user interaction for authentication
> (which may be required by some authentication mechanisms). The extension
> shall not have negative impact on IKEv2 security features.
>
> Failover from one gateway to another, mechanisms for detecting when a
> session should be resumed, and specifying communication mechanisms
> between gateways are beyond the scope of this work item. Specifying the
> detailed contents of the "session ticket" is also beyond the scope of
> this document; if there is sufficient interest, this could be specified
> later in a separate document.
>
> To the degree its content falls within the scope of this work item, text
> and ideas from draft-sheffer-ipsec-failover will be used as a starting
> point.
>
> - A standards-track extension to IPsec that allows an IPsec remote
> access gateway to redirect VPN clients to another gateway. This
> extension should be aligned with the session resumption extension,
> (the previous work item), and if so decided by the WG, could be
> specified in the same document. The starting point will be
> draft-devarapalli-ipsec-ikev2-redirect.
>
> - A standards-track mechanism that allows an intermediary device, such
> as a firewall or intrusion detection system, to easily and reliably
> determine whether an ESP packet is encrypted with the NULL cipher; and
> if it is, determine the location of the actual payload data inside the
> packet. The starting points for this work item are
> draft-grewal-ipsec-traffic-visibility and draft-hoffman-
> esp-null-protocol.
>
> The initial scope of the WG is restricted to the work items listed
> above. The WG shall not consider adding new work items until one or more
> of its documents progress to IESG evaluation. At that time, the WG can
> propose rechartering.
>
> Chartering this WG is not intended to have effect on documents that
> beyond the initial scope. In particular, work on IPsec extensions that
> are not included in this charter can happen as usual in other WGs (and
> there are currently several other WGs working on IPsec extensions; for
> example, BTNS and ROHC), or as individual submissions.
>
> This charter will expire in July 2010 (24 months from approval). If
> the charter is not updated before that time, the WG will be closed and
> any remaining documents revert back to individual Internet-Drafts.
>
> Milestones:
>
> Dec 2008 WG last call on IPv6 configuration payloads
> Dec 2008 WG last call on IPsec roadmap
> Jan 2009 WG last call on session resumption
> Feb 2009 WG last call on redirect
> Mar 2009 WG last call on IKEv2bis
> Apr 2009 WG last call on ESP NULL traffic visibility
> _______________________________________________
> IPsec mailing list
> IPsec@ietf.org
> https://www.ietf.org/mailman/listinfo/ipsec
>

------=_Part_13621_29868835.1214473288989
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


Hello, all


There were some concern about the proposed "GRE key" work item 
description sent earlier is *significantly* different from the
two individual drafts related to this topic.


We have updated the draft below and had several constructive 
discussion in the ML later.
http://tools.ietf.org/id/draft-deng-ipsec-gre-key-ts-00.txt



In that case, we propose to consider the below work item
description which was writen by our AD, thanks.


o  A standards-track extension to IKEv2 to support using the "Key" 
   field of Generic Routing Encapsulation (GRE) packets, specified 
   in RFC 2890, as a traffic selector (in similar fashion as TCP/UDP 

   port number or ICMP type/code fields). This allows different GRE 
   traffic flows to be mapped to different IPsec SAs.  Any further 
   extensions related to the use of IPsec with GRE are beyond the 
   scope of this work item.



Regards,


-Hui



2008/6/25 IESG Secretary <iesg-secretary@ietf.org>:


A new IETF working group has been proposed in the Security Area.  The IESG
has not made any determination as yet.  The following draft charter was

submitted, and is provided for informational purposes only.  Please send
your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, July 1,
2008.


IP Security Maintenance and Extensions (ipsecme)

------------------------------------------------
Last Modified: June 19, 2008

Current Status: Proposed Working Group

Chair(s): TBD

Mailing Lists:

General Discussion: ipsec@ietf.org

To Subscribe: https://www.ietf.org/mailman/listinfo/ipsec
Archive: http://www.ietf.org/mail-archive/web/ipsec/


The IPsec suite of protocols includes IKEv1 (RFC 2409 and associated
RFCs), IKEv2 (RFC 4106, RFC 4718, and associated RFCs), and the IPsec
security architecture (RFC 4301). IPsec is widely deployed in VPN
gateways, VPN remote access clients, and as a substrate for

host-to-host, host-to-network, and network-to-network security.

The IPsec Maintenance and Extensions Working Group will continue the
work of the earlier IPsec Working Group which was concluded in 2005. Its
purpose is to maintain the IPsec standard and to facilitate discussion

of clarifications, improvements, and extensions and improvements to
IPsec, mostly to IKEv2. The working group will also be a focus point for
other IETF Working Groups who use IPsec in their own protocols.

The initial set of work items is:


- A revision to IKEv2 (RFC 4306) that incorporates the clarifications
from RFC 4718, and otherwise improves the quality of the specification,
taking into account implementation and interoperability experience. In

some cases, the revision may include small technical corrections;
however, impact on existing implementations must be considered. Major
changes and adding new features is beyond the scope of this work
item. The starting point for this work is draft-hoffman-ikev2bis.


- An IPsec document roadmap that describes the various RFC documents
covering IPsec, including both the core RFC 240x and RFC 430x versions
of IPsec, and extensions specified in other documents. Sections 2 and 3

of RFC 2411 can provide useful material, but the expected scope is
slightly different from RFC 2411. This document will be informational.

- A standards-track extension to IKEv2 that provides full IPv6 support

for IPsec remote access clients that use configuration payloads. This
work will be based on draft-eronen-ipsec-ikev2-ipv6-config. The WG shall
solicit help and reviews from the 6MAN WG to ensure that all aspects of

IPv6 are properly considered.

- A standards-track extension that allows an IPsec remote access client
to "resume" a session with a gateway; that is, to skip certain parts of
IKE negotation when connecting again to the same gateway (or possibly a

cluster of closely cooperating gateways). The idea is similar to TLS
session resumption without server-side state, specified in RFC 5077.

The main goals for this extension are to avoid public-key computations

(to reduce VPN gateway load when a large number of clients reconnect to
the geteway within a short period of time, such as following a network
outage), and remove the need for user interaction for authentication

(which may be required by some authentication mechanisms). The extension
shall not have negative impact on IKEv2 security features.

Failover from one gateway to another, mechanisms for detecting when a
session should be resumed, and specifying communication mechanisms

between gateways are beyond the scope of this work item. Specifying the
detailed contents of the "session ticket" is also beyond the scope of
this document; if there is sufficient interest, this could be specified

later in a separate document.

To the degree its content falls within the scope of this work item, text
and ideas from draft-sheffer-ipsec-failover will be used as a starting
point.

- A standards-track extension to IPsec that allows an IPsec remote

access gateway to redirect VPN clients to another gateway. This
extension should be aligned with the session resumption extension,
(the previous work item), and if so decided by the WG, could be
specified in the same document. The starting point will be

draft-devarapalli-ipsec-ikev2-redirect.

- A standards-track mechanism that allows an intermediary device, such
as a firewall or intrusion detection system, to easily and reliably
determine whether an ESP packet is encrypted with the NULL cipher; and

if it is, determine the location of the actual payload data inside the
packet. The starting points for this work item are
draft-grewal-ipsec-traffic-visibility and draft-hoffman-
esp-null-protocol.

The initial scope of the WG is restricted to the work items listed

above. The WG shall not consider adding new work items until one or more
of its documents progress to IESG evaluation. At that time, the WG can
propose rechartering.

Chartering this WG is not intended to have effect on documents that

beyond the initial scope. In particular, work on IPsec extensions that
are not included in this charter can happen as usual in other WGs (and
there are currently several other WGs working on IPsec extensions; for

example, BTNS and ROHC), or as individual submissions.

This charter will expire in July 2010 (24 months from approval). If
the charter is not updated before that time, the WG will be closed and
any remaining documents revert back to individual Internet-Drafts.


Milestones:

Dec 2008 WG last call on IPv6 configuration payloads
Dec 2008 WG last call on IPsec roadmap
Jan 2009 WG last call on session resumption
Feb 2009 WG last call on redirect
Mar 2009 WG last call on IKEv2bis

Apr 2009 WG last call on ESP NULL traffic visibility
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec





------=_Part_13621_29868835.1214473288989--

--===============1702505991==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============1702505991==--


From ipsec-bounces@ietf.org  Thu Jun 26 07:03:34 2008
Return-Path: 
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 163CD3A6ABB;
	Thu, 26 Jun 2008 07:03:34 -0700 (PDT)
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 F36573A6ABB
	for ; Thu, 26 Jun 2008 07:03:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.617
X-Spam-Level: 
X-Spam-Status: No, score=-5.617 tagged_above=-999 required=5
	tests=[AWL=-0.982, 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 TSBeMaYmY9Ah for ;
	Thu, 26 Jun 2008 07:03:28 -0700 (PDT)
Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.144])
	by core3.amsl.com (Postfix) with ESMTP id 5EA603A69C6
	for ; Thu, 26 Jun 2008 07:03:28 -0700 (PDT)
Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234])
	by e4.ny.us.ibm.com (8.13.8/8.13.8) with ESMTP id m5QE3UMd010160
	for ; Thu, 26 Jun 2008 10:03:30 -0400
Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216])
	by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v9.0) with ESMTP id
	m5QE3Uq2169484 for ; Thu, 26 Jun 2008 10:03:30 -0400
Received: from d01av02.pok.ibm.com (loopback [127.0.0.1])
	by d01av02.pok.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id
	m5QE3T5e026556 for ; Thu, 26 Jun 2008 10:03:29 -0400
Received: from d01mll83.pok.ibm.com (d01mll83.pok.ibm.com [9.57.160.143])
	by d01av02.pok.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id
	m5QE3TkY026553; Thu, 26 Jun 2008 10:03:29 -0400
In-Reply-To: <0632EFA9-177D-4A52-92B2-80CCA3A52D2F@checkpoint.com>
To: Yoav Nir 
X-Mailer: Lotus Notes Release 7.0 HF277 June 21, 2006
Message-ID: 
From: David Wierbowski 
Date: Thu, 26 Jun 2008 10:03:28 -0400
X-MIMETrack: Serialize by Router on D01MLL83/01/M/IBM(Release 7.0.2FP2|April
	16, 2007) at 06/26/2008 10:03:28
MIME-Version: 1.0
Cc: ipsec@ietf.org
Subject: Re: [IPsec] Simultaneous re-authentication of an IKE_SA
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: ,
	
Content-Type: multipart/mixed; boundary="===============0425218165=="
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

--===============0425218165==
Content-type: multipart/related; 
	Boundary="0__=0ABBFEE7DFD5CC9C8f9e8a93df938690918c0ABBFEE7DFD5CC9C"

--0__=0ABBFEE7DFD5CC9C8f9e8a93df938690918c0ABBFEE7DFD5CC9C
Content-type: multipart/alternative; 
	Boundary="1__=0ABBFEE7DFD5CC9C8f9e8a93df938690918c0ABBFEE7DFD5CC9C"

--1__=0ABBFEE7DFD5CC9C8f9e8a93df938690918c0ABBFEE7DFD5CC9C
Content-type: text/plain; charset=US-ASCII
Content-transfer-encoding: quoted-printable


Yoav,

RFC 4306 and draft-hoffman-ikev2bis-03.txt indicate that a minimal
implementation may accept only one CHILD_SA per IKE_SA; however, it doe=
s
not restrict such implementations to creating only one IKE_SA/CHILD_SA =
pair
with the same peer.  They also state that the ability to rekey SAs with=
out
restarting the entire IKE_SA is optional (i.e. an implementation can ch=
ose
to only re-authenticate).  Given that I don't think we can restrict tha=
t an
IKE peer MUST NOT re-authenticate multiple IKE SAs with the same peer.

Detecting simultaneous attempts to re-authenticate an IKE_SA  would hav=
e
been simplified if IKEv2 contained a REAUTH_SA notify similar to the
REKEY_SA notify.  Such a notify could have been included in the IKE_AUT=
H
exchange to clearly identify that an IKE_SA was being created for the
purpose of re-authenticating an existing IKE_SA.

Since the decision of when to rekey or re-authenticate an IKE_SA is not=

negotiated the likelihood of simultaneous re-authentications should be
small to begin with.  Jittering the time would reduce it even further.
Still the possibility of a simultaneous re-authentication does exist.  =
It
would be nice if this issue could be addressed by the IP Security
Maintenance and Extensions working group as part of it's work item to
produce a revision to IKEv2 (assuming the working group's charter is
actually approved).



                                                                       =
    
             Yoav Nir                                                  =
    
                                                                   =
 To 
                                       David Wierbowski/Endicott/IBM@IB=
MUS 
             06/25/2008 06:17                                          =
 cc 
             AM                        ipsec@ietf.org                  =
    
                                                                   Subj=
ect 
                                       Re: [IPsec] Simultaneous        =
    
                                       re-authentication of an IKE_SA  =
    
                                                                       =
    
                                                                       =
    
                                                                       =
    
                                                                       =
    
                                                                       =
    
                                                                       =
    




>Hi David.

>I agree that RFC 4718 is silent about simultaneous re-authentication.
>I guess the jitter recommendation should extend to re-authentication
>as well.

>I guess we can recommend some text in the revision document saying
>that an IKE peer MUST NOT re-authenticate multiple IKE SAs with the
>same peer.  This should limit the amount of IKE SAs to (at most) two
>at a time.

>If you're following the list, you will have noticed that a revision
>document for IKEv2 is planned for the hopefully-soon-to-be-formed
>IPsec extensions and maintenance working groups, so we can hope to fix=

>this.

>Yoav

>On Jun 24, 2008, at 7:15 PM, David Wierbowski wrote:

>> RFC 4718 highlights the difference between re-keying an IKE_SA and
>> re-authenticating an IKE_SA; however, it does not address the issue
>> of both peers simultaneously re-authenticating an IKE_SA.
>>
>> Re-authentication of an IKE_SA involves creating a new IKE_SA from
>> scratch (using the initial exchanges), creating new CHILD_SAs within=

>> the new IKE_SA, and finally deleting the old IKE_SA. The window
>> between sending the SA_INIT request and deleting the IKE_SA is
>> relatively significant in size.
>>
>> Unlike the re-keying, there is nothing that ties the IKE_SA being re=
-
>> authenticated to the new IKE_SA. How can one even detect that a
>> simultaneous re-authentication has even occurred?
>>
>> Much of the previous discussion on the mailing list about re-
>> authentication of the IKE_SA was in an EAP context. I am asking this=

>> question is in a non-EAP context.
>>
>> The concern is that if a simultaneous re-authentication goes
>> undetected that both peers will end up with 2 identical IKE_SAs. In
>> a worst case scenario the peers will simultaneously re-authenticate
>> both the new IKE_SAs and then end up with 4 identical IKE_SAs, and
>> so on.
>>
>>
>> Dave Wierbowski
>>
>> z/OS Comm Server Developer
>>
>> Scanned by Check Point Total Security Gateway.
>>
>>
>> _______________________________________________
>> IPsec mailing list
>> IPsec@ietf.org
>> https://www.ietf.org/mailman/listinfo/ipsec

=

--1__=0ABBFEE7DFD5CC9C8f9e8a93df938690918c0ABBFEE7DFD5CC9C
Content-type: text/html; charset=US-ASCII
Content-Disposition: inline
Content-transfer-encoding: quoted-printable



Yoav,



RFC 4306 and draft-hoffman-ikev2bis-03.txt indicate that a minimal impl=
ementation may accept only one CHILD_SA per IKE_SA; however, it does no=
t restrict such implementations to creating only one IKE_SA/CHILD_SA pa=
ir with the same peer.  They also state that the ability to rekey SAs w=
ithout restarting the entire IKE_SA is optional (i.e. an implementation=
 can chose to only re-authenticate).  Given that I don't think we can r=
estrict that an IKE peer MUST NOT re-authenticate multiple IKE SAs with=
 the same peer.



Detecting simultaneous attempts to re-authenticate an IKE_SA  would hav=
e been simplified if IKEv2 contained a REAUTH_SA notify similar to the =
REKEY_SA notify.  Such a notify could have been included in the IKE_AUT=
H exchange to clearly identify that an IKE_SA was being created for the=
 purpose of re-authenticating an existing IKE_SA.



Since the decision of when to rekey or re-authenticate an IKE_SA is not=
 negotiated the likelihood of simultaneous re-authentications should be=
 small to begin with.  Jittering the time would reduce it even further.=
  Still the possibility of a simultaneous re-authentication does exist.=
  It would be nice if this issue could be addressed by the IP Security =
Maintenance and Extensions working group as part of it's work item to p=
roduce a revision to IKEv2 (assuming the working group's charter is act=
ually approved).  



3D"InactiveYoav Nir <ynir@checkpoint.com>





=




    

      

        

          Yoav Nir <ynir@checkpoint.com>=
 

          06/25/2008 06:17 AM
        

      

    



=


3D=


To
3D""

David Wierbowski/Endicott/IBM@IBMUS



3D=


cc
3D""

ipsec@ietf.org



3D=


Subject
3D""

Re: [IPsec] Simultaneous re-authentication of an IKE_S=
A







3D=3D""








>Hi David.



>I agree that RFC 4718 is silent about simultaneous re-authenticatio=
n.   

>I guess the jitter recommendation should extend to re-authenticatio=
n  

>as well.



>I guess we can recommend some text in the revision document saying =
 

>that an IKE peer MUST NOT re-authenticate multiple IKE SAs with the=
  

>same peer.  This should limit the amount of IKE SAs to (at mos=
t) two  

>at a time.



>If you're following the list, you will have noticed that a revision=
  

>document for IKEv2 is planned for the hopefully-soon-to-be-formed &=
nbsp;

>IPsec extensions and maintenance working groups, so we can hope to =
fix  

>this.



>Yoav



>On Jun 24, 2008, at 7:15 PM, David Wierbowski wrote:



>> RFC 4718 highlights the difference between re-keying an IKE_SA=
 and  

>> re-authenticating an IKE_SA; however, it does not address the =
issue  

>> of both peers simultaneously re-authenticating an IKE_SA.

>>

>> Re-authentication of an IKE_SA involves creating a new IKE_SA =
from  

>> scratch (using the initial exchanges), creating new CHILD_SAs =
within  

>> the new IKE_SA, and finally deleting the old IKE_SA. The windo=
w  

>> between sending the SA_INIT request and deleting the IKE_SA is=
  

>> relatively significant in size.

>>

>> Unlike the re-keying, there is nothing that ties the IKE_SA be=
ing re- 

>> authenticated to the new IKE_SA. How can one even detect that =
a  

>> simultaneous re-authentication has even occurred?

>>

>> Much of the previous discussion on the mailing list about re- =


>> authentication of the IKE_SA was in an EAP context. I am askin=
g this  

>> question is in a non-EAP context.

>>

>> The concern is that if a simultaneous re-authentication goes &=
nbsp;

>> undetected that both peers will end up with 2 identical IKE_SA=
s. In  

>> a worst case scenario the peers will simultaneously re-authent=
icate  

>> both the new IKE_SAs and then end up with 4 identical IKE_SAs,=
 and  

>> so on.

>>

>>

>> Dave Wierbowski

>>

>> z/OS Comm Server Developer

>>

>> Scanned by Check Point Total Security Gateway.

>>

>>

>> _______________________________________________

>> IPsec mailing list

>> IPsec@ietf.org

>> https://www.ietf.org/mailman/listinfo/ipsec





=


--1__=0ABBFEE7DFD5CC9C8f9e8a93df938690918c0ABBFEE7DFD5CC9C--


--0__=0ABBFEE7DFD5CC9C8f9e8a93df938690918c0ABBFEE7DFD5CC9C
Content-type: image/gif; 
	name="graycol.gif"
Content-Disposition: inline; filename="graycol.gif"
Content-ID: <1__=0ABBFEE7DFD5CC9C8f9e8a93df938@us.ibm.com>
Content-transfer-encoding: base64

R0lGODlhEAAQAKECAMzMzAAAAP///wAAACH5BAEAAAIALAAAAAAQABAAAAIXlI+py+0PopwxUbpu
ZRfKZ2zgSJbmSRYAIf4fT3B0aW1pemVkIGJ5IFVsZWFkIFNtYXJ0U2F2ZXIhAAA7

--0__=0ABBFEE7DFD5CC9C8f9e8a93df938690918c0ABBFEE7DFD5CC9C
Content-type: image/gif; 
	name="pic62049.gif"
Content-Disposition: inline; filename="pic62049.gif"
Content-ID: <2__=0ABBFEE7DFD5CC9C8f9e8a93df938@us.ibm.com>
Content-transfer-encoding: base64

R0lGODlhWABDALP/AAAAAK04Qf79/o+Gm7WuwlNObwoJFCsoSMDAwGFsmIuezf///wAAAAAAAAAA
AAAAACH5BAEAAAgALAAAAABYAEMAQAT/EMlJq704682770RiFMRinqggEUNSHIchG0BCfHhOjAuh
EDeUqTASLCbBhQrhG7xis2j0lssNDopE4jfIJhDaggI8YB1sZeZgLVA9YVCpnGagVjV171aRVrYR
RghXcAGFhoUETwYxcXNyADJ3GlcSKGAwLwllVC1vjIUHBWsFilKQdI8GA5IcpApeJQt8L09lmgkH
LZikoU5wjqcyAMMFrJIDPAKvCFletKSev1HBw8KrxtjZ2tvc3d5VyKtCKW3jfz4uMKmq3xu4N0nK
BVoJQmx2LGVOmrqNjjJf2hHAQo/eDwJGTKhQMcgQEEAnEjFS98+RnW3smGkZU6ncCWav/4wYOnAI
TihRL/4FEwbp28BXMMcoscQCVxlepL4IGDSCyJyVQOu0o7CjmLN50OZlqWmyFy5/6yBBuji0AxFR
M00oQAqNIstqI6qKHUsWRAEAvagsmfUEAImyxgbmUpJk3IklNUtJOUAVLoUr1+wqDGTE4zk+T6FG
uQb3SizBCwatiiUgCBN8vrz+zFjVyQ8FWkOlg4NQiZMB5QS8QO3mpOaKnL0Z2EKvNMSILEThKhCg
zMKPVxYJh23qm9KNW7pArPynMqZDiErsTMqI+LRi3QAgkFUbXpuFKhSYZALd0O5RKa2z9EYKBbpb
qxIKsjUPRgD7I2XYV6wyrOw92ykExP8NW4URhknC5dKGE4v4NENQj2jXjmfNgOZDaXb5glRmXQ33
YEWQYNcZFnrYcIQLNzyTFDQNkXIff0ExVlY4srziQk43inZgL4rwxxINMvpFFAz1KOODHiu+4aEw
NEjFl5B3JIKWKF3k6I9bfUGp5ZZcdunll5IA4cuHvQQJ5gcsoCWOOUwgltIwAKRxJgbIkJAQZEq0
2YliZnpZZ4BH3CnYOXldOUOfQoYDqF1LFHbXCrO8xmRsfoXDXJ6ChjCAH3QlhJcT6VWE6FCkfCco
CgrMFsROrIEX3o2whVjWDjoJccN3LdggSGXLCdLEgHr1lyU3O3QxhgohNKXJCWv8JQr/PDdaqd6w
2rj1inLiGeiCJoDspAoQlYE6QWLSECehcWIYxIQES6zhbn1iImTHEQyqJ4eIxJJoUBc+3CbBuwZE
V5cJPPkIjFDdeEabQbd6WgICTxiiz0f5dBKquXF6k4senwEhYGnKEFJeGrxUZy8dB8gmAXI/sPvH
ESfCwVt5hTgYiqQqtdRNHQIU1PJ33ZqmzgE90OwLaoJcnMop1WiMmgkPHQRIrwgFuNV90A3doNKT
mrKIN07AnGcI9BQjhCBN4RfA1qIZnMqorJCogKfGQnxSCDilTVIA0yl5ciTovgLuBDKFUDE9aQcw
9SA+rjSNf9/M1gxrj6VwDTS0IUSElMzBfsj0NFXR2kwsV1A5IF1grLgLL/r1R40BZEnuBWgmQEyb
jqRwSAt6bqMCOFkvKFN2GPPkUzIm/SCF8z8pVzpbjVnMsy0vOr1hw3SaSRUhpY09v0z0J1FnwzPl
fmh+xl4WtR0zGu24I4KbMQm3lnVu2oNWxI9W/lcyzA+mCKF4DBikxb/+UWtOGRiFP8qEwAayIgIA
Ow==

--0__=0ABBFEE7DFD5CC9C8f9e8a93df938690918c0ABBFEE7DFD5CC9C
Content-type: image/gif; 
	name="ecblank.gif"
Content-Disposition: inline; filename="ecblank.gif"
Content-ID: <3__=0ABBFEE7DFD5CC9C8f9e8a93df938@us.ibm.com>
Content-transfer-encoding: base64

R0lGODlhEAABAIAAAAAAAP///yH5BAEAAAEALAAAAAAQAAEAAAIEjI8ZBQA7

--0__=0ABBFEE7DFD5CC9C8f9e8a93df938690918c0ABBFEE7DFD5CC9C--


--===============0425218165==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0425218165==--



From ipsec-bounces@ietf.org  Fri Jun 27 04:51:56 2008
Return-Path: 
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 6841A3A6B4E;
	Fri, 27 Jun 2008 04:51:56 -0700 (PDT)
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 CBCBC3A6B4E
	for ; Fri, 27 Jun 2008 04:51:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.11
X-Spam-Level: 
X-Spam-Status: No, score=-1.11 tagged_above=-999 required=5
	tests=[BAYES_05=-1.11]
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 9hYorOjQXb8n for ;
	Fri, 27 Jun 2008 04:51:54 -0700 (PDT)
Received: from iluvatar.zemris.fer.hr (iluvatar.zemris.fer.hr [161.53.65.13])
	by core3.amsl.com (Postfix) with ESMTP id F20E43A6ABB
	for ; Fri, 27 Jun 2008 04:51:53 -0700 (PDT)
Received: from localhost (unknown [127.0.0.1])
	by iluvatar.zemris.fer.hr (Postfix) with ESMTP id 35C7A13C2BB
	for ; Fri, 27 Jun 2008 11:51:28 +0000 (UTC)
X-Virus-Scanned: by amavisd-new at zemris.fer.hr
Received: from iluvatar.zemris.fer.hr ([127.0.0.1])
	by localhost (iluvatar.zemris.fer.hr [127.0.0.1]) (amavisd-new,
	port 10024) with ESMTP id r3zfiLHubkJq for ;
	Fri, 27 Jun 2008 13:51:26 +0200 (CEST)
Received: from [161.53.65.45] (Isumbras.zemris.fer.hr [161.53.65.45])
	(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(No client certificate requested)
	by iluvatar.zemris.fer.hr (Postfix) with ESMTP id 8BA6513C2B6
	for ; Fri, 27 Jun 2008 13:51:26 +0200 (CEST)
From: Stjepan Gros 
To: ipsec@ietf.org
Organization: FER - ZEMRIS
Date: Fri, 27 Jun 2008 13:51:54 +0200
Message-Id: <1214567514.3620.7.camel@isumbras.zemris.fer.hr>
Mime-Version: 1.0
X-Mailer: Evolution 2.22.2 (2.22.2-2.fc9) 
Subject: [IPsec] IKEv2 & MIBs
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: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

Hi!

I just wonder if anyone worked on defining MIBs for IKEv2 or are there
any plans of defining them?

Stjepan

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


From ipsec-bounces@ietf.org  Sat Jun 28 02:54:24 2008
Return-Path: 
X-Original-To: ipsec-archive@megatron.ietf.org
Delivered-To: ietfarch-ipsec-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1])
	by core3.amsl.com (Postfix) with ESMTP id 076F43A6B93;
	Sat, 28 Jun 2008 02:54:24 -0700 (PDT)
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 C00A33A6B93
	for ; Sat, 28 Jun 2008 02:54:22 -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 NuEpOE567ugM for ;
	Sat, 28 Jun 2008 02:54:21 -0700 (PDT)
Received: from mail.kivinen.iki.fi (fireball.kivinen.iki.fi
	[IPv6:2001:1bc8:100d::2])
	by core3.amsl.com (Postfix) with ESMTP id 791913A6B58
	for ; Sat, 28 Jun 2008 02:54:21 -0700 (PDT)
Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1])
	by mail.kivinen.iki.fi (8.13.8/8.13.8) with ESMTP id m5S9rqU8028289
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
	Sat, 28 Jun 2008 12:53:52 +0300 (EEST)
Received: (from kivinen@localhost)
	by fireball.kivinen.iki.fi (8.13.8/8.12.11) id m5S9rpj8020130;
	Sat, 28 Jun 2008 12:53:51 +0300 (EEST)
X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to
	kivinen@iki.fi using -f
MIME-Version: 1.0
Message-ID: <18534.2607.349604.149248@fireball.kivinen.iki.fi>
Date: Sat, 28 Jun 2008 12:53:51 +0300
From: Tero Kivinen 
To: fd@cisco.com
In-Reply-To: <1214317086.6654.139.camel@fdetienn-laptop>
References: <485F394A.1090804@cisco.com>
	<5326E5DF-0D3E-4ADD-9647-785274E8A2A2@checkpoint.com>
	<1214222942.6828.205.camel@fdetienn-laptop>
	
	<1214294503.6654.23.camel@fdetienn-laptop>
	<9ED51A04-61B5-43D2-B93C-D356C0365E16@checkpoint.com>
	<1214317086.6654.139.camel@fdetienn-laptop>
X-Mailer: VM 7.19 under Emacs 21.4.1
X-Edit-Time: 7 min
X-Total-Time: 6 min
Cc: ipsec@ietf.org, Yoav Nir ,
	Pratima Sethi 
Subject: Re: [IPsec] [Fwd: New Version
	Notification	for	draft-detienne-ikev2-recovery-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: ,
	
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: ipsec-bounces@ietf.org
Errors-To: ipsec-bounces@ietf.org

Frederic Detienne writes:
> Reading through, I think we need to expose a little more of our
> rationale.

I have not read the draft (yet), but from your discussion it seems
that the real solution to the problem is to use birth certificates,
not adding more round trips to get more protection (from
http://tools.ietf.org/html/draft-ietf-ipsec-ikev2-rationale-00 section
3.1 changes we considered and rejected):

----------------------------------------------------------------------
   - adding in Bill Sommerfeld's "birth certificate" idea. In this idea
   Bob keeps a number in nonvolatile memory that increments each time
   the node restarts. When Bob restarts, he signs a "birth certificate"
   stating what the value of that counter is. This birth certificate is
   transmitted as a payload in message 4. Alice keeps this value. If Bob
   ever receives an ESP packet that doesn't decrypt properly or with an
   unknown SPI, he responds to that packet with his birth certificate.
   If the recipient has an SA for Bob with an older birth certificate,
   this lets them know Bob has restarted and forgotten state for that
   SA. We decided not to add that to this version of the draft, although
   we think it is a good idea, until it's been written up in a separate
   draft and there has been an opportunity for people to understand it
   and give feedback.
----------------------------------------------------------------------

The counter could of course be also the timestamp, as that is already
available for systems which are using certificates. I.e. instead of
sending non-authenticated invalid IKE SA notify, Bob would send his
birth certificate, so Alice can see whether Bob has rebooted or not,
and as the certificate is signed with Bobs key it means Alice can
trust that information. 
-- 
kivinen@safenet-inc.com
_______________________________________________
IPsec mailing list
IPsec@ietf.org
https://www.ietf.org/mailman/listinfo/ipsec