From root@core3.amsl.com Mon Jun 1 11:30:01 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6B48E3A71B2; Mon, 1 Jun 2009 11:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090601183001.6B48E3A71B2@core3.amsl.com> Date: Mon, 1 Jun 2009 11:30:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic-visibility-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 18:30:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Wrapped ESP for Traffic Visibility Author(s) : M. Bhatia, K. Grewal, G. Montenegro Filename : draft-ietf-ipsecme-traffic-visibility-03.txt Pages : 14 Date : 2009-6-1 This document describes the Wrapped Encapsulating Security Payload (WESP) protocol, which builds on top of Encapsulating Security Payload (ESP) [RFC4303] and is designed to allow intermediate devices to ascertain if ESP-NULL [RFC2410] is being employed and hence inspect the IPsec packets for network monitoring and access control functions. Currently in the IPsec standard, there is no way to differentiate between ESP encryption and ESP NULL encryption by simply examining a packet. This poses certain challenges to the intermediate devices that need to deep inspect the packet before making a decision on what should be done with that packet (Inspect and/or Allow/Drop). The mechanism described in this document can be used to easily disambiguate ESP-NULL from ESP encrypted packets, without compromising on the security provided by ESP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-traffic-visibility-03.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-traffic-visibility-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-6-1111533.I-D@ietf.org> --NextPart-- From ynir@checkpoint.com Mon Jun 1 15:31:52 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 879DD3A6BCE for ; Mon, 1 Jun 2009 15:31: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=[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 0H-CUSVaoixS for ; Mon, 1 Jun 2009 15:31:51 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 853863A6E34 for ; Mon, 1 Jun 2009 15:31:51 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id E49CF200E3F; Tue, 2 Jun 2009 01:31:53 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 8FF8D200437; Tue, 2 Jun 2009 01:31:53 +0300 (IDT) X-CheckPoint: {4A245569-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n51MVo3d016700; Tue, 2 Jun 2009 01:31:50 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Tue, 2 Jun 2009 01:31:50 +0300 From: Yoav Nir To: "Pasi.Eronen@nokia.com" , "ipsec@ietf.org" Date: Tue, 2 Jun 2009 01:27:42 +0300 Thread-Topic: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-resumption-04.txt Thread-Index: AcnVmMEj2J2LXoVkQamMww7oVGxsbAK9MhFwAJ6pIvc= Message-ID: <006FEB08D9C6444AB014105C9AEB133F0522CDF73F@il-ex01.ad.checkpoint.com> References: <20090515163001.6D4AB28C106@core3.amsl.com> , <808FD6E27AD4884E94820BC333B2DB773A6AEBC734@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773A6AEBC734@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-resumption-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2009 22:31:52 -0000 I'm not so sure about that. The authentication in the IKE_AUTH exchange tha= t follows the resumption only proves that the (new) responder can decipher = the ticket (or has access to the ticket database). Presumably a "cluster" of gateways backing each other up would have the sam= e IDr, but if they're using (for example) IPv4 or IPv6 addresses as IDr, th= ese IDrs could be different. IOW I don't see much security value in mandating that the responder show th= e same IDr, although I can't think of a really good reason why they would n= ot. ________________________________________ From: ipsec-bounces@ietf.org [ipsec-bounces@ietf.org] On Behalf Of Pasi.Ero= nen@nokia.com [Pasi.Eronen@nokia.com] Sent: Friday, May 29, 2009 21:46 8) The text about handling IDr is very unclear -- certainly the gateway can't start to use some other IDr in the new IKE_SA, without authenticating it? Email secured by Check Point From kivinen@iki.fi Tue Jun 2 04:09:30 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 999943A68F1 for ; Tue, 2 Jun 2009 04:09:30 -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 V9QPr6bPxOSH for ; Tue, 2 Jun 2009 04:09:30 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 9E58E3A6F19 for ; Tue, 2 Jun 2009 04:09:29 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n52B4O9i017162 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 2 Jun 2009 14:04:24 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n52B4N53017198; Tue, 2 Jun 2009 14:04:23 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18981.1847.250146.113010@fireball.kivinen.iki.fi> Date: Tue, 2 Jun 2009 14:04:23 +0300 From: Tero Kivinen To: Vijay Devarapalli In-Reply-To: References: <006FEB08D9C6444AB014105C9AEB133F0522CDF72D@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 0 min Cc: "ipsec@ietf.org" , Yoav Nir Subject: Re: [IPsec] Some comments about redirect X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 11:09:30 -0000 Vijay Devarapalli writes: > Anyone else have any comments on including "4 - Locally Meaningful Name"? I can see use for that, so I would say it is good idea to add such. -- kivinen@iki.fi From ken.grewal@intel.com Tue Jun 2 13:58:26 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E35383A67AF for ; Tue, 2 Jun 2009 13:58:26 -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 NNsiWNvYcV62 for ; Tue, 2 Jun 2009 13:58:26 -0700 (PDT) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by core3.amsl.com (Postfix) with ESMTP id 27EB53A676A for ; Tue, 2 Jun 2009 13:58:26 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 02 Jun 2009 13:45:53 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.41,293,1241420400"; d="scan'208";a="695866499" Received: from rrsmsx602.amr.corp.intel.com ([10.31.0.33]) by fmsmga001.fm.intel.com with ESMTP; 02 Jun 2009 14:01:51 -0700 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx602.amr.corp.intel.com ([10.31.0.33]) with mapi; Tue, 2 Jun 2009 14:58:23 -0600 From: "Grewal, Ken" To: "ipsec@ietf.org" Date: Tue, 2 Jun 2009 14:58:00 -0600 Thread-Topic: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic-visibility-03.txt Thread-Index: Acni5yzZJU/Jbsi6QBWjBvM/fjNaQgA3V1fg Message-ID: References: <20090601183001.6B48E3A71B2@core3.amsl.com> In-Reply-To: <20090601183001.6B48E3A71B2@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic-visibility-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Jun 2009 20:58:27 -0000 All,=20 The updated draft for traffic visibility is now available, incorporating va= rious suggested changes.=20 All previously open tickets for this work item have now been closed, indica= ting the resolution and changes made. =20 Please review and provide any additional feedback. Thanks,=20 - Ken =20 >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of >Internet-Drafts@ietf.org >Sent: Monday, June 01, 2009 11:30 AM >To: i-d-announce@ietf.org >Cc: ipsec@ietf.org >Subject: [IPsec] I-D ACTION:draft-ietf-ipsecme-traffic-visibility-03.txt > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the IP Security Maintenance and Extensions >Working Group of the IETF. > > Title : Wrapped ESP for Traffic Visibility > Author(s) : M. Bhatia, K. Grewal, G. Montenegro > Filename : draft-ietf-ipsecme-traffic-visibility-03.txt > Pages : 14 > Date : 2009-6-1 > >This document describes the Wrapped Encapsulating Security > Payload (WESP) protocol, which builds on top of Encapsulating > Security Payload (ESP) [RFC4303] and is designed to allow > intermediate devices to ascertain if ESP-NULL [RFC2410] is being > employed and hence inspect the IPsec packets for network > monitoring and access control functions. Currently in the IPsec > standard, there is no way to differentiate between ESP > encryption and ESP NULL encryption by simply examining a packet. > This poses certain challenges to the intermediate devices that > need to deep inspect the packet before making a decision on what > should be done with that packet (Inspect and/or Allow/Drop). The > mechanism described in this document can be used to easily > disambiguate ESP-NULL from ESP encrypted packets, without > compromising on the security provided by ESP. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-traffic-visibility- >03.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. From Pasi.Eronen@nokia.com Fri Jun 5 04:43:57 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B104A3A6AD9 for ; Fri, 5 Jun 2009 04:43: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=[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 QlXNd8jRIo5m for ; Fri, 5 Jun 2009 04:43:57 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 974913A6ABD for ; Fri, 5 Jun 2009 04:43:56 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n55BhkZZ009586; Fri, 5 Jun 2009 14:43:50 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Jun 2009 14:42:49 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Jun 2009 14:42:48 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Fri, 5 Jun 2009 13:42:48 +0200 From: To: , Date: Fri, 5 Jun 2009 13:42:47 +0200 Thread-Topic: [IPsec] Final comments for ikev2-redirect-10 Thread-Index: Acnd2l1IeD7eu8inRHSVz2Vyii7gVQBOvEnrAClbFHAAOwvwhAFK0rBg Message-ID: <808FD6E27AD4884E94820BC333B2DB773A6AFA5CA0@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB773A6AE79A63@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 05 Jun 2009 11:42:48.0919 (UTC) FILETIME=[C050E670:01C9E5D2] X-Nokia-AV: Clean Subject: Re: [IPsec] Final comments for ikev2-redirect-10 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 11:43:57 -0000 Vijay Devarapalli wrote: > > And having these two cases is more complex than having just one > > (IKE_SA is not used for any more exchanges). What benefits does > > this additional complexity (both in spec and in implementation) > > get us? > > > > If nothing, let's just remove it.... >=20 > When the AUTH payloads are exchanged and verified, the IKEv2 SA is > valid. This seems straightforward. We are not doing anything out of > the ordinary here by not invalidating the IKEv2 SA just because the > gateway sent the REDIRECT payload to the client. > > I can imagine extensions tomorrow that would let the client convey > additional information using the IKEv2 SA to the gateway, after the > gateway had sent a REDIRECT payload to the client. What do you mean by "valid"? So the client could potentially ignore the redirect (in the last IKE_AUTH response), and continue using the IKE_SA (at least for some time) for other exhanges? AFAIK, the current text is *not* supposed to allow that -- but it seems it is indeed quite unclear. Best regards, Pasi From Pasi.Eronen@nokia.com Fri Jun 5 05:23:24 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 020453A6C10 for ; Fri, 5 Jun 2009 05:23:24 -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 CLU1v3GCzfaB for ; Fri, 5 Jun 2009 05:23:23 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 8BCCD3A6AD9 for ; Fri, 5 Jun 2009 05:23:22 -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 n55CMpmZ024463; Fri, 5 Jun 2009 15:23:17 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Jun 2009 15:23:14 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Fri, 5 Jun 2009 15:23:09 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Fri, 5 Jun 2009 14:23:07 +0200 From: To: , Date: Fri, 5 Jun 2009 14:23:06 +0200 Thread-Topic: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-resumption-04.txt Thread-Index: AcnVmMEj2J2LXoVkQamMww7oVGxsbAK9MhFwAF31gbAA9Bv/IA== Message-ID: <808FD6E27AD4884E94820BC333B2DB773A6AFA5D01@NOK-EUMSG-01.mgdnok.nokia.com> References: <20090515163001.6D4AB28C106@core3.amsl.com> <808FD6E27AD4884E94820BC333B2DB773A6AEBC734@NOK-EUMSG-01.mgdnok.nokia.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8DED898E4C7@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8DED898E4C7@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 05 Jun 2009 12:23:09.0306 (UTC) FILETIME=[62FAA5A0:01C9E5D8] X-Nokia-AV: Clean Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-resumption-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 12:23:24 -0000 Yaron Sheffer wrote: > > The current ikev2-resumption draft, on the other hand, seems to > > assume a quite different model, where resumption replaces the old > > connection, and can be done only if the old connection was > > interrupted. > > > > This would seem to preclude one case discussed earlier: I close my > > laptop (cleanly) at work, commute, and reconnect at home (without > > having to do EAP again; e.g. type in one-time password). Or "switch > > off my phone (cleanly), fly to IETF meeting, and switch it back on". > > > > In case of IKEv2, having multiple parallel IKE connections is > > probably less common than with TLS (where it's very common), but > > to me it seems using the IKE_SESSION_RESUME handshake when the old > > IKE_SA was cleanly closed would be quite useful, and should be > > supported. (And making the "new connection" completely independent > > of the old one might simplify the protocol anyway.) > > > > (Or in other words: I'd propose changing Section 7.2, 1st paragraph, > > and making these MUSTs MAYs.) >=20 > [YS] Let me answer at two levels, the principle of session > resumption and the particular use case you present. >=20 > At the principle level, I think SSL/TLS history, going back to HTTP > 1.0, required support of many concurrent "cloned" sessions. Typical > use of IKE, at least for RA VPN, is different, preferring a single > instance per client. So much so that even the concept of > reauthentication was only recognized post 4306 (RFC 4478). >=20 > Regarding the use case, most security policies will require you to > reauthenticate after a logout/suspend. But even if your scenario is > legit, I don't see why the current draft precludes the client from > implementing this behavior. >=20 > One interesting use case that would support your view is setting up > simultaneous IKE SAs to multiple gateways, with no need to > authenticate to each one separately. But that's of course WAY out of > scope. >=20 > Also, I believe your issue is NOT with the MUSTs in Sec. 7.2, it is > rather with the last paragraph of 4.3, quoted here: >=20 > When the responder receives a ticket for an IKE SA that is still > active and if the responder accepts it, then the old SA SHOULD be > silently deleted without sending a DELETE informational > exchange. Consequently, all the dependent IPsec child SAs are also > deleted. This happens after both peers have been authenticated. Note that my comment had two somewhat separate concerns: prohibiting parallel IKE SAs, and prohibiting using this mechanism when the IKE_SA was cleanly closed. I think you're right that parallel IKE SAs aren't really needed. But why the resumption mechanism can't be used if the session was termined cleanly instead of dead-peer-detection timeout? I think this restriction doesn't give us any benefits, and loses some flexibility.. > > 6) Section 6: The word "Unspecified" is probably wrong here -- > > this document has to specify these (but clearly an implementation > > doesn't have to include in the ticket any data it never uses). >=20 > [YS] I have used "unspecified" as synonymous with "implementation > specific". Or do you want to propose alternative text? I don't think "implementation speific" is the right term either, If the implementation needs e.g. the certificates after resumption, it is *not* implementation specific whether they come from the ticket (or local store) or the new exchange. I think the text should say "From the ticket", with a note explaining that some implementations may not need this information during/after resumption, and in this case, it doesn't have to be stored anywhere. > > 8) The text about handling IDr is very unclear -- certainly the > > gateway can't start to use some other IDr in the new IKE_SA, > > without authenticating it? >=20 > [YS] Unfortunately you are right, but this eliminates important > flexibility in naming the gateways. We *could* say that the client > trusts the gateway to identify itself, because the gateway is > clearly a member of the "trusted gateways" group (it is able to > decrypt the ticket). But that still sounds wrong. The gateway is part of the *same* group as the original gateway (who authenticated itself, probably with certificates) -- but that doesn't mean it's trusted to use someone else's SPD/PAD entries (for some other gateway/group of gateways than the original one). So on client, the IDr (used for SPD/PAD lookups) should come from the ticket/local storage, not from the new exchange... (unless the gateway actually authenticates it's really the new IDr) > > 9) Section 7.1: Why are storing SPIi/SPIr and the authentication > > method "MUST"s? (The gateway doesn't seem to really need those for > > anything) > > > [YS] SPIi/SPIr are used to identify the SA we are resuming (see > discussion above).=20 That seems like an internal implementation detail...=20 > The authentication method seems to be useful, e.g. to know that you > should expect a cert to be included. But yes, the auth method could > be left implementation-dependent. But the client does *not* include a certificate when doing resumption, so if the gateway expects to receive a cert, it will never get one? However, the draft should probably clarify that the ticket (or local storage) has to include the authenticated peer identity used for policy lookups -- which is not necessarily the same as IDi payload (see RFC 4718, Section 3.5). (And if the value from IDi isn't actually used for anything, it obviously doesn't have to be stored either.) Best regards, Pasi From root@core3.amsl.com Fri Jun 5 08:30:02 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id E4A653A6B72; Fri, 5 Jun 2009 08:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090605153001.E4A653A6B72@core3.amsl.com> Date: Fri, 5 Jun 2009 08:30:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-traffic-visibility-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 15:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Wrapped ESP for Traffic Visibility Author(s) : K. Grewal, et al. Filename : draft-ietf-ipsecme-traffic-visibility-04.txt Pages : 13 Date : 2009-06-05 This document describes the Wrapped Encapsulating Security Payload (WESP) protocol, which builds on top of Encapsulating Security Payload (ESP) [RFC4303] and is designed to allow intermediate devices to ascertain if ESP-NULL [RFC2410] is being employed and hence inspect the IPsec packets for network monitoring and access control functions. Currently in the IPsec standard, there is no way to differentiate between ESP encryption and ESP NULL encryption by simply examining a packet. This poses certain challenges to the intermediate devices that need to deep inspect the packet before making a decision on what should be done with that packet (Inspect and/or Allow/Drop). The mechanism described in this document can be used to easily disambiguate ESP-NULL from ESP encrypted packets, without compromising on the security provided by ESP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-traffic-visibility-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-traffic-visibility-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-06-05081724.I-D@ietf.org> --NextPart-- From ken.grewal@intel.com Fri Jun 5 14:01:28 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C04833A6C33 for ; Fri, 5 Jun 2009 14:01:28 -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 lzGjwSDUG5B1 for ; Fri, 5 Jun 2009 14:01:28 -0700 (PDT) Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by core3.amsl.com (Postfix) with ESMTP id 0071B3A6BC5 for ; Fri, 5 Jun 2009 14:01:27 -0700 (PDT) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga101.fm.intel.com with ESMTP; 05 Jun 2009 13:48:48 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.41,312,1241420400"; d="scan'208";a="696918484" Received: from rrsmsx603.amr.corp.intel.com ([10.31.0.57]) by fmsmga001.fm.intel.com with ESMTP; 05 Jun 2009 14:04:58 -0700 Received: from rrsmsx601.amr.corp.intel.com (10.31.0.151) by rrsmsx603.amr.corp.intel.com (10.31.0.57) with Microsoft SMTP Server (TLS) id 8.1.358.0; Fri, 5 Jun 2009 15:01:30 -0600 Received: from rrsmsx505.amr.corp.intel.com ([10.31.0.36]) by rrsmsx601.amr.corp.intel.com ([10.31.0.151]) with mapi; Fri, 5 Jun 2009 15:01:30 -0600 From: "Grewal, Ken" To: "ipsec@ietf.org" Date: Fri, 5 Jun 2009 15:01:10 -0600 Thread-Topic: [IPsec] I-D Action:draft-ietf-ipsecme-traffic-visibility-04.txt Thread-Index: Acnl8oNsTfaE8D3BQLOpWgr1zlDpvAALgHHQ Message-ID: References: <20090605153001.E4A653A6B72@core3.amsl.com> In-Reply-To: <20090605153001.E4A653A6B72@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-traffic-visibility-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2009 21:01:28 -0000 All,=20 Updated draft for traffic visibility has been posted. Only changes since re= v-03 is text related to the flags handling, as suggested by Yaron Sheffer. Look forward to your feedback. Thanks,=20 - Ken =20 >-----Original Message----- >From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of >Internet-Drafts@ietf.org >Sent: Friday, June 05, 2009 8:30 AM >To: i-d-announce@ietf.org >Cc: ipsec@ietf.org >Subject: [IPsec] I-D Action:draft-ietf-ipsecme-traffic-visibility-04.txt > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. >This draft is a work item of the IP Security Maintenance and Extensions >Working Group of the IETF. > > > Title : Wrapped ESP for Traffic Visibility > Author(s) : K. Grewal, et al. > Filename : draft-ietf-ipsecme-traffic-visibility-04.txt > Pages : 13 > Date : 2009-06-05 > >This document describes the Wrapped Encapsulating Security >Payload (WESP) protocol, which builds on top of Encapsulating >Security Payload (ESP) [RFC4303] and is designed to allow >intermediate devices to ascertain if ESP-NULL [RFC2410] is being >employed and hence inspect the IPsec packets for network >monitoring and access control functions. Currently in the IPsec >standard, there is no way to differentiate between ESP >encryption and ESP NULL encryption by simply examining a packet. >This poses certain challenges to the intermediate devices that >need to deep inspect the packet before making a decision on what >should be done with that packet (Inspect and/or Allow/Drop). The >mechanism described in this document can be used to easily >disambiguate ESP-NULL from ESP encrypted packets, without >compromising on the security provided by ESP. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-traffic-visibility- >04.txt > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >Below is the data which will enable a MIME compliant mail reader >implementation to automatically retrieve the ASCII version of the >Internet-Draft. From rsjenwar@gmail.com Sat Jun 6 03:46:31 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E26C23A6830 for ; Sat, 6 Jun 2009 03:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, 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 IM9xLUtAEbXf for ; Sat, 6 Jun 2009 03:46:31 -0700 (PDT) Received: from mail-pz0-f181.google.com (mail-pz0-f181.google.com [209.85.222.181]) by core3.amsl.com (Postfix) with ESMTP id 10D263A67F1 for ; Sat, 6 Jun 2009 03:46:31 -0700 (PDT) Received: by pzk11 with SMTP id 11so382173pzk.32 for ; Sat, 06 Jun 2009 03:46:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=+GUtSxjBazZdvBxLCUwNM4Qq0n6dlNYTc3dnseLI1bI=; b=AyoM1u4E5MOXhUA61/6EfJWAl0eLJ2Bh1pjkclp+q2We0ayua2YoeB+MSed/zFpyWo Q+inzdih9pillwTytF5TQIetg79dzGZm70jRs8w23NPJG9G1RV/8hq45j4HIFY7V7DSJ h49jH3fneznR7pf++W/hk7xLMZfBnGA78W7pY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=RCeijzzGXmB6vN+HRKHJqbsP9MPAcxTSF7pQNW553dQVXk59+BiRuKhBjjzPon4b6q tw676EMMaqmKm9Zc2BUjd5M8DqScuXn+2bBnjYfQcyjx55XpBF3Tw3WVe3pTHL7aEOK2 ve43hsf47ekT3in+N2PUua+knaW3decjNZ6zg= MIME-Version: 1.0 Received: by 10.142.229.6 with SMTP id b6mr1925289wfh.98.1244285192729; Sat, 06 Jun 2009 03:46:32 -0700 (PDT) In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773A6AFA5CA0@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB773A6AE79A63@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB773A6AFA5CA0@NOK-EUMSG-01.mgdnok.nokia.com> Date: Sat, 6 Jun 2009 16:16:32 +0530 Message-ID: <7ccecf670906060346o1249f3e3s7e7568264e3870a5@mail.gmail.com> From: Raj Singh To: Pasi.Eronen@nokia.com Content-Type: multipart/alternative; boundary=000e0cd32c48e9768f046babb88a Cc: ipsec@ietf.org, vijay@wichorus.com Subject: Re: [IPsec] Final comments for ikev2-redirect-10 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 06 Jun 2009 10:46:32 -0000 --000e0cd32c48e9768f046babb88a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Team, I agree with Pasi. Regards, Raj On Fri, Jun 5, 2009 at 5:12 PM, wrote: > Vijay Devarapalli wrote: > > > > And having these two cases is more complex than having just one > > > (IKE_SA is not used for any more exchanges). What benefits does > > > this additional complexity (both in spec and in implementation) > > > get us? > > > > > > If nothing, let's just remove it.... > > > > When the AUTH payloads are exchanged and verified, the IKEv2 SA is > > valid. This seems straightforward. We are not doing anything out of > > the ordinary here by not invalidating the IKEv2 SA just because the > > gateway sent the REDIRECT payload to the client. > > > > I can imagine extensions tomorrow that would let the client convey > > additional information using the IKEv2 SA to the gateway, after the > > gateway had sent a REDIRECT payload to the client. > > What do you mean by "valid"? So the client could potentially ignore > the redirect (in the last IKE_AUTH response), and continue using the > IKE_SA (at least for some time) for other exhanges? > > AFAIK, the current text is *not* supposed to allow that -- but > it seems it is indeed quite unclear. > > Best regards, > Pasi > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --000e0cd32c48e9768f046babb88a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Team,

I agree with Pasi.

Regards,
Raj

On Fri, Jun 5, 2009 at 5:12 PM, <Pasi.Eronen@nokia.com> = wrote:
Vijay Devarapalli wrote:

> > And having these two cases is more complex than having just one > > (IKE_SA is not used for any more exchanges). What benefits does > > this additional complexity (both in spec and in implementation) > > get us?
> >
> > If nothing, let's just remove it....
>
> When the AUTH payloads are exchanged and verified, the IKEv2 SA is
> valid. =C2=A0This seems straightforward. We are not doing anything out= of
> the ordinary here by not invalidating the IKEv2 SA just because the > gateway sent the REDIRECT payload to the client.
>
> I can imagine extensions tomorrow that would let the client convey
> additional information using the IKEv2 SA to the gateway, after the > gateway had sent a REDIRECT payload to the client.

What do you mean by "valid"? So the client could potentiall= y ignore
the redirect (in the last IKE_AUTH response), and continue using the
IKE_SA (at least for some time) for other exhanges?

AFAIK, the current text is *not* supposed to allow that -- but
it seems it is indeed quite unclear.

Best regards,
Pasi

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

--000e0cd32c48e9768f046babb88a-- From vijay@wichorus.com Wed Jun 10 16:18:55 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAB193A6AC8 for ; Wed, 10 Jun 2009 16:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.087 X-Spam-Level: X-Spam-Status: No, score=0.087 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, RCVD_NUMERIC_HELO=2.067] 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 N9cAYTcCjRyl for ; Wed, 10 Jun 2009 16:18:54 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id BDC3C3A6A36 for ; Wed, 10 Jun 2009 16:18:54 -0700 (PDT) Received: from 99.51.129.145 ([99.51.129.145]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Wed, 10 Jun 2009 23:19:01 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Wed, 10 Jun 2009 16:19:00 -0700 From: Vijay Devarapalli To: Yaron Sheffer , Yoav Nir , Tero Kivinen Message-ID: Thread-Topic: [IPsec] Some comments about redirect Thread-Index: Acnesk3oSIjXgYfrRQexWivag3J31QAATxyjABjoFTwAAFOqHwBjw6AqAEf+1zACFpSsfQ== In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8DED898E3CF@il-ex01.ad.checkpoint.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Some comments about redirect X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 23:18:55 -0000 Hello, On 5/31/09 1:19 AM, "Yaron Sheffer" wrote: > I think we should *not* add this type. I don't see how a client and a > gateway can agree on such a "locally meaningful name", without > non-interoperable protocols (or configuration databases). And I don't think > we should add this new concept, of all places, to the Redirect draft. I don't see a consensus on this yet. Tero and Yoav would like to see this new gateway id type. > But of course we should reserve a portion of the new ID Type registry for > private use. Since new values can be assigned by "Expert Review" do we really need to set aside space for private use? You can always request new assignments without having to revise the RFC. Vijay > > Thanks, > Yaron > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of >> Vijay Devarapalli >> Sent: Saturday, May 30, 2009 0:51 >> To: Yoav Nir; Tero Kivinen >> Cc: ipsec@ietf.org >> Subject: Re: [IPsec] Some comments about redirect >> >> Ok. >> >> Anyone else have any comments on including "4 - Locally Meaningful Name"? >> >> Vijay >> >> >> On 5/27/09 3:14 PM, "Yoav Nir" wrote: >> >>> The client has to have a PAD that includes the gateways. >>> >>> Our implementation has the client downloading the configuration (by a >>> proprietary protocol) that includes the gateway names (and how to find >> them - >>> IP address or DNS name). These gateway names can optionally be shown to >> the >>> user in the GUI. In any case, the client is as aware of the names as >> the >>> gateways. >>> ________________________________________ >>> From: Vijay Devarapalli [vijay@wichorus.com] >>> Sent: Thursday, May 28, 2009 01:04 >>> To: Yoav Nir; Tero Kivinen >>> Cc: ipsec@ietf.org >>> Subject: Re: [IPsec] Some comments about redirect >>> >>> Hi Yoav, >>> >>> On 5/27/09 3:11 AM, "Yoav Nir" wrote: >>> >>>> OK. In that case I would add to the initial registry >>>> >>>> 4 - locally meaningful name >>> >>> The client should be able to resolve this "locally meaningful name" to >> an IP >>> address to which it can initiate a new IKE_SA_INIT exchange. These >> "locally >>> meaningful names" might make sense to the pool of IKEv2 gateways, but >> would >>> it make sense to the client? How does the client figure out what the new >> VPN >>> gateway is? >>> >>> Am I missing something? >>> >>> Vijay >>> >>>> >>>> In our product, the gateways have "names" that appear both in the GUI >> and the >>>> configuration files (and logs). It's easier for them to fetch another >>>> gateway's "object" by name than by IP address. Such a name could be >> ASCII or >>>> UTF-8. >>>> ________________________________________ >>>> From: Tero Kivinen [kivinen@iki.fi] >>> >>> >>> Scanned by Check Point Total Security Gateway. >>> >>> Email secured by Check Point >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> Scanned by Check Point Total Security Gateway. From vijay@wichorus.com Wed Jun 10 16:29:42 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D6F993A6826 for ; Wed, 10 Jun 2009 16:29:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.087 X-Spam-Level: X-Spam-Status: No, score=0.087 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, RCVD_NUMERIC_HELO=2.067] 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 mx6DAoJBaiAu for ; Wed, 10 Jun 2009 16:29:42 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id E1D2A3A6358 for ; Wed, 10 Jun 2009 16:29:41 -0700 (PDT) Received: from 99.51.129.145 ([99.51.129.145]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Wed, 10 Jun 2009 23:29:48 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Wed, 10 Jun 2009 16:29:49 -0700 From: Vijay Devarapalli To: , Message-ID: Thread-Topic: [IPsec] Final comments for ikev2-redirect-10 Thread-Index: Acnd2l1IeD7eu8inRHSVz2Vyii7gVQBOvEnrAClbFHAAOwvwhAFK0rBgARRI32I= In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773A6AFA5CA0@NOK-EUMSG-01.mgdnok.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: Raj Singh Subject: Re: [IPsec] Final comments for ikev2-redirect-10 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2009 23:29:43 -0000 Hi Pasi, On 6/5/09 4:42 AM, "Pasi.Eronen@nokia.com" wrote: > Vijay Devarapalli wrote: > >>> And having these two cases is more complex than having just one >>> (IKE_SA is not used for any more exchanges). What benefits does >>> this additional complexity (both in spec and in implementation) >>> get us? >>> >>> If nothing, let's just remove it.... >> >> When the AUTH payloads are exchanged and verified, the IKEv2 SA is >> valid. This seems straightforward. We are not doing anything out of >> the ordinary here by not invalidating the IKEv2 SA just because the >> gateway sent the REDIRECT payload to the client. >> >> I can imagine extensions tomorrow that would let the client convey >> additional information using the IKEv2 SA to the gateway, after the >> gateway had sent a REDIRECT payload to the client. > > What do you mean by "valid"? So the client could potentially ignore > the redirect (in the last IKE_AUTH response), and continue using the > IKE_SA (at least for some time) for other exhanges? Yes, the client can use the IKEv2 SA for other exchanges if it wants to. When the AUTH payloads have been exchanged and verified, the IKEv2 SA setup is complete, IMO. I don't think the REDIRECT payload during the IKE_AUTH exchange should invalidate the IKEv2 SA. So the IKEv2 SA needs to be explicitly torn down. > AFAIK, the current text is *not* supposed to allow that -- but > it seems it is indeed quite unclear. The current text only says the client SHOULD delete the IKEv2 SA with an Informational message if it receives a REDIRECT payload in the IKE_AUTH response. Only when EAP is used and the gateway decides to redirect based on an unauthenticated ID, is the IKEv2 SA not created. The client does not have to send a message to delete the IKEv2 SA in this case. At least this has been my assumption so far. Vijay > > Best regards, > Pasi > From yaronf@checkpoint.com Wed Jun 10 23:18:07 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 47E1D3A69BD for ; Wed, 10 Jun 2009 23:18:07 -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 D1g8A9c1Bajw for ; Wed, 10 Jun 2009 23:18:06 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id AB01B3A68E7 for ; Wed, 10 Jun 2009 23:18:05 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 621B529C007; Thu, 11 Jun 2009 09:18:17 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 03226200437; Thu, 11 Jun 2009 09:18:16 +0300 (IDT) X-CheckPoint: {4A309FB8-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n5B6IA3d028265; Thu, 11 Jun 2009 09:18:11 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Thu, 11 Jun 2009 09:18:10 +0300 From: Yaron Sheffer To: Vijay Devarapalli , Yoav Nir , Tero Kivinen Date: Thu, 11 Jun 2009 09:18:08 +0300 Thread-Topic: [IPsec] Some comments about redirect Thread-Index: Acnesk3oSIjXgYfrRQexWivag3J31QAATxyjABjoFTwAAFOqHwBjw6AqAEf+1zACFpSsfQAOKNzg Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8DED8AF30A7@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8DED898E3CF@il-ex01.ad.checkpoint.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0005_01C9EA75.8891CEA0" MIME-Version: 1.0 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] Some comments about redirect X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 06:18:07 -0000 ------=_NextPart_000_0005_01C9EA75.8891CEA0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Vijay, I agree there is no consensus on the "locally meaningful name". But I'd like to hear more opinions before we add new stuff to the draft at this late stage. Regarding private values: We want to encourage experimentation with the protocol, and private values are an important part of that. People may not have stable documentation when they start to deploy a system, or such documentation may be confidential. Private use ranges provide an easy way for vendors to deal with such cases. In this particular case, I don't see any reason NOT to include a private range. Thanks, Yaron > -----Original Message----- > From: Vijay Devarapalli [mailto:vijay@wichorus.com] > Sent: Thursday, June 11, 2009 2:19 > To: Yaron Sheffer; Yoav Nir; Tero Kivinen > Cc: ipsec@ietf.org > Subject: Re: [IPsec] Some comments about redirect > > Hello, > > On 5/31/09 1:19 AM, "Yaron Sheffer" wrote: > > > I think we should *not* add this type. I don't see how a client and a > > gateway can agree on such a "locally meaningful name", without > > non-interoperable protocols (or configuration databases). And I don't > think > > we should add this new concept, of all places, to the Redirect draft. > > I don't see a consensus on this yet. Tero and Yoav would like to see this > new gateway id type. > > > But of course we should reserve a portion of the new ID Type registry > for > > private use. > > Since new values can be assigned by "Expert Review" do we really need to > set > aside space for private use? You can always request new assignments > without > having to revise the RFC. > > Vijay > > > > > Thanks, > > Yaron > > > >> -----Original Message----- > >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of > >> Vijay Devarapalli > >> Sent: Saturday, May 30, 2009 0:51 > >> To: Yoav Nir; Tero Kivinen > >> Cc: ipsec@ietf.org > >> Subject: Re: [IPsec] Some comments about redirect > >> > >> Ok. > >> > >> Anyone else have any comments on including "4 - Locally Meaningful > Name"? > >> > >> Vijay > >> > >> > >> On 5/27/09 3:14 PM, "Yoav Nir" wrote: > >> > >>> The client has to have a PAD that includes the gateways. > >>> > >>> Our implementation has the client downloading the configuration (by a > >>> proprietary protocol) that includes the gateway names (and how to find > >> them - > >>> IP address or DNS name). These gateway names can optionally be shown > to > >> the > >>> user in the GUI. In any case, the client is as aware of the names as > >> the > >>> gateways. > >>> ________________________________________ > >>> From: Vijay Devarapalli [vijay@wichorus.com] > >>> Sent: Thursday, May 28, 2009 01:04 > >>> To: Yoav Nir; Tero Kivinen > >>> Cc: ipsec@ietf.org > >>> Subject: Re: [IPsec] Some comments about redirect > >>> > >>> Hi Yoav, > >>> > >>> On 5/27/09 3:11 AM, "Yoav Nir" wrote: > >>> > >>>> OK. In that case I would add to the initial registry > >>>> > >>>> 4 - locally meaningful name > >>> > >>> The client should be able to resolve this "locally meaningful name" to > >> an IP > >>> address to which it can initiate a new IKE_SA_INIT exchange. These > >> "locally > >>> meaningful names" might make sense to the pool of IKEv2 gateways, but > >> would > >>> it make sense to the client? How does the client figure out what the > new > >> VPN > >>> gateway is? > >>> > >>> Am I missing something? > >>> > >>> Vijay > >>> > >>>> > >>>> In our product, the gateways have "names" that appear both in the GUI > >> and the > >>>> configuration files (and logs). It's easier for them to fetch another > >>>> gateway's "object" by name than by IP address. Such a name could be > >> ASCII or > >>>> UTF-8. > >>>> ________________________________________ > >>>> From: Tero Kivinen [kivinen@iki.fi] > >>> > >>> > >>> Scanned by Check Point Total Security Gateway. > >>> > >>> Email secured by Check Point > >> > >> _______________________________________________ > >> 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. ------=_NextPart_000_0005_01C9EA75.8891CEA0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDYxMTA2MTgwOFowIwYJKoZIhvcNAQkEMRYEFJUbIG9I71NF blNbG6KixkE09lHuMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA l9obToajv613hLvB8GfjdhjYclQhWBplN8tIZGofdFew3qA5Bhpyrfh9kqzcPswRfSe2zdnBXzWY F1DQIRlRPOmrQi64N32egIUyyOT2x8Cdg8JR5Zxs7CtB0Y+gupY8l4QQSpsHghjXmRgSUiRj5vPn ryFT/dZa45ygyjus0XlfxsKApjQ6vM5aSAHoFBpnugACBFBlLOiQ0h1oaFs6K4REVQ6S9BfrYkSt l2gJNANvXRar9rHYJU1qkV+46GPDnd3O6B6LOEHjUd+w+zleOmBN9m+sRBVcBb3GfQ6TxaMbGvSJ ES4lvs4nHlCCTYXW2JGgxwa0ySho/vz5s21dIwAAAAAAAA== ------=_NextPart_000_0005_01C9EA75.8891CEA0-- From kivinen@iki.fi Thu Jun 11 02:00:55 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98F463A6B3D for ; Thu, 11 Jun 2009 02: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=[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 BR56KQWB1cwe for ; Thu, 11 Jun 2009 02:00:54 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 594B13A696C for ; Thu, 11 Jun 2009 02:00:53 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n5B90rf2023161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 12:00:53 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n5B90q4c027580; Thu, 11 Jun 2009 12:00:52 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18992.51140.513038.329964@fireball.kivinen.iki.fi> Date: Thu, 11 Jun 2009 12:00:52 +0300 From: Tero Kivinen To: Yaron Sheffer In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8DED8AF30A7@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8DED898E3CF@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8DED8AF30A7@il-ex01.ad.checkpoint.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 3 min Cc: "ipsec@ietf.org" , Vijay Devarapalli , Yoav Nir Subject: Re: [IPsec] Some comments about redirect X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 09:00:55 -0000 Yaron Sheffer writes: > Hi Vijay, > > I agree there is no consensus on the "locally meaningful name". But I'd like > to hear more opinions before we add new stuff to the draft at this late > stage. > > Regarding private values: We want to encourage experimentation with the > protocol, and private values are an important part of that. People may not > have stable documentation when they start to deploy a system, or such > documentation may be confidential. Private use ranges provide an easy way > for vendors to deal with such cases. In this particular case, I don't see > any reason NOT to include a private range. The reason I was supporting "locally meaningful name" is that in most cases the redirection support is used inside one adminstrative domain and that adminstrative domain often use some kind of centralized policy distribution system and that means that all clients & gateways will have some kind of "locally meaningful name" in their centrally distributed policy and redirecting from one name to another makes more sense than redirecting from one IP to another. As those implementations used there are quite often also from same vendor I assume private use range could also be used here without any problems. So I think we need at least the private use range so vendors can use that one number from there as their "locally meaningful name". -- kivinen@iki.fi From Pasi.Eronen@nokia.com Thu Jun 11 03:13:14 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A446E3A68BB for ; Thu, 11 Jun 2009 03:13:14 -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 znN-6wdH2Z6L for ; Thu, 11 Jun 2009 03:13:13 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 73CA53A67B0 for ; Thu, 11 Jun 2009 03:13:13 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.2.6/Switch-3.2.6) with ESMTP id n5BACtI9003282; Thu, 11 Jun 2009 13:13:11 +0300 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Jun 2009 13:13:12 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Thu, 11 Jun 2009 13:13:07 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Thu, 11 Jun 2009 12:13:07 +0200 From: To: , Date: Thu, 11 Jun 2009 12:13:04 +0200 Thread-Topic: [IPsec] Final comments for ikev2-redirect-10 Thread-Index: Acnd2l1IeD7eu8inRHSVz2Vyii7gVQBOvEnrAClbFHAAOwvwhAFK0rBgARRI32IAFkNEkA== Message-ID: <808FD6E27AD4884E94820BC333B2DB773A6B02EF69@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB773A6AFA5CA0@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 11 Jun 2009 10:13:07.0288 (UTC) FILETIME=[3717AD80:01C9EA7D] X-Nokia-AV: Clean Subject: Re: [IPsec] Final comments for ikev2-redirect-10 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 10:13:14 -0000 Vijay Devarapalli wrote: > > What do you mean by "valid"? So the client could potentially ignore > > the redirect (in the last IKE_AUTH response), and continue using the > > IKE_SA (at least for some time) for other exhanges? >=20 > Yes, the client can use the IKEv2 SA for other exchanges if it wants > to. When the AUTH payloads have been exchanged and verified, the > IKEv2 SA setup is complete, IMO. I don't think the REDIRECT payload > during the IKE_AUTH exchange should invalidate the IKEv2 SA. So the > IKEv2 SA needs to be explicitly torn down. >=20 > > AFAIK, the current text is *not* supposed to allow that -- but > > it seems it is indeed quite unclear. >=20 > The current text only says the client SHOULD delete the IKEv2 SA > with an Informational message if it receives a REDIRECT payload in > the IKE_AUTH response. Only when EAP is used and the gateway decides > to redirect based on an unauthenticated ID, is the IKEv2 SA not > created. The client does not have to send a message to delete the > IKEv2 SA in this case. >=20 > At least this has been my assumption so far. This is exactly the opposite of my assumption so far, so clearly the draft needs to be clarified one way or another. Anyone else in the WG care to comment? If the gateway sends REDIRECT in the last IKE_AUTH response, can the client ignore it and continue using the IKE_SA? =20 (REDIRECT during IKE_SA_INIT clearly cannot be ignored by the=20 client; at least, it cannot continue the IKE negotiation.) Best regards, Pasi From kivinen@iki.fi Thu Jun 11 03:22:06 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5634928C154 for ; Thu, 11 Jun 2009 03:22:06 -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 SXV06pYeXVLK for ; Thu, 11 Jun 2009 03:22:05 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id 3BD4D3A67DB for ; Thu, 11 Jun 2009 03:22:05 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n5BAM7C2026153 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 13:22:07 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n5BAM7Y1003603; Thu, 11 Jun 2009 13:22:07 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18992.56015.638522.786574@fireball.kivinen.iki.fi> Date: Thu, 11 Jun 2009 13:22:07 +0300 From: Tero Kivinen To: In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773A6B02EF69@NOK-EUMSG-01.mgdnok.nokia.com> References: <808FD6E27AD4884E94820BC333B2DB773A6AFA5CA0@NOK-EUMSG-01.mgdnok.nokia.com> <808FD6E27AD4884E94820BC333B2DB773A6B02EF69@NOK-EUMSG-01.mgdnok.nokia.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, vijay@wichorus.com Subject: Re: [IPsec] Final comments for ikev2-redirect-10 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 10:22:06 -0000 Pasi.Eronen@nokia.com writes: > Anyone else in the WG care to comment? If the gateway sends REDIRECT > in the last IKE_AUTH response, can the client ignore it and continue > using the IKE_SA? I did assume that, as the IKE SA was created completely, and it is usable. Of course client should follow the redirection and delete the IKE SA after that is finished, but there is nothing which results the IKE SA to be unusable in that case. > (REDIRECT during IKE_SA_INIT clearly cannot be ignored by the > client; at least, it cannot continue the IKE negotiation.) Same goes for the REDIRECT during the IKE_AUTH if redirection is done based on the unauthenticated identity (i.e. IKE SA is not finished). -- kivinen@iki.fi From vijay@wichorus.com Thu Jun 11 14:13:21 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B29A3A6B9A for ; Thu, 11 Jun 2009 14:13:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.532 X-Spam-Level: X-Spam-Status: No, score=-0.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_NUMERIC_HELO=2.067] 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 Rpup297PQo2M for ; Thu, 11 Jun 2009 14:13:20 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 7218B3A6B67 for ; Thu, 11 Jun 2009 14:13:20 -0700 (PDT) Received: from 12.204.153.98 ([12.204.153.98]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Thu, 11 Jun 2009 21:13:27 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Thu, 11 Jun 2009 14:13:24 -0700 From: Vijay Devarapalli To: Tero Kivinen , Yaron Sheffer Message-ID: Thread-Topic: [IPsec] Some comments about redirect Thread-Index: Acnq2XR+9GRT7HawNE2W7UK3ZcEmOQ== In-Reply-To: <18992.51140.513038.329964@fireball.kivinen.iki.fi> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: "ipsec@ietf.org" , Yoav Nir Subject: Re: [IPsec] Some comments about redirect X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 21:13:21 -0000 Hello Yaron, Tero, Ok, I am fine with setting aside some space for private GW identity. Lets set aside 240-255. Since we have the private space, I guess we don't need the "locally meaningful name" as a GW identity. Vijay On 6/11/09 2:00 AM, "Tero Kivinen" wrote: > Yaron Sheffer writes: >> Hi Vijay, >> >> I agree there is no consensus on the "locally meaningful name". But I'd like >> to hear more opinions before we add new stuff to the draft at this late >> stage. >> >> Regarding private values: We want to encourage experimentation with the >> protocol, and private values are an important part of that. People may not >> have stable documentation when they start to deploy a system, or such >> documentation may be confidential. Private use ranges provide an easy way >> for vendors to deal with such cases. In this particular case, I don't see >> any reason NOT to include a private range. > > The reason I was supporting "locally meaningful name" is that in most > cases the redirection support is used inside one adminstrative domain > and that adminstrative domain often use some kind of centralized > policy distribution system and that means that all clients & gateways > will have some kind of "locally meaningful name" in their centrally > distributed policy and redirecting from one name to another makes more > sense than redirecting from one IP to another. > > As those implementations used there are quite often also from same > vendor I assume private use range could also be used here without any > problems. > > So I think we need at least the private use range so vendors can use > that one number from there as their "locally meaningful name". From kent@bbn.com Thu Jun 11 16:58:21 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CDE103A6837 for ; Thu, 11 Jun 2009 16:58:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=-0.021, BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044] 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 jran-Tz-RM1g for ; Thu, 11 Jun 2009 16:58:21 -0700 (PDT) Received: from mx11.bbn.com (mx11.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 367F13A67E3 for ; Thu, 11 Jun 2009 16:58:21 -0700 (PDT) Received: from dommiel.bbn.com ([192.1.122.15] helo=[10.77.11.211]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1MEtE3-0005CG-Fe; Thu, 11 Jun 2009 18:58:27 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8DED8AF30A7@il-ex01.ad.checkpoint.com> References: <7F9A6D26EB51614FBF9F81C0DA4CFEC8DED898E3CF@il-ex01.ad.checkpoint.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8DED8AF30A7@il-ex01.ad.checkpoint.com> Date: Thu, 11 Jun 2009 15:49:22 -0400 To: Yaron Sheffer From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" Cc: "ipsec@ietf.org" , Vijay Devarapalli , Yoav Nir , Tero Kivinen Subject: Re: [IPsec] Some comments about redirect X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2009 23:58:21 -0000 Yaron, Add me to the list of folks who does not understand how a locally meaningful name works. I'd like to see a more thorough discussion of this notion before we proceed. Steve From yaronf@checkpoint.com Fri Jun 12 12:09:05 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5BF13A682E for ; Fri, 12 Jun 2009 12:09:05 -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 tihMOWFvOuZF for ; Fri, 12 Jun 2009 12:09:04 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 8FDD93A6ADD for ; Fri, 12 Jun 2009 12:08:55 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id A55CC29C002; Fri, 12 Jun 2009 22:09:08 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 484EE20037A; Fri, 12 Jun 2009 22:09:08 +0300 (IDT) X-CheckPoint: {4A32A5CE-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n5CJ913d019086; Fri, 12 Jun 2009 22:09:01 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Fri, 12 Jun 2009 22:09:01 +0300 From: Yaron Sheffer To: "Pasi.Eronen@nokia.com" , "ipsec@ietf.org" Date: Fri, 12 Jun 2009 22:08:57 +0300 Thread-Topic: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-resumption-04.txt Thread-Index: AcnVmMEj2J2LXoVkQamMww7oVGxsbAK9MhFwAF31gbAA9Bv/IAFuVuxQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8DED8AF3215@il-ex01.ad.checkpoint.com> References: <20090515163001.6D4AB28C106@core3.amsl.com> <808FD6E27AD4884E94820BC333B2DB773A6AEBC734@NOK-EUMSG-01.mgdnok.nokia.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8DED898E4C7@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB773A6AFA5D01@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773A6AFA5D01@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_008E_01C9EBAA.61FF78B0" MIME-Version: 1.0 Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-resumption-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Jun 2009 19:09:05 -0000 ------=_NextPart_000_008E_01C9EBAA.61FF78B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi Pasi, Sorry for the late reply. I believe most people would NOT expect a properly terminated (deleted) IKE SA to be resumed. To give one example, suppose I "downsize" a user and revoke his access rights. Today I will simply terminate (=delete) all his existing SAs, and then will rely on the next IKE setup to revalidate the user with the AAA server, which will correctly fail. Resumption would bypass this check. We could add a flag to the 2 notifications for the gateway to signal to the client that it implements a different semantics, i.e. it is willing to resume a previously deleted SA. Do you think this use case is worth the added complexity? Thanks, Yaron > -----Original Message----- > From: Pasi.Eronen@nokia.com [mailto:Pasi.Eronen@nokia.com] > Sent: Friday, June 05, 2009 15:23 > To: Yaron Sheffer; ipsec@ietf.org > Subject: RE: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-resumption- > 04.txt > > Yaron Sheffer wrote: > > > > > The current ikev2-resumption draft, on the other hand, seems to > > > assume a quite different model, where resumption replaces the old > > > connection, and can be done only if the old connection was > > > interrupted. > > > > > > This would seem to preclude one case discussed earlier: I close my > > > laptop (cleanly) at work, commute, and reconnect at home (without > > > having to do EAP again; e.g. type in one-time password). Or "switch > > > off my phone (cleanly), fly to IETF meeting, and switch it back on". > > > > > > In case of IKEv2, having multiple parallel IKE connections is > > > probably less common than with TLS (where it's very common), but > > > to me it seems using the IKE_SESSION_RESUME handshake when the old > > > IKE_SA was cleanly closed would be quite useful, and should be > > > supported. (And making the "new connection" completely independent > > > of the old one might simplify the protocol anyway.) > > > > > > (Or in other words: I'd propose changing Section 7.2, 1st paragraph, > > > and making these MUSTs MAYs.) > > > > [YS] Let me answer at two levels, the principle of session > > resumption and the particular use case you present. > > > > At the principle level, I think SSL/TLS history, going back to HTTP > > 1.0, required support of many concurrent "cloned" sessions. Typical > > use of IKE, at least for RA VPN, is different, preferring a single > > instance per client. So much so that even the concept of > > reauthentication was only recognized post 4306 (RFC 4478). > > > > Regarding the use case, most security policies will require you to > > reauthenticate after a logout/suspend. But even if your scenario is > > legit, I don't see why the current draft precludes the client from > > implementing this behavior. > > > > One interesting use case that would support your view is setting up > > simultaneous IKE SAs to multiple gateways, with no need to > > authenticate to each one separately. But that's of course WAY out of > > scope. > > > > Also, I believe your issue is NOT with the MUSTs in Sec. 7.2, it is > > rather with the last paragraph of 4.3, quoted here: > > > > When the responder receives a ticket for an IKE SA that is still > > active and if the responder accepts it, then the old SA SHOULD be > > silently deleted without sending a DELETE informational > > exchange. Consequently, all the dependent IPsec child SAs are also > > deleted. This happens after both peers have been authenticated. > > Note that my comment had two somewhat separate concerns: prohibiting > parallel IKE SAs, and prohibiting using this mechanism when the IKE_SA > was cleanly closed. > > I think you're right that parallel IKE SAs aren't really needed. > > But why the resumption mechanism can't be used if the session was > termined cleanly instead of dead-peer-detection timeout? I think this > restriction doesn't give us any benefits, and loses some flexibility.. > > > > > 6) Section 6: The word "Unspecified" is probably wrong here -- > > > this document has to specify these (but clearly an implementation > > > doesn't have to include in the ticket any data it never uses). > > > > [YS] I have used "unspecified" as synonymous with "implementation > > specific". Or do you want to propose alternative text? > > I don't think "implementation speific" is the right term either, If > the implementation needs e.g. the certificates after resumption, it > is *not* implementation specific whether they come from the ticket > (or local store) or the new exchange. > > I think the text should say "From the ticket", with a note explaining > that some implementations may not need this information during/after > resumption, and in this case, it doesn't have to be stored anywhere. > > > > > 8) The text about handling IDr is very unclear -- certainly the > > > gateway can't start to use some other IDr in the new IKE_SA, > > > without authenticating it? > > > > [YS] Unfortunately you are right, but this eliminates important > > flexibility in naming the gateways. We *could* say that the client > > trusts the gateway to identify itself, because the gateway is > > clearly a member of the "trusted gateways" group (it is able to > > decrypt the ticket). But that still sounds wrong. > > The gateway is part of the *same* group as the original gateway (who > authenticated itself, probably with certificates) -- but that doesn't > mean it's trusted to use someone else's SPD/PAD entries (for some > other gateway/group of gateways than the original one). > > So on client, the IDr (used for SPD/PAD lookups) should come from the > ticket/local storage, not from the new exchange... (unless the gateway > actually authenticates it's really the new IDr) > > > > 9) Section 7.1: Why are storing SPIi/SPIr and the authentication > > > method "MUST"s? (The gateway doesn't seem to really need those for > > > anything) > > > > > [YS] SPIi/SPIr are used to identify the SA we are resuming (see > > discussion above). > > That seems like an internal implementation detail... > > > The authentication method seems to be useful, e.g. to know that you > > should expect a cert to be included. But yes, the auth method could > > be left implementation-dependent. > > But the client does *not* include a certificate when doing resumption, > so if the gateway expects to receive a cert, it will never get one? > > However, the draft should probably clarify that the ticket (or local > storage) has to include the authenticated peer identity used for > policy lookups -- which is not necessarily the same as IDi payload > (see RFC 4718, Section 3.5). (And if the value from IDi isn't actually > used for anything, it obviously doesn't have to be stored either.) > > Best regards, > Pasi > > Scanned by Check Point Total Security Gateway. ------=_NextPart_000_008E_01C9EBAA.61FF78B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDYxMjE5MDg1N1owIwYJKoZIhvcNAQkEMRYEFNpywfBR3dPe NhzALRbSZF7C/XHKMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA Hk+y1dg2pAx29he5iT/YV1eCOwezI4G1kPCPZrR0KNbt7PgT0h8GzpzuR6yOH0zdxiKFaQlYzrlr V4+hEWZkitMPCrutozMnGM6M1kWP7r/gGTwxcaOecVD9al3l5vzfa3+I7HfCyeXlNHCQF13em1JG EsnMwlIeOrnvdMzw1vgo8lJ6bdER2JHY4sPsDsVUuHFyOLKz1L172aahZWN++QzLsllpYF7rXtaL K5ymQzxUhUMU69JV6OiCBjZSx95A/N38a4NamKdtGtuoIA6n/29igbl2F7kIcmTOV5jh56gNpOOO Eq0Dc+CpKywXxs2/DFLKGFePBtWEvvFCfHVScAAAAAAAAA== ------=_NextPart_000_008E_01C9EBAA.61FF78B0-- From vijay@wichorus.com Mon Jun 15 15:53:46 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4EDD03A6858 for ; Mon, 15 Jun 2009 15:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.087 X-Spam-Level: X-Spam-Status: No, score=0.087 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_SORBS_WEB=0.619, RCVD_NUMERIC_HELO=2.067] 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 gqxqCUNNLGId for ; Mon, 15 Jun 2009 15:53:45 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id 275383A682B for ; Mon, 15 Jun 2009 15:53:45 -0700 (PDT) Received: from 38.96.10.141 ([38.96.10.141]) by mse15be2.mse15.exchange.ms ([172.30.10.130]) via Exchange Front-End Server owa.mse15.exchange.ms ([172.30.10.124]) with Microsoft Exchange Server HTTP-DAV ; Mon, 15 Jun 2009 22:53:55 +0000 User-Agent: Microsoft-Entourage/12.10.0.080409 Date: Mon, 15 Jun 2009 15:53:54 -0700 From: Vijay Devarapalli To: , Message-ID: Thread-Topic: [IPsec] Final comments for ikev2-redirect-10 Thread-Index: Acnd2l1IeD7eu8inRHSVz2Vyii7gVQBOvEnrAClbFHAAOwvwhAFK0rBgARRI32IAFkNEkADj8KEp In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773A6B02EF69@NOK-EUMSG-01.mgdnok.nokia.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [IPsec] Final comments for ikev2-redirect-10 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2009 22:53:46 -0000 Hi Pasi, On 6/11/09 3:13 AM, "Pasi.Eronen@nokia.com" wrote: > Vijay Devarapalli wrote: > >>> What do you mean by "valid"? So the client could potentially ignore >>> the redirect (in the last IKE_AUTH response), and continue using the >>> IKE_SA (at least for some time) for other exhanges? >> >> Yes, the client can use the IKEv2 SA for other exchanges if it wants >> to. When the AUTH payloads have been exchanged and verified, the >> IKEv2 SA setup is complete, IMO. I don't think the REDIRECT payload >> during the IKE_AUTH exchange should invalidate the IKEv2 SA. So the >> IKEv2 SA needs to be explicitly torn down. >> >>> AFAIK, the current text is *not* supposed to allow that -- but >>> it seems it is indeed quite unclear. >> >> The current text only says the client SHOULD delete the IKEv2 SA >> with an Informational message if it receives a REDIRECT payload in >> the IKE_AUTH response. Only when EAP is used and the gateway decides >> to redirect based on an unauthenticated ID, is the IKEv2 SA not >> created. The client does not have to send a message to delete the >> IKEv2 SA in this case. >> >> At least this has been my assumption so far. > > This is exactly the opposite of my assumption so far, so clearly the > draft needs to be clarified one way or another. I think the current already describes what I wrote in my previous mail. But just to make sure it is very explicit, we can make the following text changes. Replace If the gateway decides to redirect the client during the IKE_AUTH exchange, based on the identity presented by the client in the IKE_AUTH request message, it prevents the creation of a CHILD SA and sends the REDIRECT payload in the IKE_AUTH response. When the client receives the IKE_AUTH response with the REDIRECT payload, it SHOULD delete the existing IKEv2 security association with the gateway by sending an Informational message with a DELETE payload. The gateway MUST verify the client's AUTH payload before sending the Redirect payload, and the client MUST verify the gateway's AUTH payload before acting on the Redirect payload. With If the gateway decides to redirect the client during the IKE_AUTH exchange, based on the identity presented by the client in the IKE_AUTH request message, it prevents the creation of a CHILD SA and sends the REDIRECT payload in the IKE_AUTH response. The gateway MUST verify the client's AUTH payload before sending the Redirect payload, and the client MUST verify the gateway's AUTH payload before acting on the Redirect payload. Since the AUTH payloads were exchanged and successfully verified, the IKEv2 security association is valid. When the client receives the IKE_AUTH response with the REDIRECT payload, it SHOULD delete the IKEv2 security association with the gateway by sending an Informational message with a DELETE payload. In addition, we already have the following text in section 6 When EAP is used, the gateway MAY also redirect the client based on the unauthenticated identity presented by the client in the first IKE_AUTH exchange itself. Since EAP is used as the authentication mechanism, the client does not include AUTH payload to authenticate his identity, but the server still MUST include his own AUTH payload, and client MUST verify it. Note that the IKEv2 SA is not created in this case and the client does not have to explicitly delete the IKEv2 SA. Vijay > > Anyone else in the WG care to comment? If the gateway sends REDIRECT > in the last IKE_AUTH response, can the client ignore it and continue > using the IKE_SA? > > (REDIRECT during IKE_SA_INIT clearly cannot be ignored by the > client; at least, it cannot continue the IKE negotiation.) > > Best regards, > Pasi > From root@core3.amsl.com Tue Jun 16 05:00:01 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 656D33A6927; Tue, 16 Jun 2009 05:00:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090616120001.656D33A6927@core3.amsl.com> Date: Tue, 16 Jun 2009 05:00:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-resumption-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 12:00:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : IKEv2 Session Resumption Author(s) : Y. Sheffer, H. Tschofenig Filename : draft-ietf-ipsecme-ikev2-resumption-05.txt Pages : 28 Date : 2009-06-16 The Internet Key Exchange version 2 (IKEv2) protocol has a certain computational and communication overhead with respect to the number of round-trips required and the cryptographic operations involved. In remote access situations, the Extensible Authentication Protocol (EAP) is used for authentication, which adds several more round trips and consequently latency. To re-establish security associations (SAs) upon a failure recovery condition is time consuming especially when an IPsec peer (such as a VPN gateway) needs to re-establish a large number of SAs with various end points. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA re-establishment. In order to avoid the need to re-run the key exchange protocol from scratch it would be useful to provide an efficient way to resume an IKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously established IKE SA. A client can reconnect to a gateway from which it was disconnected. The proposed approach encodes partial IKE state into an opaque ticket, which can be stored on the client or in a centralized store, and is later made available to the IKEv2 responder for re- authentication. We use the term ticket to refer to the opaque data that is created by the IKEv2 responder. This document does not specify the format of the ticket but examples are provided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-resumption-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-ikev2-resumption-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-06-16045000.I-D@ietf.org> --NextPart-- From srinid@cisco.com Tue Jun 16 08:55:27 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C1C63A6D82 for ; Tue, 16 Jun 2009 08:55:27 -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 7ssC2ARKQT7I for ; Tue, 16 Jun 2009 08:55:25 -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 CB2E83A6D7F for ; Tue, 16 Jun 2009 08:55:25 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,229,1243814400"; d="scan'208,217";a="325078446" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 16 Jun 2009 15:55:21 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5GFtLpK025478 for ; Tue, 16 Jun 2009 08:55:21 -0700 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by sj-core-4.cisco.com (8.13.8/8.13.8) with ESMTP id n5GFtK7x005440 for ; Tue, 16 Jun 2009 15:55:21 GMT Received: from xmb-bgl-41c.cisco.com ([72.163.129.218]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 16 Jun 2009 21:25:20 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9EE9A.D9A0B2EA" Date: Tue, 16 Jun 2009 21:25:18 +0530 Message-ID: <3A8C969225424C4D8E6BEE65ED8552DA069C9A@XMB-BGL-41C.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: About port floating b/w 4500 and 500 Thread-Index: AcnumtjeVhdZl+mWR+qpsewiEall6A== From: "Srinivasu S R S Dhulipala (srinid)" To: X-OriginalArrivalTime: 16 Jun 2009 15:55:20.0113 (UTC) FILETIME=[D9ACE210:01C9EE9A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5201; t=1245167721; x=1246031721; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=srinid@cisco.com; z=From:=20=22Srinivasu=20S=20R=20S=20Dhulipala=20(srinid)=22 =20 |Subject:=20About=20port=20floating=20b/w=204500=20and=2050 0 |Sender:=20; bh=QrObC4YJog1FMJnAVo7Eqn3WJrrHSxTjQ903qUEcjHk=; b=WgVFxLi6Wo0XvBpCOwq9gcb4RSl6VUMEdiZPDu60q3X+RK3NMv0bojOQcn Sd+5eTejtWbFLyfvwDcaj1rpvxQuqM96wHXgVOTFCFXINiygk3+MVCxpRq0a Y5lLCdS8EAfU1VXm6M9b4z8NmIpklPmHasdnVawY1+QiXi4BSzRig=; Authentication-Results: sj-dkim-1; header.From=srinid@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: [IPsec] About port floating b/w 4500 and 500 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 15:55:27 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9EE9A.D9A0B2EA Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi team, I request clarification here. Sec 2.23 "NAT traversal" on Page 58 of draft-ietf-ipsecme-ikev2bis-03.txt says : An initiator can float to port 4500, regardless whether or not there is NAT, even at the beginning of IKE. When either side is using port 4500, sending with UDP encapsulation is not required, but understanding received packets with UDP encapsulation is required. UDP encapsulation MUST NOT be done on port 500. If NAT-T is supported (that is, if NAT_DETECTION_*_IP payloads were exchanged during IKE_SA_INIT), all devices MUST be able to receive and process both UDP encapsulated and non-UDP encapsulated packets at any time. Either side can decide whether or not to use UDP encapsulation irrespective of the choice made by the other side. However, if a NAT is detected, both devices MUST send UDP encapsulated packets. Later on the same page as a NAT requirement says:=20 o IKE MUST listen on port 4500 as well as port 500. IKE MUST respond to the IP address and port from which packets arrived. With the above NAT-T and MOBIKE in the context, I've the following questions: 1) Can an IKE peer that migrated to 4500 for some reason migrate back to 500 later? Is that allowed? 2) One use case I see is that an IKE initiator who supports MOBIKE does IKE_SA_INIT=20 exchange on port 500. According to MOBIKE RFC, it sends message 3 on port 4500. Let=20 us assume that the responder does not support MOBIKE. =20 Is the responder expected to respond on port 4500? 3) Continuing case 2) above, what is the port on which both the peers are supposed to=20 communicate afterwards? Initiator learnt that resonder is not supporting MOBIKE. Is it=20 expected to contiue on port 4500? That is, if one peer migrates to 4500, is it expected to=20 continue on that port and not migrate back? Thanks, Srinivas ------_=_NextPart_001_01C9EE9A.D9A0B2EA Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi team,

I request clarification here. Sec 2.23 "NAT = traversal" on=20 Page 58 of  draft-ietf-ipsecme-ikev2bis-03.txt says = :
   An initiator can float to port 4500, regardless =
whether or not there
   is NAT, even at the beginning of IKE.  When =
either side is using port

   4500, sending with UDP encapsulation is not required, but
   =
understanding received packets with UDP encapsulation is required.
   =
UDP encapsulation MUST NOT be done on port 500.  If NAT-T is
   =
supported (that is, if NAT_DETECTION_*_IP payloads were exchanged


   during IKE_SA_INIT), all devices MUST be able to receive and =
process
   both UDP encapsulated and non-UDP encapsulated packets at =
any time.
   Either side can decide whether or not to use UDP =
encapsulation
   irrespective of the choice made by the other side.  =
However, if a NAT


   is detected, both devices MUST send UDP encapsulated =
packets.

Later on the same page as a NAT requirement says: 
   =
o  IKE MUST listen on port 4500 as well as port 500.  IKE MUST
      =
respond to the IP address and port from which packets arrived.
With the above NAT-T and MOBIKE in the context, I've the following=20 questions:

1) Can an IKE peer that migrated to 4500 for some = reason=20 migrate back to
    500 later? Is that = allowed?
2) One use case I see is that an IKE initiator who supports MOBIKE = does=20 IKE_SA_INIT
    exchange on = port 500.=20 According to MOBIKE RFC, it sends message 3 on port 4500. Let
    us assume = that the=20 responder does not support MOBIKE. =20
    Is the = responder=20 expected to respond on port 4500?
3) Continuing case 2) above, what is the port on which both the = peers are=20 supposed to
    = communicate=20 afterwards? Initiator learnt that resonder is not supporting MOBIKE. Is = it=20
    expected = to=20 contiue on port 4500? That is, if one peer migrates to 4500, is it = expected to=20
    continue = on that=20 port and not migrate back?

Thanks,
Srinivas

------_=_NextPart_001_01C9EE9A.D9A0B2EA-- From root@core3.amsl.com Tue Jun 16 11:15:01 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id A67583A6969; Tue, 16 Jun 2009 11:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090616181501.A67583A6969@core3.amsl.com> Date: Tue, 16 Jun 2009 11:15:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-11.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2009 18:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Redirect Mechanism for IKEv2 Author(s) : V. Devarapalli, K. Weniger Filename : draft-ietf-ipsecme-ikev2-redirect-11.txt Pages : 16 Date : 2009-06-16 IKEv2 is a protocol for setting up VPN tunnels from a remote location to a gateway so that the VPN client can access services in the network behind the gateway. Currently there is no standard mechanism specified that allows an overloaded VPN gateway or a VPN gateway that is being shut down for maintenance to redirect the VPN client to attach to another gateway. This document proposes a redirect mechanism for IKEv2. The proposed mechanism can also be used in Mobile IPv6 to enable the home agent to redirect the mobile node to another home agent. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-redirect-11.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-ikev2-redirect-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-06-16110740.I-D@ietf.org> --NextPart-- From paul.hoffman@vpnc.org Tue Jun 16 18:51:40 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 410F63A6C27 for ; Tue, 16 Jun 2009 18:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.533 X-Spam-Level: X-Spam-Status: No, score=-2.533 tagged_above=-999 required=5 tests=[AWL=0.066, 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 vQI44rQ9lDiW for ; Tue, 16 Jun 2009 18:51:39 -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 0CADD3A6BDD for ; Tue, 16 Jun 2009 18:51:38 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5H1pkXb061050 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 16 Jun 2009 18:51:47 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 16 Jun 2009 18:51:44 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Fwd: Last Call: draft-ietf-ipsecme-ikev2-redirect (Redirect Mechanism X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 01:51:40 -0000 [[ The IETF mailer managed to break the outgoing message... ]] >X-Original-To: ietf-announce@ietf.org >Delivered-To: ietf-announce@core3.amsl.com >X-idtracker: yes >To: IETF-Announce >From: The IESG >Subject: Last Call: draft-ietf-ipsecme-ikev2-redirect (Redirect Mechanism >Date: Tue, 16 Jun 2009 17:29:08 -0700 (PDT) >X-BeenThere: ietf-announce@ietf.org >X-Mailman-Version: 2.1.9 >List-Id: "IETF announcement list. No discussions." >List-Unsubscribe: , > >List-Archive: >List-Post: >List-Help: >List-Subscribe: , > >Sender: ietf-announce-bounces@ietf.org > > for IKEv2) to Proposed Standard >Reply-to: ietf@ietf.org >CC: > >The IESG has received a request from the IP Security Maintenance and >Extensions WG (ipsecme) to consider the following document: > >- 'Redirect Mechanism for IKEv2 ' > 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 2009-06-30. 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-ietf-ipsecme-ikev2-redirect-11.txt > > >IESG discussion can be tracked via >https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17793&rfc_flag=0 > >_______________________________________________ >IETF-Announce mailing list >IETF-Announce@ietf.org >https://www.ietf.org/mailman/listinfo/ietf-announce From glen@amsl.com Tue Jun 16 20:25:08 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E06633A6BC4 for ; Tue, 16 Jun 2009 20:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.648 X-Spam-Level: X-Spam-Status: No, score=-100.648 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, MSGID_MULTIPLE_AT=1.449, NO_RELAYS=-0.001, 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 B-f1IUEhOboh for ; Tue, 16 Jun 2009 20:25:07 -0700 (PDT) Received: from mail.amsl.com (unknown [IPv6:2001:1890:1112:1::14]) by core3.amsl.com (Postfix) with ESMTP id 9D1133A6D5F for ; Tue, 16 Jun 2009 20:25:05 -0700 (PDT) Received: by core2.amsl.com (Postfix, from userid 1000) id 76A27242F3; Tue, 16 Jun 2009 20:25:04 -0700 (PDT) Date: Tue, 16 Jun 2009 20:25:04 -0700 From: Glen To: ipsec@ietf.org Message-ID: <20090617032504.GC6915@glen@amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.16 (2007-06-09) X-Mailman-Approved-At: Tue, 16 Jun 2009 20:25:25 -0700 Subject: [IPsec] Last Call: draft-ietf-ipsecme-ikev2-redirect (Redirect Mechanism X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 03:25:09 -0000 Due to a bug in the IESG Datatracker that was not previously exposed, the following message did not make it to this list. I am forwarding it manually. Please treat this as a Last Call announcement - which it is. Glen Barney IT Director AMS (IETF Secretariat) The IESG has received a request from the IP Security Maintenance and Extensions WG (ipsecme) to consider the following document: - 'Redirect Mechanism for IKEv2 ' 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 at ietf.org mailing lists by 2009-06-30. Exceptionally, comments may be sent to iesg at 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-ietf-ipsecme-ikev2-redirect-11.txt IESG discussion can be tracked via https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17793&rfc_flag=0 From kivinen@iki.fi Wed Jun 17 05:18:25 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B88CF3A6E42 for ; Wed, 17 Jun 2009 05:18:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.516 X-Spam-Level: X-Spam-Status: No, score=-1.516 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166] 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 0ATrYs5Hsf5w for ; Wed, 17 Jun 2009 05:18:25 -0700 (PDT) Received: from mail.kivinen.iki.fi (fireball.acr.fi [83.145.195.1]) by core3.amsl.com (Postfix) with ESMTP id A58533A6C42 for ; Wed, 17 Jun 2009 05:18:24 -0700 (PDT) Received: from fireball.kivinen.iki.fi (localhost [127.0.0.1]) by mail.kivinen.iki.fi (8.14.3/8.13.8) with ESMTP id n5HCIOr3008779 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 17 Jun 2009 15:18:24 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.14.3/8.12.11) id n5HCIO1I021859; Wed, 17 Jun 2009 15:18:24 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <19000.57104.90163.385147@fireball.kivinen.iki.fi> Date: Wed, 17 Jun 2009 15:18:24 +0300 From: Tero Kivinen To: "Srinivasu S R S Dhulipala (srinid)" In-Reply-To: <3A8C969225424C4D8E6BEE65ED8552DA069C9A@XMB-BGL-41C.cisco.com> References: <3A8C969225424C4D8E6BEE65ED8552DA069C9A@XMB-BGL-41C.cisco.com> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 11 min X-Total-Time: 14 min Cc: ipsec@ietf.org Subject: [IPsec] About port floating b/w 4500 and 500 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 12:18:25 -0000 Srinivasu S R S Dhulipala (srinid) writes: > With the above NAT-T and MOBIKE in the context, I've the following > questions: > > 1) Can an IKE peer that migrated to 4500 for some reason migrate back to > 500 later? Is that allowed? If using MOBIKE it is very clear it cannot migrate back, as MOBIKE requires that you always use port 4500 if NAT-T is supported at all. If you do not use MOBIKE then there is no explicit text forbidding that, but I myself at least have interpreted "can float to port 4500" as something that can only happen to one direction, i.e. after you float to 4500, you stay there, there is no way getting back to port 500 with the same IKE SA. If you start new IKE SA then that exchange can start from port 500 (or 4500) and it can float to 4500 or stay at 500 (if started in port 500). > 2) One use case I see is that an IKE initiator who supports MOBIKE does > IKE_SA_INIT > exchange on port 500. According to MOBIKE RFC, it sends message 3 on > port 4500. Let > us assume that the responder does not support MOBIKE. If the responder includes NAT_DETECTION_*_IP payloads in its reply, that means it will support NAT-T, thus initiator is allowed to float to port 4500 (with new IKEv2bis text). Then when during the IKE_AUTH the initiator detects that responder does not support MOBIKE, that does not change anything, the IKE SA has already floated to port 4500, and it will stay there. > Is the responder expected to respond on port 4500? Yes. The RFC has text saying that you always reply back with the port numbers reversed, and as incoming request had port numbers 4500 in it, responder MUST reply from port 4500: ---------------------------------------------------------------------- 2.11. Address and Port Agility ... An implementation MUST accept incoming requests even if the source port is not 500 or 4500, and MUST respond to the address and port from which the request was received. It MUST specify the address and port at which the request was received as the source address and port in the response. ---------------------------------------------------------------------- > 3) Continuing case 2) above, what is the port on which both the peers > are supposed to > communicate afterwards? Port 4500. > Initiator learnt that resonder is not supporting MOBIKE. Is it > expected to contiue on port 4500? Yes. > That is, if one peer migrates to 4500, is it expected to continue on > that port and not migrate back? Yes. -- kivinen@iki.fi From root@core3.amsl.com Wed Jun 17 09:30:02 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 19F933A6E99; Wed, 17 Jun 2009 09:30:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090617163002.19F933A6E99@core3.amsl.com> Date: Wed, 17 Jun 2009 09:30:02 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-ipv6-config-01.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 16:30:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : IPv6 Configuration in IKEv2 Author(s) : P. Eronen, et al. Filename : draft-ietf-ipsecme-ikev2-ipv6-config-01.txt Pages : 33 Date : 2009-06-17 When IKEv2 is used for remote VPN access (client to VPN gateway), the gateway assigns the client an IP address from the internal network using IKEv2 configuration payloads. The configuration payloads specified in RFC 4306 work well for IPv4, but make it difficult to use certain features of IPv6. This document specifies new configuration attributes for IKEv2 that allows the VPN gateway to assign IPv6 prefixes to clients, enabling all features of IPv6 to be used with the client-gateway "virtual link". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-ipv6-config-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-ikev2-ipv6-config-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-06-17091724.I-D@ietf.org> --NextPart-- From vijay@wichorus.com Wed Jun 17 10:46:35 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFD2628C0E6 for ; Wed, 17 Jun 2009 10:46: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=[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 1y7XIU6baWGC for ; Wed, 17 Jun 2009 10:46:34 -0700 (PDT) Received: from outbound.mse15.exchange.ms (outbound.mse15.exchange.ms [216.52.164.185]) by core3.amsl.com (Postfix) with ESMTP id C66D03A6E8D for ; Wed, 17 Jun 2009 10:46:34 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 17 Jun 2009 13:46:19 -0400 Message-ID: In-Reply-To: <20090616181501.A67583A6969@core3.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-11.txt Thread-Index: AcnurqOROjJXSc8QRMmzceFsvcVbEQAxHIRA References: <20090616181501.A67583A6969@core3.amsl.com> From: "Vijay Devarapalli" To: Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-11.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 17:46:35 -0000 Hello, The document was revised to address the comments received from the AD. The diff is at http://tools.ietf.org/wg/ipsecme/draft-ietf-ipsecme-ikev2-redirect/draft -ietf-ipsecme-ikev2-redirect-11-from-10.diff.html The Mobile IPv6-related text, that was in two different sections, has been moved into a separate section.=20 Let me know if anyone has comments on the changes that were made in version 11. Vijay=20 > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]=20 > On Behalf Of Internet-Drafts@ietf.org > Sent: Tuesday, June 16, 2009 11:15 AM > To: i-d-announce@ietf.org > Cc: ipsec@ietf.org > Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-redirect-11.txt >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the IP Security Maintenance and=20 > Extensions Working Group of the IETF. >=20 >=20 > Title : Redirect Mechanism for IKEv2 > Author(s) : V. Devarapalli, K. Weniger > Filename : draft-ietf-ipsecme-ikev2-redirect-11.txt > Pages : 16 > Date : 2009-06-16 >=20 > IKEv2 is a protocol for setting up VPN tunnels from a remote location > to a gateway so that the VPN client can access services in the > network behind the gateway. Currently there is no standard mechanism > specified that allows an overloaded VPN gateway or a VPN gateway that > is being shut down for maintenance to redirect the VPN client to > attach to another gateway. This document proposes a redirect > mechanism for IKEv2. The proposed mechanism can also be used in > Mobile IPv6 to enable the home agent to redirect the mobile node to > another home agent. >=20 > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-r > edirect-11.txt >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. >=20 From Pasi.Eronen@nokia.com Wed Jun 17 11:07:34 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AF1DE3A691D for ; Wed, 17 Jun 2009 11:07:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.564 X-Spam-Level: X-Spam-Status: No, score=-6.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 MWrCuduqT0fx for ; Wed, 17 Jun 2009 11:07:33 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id B57483A6EA5 for ; Wed, 17 Jun 2009 11:07:33 -0700 (PDT) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id n5HI7idl006712; Wed, 17 Jun 2009 13:07:45 -0500 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Jun 2009 21:06:53 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Jun 2009 21:06:47 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.3959); Wed, 17 Jun 2009 21:06:42 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Wed, 17 Jun 2009 20:06:42 +0200 From: To: , Date: Wed, 17 Jun 2009 20:06:40 +0200 Thread-Topic: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-resumption-04.txt Thread-Index: AcnVmMEj2J2LXoVkQamMww7oVGxsbAK9MhFwAF31gbAA9Bv/IAFuVuxQAPlockA= Message-ID: <808FD6E27AD4884E94820BC333B2DB773A6B0FAA4E@NOK-EUMSG-01.mgdnok.nokia.com> References: <20090515163001.6D4AB28C106@core3.amsl.com> <808FD6E27AD4884E94820BC333B2DB773A6AEBC734@NOK-EUMSG-01.mgdnok.nokia.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8DED898E4C7@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB773A6AFA5D01@NOK-EUMSG-01.mgdnok.nokia.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8DED8AF3215@il-ex01.ad.checkpoint.com> In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8DED8AF3215@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 17 Jun 2009 18:06:42.0750 (UTC) FILETIME=[5E8195E0:01C9EF76] X-Nokia-AV: Clean Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-resumption-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 18:07:34 -0000 Yaron Sheffer wrote: > Hi Pasi, >=20 > Sorry for the late reply. >=20 > I believe most people would NOT expect a properly terminated > (deleted) IKE SA to be resumed. To give one example, suppose I > "downsize" a user and revoke his access rights. Today I will simply > terminate (=3Ddelete) all his existing SAs, and then will rely on the > next IKE setup to revalidate the user with the AAA server, which > will correctly fail. Resumption would bypass this check. If you want to make sure the downsized user doesn't come back and bypass the AAA server, you need either ticket-by-reference or some gateway-side state to prevent use of tickets that have been revoked. In either case, it seems the gateway could prevent resumption in cases where the gateway closed the IKE_SA, but still allow it if the client closed the IKE_SA, no? (BTW, in case of ticket-by-value, the gateway doesn't need per-ticket=20 "black list" -- e.g. Eric Rescorla's "stateless tokens" draft suggested=20 using a fixed-size Bloom filter to keep track of tickets that should not be accepted any more.) But it seems regardless of whether we allow resuming a properly closed IKE_SA or not, this is an issue that should be discussed in the Security Considerations section. If most people would expect revoking access rights to work the way you describe, it might=20 come as a surprise that it does not, when using ticket-by-value... > We could add a flag to the 2 notifications for the gateway to signal > to the client that it implements a different semantics, i.e. it is > willing to resume a previously deleted SA. Do you think this use > case is worth the added complexity? It seems we're looking at this from quite different angles -- to me, *not* allowing resumption here is added complexity, since it's=20 more difficult to implement than allowing resumption...? Best regards, Pasi From ynir@checkpoint.com Wed Jun 17 14:06:38 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9ABA53A6801 for ; Wed, 17 Jun 2009 14:06:38 -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 5udPNWAM44hy for ; Wed, 17 Jun 2009 14:06:37 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 4D76A3A67B1 for ; Wed, 17 Jun 2009 14:06:37 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 62CA029C004; Thu, 18 Jun 2009 00:06:55 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 0CBDB29C002; Thu, 18 Jun 2009 00:06:55 +0300 (IDT) X-CheckPoint: {4A3958A3-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n5HL6l3d003831; Thu, 18 Jun 2009 00:06:47 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Thu, 18 Jun 2009 00:06:47 +0300 From: Yoav Nir To: "Pasi.Eronen@nokia.com" , Yaron Sheffer , "ipsec@ietf.org" Date: Thu, 18 Jun 2009 00:06:46 +0300 Thread-Topic: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-resumption-04.txt Thread-Index: AcnVmMEj2J2LXoVkQamMww7oVGxsbAK9MhFwAF31gbAA9Bv/IAFuVuxQAPlockAABlGeXg== Message-ID: <006FEB08D9C6444AB014105C9AEB133F0522CDF765@il-ex01.ad.checkpoint.com> References: <20090515163001.6D4AB28C106@core3.amsl.com> <808FD6E27AD4884E94820BC333B2DB773A6AEBC734@NOK-EUMSG-01.mgdnok.nokia.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8DED898E4C7@il-ex01.ad.checkpoint.com> <808FD6E27AD4884E94820BC333B2DB773A6AFA5D01@NOK-EUMSG-01.mgdnok.nokia.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8DED8AF3215@il-ex01.ad.checkpoint.com>, <808FD6E27AD4884E94820BC333B2DB773A6B0FAA4E@NOK-EUMSG-01.mgdnok.nokia.com> In-Reply-To: <808FD6E27AD4884E94820BC333B2DB773A6B0FAA4E@NOK-EUMSG-01.mgdnok.nokia.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-resumption-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 21:06:38 -0000 I agree with Yaron that it should be the way it is now described in the dra= ft. If either side deleted the IKE SA, then it should not come back to life= through session resumption. Specifically, the client should not get reconn= ected without authentication. The laptop example is excellent. If I close m= y laptop in Tel Aviv, and fly to Stockholm, and some guy from baggage handl= ing gets at my laptop, they should not be able to resume a session to my wo= rkplace. I should need to authenticate again (if I was dilligent enough to = disconnect the session). With a ticket-by-reference scheme, this is easy - the gateway deletes the t= icket from the store when the IKE SA is deleted. With ticket-by-value this = doesn't work. After a crash, the gateway gets presented with a valid ticket= , and has no way of knowing whether the IKE SA associated with that ticket = has or has not been closed. The gateway could keep a blacklist (ticket rev= ocation list?) but that really does add lots of complexity. I think the spec should reduce this to a SHOULD, with an explanation in sec= urity considerations about what it means for ticket-by-value and ticket-by-= reference. ________________________________________ Yaron Sheffer wrote: > Hi Pasi, > > Sorry for the late reply. > > I believe most people would NOT expect a properly terminated > (deleted) IKE SA to be resumed. To give one example, suppose I > "downsize" a user and revoke his access rights. Today I will simply > terminate (=3Ddelete) all his existing SAs, and then will rely on the > next IKE setup to revalidate the user with the AAA server, which > will correctly fail. Resumption would bypass this check. If you want to make sure the downsized user doesn't come back and bypass the AAA server, you need either ticket-by-reference or some gateway-side state to prevent use of tickets that have been revoked. In either case, it seems the gateway could prevent resumption in cases where the gateway closed the IKE_SA, but still allow it if the client closed the IKE_SA, no? (BTW, in case of ticket-by-value, the gateway doesn't need per-ticket "black list" -- e.g. Eric Rescorla's "stateless tokens" draft suggested using a fixed-size Bloom filter to keep track of tickets that should not be accepted any more.) But it seems regardless of whether we allow resuming a properly closed IKE_SA or not, this is an issue that should be discussed in the Security Considerations section. If most people would expect revoking access rights to work the way you describe, it might come as a surprise that it does not, when using ticket-by-value... > We could add a flag to the 2 notifications for the gateway to signal > to the client that it implements a different semantics, i.e. it is > willing to resume a previously deleted SA. Do you think this use > case is worth the added complexity? It seems we're looking at this from quite different angles -- to me, *not* allowing resumption here is added complexity, since it's more difficult to implement than allowing resumption...? Best regards, Pasi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. Email secured by Check Point From ynir@checkpoint.com Wed Jun 17 14:09:06 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 886333A6863 for ; Wed, 17 Jun 2009 14:09:06 -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 WHFUZPH6aZAJ for ; Wed, 17 Jun 2009 14:09:05 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id CAA443A6EC2 for ; Wed, 17 Jun 2009 14:08:52 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 7040C29C004; Thu, 18 Jun 2009 00:09:11 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 2BDFC29C002 for ; Thu, 18 Jun 2009 00:09:11 +0300 (IDT) X-CheckPoint: {4A39592B-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n5HL933d004366 for ; Thu, 18 Jun 2009 00:09:03 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Thu, 18 Jun 2009 00:09:03 +0300 From: Yoav Nir To: "ipsec@ietf.org" Date: Thu, 18 Jun 2009 00:08:02 +0300 Thread-Topic: I-D Action:draft-nir-ike-nochild-02.txt Thread-Index: AcnvjqpMSqbPGPy+R+6h0M7TW02C5gAAQjM6 Message-ID: <006FEB08D9C6444AB014105C9AEB133F0522CDF769@il-ex01.ad.checkpoint.com> References: <20090617210001.9060B3A6C84@core3.amsl.com> In-Reply-To: <20090617210001.9060B3A6C84@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/mixed; boundary="_002_006FEB08D9C6444AB014105C9AEB133F0522CDF769ilex01adcheck_" MIME-Version: 1.0 Subject: [IPsec] FW: I-D Action:draft-nir-ike-nochild-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2009 21:09:06 -0000 --_002_006FEB08D9C6444AB014105C9AEB133F0522CDF769ilex01adcheck_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi all version -02 of this private submission draft, with two additional co-author= s and some more use cases. Enjoy Yoav ________________________________________ From: i-d-announce-bounces@ietf.org [i-d-announce-bounces@ietf.org] On Beha= lf Of Internet-Drafts@ietf.org [Internet-Drafts@ietf.org] Sent: Thursday, June 18, 2009 00:00 To: i-d-announce@ietf.org Subject: I-D Action:draft-nir-ike-nochild-02.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. Title : A Childless Initiation of the IKE SA Author(s) : Y. Nir, et al. Filename : draft-nir-ike-nochild-02.txt Pages : 7 Date : 2009-06-17 This document describes an extension to the IKEv2 protocol that allows an IKE SA to be created and authenticated without generating a child SA. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nir-ike-nochild-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. =0D=0A Email secured by Check Point=0D=0A --_002_006FEB08D9C6444AB014105C9AEB133F0522CDF769ilex01adcheck_ Content-Type: text/plain; name="ATT00001.txt" Content-Description: ATT00001.txt Content-Disposition: attachment; filename="ATT00001.txt"; size=258; creation-date="Thu, 18 Jun 2009 00:00:37 GMT"; modification-date="Thu, 18 Jun 2009 00:00:37 GMT" Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkktRC1Bbm5v dW5jZSBtYWlsaW5nIGxpc3QNCkktRC1Bbm5vdW5jZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9pLWQtYW5ub3VuY2UNCkludGVybmV0LURyYWZ0IGRpcmVj dG9yaWVzOiBodHRwOi8vd3d3LmlldGYub3JnL3NoYWRvdy5odG1sDQpvciBmdHA6Ly9mdHAuaWV0 Zi5vcmcvaWV0Zi8xc2hhZG93LXNpdGVzLnR4dA0K --_002_006FEB08D9C6444AB014105C9AEB133F0522CDF769ilex01adcheck_-- From rsjenwar@gmail.com Wed Jun 17 22:54:04 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A44593A6E4A for ; Wed, 17 Jun 2009 22:54:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.948 X-Spam-Level: X-Spam-Status: No, score=-1.948 tagged_above=-999 required=5 tests=[AWL=0.650, 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 Z-3v05HT1izW for ; Wed, 17 Jun 2009 22:54:03 -0700 (PDT) Received: from mail-pz0-f204.google.com (mail-pz0-f204.google.com [209.85.222.204]) by core3.amsl.com (Postfix) with ESMTP id D07BE3A6E56 for ; Wed, 17 Jun 2009 22:53:57 -0700 (PDT) Received: by pzk42 with SMTP id 42so965601pzk.29 for ; Wed, 17 Jun 2009 22:54:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=RiJom3sj7EFC7fLwgPuFmmFj8KgnyXvpbjrWWPjcDLs=; b=idD/2331ZO+B/gX3ftl69gd+15lRnuCkp7+jdGsXZhPgkb3DQAiaFQve/TYDt3FBYR DQ00x9+NUVCAOxntOJcQrs1/adFHagT3AU7Aa/K89hPoF+/MUhxCs4IJYixefzduC6by Rj2tr0/ohFhzGnqB3l3hgQwexuVhrD5UNwUUU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=oRv1aK1y7V4LRi8rtkUKRuvqPnH73Vp9uv3rTKMothy9m/aOrR/1ltd0STftjBGhzK mlOwMpZ6G+50oMjpWa/9lodHq9wB00S475Wns21MaEfyFOOeTHn8tXDjt8HqsgrEUK4Z xWOKM3XxrAz4XqO7TglwF77sN0hpOOfoqSb14= MIME-Version: 1.0 Received: by 10.143.31.4 with SMTP id i4mr885251wfj.188.1245304447206; Wed, 17 Jun 2009 22:54:07 -0700 (PDT) In-Reply-To: <006FEB08D9C6444AB014105C9AEB133F0522CDF769@il-ex01.ad.checkpoint.com> References: <20090617210001.9060B3A6C84@core3.amsl.com> <006FEB08D9C6444AB014105C9AEB133F0522CDF769@il-ex01.ad.checkpoint.com> Date: Thu, 18 Jun 2009 11:24:07 +0530 Message-ID: <7ccecf670906172254u25f178bdp7f72751432f868bc@mail.gmail.com> From: Raj Singh To: Yoav Nir Content-Type: multipart/alternative; boundary=001636e0b4f1368528046c990960 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] FW: I-D Action:draft-nir-ike-nochild-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 05:54:04 -0000 --001636e0b4f1368528046c990960 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Yoav, Please find my inputs: 1. In section 3: ..... A supporting responder that advertised the VID payload in the IKE_INIT response MUST process a modified IKE_AUTH request, and MUST reply with a modified IKE_AUTH response. Such a responder MUST NOT reply with a modified IKE_AUTH response if the initiator did not send a modified IKE_AUTH request. A supporting responder that has been configured not to support this extension to the protocol MUST behave as the same as if it didn't support this extension. It MUST NOT advertise the capability with a VID payload, and it SHOULD reply with an INVALID_SYNTAX Notify payload if the client sends an IKE_AUTH request that is modified as described in Section 5. .... It does not fully clarifies exactly the behavior of the responder if a faulty initiator send modified IKE_AUTH request without responder sending NO_CHILD in IKE_SA_INIT response ? Shall in that case responder should bring UP the only IKE SA and send modified response or send INVALID_SYNTAX notify and tear down the SA? More clarity needed here. Also we can replace SHOULD to MUST for INVALID_SYNTAX. 2. In whole document, IKE_SA_INIT exchange has been termed as IKE_INIT, change it to IKE_SA_INIT. 3. In section 4, hash string "Can do IKE_AUTH without child SA payloads also" seems to more close to what draft says :-) Thanks & Regards, Raj On Thu, Jun 18, 2009 at 2:38 AM, Yoav Nir wrote: > Hi all > > version -02 of this private submission draft, with two additional > co-authors and some more use cases. > > Enjoy > > Yoav > ________________________________________ > From: i-d-announce-bounces@ietf.org [i-d-announce-bounces@ietf.org] On > Behalf Of Internet-Drafts@ietf.org [Internet-Drafts@ietf.org] > Sent: Thursday, June 18, 2009 00:00 > To: i-d-announce@ietf.org > Subject: I-D Action:draft-nir-ike-nochild-02.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : A Childless Initiation of the IKE SA > Author(s) : Y. Nir, et al. > Filename : draft-nir-ike-nochild-02.txt > Pages : 7 > Date : 2009-06-17 > > This document describes an extension to the IKEv2 protocol that > allows an IKE SA to be created and authenticated without generating a > child SA. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-nir-ike-nochild-02.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > > > > Email secured by Check Point > > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --001636e0b4f1368528046c990960 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Yoav,

Please find my inputs:

1. In section 3:

.....= 
   A supporting responder that advertised the VID payload in the   IKE_INIT response MUST process a modified IKE_AUTH request, and MUST
   reply with a modified IKE_AUTH response.  Such a responder MUST NOT
 =
  reply with a modified IKE_AUTH response if the initiator did not send
=
   a modified IKE_AUTH request.
   A supporting responder that has been =
configured not to support this

   extension to the protocol MUST behave as the same as if it didn't   support this extension.  It MUST NOT advertise the capability with a   VID payload, and it SHOULD reply with an INVALID_SYNTAX Notify
   pa=
yload if the client sends an IKE_AUTH request that is modified as

   described in Section 5.


....

It does not fully clarifi=
es exactly the behavior of the responder if a 
faulty initiator send mod=
ified IKE_AUTH request without responder sending NO_CHILD
in IKE_SA_INIT=
 response ? Shall in that case responder should bring UP the only IKE SA 
and send modified response or send INVALID_SYNTAX notify and tear down the =
SA? More
clarity needed here. Also we can replace SHOULD to MUST for INV=
ALID_SYNTAX.

2. In whole document, IKE_SA_INIT exchange has be= en termed as IKE_INIT, change it to IKE_SA_INIT.

3. In section 4, hash string "Can do IKE_AUTH without child SA pay= loads also" seems to more close to what draft says :-)

Thanks &= amp; Regards,
Raj

On Thu, Jun 18, 2009= at 2:38 AM, Yoav Nir <ynir@checkpoint.com> wrote:
Hi all

version -02 of this private submission draft, with two additional co-author= s and some more use cases.

Enjoy

Yoav
________________________________________
From: i-d-announce-bounces= @ietf.org [i-d-announc= e-bounces@ietf.org] On Behalf Of Internet-Drafts@ietf.org [Internet-Drafts@ietf.org]
Sent: Thursday, June 18, 2009 00:00
To: i-d-announce@ietf.org
Subject: I-D Action:draft-nir-ike-nochild-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.

=C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : A Ch= ildless Initiation of the IKE SA
=C2=A0 =C2=A0 =C2=A0 =C2=A0Author(s) =C2=A0 =C2=A0 =C2=A0 : Y. Nir, et al.=
=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-nir= -ike-nochild-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 7 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2009-06-17

This document describes an extension to the IKEv2 protocol that
allows an IKE SA to be created and authenticated without generating a
child SA.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nir-ike-nochi= ld-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.



Email secured by Check Point


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


--001636e0b4f1368528046c990960-- From rsjenwar@gmail.com Wed Jun 17 23:16:01 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 373603A67BD for ; Wed, 17 Jun 2009 23:16:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433, 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 aTRaWX9vQglJ for ; Wed, 17 Jun 2009 23:16:00 -0700 (PDT) Received: from mail-px0-f171.google.com (mail-px0-f171.google.com [209.85.216.171]) by core3.amsl.com (Postfix) with ESMTP id 1C4F43A6EA8 for ; Wed, 17 Jun 2009 23:15:59 -0700 (PDT) Received: by pxi1 with SMTP id 1so482647pxi.29 for ; Wed, 17 Jun 2009 23:16:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=Ws8qmRRkRiFaRJ7NslcRKH8p3GRcq3hER5TyrgUk0xg=; b=rx+hVk9q2zPB8njYh3mR5X4o7i/ANPxfiSxdijVBep1KpJNChIioDWXn2x1XYjTujK fRzOf6QVozYrdoK74GiVrhg2KnWX5S5wyMJVc8kYKvlffezzPP3CRx3Wh803uhEd+JcY B2JD6Zfj8MW0K3kAEXH7rl9J6WuAB6OZCAnrE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=WsjWoYbPqBhPraNEhjWLM4VilJsKJVj5AAyjl0vIXupcL/UsS+ek0h3Ojrb2Nq4x2f xY3eb4MAjmD2MPDuqc+ZdTyjdqBMioqmgafK9fkALCXKRUyThLVYQG2jSmrk3gvcywyg QQGf7GNQJ+d465pvOTeoouD42pZxJffZLVN6M= MIME-Version: 1.0 Received: by 10.142.44.14 with SMTP id r14mr886212wfr.221.1245305770707; Wed, 17 Jun 2009 23:16:10 -0700 (PDT) In-Reply-To: <7ccecf670906172254u25f178bdp7f72751432f868bc@mail.gmail.com> References: <20090617210001.9060B3A6C84@core3.amsl.com> <006FEB08D9C6444AB014105C9AEB133F0522CDF769@il-ex01.ad.checkpoint.com> <7ccecf670906172254u25f178bdp7f72751432f868bc@mail.gmail.com> Date: Thu, 18 Jun 2009 11:46:10 +0530 Message-ID: <7ccecf670906172316w6e20a474g717c75877e1109c@mail.gmail.com> From: Raj Singh To: Yoav Nir Content-Type: multipart/alternative; boundary=000e0cd15744198bdf046c9958d7 Cc: "ipsec@ietf.org" Subject: Re: [IPsec] FW: I-D Action:draft-nir-ike-nochild-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 06:16:01 -0000 --000e0cd15744198bdf046c9958d7 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Hi Yoav, On Thu, Jun 18, 2009 at 11:24 AM, Raj Singh wrote: > Hi Yoav, > > Please find my inputs: > > 1. In section 3: > > ..... > > A supporting responder that advertised the VID payload in the > IKE_INIT response MUST process a modified IKE_AUTH request, and MUST > > reply with a modified IKE_AUTH response. Such a responder MUST NOT > reply with a modified IKE_AUTH response if the initiator did not send > a modified IKE_AUTH request. > A supporting responder that has been configured not to support this > > extension to the protocol MUST behave as the same as if it didn't > support this extension. It MUST NOT advertise the capability with a > VID payload, and it SHOULD reply with an INVALID_SYNTAX Notify > payload if the client sends an IKE_AUTH request that is modified as > > described in Section 5. > > > .... > > It does not fully clarifies exactly the behavior of the responder if a > faulty initiator send modified IKE_AUTH request without responder sending NO_CHILD > in IKE_SA_INIT response ? Shall in that case responder should bring UP the only IKE SA > > and send modified response or send INVALID_SYNTAX notify and tear down the SA? More > clarity needed here. Also we can replace SHOULD to MUST for INVALID_SYNTAX. > > 2. In whole document, IKE_SA_INIT exchange has been termed as IKE_INIT, > change it to IKE_SA_INIT. > > 3. In section 4, hash string "Can do IKE_AUTH without child SA payloads > also" seems to more close to what draft says :-) Also please make a mention of hashing algorithm for completeness. > > > Thanks & Regards, > Raj > With Regards, Raj > > On Thu, Jun 18, 2009 at 2:38 AM, Yoav Nir wrote: > >> Hi all >> >> version -02 of this private submission draft, with two additional >> co-authors and some more use cases. >> >> Enjoy >> >> Yoav >> ________________________________________ >> From: i-d-announce-bounces@ietf.org [i-d-announce-bounces@ietf.org] On >> Behalf Of Internet-Drafts@ietf.org [Internet-Drafts@ietf.org] >> Sent: Thursday, June 18, 2009 00:00 >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-nir-ike-nochild-02.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : A Childless Initiation of the IKE SA >> Author(s) : Y. Nir, et al. >> Filename : draft-nir-ike-nochild-02.txt >> Pages : 7 >> Date : 2009-06-17 >> >> This document describes an extension to the IKEv2 protocol that >> allows an IKE SA to be created and authenticated without generating a >> child SA. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-nir-ike-nochild-02.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> Below is the data which will enable a MIME compliant mail reader >> implementation to automatically retrieve the ASCII version of the >> Internet-Draft. >> >> >> >> Email secured by Check Point >> >> >> _______________________________________________ >> IPsec mailing list >> IPsec@ietf.org >> https://www.ietf.org/mailman/listinfo/ipsec >> >> > --000e0cd15744198bdf046c9958d7 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Yoav,

On Thu, Jun 18, 2009 at 11:24 AM= , Raj Singh <rsj= enwar@gmail.com> wrote:
Hi Yoav,

Please find my inputs:

1. In section 3:

.....= 
   A supporting responder that advertised the VID payload in the   IKE_INIT response MUST process a modified IKE_AUTH request, and MUST

   reply with a modified IKE_AUTH response.  Such a responder MUST NOT
 =
  reply with a modified IKE_AUTH response if the initiator did not send
=
   a modified IKE_AUTH request.
   A supporting responder that has been =
configured not to support this


   extension to the protocol MUST behave as the same as if it didn't   support this extension.  It MUST NOT advertise the capability with a   VID payload, and it SHOULD reply with an INVALID_SYNTAX Notify

   payload if the client sends an IKE_AUTH request that is modified as

   described in Section 5.


....

It does not fully clarifi=
es exactly the behavior of the responder if a 
faulty initiator send mod=
ified IKE_AUTH request without responder sending NO_CHILD
in IKE_SA_INIT=
 response ? Shall in that case responder should bring UP the only IKE SA 

and send modified response or send INVALID_SYNTAX notify and tear down the =
SA? More
clarity needed here. Also we can replace SHOULD to MUST for INV=
ALID_SYNTAX.

2. In whole document, IKE_SA_INIT exchange has be= en termed as IKE_INIT, change it to IKE_SA_INIT.

3. In section 4, hash string "Can do IKE_AUTH without child SA pay= loads also" seems to more close to what draft says :-)
Also please make a mention of hashing algorithm for completeness.


Tha= nks & Regards,
Raj

With Regards,
Raj

On Thu, Jun 18, 2009 at 2:38 AM, Yoav Nir <ynir@checkp= oint.com> wrote:
<= /div>
Hi all

version -02 of this private submission draft, with two additional co-author= s and some more use cases.

Enjoy

Yoav
________________________________________
From: i-= d-announce-bounces@ietf.org [i-d-announce-bounces@ietf.org] On Behalf Of Internet-Drafts= @ietf.org [Internet-Drafts@ietf.org]
Sent: Thursday, June 18, 2009 00:00
To: i-d-announce= @ietf.org
Subject: I-D Action:draft-nir-ike-nochild-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts director= ies.

=C2=A0 =C2=A0 =C2=A0 =C2=A0Title =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : A Ch= ildless Initiation of the IKE SA
=C2=A0 =C2=A0 =C2=A0 =C2=A0Author(s) =C2=A0 =C2=A0 =C2=A0 : Y. Nir, et al.=
=C2=A0 =C2=A0 =C2=A0 =C2=A0Filename =C2=A0 =C2=A0 =C2=A0 =C2=A0: draft-nir= -ike-nochild-02.txt
=C2=A0 =C2=A0 =C2=A0 =C2=A0Pages =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 : 7 =C2=A0 =C2=A0 =C2=A0 =C2=A0Date =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0:= 2009-06-17

This document describes an extension to the IKEv2 protocol that
allows an IKE SA to be created and authenticated without generating a
child SA.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-nir-ike-nochi= ld-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp= .ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.



Email secured by Check Point


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



--000e0cd15744198bdf046c9958d7-- From yaronf@checkpoint.com Thu Jun 18 08:01:07 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7F83328C35C for ; Thu, 18 Jun 2009 08:01:07 -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=[AWL=-0.000, 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 HWEQPGN45e3a for ; Thu, 18 Jun 2009 08:01:04 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 7110128C329 for ; Thu, 18 Jun 2009 08:01:03 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 4D59429C004; Thu, 18 Jun 2009 18:01:22 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id EC8E729C002 for ; Thu, 18 Jun 2009 18:01:21 +0300 (IDT) X-CheckPoint: {4A3A546C-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n5IF1D3d021025 for ; Thu, 18 Jun 2009 18:01:14 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Thu, 18 Jun 2009 18:01:13 +0300 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Thu, 18 Jun 2009 18:01:11 +0300 Thread-Topic: IPsec-related academic papers Thread-Index: AcnwJZ5Qy3K0mR1mTlaSQ2rSU+Fe7A== Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8E8ABC0D7CA@il-ex01.ad.checkpoint.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0103_01C9F03E.C3A04930" MIME-Version: 1.0 Subject: [IPsec] IPsec-related academic papers X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 15:01:07 -0000 ------=_NextPart_000_0103_01C9F03E.C3A04930 Content-Type: multipart/alternative; boundary="----=_NextPart_001_0104_01C9F03E.C3A04930" ------=_NextPart_001_0104_01C9F03E.C3A04930 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I took an initial stab at getting together a collection of recent academic papers that deal with IKE/IPsec. It is now on the IPsecME wiki . This is at the top of the page: "The list below is by no means exhaustive. It contains papers that are reasonably recent (post-2000) and that we believe may be useful to implementers. It does not contain papers that are primarily of historical value, e.g. much of the protocol work that led to IKEv2." It's a wiki, so feel free to add your favorite papers. Thanks, Yaron ------=_NextPart_001_0104_01C9F03E.C3A04930 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

I took an initial stab at getting together a = collection of recent academic papers that deal with IKE/IPsec. It is now on the I= PsecME wiki.

 

This is at the top of the page: “The list below = is by no means exhaustive. It contains papers that are reasonably recent = (post-2000) and that we believe may be useful to implementers. It does not contain = papers that are primarily of historical value, e.g. much of the protocol work that = led to IKEv2.”

 

It’s a wiki, so feel free to add your favorite = papers.

 

Thanks,

         =    Yaron

------=_NextPart_001_0104_01C9F03E.C3A04930-- ------=_NextPart_000_0103_01C9F03E.C3A04930 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDYxODE1MDExMVowIwYJKoZIhvcNAQkEMRYEFFZtfyBq38sy DMyfX8vyIDv9QKKcMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA Wb50heodiRnUd0Rw5LgSMzlrYWDPFhNWfIqaHqBAPRyEFvlWcbKZndai6lKcZNM6YZVAu1csXfqK evpW9q7XJHb/ls59b6QnRbTa786j1bLLNOgLC9uI2Z72M8yPD+tdxpOefVMX//XFVKa/FIqaxBSI NCJT1GyUVaTr6YtM5UUkHnnCq27UFYgoLgI9GWeF4O1kEn4SxbW1qpU05FEtbbaLHGHzrF/g6Xm9 +BirVnJC/T0Npry7yIJYK8pNS2wgHsr9Kf3oXdpsTrFl2VGNavxSZpSExUAWvd4uOu/HwO/hc+6e q6wc0nEEu88WW6y2+ugohv9yD2jV2WF8aWhZ2AAAAAAAAA== ------=_NextPart_000_0103_01C9F03E.C3A04930-- From root@core3.amsl.com Thu Jun 18 10:15:02 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 1086228C30D; Thu, 18 Jun 2009 10:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090618171502.1086228C30D@core3.amsl.com> Date: Thu, 18 Jun 2009 10:15:02 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-ikev2-resumption-06.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Jun 2009 17:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : IKEv2 Session Resumption Author(s) : Y. Sheffer, H. Tschofenig Filename : draft-ietf-ipsecme-ikev2-resumption-06.txt Pages : 28 Date : 2009-06-18 The Internet Key Exchange version 2 (IKEv2) protocol has a certain computational and communication overhead with respect to the number of round-trips required and the cryptographic operations involved. In remote access situations, the Extensible Authentication Protocol (EAP) is used for authentication, which adds several more round trips and consequently latency. To re-establish security associations (SAs) upon a failure recovery condition is time consuming especially when an IPsec peer (such as a VPN gateway) needs to re-establish a large number of SAs with various end points. A high number of concurrent sessions might cause additional problems for an IPsec peer during SA re-establishment. In order to avoid the need to re-run the key exchange protocol from scratch it would be useful to provide an efficient way to resume an IKE/IPsec session. This document proposes an extension to IKEv2 that allows a client to re-establish an IKE SA with a gateway in a highly efficient manner, utilizing a previously established IKE SA. A client can reconnect to a gateway from which it was disconnected. The proposed approach encodes partial IKE state into an opaque ticket, which can be stored on the client or in a centralized store, and is later made available to the IKEv2 responder for re- authentication. We use the term ticket to refer to the opaque data that is created by the IKEv2 responder. This document does not specify the format of the ticket but examples are provided. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-resumption-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-ikev2-resumption-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-06-18100513.I-D@ietf.org> --NextPart-- From srinid@cisco.com Fri Jun 19 08:38:23 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2BAA3A6A17 for ; Fri, 19 Jun 2009 08:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.515 X-Spam-Level: X-Spam-Status: No, score=-5.515 tagged_above=-999 required=5 tests=[AWL=-1.083, BAYES_00=-2.599, FF_IHOPE_YOU_SINK=2.166, 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 ZIQB7ZkMVfSj for ; Fri, 19 Jun 2009 08:38:22 -0700 (PDT) Received: from syd-iport-1.cisco.com (syd-iport-1.cisco.com [64.104.193.196]) by core3.amsl.com (Postfix) with ESMTP id 76D833A6828 for ; Fri, 19 Jun 2009 08:38:22 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,254,1243814400"; d="scan'208";a="56192787" Received: from hkg-dkim-1.cisco.com ([10.75.231.161]) by syd-iport-1.cisco.com with ESMTP; 19 Jun 2009 15:38:17 +0000 Received: from hkg-core-1.cisco.com (hkg-core-1.cisco.com [64.104.123.94]) by hkg-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5JFcGtn018989; Fri, 19 Jun 2009 23:38:16 +0800 Received: from xbh-bgl-412.cisco.com (xbh-bgl-412.cisco.com [72.163.129.202]) by hkg-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n5JFcGnv020896; Fri, 19 Jun 2009 15:38:16 GMT Received: from xmb-bgl-41c.cisco.com ([72.163.129.218]) by xbh-bgl-412.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 19 Jun 2009 21:08:16 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Jun 2009 21:08:14 +0530 Message-ID: <3A8C969225424C4D8E6BEE65ED8552DA069D82@XMB-BGL-41C.cisco.com> In-Reply-To: <19000.57104.90163.385147@fireball.kivinen.iki.fi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [IPsec] About port floating b/w 4500 and 500 Thread-Index: AcnvRcOyH1iwJU5tQXeTmwfbv0WJMABriS+Q References: <3A8C969225424C4D8E6BEE65ED8552DA069C9A@XMB-BGL-41C.cisco.com> <19000.57104.90163.385147@fireball.kivinen.iki.fi> From: "Srinivasu S R S Dhulipala (srinid)" To: "Tero Kivinen" X-OriginalArrivalTime: 19 Jun 2009 15:38:16.0287 (UTC) FILETIME=[F6AAAEF0:01C9F0F3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2968; t=1245425896; x=1246289896; c=relaxed/simple; s=hkgdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=srinid@cisco.com; z=From:=20=22Srinivasu=20S=20R=20S=20Dhulipala=20(srinid)=22 =20 |Subject:=20RE=3A=20[IPsec]=20About=20port=20floating=20b/w =204500=20and=20500 |Sender:=20; bh=Q6RbyVwmKgJaCm/9As9qDG0rg0nWP3cV34HxaGaIuo4=; b=fbKvk0Qu1w0uXZv/9lpiKj9IvFTRQr4kWDRs6wnIS/nKy5Pmbs1fI2zyXU VTiBISd+SHubFNRk41ZJwJIUa1FfEAGO8WLIKT9aQoZnmNtAeQGDsMPGhd/N LyOszIfz8GXTt6HfOqPeZX75F9XvAgSSrjWhzYvbiHcaR01LdCBxM=; Authentication-Results: hkg-dkim-1; header.From=srinid@cisco.com; dkim=pass ( sig from cisco.com/hkgdkim1002 verified; ); Cc: ipsec@ietf.org Subject: Re: [IPsec] About port floating b/w 4500 and 500 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2009 15:38:24 -0000 Hi Tero, Many thanks for answering all the questions. Regards, Srinivas=20 -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi]=20 Sent: Wednesday, June 17, 2009 5:48 PM To: Srinivasu S R S Dhulipala (srinid) Cc: ipsec@ietf.org Subject: [IPsec] About port floating b/w 4500 and 500 Srinivasu S R S Dhulipala (srinid) writes: > With the above NAT-T and MOBIKE in the context, I've the following > questions: >=20 > 1) Can an IKE peer that migrated to 4500 for some reason migrate back to > 500 later? Is that allowed? If using MOBIKE it is very clear it cannot migrate back, as MOBIKE requires that you always use port 4500 if NAT-T is supported at all. If you do not use MOBIKE then there is no explicit text forbidding that, but I myself at least have interpreted "can float to port 4500" as something that can only happen to one direction, i.e. after you float to 4500, you stay there, there is no way getting back to port 500 with the same IKE SA. If you start new IKE SA then that exchange can start from port 500 (or 4500) and it can float to 4500 or stay at 500 (if started in port 500).=20 > 2) One use case I see is that an IKE initiator who supports MOBIKE=20 > does IKE_SA_INIT > exchange on port 500. According to MOBIKE RFC, it sends message 3=20 > on port 4500. Let > us assume that the responder does not support MOBIKE. If the responder includes NAT_DETECTION_*_IP payloads in its reply, that means it will support NAT-T, thus initiator is allowed to float to port 4500 (with new IKEv2bis text). Then when during the IKE_AUTH the initiator detects that responder does not support MOBIKE, that does not change anything, the IKE SA has already floated to port 4500, and it will stay there.=20 > Is the responder expected to respond on port 4500? Yes. The RFC has text saying that you always reply back with the port numbers reversed, and as incoming request had port numbers 4500 in it, responder MUST reply from port 4500: ---------------------------------------------------------------------- 2.11. Address and Port Agility ... An implementation MUST accept incoming requests even if the source port is not 500 or 4500, and MUST respond to the address and port from which the request was received. It MUST specify the address and port at which the request was received as the source address and port in the response. =20 ---------------------------------------------------------------------- > 3) Continuing case 2) above, what is the port on which both the peers=20 > are supposed to > communicate afterwards? Port 4500. > Initiator learnt that resonder is not supporting MOBIKE. Is it=20 > expected to contiue on port 4500? Yes. > That is, if one peer migrates to 4500, is it expected to continue on=20 > that port and not migrate back? Yes. -- kivinen@iki.fi From paul.hoffman@vpnc.org Sat Jun 20 07:55:25 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFD513A6C35 for ; Sat, 20 Jun 2009 07:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.539 X-Spam-Level: X-Spam-Status: No, score=-2.539 tagged_above=-999 required=5 tests=[AWL=0.060, 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 B-2XvKemU4oE for ; Sat, 20 Jun 2009 07:55:25 -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 A66633A6AB9 for ; Sat, 20 Jun 2009 07:55:24 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5KEtYsO066195 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Sat, 20 Jun 2009 07:55:35 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Sat, 20 Jun 2009 07:55:33 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] Fwd: I-D Action:draft-solinas-rfc4753bis-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 20 Jun 2009 14:55:25 -0000 >A New Internet-Draft is available from the on-line Internet-Drafts directories. > > Title : ECP Groups for IKE and IKEv2 > Author(s) : D. Fu, D. Fulker > Filename : draft-solinas-rfc4753bis-00.txt > Pages : 14 > Date : 2009-06-20 > >This document describes new Elliptic Curve Cryptography (ECC) groups >for use in the Internet Key Exchange (IKE) and Internet Key Exchange >version 2 (IKEv2) protocols in addition to previously defined groups. >Specifically, the new curve groups are based on modular arithmetic >rather than binary arithmetic. These new groups are defined to align >IKE and IKEv2 with other ECC implementations and standards, >particularly NIST standards. In addition, the curves defined here >can provide more efficient implementation than previously defined ECC >groups. > >This version incorporates the erratum for RFC 4753, which changes the >format of the Diffie-Hellman shared secret value. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-solinas-rfc4753bis-00.txt From paul.hoffman@vpnc.org Mon Jun 22 18:55:25 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 304343A6AB3 for ; Mon, 22 Jun 2009 18:55:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 jXJg5XdApRHJ for ; Mon, 22 Jun 2009 18:55:23 -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 440383A6BB8 for ; Mon, 22 Jun 2009 18:55:22 -0700 (PDT) Received: from [10.20.30.158] (dsl-63-249-108-169.static.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5N1tZcj047678 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Mon, 22 Jun 2009 18:55:36 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 22 Jun 2009 18:54:35 -0700 To: IPsecme WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: [IPsec] WG Last Call for IPv6 Configuration in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 01:55:25 -0000 Greetings again. This document has been kicked around a bit, but it is not clear what level of interest there in in the WG. Thus, I am initiating WG Last Call to see: - Do people think it is in good enough shape for the WG to put out as an Experimental (not Standards Track) RFC? - Is there is more interest than from just the document authors? Ideally, it would be good to hear five or more WG participants who are not authors on the document say that they have read it and think it is worthy of being an Experimental RFC. We will consider doing it with fewer people, but such a poor turnout is not a good sign for the value of the document. Please comment on the list. Thanks! --Paul Hoffman Title : IPv6 Configuration in IKEv2 Author(s) : P. Eronen, et al. Filename : draft-ietf-ipsecme-ikev2-ipv6-config-01.txt Pages : 33 Date : 2009-06-17 When IKEv2 is used for remote VPN access (client to VPN gateway), the gateway assigns the client an IP address from the internal network using IKEv2 configuration payloads. The configuration payloads specified in RFC 4306 work well for IPv4, but make it difficult to use certain features of IPv6. This document specifies new configuration attributes for IKEv2 that allows the VPN gateway to assign IPv6 prefixes to clients, enabling all features of IPv6 to be used with the client-gateway "virtual link". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-ipv6-config-01.txt From peng.yang.chn@gmail.com Mon Jun 22 20:06:06 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E0C33A699D for ; Mon, 22 Jun 2009 20:06:06 -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 s0VLZdfeoEA8 for ; Mon, 22 Jun 2009 20:06:05 -0700 (PDT) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by core3.amsl.com (Postfix) with ESMTP id 0FE1C3A6812 for ; Mon, 22 Jun 2009 20:06:04 -0700 (PDT) Received: by gxk10 with SMTP id 10so6107854gxk.13 for ; Mon, 22 Jun 2009 20:06:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=E7FahuIrvy+tW9lozQ70lpyWUQEd+J9U/+lUpsOPnuM=; b=rY927MUwtrIKqjDcVR4FR3S6Zj8eW0VEJE0GZXYXv1wihpZcAAa4ZIBW4/7HZYAt03 FWmQ7O2gWWXeR7Lrd/eY1PCf7XVXZMgI4GSUk6Dad00Rg4odGG/i4eOtE02l3LJRrgtn yZpse2oYftylOoqm9BWPM2DU6oJZVmcF5E6Lw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=vh9eK4e+dG+NRbeBxL+9PYwfebLSZWqHY5jsgjKAcPnnc1CdU6x/u/ZPwDuYY9+BKi Y1mdqAaC8n8Ejij5es1ZHcFmBhsdNOgQYtM0peQfKuN16eW5qfQSe5vCj+M8LHas6P0i TNZTTmmFsffvK0HEglE6f5GxG9GBVnmucXPs0= MIME-Version: 1.0 Received: by 10.90.81.11 with SMTP id e11mr5800897agb.110.1245726378867; Mon, 22 Jun 2009 20:06:18 -0700 (PDT) In-Reply-To: References: <20090515163001.6D4AB28C106@core3.amsl.com> Date: Tue, 23 Jun 2009 11:06:18 +0800 Message-ID: <4c5c7a6d0906222006i8443d60x6d559d7c83a46b6f@mail.gmail.com> From: Peny Yang To: Paul Hoffman Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org Subject: Re: [IPsec] WG Last Call: draft-ietf-ipsecme-ikev2-resumption-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 03:06:06 -0000 Dear all: Sorry for the late comments. I went through the -06 version of IKEv2 session resumption draft. Basically, I agree with more of the content expect for the new IKE_SESSION_RESUME exchange. Well, we've discussed pros and cons of IKE_SA_INIT and IKE_SESSION_RESUME for quite a long time. However, IMHO, the consensus is still not fully achieved on this item. So far, I still prefer to choosing extended IKE_SA_INIT for ticket presenting. This solution can be found in http://tools.ietf.org/html/draft-xu-ike-sa-sync-01 As a summary, the virtues are as follows: 1) RFC5077 (TLS session resumption) also uses the similar scheme, which extends the message of clienthello with session ticket extension. The extended IKE_SA_INIT solution has the similar way. It's easy to extend the base IKEv2 protocol stack to support session resumption. 2) Considering the case of failing session resumption, the extended IKE_SA_INIT solution can save one round trip. 3) As indicated in 4.3.3 IKE_AUTH exchange, IKE_AUTH must be initiated after IKE_SESSION_RESUME. In this sense, the extended IKE_SA_INIT way need less code to be supported compared with IKE_SESSION_RESUME. The down side: 1) some people thought the way of extended IKE_SA_INIT will make the base IKEv2 protocol stack more complex. IMHO, it's implementation specific. Again, I still support to use extended IKE_SA_INIT for ticket presenting instead of IKE_SESSION_RESUME. Thanks BRG Peny On Sat, May 16, 2009 at 4:06 AM, Paul Hoffman wrote: > Greetings again. There has been almost no discussion on the -03 draft, an= d Yaron has made some small changes in the -04. As we discussed at the inte= rim WG meeting, we would like to advance this before Stockholm. > > Therefore, this is the beginning of the two-week WG Last Call, which will= end May 29. The current document is at . > > Even if you have not read the document before now, please do so. Having f= resh eyes on the document often brings up important issues. Send any commen= ts to the list, even if they are as simple as "I read it and it seems fine"= . We would like to gauge how much support there is or isn't for this protoc= ol. > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > From julien.bournelle@gmail.com Tue Jun 23 10:38:23 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4125428C3DD for ; Tue, 23 Jun 2009 10:38:23 -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 CqJRE+E8t0yM for ; Tue, 23 Jun 2009 10:38:22 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id C7CB928C3D5 for ; Tue, 23 Jun 2009 10:38:21 -0700 (PDT) Received: by ewy6 with SMTP id 6so362989ewy.37 for ; Tue, 23 Jun 2009 10:38:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=nP9ciRH/I6eczZa5sMmBDS3IRRWTybIpmNhPSyssul8=; b=DObi/g7+y513CUXLRvYnIsornl49rSapB5k6YXQPZQsxjObElq6QlH6HzzlPXsh4MC UOsymDfAV+PU6TwtCL+fw2hQNwyFXklOi+etADk8D7MaCK6tvZb3uCcegX5vUgyMaJkV waOiXFPQsEa3Juu0RwvfvHyFE/z4Xz5pgdgEs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=NC9VUuDvKqMH8UFfo2AhgrSaSgaicYv0EVQ9UFG5w+6E6+uR8FqTSWaIcREOH1kvLd +f6ix3PJbvGFA/On0KlA9IGmTEDC3ltPLU1Rp/SCe961gG73NWXfxWCq5v0BhRvdyID/ PxlMinFLp0X29TsUyMn5hyr8tT90bbRpXmvDQ= MIME-Version: 1.0 Received: by 10.216.24.141 with SMTP id x13mr103595wex.106.1245778712305; Tue, 23 Jun 2009 10:38:32 -0700 (PDT) In-Reply-To: References: Date: Tue, 23 Jun 2009 19:38:32 +0200 Message-ID: <5e2406980906231038m1a4284d4ydb2cc29cc2f597d9@mail.gmail.com> From: Julien Bournelle To: Paul Hoffman Content-Type: multipart/alternative; boundary=0016e6dbe8899da1dd046d077556 Cc: IPsecme WG Subject: Re: [IPsec] WG Last Call for IPv6 Configuration in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jun 2009 17:38:23 -0000 --0016e6dbe8899da1dd046d077556 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hello, On Tue, Jun 23, 2009 at 3:54 AM, Paul Hoffman wrote: > Greetings again. This document has been kicked around a bit, but it is not > clear what level of interest there in in the WG. Thus, I am initiating WG > Last Call to see: > > - Do people think it is in good enough shape for the WG to put out as an > Experimental (not Standards Track) RFC? Yes. > > - Is there is more interest than from just the document authors? Ideally, > it would be good to hear five or more WG participants who are not authors on > the document say that they have read it and think it is worthy of being an > Experimental RFC. We will consider doing it with fewer people, but such a > poor turnout is not a good sign for the value of the document. Yes, I think that this document is useful considering that it solves some current limitations of IKEv2 for IPv6 deployment for VPN access Regards, Julien. > > > Please comment on the list. Thanks! > > --Paul Hoffman > > Title : IPv6 Configuration in IKEv2 > Author(s) : P. Eronen, et al. > Filename : draft-ietf-ipsecme-ikev2-ipv6-config-01.txt > Pages : 33 > Date : 2009-06-17 > > When IKEv2 is used for remote VPN access (client to VPN gateway), the > gateway assigns the client an IP address from the internal network > using IKEv2 configuration payloads. The configuration payloads > specified in RFC 4306 work well for IPv4, but make it difficult to > use certain features of IPv6. This document specifies new > configuration attributes for IKEv2 that allows the VPN gateway to > assign IPv6 prefixes to clients, enabling all features of IPv6 to be > used with the client-gateway "virtual link". > > A URL for this Internet-Draft is: > > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-ipv6-config-01.txt > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > --0016e6dbe8899da1dd046d077556 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hello,

On Tue, Jun 23, 2009 at 3:54 AM, P= aul Hoffman <= paul.hoffman@vpnc.org> wrote:
Greetings again. This document has been kicked around a bit, but it is not = clear what level of interest there in in the WG. Thus, I am initiating WG L= ast Call to see:

- Do people think it is in good enough shape for the WG to put out as an Ex= perimental (not Standards Track) RFC?

=A0Yes.=A0

- Is there is more interest than from just the document authors? Ideally, i= t would be good to hear five or more WG participants who are not authors on= the document say that they have read it and think it is worthy of being an= Experimental RFC. We will consider doing it with fewer people, but such a = poor turnout is not a good sign for the value of the document.

=A0Yes, I think that this document is useful considering that it s= olves some current limitations of IKEv2 for IPv6 deployment for VPN access<= br>
=A0Regards,

=A0Julien.
=A0


Please comment on the list. Thanks!

--Paul Hoffman

=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : IPv6 Configuration in IKEv2
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : P. Eronen, et al.
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-ipsecme-ikev2-ipv6-con= fig-01.txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 33
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-06-17

When IKEv2 is used for remote VPN access (client to VPN gateway), the
gateway assigns the client an IP address from the internal network
using IKEv2 configuration payloads. =A0The configuration payloads
specified in RFC 4306 work well for IPv4, but make it difficult to
use certain features of IPv6. =A0This document specifies new
configuration attributes for IKEv2 that allows the VPN gateway to
assign IPv6 prefixes to clients, enabling all features of IPv6 to be
used with the client-gateway "virtual link".

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draf= t-ietf-ipsecme-ikev2-ipv6-config-01.txt

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

--0016e6dbe8899da1dd046d077556-- From ynir@checkpoint.com Tue Jun 23 23:53:37 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0374E28C46E for ; Tue, 23 Jun 2009 23:53:37 -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 okQWxK4oIX1i for ; Tue, 23 Jun 2009 23:53:36 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id 7468C28C465 for ; Tue, 23 Jun 2009 23:53:35 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 7221F29C002; Wed, 24 Jun 2009 09:53:14 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 3596B200472; Wed, 24 Jun 2009 09:53:14 +0300 (IDT) X-CheckPoint: {4A41CAB6-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n5O6r43d000078; Wed, 24 Jun 2009 09:53:04 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 24 Jun 2009 09:53:04 +0300 From: Yoav Nir To: "'Paul Hoffman'" , IPsecme WG Date: Wed, 24 Jun 2009 09:53:03 +0300 Thread-Topic: [IPsec] WG Last Call for IPv6 Configuration in IKEv2 Thread-Index: AcnzpbndXMejGAdASseVn5VGpujKnQA8SMYA Message-ID: <006FEB08D9C6444AB014105C9AEB133F433538CDE3@il-ex01.ad.checkpoint.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [IPsec] WG Last Call for IPv6 Configuration in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 06:53:37 -0000 Hi. IMO the CFG payloads are the last place where there will ever be a shortage= of IPv4 addresses. The addresses distributed through CFG payloads in IKEv2= or through extensions to IKEv1 are almost always non-routable addresses, a= nd even for extremely large organizations, there are plenty of those. The time when we'll actually need to distribute IPv6 addresses for this use= , is only when IPv6 has become so ubiquitous, that we're actually trying to= get rid of all kinds of NAT and 4-in-6 solutions, which is not for several= years. I think this accounts for why there has been relatively little int= erest in IPv6 configuration. Having said that, the discussion in the draft shows that the IPv6 configura= tion, as it exists in RFC 4306, is faulty and since it's already there, it = really should be fixed. OTOH we can't expect to see lots of interoperable i= mplementations soon. So I agree that the document is in good enough shape, and interesting enoug= h to be published as Experimental. -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of P= aul Hoffman Sent: Tuesday, June 23, 2009 4:55 AM To: IPsecme WG Subject: [IPsec] WG Last Call for IPv6 Configuration in IKEv2 Greetings again. This document has been kicked around a bit, but it is not = clear what level of interest there in in the WG. Thus, I am initiating WG L= ast Call to see: - Do people think it is in good enough shape for the WG to put out as an Ex= perimental (not Standards Track) RFC? - Is there is more interest than from just the document authors? Ideally, i= t would be good to hear five or more WG participants who are not authors on= the document say that they have read it and think it is worthy of being an= Experimental RFC. We will consider doing it with fewer people, but such a = poor turnout is not a good sign for the value of the document. Please comment on the list. Thanks! --Paul Hoffman Title : IPv6 Configuration in IKEv2 Author(s) : P. Eronen, et al. Filename : draft-ietf-ipsecme-ikev2-ipv6-config-01.txt Pages : 33 Date : 2009-06-17 When IKEv2 is used for remote VPN access (client to VPN gateway), the gateway assigns the client an IP address from the internal network using IKEv2 configuration payloads. The configuration payloads specified in RFC 4306 work well for IPv4, but make it difficult to use certain features of IPv6. This document specifies new configuration attributes for IKEv2 that allows the VPN gateway to assign IPv6 prefixes to clients, enabling all features of IPv6 to be used with the client-gateway "virtual link". A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-ikev2-ipv6-config-01= .txt _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec Scanned by Check Point Total Security Gateway. Email secured by Check Point From root@core3.amsl.com Wed Jun 24 08:45:01 2009 Return-Path: X-Original-To: ipsec@ietf.org Delivered-To: ipsec@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 888063A6CBE; Wed, 24 Jun 2009 08:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090624154501.888063A6CBE@core3.amsl.com> Date: Wed, 24 Jun 2009 08:45:01 -0700 (PDT) Cc: ipsec@ietf.org Subject: [IPsec] I-D Action:draft-ietf-ipsecme-traffic-visibility-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 15:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. Title : Wrapped ESP for Traffic Visibility Author(s) : K. Grewal, et al. Filename : draft-ietf-ipsecme-traffic-visibility-05.txt Pages : 13 Date : 2009-06-24 This document describes the Wrapped Encapsulating Security Payload (WESP) protocol, which builds on top of Encapsulating Security Payload (ESP) [RFC4303] and is designed to allow intermediate devices to ascertain if ESP-NULL [RFC2410] is being employed and hence inspect the IPsec packets for network monitoring and access control functions. Currently in the IPsec standard, there is no way to differentiate between ESP encryption and ESP NULL encryption by simply examining a packet. This poses certain challenges to the intermediate devices that need to deep inspect the packet before making a decision on what should be done with that packet (Inspect and/or Allow/Drop). The mechanism described in this document can be used to easily disambiguate ESP-NULL from ESP encrypted packets, without compromising on the security provided by ESP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-traffic-visibility-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-ipsecme-traffic-visibility-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-06-24084247.I-D@ietf.org> --NextPart-- From paul.hoffman@vpnc.org Wed Jun 24 10:05:13 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ABB2528C4CE for ; Wed, 24 Jun 2009 10:05:13 -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 Z9PYxXNaDAbl for ; Wed, 24 Jun 2009 10:05:12 -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 7FF2728C4CA for ; Wed, 24 Jun 2009 10:05:12 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5OH5O7s014350 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 24 Jun 2009 10:05:24 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20090416140001.4BD833A6B6E@core3.amsl.com> References: <20090416140001.4BD833A6B6E@core3.amsl.com> Date: Wed, 24 Jun 2009 10:05:22 -0700 To: ipsec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-esp-null-heuristics-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 17:05:13 -0000 At 7:00 AM -0700 4/16/09, Internet-Drafts@ietf.org wrote: >A New Internet-Draft is available from the on-line Internet-Drafts directories. >This draft is a work item of the IP Security Maintenance and Extensions Working Group of the IETF. > > > Title : Heuristics for Detecting ESP-NULL packets > Author(s) : T. Kivinen, D. McDonald > Filename : draft-ietf-ipsecme-esp-null-heuristics-00.txt > Pages : 33 > Date : 2009-04-16 > >This document describes a heuristic approach for distinguishing ESP- >NULL (Encapsulating Security Payload without encryption) packets from >encrypted ESP packets. The reason for using heuristics instead of >modifying ESP is to provide a solution that can be used now without >updating all end nodes. With heuristic methods, only the >intermediate devices wanting to find ESP-NULL packets need to be >updated. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-esp-null-heuristics-00.txt > Soooo, that was two months ago, and there has been no discussion. Has anyone other than the document authors (and the WESP authors) read the document? Does the WG find this to be useful? Tero and Dan: have you found anything that you want to change? --Paul Hoffman, Director --VPN Consortium From yaronf@checkpoint.com Wed Jun 24 14:09:44 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 225B63A6C2D for ; Wed, 24 Jun 2009 14:09:44 -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 YrdlgfCeeE-y for ; Wed, 24 Jun 2009 14:09:43 -0700 (PDT) Received: from dlpdemo.checkpoint.com (dlpdemo.checkpoint.com [194.29.32.54]) by core3.amsl.com (Postfix) with ESMTP id AECE63A6D61 for ; Wed, 24 Jun 2009 14:09:32 -0700 (PDT) Received: by dlpdemo.checkpoint.com (Postfix, from userid 105) id 9E45A29C002; Wed, 24 Jun 2009 23:43:45 +0300 (IDT) Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by dlpdemo.checkpoint.com (Postfix) with ESMTP id 4EEFC200384 for ; Wed, 24 Jun 2009 23:43:45 +0300 (IDT) X-CheckPoint: {4A428D55-0-14201DC2-1FFFF} Received: from il-ex01.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id n5OKhZ3d028179 for ; Wed, 24 Jun 2009 23:43:35 +0300 (IDT) Received: from il-ex01.ad.checkpoint.com ([194.29.32.26]) by il-ex01.ad.checkpoint.com ([194.29.32.26]) with mapi; Wed, 24 Jun 2009 23:43:35 +0300 From: Yaron Sheffer To: "ipsec@ietf.org" Date: Wed, 24 Jun 2009 23:43:33 +0300 Thread-Topic: [IPsec] I-D Action:draft-ietf-ipsecme-traffic-visibility-05.txt Thread-Index: Acn04ssJ4/HfMpuWTjy4WlVl1uiQ+QAJsgoQ Message-ID: <7F9A6D26EB51614FBF9F81C0DA4CFEC8E8ABC0DFA9@il-ex01.ad.checkpoint.com> References: <20090624154501.888063A6CBE@core3.amsl.com> In-Reply-To: <20090624154501.888063A6CBE@core3.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0019_01C9F525.95D3F1A0" MIME-Version: 1.0 Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-traffic-visibility-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 21:09:44 -0000 ------=_NextPart_000_0019_01C9F525.95D3F1A0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, we've done a lot of work on this document as a group, and it may well be ready to go through WG Last Call. However it did go through 4 revisions since San Francisco. So before we proceed, I'd like to ask if anybody is seeing showstopper issues with the draft in its current form. In which case we'll need to work on this draft some more before sending it to LC. If there are small issues though, we can defer them to the last call process. Please respond to the list, or to Paul and myself. Thanks, Yaron > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Internet-Drafts@ietf.org > Sent: Wednesday, June 24, 2009 18:45 > To: i-d-announce@ietf.org > Cc: ipsec@ietf.org > Subject: [IPsec] I-D Action:draft-ietf-ipsecme-traffic-visibility-05.txt > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the IP Security Maintenance and Extensions > Working Group of the IETF. > > > Title : Wrapped ESP for Traffic Visibility > Author(s) : K. Grewal, et al. > Filename : draft-ietf-ipsecme-traffic-visibility-05.txt > Pages : 13 > Date : 2009-06-24 > > This document describes the Wrapped Encapsulating Security > Payload (WESP) protocol, which builds on top of Encapsulating > Security Payload (ESP) [RFC4303] and is designed to allow > intermediate devices to ascertain if ESP-NULL [RFC2410] is being > employed and hence inspect the IPsec packets for network > monitoring and access control functions. Currently in the IPsec > standard, there is no way to differentiate between ESP > encryption and ESP NULL encryption by simply examining a packet. > This poses certain challenges to the intermediate devices that > need to deep inspect the packet before making a decision on what > should be done with that packet (Inspect and/or Allow/Drop). The > mechanism described in this document can be used to easily > disambiguate ESP-NULL from ESP encrypted packets, without > compromising on the security provided by ESP. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-traffic-visibility- > 05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. ------=_NextPart_000_0019_01C9F525.95D3F1A0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIPTTCCBDIw ggMaoAMCAQICAQEwDQYJKoZIhvcNAQEFBQAwezELMAkGA1UEBhMCR0IxGzAZBgNVBAgMEkdyZWF0 ZXIgTWFuY2hlc3RlcjEQMA4GA1UEBwwHU2FsZm9yZDEaMBgGA1UECgwRQ29tb2RvIENBIExpbWl0 ZWQxITAfBgNVBAMMGEFBQSBDZXJ0aWZpY2F0ZSBTZXJ2aWNlczAeFw0wNDAxMDEwMDAwMDBaFw0y ODEyMzEyMzU5NTlaMHsxCzAJBgNVBAYTAkdCMRswGQYDVQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIx EDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9kbyBDQSBMaW1pdGVkMSEwHwYDVQQDDBhB QUEgQ2VydGlmaWNhdGUgU2VydmljZXMwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC+ QJ30buHqdoccTUVEjr5GyIMGncEq/hgfjuQC+vOrXVCKFjELmgbQxXAizUktVGPMtm5oRgtT6stM JMC8ck7q8RWu9FSaEgrDerIzYOLaiVXzIljz3tzP74OGooyUT59o8piQRoQnx3a/48w1LIteB2Rl gsBIsKiR+WGfdiBQqJHHZrXreGIDVvCKGhPqMaMeoJn9OPb2JzJYbwf1a7j7FCuvt6rM1mNfc4za BZmoOKjLF3g2UazpnvR4Oo3PD9lC4pgMqy+fDgHe75+ZSfEt36x0TRuYtUfF5SnR+ZAYx2KcvoPH Jns+iiXHwN2d5jVoECCdj9je0sOEnA1e6C/JAgMBAAGjgcAwgb0wHQYDVR0OBBYEFKARCiM+lvEH 7OKvKe+CpX/QMKS0MA4GA1UdDwEB/wQEAwIBBjAPBgNVHRMBAf8EBTADAQH/MHsGA1UdHwR0MHIw OKA2oDSGMmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3Js MDagNKAyhjBodHRwOi8vY3JsLmNvbW9kby5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmww DQYJKoZIhvcNAQEFBQADggEBAAhW/ALwm+j/pPrWe8ZEgM5PxMX2AFjMpra8FEloBHbo5u5d7AIP YNaNUBhPJk4B4+awpe6/vHRUQb/9/BK4x09a9IlgBX9gtwVK8/bxwr/EuXSGti19a8zS80bdL8bg asPDNAMsfZbdWsIOpwqZwQWLqwwv81w6z2w3VQmH3lNAbFjv/LarZW4E9hvcPOBaFcae2fFZSDAh ZQNs7Okhc+ybA6HgN62gFRiP+roCzqcsqRATLNTlCCarIpdg+JBedNSimlO98qlo4KJuwtdssaMP nr/raOdW8q7y4ys4OgmBtWuF174t7T8at7Jj4vViLILUagBBUPE5g5+V6TaWmG4wggTdMIIDxaAD AgECAhBxkvvmGV+sTRKFdHE0ohinMA0GCSqGSIb3DQEBBQUAMHsxCzAJBgNVBAYTAkdCMRswGQYD VQQIDBJHcmVhdGVyIE1hbmNoZXN0ZXIxEDAOBgNVBAcMB1NhbGZvcmQxGjAYBgNVBAoMEUNvbW9k byBDQSBMaW1pdGVkMSEwHwYDVQQDDBhBQUEgQ2VydGlmaWNhdGUgU2VydmljZXMwHhcNMDQwMTAx MDAwMDAwWhcNMjgxMjMxMjM1OTU5WjCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYD VQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYD VQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xp ZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoC ggEBALI5haTyfatBO2JGN67NwWB1vDll+UoaR6K5zEjMapjVTTUZuaRC5c5J4oovHnzSMQfHTrSD ZJ0uKdWiZMSFvYVRNXmkTmiQexx6pJKoF/KYFfKTzMmkMpW7DE8wvZigC4vlbhuiRvp4vKJvq1le pS/Pytptqi/rrKGzaqq3Lmc1i3nhHmmI4uZGzaCl6r4LznY6eg6b6vzaJ1s9cx8i5khhxkzzabGo Lhu21DEgLLyCio6kDqXXiUP8FlqvHXHXEVnauocNr/rz4cLwpMVnjNbWVDreCqS6A3ezZcj9HtN0 YqoYymiTHqGFfvVHZcv4TVcodNI0/zC27vZiMBSMLOsCAwEAAaOCAScwggEjMB8GA1UdIwQYMBaA FKARCiM+lvEH7OKvKe+CpX/QMKS0MB0GA1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNV HQ8BAf8EBAMCAQYwDwYDVR0TAQH/BAUwAwEB/zAdBgNVHSUEFjAUBggrBgEFBQcDAgYIKwYBBQUH AwQwEQYDVR0gBAowCDAGBgRVHSAAMHsGA1UdHwR0MHIwOKA2oDSGMmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL0FBQUNlcnRpZmljYXRlU2VydmljZXMuY3JsMDagNKAyhjBodHRwOi8vY3JsLmNvbW9k by5uZXQvQUFBQ2VydGlmaWNhdGVTZXJ2aWNlcy5jcmwwEQYJYIZIAYb4QgEBBAQDAgEGMA0GCSqG SIb3DQEBBQUAA4IBAQCdlcs8uH6lCcQevwvCx3aOOTyUxhCqTwzJ4KuEXYlU4GU7820cfDcsJVRf liH8N4SRnRXcFE+Bz1Qda2xFYMct+ZdRTPlmyjyggoymyPDi6dRK+ew/VsnddozDggFPbADzHhph dARHA6nGQFeRvGUixSdnT1fbZFrZjR+6hi/0Bq6cae3p9M8pF9jgSp8aIC+XTFG7RgfEijdOIOMJ MWjHnsSLneh+EbwyaBCWEZhE2CpRYE2I63Q630MGMsg5Vow6EVLTQaRDA/Tt7zMn2zngFE4mydj1 OeKJuJNdtykmQeqzm66D/Hd1yujKtf7iZUpjPkTE0MNeh3OpmByvfxV/MIIGMjCCBRqgAwIBAgIR AIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQI EwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0 d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNF UkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwOTEwMDAwMDAwWhcN MDkwOTEwMjM1OTU5WjCB3jE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsgLSBQRVJTT05B IE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9mIHVzZTogaHR0 cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExp bWl0ZWQxFjAUBgNVBAMTDVlhcm9uIFNoZWZmZXIxJDAiBgkqhkiG9w0BCQEWFXlhcm9uZkBjaGVj a3BvaW50LmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALqGr14AEP/lS7OgXTYs 8LjmDZYg3KegpdGXufAXa93NbmAAQ1EmqkVBw8vC/EcYCM+D9uUWeK0uC7BpmCalFDh28AMMIUKI W0VGvDF+kE8zjnch/j7whoWvOvj6yFxYZNe9zfUlZZ7xBc+LEPzqsd4oLbK7a7WkvZAuUHfH0oiH k2miEZkXZF/mhpGp/LplLeA8b51fvQhv8UqIzwRghVTLDCAnIhVk/w+WMmRhcHptYZDa0gOhjyza a/4kG1oHw44Ae9cZpws8TXL+JOrUdmJG6uFY3wB0YvPw9b/u0WeY7Snq0bDF58vDNw0jaQsfIoxx EE+MscA9JbuaPaXIFdkCAwEAAaOCAhcwggITMB8GA1UdIwQYMBaAFImCZ33EnSZwAEu0UEh83j2u BG59MB0GA1UdDgQWBBSNbKhiJVIDkhy5HRA+njy+oWiKMDAOBgNVHQ8BAf8EBAMCBaAwDAYDVR0T AQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQD AgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2Vj dXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2Rv Y2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBI oEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0 aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYqaHR0cDovL2NydC5j b21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC5j b21vZG9jYS5jb20wIAYDVR0RBBkwF4EVeWFyb25mQGNoZWNrcG9pbnQuY29tMA0GCSqGSIb3DQEB BQUAA4IBAQBemghknp7tCcWJ+Pzvopk4bHBaaYF/NJtkrSLXJdOb8p286uOS+7po0DIE+zh9iIyV MTq5GFkleVzIVQHWOIOfCMnxbYh6tgrJUZKdDHMJG2vhz2i2dFOJzWnMnosWmKsDDMpmtLMH1mn+ 31lQkp+rgUAkuFUruAPrG6ms5BVaO/Ta+yBGdEJ0ecLOKuA3zmKnmy8beceXpm4OdkBGWWdLvBGu P/+v8n8KwVf2zzNTaZeEy+139MH9GTrVTiHnOsgdkvvsTu7cAl3mhRxR+o60XU0fQdk3jtbPrzeF uK5fTY6yKlW2e/rlJg3hAr3FkIpszNRgnu+BUDYFg9VnYjjYMYIEaDCCBGQCAQEwgcQwga4xCzAJ BgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoT FVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29t MTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwC EQCAysg33ees11KuGql5QtYmMAkGBSsOAwIaBQCgggJ4MBgGCSqGSIb3DQEJAzELBgkqhkiG9w0B BwEwHAYJKoZIhvcNAQkFMQ8XDTA5MDYyNDIwNDMzM1owIwYJKoZIhvcNAQkEMRYEFHG6nNHOLh83 YzepRyXp/XT/qiVhMGcGCSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCA MA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3 DQIFMIHVBgkrBgEEAYI3EAQxgccwgcQwga4xCzAJBgNVBAYTAlVTMQswCQYDVQQIEwJVVDEXMBUG A1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VSVFJVU1QgTmV0d29yazEhMB8G A1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNs aWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwCEQCAysg33ees11KuGql5QtYmMIHXBgsqhkiG 9w0BCRACCzGBx6CBxDCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0 IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRw Oi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhl bnRpY2F0aW9uIGFuZCBFbWFpbAIRAIDKyDfd56zXUq4aqXlC1iYwDQYJKoZIhvcNAQEBBQAEggEA I9jmG9aKJ49gcWfHcUD9XSax9e7vECel9wgQjpfiLOiEv/HNofHWHdPrIBY/1ZwNHQfUCc3B6lz+ fsCBvaKnsPHCMGQL2BA2NtmUMW/qz6MgvmuQ7ISi9RSIEWE3g+RMW1wNQ3ch+T6NcMlQ3QNSPYxK 5ywAZFCk1uJ+NoeP9tayxhVnNcY71LkP+Te/WoDSVZtqWkq2q2OiOy/Q4r2wzUwZhwt6XGXo30DT Cy1dsipzqhZ5BKH9KtYm+0rmkRUuQ46PY3mKDj17OMNYqZb1j2dEdNc8bixPyLpe+eRphbl4rV9v 8Mzma6dOu1MheXF2AuLJNoYFjqRjAGrJaF3VlgAAAAAAAA== ------=_NextPart_000_0019_01C9F525.95D3F1A0-- From kohn.jack@gmail.com Wed Jun 24 15:56:06 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D99133A6D83 for ; Wed, 24 Jun 2009 15:56:06 -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 gUgzyipzlNgr for ; Wed, 24 Jun 2009 15:56:05 -0700 (PDT) Received: from mail-qy0-f198.google.com (mail-qy0-f198.google.com [209.85.221.198]) by core3.amsl.com (Postfix) with ESMTP id A2B3B3A6C80 for ; Wed, 24 Jun 2009 15:56:05 -0700 (PDT) Received: by qyk36 with SMTP id 36so1544607qyk.29 for ; Wed, 24 Jun 2009 15:55:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=bQeinfl4KzgNSGJPs+huOgBGwYdle0Zhjpr7dW5aA+U=; b=PPtErCQ0o6nJmyJ/Vf4z02TKkpvj5Zrn2GdO0M1Fc1KXkf5Dw7u3MBbK+ghnmT3QCq UZVL/LB0HX0+c1X2pwsl4sfjLLQCDTYBNKfbS9j5q0UKzMVTTxgy66zc0raOgxlOGtU/ IMyJ2KRqK4J5X96fHfHrkGr/n59ao9Suy82Wk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=FGPNTWp1tKSNyeCvS5zmHM7XXVkLescGZXGioroPVztKGIPjG6PbC5Zih/py2WcTzK NyxnPznm3mjROPj3iDb8jXpHXKY5GyQqGKe8M4OyijEZju0F4fBeNmQ74IL3mwmOmbdL D8b3d8xs9s2uElKMCbZn50235PfcEr2BH9jzA= MIME-Version: 1.0 Received: by 10.220.86.149 with SMTP id s21mr1989402vcl.79.1245884142077; Wed, 24 Jun 2009 15:55:42 -0700 (PDT) In-Reply-To: <7F9A6D26EB51614FBF9F81C0DA4CFEC8E8ABC0DFA9@il-ex01.ad.checkpoint.com> References: <20090624154501.888063A6CBE@core3.amsl.com> <7F9A6D26EB51614FBF9F81C0DA4CFEC8E8ABC0DFA9@il-ex01.ad.checkpoint.com> Date: Thu, 25 Jun 2009 04:25:42 +0530 Message-ID: From: Jack Kohn To: Yaron Sheffer Content-Type: multipart/alternative; boundary=0016e6476110b8480c046d2001de Cc: "ipsec@ietf.org" Subject: Re: [IPsec] I-D Action:draft-ietf-ipsecme-traffic-visibility-05.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Jun 2009 22:56:06 -0000 --0016e6476110b8480c046d2001de Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Yaron, I think its ready for the WG LC. Jack On Thu, Jun 25, 2009 at 2:13 AM, Yaron Sheffer wrote: > Hi, > > we've done a lot of work on this document as a group, and it may well be > ready to go through WG Last Call. However it did go through 4 revisions > since San Francisco. So before we proceed, I'd like to ask if anybody is > seeing showstopper issues with the draft in its current form. In which case > we'll need to work on this draft some more before sending it to LC. If > there > are small issues though, we can defer them to the last call process. > > Please respond to the list, or to Paul and myself. > > Thanks, > Yaron > > > -----Original Message----- > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of > > Internet-Drafts@ietf.org > > Sent: Wednesday, June 24, 2009 18:45 > > To: i-d-announce@ietf.org > > Cc: ipsec@ietf.org > > Subject: [IPsec] I-D Action:draft-ietf-ipsecme-traffic-visibility-05.txt > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > This draft is a work item of the IP Security Maintenance and Extensions > > Working Group of the IETF. > > > > > > Title : Wrapped ESP for Traffic Visibility > > Author(s) : K. Grewal, et al. > > Filename : draft-ietf-ipsecme-traffic-visibility-05.txt > > Pages : 13 > > Date : 2009-06-24 > > > > This document describes the Wrapped Encapsulating Security > > Payload (WESP) protocol, which builds on top of Encapsulating > > Security Payload (ESP) [RFC4303] and is designed to allow > > intermediate devices to ascertain if ESP-NULL [RFC2410] is being > > employed and hence inspect the IPsec packets for network > > monitoring and access control functions. Currently in the IPsec > > standard, there is no way to differentiate between ESP > > encryption and ESP NULL encryption by simply examining a packet. > > This poses certain challenges to the intermediate devices that > > need to deep inspect the packet before making a decision on what > > should be done with that packet (Inspect and/or Allow/Drop). The > > mechanism described in this document can be used to easily > > disambiguate ESP-NULL from ESP encrypted packets, without > > compromising on the security provided by ESP. > > > > A URL for this Internet-Draft is: > > > http://www.ietf.org/internet-drafts/draft-ietf-ipsecme-traffic-visibility- > > 05.txt > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > Below is the data which will enable a MIME compliant mail reader > > implementation to automatically retrieve the ASCII version of the > > Internet-Draft. > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec > > --0016e6476110b8480c046d2001de Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yaron,

I think its ready for the WG LC.

Jack

On Thu, Jun 25, 2009 at 2:13 AM, Yaron Sheffer <yaronf@checkpoint.com= > wrote:
Hi,

we've done a lot of work on this document as a group, and it may well b= e
ready to go through WG Last Call. However it did go through 4 revisions
since San Francisco. So before we proceed, I'd like to ask if anybody i= s
seeing showstopper issues with the draft in its current form. In which case=
we'll need to work on this draft some more before sending it to LC. If = there
are small issues though, we can defer them to the last call process.

Please respond to the list, or to Paul and myself.

Thanks,
=A0 =A0 =A0 =A0Yaron

> -----Original Message-----
> From: ipsec-bounces@ietf.org= [mailto:ipsec-bounces@ietf.o= rg] On Behalf Of
> Internet-Drafts@ietf.org
> Sent: Wednesday, June 24, 2009 18:45
> To: i-d-announce@ietf.org=
> Cc: ipsec@ietf.org
> Subject: [IPsec] I-D Action:draft-ietf-ipsecme-traffic-visibility-05.t= xt
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the IP Security Maintenance and Extension= s
> Working Group of the IETF.
>
>
> =A0 =A0 =A0 Title =A0 =A0 =A0 =A0 =A0 : Wrapped ESP for Traffic Visibi= lity
> =A0 =A0 =A0 Author(s) =A0 =A0 =A0 : K. Grewal, et al.
> =A0 =A0 =A0 Filename =A0 =A0 =A0 =A0: draft-ietf-ipsecme-traffic-visib= ility-05.txt
> =A0 =A0 =A0 Pages =A0 =A0 =A0 =A0 =A0 : 13
> =A0 =A0 =A0 Date =A0 =A0 =A0 =A0 =A0 =A0: 2009-06-24
>
> This document describes the Wrapped Encapsulating Security
> Payload (WESP) protocol, which builds on top of Encapsulating
> Security Payload (ESP) [RFC4303] and is designed to allow
> intermediate devices to ascertain if ESP-NULL [RFC2410] is being
> employed and hence inspect the IPsec packets for network
> monitoring and access control functions. =A0Currently in the IPsec
> standard, there is no way to differentiate between ESP
> encryption and ESP NULL encryption by simply examining a packet.
> This poses certain challenges to the intermediate devices that
> need to deep inspect the packet before making a decision on what
> should be done with that packet (Inspect and/or Allow/Drop). The
> mechanism described in this document can be used to easily
> disambiguate ESP-NULL from ESP encrypted packets, without
> compromising on the security provided by ESP.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draf= t-ietf-ipsecme-traffic-visibility-
> 05.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp:= //ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

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


--0016e6476110b8480c046d2001de-- From mohini_kaur@hotmail.com Thu Jun 25 05:38:00 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2B2728C136 for ; Thu, 25 Jun 2009 05:38:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 clZvsJPLnnfq for ; Thu, 25 Jun 2009 05:37:59 -0700 (PDT) Received: from blu0-omc2-s37.blu0.hotmail.com (blu0-omc2-s37.blu0.hotmail.com [65.55.111.112]) by core3.amsl.com (Postfix) with ESMTP id BC32D28C12B for ; Thu, 25 Jun 2009 05:37:59 -0700 (PDT) Received: from BLU104-W9 ([65.55.111.72]) by blu0-omc2-s37.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 25 Jun 2009 05:34:50 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_00103650-bc31-40fd-90d9-f8f4dbf4c370_" X-Originating-IP: [125.22.248.230] From: Mohini Kaur To: Date: Thu, 25 Jun 2009 18:04:49 +0530 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 25 Jun 2009 12:34:50.0201 (UTC) FILETIME=[5501BC90:01C9F591] Subject: [IPsec] IPSec responder cookie X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Jun 2009 12:44:18 -0000 --_00103650-bc31-40fd-90d9-f8f4dbf4c370_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi=2C I have a doubt regarding the value of Responder cookie in ISAKMP protocol. When I read RFC 2408=2C Sec 2.5.3=2C it tells that the initiator and respon= der cookie must be set to a random value.=20 What I understand from this is=2C the responder cookie can have any value d= isregard to the cookie value from initiator. But when I verify this in a Cisco device (initiator)=2C it generates ISAKMP= main mode message with initiator cookie (let it be X). When I send an ISAKMP main mode message=2C with responder cookie same as Cisco device (X) or incrementing it by one (X+1)=2C it is discarding. (However it is processing the message with other values). Again when I do the same in a Linux machine as in Cisco=2C it is discarding the responder cookie with same value (X)=2C however processing responder cookie with value incremented by one (X+1). 1. Could someone explain me why Cisco and Linux validates ISAKMP main mode message with responder cookie differently? And which is the right validation? 2. Is there any other RFCs where I can get more information about validatio= n of ISAKMP main mode message with responder cookie? Thanks in advance. Regards Mohini _________________________________________________________________ Stay updated! Add Facebook=2C LinkedIn=2C MySpace & Hi5 friends to your Wi= ndows Live network instantly. Add Now! http://profile.live.com/webactivities/?mkt=3Den-in= --_00103650-bc31-40fd-90d9-f8f4dbf4c370_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi=2C

I have a doubt regarding the value of Res= ponder cookie in ISAKMP protocol.

When I read R= FC 2408=2C Sec 2.5.3=2C it tells that the initiator and responder cookie mu= st be set to a random value.
What I understand= from this is=2C the responder cookie can have any value disregard to the c= ookie value from initiator.
But when I verify= this in a Cisco device (initiator)=2C it generates ISAKMP main mode messag= e with initiator cookie (let it be X).

When I send an ISAKMP main mode message=2C with responder cookie same as Cisco device (X) or incrementing it by one (X+1)=2C it is discarding. (However it is processing the message with other values).

Again when I do the same in a Linux machine as in Cisco=2C it is discarding the responder cookie with same value (X)=2C however processing responder cookie with value incremented by one (X+1).

1. Could someone explain me why Cisco and Linux validates ISAKMP main mode message with responder cookie differently? And which is the right validation?

2. Is there any other RFCs where I = can get more information about validation of ISAKMP main mode message with = responder cookie?<= br>
Thanks in advance.

Regards
Mohini<= /font>

MSN Battles We pitch one stalwart against the other and give you the po= wer. Who will you vote for? Share photos while you chat with Windows Live Messenger. = --_00103650-bc31-40fd-90d9-f8f4dbf4c370_-- From smoonen@us.ibm.com Fri Jun 26 12:51:39 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6B2783A6C27 for ; Fri, 26 Jun 2009 12:51:39 -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 vsFsjlQs7i+L for ; Fri, 26 Jun 2009 12:51:38 -0700 (PDT) Received: from e33.co.us.ibm.com (e33.co.us.ibm.com [32.97.110.151]) by core3.amsl.com (Postfix) with ESMTP id 710A83A696C for ; Fri, 26 Jun 2009 12:51:38 -0700 (PDT) Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e33.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n5QJnejN025001 for ; Fri, 26 Jun 2009 13:49:40 -0600 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n5QJplO3198986 for ; Fri, 26 Jun 2009 13:51:47 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id n5QJpkfs015835 for ; Fri, 26 Jun 2009 13:51:46 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av04.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id n5QJpkxL015830 for ; Fri, 26 Jun 2009 13:51:46 -0600 To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: 21F0C16F:234B85E1-852575E1:006AB21B; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 06/26/2009 03:42:54 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 06/26/2009 03:42:54 PM, Serialize complete at 06/26/2009 03:42:54 PM, S/MIME Sign failed at 06/26/2009 03:42:55 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 06/26/2009 13:51:46, Serialize complete at 06/26/2009 13:51:46 Message-ID: Date: Fri, 26 Jun 2009 15:51:46 -0400 Content-Type: multipart/alternative; boundary="=_alternative 006C4C95852575E1_=" Subject: [IPsec] ike sa rekey key generation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Jun 2009 19:51:39 -0000 This is a multipart message in MIME format. --=_alternative 006C4C95852575E1_= Content-Type: text/plain; charset="US-ASCII" ikev2bis says the following: SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as specified in Section 2.14. Is it correct to assume that SPIi and SPIr as used in this rekey calculation are from the new, rekeyed IKE SA? Is it worth specifying that explicitly? Ni/Nr is more obvious, since those are explicitly exchanged with the CREATE_CHILD_SA rekey exchange. But the rekey exchange has two associated SPIs (the old SA's SPIs for the messages themselves, and the SPIs within the SA proposals), and it might be helpful to clarify this. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen --=_alternative 006C4C95852575E1_= Content-Type: text/html; charset="US-ASCII"
ikev2bis says the following:

   SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as
   specified in Section 2.14.

Is it correct to assume that SPIi and SPIr as used in this rekey calculation are from the new, rekeyed IKE SA?  Is it worth specifying that explicitly?  Ni/Nr is more obvious, since those are explicitly exchanged with the CREATE_CHILD_SA rekey exchange.  But the rekey exchange has two associated SPIs (the old SA's SPIs for the messages themselves, and the SPIs within the SA proposals), and it might be helpful to clarify this.


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen --=_alternative 006C4C95852575E1_=-- From smoonen@us.ibm.com Mon Jun 29 09:30:14 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2B5B28C0DF for ; Mon, 29 Jun 2009 09:30:14 -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 SqCW3fjEGlIs for ; Mon, 29 Jun 2009 09:30:13 -0700 (PDT) Received: from e38.co.us.ibm.com (e38.co.us.ibm.com [32.97.110.159]) by core3.amsl.com (Postfix) with ESMTP id 840293A6B9E for ; Mon, 29 Jun 2009 09:30:13 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e38.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n5TGRI2S005316 for ; Mon, 29 Jun 2009 10:27:18 -0600 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n5TGUJL0122238 for ; Mon, 29 Jun 2009 10:30:21 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.13.1/8.13.3) with ESMTP id n5TGV1xs011531 for ; Mon, 29 Jun 2009 10:31:01 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av06.boulder.ibm.com (8.13.1/8.12.11) with ESMTP id n5TGV1o7011528 for ; Mon, 29 Jun 2009 10:31:01 -0600 To: ipsec@ietf.org MIME-Version: 1.0 X-KeepSent: C59218B3:D7FCE0DB-852575E4:00549FEF; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 06/29/2009 12:29:58 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 06/29/2009 12:29:58 PM, Serialize complete at 06/29/2009 12:29:58 PM, S/MIME Sign failed at 06/29/2009 12:29:58 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 06/29/2009 10:30:18, Serialize complete at 06/29/2009 10:30:18 Message-ID: Date: Mon, 29 Jun 2009 12:30:18 -0400 Content-Type: multipart/alternative; boundary="=_alternative 005AA28E852575E4_=" Subject: [IPsec] guidelines for choice of D-H group X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 16:30:15 -0000 This is a multipart message in MIME format. --=_alternative 005AA28E852575E4_= Content-Type: text/plain; charset="US-ASCII" RFCs 4753 and 5114 provide vague recommendations for choice of Diffie-Hellman group relative to symmetric key sizes. They don't specifically address how to look at a set of chosen SA encryption and authentication algorithms and arrive at a choice of suitable Diffie-Hellman group, nor do they address the use of PFS. So: 1) For the IKE SA, the Diffie-Hellman operation generates two encryption and two authentication keys. Should the Diffie-Hellman strength generally be equivalent to the longest key length, or to the sum of the key lengths? If we sum up all four symmetric key lengths, most choices will exceed the strength provided by the currently available Diffie-Hellman groups. But if we don't sum up the symmetric key lengths, then we are making Diffie-Hellman the weakest link in the chain (i.e., we aren't obtaining significant added value by generating different values for each of SK_ei, SK_er, SK_ai, SK_ar). Which is the case? 1b) In any case, we don't have suitable Diffie-Hellman groups for use with HMAC-SHA2-384 and HMAC-SHA2-512. Interestingly, the upcoming NIST and DoD standards push into the realm of 256-bit symmetric algorithms (HMAC-SHA2-256) with SHOULD+ or MUST, but for Diffie-Hellman only into the realm of 112 bits (NIST makes group 24 a MUST) or 128 bits (DoD makes group 19 a MUST). Do the folks from DoD or NIST have any comments on this disparity? 2) If we are recommending parity between symmetric algorithms and DH group choice, is there any place that we are also recommending the use of perfect forward secrecy to guard against weaknesses there? Not using perfect forward secrecy goes even further to make the Diffie-Hellman the weakest link in the chain. And yet RFC 4308 does not require PFS, and NIST's own RFC 4869 doesn't even mention it. Do the folks from NIST have any comments on why PFS is not mandated, let alone mentioned, in RFC 4869? 3) IKEv2 does not allow perfect forward secrecy for the first child SA. Similar to question 1 above, how does that play into the recommendation for DH group size to choose? Admittedly, there probably isn't much lost if the IKE SA keys are compromised. So should we look only at the child SA symmetric key sizes when considering what IKE SA DH group is appropriate? Or should we sum up the IKE and child SA symmetric key lengths? Thanks, Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen --=_alternative 005AA28E852575E4_= Content-Type: text/html; charset="US-ASCII"
RFCs 4753 and 5114 provide vague recommendations for choice of Diffie-Hellman group relative to symmetric key sizes.  They don't specifically address how to look at a set of chosen SA encryption and authentication algorithms and arrive at a choice of suitable Diffie-Hellman group, nor do they address the use of PFS.  So:

1) For the IKE SA, the Diffie-Hellman operation generates two encryption and two authentication keys.  Should the Diffie-Hellman strength generally be equivalent to the longest key length, or to the sum of the key lengths?  If we sum up all four symmetric key lengths, most choices will exceed the strength provided by the currently available Diffie-Hellman groups.  But if we don't sum up the symmetric key lengths, then we are making Diffie-Hellman the weakest link in the chain (i.e., we aren't obtaining significant added value by generating different values for each of SK_ei, SK_er, SK_ai, SK_ar).  Which is the case?

1b) In any case, we don't have suitable Diffie-Hellman groups for use with HMAC-SHA2-384 and HMAC-SHA2-512.  Interestingly, the upcoming NIST and DoD standards push into the realm of 256-bit symmetric algorithms (HMAC-SHA2-256) with SHOULD+ or MUST, but for Diffie-Hellman only into the realm of 112 bits (NIST makes group 24 a MUST) or 128 bits (DoD makes group 19 a MUST).  Do the folks from DoD or NIST have any comments on this disparity?

2) If we are recommending parity between symmetric algorithms and DH group choice, is there any place that we are also recommending the use of perfect forward secrecy to guard against weaknesses there?  Not using perfect forward secrecy goes even further to make the Diffie-Hellman the weakest link in the chain.  And yet RFC 4308 does not require PFS, and NIST's own RFC 4869 doesn't even mention it.  Do the folks from NIST have any comments on why PFS is not mandated, let alone mentioned, in RFC 4869?

3) IKEv2 does not allow perfect forward secrecy for the first child SA.  Similar to question 1 above, how does that play into the recommendation for DH group size to choose?  Admittedly, there probably isn't much lost if the IKE SA keys are compromised.  So should we look only at the child SA symmetric key sizes when considering what IKE SA DH group is appropriate?  Or should we sum up the IKE and child SA symmetric key lengths?

Thanks,


Scott Moonen (smoonen@us.ibm.com)
z/OS Communications Server TCP/IP Development
http://scott.andstuff.org/
http://www.linkedin.com/in/smoonen --=_alternative 005AA28E852575E4_=-- From sfluhrer@cisco.com Mon Jun 29 10:01:16 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CCC628C2C4 for ; Mon, 29 Jun 2009 10:01:16 -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 HWjKv-UT6w0L for ; Mon, 29 Jun 2009 10:01:14 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id DA2CB3A6BCF for ; Mon, 29 Jun 2009 10:01:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,310,1243814400"; d="scan'208,217";a="173583990" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 29 Jun 2009 17:01:06 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n5TH14iP029596; Mon, 29 Jun 2009 10:01:04 -0700 Received: from sfluhrerwxp (stealth-10-32-244-82.cisco.com [10.32.244.82]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n5TH13sm016211; Mon, 29 Jun 2009 17:01:04 GMT From: "Scott Fluhrer" To: "'Scott C Moonen'" , References: Date: Mon, 29 Jun 2009 13:01:03 -0400 Message-ID: <061a01c9f8db$3011d0d0$52f4200a@amer.cisco.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_061B_01C9F8B9.A90030D0" X-Mailer: Microsoft Office Outlook 11 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 Thread-Index: Acn411OKjIGHhqsFQoW6IE5ySitKtwAAVvRQ DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10965; t=1246294864; x=1247158864; c=relaxed/simple; s=sjdkim1004; 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]=20guidelines=20for=20choice=20o f=20D-H=20group |Sender:=20; bh=LJyxk/GHcF3QZ3pJPS6vZN0tYMdCSNHcn9jWO+7IApg=; b=HwxOozdkU0v77oKIcoBlXY5En4BGrVSXD60SmqRwZehL5Odc0GBesVHaea H5WGuYqT2UeDjECzBuQUmSF5eooFQ7n9LgO84k8q34eZI/1GxBk/NqKKs3S3 UlwJ6ivMO2TSt6zOTePtpFOdZL539/B22kKzNzMQ9bWXzZuau9ZHg=; Authentication-Results: sj-dkim-1; header.From=sfluhrer@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [IPsec] guidelines for choice of D-H group X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 17:01:16 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_061B_01C9F8B9.A90030D0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit _____ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Scott C Moonen Sent: Monday, June 29, 2009 12:30 PM To: ipsec@ietf.org Subject: [IPsec] guidelines for choice of D-H group RFCs 4753 and 5114 provide vague recommendations for choice of Diffie-Hellman group relative to symmetric key sizes. They don't specifically address how to look at a set of chosen SA encryption and authentication algorithms and arrive at a choice of suitable Diffie-Hellman group, nor do they address the use of PFS. So: 1) For the IKE SA, the Diffie-Hellman operation generates two encryption and two authentication keys. Should the Diffie-Hellman strength generally be equivalent to the longest key length, or to the sum of the key lengths? If we sum up all four symmetric key lengths, most choices will exceed the strength provided by the currently available Diffie-Hellman groups. But if we don't sum up the symmetric key lengths, then we are making Diffie-Hellman the weakest link in the chain (i.e., we aren't obtaining significant added value by generating different values for each of SK_ei, SK_er, SK_ai, SK_ar). Which is the case? It's pointless to make it much stronger than the longest key, as each individual symmetric key can be attacked separately. For example, suppose that SK_ei was an 128 bit AES key; the attacker could recover that key by finding a packet encrypted with that key, and do a trial decrypt based on successive keys, and stop when he finds a key that makes a plausible plaintext. The important point is that he can do this without knowing what the other keys SK_er, SK_ai, SK_ar are, and so those other keys don't add to the security in this specific attack. More generally, suppose the attacker is able to recover SK_ei with effort A (for example, if AES-128 is being used, and we're using brute force to recover the key, then A=2**127 decrypt operations expected), and similarly SK_er, SK_ai, SK_ar can be recovered with efforts B, C, D, then the time taken to recover all four is A+B+C+D, which is no more than 4 times the largest of the four (and this is assuming that the attacker is actually interested in all four, which is generally not the case). 1b) In any case, we don't have suitable Diffie-Hellman groups for use with HMAC-SHA2-384 and HMAC-SHA2-512. Interestingly, the upcoming NIST and DoD standards push into the realm of 256-bit symmetric algorithms (HMAC-SHA2-256) with SHOULD+ or MUST, but for Diffie-Hellman only into the realm of 112 bits (NIST makes group 24 a MUST) or 128 bits (DoD makes group 19 a MUST). Do the folks from DoD or NIST have any comments on this disparity? 2) If we are recommending parity between symmetric algorithms and DH group choice, is there any place that we are also recommending the use of perfect forward secrecy to guard against weaknesses there? Not using perfect forward secrecy goes even further to make the Diffie-Hellman the weakest link in the chain. And yet RFC 4308 does not require PFS, and NIST's own RFC 4869 doesn't even mention it. Do the folks from NIST have any comments on why PFS is not mandated, let alone mentioned, in RFC 4869? 3) IKEv2 does not allow perfect forward secrecy for the first child SA. Similar to question 1 above, how does that play into the recommendation for DH group size to choose? Admittedly, there probably isn't much lost if the IKE SA keys are compromised. So should we look only at the child SA symmetric key sizes when considering what IKE SA DH group is appropriate? Or should we sum up the IKE and child SA symmetric key lengths? Same answer to the last question: the IKE and the IPSec SA keys can be attacked separately, and so making the DH stronger than the longest individual key doesn't gain you anything from a security standpoint. -- scott ------=_NextPart_000_061B_01C9F8B9.A90030D0 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 Scott C=20 Moonen
Sent: Monday, June 29, 2009 12:30 PM
To:=20 ipsec@ietf.org
Subject: [IPsec] guidelines for choice of D-H = group


RFCs 4753 and 5114 provide = vague=20 recommendations for choice of Diffie-Hellman group relative to = symmetric key=20 sizes.  They don't specifically address how to look at a set of = chosen SA=20 encryption and authentication algorithms and arrive at a choice of = suitable=20 Diffie-Hellman group, nor do they address the use of PFS. =  So:=20

1) For the IKE SA, the = Diffie-Hellman=20 operation generates two encryption and two authentication keys. =  Should=20 the Diffie-Hellman strength generally be equivalent to the longest key = length,=20 or to the sum of the key lengths?  If we sum up all four = symmetric key=20 lengths, most choices will exceed the strength provided by the = currently=20 available Diffie-Hellman groups.  But if we don't sum up the = symmetric=20 key lengths, then we are making Diffie-Hellman the weakest link in the = chain=20 (i.e., we aren't obtaining significant added value by generating = different=20 values for each of SK_ei, SK_er, SK_ai, SK_ar).  Which is the = case? 
It's pointless=20 to make it much stronger than the longest key, as each individual = symmetric key=20 can be attacked separately.
 
For example,=20 suppose that SK_ei was an 128 bit AES key; the attacker could recover = that key=20 by finding a packet encrypted with that key, and do a trial decrypt = based on=20 successive keys, and stop when he finds a key that makes a plausible=20 plaintext.  The important point is that he can do this without = knowing what=20 the other keys SK_er, SK_ai, SK_ar are, and so those other keys don't = add to the=20 security in this specific attack.
 
More=20 generally, suppose the attacker is able to recover SK_ei with effort A = (for=20 example, if AES-128 is being used, and we're using brute force to = recover=20 the key, then A=3D2**127 decrypt operations expected), and = similarly SK_er,=20 SK_ai, SK_ar can be recovered with efforts B, C, D, then the time taken = to=20 recover all four is A+B+C+D, which is no more than 4 times the = largest of=20 the four (and this is assuming that the attacker is actually interested = in all=20 four, which is generally not the case).
 

1b) In any case, we don't have suitable = Diffie-Hellman=20 groups for use with HMAC-SHA2-384 and HMAC-SHA2-512. =  Interestingly, the=20 upcoming NIST and DoD standards push into the realm of 256-bit = symmetric=20 algorithms (HMAC-SHA2-256) with SHOULD+ or MUST, but for = Diffie-Hellman only=20 into the realm of 112 bits (NIST makes group 24 a MUST) or 128 bits = (DoD makes=20 group 19 a MUST).  Do the folks from DoD or NIST have any = comments on=20 this disparity?

2) If = we are=20 recommending parity between symmetric algorithms and DH group choice, = is there=20 any place that we are also recommending the use of perfect forward = secrecy to=20 guard against weaknesses there?  Not using perfect forward = secrecy goes=20 even further to make the Diffie-Hellman the weakest link in the chain. =  And yet RFC 4308 does not require PFS, and NIST's own RFC 4869 = doesn't=20 even mention it.  Do the folks from NIST have any comments on why = PFS is=20 not mandated, let alone mentioned, in RFC 4869?

3) IKEv2 does not allow perfect forward = secrecy for the=20 first child SA.  Similar to question 1 above, how does that play = into the=20 recommendation for DH group size to choose?  Admittedly, there = probably=20 isn't much lost if the IKE SA keys are compromised.  So should we = look=20 only at the child SA symmetric key sizes when considering what IKE SA = DH group=20 is appropriate?  Or should we sum up the IKE and child SA = symmetric key=20 lengths?  
Same = answer to the=20 last question: the IKE and the IPSec SA keys can be attacked separately, = and so=20 making the DH stronger than the longest individual key doesn't gain you = anything=20 from a security standpoint.
 
--=20
scott
 
------=_NextPart_000_061B_01C9F8B9.A90030D0-- From smoonen@us.ibm.com Mon Jun 29 13:09:36 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A4A8E3A68ED for ; Mon, 29 Jun 2009 13:09:36 -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 LXCAdTfawsQx for ; Mon, 29 Jun 2009 13:09:35 -0700 (PDT) Received: from e36.co.us.ibm.com (e36.co.us.ibm.com [32.97.110.154]) by core3.amsl.com (Postfix) with ESMTP id 050E63A67AA for ; Mon, 29 Jun 2009 13:09:34 -0700 (PDT) Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e36.co.us.ibm.com (8.13.1/8.13.1) with ESMTP id n5TJ7WEi008270 for ; Mon, 29 Jun 2009 13:07:32 -0600 Received: from d03av06.boulder.ibm.com (d03av06.boulder.ibm.com [9.17.195.245]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.2) with ESMTP id n5TJ91H5263510 for ; Mon, 29 Jun 2009 13:09:01 -0600 Received: from d03av06.boulder.ibm.com (loopback [127.0.0.1]) by d03av06.boulder.ibm.com (8.13.1/8.13.3) with ESMTP id n5TJ9i4I001073 for ; Mon, 29 Jun 2009 13:09:44 -0600 Received: from d03nm118.boulder.ibm.com (d03nm118.boulder.ibm.com [9.17.195.144]) by d03av06.boulder.ibm.com (8.13.1/8.12.11) with ESMTP id n5TJ9iDY001070; Mon, 29 Jun 2009 13:09:44 -0600 In-Reply-To: <061a01c9f8db$3011d0d0$52f4200a@amer.cisco.com> References: <061a01c9f8db$3011d0d0$52f4200a@amer.cisco.com> To: "Scott Fluhrer" MIME-Version: 1.0 X-KeepSent: F2271134:08DE197B-852575E4:00686F91; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2 HF623 January 16, 2009 From: Scott C Moonen X-MIMETrack: S/MIME Sign by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 06/29/2009 03:05:33 PM, Serialize by Notes Client on Scott C Moonen/Raleigh/IBM(Release 8.0.2 HF623|January 16, 2009) at 06/29/2009 03:05:33 PM, Serialize complete at 06/29/2009 03:05:33 PM, S/MIME Sign failed at 06/29/2009 03:05:33 PM: The cryptographic key was not found, Serialize by Router on D03NM118/03/M/IBM(Release 8.5|December 05, 2008) at 06/29/2009 13:09:00, Serialize complete at 06/29/2009 13:09:00 Message-ID: Date: Mon, 29 Jun 2009 15:09:00 -0400 Content-Type: multipart/alternative; boundary="=_alternative 0068E0F8852575E4_=" Cc: ipsec@ietf.org Subject: Re: [IPsec] guidelines for choice of D-H group X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 20:09:36 -0000 This is a multipart message in MIME format. --=_alternative 0068E0F8852575E4_= Content-Type: text/plain; charset="US-ASCII" Scott, thank you. How dense of me! Doubling the work effort is equivalent to adding one bit to the effective strength, not doubling the number of bits. Scott Moonen (smoonen@us.ibm.com) z/OS Communications Server TCP/IP Development http://scott.andstuff.org/ http://www.linkedin.com/in/smoonen From: "Scott Fluhrer" To: Scott C Moonen/Raleigh/IBM@IBMUS, Date: 06/29/2009 01:01 PM Subject: RE: [IPsec] guidelines for choice of D-H group From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Scott C Moonen Sent: Monday, June 29, 2009 12:30 PM To: ipsec@ietf.org Subject: [IPsec] guidelines for choice of D-H group RFCs 4753 and 5114 provide vague recommendations for choice of Diffie-Hellman group relative to symmetric key sizes. They don't specifically address how to look at a set of chosen SA encryption and authentication algorithms and arrive at a choice of suitable Diffie-Hellman group, nor do they address the use of PFS. So: 1) For the IKE SA, the Diffie-Hellman operation generates two encryption and two authentication keys. Should the Diffie-Hellman strength generally be equivalent to the longest key length, or to the sum of the key lengths? If we sum up all four symmetric key lengths, most choices will exceed the strength provided by the currently available Diffie-Hellman groups. But if we don't sum up the symmetric key lengths, then we are making Diffie-Hellman the weakest link in the chain (i.e., we aren't obtaining significant added value by generating different values for each of SK_ei, SK_er, SK_ai, SK_ar). Which is the case? It's pointless to make it much stronger than the longest key, as each individual symmetric key can be attacked separately. For example, suppose that SK_ei was an 128 bit AES key; the attacker could recover that key by finding a packet encrypted with that key, and do a trial decrypt based on successive keys, and stop when he finds a key that makes a plausible plaintext. The important point is that he can do this without knowing what the other keys SK_er, SK_ai, SK_ar are, and so those other keys don't add to the security in this specific attack. More generally, suppose the attacker is able to recover SK_ei with effort A (for example, if AES-128 is being used, and we're using brute force to recover the key, then A=2**127 decrypt operations expected), and similarly SK_er, SK_ai, SK_ar can be recovered with efforts B, C, D, then the time taken to recover all four is A+B+C+D, which is no more than 4 times the largest of the four (and this is assuming that the attacker is actually interested in all four, which is generally not the case). 1b) In any case, we don't have suitable Diffie-Hellman groups for use with HMAC-SHA2-384 and HMAC-SHA2-512. Interestingly, the upcoming NIST and DoD standards push into the realm of 256-bit symmetric algorithms (HMAC-SHA2-256) with SHOULD+ or MUST, but for Diffie-Hellman only into the realm of 112 bits (NIST makes group 24 a MUST) or 128 bits (DoD makes group 19 a MUST). Do the folks from DoD or NIST have any comments on this disparity? 2) If we are recommending parity between symmetric algorithms and DH group choice, is there any place that we are also recommending the use of perfect forward secrecy to guard against weaknesses there? Not using perfect forward secrecy goes even further to make the Diffie-Hellman the weakest link in the chain. And yet RFC 4308 does not require PFS, and NIST's own RFC 4869 doesn't even mention it. Do the folks from NIST have any comments on why PFS is not mandated, let alone mentioned, in RFC 4869? 3) IKEv2 does not allow perfect forward secrecy for the first child SA. Similar to question 1 above, how does that play into the recommendation for DH group size to choose? Admittedly, there probably isn't much lost if the IKE SA keys are compromised. So should we look only at the child SA symmetric key sizes when considering what IKE SA DH group is appropriate? Or should we sum up the IKE and child SA symmetric key lengths? Same answer to the last question: the IKE and the IPSec SA keys can be attacked separately, and so making the DH stronger than the longest individual key doesn't gain you anything from a security standpoint. -- scott --=_alternative 0068E0F8852575E4_= Content-Type: text/html; charset="US-ASCII"
Scott, thank you.  How dense of me!  Doubling the work effort is equivalent to adding one bit to the effective strength, not doubling the number of bits.


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


From: "Scott Fluhrer" <sfluhrer@cisco.com>
To: Scott C Moonen/Raleigh/IBM@IBMUS, <ipsec@ietf.org>
Date: 06/29/2009 01:01 PM
Subject: RE: [IPsec] guidelines for choice of D-H group




 

From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Scott C Moonen
Sent: Monday, June 29, 2009 12:30 PM
To: ipsec@ietf.org
Subject: [IPsec] guidelines for choice of D-H group

RFCs 4753 and 5114 provide vague recommendations for choice of Diffie-Hellman group relative to symmetric key sizes.  They don't specifically address how to look at a set of chosen SA encryption and authentication algorithms and arrive at a choice of suitable Diffie-Hellman group, nor do they address the use of PFS.  So:

1) For the IKE SA, the Diffie-Hellman operation generates two encryption and two authentication keys.  Should the Diffie-Hellman strength generally be equivalent to the longest key length, or to the sum of the key lengths?  If we sum up all four symmetric key lengths, most choices will exceed the strength provided by the currently available Diffie-Hellman groups.  But if we don't sum up the symmetric key lengths, then we are making Diffie-Hellman the weakest link in the chain (i.e., we aren't obtaining significant added value by generating different values for each of SK_ei, SK_er, SK_ai, SK_ar).  Which is the case?
It's pointless to make it much stronger than the longest key, as each individual symmetric key can be attacked separately.
 
For example, suppose that SK_ei was an 128 bit AES key; the attacker could recover that key by finding a packet encrypted with that key, and do a trial decrypt based on successive keys, and stop when he finds a key that makes a plausible plaintext.  The important point is that he can do this without knowing what the other keys SK_er, SK_ai, SK_ar are, and so those other keys don't add to the security in this specific attack.
 
More generally, suppose the attacker is able to recover SK_ei with effort A (for example, if AES-128 is being used, and we're using brute force to recover the key, then A=2**127 decrypt operations expected), and similarly SK_er, SK_ai, SK_ar can be recovered with efforts B, C, D, then the time taken to recover all four is A+B+C+D, which is no more than 4 times the largest of the four (and this is assuming that the attacker is actually interested in all four, which is generally not the case).
 

1b) In any case, we don't have suitable Diffie-Hellman groups for use with HMAC-SHA2-384 and HMAC-SHA2-512.  Interestingly, the upcoming NIST and DoD standards push into the realm of 256-bit symmetric algorithms (HMAC-SHA2-256) with SHOULD+ or MUST, but for Diffie-Hellman only into the realm of 112 bits (NIST makes group 24 a MUST) or 128 bits (DoD makes group 19 a MUST).  Do the folks from DoD or NIST have any comments on this disparity?

2) If we are recommending parity between symmetric algorithms and DH group choice, is there any place that we are also recommending the use of perfect forward secrecy to guard against weaknesses there?  Not using perfect forward secrecy goes even further to make the Diffie-Hellman the weakest link in the chain.  And yet RFC 4308 does not require PFS, and NIST's own RFC 4869 doesn't even mention it.  Do the folks from NIST have any comments on why PFS is not mandated, let alone mentioned, in RFC 4869?

3) IKEv2 does not allow perfect forward secrecy for the first child SA.  Similar to question 1 above, how does that play into the recommendation for DH group size to choose?  Admittedly, there probably isn't much lost if the IKE SA keys are compromised.  So should we look only at the child SA symmetric key sizes when considering what IKE SA DH group is appropriate?  Or should we sum up the IKE and child SA symmetric key lengths?  
Same answer to the last question: the IKE and the IPSec SA keys can be attacked separately, and so making the DH stronger than the longest individual key doesn't gain you anything from a security standpoint.
 
--
scott
 

--=_alternative 0068E0F8852575E4_=-- From paul.hoffman@vpnc.org Mon Jun 29 14:53:27 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5A4893A6C3E for ; Mon, 29 Jun 2009 14:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 jA1lCQXMtMB1 for ; Mon, 29 Jun 2009 14:53:26 -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 5349F3A6BE9 for ; Mon, 29 Jun 2009 14:53:26 -0700 (PDT) Received: from [10.20.30.158] (75-101-30-90.dsl.dynamic.sonic.net [75.101.30.90]) (authenticated bits=0) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5TLriAh035690 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 29 Jun 2009 14:53:45 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 29 Jun 2009 14:50:17 -0700 To: Scott C Moonen , ipsec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" Subject: Re: [IPsec] ike sa rekey key generation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2009 21:53:27 -0000 At 3:51 PM -0400 6/26/09, Scott C Moonen wrote: >ikev2bis says the following: > > SK_d, SK_ai, SK_ar, SK_ei, and SK_er are computed from SKEYSEED as > specified in Section 2.14. > >Is it correct to assume that SPIi and SPIr as used in this rekey calculation are from the new, rekeyed IKE SA? Yes. It would not make sense to have the new values be based on the old SPIs. >Is it worth specifying that explicitly? Ni/Nr is more obvious, since those are explicitly exchanged with the CREATE_CHILD_SA rekey exchange. But the rekey exchange has two associated SPIs (the old SA's SPIs for the messages themselves, and the SPIs within the SA proposals), and it might be helpful to clarify this. I will add this to the next version of the ikev2bis document. --Paul Hoffman, Director --VPN Consortium From mohini_kaur@hotmail.com Tue Jun 30 22:51:58 2009 Return-Path: X-Original-To: ipsec@core3.amsl.com Delivered-To: ipsec@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F09828C12F for ; Tue, 30 Jun 2009 22:51:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.61 X-Spam-Level: X-Spam-Status: No, score=-0.61 tagged_above=-999 required=5 tests=[AWL=-0.612, BAYES_50=0.001, 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 3t81fmX0c1Lr for ; Tue, 30 Jun 2009 22:51:57 -0700 (PDT) Received: from blu0-omc2-s4.blu0.hotmail.com (blu0-omc2-s4.blu0.hotmail.com [65.55.111.79]) by core3.amsl.com (Postfix) with ESMTP id 1324D3A6768 for ; Tue, 30 Jun 2009 22:51:57 -0700 (PDT) Received: from BLU104-W28 ([65.55.111.73]) by blu0-omc2-s4.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 30 Jun 2009 22:52:18 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_5f700940-e717-4826-8ec1-6471988a7663_" X-Originating-IP: [125.22.248.230] From: Mohini Kaur To: Date: Wed, 1 Jul 2009 11:22:18 +0530 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 01 Jul 2009 05:52:18.0491 (UTC) FILETIME=[17F1C0B0:01C9FA10] Subject: [IPsec] FW: IPSec responder cookie X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Discussion of IPsec protocols List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 01 Jul 2009 05:51:58 -0000 --_5f700940-e717-4826-8ec1-6471988a7663_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: mohini_kaur@hotmail.com To: ipsec@ietf.org Subject: IPSec responder cookie Date: Thu=2C 25 Jun 2009 18:04:49 +0530 Hi=2C I have a doubt regarding the value of Responder cookie in ISAKMP protocol. When I read RFC 2408=2C Sec 2.5.3=2C it tells that the initiator and respon= der cookie must be set to a random value.=20 What I understand from this is=2C the responder cookie can have any value d= isregard to the cookie value from initiator. But when I verify this in a Cisco device (initiator)=2C it generates ISAKMP= main mode message with initiator cookie (let it be X). When I send an ISAKMP main mode message=2C with responder cookie same as Cisco device (X) or incrementing it by one (X+1)=2C it is discarding. (However it is processing the message with other values). Again when I do the same in a Linux machine as in Cisco=2C it is discarding the responder cookie with same value (X)=2C however processing responder cookie with value incremented by one (X+1). 1. Could someone explain me why Cisco and Linux validates ISAKMP main mode message with responder cookie differently? And which is the right validation? 2. Is there any other RFCs where I can get more information about validatio= n of ISAKMP main mode message with responder cookie? Thanks in advance. Regards Mohini MSN Battles We pitch one stalwart against the other and give you the power.= Who will you vote for? Share photos while you chat with Windows Live Messe= nger. _________________________________________________________________ Missed any of the IPL matches ? Catch a recap of all the action on MSN Vide= os http://msnvideos.in/iplt20/msnvideoplayer.aspx= --_5f700940-e717-4826-8ec1-6471988a7663_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

From: mohini_kaur@hotmail.com
To: ipsec@= ietf.org
Subject: IPSec responder cookie
Date: Thu=2C 25 Jun 2009 18:= 04:49 +0530

Hi=2C

I have a doubt regarding the value of Res= ponder cookie in ISAKMP protocol.

When I read R= FC 2408=2C Sec 2.5.3=2C it tells that the initiator and responder cookie mu= st be set to a random value.
What I understand= from this is=2C the responder cookie can have any value disregard to the c= ookie value from initiator.
But when I verify= this in a Cisco device (initiator)=2C it generates ISAKMP main mode messag= e with initiator cookie (let it be X).

When I send an ISAKMP main mode message=2C with responder cookie same as Cisco device (X) or incrementing it by one (X+1)=2C it is discarding. (However it is processing the message with other values).

Again when I do the same in a Linux machine as in Cisco=2C it is discarding the responder cookie with same value (X)=2C however processing responder cookie with value incremented by one (X+1).

1. Could someone explain me why Cisco and Linux validates ISAKMP main mode message with responder cookie differently? And which is the right validation?

2. Is there any other RFCs where I = can get more information about validation of ISAKMP main mode message with = responder cookie?<= br>
Thanks in advance.

Regards
Mohini<= /font>

= MSN Battles We pitch one stalwart against the other and give you the power.= Who will you vote for? Share photos= while you chat with Windows Live Messenger.
Videos Get the = latest video streams on movies=2C Try it! = --_5f700940-e717-4826-8ec1-6471988a7663_--