From ipsec-bounces@ietf.org Mon May 02 06:20:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSY2a-00039T-GT; Mon, 02 May 2005 06:20:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DSY2Y-00038f-AC for ipsec@megatron.ietf.org; Mon, 02 May 2005 06:20:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23981 for ; Mon, 2 May 2005 06:20:34 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DSYG9-0006wN-W0 for ipsec@ietf.org; Mon, 02 May 2005 06:34:43 -0400 Received: (qmail 7921 invoked by uid 0); 2 May 2005 10:20:14 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (156.106.205.51) by woodstock.binhost.com with SMTP; 2 May 2005 10:20:14 -0000 Message-Id: <6.2.0.14.2.20050502054310.0558b250@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Mon, 02 May 2005 06:20:21 -0400 To: ipsec@ietf.org From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Subject: [Ipsec] Many Thanks: WG Action: Conclusion of IP Security Protocol (ipsec) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I want to say a few words of thanks. The IPsec WG was one of the longest running IETF WG ever. The results are quite impressive. It is not possible to thank every contributor, reviewer, author, and editor. There were simply too many. You know who you are. Be proud of your work products. Over the years, there have been seven WG chairs. Thanks to each of them. Obviously, the work could not have been completed without their leadership. Alton Hoover Aug 1992 - Jan 1994 Paul Lambert Aug 1992 - Mar 1997 Jim Zmuda Feb 1994 - Dec 1994 Ran Atkinson Apr 1995 - Mar 1997 Bob Moskowitz Aug 1997 - Dec 1999 Ted Ts'o Aug 1997 - Apr 2005 Barbara Fraser Mar 2001 - Apr 2005 In the last two years, the WG chairs were assisted by two technical advisors. Thanks to them; they really helped the working group reach closure and consensus on recently approves set of documents. Angelos Keromytis Tero Kivinen Given the many years involved in the IPsec WG effort, many different Security Area Directors were involved. Steve Crocker was the first Security Area Director, and he was the original shepherd for the IPsec WG. Steve Crocker Nov 1989 - Mar 1994 Marcus Leech Mar 1998 - Mar 2002 Jeff Schiller Mar 1994 - Mar 2003 Steve Bellovin Mar 2002 - Nov 2004 Russ Housley Mar 2003 - ... Sam Hartman Nov 2004 - ... Again, thanks very much to all of the people who contributed to this important body of work. Russ _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed May 04 18:59:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTSpg-0006qp-F9; Wed, 04 May 2005 18:59:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTSpf-0006qk-0y for ipsec@megatron.ietf.org; Wed, 04 May 2005 18:59:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA21452 for ; Wed, 4 May 2005 18:59:03 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTT3n-0003jb-1P for ipsec@ietf.org; Wed, 04 May 2005 19:13:46 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j44MSEx23161; Wed, 4 May 2005 15:28:14 -0700 X-mProtect: <200505042228> Nokia Silicon Valley Messaging Protection Received: from mvdhcp141133.americas.nokia.com (172.18.141.133, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdRPJdef; Wed, 04 May 2005 15:28:12 PDT Message-ID: <4279539F.6010802@iprg.nokia.com> Date: Wed, 04 May 2005 15:58:39 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 0.9 (Windows/20041103) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [Ipsec] Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org hi Pasi, I interpreted this in a different way for IPv6. IMO, the INTERNAL_IP6_SUBNET attribute should contain the prefix that corresponds to the IPv6 prefix from which the address returned in the INTERNAL_IP6_ADDRESS attribute is configured from. Vijay ps: we already had a discussion on this off list, but I thought it would be a good idea to get comments from others. Pasi.Eronen@nokia.com wrote: > Hi everyone, > > One of the open issues in the IKEv2 clarifications draft > concerns INTERNAL_IP4_SUBNET and INTERNAL_IP4_NETMASK > attributes. We already had some discussion about these on the > list earlier, but I'd like to check if others think our > interpretation is roughly correct: > > - INTERNAL_IP4_SUBNET in CFG_REPLY means roughly that "in > my (responder's) opinion, you should send traffic to these > addresses through me". If these addresses are not included in > TSr, obviously we need to create additional SAs. And if TSr > includes other addresses (e.g. is 0.0.0.0-255.255.255.255) > it means that the client can (but does not have to), if > permitted by its own policy, do "split tunneling" (only > send the traffic listed in INTERNAL_IP4_SUBNETs via the > gateway, but other traffic directly). > > - Including INTERNAL_IP4_SUBNET in CFG_REQUEST is not > absolutely necessary: if the responder has this information, > it can send it anyway (as shown in the example in ikev2-17 > Section 2.19). But if INTERNAL_IP4_SUBNET is included in > CFG_REQUEST, other lengths than zero don't make sense. > > - The address blocks listed in INTERNAL_IP4_SUBNET do not have > to match physical link boundaries. For instance, if the whole > B class block 130.233.0.0/16 is behind the gateway, it's > enough to send a single INTERNAL_IP4_SUBNET attribute (rather > than listing all the /24s or whatever sized subnets that > organization uses). > > - INTERNAL_IP4_NETMASK does not make much sense, and should not > be used (or it means the same thing as INTERNAL_IP4_SUBNET, > and in that case, it's preferable to use INTERNAL_IP4_SUBNET). > > draft-eronen-draft-eronen-ipsec-ikev2-clarifications-02.txt > actually has almost four pages of text about these payloads, > so especially if you disagree with our current opinion (which > is open to change, BTW), please check that, too! > > Best regards, > Pasi > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu May 05 02:49:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTaB1-0004SN-IN; Thu, 05 May 2005 02:49:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DTaAz-0004SF-WB for ipsec@megatron.ietf.org; Thu, 05 May 2005 02:49:38 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA24668 for ; Thu, 5 May 2005 02:49:36 -0400 (EDT) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DTaPE-0000bl-Qt for ipsec@ietf.org; Thu, 05 May 2005 03:04:21 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id j456nMnP021087 for ; Thu, 5 May 2005 09:49:22 +0300 (IDT) Mime-Version: 1.0 (Apple Message framework v619.2) Content-Transfer-Encoding: 7bit Message-Id: Content-Type: text/plain; charset=US-ASCII; format=flowed To: IPsec WG From: Yoav Nir Date: Thu, 5 May 2005 09:49:21 +0300 X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Subject: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi. I've just submitted version -02 of the repeated authentication draft. Not much is changed other than some typos and explanations. I thought that version -02 would include a reference to the IKEv2 RFC, but I guess not yet. Is anyone else interested in this? A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Repeated Authentication in IKEv2 Author(s) : Y. Nir Filename : draft-nir-ikev2-auth-lt-02.txt Pages : 4 Date : 2005-5-4 With some IPsec peers, particularly in the remote access scenario, it is desirable to repeat the mutual authentication periodically. The purpose of this is to limit the time that SAs can be used by a third party who has gained control of the IPsec peer. This is not the same as IKE SA rekeying, and need not be tied to it. Repeated authentication can be achieved by simply repeating the Initial exchange by whichever side has a stricter policy. However, in the remote access scenario it is usually up to a human user to supply the authentication credentials, and often EAP is used for authentication, which makes it unreasonable or impossible for the remote access gateway to initiate the exchange. This document describes how the original Responder can send a notification to the Initiator with the number of seconds before the authentication needs to be repeated. The Initiator will repeat the Initial exchange before that time is expired. If the Initiator fails to do so, the Responder may close all tunnels. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-nir-ikev2-auth-lt-02.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-nir-ikev2-auth-lt-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-nir-ikev2-auth-lt-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. Content-Type: text/plain Content-ID: <2005-5-4153137.I-D@ietf.org> _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri May 06 10:42:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU42J-0008GG-B4; Fri, 06 May 2005 10:42:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU42H-0008G7-LU for ipsec@megatron.ietf.org; Fri, 06 May 2005 10:42:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21720 for ; Fri, 6 May 2005 10:42:35 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU4Gn-0000af-7b for ipsec@ietf.org; Fri, 06 May 2005 10:57:38 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j46EgTu11577 for ; Fri, 6 May 2005 17:42:31 +0300 (EET DST) X-Scanned: Fri, 6 May 2005 17:42:07 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j46Eg7AS000572 for ; Fri, 6 May 2005 17:42:07 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 006qCUR0; Fri, 06 May 2005 17:42:05 EEST Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j46Eg2M16255 for ; Fri, 6 May 2005 17:42:02 +0300 (EET DST) Received: from esebh006.NOE.Nokia.com ([172.21.138.88]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 6 May 2005 17:41:58 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh006.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 6 May 2005 17:41:57 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 May 2005 17:41:58 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK Date: Fri, 6 May 2005 17:41:57 +0300 Message-ID: Thread-Topic: [Ipsec] Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK thread-index: AcVQ/NizVUCF8m6tRAWoLikSIMMRPgBTF/qg To: X-OriginalArrivalTime: 06 May 2005 14:41:58.0190 (UTC) FILETIME=[C1783CE0:01C55249] X-Spam-Score: 0.3 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Vijay, Isn't that information already sent in INTERNAL_IP6_ADDRESS attribute, in the "prefix length" field...? Best regards, Pasi > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: Thursday, May 05, 2005 1:59 AM > To: Eronen Pasi (Nokia-NRC/Helsinki) > Cc: ipsec@ietf.org > Subject: Re: [Ipsec] Clarifications open issue: > INTERNAL_IP4_SUBNET/NETMASK >=20 >=20 > hi Pasi, >=20 > I interpreted this in a different way for IPv6. IMO, the > INTERNAL_IP6_SUBNET attribute should contain the prefix that > corresponds to the IPv6 prefix from which the address > returned in the INTERNAL_IP6_ADDRESS attribute is configured > from. >=20 > Vijay >=20 > ps: we already had a discussion on this off list, but I thought > it would be a good idea to get comments from others. >=20 > Pasi.Eronen@nokia.com wrote: > > Hi everyone, > >=20 > > One of the open issues in the IKEv2 clarifications draft > > concerns INTERNAL_IP4_SUBNET and INTERNAL_IP4_NETMASK > > attributes. We already had some discussion about these on the > > list earlier, but I'd like to check if others think our > > interpretation is roughly correct: > >=20 > > - INTERNAL_IP4_SUBNET in CFG_REPLY means roughly that "in > > my (responder's) opinion, you should send traffic to these > > addresses through me". If these addresses are not included in > > TSr, obviously we need to create additional SAs. And if TSr > > includes other addresses (e.g. is 0.0.0.0-255.255.255.255)=20 > > it means that the client can (but does not have to), if=20 > > permitted by its own policy, do "split tunneling" (only=20 > > send the traffic listed in INTERNAL_IP4_SUBNETs via the=20 > > gateway, but other traffic directly). > >=20 > > - Including INTERNAL_IP4_SUBNET in CFG_REQUEST is not=20 > > absolutely necessary: if the responder has this information,=20 > > it can send it anyway (as shown in the example in ikev2-17=20 > > Section 2.19). But if INTERNAL_IP4_SUBNET is included in=20 > > CFG_REQUEST, other lengths than zero don't make sense. > >=20 > > - The address blocks listed in INTERNAL_IP4_SUBNET do not have > > to match physical link boundaries. For instance, if the whole > > B class block 130.233.0.0/16 is behind the gateway, it's > > enough to send a single INTERNAL_IP4_SUBNET attribute (rather > > than listing all the /24s or whatever sized subnets that > > organization uses). > > =20 > > - INTERNAL_IP4_NETMASK does not make much sense, and should not > > be used (or it means the same thing as INTERNAL_IP4_SUBNET, > > and in that case, it's preferable to use INTERNAL_IP4_SUBNET). > >=20 > > draft-eronen-draft-eronen-ipsec-ikev2-clarifications-02.txt > > actually has almost four pages of text about these payloads, > > so especially if you disagree with our current opinion (which > > is open to change, BTW), please check that, too! > >=20 > > Best regards, > > Pasi > >=20 > > _______________________________________________ > > Ipsec mailing list > > Ipsec@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipsec >=20 >=20 >=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri May 06 11:08:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU4RN-0003cH-5z; Fri, 06 May 2005 11:08:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU4RK-0003c9-O2 for ipsec@megatron.ietf.org; Fri, 06 May 2005 11:08:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24393 for ; Fri, 6 May 2005 11:08:28 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DU4fp-0002Mq-Ni for ipsec@ietf.org; Fri, 06 May 2005 11:23:31 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j46F8PM15368; Fri, 6 May 2005 18:08:25 +0300 (EET DST) X-Scanned: Fri, 6 May 2005 18:08:18 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j46F8IWh002180; Fri, 6 May 2005 18:08:18 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 001lGFqd; Fri, 06 May 2005 18:06:14 EEST Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j46F6CM12078; Fri, 6 May 2005 18:06:12 +0300 (EET DST) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 6 May 2005 18:06:02 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 6 May 2005 18:06:01 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 6 May 2005 18:06:02 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt Date: Fri, 6 May 2005 18:06:00 +0300 Message-ID: Thread-Topic: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt thread-index: AcVRP2izi5xulpbwREyfogDl+912KgBC79tw To: , X-OriginalArrivalTime: 06 May 2005 15:06:02.0218 (UTC) FILETIME=[1E2D6CA0:01C5524D] X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > I've just submitted version -02 of the repeated authentication > draft. Not much is changed other than some typos and > explanations. I thought that version -02 would include a > reference to the IKEv2 RFC, but I guess not yet. >=20 > Is anyone else interested in this? Yes, I think many vendors will need something like this, and it makes more sense to have one interoperable way, rather than each vendor implementing their proprietary extension. And IMHO it does not matter what exactly the details are, as long as we get it published in a timely fashion. Given that the IANA actions for IKEv2 are already done, I think you should ask Russ to appoint a "Designated Expert", and move forward as individual submission for informational (so we don't have to wait years for all IPsec folks to get full consensus=20 on the punctuation). Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri May 06 14:14:51 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU7Lf-0005nz-Eu; Fri, 06 May 2005 14:14:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DU7Ld-0005nl-TC for ipsec@megatron.ietf.org; Fri, 06 May 2005 14:14:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA16448 for ; Fri, 6 May 2005 14:14:48 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DU7a8-00076f-8M for ipsec@ietf.org; Fri, 06 May 2005 14:29:52 -0400 Received: (qmail 8316 invoked by uid 0); 6 May 2005 18:14:05 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.0.77) by woodstock.binhost.com with SMTP; 6 May 2005 18:14:05 -0000 Message-Id: <6.2.0.14.2.20050506125406.0655c420@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 06 May 2005 13:04:25 -0400 To: Pasi.Eronen@nokia.com, , From: Russ Housley Subject: RE: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org My understanding is that an expert for IKEv2 has already been appointed to help IANA. Russ At 11:06 AM 5/6/2005, Pasi.Eronen@nokia.com wrote: > > I've just submitted version -02 of the repeated authentication > > draft. Not much is changed other than some typos and > > explanations. I thought that version -02 would include a > > reference to the IKEv2 RFC, but I guess not yet. > > > > Is anyone else interested in this? > >Yes, I think many vendors will need something like this, and it >makes more sense to have one interoperable way, rather than each >vendor implementing their proprietary extension. And IMHO it >does not matter what exactly the details are, as long as we get >it published in a timely fashion. > >Given that the IANA actions for IKEv2 are already done, I think >you should ask Russ to appoint a "Designated Expert", and move >forward as individual submission for informational (so we don't >have to wait years for all IPsec folks to get full consensus >on the punctuation). > >Best regards, >Pasi > >_______________________________________________ >Ipsec mailing list >Ipsec@ietf.org >https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun May 08 03:23:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUg8Z-000172-4V; Sun, 08 May 2005 03:23:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUg8W-00016t-Vz for ipsec@megatron.ietf.org; Sun, 08 May 2005 03:23:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20132 for ; Sun, 8 May 2005 03:23:35 -0400 (EDT) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DUgNN-0003H5-5V for ipsec@ietf.org; Sun, 08 May 2005 03:38:58 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id j487NOnP018491; Sun, 8 May 2005 10:23:25 +0300 (IDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <45fc835f886835ca2fc010f353239a01@checkpoint.com> Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt Date: Sun, 8 May 2005 10:23:25 +0300 To: X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org The reason I'm asking is that I'm not sure what I'm doing there is the best way. What the draft says is for the Initiator to wait a certain amount of time, and then tear down all the SAs and create new ones via a completely new initial exchange. This is much more than is necessary. A better solution would be to allow a new AUTH exchange (2 or 6 messages) without an INITIAL exchange, and without any piggybacked child SAs. The reason I chose the inferior solutions is for simplicity: - No need to create a new state machine for a standalone AUTH exchange - Easier to add support to existing IKEv2 implementations - No need to find something to sign in the in AUTH payloads (maybe the original INITIAL exchange packets? Would it be secure to sign them again?) Anyway, I can see valid reasons to do it either way, and that is why I'm soliciting comments. On May 6, 2005, at 6:06 PM, wrote: > > Yes, I think many vendors will need something like this, and it > makes more sense to have one interoperable way, rather than each > vendor implementing their proprietary extension. And IMHO it > does not matter what exactly the details are, as long as we get > it published in a timely fashion. > > Given that the IANA actions for IKEv2 are already done, I think > you should ask Russ to appoint a "Designated Expert", and move > forward as individual submission for informational (so we don't > have to wait years for all IPsec folks to get full consensus > on the punctuation). _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun May 08 12:44:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUotl-0003RK-V4; Sun, 08 May 2005 12:44:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DUotj-0003RF-QH for ipsec@megatron.ietf.org; Sun, 08 May 2005 12:44:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28141 for ; Sun, 8 May 2005 12:44:53 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DUp8g-0000TN-AF for ipsec@ietf.org; Sun, 08 May 2005 13:00:22 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 08 May 2005 09:44:46 -0700 X-IronPort-AV: i="3.92,164,1112598000"; d="scan'208"; a="262141756:sNHT28556068" Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j48GiSOD026203; Sun, 8 May 2005 09:44:41 -0700 (PDT) Received: from xmb-sjc-237.amer.cisco.com ([128.107.191.123]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 8 May 2005 09:44:36 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt Date: Sun, 8 May 2005 09:44:35 -0700 Message-ID: Thread-Topic: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt Thread-Index: AcVTn1kAHEVR6+0XTB2zS81DHLG6XAATCTHw From: "Geoff Huang \(ghuang\)" To: "Yoav Nir" , X-OriginalArrivalTime: 08 May 2005 16:44:36.0077 (UTC) FILETIME=[37F031D0:01C553ED] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]=20 > On Behalf Of Yoav Nir > Sent: Sunday, May 08, 2005 12:23 AM > To: Pasi.Eronen@nokia.com > Cc: ipsec@ietf.org > Subject: Re: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt >=20 > The reason I'm asking is that I'm not sure what I'm doing=20 > there is the best way. >=20 > What the draft says is for the Initiator to wait a certain=20 > amount of time, and then tear down all the SAs and create new=20 > ones via a completely new initial exchange. This is much=20 > more than is necessary. =20 > A better solution would be to allow a new AUTH exchange (2 or 6 > messages) without an INITIAL exchange, and without any=20 > piggybacked child SAs. Or simply an informational exchange that contains an AUTH payload (or AUTH + ID payloads). > The reason I chose the inferior solutions is for simplicity: > - No need to create a new state machine for a standalone=20 > AUTH exchange > - Easier to add support to existing IKEv2 implementations > - No need to find something to sign in the in AUTH payloads=20 > (maybe the original INITIAL exchange packets? Would it be=20 > secure to sign them > again?) >=20 > Anyway, I can see valid reasons to do it either way, and that=20 > is why I'm soliciting comments. Despite the fact that the re-authentication could be achieved with fewer messages, I prefer your approach for the same reasons you mention. I do have one question however: - why give the option of sending the AUTH_LIFETIME notify in either a separate informational exchange or at the end of the IKE_AUTH exchange? Why not just include it in the IKE_AUTH exchange? Is this a compromise between the "re-auth immediately" vs. "re-auth in X seconds" discussion we had on this list a few months ago? -g >=20 >=20 > On May 6, 2005, at 6:06 PM, wrote: > > > > Yes, I think many vendors will need something like this, and it > > makes more sense to have one interoperable way, rather than each > > vendor implementing their proprietary extension. And IMHO it > > does not matter what exactly the details are, as long as we get > > it published in a timely fashion. > > > > Given that the IANA actions for IKEv2 are already done, I think > > you should ask Russ to appoint a "Designated Expert", and move > > forward as individual submission for informational (so we don't > > have to wait years for all IPsec folks to get full consensus > > on the punctuation). >=20 >=20 > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec >=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon May 09 02:39:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV1vB-0002HY-87; Mon, 09 May 2005 02:39:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV1v9-0002HR-Li for ipsec@megatron.ietf.org; Mon, 09 May 2005 02:39:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05491 for ; Mon, 9 May 2005 02:39:14 -0400 (EDT) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DV2AC-0001wS-5n for ipsec@ietf.org; Mon, 09 May 2005 02:54:49 -0400 Received: from [172.31.24.201] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id j496d1nP007589; Mon, 9 May 2005 09:39:01 +0300 (IDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt Date: Mon, 9 May 2005 09:38:59 +0300 To: "Geoff Huang \(ghuang\)" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On May 8, 2005, at 7:44 PM, Geoff Huang ((ghuang)) wrote: > > Despite the fact that the re-authentication could be achieved with > fewer > messages, I prefer your approach for the same reasons you mention. I > do > have one question however: > > - why give the option of sending the AUTH_LIFETIME notify in either a > separate informational exchange or at the end of the IKE_AUTH exchange? > Why not just include it in the IKE_AUTH exchange? Is this a compromise > between the "re-auth immediately" vs. "re-auth in X seconds" discussion > we had on this list a few months ago? > Yes. It allows you to do either. You can do it during the initial exchange, or you can do it just before you want the peer to re-authenticate. My implementation will only send them as part of the AUTH exchange, but I do want others to use it as well. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon May 09 06:16:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV5J2-0004wC-SW; Mon, 09 May 2005 06:16:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV5J0-0004v6-Jr for ipsec@megatron.ietf.org; Mon, 09 May 2005 06:16:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA23935 for ; Mon, 9 May 2005 06:16:04 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DV5Y4-0001IL-Vt for ipsec@ietf.org; Mon, 09 May 2005 06:31:42 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j49AG0TB008058 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Mon, 9 May 2005 13:16:00 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j49AFvWX008055; Mon, 9 May 2005 13:15:58 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17023.14429.474761.207509@fireball.kivinen.iki.fi> Date: Mon, 9 May 2005 13:15:57 +0300 From: Tero Kivinen To: Pasi.Eronen@nokia.com Subject: RE: [Ipsec] Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 15 min X-Total-Time: 15 min X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, vijayd@iprg.nokia.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Pasi.Eronen@nokia.com writes: > Isn't that information already sent in INTERNAL_IP6_ADDRESS > attribute, in the "prefix length" field...? When the initiator requests IPv6 address with INTERNAL_IP6_ADDRESS, he already fills that field with the hint what address he would like to have. If he had had address before then that address will be filled in completely, as he would like to get same address back. If he has no prefix to use, he can fill in the lower 64-bits to tell the server which 64 lower bits to use for the address (i.e. fillin the interface ID). The prefix length of the request most likely matches either the previous prefix, or 64 in case initiator filled in lower 64 bits (or prefix length matching the filled data). When the responder (server) gets the request it first checks if the address specified is acceptable, and if so it will return that. If not he will replace the prefix length, and fill in the suitable global routing prefix and subnet ID to be used for this connection. Then it needs to check if the given IP-address is acceptable (i.e no duplicate address already given out etc), and if so give it out. If the address from previous step is not acceptable (for example because the initiator didn't fill in the interface ID, and they are all zeros), then the server will modify the interface ID so that it forms acceptable IP-address. > > I interpreted this in a different way for IPv6. IMO, the > > INTERNAL_IP6_SUBNET attribute should contain the prefix that > > corresponds to the IPv6 prefix from which the address > > returned in the INTERNAL_IP6_ADDRESS attribute is configured > > from. I have not interpreted IKEv2 draft that way. INTERNAL_IP6_SUBNET is specified to contain the "protected sub-networks that this edge-device protects". That does not have anything to do with INTERNAL_IP6_ADDRESS address allocation. Most commonly there is no need to list the subnet where the address is allocated from in the INTERNAL_IP6_SUBNET as it is already covered by the traffic selectors. It could also be listed in the INTERNAL_IP6_SUBNET, but I do not think that is necessary. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon May 09 10:52:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV9ch-0002I7-Rt; Mon, 09 May 2005 10:52:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV9cg-0002I2-21 for ipsec@megatron.ietf.org; Mon, 09 May 2005 10:52:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21606 for ; Mon, 9 May 2005 10:52:39 -0400 (EDT) Received: from sj-iport-4.cisco.com ([171.68.10.86]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DV9rm-0003Iu-UI for ipsec@ietf.org; Mon, 09 May 2005 11:08:20 -0400 Received: from sj-core-3.cisco.com (171.68.223.137) by sj-iport-4.cisco.com with ESMTP; 09 May 2005 07:52:28 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-3.cisco.com (8.12.10/8.12.6) with ESMTP id j49Epiri014764; Mon, 9 May 2005 07:52:25 -0700 (PDT) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 9 May 2005 07:52:24 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt Date: Mon, 9 May 2005 07:52:23 -0700 Message-ID: <2AB1DCE354761449A2E270681CC0429823CEDD@xmb-sjc-21c.amer.cisco.com> Thread-Topic: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt Thread-Index: AcVUYmKMjeu0wTCLSaK86yImYytSnAARD7qw From: "Bora Akyol \(bora\)" To: "Yoav Nir" , "Geoff Huang \(ghuang\)" X-OriginalArrivalTime: 09 May 2005 14:52:24.0539 (UTC) FILETIME=[B60AC2B0:01C554A6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Why would we want to give the opportunity for diverged functionality? IMHO, better pick one and stick with it unless there is a good reason to do otherwise. =20 -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Yoav Nir Sent: Sunday, May 08, 2005 11:39 PM To: Geoff Huang (ghuang) Cc: ipsec@ietf.org; Pasi.Eronen@nokia.com Subject: Re: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt On May 8, 2005, at 7:44 PM, Geoff Huang ((ghuang)) wrote: > > Despite the fact that the re-authentication could be achieved with=20 > fewer messages, I prefer your approach for the same reasons you=20 > mention. I do have one question however: > > - why give the option of sending the AUTH_LIFETIME notify in either a=20 > separate informational exchange or at the end of the IKE_AUTH exchange? > Why not just include it in the IKE_AUTH exchange? Is this a=20 > compromise between the "re-auth immediately" vs. "re-auth in X=20 > seconds" discussion we had on this list a few months ago? > Yes. It allows you to do either. You can do it during the initial exchange, or you can do it just before you want the peer to re-authenticate. My implementation will only send them as part of the AUTH exchange, but I do want others to use it as well. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon May 09 11:14:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV9xQ-00073v-OH; Mon, 09 May 2005 11:14:08 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DV9xO-00073j-Ez for ipsec@megatron.ietf.org; Mon, 09 May 2005 11:14:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24931 for ; Mon, 9 May 2005 11:14:04 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVACU-0004QP-OZ for ipsec@ietf.org; Mon, 09 May 2005 11:29:45 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 09 May 2005 08:13:55 -0700 X-IronPort-AV: i="3.92,169,1112598000"; d="scan'208"; a="262461539:sNHT26802120" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j49FDqPo018706; Mon, 9 May 2005 08:13:52 -0700 (PDT) Received: from [10.32.227.24] ([10.32.227.24]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id BEM95799; Mon, 9 May 2005 08:13:51 -0700 (PDT) Message-ID: <427F7DB5.9010006@cisco.com> Date: Mon, 09 May 2005 08:11:49 -0700 From: Geoffrey Huang User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050408) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Bora Akyol (bora)" Subject: Re: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt References: <2AB1DCE354761449A2E270681CC0429823CEDD@xmb-sjc-21c.amer.cisco.com> In-Reply-To: <2AB1DCE354761449A2E270681CC0429823CEDD@xmb-sjc-21c.amer.cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 2.2 (++) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com, Yoav Nir X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Bora Akyol (bora) wrote: > Why would we want to give the opportunity for diverged functionality? > > IMHO, better pick one and stick with it unless there is a good > reason to do otherwise. The reason is that sending a "re-auth now" message saves the initiator from ever having to keep a reauthentication timer. I guess in practice, this might not really buy you anything. -g > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Yoav Nir > Sent: Sunday, May 08, 2005 11:39 PM > To: Geoff Huang (ghuang) > Cc: ipsec@ietf.org; Pasi.Eronen@nokia.com > Subject: Re: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt > > On May 8, 2005, at 7:44 PM, Geoff Huang ((ghuang)) wrote: > > >>Despite the fact that the re-authentication could be achieved with >>fewer messages, I prefer your approach for the same reasons you >>mention. I do have one question however: >> >>- why give the option of sending the AUTH_LIFETIME notify in either a >>separate informational exchange or at the end of the IKE_AUTH > > exchange? > >>Why not just include it in the IKE_AUTH exchange? Is this a >>compromise between the "re-auth immediately" vs. "re-auth in X >>seconds" discussion we had on this list a few months ago? >> > > > Yes. It allows you to do either. You can do it during the initial > exchange, or you can do it just before you want the peer to > re-authenticate. My implementation will only send them as part of the > AUTH exchange, but I do want others to use it as well. > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon May 09 12:25:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVB4e-0004Yd-Ub; Mon, 09 May 2005 12:25:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVB4d-0004Xz-4b for ipsec@megatron.ietf.org; Mon, 09 May 2005 12:25:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02414 for ; Mon, 9 May 2005 12:25:36 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVBJl-0007Qi-1c for ipsec@ietf.org; Mon, 09 May 2005 12:41:18 -0400 Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j49GORDN076686; Mon, 9 May 2005 09:24:27 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <427F7DB5.9010006@cisco.com> References: <2AB1DCE354761449A2E270681CC0429823CEDD@xmb-sjc-21c.amer.cisco.com> <427F7DB5.9010006@cisco.com> Date: Mon, 9 May 2005 09:24:25 -0700 To: Geoffrey Huang , "Bora Akyol (bora)" From: Paul Hoffman Subject: Re: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ipsec@ietf.org, Yoav Nir , Pasi.Eronen@nokia.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 8:11 AM -0700 5/9/05, Geoffrey Huang wrote: >Bora Akyol (bora) wrote: >> Why would we want to give the opportunity for diverged functionality? >> >> IMHO, better pick one and stick with it unless there is a good >> reason to do otherwise. > >The reason is that sending a "re-auth now" message saves the initiator >from ever having to keep a reauthentication timer. I guess in practice, >this might not really buy you anything. Right, it really doesn't. And, it makes implementation harder. I support "do it in one place", and I think in the initial exchange makes the most sense. "I just decided I want you to reauthenticate" doesn't seem nearly as likely as "I know what my reauthentication rules are at the beginning". --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 10 02:42:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOSF-0000Lz-H2; Tue, 10 May 2005 02:42:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVOSD-0000Lk-Ht for ipsec@megatron.ietf.org; Tue, 10 May 2005 02:42:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA19981 for ; Tue, 10 May 2005 02:42:52 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVOhS-0000fR-S9 for ipsec@ietf.org; Tue, 10 May 2005 02:58:40 -0400 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j4A6gnl00987 for ; Tue, 10 May 2005 09:42:49 +0300 (EET DST) X-Scanned: Tue, 10 May 2005 09:42:33 +0300 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j4A6gX3S014834 for ; Tue, 10 May 2005 09:42:33 +0300 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00szp6i1; Tue, 10 May 2005 09:42:31 EEST Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j4A6gNM14675 for ; Tue, 10 May 2005 09:42:23 +0300 (EET DST) Received: from esebh108.NOE.Nokia.com ([172.21.143.145]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 10 May 2005 09:42:20 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 May 2005 09:42:19 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 10 May 2005 09:42:19 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt Date: Tue, 10 May 2005 09:42:18 +0300 Message-ID: Thread-Topic: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt Thread-Index: AcVUs/eeKYk3YN3JS4izr50anq8GrQAdj13g To: X-OriginalArrivalTime: 10 May 2005 06:42:19.0527 (UTC) FILETIME=[69B3C170:01C5552B] X-Spam-Score: 0.3 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Existing AAA protocols (RADIUS and Diameter) have found it useful=20 to have both Session-Timeout/Authorization-Lifetime AVPs, and the=20 ability for the server to initiate reauthentication even if the=20 previously given lifetime hasn't passed yet (Change-of-Authorization and Re-Auth-Request messages). Since many VPN gateways are likely to use some AAA protocol, I=20 don't think we should remove the ability to send a new AUTH_LIFETIME=20 in a separate Informational exchange (especially considering that it doesn't complicate implementations very much). Best regards, Pasi > -----Original Message----- > From: paul.hoffman@vpnc.org > Sent: Monday, May 09, 2005 7:24 PM > To: Geoffrey Huang; Bora Akyol (bora) > Cc: ipsec@ietf.org; Eronen Pasi (Nokia-NRC/Helsinki); Yoav Nir > Subject: Re: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt >=20 >=20 > At 8:11 AM -0700 5/9/05, Geoffrey Huang wrote: > >Bora Akyol (bora) wrote: > >> Why would we want to give the opportunity for diverged=20 > >> functionality? > >> > >> IMHO, better pick one and stick with it unless there is a good > >> reason to do otherwise. > > > >The reason is that sending a "re-auth now" message saves the=20 > >initiator from ever having to keep a reauthentication timer. =20 > >I guess in practice, his might not really buy you anything. >=20 > Right, it really doesn't. And, it makes implementation harder. I=20 > support "do it in one place", and I think in the initial exchange=20 > makes the most sense. "I just decided I want you to reauthenticate"=20 > doesn't seem nearly as likely as "I know what my reauthentication=20 > rules are at the beginning". >=20 > --Paul Hoffman, Director > --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 10 06:30:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVS0F-0002TC-Bb; Tue, 10 May 2005 06:30:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVS0E-0002Sh-7X for ipsec@megatron.ietf.org; Tue, 10 May 2005 06:30:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05712 for ; Tue, 10 May 2005 06:30:11 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVSFV-0003jS-JU for ipsec@ietf.org; Tue, 10 May 2005 06:46:03 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j4AAStv1028279 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 10 May 2005 13:28:56 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j4AASr1r028275; Tue, 10 May 2005 13:28:53 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17024.36069.127087.77628@fireball.kivinen.iki.fi> Date: Tue, 10 May 2005 13:28:53 +0300 From: Tero Kivinen To: Geoffrey Huang Subject: Re: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt In-Reply-To: <427F7DB5.9010006@cisco.com> References: <2AB1DCE354761449A2E270681CC0429823CEDD@xmb-sjc-21c.amer.cisco.com> <427F7DB5.9010006@cisco.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 5 min X-Total-Time: 5 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com, "Bora Akyol \(bora\)" , Yoav Nir X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Geoffrey Huang writes: > Bora Akyol (bora) wrote: > > Why would we want to give the opportunity for diverged functionality? > > > > IMHO, better pick one and stick with it unless there is a good > > reason to do otherwise. > > The reason is that sending a "re-auth now" message saves the initiator > from ever having to keep a reauthentication timer. I guess in practice, > this might not really buy you anything. Or the reauthentication can be based on something else than time only. I.e. on some system reauthentication might always be required before doing monetary transaction over $10000 or after 1GB of transferred data or before accessing certain systems etc. If the only option is time based thing set when the SA is created it is quite restrictive. If the server can use implementation depended code to decide when to request reauthentication from client, that is much more flexible. I would leave the time based thing away completely, i.e server would always drive the reauthentication, but some people want it there too. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 10 06:33:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVS3N-0002ZI-A5; Tue, 10 May 2005 06:33:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVS3L-0002ZD-4r for ipsec@megatron.ietf.org; Tue, 10 May 2005 06:33:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05920 for ; Tue, 10 May 2005 06:33:24 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVSId-0003si-DM for ipsec@ietf.org; Tue, 10 May 2005 06:49:16 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j4AAW3vF028428 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 10 May 2005 13:32:08 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j4AAVxJ9028425; Tue, 10 May 2005 13:31:59 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17024.36255.386391.748558@fireball.kivinen.iki.fi> Date: Tue, 10 May 2005 13:31:59 +0300 From: Tero Kivinen To: Paul Hoffman Subject: Re: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt In-Reply-To: References: <2AB1DCE354761449A2E270681CC0429823CEDD@xmb-sjc-21c.amer.cisco.com> <427F7DB5.9010006@cisco.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 2 min X-Total-Time: 2 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Yoav Nir , "Bora Akyol \(bora\)" , Pasi.Eronen@nokia.com, Geoffrey Huang X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Paul Hoffman writes: > Right, it really doesn't. And, it makes implementation harder. I > support "do it in one place", and I think in the initial exchange > makes the most sense. "I just decided I want you to reauthenticate" > doesn't seem nearly as likely as "I know what my reauthentication > rules are at the beginning". Then the problem is that the reauthentication rules might be something that cannot be expressed by simple time based system. I.e. what happens after reauthentication. Do we start new timer after that? What if the server requires reauthentication only if systems are accessed after office hours (i.e. you can leave connections up when you go home, but if you try to really use them (download files etc), it requires reauthentication after 5pm etc. That was the reason why we left out communcation of timers, lifetimes etc in the IKEv2 in the first place. Why do we want to add it now? -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 10 10:14:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVVVg-0006aL-Jt; Tue, 10 May 2005 10:14:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVVVf-0006aG-1W for ipsec@megatron.ietf.org; Tue, 10 May 2005 10:14:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29466 for ; Tue, 10 May 2005 10:14:53 -0400 (EDT) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVVky-0002qY-G1 for ipsec@ietf.org; Tue, 10 May 2005 10:30:45 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-5.cisco.com with ESMTP; 10 May 2005 07:14:45 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4AEETQ0011552; Tue, 10 May 2005 07:14:42 -0700 (PDT) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 10 May 2005 07:14:39 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt Content-class: urn:content-classes:message X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 10 May 2005 07:14:37 -0700 Message-ID: <2AB1DCE354761449A2E270681CC0429823D01B@xmb-sjc-21c.amer.cisco.com> Thread-Topic: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt Thread-Index: AcVVS1p/4n+w/D8STbOwG/L0EXYNnwAHwwRA From: "Bora Akyol \(bora\)" To: "Tero Kivinen" , "Geoff Huang \(ghuang\)" X-OriginalArrivalTime: 10 May 2005 14:14:39.0179 (UTC) FILETIME=[9A3201B0:01C5556A] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, Yoav Nir , Pasi.Eronen@nokia.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Tero This is all nice and sound in theory, but in practice we know that the encrypting gateways rarely talk to the end application and neither does the vpn software running on the end host. So I suggest the KISS principle as being appropriate here. =20 -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi]=20 Sent: Tuesday, May 10, 2005 3:29 AM To: Geoff Huang (ghuang) Cc: Bora Akyol (bora); ipsec@ietf.org; Pasi.Eronen@nokia.com; Yoav Nir Subject: Re: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt Geoffrey Huang writes: > Bora Akyol (bora) wrote: > > Why would we want to give the opportunity for diverged functionality? > >=20 > > IMHO, better pick one and stick with it unless there is a good=20 > > reason to do otherwise. >=20 > The reason is that sending a "re-auth now" message saves the initiator > from ever having to keep a reauthentication timer. I guess in=20 > practice, this might not really buy you anything. Or the reauthentication can be based on something else than time only. I.e. on some system reauthentication might always be required before doing monetary transaction over $10000 or after 1GB of transferred data or before accessing certain systems etc. If the only option is time based thing set when the SA is created it is quite restrictive. If the server can use implementation depended code to decide when to request reauthentication from client, that is much more flexible. I would leave the time based thing away completely, i.e server would always drive the reauthentication, but some people want it there too. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 10 10:21:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVVbZ-0007Q9-Nk; Tue, 10 May 2005 10:21:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVVbY-0007Q4-6i for ipsec@megatron.ietf.org; Tue, 10 May 2005 10:21:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00223 for ; Tue, 10 May 2005 10:20:58 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVVqr-0003G3-Pg for ipsec@ietf.org; Tue, 10 May 2005 10:36:51 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 10 May 2005 07:20:50 -0700 X-IronPort-AV: i="3.92,172,1112598000"; d="scan'208"; a="635255424:sNHT29098304" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4AEKeO3015486; Tue, 10 May 2005 07:20:40 -0700 (PDT) Received: from [10.32.227.24] ([10.32.227.24]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id BEN49397; Tue, 10 May 2005 07:20:46 -0700 (PDT) Message-ID: <4280C2C2.2020403@cisco.com> Date: Tue, 10 May 2005 07:18:42 -0700 From: Geoffrey Huang User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050408) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen Subject: Re: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt References: <2AB1DCE354761449A2E270681CC0429823CEDD@xmb-sjc-21c.amer.cisco.com> <427F7DB5.9010006@cisco.com> <17024.36069.127087.77628@fireball.kivinen.iki.fi> In-Reply-To: <17024.36069.127087.77628@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com, "Bora Akyol \(bora\)" , Yoav Nir X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org That's right - I'd forgotten about this scenario. Thanks, -g Tero Kivinen wrote: > Geoffrey Huang writes: > >>Bora Akyol (bora) wrote: >> >>>Why would we want to give the opportunity for diverged functionality? >>> >>>IMHO, better pick one and stick with it unless there is a good >>>reason to do otherwise. >> >>The reason is that sending a "re-auth now" message saves the initiator >>from ever having to keep a reauthentication timer. I guess in practice, >>this might not really buy you anything. > > > Or the reauthentication can be based on something else than time only. > I.e. on some system reauthentication might always be required before > doing monetary transaction over $10000 or after 1GB of transferred > data or before accessing certain systems etc. > > If the only option is time based thing set when the SA is created it > is quite restrictive. If the server can use implementation depended > code to decide when to request reauthentication from client, that is > much more flexible. I would leave the time based thing away > completely, i.e server would always drive the reauthentication, but > some people want it there too. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 10 12:54:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVY0A-00080Y-Lk; Tue, 10 May 2005 12:54:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVY08-0007xs-Br for ipsec@megatron.ietf.org; Tue, 10 May 2005 12:54:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14908 for ; Tue, 10 May 2005 12:54:29 -0400 (EDT) Received: from alpha.xerox.com ([13.1.64.93]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DVYFT-0005Cw-4X for ipsec@ietf.org; Tue, 10 May 2005 13:10:24 -0400 Received: from [13.2.116.161] ([13.2.116.161]) by alpha.xerox.com with SMTP id <172747(1)>; Tue, 10 May 2005 09:53:55 PDT Message-ID: <4280E721.9070509@parc.com> Date: Tue, 10 May 2005 09:53:53 PDT From: "D. K. Smetters" Organization: PARC User-Agent: Mozilla Thunderbird 1.0.2-1.3.2 (X11/20050324) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen Subject: Re: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt References: <2AB1DCE354761449A2E270681CC0429823CEDD@xmb-sjc-21c.amer.cisco.com> <427F7DB5.9010006@cisco.com> <17024.36255.386391.748558@fireball.kivinen.iki.fi> In-Reply-To: <17024.36255.386391.748558@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com, Yoav Nir , "Bora Akyol \(bora\)" , Paul Hoffman , Geoffrey Huang X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Tero Kivinen wrote: > Paul Hoffman writes: > >>Right, it really doesn't. And, it makes implementation harder. I >>support "do it in one place", and I think in the initial exchange >>makes the most sense. "I just decided I want you to reauthenticate" >>doesn't seem nearly as likely as "I know what my reauthentication >>rules are at the beginning". > The most common place I've seen this in practice is on a policy change on the server -- anything from new authentication requirements to a new CRL -- essentially "I've just changed my mind about what I need from you in order to trust you, and I need you to reauthenticate NOW". This is not a common event, but it is an important one. And as pointed out already, a forced reauth mechanism allows almost any complex reauthentication policy to be specified on the server. > That was the reason why we left out communcation of timers, lifetimes > etc in the IKEv2 in the first place. Why do we want to add it now? The basic reauth-interval mechanism seems the thing that will be most commonly used in practice. It also makes it possible to write clients that are easier to use (e.g. by scheduling an interactive authentication when the user is most likely to be there). It's nice, and seems worth including, but doesn't seem sufficient on its own. --Diana Smetters smetters@parc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 10 20:44:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVfKv-00009x-Pr; Tue, 10 May 2005 20:44:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVfKt-00009i-Nm for ipsec@megatron.ietf.org; Tue, 10 May 2005 20:44:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08320 for ; Tue, 10 May 2005 20:44:26 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVfaH-0002Zz-Hs for ipsec@ietf.org; Tue, 10 May 2005 21:00:24 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j4B0D9C25157; Tue, 10 May 2005 17:13:09 -0700 X-mProtect: <200505110013> Nokia Silicon Valley Messaging Protection Received: from manisht.iprg.nokia.com (205.226.2.40, claiming to be "[205.226.2.40]") by darkstar.iprg.nokia.com smtpdHCETzN; Tue, 10 May 2005 17:13:08 PDT Message-ID: <42815545.6000004@iprg.nokia.com> Date: Tue, 10 May 2005 17:43:49 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen Subject: Re: [Ipsec] Clarifications open issue: INTERNAL_IP4_SUBNET/NETMASK References: <17023.14429.474761.207509@fireball.kivinen.iki.fi> In-Reply-To: <17023.14429.474761.207509@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Tero Kivinen wrote: > Pasi.Eronen@nokia.com writes: > >>Isn't that information already sent in INTERNAL_IP6_ADDRESS >>attribute, in the "prefix length" field...? > > > When the initiator requests IPv6 address with INTERNAL_IP6_ADDRESS, he > already fills that field with the hint what address he would like to > have. > > If he had had address before then that address will be filled in > completely, as he would like to get same address back. okay. this is my understanding too. > If he has no > prefix to use, he can fill in the lower 64-bits to tell the server > which 64 lower bits to use for the address (i.e. fillin the interface > ID). The prefix length of the request most likely matches either the > previous prefix, or 64 in case initiator filled in lower 64 bits (or > prefix length matching the filled data). > > When the responder (server) gets the request it first checks if the > address specified is acceptable, and if so it will return that. > > If not he will replace the prefix length, and fill in the suitable > global routing prefix and subnet ID to be used for this connection. > Then it needs to check if the given IP-address is acceptable (i.e no > duplicate address already given out etc), and if so give it out. this can work, but is this specified anywhere in any spec? >>>I interpreted this in a different way for IPv6. IMO, the >>>INTERNAL_IP6_SUBNET attribute should contain the prefix that >>>corresponds to the IPv6 prefix from which the address >>>returned in the INTERNAL_IP6_ADDRESS attribute is configured >>>from. > > > I have not interpreted IKEv2 draft that way. INTERNAL_IP6_SUBNET is > specified to contain the "protected sub-networks that this edge-device > protects". That does not have anything to do with > INTERNAL_IP6_ADDRESS address allocation. Most commonly there is no > need to list the subnet where the address is allocated from in the > INTERNAL_IP6_SUBNET as it is already covered by the traffic selectors. > It could also be listed in the INTERNAL_IP6_SUBNET, but I do not think > that is necessary. okay. just wanted to see if my interpretation was correct. another question. the prefix from which the address configured through the INTERNAL_IP6_SUBNET is always part of the protected sub-networks, right? so that prefix is always returned by the responder? Vijay _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed May 11 06:41:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVoee-0002X1-Ep; Wed, 11 May 2005 06:41:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVoec-0002Wt-VM for ipsec@megatron.ietf.org; Wed, 11 May 2005 06:41:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21314 for ; Wed, 11 May 2005 06:41:23 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVou7-0006lu-2H for ipsec@ietf.org; Wed, 11 May 2005 06:57:28 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j4BAe8ZB002281 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 11 May 2005 13:40:08 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j4BAe4L4002278; Wed, 11 May 2005 13:40:04 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17025.57604.383671.440128@fireball.kivinen.iki.fi> Date: Wed, 11 May 2005 13:40:04 +0300 From: Tero Kivinen To: "Bora Akyol \(bora\)" Subject: RE: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt In-Reply-To: <2AB1DCE354761449A2E270681CC0429823D01B@xmb-sjc-21c.amer.cisco.com> References: <2AB1DCE354761449A2E270681CC0429823D01B@xmb-sjc-21c.amer.cisco.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 2 min X-Total-Time: 1 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Yoav Nir , Pasi.Eronen@nokia.com, "Geoff Huang \(ghuang\)" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Bora Akyol \(bora\) writes: > This is all nice and sound in theory, but in practice we know that the > encrypting gateways rarely talk to the end application and neither does > the vpn software running on the end host. The whole world is not a VPNs. There is end to end IPsec things. > So I suggest the KISS principle as being appropriate here. I agree, and the easiest is not to have any timers or so, simply a notify from server saying "Reauthenticate now". That way implementations can implement any logic they want to, even the time based one... -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed May 11 14:25:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVvtW-0007Kw-Pa; Wed, 11 May 2005 14:25:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVvtV-0007Kr-9g for ipsec@megatron.ietf.org; Wed, 11 May 2005 14:25:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00617 for ; Wed, 11 May 2005 14:25:15 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVw93-0006Nx-Hw for ipsec@ietf.org; Wed, 11 May 2005 14:41:22 -0400 Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4BIP1Tv021220; Wed, 11 May 2005 11:25:02 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <17025.57604.383671.440128@fireball.kivinen.iki.fi> References: <2AB1DCE354761449A2E270681CC0429823D01B@xmb-sjc-21c.amer.cisco.com> <17025.57604.383671.440128@fireball.kivinen.iki.fi> Date: Wed, 11 May 2005 11:24:59 -0700 To: Tero Kivinen , "Bora Akyol \(bora\)" From: Paul Hoffman Subject: RE: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com, Yoav Nir , "Geoff Huang \(ghuang\)" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 1:40 PM +0300 5/11/05, Tero Kivinen wrote: >I agree, and the easiest is not to have any timers or so, simply a >notify from server saying "Reauthenticate now". That way >implementations can implement any logic they want to, even the time >based one... I'm fine with that as well. It also matches our thinking about getting rid of the rekeying timers in IKEv2. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed May 11 14:34:22 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVw2I-0001OK-CU; Wed, 11 May 2005 14:34:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVw2G-0001OA-Li for ipsec@megatron.ietf.org; Wed, 11 May 2005 14:34:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03668 for ; Wed, 11 May 2005 14:34:18 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVwHp-00071o-2g for ipsec@ietf.org; Wed, 11 May 2005 14:50:26 -0400 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j4BIY22s002689; Wed, 11 May 2005 14:34:09 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 11 May 2005 13:50:43 -0400 To: Pekka Nikander From: Stephen Kent Subject: Re: [Ipsec] Small comments to rfc2401bis-06.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.8 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ipsec@ietf.org, Karen Seo X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 3:36 PM +0300 4/29/05, Pekka Nikander wrote: >Karen, > >I know rfc2401bis is quite far and that I am late in game, >but some small suggestions based on my fresh reading: > >On page 18, Section 4.4 > > The Mobility Header is first time mentioned in Section 4.4., > without any reference. The reference an explanation is only > in Section 4.4.1.1, several pages later. > > I found that surprising. I would suggest adding > some text wrt. Mobile IPv6 in Section 3.2, and perhaps also > explicitly mention ICMP there, too. At minimum, the informative > reference to [Mobip] should be normative, as it is referenced > in normative contexts. > >On page 23, Section 4.4.1.1 > > In the parenthesised sentence, there is a phrase ", as noted above". > However, I didn't find any explanation about how to use sockets > directly before that in the document; indeed, I found a corresponding > note in the beginning of page 24, and in more detail only on page 29, > in the end of 4.4.1.1. There is a further note on page 49, in Section 5. > Maybe these locations should be linked together better? > >I have a couple of other questions, but they are more to the WG >and I'll send them separately. > >--Pekka Nikander Sorry for not responding sooner, but I was away on vacation for two weeks, off on business travel, and then wading through a ton of e-mail. The IESG approved 2401bis and it is in the RFC Editor's queue. So, any changes we might make have to be very minor, editorial things. With those constraints in mind, we'll look at the text you cited and see if any changes can be made. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed May 11 14:34:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVw2J-0001Ok-2q; Wed, 11 May 2005 14:34:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVw2G-0001OC-Pn for ipsec@megatron.ietf.org; Wed, 11 May 2005 14:34:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03671 for ; Wed, 11 May 2005 14:34:19 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVwHp-00071p-4w for ipsec@ietf.org; Wed, 11 May 2005 14:50:26 -0400 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j4BIY22u002689; Wed, 11 May 2005 14:34:10 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <5dfcc9adb0e5a519ab5af5dc19ad82fb@nomadiclab.com> References: <5dfcc9adb0e5a519ab5af5dc19ad82fb@nomadiclab.com> Date: Wed, 11 May 2005 14:11:30 -0400 To: Pekka Nikander From: Stephen Kent Subject: Re: [Ipsec] rfc2401bis-06: why ESP and AH SPIs are not considered as (potential) selectors? Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 1.0 (+) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 3:43 PM +0300 4/29/05, Pekka Nikander wrote: >Folks, > >This has probably been discussed in the death before, but I was >not able to find the answer in the archives. Consequently, I'd >appreciate if someone would enlighten me, perhaps by pointing out >to the relevant thread of previous discussion. Please note too >that this question is more due to academic/architectural curiosity >rather than that I would be implementing this. > >Anyway, while reading rfc2401bis-06 with fresh eyes, I was left >wondering why aren't the AH and ESP SPI fields considered as >selectors, similar to TCP/UDP ports, ICMP types/codes, and MH >message types? Such support looks trivial to me (but perhaps >I am missing something), and would make supporting the (admittedly >dubious) nested SAs much easier. In other words, if my 2401bis >implementation would route back outgoing IPsec packets to the protected >side and then again out, then how do I select the right enclosing >SA for it unless I can use the SPI? Likewise, if I receive an >incoming packet that contains an AH or ESP header after IPsec >processing, how to I enforce anything on the SPIs before passing >it again out for nested processing? > >So, what is the reason for the current state? It is the stated intent of IPsec to offer simple, stateless firewall access control for traffic (see sections 2.1, 4.4.1, & 5). The selectors we defined years ago in 2401 match this intent. We augmented the list to accommodate ICMP type/code values and mobility header message types in 2401, to better accommodate handling of these packet types, but the concept is still the same. SPIs have no counterpart in firewall rules and thus do not match the firewall model. Also, IPsec does not require that the SPD be dynamic. Vendors are free to offer dynamic SPD management options in products, e.g., to better support protocols like FTP, but this is not mandated. 2401/bis notes that adding such functionality may cause interoperability problems, depending on what additional features are locally supported. Because SPI's generally are created dynamically, and because an SPI for an outbound SA is created by the peer, support for them would imply dynamic SPD management, inconsistent with the premises I mentioned above. You are correct that nesting requires an ability to configure a combination of SPD entries and forwarding table entries that will cause outbound and inbound packets to be "looped." We gave an example of an SPD configuration that supported nesting in an appendix that shows how one might accomplish this, and it did not require use of SPI's as traffic selectors. Use of SPIs as traffic selectors could facilitate nesting, if they were also used in the forwarding tables, but this would require dynamic SPD management. As to your last question, for a nested SA, after processing the outer layer of IPsec protection, the SA would be configured to require the next IPsec layer (e.g., AH or ESP), and would have port field selectors set to ANY. Then the plaintext side forwarding tables would have to be configured so that the now visible S/D addresses and the protocol called for bypass, vs. delivery to a higher layer protocol or to a host behind an SG. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed May 11 14:34:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVw2c-0001Qh-3X; Wed, 11 May 2005 14:34:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVw2Y-0001QP-Q6 for ipsec@megatron.ietf.org; Wed, 11 May 2005 14:34:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03709 for ; Wed, 11 May 2005 14:34:37 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVwI8-00072B-7j for ipsec@ietf.org; Wed, 11 May 2005 14:50:44 -0400 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j4BIY22w002689; Wed, 11 May 2005 14:34:29 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 11 May 2005 14:34:01 -0400 To: Pekka Nikander , ipsec@ietf.org, "Discussions of anonymous Internet security." From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: ipsec@ietf.org, BTNS WG ML Subject: [Ipsec] Re: [anonsec] rfc2401bis-06: Why there are no names in SAs? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 3:57 PM +0300 4/29/05, Pekka Nikander wrote: >[Excuse for cross-posting; followups to ipsec only.] > >Folks, > >While reading rfc2401bis-06 for considering BTNS, I came up >with one serious architectural question. At this point of time >I don't know if this really relates to BTNS or not, but it seems >to have some larger relevance in any case. > >The essence of this question boils down to the nature of IP >addresses. While reading rfc2401bis, it becomes apparent that >it is very much build around the model that the IP addresses >used by different hosts are considered to be stable, or at least >divisible into different security classes in a static manner. >While that may be fine for most if not all current purposes of >IPsec, I am afraid that the Internet in general is moving away >from that notion. The SPD initially supported static IP addresses well, and names only minimally, via ambiguous wording in 2401. This was motivated by the fact that we knew how to deal with addresses well, and we did not have a clear picture how to handle names. >However, in addition to the selectors based on this world view, >the SPD and PAD also have now support for "names", mainly >meant to be used in situations where at least one of the IPsec >devices is an end-host (rather than a security gateway). The >support for these higher-layer, symbolic identifiers seems to >be sufficient for key management and outgoing traffic. What >seems to be especially good is the use of names in linking PAD >and SPD entries together (end of section 4.4.3.4). it is not true that we assume that one end of an SA is a host when names are used in lieu of addresses for both ends. However, it is fair to say that the primary motivation for supporting names was road warriors, even in 2401. 2401 lacked a description of how key management (e.g., IKE) and the SPD were to be linked. This was an oversight, caused by the fact that two different groups of folks worked on each set of documents and there was a rush to get the documents out at the end of the process. In 2401bis we addressed this linkage, motivated in part by the ongoing work in the pki4ipsec WG. The PAD is needed whether we use symbolic names or static IP addresses to identify peers. In either case there has to be a way to express the notion of what set of IDs is a peer authorized to represent. These IDs can be names or IP addresses, depending on how we will match the ID against the SPD. We considered additional uses for names in the PAD, and rejected them due to complexity arguments. For example, an SG might have symbolic names for source addresses for hosts behind it, but then it would have to have a secure way to link the names to the addresses it sees in packets. Given the lack of DNSSEC deployment, DHCP security, etc, we didn't think it was appropriate to mention this sort of functionality. >What seems to be missing is support for incoming traffic. All inbound protected traffic arrives via an SA, and the creation of the SA is the time at which we deal with ID and authorization issues. >More specifically, what I am missing is either > > a) names embedded in (inbound) SAD entries, or The data in an (inbound) SAD entry is used to manage the processing of the arriving packet. Since an IP packet carries addresses, but not names, it does not seem appropriate to put a name in an SAD entry. > b) back pointers from (inbound) SAD entries to > corresponding SPD entries in 2401 we talked about the need to examine the SPD to match received traffic against the selectors associated with an SA. This was one of the most complex aspects of inbound traffic processing, the one that generated the most questions. 2401bis adopted a decorrelated SPD in part to avoid this complexity, and as a result did away with any need to provide a back pointer to the SPD for either inbound or outbound SAD entries. >If either of them were in place, that would allow incoming >packets to be tagged with names. Those names could then, >optionally, be available to apps above. In a host environment this is true, but is is not meaningful for an SG. Might there not be other ways to offer these names to an app? Also, in the absence of an API, it's hard to decide where one might maintain this info, to make it available. >Furthermore, and probably more importantly, tagging >the SAs with names would make it also easier to handle >with potential stale SAs as the SPD is dynamically >changed. In my response to your message about why we do not use SPIs as selectors, I noted that the SPD is not assumed to be dynamic. So, when one starts to talk about dynamic SPD changes, one is moving away from the base IPsec model. One might choose to do this, but the IPsec WG avoided embracing this sort of complexity for many years, so one should be careful when considering such a fundamental change. >Now, is there a specific reason why the (inbound) SAD >entries are not tagged/linked with their corresponding >SPD entries? As noted above, the SAD has no need for such links, now that decorrelation is a fundamental aspect of the processing model. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed May 11 15:39:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVx3l-0007sz-5i; Wed, 11 May 2005 15:39:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVx3j-0007rr-3A for ipsec@megatron.ietf.org; Wed, 11 May 2005 15:39:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12782 for ; Wed, 11 May 2005 15:39:52 -0400 (EDT) Received: from ns.ca.certicom.com ([66.48.18.197] helo=mail.ca.certicom.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DVxJH-0002Hc-2S for ipsec@ietf.org; Wed, 11 May 2005 15:56:00 -0400 Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 421B2100EC for ; Wed, 11 May 2005 15:39:33 -0400 (EDT) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00937-65 for ; Wed, 11 May 2005 15:39:22 -0400 (EDT) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 0787310090 for ; Wed, 11 May 2005 15:39:22 -0400 (EDT) To: ipsec@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Tom Stiemerling Date: Wed, 11 May 2005 15:39:00 -0400 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 05/11/2005 03:39:02 PM, Serialize complete at 05/11/2005 03:39:02 PM X-Spam-Score: 0.5 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Ipsec] Question about delete IKE SA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1885644976==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============1885644976== Content-Type: multipart/alternative; boundary="=_alternative 006C0B3E85256FFE_=" This is a multipart message in MIME format. --=_alternative 006C0B3E85256FFE_= Content-Type: text/plain; charset="US-ASCII" Can anybody provide a definitive answer about whether a delete IKE SA payload needs to be replied to with another delete IKE SA payload, or whether an empty INFORM response is sufficient to acknowledge the delete? Thanks, Tom Stiemerling Senior Software Developer Certicom Corp. Tel: 905 501 6087 http://www.certicom.com/ --=_alternative 006C0B3E85256FFE_= Content-Type: text/html; charset="US-ASCII"
Can anybody provide a definitive answer about whether a delete IKE SA
payload needs to be replied to with another delete IKE SA payload, or
whether an empty INFORM response is sufficient to acknowledge the
delete?

Thanks,

Tom Stiemerling
Senior Software Developer
Certicom Corp.
Tel: 905 501 6087
http://www.certicom.com/ --=_alternative 006C0B3E85256FFE_=-- --===============1885644976== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1885644976==-- From ipsec-bounces@ietf.org Wed May 11 15:55:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVxIm-0003J8-Sl; Wed, 11 May 2005 15:55:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DVxIk-0003HT-Sp for ipsec@megatron.ietf.org; Wed, 11 May 2005 15:55:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14462 for ; Wed, 11 May 2005 15:55:21 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DVxYG-0003Kg-Jj for ipsec@ietf.org; Wed, 11 May 2005 16:11:29 -0400 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-1.cisco.com with ESMTP; 11 May 2005 12:55:12 -0700 X-IronPort-AV: i="3.93,96,1115017200"; d="scan'208"; a="635653194:sNHT32112312" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j4BJt5Po017170; Wed, 11 May 2005 12:55:05 -0700 (PDT) Received: from [10.32.227.24] ([10.32.227.24]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id BEO23767; Wed, 11 May 2005 12:55:04 -0700 (PDT) Message-ID: <4282629A.8020306@cisco.com> Date: Wed, 11 May 2005 12:52:58 -0700 From: Geoffrey Huang User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050408) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Stiemerling Subject: Re: [Ipsec] Question about delete IKE SA References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Tom, Look at section 1.4 of the IKEv2 draft. Your answer is "normally" :-). Actually, this text seems to be referring to deletion of IPSec SAs. For IKE SAs, really the only thing that you need to acknowledge any request is a response that matches the request's message ID. Also from 1.4: "That response MAY be a message with no payloads." -g Tom Stiemerling wrote: > > Can anybody provide a definitive answer about whether a delete IKE SA > payload needs to be replied to with another delete IKE SA payload, or > whether an empty INFORM response is sufficient to acknowledge the > delete? > > Thanks, > > Tom Stiemerling > Senior Software Developer > Certicom Corp. > Tel: 905 501 6087 > http://www.certicom.com/ > > > ------------------------------------------------------------------------ > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu May 12 04:34:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW99d-0008Va-Oy; Thu, 12 May 2005 04:34:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW99b-0008V1-7f for ipsec@megatron.ietf.org; Thu, 12 May 2005 04:34:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05307 for ; Thu, 12 May 2005 04:34:45 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW9PG-0001c0-Nr for ipsec@ietf.org; Thu, 12 May 2005 04:51:00 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j4C8Wc6f016934 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 12 May 2005 11:32:39 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j4C8Wa8E016931; Thu, 12 May 2005 11:32:36 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17027.5284.686030.287291@fireball.kivinen.iki.fi> Date: Thu, 12 May 2005 11:32:36 +0300 From: Tero Kivinen To: Yoav Nir Subject: Re: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt In-Reply-To: <0991f64d9c1f49a4a31bec877848aa8d@netvision.net.il> References: <2AB1DCE354761449A2E270681CC0429823D01B@xmb-sjc-21c.amer.cisco.com> <17025.57604.383671.440128@fireball.kivinen.iki.fi> <0991f64d9c1f49a4a31bec877848aa8d@netvision.net.il> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 9 min X-Total-Time: 11 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: ipsec , Bora Akyol , Pasi Eronen , Paul Hoffman , Geoff Huang X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Yoav Nir writes: > And so much for a rough consensus. In practice, the only requirement > that I've ever seen was to repeat the authentication periodically. > Once you have a "period", you want to display it to the user like in a > countdown timer. You also want to ask for credentials in plenty of > time, where "plenty" can have different meanings depending on whether > the authentication method is a certificate in the computer, a > certificate in a token, a token card, a scratch list or a remembered > password. "Plenty" can also have different meanings for a 20-year-old > as opposed to a 70-year-old or people with disabilities. These are > clearly Initiator-side decisions, not something for the Responder to > decide. As I have not used that kind of system, can you tell me what are the estimated values for timers. I mean how often do they require reauthentication. Every 5 minutes? Every 15 minutes? Every hour? Every 24 hours? And can you also explain what is the reasoning behind this reauthentication, i.e. what is the expected benefit from it. It cannot be for revocation checking, as there is much easier ways to do that (i.e. reload for example CRL every time new one comes, and check that all current SAs are still authenticated). It cannot be used for detecting users moving away from keyboard, as the required time frame there would be way too small to be practical (unless the authentication is based on the automatic token, but then on the other hand it is easier for the client to remove the SAs when token is removed). So what is the reasoning behind this feature. It would make easier to talk about this. The draft says "The purpose of this is to limit the time that SAs can be used by a third party who has gained control of the IPsec peer." Can you give some concrete examples. > That's why "reauthenticate now" is not good enough. "Reauthenticate > within 3 minutes" is better, although it doesn't allow for a countdown > timer, and again requires the Responder to decide what "plenty" is. Actually if we use the third party checking argument giving any timer is bad, as then attacker can see the timer, so he knows how much time he has to finish the attack. If the reauthentication requests come in random intervals, or every time the server suspects something (i.e. if the access pattern changes) then it can make the time attacker can use much shorter. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu May 12 04:49:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW9Nl-0003lt-2t; Thu, 12 May 2005 04:49:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW9Ni-0003ll-2A for ipsec@megatron.ietf.org; Thu, 12 May 2005 04:49:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06562 for ; Thu, 12 May 2005 04:49:20 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DW9dO-0002CM-Tx for ipsec@ietf.org; Thu, 12 May 2005 05:05:35 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j4C8nFwe017014 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 12 May 2005 11:49:16 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j4C8nAhT017011; Thu, 12 May 2005 11:49:10 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17027.6278.574861.913394@fireball.kivinen.iki.fi> Date: Thu, 12 May 2005 11:49:10 +0300 From: Tero Kivinen To: Tom Stiemerling Subject: [Ipsec] Question about delete IKE SA In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 8 min X-Total-Time: 8 min X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Tom Stiemerling writes: > Can anybody provide a definitive answer about whether a delete IKE SA > payload needs to be replied to with another delete IKE SA payload, or > whether an empty INFORM response is sufficient to acknowledge the > delete? As the IKE SA is bidirectional and there is no way to delete it only in one direction, I would say no need to add another delete IKE SA payload to the reply packet. The IKE SA delete payload does NOT contain SPI at all, it only has Protocol ID of 1 for IKE SA, and SPI size of zero, so there is no way to delete any other IKE SA than the current one. Thus after the any reply is received from the other end the IKE SA is deleted, thus empty acknowledge response is enough to finish the exchange. So do not send delete payload in the reply packet, but accept the reply packet even if the other end added a delete payload there. The document itself does not explicitly specify anything for this case (Note that replying with SPIs is NOT MANDATORY even for the IPsec SAs). The text explaining how to reply with the deletes to other direction, clearly cannot be used for the IKE SAs as there is no SPIs to be included in the delete payload. Also the paragrap starts with saying "ESP and AH SAs always exist in pairs, with one SA in each direction...." -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu May 12 05:17:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW9ol-0001M8-0X; Thu, 12 May 2005 05:17:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DW9oi-0001M0-LM for ipsec@megatron.ietf.org; Thu, 12 May 2005 05:17:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08189 for ; Thu, 12 May 2005 05:17:14 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWA4O-0003BI-Ow for ipsec@ietf.org; Thu, 12 May 2005 05:33:30 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4C9FhoT022899; Thu, 12 May 2005 12:15:44 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 May 2005 12:17:13 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 May 2005 12:17:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt Date: Thu, 12 May 2005 12:17:11 +0300 Message-ID: Thread-Topic: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt Thread-Index: AcVWW8DV9KSaPW9AS32dwZYwb5AEGwAddcqw To: , X-OriginalArrivalTime: 12 May 2005 09:17:13.0253 (UTC) FILETIME=[62054D50:01C556D3] X-Spam-Score: 0.3 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org BTW, since this is your individual draft rather than a=20 working group item, we don't have to get rough consensus=20 on it. Several people have expressed that they think it's useful to have both "reauth in 3600 seconds" and "reauth now" functionality. Many existing VPN products also have both. We don't have to get everyone to agree that this is a useful feature, because those who think it isn't can just not implement it...=20 Best regards, Pasi > -----Original Message----- > From: ynir@netvision.net.il > Sent: Wednesday, May 11, 2005 9:59 PM > To: Paul Hoffman > Cc: Eronen Pasi (Nokia-NRC/Helsinki); Tero Kivinen; ipsec;=20 > Geoff Huang; Bora Akyol > Subject: Re: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt >=20 > And so much for a rough consensus. In practice, the only > requirement that I've ever seen was to repeat the > authentication periodically. Once you have a "period", you > want to display it to the user like in a countdown timer. You > also want to ask for credentials in plenty of time, where > "plenty" can have different meanings depending on whether the > authentication method is a certificate in the computer, a > certificate in a token, a token card, a scratch list or a > remembered password. "Plenty" can also have different > meanings for a 20-year-old as opposed to a 70-year-old or > people with disabilities. These are clearly Initiator-side > decisions, not something for the Responder to decide. >=20 > That's why "reauthenticate now" is not good > enough. "Reauthenticate within 3 minutes" is better, although > it doesn't allow for a countdown timer, and again requires the > Responder to decide what "plenty" is. =20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu May 12 05:57:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWARa-0000eh-0X; Thu, 12 May 2005 05:57:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWARY-0000bc-ET for ipsec@megatron.ietf.org; Thu, 12 May 2005 05:57:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10407 for ; Thu, 12 May 2005 05:57:22 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWAhE-0004aw-St for ipsec@ietf.org; Thu, 12 May 2005 06:13:38 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4C9vDcO002288; Thu, 12 May 2005 12:57:21 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 May 2005 12:57:21 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 12 May 2005 12:57:20 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt Date: Thu, 12 May 2005 12:57:19 +0300 Message-ID: Thread-Topic: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt Thread-Index: AcVWzceq+ngqOgQxQc6X7z5ujdwV+AAAfLjw To: , X-OriginalArrivalTime: 12 May 2005 09:57:20.0894 (UTC) FILETIME=[FD1629E0:01C556D8] X-Spam-Score: 0.3 (/) X-Scan-Signature: 02ec665d00de228c50c93ed6b5e4fc1a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Tero Kivinen writes: >=20 > As I have not used that kind of system, can you tell me what > are the estimated values for timers. I mean how often do they > require reauthentication. Every 5 minutes? Every 15 minutes? > Every hour? Every 24 hours? >=20 > And can you also explain what is the reasoning behind this > reauthentication, i.e. what is the expected benefit from it. > > It cannot be for revocation checking, as there is much easier > ways to do that (i.e. reload for example CRL every time new > one comes, and check that all current SAs are still > authenticated). > > It cannot be used for detecting users moving away from > keyboard, as the required time frame there would be way too > small to be practical (unless the authentication is based on > the automatic token, but then on the other hand it is easier > for the client to remove the SAs when token is removed). >=20 > So what is the reasoning behind this feature. It would make > easier to talk about this. The draft says "The purpose of this > is to limit the time that SAs can be used by a third party who > has gained control of the IPsec peer." > > Can you give some concrete examples. In one system that I have used, you need to enter the code=20 from your SecurID token every four hours. In another one,=20 the interval was ten hours. The reasoning is the same as reauthentication in other places, managing risk by reducing time-of-check to time-of-use. For example, if I once open VPN connection from some machine, the connection won't stay open forever (potentially for months or years, depending on how often your PC crashes :-). The=20 risks we're trying to manage might involve a malicious third=20 party gaining control over the laptop (or something), a third=20 party accidentally using the connection for something, the user=20 losing the token (and not noticing it because the system does=20 not require it), the user forgetting that he/she has the=20 connection open, etc. (And no, reauthentication alone does not _solve_ any of these problems, but it does help in managing the risks in many cases.) For some types of hardware tokens (like SIM card in a phone) it's of course easy to close the connection when the token is removed. But for authentication that requires user interaction, doing it "every now and then" is often a reasonable compromise with usability (and often better than never doing reauthentication at all). (Of course, here one size doesn't fit all; each environment is different, and IT administrators/whoever should be able to decide for themselves whether reauthentication is necessary and how long the interval should be.) Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu May 12 10:37:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWEor-0000fk-SK; Thu, 12 May 2005 10:37:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DWEop-0000fX-Kw for ipsec@megatron.ietf.org; Thu, 12 May 2005 10:37:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29397 for ; Thu, 12 May 2005 10:37:41 -0400 (EDT) Received: from mxout5.netvision.net.il ([194.90.9.29]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DWF4Y-0003PT-50 for ipsec@ietf.org; Thu, 12 May 2005 10:53:59 -0400 Received: from [192.168.0.70] ([217.132.96.86]) by mxout5.netvision.net.il (Sun Java System Messaging Server 6.1 HotFix 0.11 (built Jan 28 2005)) with ESMTP id <0IGD00LM4SMI3NB0@mxout5.netvision.net.il> for ipsec@ietf.org; Thu, 12 May 2005 17:37:31 +0300 (IDT) Date: Thu, 12 May 2005 17:37:30 +0300 From: Yoav Nir Subject: Re: [Ipsec] Fwd: I-D ACTION:draft-nir-ikev2-auth-lt-02.txt In-reply-to: To: Pasi.Eronen@nokia.com Message-id: MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: X-Spam-Score: 4.0 (++++) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7BIT Cc: ipsec@ietf.org, kivinen@iki.fi X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org It's often not up to the IT administrator. In many cases the security policy is dictated by some regulatory agency. This is very common in financial institutions in Europe. There is a government agency that publishes a security policy that all financial institutions must follow. These usually include algorithms (3DES and SHA-1 are nearly universal for such things) as well as encryption key timeouts and authentication timeouts. The times I usually see are from as little as 1 hour to as much as 24 hours. 2 hours is probably the median. On May 12, 2005, at 12:57 PM, Pasi.Eronen@nokia.com wrote: > (Of course, here one size doesn't fit all; each environment > is different, and IT administrators/whoever should be able > to decide for themselves whether reauthentication is necessary > and how long the interval should be.) > > Best regards, > Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 17 00:34:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXtmT-0008Gd-QR; Tue, 17 May 2005 00:34:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXtmS-0008GY-1d for ipsec@megatron.ietf.org; Tue, 17 May 2005 00:34:08 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13129 for ; Tue, 17 May 2005 00:34:04 -0400 (EDT) Received: from inet-tsb5.toshiba.co.jp ([202.33.96.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXu2y-0002zf-1G for ipsec@ietf.org; Tue, 17 May 2005 00:51:22 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb5.toshiba.co.jp with ESMTP id j4H4Vnnf029188; Tue, 17 May 2005 13:32:50 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id j4H4Vigu015905; Tue, 17 May 2005 13:31:44 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id PAA15179 ; Tue, 17 May 2005 13:31:43 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id j4H4VS9p018583; Tue, 17 May 2005 13:31:28 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id j4H4VIBh000196; Tue, 17 May 2005 13:31:20 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id j4H4VHu6002781; Tue, 17 May 2005 13:31:17 +0900 (JST) Received: from steelhead (iVPN11-057.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0IGM00D0G9V8LQ@tsbpo1.po.toshiba.co.jp>; Tue, 17 May 2005 13:31:10 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1DXteS-00035i-00; Mon, 16 May 2005 21:25:52 -0700 Date: Tue, 17 May 2005 00:25:48 -0400 From: Yoshihiro Ohba To: ipsec@ietf.org Message-id: <20050517042548.GB11712@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.9i X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Ipsec] configuration payload usage X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I have the following questions about the usage of Configuration Payload (CP). - When two (or more) IPsec SAs are to be established under a single IKE_SA, does IKEv2 allow the first IPsec SA to be established with CP exchange in IKE_AUTH exchange, but the configuration parameters (e.g., an IPv6 prefix) carried in the CP is used by the second IPsec SA for e.g., an initiator to auto-configure an IPsec tunnel inner address by combining the assigned IPv6 prefix with its own interface ID? - Maybe the first question is confusing, so more general question would be: Does IKEv2 allow an initiator's inner address to be auto-configured by combining an IPv6 prefix carried in CP with an initiator's interface ID? If yes, how? This general question is not only for the case where there are two (or more) IPsec SAs but also for the case where there is only one IPsec SA. Note that an assumption in the above questions is that the initiator does not even know the prefix length before running IKEv2. Best regards, Yoshihiro Ohba _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 17 02:56:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXw0T-0008Q7-T5; Tue, 17 May 2005 02:56:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXw0R-0008Py-8j for ipsec@megatron.ietf.org; Tue, 17 May 2005 02:56:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA15452 for ; Tue, 17 May 2005 02:56:41 -0400 (EDT) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DXwH7-0001yf-DP for ipsec@ietf.org; Tue, 17 May 2005 03:13:58 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id j4H6uUnP029119; Tue, 17 May 2005 09:56:31 +0300 (IDT) In-Reply-To: <20050517042548.GB11712@steelhead> References: <20050517042548.GB11712@steelhead> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <1dc70207ce8df6bb66d53ddb422c58c1@checkpoint.com> Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] configuration payload usage Date: Tue, 17 May 2005 09:56:31 +0300 To: Yoshihiro Ohba X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org The way I read the draft, CP is orthogonal to traffic selectors. It does make sense to use the assigned IP address in the traffic selectors of all Child SAs, but the protocol does not dictate this in any way. It is perfectly acceptable (by the protocol) for the Responder to assign an IP address to the Initiator, and then for the initiator to establish Child SAs with traffic selectors that are different from the assigned IP address. So IMHO the answer to your questions is yes. Specific implementations may of course have a policy to not allow this. Yoav On May 17, 2005, at 7:25 AM, Yoshihiro Ohba wrote: > I have the following questions about the usage of Configuration > Payload (CP). > > - When two (or more) IPsec SAs are to be established under a single > IKE_SA, does IKEv2 allow the first IPsec SA to be established with CP > exchange in IKE_AUTH exchange, but the configuration parameters (e.g., > an IPv6 prefix) carried in the CP is used by the second IPsec SA for > e.g., an initiator to auto-configure an IPsec tunnel inner address by > combining the assigned IPv6 prefix with its own interface ID? > > - Maybe the first question is confusing, so more general question > would be: Does IKEv2 allow an initiator's inner address to be > auto-configured by combining an IPv6 prefix carried in CP with an > initiator's interface ID? If yes, how? This general question is not > only for the case where there are two (or more) IPsec SAs but also for > the case where there is only one IPsec SA. > > Note that an assumption in the above questions is that the initiator > does not even know the prefix length before running IKEv2. > > Best regards, > Yoshihiro Ohba > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 17 06:58:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXzmJ-0007PT-KW; Tue, 17 May 2005 06:58:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXzmH-0007PO-VW for ipsec@megatron.ietf.org; Tue, 17 May 2005 06:58:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07618 for ; Tue, 17 May 2005 06:58:18 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY030-0006Vp-U8 for ipsec@ietf.org; Tue, 17 May 2005 07:15:39 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j4HAwGus018054 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 17 May 2005 13:58:17 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j4HAwEGJ018050; Tue, 17 May 2005 13:58:14 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17033.52806.275563.213358@fireball.kivinen.iki.fi> Date: Tue, 17 May 2005 13:58:14 +0300 From: Tero Kivinen To: Yoshihiro Ohba Subject: [Ipsec] configuration payload usage In-Reply-To: <20050517042548.GB11712@steelhead> References: <20050517042548.GB11712@steelhead> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 14 min X-Total-Time: 15 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 0fa76816851382eb71b0a882ccdc29ac Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Yoshihiro Ohba writes: > - When two (or more) IPsec SAs are to be established under a single > IKE_SA, does IKEv2 allow the first IPsec SA to be established with CP > exchange in IKE_AUTH exchange, but the configuration parameters (e.g., > an IPv6 prefix) carried in the CP is used by the second IPsec SA for > e.g., an initiator to auto-configure an IPsec tunnel inner address by > combining the assigned IPv6 prefix with its own interface ID? Yes, and no. CP does not send IPv6 prefix, it sends full IPv6 addresses. On the other hand it is completely valid for the responder to send both IPv4 and IPv6 address inside the CP payload to the initiator, but create the IPsec SA only for the IPv4 address. And then initiator can create new IPsec SA for the IPv6 address it received from the responder. I.e. HDR, SAi1, KEi, Ni -> <-- HDR, SAr1, KEr, Nr HDR, SK { IDi, AUTH, CP(CFG_REQUEST), SAi2, TSi1, TSr1 } --> <-- HDR, SK { IDr,AUTH, CP(CFG_REPLY), SAr2, TSi2, TSr2} where the CP(CFG_REQUEST) = INTERNAL_IP4_ADDRESS(0.0.0.0), INTERNAL_IP6_ADDRESS(::2d0:b7ff:fe83:21a0), TSi1 = (0, 0-65535, 0.0.0.0 - 255.255.255.255) TSi1 = (0, 0-65535, 0.0.0.0 - 255.255.255.255) and the replies will be: CP(CFG_REPLY) = INTERNAL_IP4_ADDRESS(192.0.2.202), INTERNAL_IP6_ADDRESS(2001:4f8:4:7:2d0:b7ff:fe83:21a0), Tsi2 = (0, 0-65535, 192.0.2.202 - 192.0.2.202) Tsr2 = (0, 0-65535, 192.0.2.0 - 192.0.2.255) Then the client can do CREATE_CHILD_SA: HDR, SK{ SA, Ni, TSi3, TSr3} --> <-- HDR, SK{ SA, Nr, TSi4, TSr4} where TSi3 = (0, 0-65535, 2001:4f8:4:7:2d0:b7ff:fe83:21a0 - 2001:4f8:4:7:2d0:b7ff:fe83:21a0) TSr3 = (0, 0-65535, :: - ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff) TSi4 = (0, 0-65535, 2001:4f8:4:7:2d0:b7ff:fe83:21a0 - 2001:4f8:4:7:2d0:b7ff:fe83:21a0) TSr4 = (0, 0-65535, 2001:4f8:4:7:: - 2001:4f8:4:7:ffff:ffff:ffff:ffff) and so on. > - Maybe the first question is confusing, so more general question > would be: Does IKEv2 allow an initiator's inner address to be > auto-configured by combining an IPv6 prefix carried in CP with an > initiator's interface ID? If yes, how? This general question is not > only for the case where there are two (or more) IPsec SAs but also for > the case where there is only one IPsec SA. The CP payload does not send prefix, but instead full IPv6 address. The initiator can request INTERNAL_IP6_ADDRESS so that it fills in the address it wants to get. The server will then mostly likely replace the prefix part to be suitable for him, but keep the interface ID of the address it returns. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 17 07:02:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXzqa-0007wT-E3; Tue, 17 May 2005 07:02:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DXzqY-0007w5-SG for ipsec@megatron.ietf.org; Tue, 17 May 2005 07:02:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA08039 for ; Tue, 17 May 2005 07:02:43 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DY07I-0006o9-2r for ipsec@ietf.org; Tue, 17 May 2005 07:20:04 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j4HB2aug018219 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 17 May 2005 14:02:41 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j4HB2Ud1018216; Tue, 17 May 2005 14:02:30 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17033.53062.323009.33635@fireball.kivinen.iki.fi> Date: Tue, 17 May 2005 14:02:30 +0300 From: Tero Kivinen To: Charlie Kaufman X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 4 min X-Total-Time: 4 min X-Spam-Score: 0.3 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org Subject: [Ipsec] Another typo in the draft-ietf-ipsec-ikev2-17.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org When reading the section 2.19 I noticed two small typos there. Firstly the TSi/TSr examples have port number ranges of 0-65536, and they should be 0-65535 instead. Secondly perhaps it should use INTERNAL_IP4_ADDRESS / INTERNAL_IP4_NETMASK / INTERNAL_IP4_DNS instead of INTERNAL_ADDRESS / INTERNAL_NETMASK / INTERNAL_DNS, and write that in the paragrap explaining things as "INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS attribute". -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed May 18 00:18:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYG1D-0003WC-TY; Wed, 18 May 2005 00:18:51 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYG1B-0003W7-M1 for ipsec@megatron.ietf.org; Wed, 18 May 2005 00:18:49 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23567 for ; Wed, 18 May 2005 00:18:45 -0400 (EDT) Received: from inet-tsb5.toshiba.co.jp ([202.33.96.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYGI2-0000KU-Gv for ipsec@ietf.org; Wed, 18 May 2005 00:36:16 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb5.toshiba.co.jp with ESMTP id j4I4IRnf015171; Wed, 18 May 2005 13:18:27 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id j4I4IS6N028056; Wed, 18 May 2005 13:18:28 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id PAA28053 ; Wed, 18 May 2005 13:18:28 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id j4I4IRQC011343; Wed, 18 May 2005 13:18:27 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id j4I4IMe0026778; Wed, 18 May 2005 13:18:22 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id j4I4IMu6026844; Wed, 18 May 2005 13:18:22 +0900 (JST) Received: from steelhead (iVPN11-193.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0IGO00ALI3WWIU@tsbpo1.po.toshiba.co.jp>; Wed, 18 May 2005 13:18:15 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1DYFwe-0003SM-00; Tue, 17 May 2005 21:14:08 -0700 Date: Wed, 18 May 2005 00:14:05 -0400 From: Yoshihiro Ohba Subject: Re: [Ipsec] configuration payload usage In-reply-to: <1dc70207ce8df6bb66d53ddb422c58c1@checkpoint.com> To: Yoav Nir Message-id: <20050518041405.GH11712@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.9i References: <20050517042548.GB11712@steelhead> <1dc70207ce8df6bb66d53ddb422c58c1@checkpoint.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Cc: ipsec@ietf.org, Yoshihiro Ohba X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Thanks for the reponse. It is a great news for me to know that CP and traffic selectors are orthogonal. BTW, another question has came up by reading your response: - Does IKEv2 also allow CP to be carried not only in IKE_AUTH exchange but also in CREATE_CHILD_SA exchange, i.e., a distinct CP exchange to be performed per CHILD_SA pair? Regards, Yoshihiro Ohba On Tue, May 17, 2005 at 09:56:31AM +0300, Yoav Nir wrote: > The way I read the draft, CP is orthogonal to traffic selectors. It > does make sense to use the assigned IP address in the traffic selectors > of all Child SAs, but the protocol does not dictate this in any way. > > It is perfectly acceptable (by the protocol) for the Responder to > assign an IP address to the Initiator, and then for the initiator to > establish Child SAs with traffic selectors that are different from the > assigned IP address. > > So IMHO the answer to your questions is yes. Specific implementations > may of course have a policy to not allow this. > > Yoav > > On May 17, 2005, at 7:25 AM, Yoshihiro Ohba wrote: > > >I have the following questions about the usage of Configuration > >Payload (CP). > > > >- When two (or more) IPsec SAs are to be established under a single > >IKE_SA, does IKEv2 allow the first IPsec SA to be established with CP > >exchange in IKE_AUTH exchange, but the configuration parameters (e.g., > >an IPv6 prefix) carried in the CP is used by the second IPsec SA for > >e.g., an initiator to auto-configure an IPsec tunnel inner address by > >combining the assigned IPv6 prefix with its own interface ID? > > > >- Maybe the first question is confusing, so more general question > >would be: Does IKEv2 allow an initiator's inner address to be > >auto-configured by combining an IPv6 prefix carried in CP with an > >initiator's interface ID? If yes, how? This general question is not > >only for the case where there are two (or more) IPsec SAs but also for > >the case where there is only one IPsec SA. > > > >Note that an assumption in the above questions is that the initiator > >does not even know the prefix length before running IKEv2. > > > >Best regards, > >Yoshihiro Ohba > > > >_______________________________________________ > >Ipsec mailing list > >Ipsec@ietf.org > >https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed May 18 00:28:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYGA7-0007Oo-IM; Wed, 18 May 2005 00:28:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYGA4-0007Of-E3 for ipsec@megatron.ietf.org; Wed, 18 May 2005 00:28:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24240 for ; Wed, 18 May 2005 00:27:57 -0400 (EDT) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYGQw-0000ot-1S for ipsec@ietf.org; Wed, 18 May 2005 00:45:27 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id j4I4RinP007602; Wed, 18 May 2005 07:27:44 +0300 (IDT) In-Reply-To: <20050518041405.GH11712@steelhead> References: <20050517042548.GB11712@steelhead> <1dc70207ce8df6bb66d53ddb422c58c1@checkpoint.com> <20050518041405.GH11712@steelhead> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] configuration payload usage Date: Wed, 18 May 2005 07:27:43 +0300 To: Yoshihiro Ohba X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Since they are orthogonal, there is no point in doing this in the CREATE_CHILD_SA. It can be done is a separate Informational exchange. This may be necessary if you use the INTERNAL_ADDRESS_EXPIRY attribute that says that the address expires after some time. If the Responder uses that, then after some time the Initiator needs to renew the address with a new CFG payload carried in an Informational exchange. On May 18, 2005, at 7:14 AM, Yoshihiro Ohba wrote: > Thanks for the reponse. It is a great news for me to know that CP and > traffic selectors are orthogonal. > > BTW, another question has came up by reading your response: > > - Does IKEv2 also allow CP to be carried not only in IKE_AUTH exchange > but also in CREATE_CHILD_SA exchange, i.e., a distinct CP exchange to > be performed per CHILD_SA pair? > > Regards, > Yoshihiro Ohba > > On Tue, May 17, 2005 at 09:56:31AM +0300, Yoav Nir wrote: >> The way I read the draft, CP is orthogonal to traffic selectors. It >> does make sense to use the assigned IP address in the traffic >> selectors >> of all Child SAs, but the protocol does not dictate this in any way. >> >> It is perfectly acceptable (by the protocol) for the Responder to >> assign an IP address to the Initiator, and then for the initiator to >> establish Child SAs with traffic selectors that are different from the >> assigned IP address. >> >> So IMHO the answer to your questions is yes. Specific implementations >> may of course have a policy to not allow this. >> >> Yoav >> >> On May 17, 2005, at 7:25 AM, Yoshihiro Ohba wrote: >> >>> I have the following questions about the usage of Configuration >>> Payload (CP). >>> >>> - When two (or more) IPsec SAs are to be established under a single >>> IKE_SA, does IKEv2 allow the first IPsec SA to be established with CP >>> exchange in IKE_AUTH exchange, but the configuration parameters >>> (e.g., >>> an IPv6 prefix) carried in the CP is used by the second IPsec SA for >>> e.g., an initiator to auto-configure an IPsec tunnel inner address by >>> combining the assigned IPv6 prefix with its own interface ID? >>> >>> - Maybe the first question is confusing, so more general question >>> would be: Does IKEv2 allow an initiator's inner address to be >>> auto-configured by combining an IPv6 prefix carried in CP with an >>> initiator's interface ID? If yes, how? This general question is not >>> only for the case where there are two (or more) IPsec SAs but also >>> for >>> the case where there is only one IPsec SA. >>> >>> Note that an assumption in the above questions is that the initiator >>> does not even know the prefix length before running IKEv2. >>> >>> Best regards, >>> Yoshihiro Ohba >>> >>> _______________________________________________ >>> Ipsec mailing list >>> Ipsec@ietf.org >>> https://www1.ietf.org/mailman/listinfo/ipsec >> _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed May 18 00:28:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYGAq-0007ZP-Ja; Wed, 18 May 2005 00:28:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYGAp-0007YB-9m for ipsec@megatron.ietf.org; Wed, 18 May 2005 00:28:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24278 for ; Wed, 18 May 2005 00:28:43 -0400 (EDT) Received: from inet-tsb5.toshiba.co.jp ([202.33.96.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYGRh-0000qO-OI for ipsec@ietf.org; Wed, 18 May 2005 00:46:14 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb5.toshiba.co.jp with ESMTP id j4I4Shnf023588; Wed, 18 May 2005 13:28:43 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id j4I4SiPj018866; Wed, 18 May 2005 13:28:44 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id PAA18859 ; Wed, 18 May 2005 13:28:43 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id j4I4ShS8021586; Wed, 18 May 2005 13:28:43 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id j4I4SgHN025402; Wed, 18 May 2005 13:28:42 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id j4I4Sfu6005400; Wed, 18 May 2005 13:28:41 +0900 (JST) Received: from steelhead (iVPN11-193.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0IGO00BVI4DW5H@tsbpo1.po.toshiba.co.jp>; Wed, 18 May 2005 13:28:34 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1DYG3M-0003T8-00; Tue, 17 May 2005 21:21:04 -0700 Date: Wed, 18 May 2005 00:21:00 -0400 From: Yoshihiro Ohba Subject: Re: [Ipsec] configuration payload usage In-reply-to: <17033.52806.275563.213358@fireball.kivinen.iki.fi> To: Tero Kivinen Message-id: <20050518042100.GI11712@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.9i References: <20050517042548.GB11712@steelhead> <17033.52806.275563.213358@fireball.kivinen.iki.fi> X-Spam-Score: 0.0 (/) X-Scan-Signature: a8a20a483a84f747e56475e290ee868e Cc: ipsec@ietf.org, Yoshihiro Ohba X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Thanks for the response with detailed example. BTW, the specification says that: " INTERNAL_IP6_ADDRESS is made up of two fields; the first being a 16 octet IPv6 address and the second being a one octet prefix-length as defined in [ADDRIPV6]. " " o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge-device protects. This attribute is made up of two fields; the first being a 16 octet IPv6 address the second being a one octet prefix-length as defined in [ADDRIPV6]. Multiple sub-networks MAY be requested. The responder MAY respond with zero or more sub-network attributes. " So I think that not only a full IPv6 address but also a prefix length is sent in CP. So can we say prefix is sent in CP? Regards, Yoshihiro Ohba On Tue, May 17, 2005 at 01:58:14PM +0300, Tero Kivinen wrote: > Yoshihiro Ohba writes: > > - When two (or more) IPsec SAs are to be established under a single > > IKE_SA, does IKEv2 allow the first IPsec SA to be established with CP > > exchange in IKE_AUTH exchange, but the configuration parameters (e.g., > > an IPv6 prefix) carried in the CP is used by the second IPsec SA for > > e.g., an initiator to auto-configure an IPsec tunnel inner address by > > combining the assigned IPv6 prefix with its own interface ID? > > Yes, and no. CP does not send IPv6 prefix, it sends full IPv6 > addresses. > > On the other hand it is completely valid for the responder to send > both IPv4 and IPv6 address inside the CP payload to the initiator, but > create the IPsec SA only for the IPv4 address. And then initiator can > create new IPsec SA for the IPv6 address it received from the > responder. > > I.e. > > HDR, SAi1, KEi, Ni -> > > <-- HDR, SAr1, KEr, Nr > > HDR, SK { IDi, AUTH, CP(CFG_REQUEST), > SAi2, TSi1, TSr1 } --> > > <-- HDR, SK { IDr,AUTH, CP(CFG_REPLY), > SAr2, TSi2, TSr2} > > where the > > CP(CFG_REQUEST) = > INTERNAL_IP4_ADDRESS(0.0.0.0), > INTERNAL_IP6_ADDRESS(::2d0:b7ff:fe83:21a0), > TSi1 = (0, 0-65535, 0.0.0.0 - 255.255.255.255) > TSi1 = (0, 0-65535, 0.0.0.0 - 255.255.255.255) > > and the replies will be: > > CP(CFG_REPLY) = > INTERNAL_IP4_ADDRESS(192.0.2.202), > INTERNAL_IP6_ADDRESS(2001:4f8:4:7:2d0:b7ff:fe83:21a0), > Tsi2 = (0, 0-65535, 192.0.2.202 - 192.0.2.202) > Tsr2 = (0, 0-65535, 192.0.2.0 - 192.0.2.255) > > Then the client can do CREATE_CHILD_SA: > > HDR, SK{ SA, Ni, TSi3, TSr3} --> > > <-- HDR, SK{ SA, Nr, TSi4, TSr4} > > where > > TSi3 = (0, 0-65535, 2001:4f8:4:7:2d0:b7ff:fe83:21a0 - > 2001:4f8:4:7:2d0:b7ff:fe83:21a0) > TSr3 = (0, 0-65535, :: - ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff) > > TSi4 = (0, 0-65535, 2001:4f8:4:7:2d0:b7ff:fe83:21a0 - > 2001:4f8:4:7:2d0:b7ff:fe83:21a0) > TSr4 = (0, 0-65535, 2001:4f8:4:7:: - 2001:4f8:4:7:ffff:ffff:ffff:ffff) > > and so on. > > > - Maybe the first question is confusing, so more general question > > would be: Does IKEv2 allow an initiator's inner address to be > > auto-configured by combining an IPv6 prefix carried in CP with an > > initiator's interface ID? If yes, how? This general question is not > > only for the case where there are two (or more) IPsec SAs but also for > > the case where there is only one IPsec SA. > > The CP payload does not send prefix, but instead full IPv6 address. > The initiator can request INTERNAL_IP6_ADDRESS so that it fills in the > address it wants to get. The server will then mostly likely replace > the prefix part to be suitable for him, but keep the interface ID of > the address it returns. > -- > kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed May 18 06:58:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYMFa-0003lc-GX; Wed, 18 May 2005 06:58:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYMFV-0003lX-BJ for ipsec@megatron.ietf.org; Wed, 18 May 2005 06:58:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04849 for ; Wed, 18 May 2005 06:57:58 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYMWR-0005W8-7b for ipsec@ietf.org; Wed, 18 May 2005 07:15:31 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j4IAvu1H008455 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 18 May 2005 13:57:57 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j4IAvs1c008452; Wed, 18 May 2005 13:57:54 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17035.8114.183234.755874@fireball.kivinen.iki.fi> Date: Wed, 18 May 2005 13:57:54 +0300 From: Tero Kivinen To: Yoshihiro Ohba Subject: Re: [Ipsec] configuration payload usage In-Reply-To: <20050518042100.GI11712@steelhead> References: <20050517042548.GB11712@steelhead> <17033.52806.275563.213358@fireball.kivinen.iki.fi> <20050518042100.GI11712@steelhead> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 7 min X-Total-Time: 6 min X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Yoshihiro Ohba writes: > Thanks for the response with detailed example. > > BTW, the specification says that: > > " > INTERNAL_IP6_ADDRESS is made up of two fields; the first > being a 16 octet IPv6 address and the second being a one octet > prefix-length as defined in [ADDRIPV6]. > " > > " > o INTERNAL_IP6_SUBNET - The protected sub-networks that this > edge-device protects. This attribute is made up of two fields; > the first being a 16 octet IPv6 address the second being a one > octet prefix-length as defined in [ADDRIPV6]. Multiple > sub-networks MAY be requested. The responder MAY respond with > zero or more sub-network attributes. > " > > So I think that not only a full IPv6 address but also a prefix length is > sent in CP. It sends full IPv6 address and the prefix length associated with the address. > So can we say prefix is sent in CP? In a way yes, as you can calculate the prefix from the full IPv6 address and prefix length, but the receiver is not allowed to change the lower order bits of the address it receives from the server, so in that sense it is not a prefix that is sent, but full IPv6 address. The reason is that the server needs to know the full IPv6 address when it narrows the traffic selectors, and fills in the information which address is behind which tunnel. So the server allocates the full IPv6 address based on the hints from the client (filled in the to the configuration payload request (typically interface ID)). The description of the INTERNAL_IP6_ADDRESS is quite clear about that, it says that the returned data is an address on the internal network, i.e. not prefix, but address. It also says that the first part of the item is the IPv6 address (not prefix, but full address), and the second part is the prefix-length: ---------------------------------------------------------------------- o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the internal network, sometimes called a red node address or private address and MAY be a private address on the Internet. In a request message, the address specified is a requested address (or zero if no specific address is requested). If a specific address is requested, it likely indicates that a previous connection existed with this address and the requestor would like to reuse that address. With IPv6, a requestor MAY supply the low order address bytes it wants to use. Multiple internal addresses MAY be requested by requesting multiple internal address attributes. The responder MAY only send up to the number of addresses requested. The INTERNAL_IP6_ADDRESS is made up of two fields; the first being a 16 octet IPv6 address and the second being a one octet prefix-length as defined in [ADDRIPV6]. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed May 18 20:45:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYZA5-0000UW-9U; Wed, 18 May 2005 20:45:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYZA3-0000UN-R0 for ipsec@megatron.ietf.org; Wed, 18 May 2005 20:45:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA11441 for ; Wed, 18 May 2005 20:45:08 -0400 (EDT) Received: from inet-tsb5.toshiba.co.jp ([202.33.96.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYZR0-0007WW-Kd for ipsec@ietf.org; Wed, 18 May 2005 21:02:48 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb5.toshiba.co.jp with ESMTP id j4J0iwnf014451; Thu, 19 May 2005 09:44:59 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id j4J0ixR4029635; Thu, 19 May 2005 09:44:59 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id KAA29624 ; Thu, 19 May 2005 09:44:58 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id j4J0iwcK027263; Thu, 19 May 2005 09:44:58 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id j4J0itJS021329; Thu, 19 May 2005 09:44:55 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id j4J0itu6027882; Thu, 19 May 2005 09:44:55 +0900 (JST) Received: from steelhead (iVPN01-149.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0IGP008CGOQ2QX@tsbpo1.po.toshiba.co.jp>; Thu, 19 May 2005 09:44:48 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1DYYEh-0003wF-00; Wed, 18 May 2005 16:45:59 -0700 Date: Wed, 18 May 2005 19:45:56 -0400 From: Yoshihiro Ohba Subject: Re: [Ipsec] configuration payload usage In-reply-to: <17033.52806.275563.213358@fireball.kivinen.iki.fi> To: Tero Kivinen Message-id: <20050518234556.GR11712@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.9i References: <20050517042548.GB11712@steelhead> <17033.52806.275563.213358@fireball.kivinen.iki.fi> X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: ipsec@ietf.org, Yoshihiro Ohba X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Tue, May 17, 2005 at 01:58:14PM +0300, Tero Kivinen wrote: > > I.e. > > HDR, SAi1, KEi, Ni -> > > <-- HDR, SAr1, KEr, Nr > > HDR, SK { IDi, AUTH, CP(CFG_REQUEST), > SAi2, TSi1, TSr1 } --> > > <-- HDR, SK { IDr,AUTH, CP(CFG_REPLY), > SAr2, TSi2, TSr2} > > where the > > CP(CFG_REQUEST) = > INTERNAL_IP4_ADDRESS(0.0.0.0), > INTERNAL_IP6_ADDRESS(::2d0:b7ff:fe83:21a0), > TSi1 = (0, 0-65535, 0.0.0.0 - 255.255.255.255) > TSi1 = (0, 0-65535, 0.0.0.0 - 255.255.255.255) > > and the replies will be: > > CP(CFG_REPLY) = > INTERNAL_IP4_ADDRESS(192.0.2.202), > INTERNAL_IP6_ADDRESS(2001:4f8:4:7:2d0:b7ff:fe83:21a0), > Tsi2 = (0, 0-65535, 192.0.2.202 - 192.0.2.202) > Tsr2 = (0, 0-65535, 192.0.2.0 - 192.0.2.255) > > Then the client can do CREATE_CHILD_SA: > > HDR, SK{ SA, Ni, TSi3, TSr3} --> > > <-- HDR, SK{ SA, Nr, TSi4, TSr4} I think this kind of CP usage for IPv6 address auto-configuration is important for some deployment scenarios, but the IKEv2 specification does not seem to explicitly describe this usage. So I am a bit afraid that there may be some interoperability issue unless it is explicitly described it in IKEv2 or some other document. Any opinion on this? Yoshihiro Ohba > > where > > TSi3 = (0, 0-65535, 2001:4f8:4:7:2d0:b7ff:fe83:21a0 - > 2001:4f8:4:7:2d0:b7ff:fe83:21a0) > TSr3 = (0, 0-65535, :: - ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff) > > TSi4 = (0, 0-65535, 2001:4f8:4:7:2d0:b7ff:fe83:21a0 - > 2001:4f8:4:7:2d0:b7ff:fe83:21a0) > TSr4 = (0, 0-65535, 2001:4f8:4:7:: - 2001:4f8:4:7:ffff:ffff:ffff:ffff) > > and so on. > > > - Maybe the first question is confusing, so more general question > > would be: Does IKEv2 allow an initiator's inner address to be > > auto-configured by combining an IPv6 prefix carried in CP with an > > initiator's interface ID? If yes, how? This general question is not > > only for the case where there are two (or more) IPsec SAs but also for > > the case where there is only one IPsec SA. > > The CP payload does not send prefix, but instead full IPv6 address. > The initiator can request INTERNAL_IP6_ADDRESS so that it fills in the > address it wants to get. The server will then mostly likely replace > the prefix part to be suitable for him, but keep the interface ID of > the address it returns. > -- > kivinen@safenet-inc.com > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed May 18 21:11:53 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYZZp-0000JX-14; Wed, 18 May 2005 21:11:53 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DYZZn-0000He-Hd for ipsec@megatron.ietf.org; Wed, 18 May 2005 21:11:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA13630 for ; Wed, 18 May 2005 21:11:49 -0400 (EDT) Received: from inet-tsb5.toshiba.co.jp ([202.33.96.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DYZqp-0008G6-KS for ipsec@ietf.org; Wed, 18 May 2005 21:29:29 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb5.toshiba.co.jp with ESMTP id j4J1BZnf013092; Thu, 19 May 2005 10:11:35 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id j4J1BZKv023687; Thu, 19 May 2005 10:11:35 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id LAA23666 ; Thu, 19 May 2005 10:11:35 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id j4J1BYQT027403; Thu, 19 May 2005 10:11:34 +0900 (JST) Received: from tsb-sgw2.toshiba.co.jp by toshiba.co.jp id j4J1BFrA028070; Thu, 19 May 2005 10:11:15 +0900 (JST) Received: from tsbpo1.po.toshiba.co.jp by tsb-sgw2.toshiba.co.jp with ESMTP id j4J1BFu6019598; Thu, 19 May 2005 10:11:15 +0900 (JST) Received: from steelhead (iVPN11-142.mobile.toshiba.co.jp) by tsbpo1.po.toshiba.co.jp (Sun Internet Mail Server sims.3.5.1999.01.13.19.49.p4) with ESMTP id <0IGP00G9IPXP6B@tsbpo1.po.toshiba.co.jp>; Thu, 19 May 2005 10:11:07 +0900 (JST) Received: from ohba by steelhead with local (Exim 3.36 #1 (Debian)) id 1DYYUA-0003xR-00; Wed, 18 May 2005 17:01:58 -0700 Date: Wed, 18 May 2005 20:01:55 -0400 From: Yoshihiro Ohba Subject: Re: [Ipsec] configuration payload usage In-reply-to: <17035.8114.183234.755874@fireball.kivinen.iki.fi> To: Tero Kivinen Message-id: <20050519000155.GS11712@steelhead> MIME-version: 1.0 Content-type: text/plain; charset=iso-2022-jp Content-disposition: inline User-Agent: Mutt/1.5.9i References: <20050517042548.GB11712@steelhead> <17033.52806.275563.213358@fireball.kivinen.iki.fi> <20050518042100.GI11712@steelhead> <17035.8114.183234.755874@fireball.kivinen.iki.fi> X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Cc: ipsec@ietf.org, Yoshihiro Ohba X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Wed, May 18, 2005 at 01:57:54PM +0300, Tero Kivinen wrote: > > > So can we say prefix is sent in CP? > > In a way yes, as you can calculate the prefix from the full IPv6 > address and prefix length, but the receiver is not allowed to change > the lower order bits of the address it receives from the server, so in > that sense it is not a prefix that is sent, but full IPv6 address. > > The reason is that the server needs to know the full IPv6 address when > it narrows the traffic selectors, and fills in the information which > address is behind which tunnel. So the server allocates the full IPv6 > address based on the hints from the client (filled in the to the > configuration payload request (typically interface ID)). > > The description of the INTERNAL_IP6_ADDRESS is quite clear about that, > it says that the returned data is an address on the internal network, > i.e. not prefix, but address. It also says that the first part of the > item is the IPv6 address (not prefix, but full address), and the > second part is the prefix-length: OK. > > ---------------------------------------------------------------------- > o INTERNAL_IP4_ADDRESS, INTERNAL_IP6_ADDRESS - An address on the > internal network, sometimes called a red node address or > private address and MAY be a private address on the Internet. > In a request message, the address specified is a requested > address (or zero if no specific address is requested). If a > specific address is requested, it likely indicates that a > previous connection existed with this address and the requestor > would like to reuse that address. With IPv6, a requestor > MAY supply the low order address bytes it wants to use. Also, the above sentence seems to indicate IPv6 address auto-configuration support. I have overlooked this. Please ignore my question I made in another mail. Yoshihiro Ohba > Multiple internal addresses MAY be requested by requesting > multiple internal address attributes. The responder MAY only > send up to the number of addresses requested. The > INTERNAL_IP6_ADDRESS is made up of two fields; the first > being a 16 octet IPv6 address and the second being a one octet > prefix-length as defined in [ADDRIPV6]. > -- > kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon May 23 08:33:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaC7G-00088E-K5; Mon, 23 May 2005 08:33:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaC7E-00087p-Fv for ipsec@megatron.ietf.org; Mon, 23 May 2005 08:33:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA20567 for ; Mon, 23 May 2005 08:33:03 -0400 (EDT) Received: from cs-pop.bu.edu ([128.197.12.2] helo=cs.bu.edu ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaCPC-0001tY-AF for ipsec@ietf.org; Mon, 23 May 2005 08:51:39 -0400 Received: from [192.168.168.102] (pool-141-154-119-22.bos.east.verizon.net [141.154.119.22]) (authenticated bits=0) by cs.bu.edu (8.12.2/8.12.2) with ESMTP id j4NCWw9o007474 for ; Mon, 23 May 2005 08:32:58 -0400 (EDT) Message-ID: <4291D229.1000209@quarrytech.com> Date: Mon, 23 May 2005 08:52:57 -0400 From: Thomas Gschwendtner User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: IPsec WG Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Subject: [Ipsec] re-authentication in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Once an IKEv2 SA got established and is up for a while, can the initiator start another AUTH exchange on that SA (e.g. because the used EAP method requires frequent re-authentication)? If yes, could you please point me to the section of the IKEv2 draft that says so? Thanks, Thomas _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon May 23 10:14:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaDgx-0001iX-3k; Mon, 23 May 2005 10:14:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaDgv-0001gK-47 for ipsec@megatron.ietf.org; Mon, 23 May 2005 10:14:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27747 for ; Mon, 23 May 2005 10:13:59 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaDyt-0004yg-JT for ipsec@ietf.org; Mon, 23 May 2005 10:32:37 -0400 Received: from esebh106.NOE.Nokia.com ([172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4NEC561018482; Mon, 23 May 2005 17:12:09 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 May 2005 17:13:57 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 23 May 2005 17:13:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] re-authentication in IKEv2 Date: Mon, 23 May 2005 17:13:55 +0300 Message-ID: Thread-Topic: [Ipsec] re-authentication in IKEv2 Thread-Index: AcVflZdotYXwVR9qTcmi2Bf/px8OTwAC55zA To: , X-OriginalArrivalTime: 23 May 2005 14:13:57.0639 (UTC) FILETIME=[A8CE4170:01C55FA1] X-Spam-Score: 0.3 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Thomas Gschwendtner writes: >=20 > Once an IKEv2 SA got established and is up for a while, can the=20 > initiator start another AUTH exchange on that SA (e.g.=20 > because the used EAP method requires frequent re-authentication)?=20 > If yes, could you please point me to the section of the IKEv2 draft=20 > that says so? There's no way to do reauthentication within a single IKE_SA; if the initiator wants to reauthenticate, it just creates a=20 new IKE_SA (the same way as the original one) and deletes the=20 old one.=20 Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon May 23 12:56:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaGET-0004TO-S7; Mon, 23 May 2005 12:56:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaGER-0004TJ-Uv for ipsec@megatron.ietf.org; Mon, 23 May 2005 12:56:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13950 for ; Mon, 23 May 2005 12:56:45 -0400 (EDT) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaGWT-0003ab-09 for ipsec@ietf.org; Mon, 23 May 2005 13:15:25 -0400 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 23 May 2005 09:56:39 -0700 X-IronPort-AV: i="3.93,129,1115017200"; d="scan'208"; a="637951832:sNHT29376876" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j4NGtgcY021819; Mon, 23 May 2005 09:56:34 -0700 (PDT) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 09:56:34 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] re-authentication in IKEv2 Date: Mon, 23 May 2005 09:56:34 -0700 Message-ID: <2AB1DCE354761449A2E270681CC0429833BEAA@xmb-sjc-21c.amer.cisco.com> Thread-Topic: [Ipsec] re-authentication in IKEv2 Thread-Index: AcVflZdotYXwVR9qTcmi2Bf/px8OTwAC55zAAAXIUJA= From: "Bora Akyol \(bora\)" To: , , X-OriginalArrivalTime: 23 May 2005 16:56:34.0023 (UTC) FILETIME=[60104F70:01C55FB8] X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org What happens to the associated IPSEC SAs when the old IKE SA is deleted? > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Pasi.Eronen@nokia.com > Sent: Monday, May 23, 2005 7:14 AM > To: tgschwendtner@quarrytech.com; ipsec@ietf.org > Subject: RE: [Ipsec] re-authentication in IKEv2 >=20 > Thomas Gschwendtner writes: > > > > Once an IKEv2 SA got established and is up for a while, can the > > initiator start another AUTH exchange on that SA (e.g. > > because the used EAP method requires frequent re-authentication)? > > If yes, could you please point me to the section of the IKEv2 draft > > that says so? >=20 > There's no way to do reauthentication within a single IKE_SA; > if the initiator wants to reauthenticate, it just creates a > new IKE_SA (the same way as the original one) and deletes the > old one. >=20 > Best regards, > Pasi >=20 > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon May 23 13:32:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaGnI-0008Ae-3o; Mon, 23 May 2005 13:32:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaGnG-0008AZ-7q for ipsec@megatron.ietf.org; Mon, 23 May 2005 13:32:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16884 for ; Mon, 23 May 2005 13:32:43 -0400 (EDT) Received: from mxout5.netvision.net.il ([194.90.9.29]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaH5G-000597-9g for ipsec@ietf.org; Mon, 23 May 2005 13:51:23 -0400 Received: from [192.168.0.70] ([217.132.114.39]) by mxout5.netvision.net.il (Sun Java System Messaging Server 6.1 HotFix 0.11 (built Jan 28 2005)) with ESMTP id <0IGY00MDWE2A7J90@mxout5.netvision.net.il> for ipsec@ietf.org; Mon, 23 May 2005 20:32:34 +0300 (IDT) Date: Mon, 23 May 2005 20:32:33 +0300 From: Yoav Nir Subject: Re: [Ipsec] re-authentication in IKEv2 In-reply-to: <2AB1DCE354761449A2E270681CC0429833BEAA@xmb-sjc-21c.amer.cisco.com> To: "Bora Akyol (bora)" Message-id: <368252c90bb945ad37da3b9e483de3f7@netvision.net.il> MIME-version: 1.0 X-Mailer: Apple Mail (2.622) Content-type: text/plain; charset=US-ASCII; format=flowed Content-transfer-encoding: 7BIT References: <2AB1DCE354761449A2E270681CC0429833BEAA@xmb-sjc-21c.amer.cisco.com> X-Spam-Score: 2.9 (++) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7BIT Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com, tgschwendtner@quarrytech.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org They're erased automatically. There is no provision (yet) for transferring them to the new IKE SA. It is an idea for an addition to the re-authentication draft. I don't see how we could add it without making a new notification type, which may complicate things, so I don't know if it's a good trade-off in terms of complexity vs efficiency. On May 23, 2005, at 7:56 PM, Bora Akyol (bora) wrote: > What happens to the associated IPSEC SAs when the old IKE SA is > deleted? > >> -----Original Message----- >> From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of >> Pasi.Eronen@nokia.com >> Sent: Monday, May 23, 2005 7:14 AM >> To: tgschwendtner@quarrytech.com; ipsec@ietf.org >> Subject: RE: [Ipsec] re-authentication in IKEv2 >> >> Thomas Gschwendtner writes: >>> >>> Once an IKEv2 SA got established and is up for a while, can the >>> initiator start another AUTH exchange on that SA (e.g. >>> because the used EAP method requires frequent re-authentication)? >>> If yes, could you please point me to the section of the IKEv2 draft >>> that says so? >> >> There's no way to do reauthentication within a single IKE_SA; >> if the initiator wants to reauthenticate, it just creates a >> new IKE_SA (the same way as the original one) and deletes the >> old one. >> >> Best regards, >> Pasi >> >> _______________________________________________ >> Ipsec mailing list >> Ipsec@ietf.org >> https://www1.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon May 23 13:37:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaGrN-0000Vh-M4; Mon, 23 May 2005 13:37:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaGrL-0000VU-SH for ipsec@megatron.ietf.org; Mon, 23 May 2005 13:36:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17371 for ; Mon, 23 May 2005 13:36:58 -0400 (EDT) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaH9N-0005Kh-0d for ipsec@ietf.org; Mon, 23 May 2005 13:55:37 -0400 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-3.cisco.com with ESMTP; 23 May 2005 10:36:09 -0700 X-IronPort-AV: i="3.93,129,1115017200"; d="scan'208"; a="268588418:sNHT1650959280" Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j4NHZPmY016319; Mon, 23 May 2005 10:36:04 -0700 (PDT) Received: from xmb-sjc-21c.amer.cisco.com ([171.70.151.176]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 23 May 2005 10:36:06 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] re-authentication in IKEv2 Date: Mon, 23 May 2005 10:36:03 -0700 Message-ID: <2AB1DCE354761449A2E270681CC0429833BEC8@xmb-sjc-21c.amer.cisco.com> Thread-Topic: [Ipsec] re-authentication in IKEv2 Thread-Index: AcVfvYuE4OC7k2a4S5GMiYhBfb6r7AAAA5+g From: "Bora Akyol \(bora\)" To: "Yoav Nir" X-OriginalArrivalTime: 23 May 2005 17:36:06.0540 (UTC) FILETIME=[E631ACC0:01C55FBD] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com, tgschwendtner@quarrytech.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Having dealt with the separation of IKE and IPSEC SAs in=20 IKEv1, I am rather attached to the grouping of IKE and its child SAs as an atom. Therefore, I would be strongly opposed to decoupling these one more time. So if we come up with a reauth mechanism that involves a new IKE SA, then we should be able to find a way to transfer IPSEC SAs. Regards Bora > -----Original Message----- > From: Yoav Nir [mailto:ynir@netvision.net.il] > Sent: Monday, May 23, 2005 10:33 AM > To: Bora Akyol (bora) > Cc: Pasi.Eronen@nokia.com; ipsec@ietf.org; tgschwendtner@quarrytech.com > Subject: Re: [Ipsec] re-authentication in IKEv2 >=20 > They're erased automatically. There is no provision (yet) for > transferring them to the new IKE SA. >=20 > It is an idea for an addition to the re-authentication draft. I don't > see how we could add it without making a new notification type, which > may complicate things, so I don't know if it's a good trade-off in > terms of complexity vs efficiency. >=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue May 24 02:43:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaT8G-0006Da-3B; Tue, 24 May 2005 02:43:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DaT8D-0006DV-Cw for ipsec@megatron.ietf.org; Tue, 24 May 2005 02:43:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA00293 for ; Tue, 24 May 2005 02:43:11 -0400 (EDT) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DaTQI-0006I2-V4 for ipsec@ietf.org; Tue, 24 May 2005 03:01:57 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id j4O6elnP026833; Tue, 24 May 2005 09:40:48 +0300 (IDT) In-Reply-To: <2AB1DCE354761449A2E270681CC0429833BEC8@xmb-sjc-21c.amer.cisco.com> References: <2AB1DCE354761449A2E270681CC0429833BEC8@xmb-sjc-21c.amer.cisco.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] re-authentication in IKEv2 Date: Tue, 24 May 2005 09:40:48 +0300 To: "Bora Akyol \(bora\)" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: IPsec WG , Pasi.Eronen@nokia.com, tgschwendtner@quarrytech.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I think the obvious solution is a new notification type in the INFO exchange that is used to delete the old IKE SA. This payload would say that the child SAs of this SA are transferred to the ownership of the specified IKE SA. The reason I'm hesitant to propose this, is that such a notification will cause an interoperability problem - what if the other side does not know how to transfer child SAs, or does not support this extension at all? You could solve this by requiring the responder to reply with the same payload if it understands the message, and if the responder does not, delete the SA. I suppose the format would be something like this: +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Next Payload !C! RESERVED ! Payload Length=24 ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! Protocol ID ! SPI Size=8 ! Notify Message Type=??? ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! NEW SPI_I ! ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! NEW SPI_R ! ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ And the exchange can be something like this: Initiator Responder ----------- ----------- HDR, SK {[D] [XFER]} --> <-- HDR, SK {[D] [XFER]} I'm still not sure it's worth it in terms of complexity vs efficiency. I think the typical case for re-authentication is the client-gateway (AKA road-warrior) case. I think that it would be very rare for such cases to have many child SAs. In fact, now that we have the ability to support complex traffic selectors, a single child SA will be very common, and that single child SA can be negotiated within the new AUTH exchange. Even if a few more SAs are needed, it only takes two IKE messages to set up an SA. On May 23, 2005, at 8:36 PM, Bora Akyol ((bora)) wrote: > Having dealt with the separation of IKE and IPSEC SAs in > IKEv1, I am rather attached to the grouping of IKE and its > child SAs as an atom. > > Therefore, I would be strongly opposed to decoupling these one > more time. > > So if we come up with a reauth mechanism that involves > a new IKE SA, then we should be able to find a way to transfer > IPSEC SAs. > > Regards > Bora > > >> -----Original Message----- >> From: Yoav Nir [mailto:ynir@netvision.net.il] >> Sent: Monday, May 23, 2005 10:33 AM >> To: Bora Akyol (bora) >> Cc: Pasi.Eronen@nokia.com; ipsec@ietf.org; > tgschwendtner@quarrytech.com >> Subject: Re: [Ipsec] re-authentication in IKEv2 >> >> They're erased automatically. There is no provision (yet) for >> transferring them to the new IKE SA. >> >> It is an idea for an addition to the re-authentication draft. I don't >> see how we could add it without making a new notification type, which >> may complicate things, so I don't know if it's a good trade-off in >> terms of complexity vs efficiency. >> > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu May 26 12:44:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbLSn-0005J5-4V; Thu, 26 May 2005 12:44:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbLSl-0005J0-G7 for ipsec@megatron.ietf.org; Thu, 26 May 2005 12:44:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11709 for ; Thu, 26 May 2005 12:44:00 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbLlJ-0005UH-VH for ipsec@ietf.org; Thu, 26 May 2005 13:03:15 -0400 Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QGhq9c033890 for ; Thu, 26 May 2005 09:43:52 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 26 May 2005 09:43:50 -0700 To: ipsec@ietf.org From: rfc-editor@rfc-editor.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.3 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Subject: [Ipsec] RFC 4109 on Algorithms for Internet Key Exchange version 1 (IKEv1) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org A new Request for Comments is now available in online RFC libraries. RFC 4109 Title: Algorithms for Internet Key Exchange version 1 (IKEv1) Author(s): P. Hoffman Status: Standards Track Date: May 2005 Mailbox: paul.hoffman@vpnc.org Pages: 5 Characters: 9491 Updates: 2409 I-D Tag: draft-hoffman-ikev1-algorithms-03.txt URL: ftp://ftp.rfc-editor.org/in-notes/rfc4109.txt The required and suggested algorithms in the original Internet Key Exchange version 1 (IKEv1) specification do not reflect the current reality of the IPsec market requirements. The original specification allows weak security and suggests algorithms that are thinly implemented. This document updates RFC 2409, the original specification, and is intended for all IKEv1 implementations deployed today. This is now a Proposed Standard Protocol. This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF list and the RFC-DIST list. Requests to be added to or deleted from the IETF distribution list should be sent to IETF-REQUEST@IETF.ORG. Requests to be added to or deleted from the RFC-DIST distribution list should be sent to RFC-DIST-REQUEST@RFC-EDITOR.ORG. Details on obtaining RFCs via FTP or EMAIL may be obtained by sending an EMAIL message to rfc-info@RFC-EDITOR.ORG with the message body help: ways_to_get_rfcs. For example: To: rfc-info@RFC-EDITOR.ORG Subject: getting rfcs help: ways_to_get_rfcs Requests for special distribution should be addressed to either the author of the RFC in question, or to RFC-Manager@RFC-EDITOR.ORG. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. Submissions for Requests for Comments should be sent to RFC-EDITOR@RFC-EDITOR.ORG. Please consult RFC 2223, Instructions to RFC Authors, for further information. Joyce K. Reynolds and Sandy Ginoza USC/Information Sciences Institute ... Below is the data which will enable a MIME compliant Mail Reader implementation to automatically retrieve the ASCII version of the RFCs. [The following attachment must be fetched by mail. Command-click the URL below and send the resulting message to get the attachment.] [The following attachment must be fetched by ftp. Command-click the URL below to ask your ftp client to fetch it.] _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu May 26 12:57:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbLfw-0007Xi-Ec; Thu, 26 May 2005 12:57:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbLfv-0007Xd-4j for ipsec@megatron.ietf.org; Thu, 26 May 2005 12:57:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12949 for ; Thu, 26 May 2005 12:57:35 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.195]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbLyV-0005s8-5L for Ipsec@ietf.org; Thu, 26 May 2005 13:16:54 -0400 Received: by wproxy.gmail.com with SMTP id 71so883285wri for ; Thu, 26 May 2005 09:57:26 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type; b=EPtSmgQQKsfb6dQ4WWIkxBjXn7tJUMpjnxSYqJAlo+sNlPWGSkzXk38zNo+HsA2C9EB2bFKGIHL63DTO7M8IEU9nmyYgHc2YWi/Y1Q7fJTeZAb/5droC7/aMeqNoeM5ou57E1wpXwQjhfvMo79u2HL+pCT5cIFN+PKPLj1WAlVg= Received: by 10.54.16.60 with SMTP id 60mr1056099wrp; Thu, 26 May 2005 09:57:25 -0700 (PDT) Received: by 10.54.86.9 with HTTP; Thu, 26 May 2005 09:57:24 -0700 (PDT) Message-ID: <75f0ad43050526095725959589@mail.gmail.com> Date: Thu, 26 May 2005 22:27:24 +0530 From: Prasanna Harpanhalli To: Ipsec@ietf.org Mime-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: Subject: [Ipsec] Regd Setting up IPsec on Linux Fedora Core 3 (2.6.* Kernel) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Prasanna Harpanhalli List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1752441427==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1752441427== Content-Type: multipart/alternative; boundary="----=_Part_2137_25592427.1117126644964" ------=_Part_2137_25592427.1117126644964 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi All, I want to setup IPsec on a Fedora core 3 box. I don't know if this is the= =20 right Forum I should be addressing my question to... I have uptill now... 1. Compiled the kernel (version 2.6.11) with IPsec openswan package support= . 2. installed ipsec-tools.=20 3. openswan user space client compiled from sources. But I am confused as to the exact tools required to start and configure=20 IPsec policy. Googling around is not useful. $ipsec verify=20 gives this output=20 Checking your system to see if IPsec got installed and started correctly: Version check and ipsec on-path [OK] Linux Openswan U2.3.1/K2.6.11-1.14_FC3 (netkey) Checking for IPsec support in kernel [OK] Checking for RSA private key (/etc/ipsec.secrets) [OK] Checking that pluto is running [OK] Two or more interfaces found, checking IP forwarding [FAILED] Checking for 'ip' command [OK] Checking for 'iptables' command [OK] Checking for 'setkey' command for NETKEY IPsec stack support [OK] Opportunistic Encryption Support=20 can anyone please list the tools the order and the correct IP Address to=20 configure it with an SSH Sentinel 1.4 IPsec Configuration running windows= =20 machine. Any pointers will be greatly appreciated. TIA, --=20 Prasanna Harpanhalli. ------=_Part_2137_25592427.1117126644964 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi All,
  I want to setup IPsec on a Fedora core 3 box. I don't know if this is the right Forum I should be addressing my question to...
I have uptill now...
1. Compiled the kernel (version 2.6.11) with IPsec openswan package support= .
2. installed ipsec-tools.
3. openswan user space client compiled from sources.
But I am confused as to the exact tools required to start and configure IPs= ec policy.
Googling around is not useful.
$ipsec= verify
      gives this output
<snip>
Checking your system to see if IPsec got installed and started correctly: Version check and ipsec on-path           &n= bsp;            = ;         [OK]
Linux Openswan U2.3.1/K2.6.11-1.14_FC3 (netkey)
Checking for IPsec support in kernel           &nb= sp;            =     [OK]
Checking for RSA private key (/etc/ipsec.secrets)         &= nbsp;     [OK]
Checking that pluto is running           &n= bsp;            = ;          [OK]
Two or more interfaces found, checking IP forwarding    = ;        [FAILED]
Checking for 'ip' command           &n= bsp;            = ;            &n= bsp;  [OK]
Checking for 'iptables' command           &n= bsp;            = ;         [OK]
Checking for 'setkey' command for NETKEY IPsec stack support  &nb= sp; [OK]
Opportunistic Encryption Support 
<snip/>


can anyone please list the tools the order and the correct IP Address to configure it with an SSH Sentinel 1.4 IPsec Configuration running windows machine. Any pointers will be greatly appreciated.
TIA,
--
Prasanna Harpanhalli.
------=_Part_2137_25592427.1117126644964-- --===============1752441427== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1752441427==-- From ipsec-bounces@ietf.org Thu May 26 17:01:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbPTh-0004Mu-D4; Thu, 26 May 2005 17:01:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbPTf-0004Mn-F2 for ipsec@megatron.ietf.org; Thu, 26 May 2005 17:01:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12165 for ; Thu, 26 May 2005 17:01:13 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbPmJ-0006bt-Nm for ipsec@ietf.org; Thu, 26 May 2005 17:20:33 -0400 Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4QL16Ff091261 for ; Thu, 26 May 2005 14:01:06 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 26 May 2005 14:01:02 -0700 To: IPsec WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Ipsec] Finishing up on rfc3664bis (AES-XCBC-PRF-128) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Greetings again. I have not heard any comments on the latest version of the revision to RFC 3664, which is currently . If I don't hear anything in the coming days, I'll ask for it to be published as an RFC. FWIW, this draft would be greatly enhanced by having worked-out examples of the three different key lengths, similar to those in RFC 3556. If any implementer of AES-XCBC-MAC-96 can do this in the near future, please let me know so I can add them (and an acknowledgement, of course) to the document. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri May 27 04:59:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbagX-0002m4-4z; Fri, 27 May 2005 04:59:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DbagU-0002lz-RC for ipsec@megatron.ietf.org; Fri, 27 May 2005 04:59:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA22088 for ; Fri, 27 May 2005 04:59:12 -0400 (EDT) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbazE-0005Pe-Q6 for ipsec@ietf.org; Fri, 27 May 2005 05:18:38 -0400 Received: from [172.31.21.213] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id j4R8wxnP006592 for ; Fri, 27 May 2005 11:59:00 +0300 (IDT) Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <0206accccdfc8c00c69769b9f6ac6a72@checkpoint.com> Content-Transfer-Encoding: 7bit From: Yoav Nir Date: Fri, 27 May 2005 11:58:58 +0300 To: IPsec WG X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Subject: [Ipsec] Question about Integrity Checksum Data X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi. This has probably been discussed before, but I couldn't find it in either the draft or the mailing list archive. The Integrity Checksum Data field in the Encrypted payload is described as having a length as specified by the integrity algorithm. All the integrity algorithms are those that are also specified for ESP. In ESP, the hash value is truncated to 96 bits (hence the _96 suffix in all their names) In IKEv1 we did not truncate the hash value for IKE, only for ESP. Has this changed for IKEv2? Are we supposed to use only the first 96 bits for MD5 and SHA1, or should we keep using the full untruncated value? Thanks Yoav _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri May 27 09:11:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbecj-0003eB-JQ; Fri, 27 May 2005 09:11:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbeci-0003dU-Ay for ipsec@megatron.ietf.org; Fri, 27 May 2005 09:11:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09136 for ; Fri, 27 May 2005 09:11:35 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbevV-0002c5-2L for ipsec@ietf.org; Fri, 27 May 2005 09:31:02 -0400 Received: from esebh107.NOE.Nokia.com ([172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j4RDBPHi000452; Fri, 27 May 2005 16:11:28 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 May 2005 16:11:24 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 27 May 2005 16:11:24 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Question about Integrity Checksum Data Date: Fri, 27 May 2005 16:11:25 +0300 Message-ID: Thread-Topic: [Ipsec] Question about Integrity Checksum Data Thread-Index: AcVim1+jZp4CVGt1SOWnNTGSkTUkmgAISt7A To: , X-OriginalArrivalTime: 27 May 2005 13:11:24.0663 (UTC) FILETIME=[95829070:01C562BD] X-Spam-Score: 0.3 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, If you negotiate e.g. "AUTH_HMAC_SHA1_96" for your integrity algorithm, then yes, the integrity checksum data is always 96 bits. (Presumably, someone could define AUTH_HMAC_SHA1_128 or AUTH_HMAC_SHA1_160 or something else in the future, but those would be totally different integrity algorithms from IKEv2=20 point of view, even though not much additional code would be needed.) Best regards, Pasi > -----Original Message----- > From: Yoav Nir > Sent: Friday, May 27, 2005 11:59 AM > To: IPsec WG > Subject: [Ipsec] Question about Integrity Checksum Data >=20 >=20 > Hi. >=20 > This has probably been discussed before, but I couldn't find it > in either the draft or the mailing list archive. >=20 > The Integrity Checksum Data field in the Encrypted payload is > described as having a length as specified by the integrity > algorithm. All the integrity algorithms are those that are also > specified for ESP. In ESP, the hash value is truncated to 96 > bits (hence the _96 suffix in all their names) >=20 > In IKEv1 we did not truncate the hash value for IKE, only for > ESP. Has this changed for IKEv2? Are we supposed to use only > the first 96 bits for MD5 and SHA1, or should we keep using the > full untruncated value? >=20 > Thanks >=20 > Yoav _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat May 28 04:43:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbwv0-00009B-TW; Sat, 28 May 2005 04:43:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dbwuy-000094-Pz for ipsec@megatron.ietf.org; Sat, 28 May 2005 04:43:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06007 for ; Sat, 28 May 2005 04:43:38 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.192]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DbxDw-0007Mw-33 for ipsec@ietf.org; Sat, 28 May 2005 05:03:17 -0400 Received: by wproxy.gmail.com with SMTP id 58so1586756wri for ; Sat, 28 May 2005 01:43:30 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:content-type:date:mime-version:x-mailer:content-transfer-encoding:message-id; b=r5XHqKMoA5CovXyoPauzZH9cYQKk0RR99XMBLsuarUF5Ef6RrjuLMNDoQZSNvN9SNGTxT3c9uYD6JcmWK5eScEV4f6d8zTY+fM173h7O41XJAL2EMKEzc+qP+3AUHPAMU/sWBPi/n/RCF3BYHoLflFhtPVs/Q1bDIPU/umbRwvE= Received: by 10.54.148.12 with SMTP id v12mr3215829wrd; Sat, 28 May 2005 01:43:30 -0700 (PDT) Received: from isabel. ([84.121.24.204]) by mx.gmail.com with ESMTP id 34sm526799wra.2005.05.28.01.43.29; Sat, 28 May 2005 01:43:30 -0700 (PDT) From: Alejandro =?ISO-8859-1?Q?P=E9rez_M=E9ndez?= To: ipsec@ietf.org Content-Type: text/plain Date: Sat, 28 May 2005 10:43:28 +0200 Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 Content-Transfer-Encoding: 7bit Message-ID: <42982f32.0b081bb4.6dbc.ffffeb82@mx.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Subject: [Ipsec] Narrowing Traffic Selectors IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi. I'm implementating IKEv2 and I have some (perhaps trivial) troubles. I have read a lot of mails in this mailing list, the IKEv2 draft, the IKEv2 tutorial draft and the IKEv2 clarifications draft, and I still have a doubt with Traffic Selectors negociation. When Peer A propose a set of TS to Peer B according with its policies, and Peer B narrow this TS to accomodate them to its policies, must Peer A update its SPD to adjust it to the new TS selected by Peer B if accept them? Thanks (anticipaded) for your responses. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat May 28 10:34:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dc2Ol-0005Ak-HJ; Sat, 28 May 2005 10:34:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dc2Oj-0005Ac-6x for ipsec@megatron.ietf.org; Sat, 28 May 2005 10:34:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25791 for ; Sat, 28 May 2005 10:34:42 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dc2hj-0005tF-EA for ipsec@ietf.org; Sat, 28 May 2005 10:54:24 -0400 Received: from sfbaymail1sca.SFBay.Sun.COM ([129.145.154.35]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j4SEY60R021417; Sat, 28 May 2005 08:34:06 -0600 (MDT) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by sfbaymail1sca.SFBay.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j4SEY4Pu002155; Sat, 28 May 2005 07:34:05 -0700 (PDT) Subject: Re: [Ipsec] Narrowing Traffic Selectors IKEv2 From: Bill Sommerfeld To: Alejandro P?rez M?ndez In-Reply-To: <42982f32.0b081bb4.6dbc.ffffeb82@mx.gmail.com> References: <42982f32.0b081bb4.6dbc.ffffeb82@mx.gmail.com> Content-Type: text/plain; charset=ASCII Message-Id: <1117290796.38491.208.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.311 Date: Sat, 28 May 2005 07:33:17 -0700 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Sat, 2005-05-28 at 01:43, Alejandro P?rez M?ndez wrote: > When Peer A propose a set of TS to Peer B according with its policies, > and Peer B narrow this TS to accomodate them to its policies, must Peer > A update its SPD to adjust it to the new TS selected by Peer B if accept > them? No. SA's also have traffic selectors, and a single SPD rule may correspond to multiple SA's. IKE is typically invoked to instantiate a new SA when outbound traffic hits in the SPD but misses in the SADB. - Bill _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat May 28 13:49:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dc5RH-00057H-TH; Sat, 28 May 2005 13:49:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dc5RG-00057C-Du for ipsec@megatron.ietf.org; Sat, 28 May 2005 13:49:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20461 for ; Sat, 28 May 2005 13:49:32 -0400 (EDT) Received: from wproxy.gmail.com ([64.233.184.196]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dc5kJ-0003bM-GL for ipsec@ietf.org; Sat, 28 May 2005 14:09:15 -0400 Received: by wproxy.gmail.com with SMTP id 58so1676234wri for ; Sat, 28 May 2005 10:49:25 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=aC3KIBnIr0bcCwUxjxHRJtJf6q0FhsencyysezB24QVnPaJsLi163apNIlitZxboC4U1axU470cs4H6zQju7L1dUnN1yUXLmFlo8MouosWm/0AV3uu4J09GkGvdK2eR/6agiriL52YqdaelVXIvyBPVJTUv2vQ28U5srhJaPwpQ= Received: by 10.54.34.62 with SMTP id h62mr1262732wrh; Sat, 28 May 2005 10:49:25 -0700 (PDT) Received: by 10.54.130.16 with HTTP; Sat, 28 May 2005 10:49:25 -0700 (PDT) Message-ID: <93591b7a050528104917bfe7fa@mail.gmail.com> Date: Sat, 28 May 2005 19:49:25 +0200 From: =?ISO-8859-1?Q?Alejandro_P=E9rez_M=E9ndez?= To: Bill Sommerfeld Subject: Re: [Ipsec] Narrowing Traffic Selectors IKEv2 In-Reply-To: <1117290796.38491.208.camel@unknown.hamachi.org> Mime-Version: 1.0 References: <42982f32.0b081bb4.6dbc.ffffeb82@mx.gmail.com> <1117290796.38491.208.camel@unknown.hamachi.org> X-Spam-Score: 0.5 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: =?ISO-8859-1?Q?Alejandro_P=E9rez_M=E9ndez?= List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============2092859869==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============2092859869== Content-Type: multipart/alternative; boundary="----=_Part_3718_6008696.1117302565366" ------=_Part_3718_6008696.1117302565366 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 2005/5/28, Bill Sommerfeld : >=20 > On Sat, 2005-05-28 at 01:43, Alejandro P?rez M?ndez wrote: > > When Peer A propose a set of TS to Peer B according with its policies, > > and Peer B narrow this TS to accomodate them to its policies, must Peer > > A update its SPD to adjust it to the new TS selected by Peer B if accep= t > > them? >=20 > No. SA's also have traffic selectors, and a single SPD rule may > correspond to multiple SA's. IKE is typically invoked to instantiate a > new SA when outbound traffic hits in the SPD but misses in the SADB. >=20 > - Bill >=20 >=20 Thanks, but now i have a new problem.=20 If SA's also have traffic selectors, how can i set them? I have read PF_KEY= =20 v2 spec several times and i haven't found nothing about it. Thanks ------=_Part_3718_6008696.1117302565366 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 2005/5/28, Bill Sommerfeld <sommer= feld@sun.com>:
On Sat, 2005-05-28 at 01:43, Alejandro P?rez M?ndez wrote:
> When Pee= r A propose a set of TS to Peer B according with its policies,
> and = Peer B narrow this TS to accomodate them to its policies, must Peer
> A update its SPD to adjust it to the new TS selected by Peer B if acce= pt
> them?

No.  SA's also have traffic selectors, an= d a single SPD rule may
correspond to multiple SA's.  IKE is t= ypically invoked to instantiate a
new SA when outbound traffic hits in the SPD but misses in the SADB.
           &nbs= p;            &= nbsp;           &nbs= p;           - Bill


Thanks, but now i have a new problem.
If SA's also have traffic selectors, how can i set them? I have read PF_KEY v2 spec several times and i haven't found nothing  about it. Thanks
------=_Part_3718_6008696.1117302565366-- --===============2092859869== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============2092859869==-- From ipsec-bounces@ietf.org Sun May 29 00:25:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcFMf-0003aU-6f; Sun, 29 May 2005 00:25:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcFMd-0003a1-MP for ipsec@megatron.ietf.org; Sun, 29 May 2005 00:25:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27095 for ; Sun, 29 May 2005 00:25:24 -0400 (EDT) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcFfl-0007ei-0q for ipsec@ietf.org; Sun, 29 May 2005 00:45:14 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id j4T4PFnP013836; Sun, 29 May 2005 07:25:15 +0300 (IDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <28f349eff556418e96f473a282592b5c@checkpoint.com> Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] Question about Integrity Checksum Data Date: Sun, 29 May 2005 07:25:15 +0300 To: "" , Paul Hoffman X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Thanks. It is strange. If you read RFC 4109 (algorithms for IKEv1) or the IANA registry, it says just MD5 or SHA1, and in fact implementations of IKEv1 did use the full checksum (128 or 160 bits). However, the UI-suites document and the algorithms document show only the _96 version of these algorithms. Is this difference intentional? Does this mean that for an IKEv1 implementation to support the VPN-A suite it would need to have a new algorithms for integrity? On May 27, 2005, at 4:11 PM, wrote: > Hi, > > If you negotiate e.g. "AUTH_HMAC_SHA1_96" for your integrity > algorithm, then yes, the integrity checksum data is always 96 bits. > > (Presumably, someone could define AUTH_HMAC_SHA1_128 or > AUTH_HMAC_SHA1_160 or something else in the future, but those > would be totally different integrity algorithms from IKEv2 > point of view, even though not much additional code would > be needed.) > > Best regards, > Pasi > >> -----Original Message----- >> From: Yoav Nir >> Sent: Friday, May 27, 2005 11:59 AM >> To: IPsec WG >> Subject: [Ipsec] Question about Integrity Checksum Data >> >> >> Hi. >> >> This has probably been discussed before, but I couldn't find it >> in either the draft or the mailing list archive. >> >> The Integrity Checksum Data field in the Encrypted payload is >> described as having a length as specified by the integrity >> algorithm. All the integrity algorithms are those that are also >> specified for ESP. In ESP, the hash value is truncated to 96 >> bits (hence the _96 suffix in all their names) >> >> In IKEv1 we did not truncate the hash value for IKE, only for >> ESP. Has this changed for IKEv2? Are we supposed to use only >> the first 96 bits for MD5 and SHA1, or should we keep using the >> full untruncated value? >> >> Thanks >> >> Yoav > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun May 29 18:44:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcWW9-00075w-LB; Sun, 29 May 2005 18:44:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DcWW8-00075p-2I for ipsec@megatron.ietf.org; Sun, 29 May 2005 18:44:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02397 for ; Sun, 29 May 2005 18:44:21 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcWpO-0001EH-9y for ipsec@ietf.org; Sun, 29 May 2005 19:04:20 -0400 Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4TMi2vd083538; Sun, 29 May 2005 15:44:03 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <28f349eff556418e96f473a282592b5c@checkpoint.com> References: <28f349eff556418e96f473a282592b5c@checkpoint.com> Date: Sun, 29 May 2005 15:43:57 -0700 To: Yoav Nir , "" From: Paul Hoffman Subject: Re: [Ipsec] Question about Integrity Checksum Data Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 7:25 AM +0300 5/29/05, Yoav Nir wrote: >It is strange. If you read RFC 4109 (algorithms for IKEv1) or the >IANA registry, it says just MD5 or SHA1, and in fact implementations >of IKEv1 did use the full checksum (128 or 160 bits). Nothing strange so far. >However, the UI-suites document and the algorithms document show >only the _96 version of these algorithms. Is this difference >intentional? Does this mean that for an IKEv1 implementation to >support the VPN-A suite it would need to have a new algorithms for >integrity? Because we changed from not negotiating the actual PRF in IKEv1 to negotiating it in IKEv2, the UI-suites document had to pick between one of the two wordings; I chose the IKEv2 wording. In IKEv1, it says: All of these attributes are mandatory and MUST be negotiated. In addition, it is possible to optionally negotiate a psuedo-random function ("prf"). (There are currently no negotiable pseudo-random functions defined in this document. Private use attribute values can be used for prf negotiation between consenting parties). If a "prf" is not negotiation, the HMAC (see [KBC96]) version of the negotiated hash algorithm is used as a pseudo-random function. Other non- mandatory attributes are described in Appendix A. The selected hash algorithm MUST support both native and HMAC modes. Thus, when you negotiate a hash algorithm of "SHA1", you are really negotiating the PRF of "HMAC-SHA1" and the use of SHA1 in other places in the protocol. Maybe instead of: Pseudo-random function HMAC-SHA1 [RFC2104] I could have said: Hash (IKEv1) or pseudo-random function (IKEv2) SHA1 [SHA1] or HMAC-SHA1 [RFC2104] but that would be harder to understand. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon May 30 02:52:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dce8U-0000Rv-1B; Mon, 30 May 2005 02:52:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dce8R-0000Rp-SF for ipsec@megatron.ietf.org; Mon, 30 May 2005 02:52:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA21224 for ; Mon, 30 May 2005 02:52:26 -0400 (EDT) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DceRn-0001Ts-1Q for ipsec@ietf.org; Mon, 30 May 2005 03:12:28 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id j4U6q9nP011828; Mon, 30 May 2005 09:52:09 +0300 (IDT) In-Reply-To: References: <28f349eff556418e96f473a282592b5c@checkpoint.com> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8b02f743ec65aaa19084de0e2fb904da@checkpoint.com> Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] Question about Integrity Checksum Data Date: Mon, 30 May 2005 09:52:10 +0300 To: Paul Hoffman X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, "" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org So if I'm using the UI suite VPN-A, whenever I'm using IKEv1 I will use the integrity algorithm SHA1 (with a 160-bit checksum field), but whenever I'm using IKEv2 I will use the SHA1_96 integrity algorithm (with a 96-bit checksum field). Is this correct? On May 30, 2005, at 1:43 AM, Paul Hoffman wrote: > At 7:25 AM +0300 5/29/05, Yoav Nir wrote: >> It is strange. If you read RFC 4109 (algorithms for IKEv1) or the >> IANA registry, it says just MD5 or SHA1, and in fact implementations >> of IKEv1 did use the full checksum (128 or 160 bits). > > Nothing strange so far. > >> However, the UI-suites document and the algorithms document show only >> the _96 version of these algorithms. Is this difference intentional? >> Does this mean that for an IKEv1 implementation to support the VPN-A >> suite it would need to have a new algorithms for integrity? > > Because we changed from not negotiating the actual PRF in IKEv1 to > negotiating it in IKEv2, the UI-suites document had to pick between > one of the two wordings; I chose the IKEv2 wording. > > In IKEv1, it says: > > All of these attributes are mandatory and MUST be negotiated. In > addition, it is possible to optionally negotiate a psuedo-random > function ("prf"). (There are currently no negotiable pseudo-random > functions defined in this document. Private use attribute values can > be used for prf negotiation between consenting parties). If a "prf" > is not negotiation, the HMAC (see [KBC96]) version of the negotiated > hash algorithm is used as a pseudo-random function. Other non- > mandatory attributes are described in Appendix A. The selected hash > algorithm MUST support both native and HMAC modes. > > Thus, when you negotiate a hash algorithm of "SHA1", you are really > negotiating the PRF of "HMAC-SHA1" and the use of SHA1 in other places > in the protocol. Maybe instead of: > Pseudo-random function HMAC-SHA1 [RFC2104] > I could have said: > Hash (IKEv1) or pseudo-random function (IKEv2) SHA1 [SHA1] or > HMAC-SHA1 [RFC2104] > but that would be harder to understand. > > --Paul Hoffman, Director > --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon May 30 11:08:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dclsk-0004JJ-7x; Mon, 30 May 2005 11:08:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dclsi-0004JE-6z for ipsec@megatron.ietf.org; Mon, 30 May 2005 11:08:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20817 for ; Mon, 30 May 2005 11:08:41 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DcmC7-0002EY-VM for ipsec@ietf.org; Mon, 30 May 2005 11:28:49 -0400 Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j4UF8SEP039963; Mon, 30 May 2005 08:08:29 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <8b02f743ec65aaa19084de0e2fb904da@checkpoint.com> References: <28f349eff556418e96f473a282592b5c@checkpoint.com> <8b02f743ec65aaa19084de0e2fb904da@checkpoint.com> Date: Mon, 30 May 2005 08:08:25 -0700 To: Yoav Nir From: Paul Hoffman Subject: Re: [Ipsec] Question about Integrity Checksum Data Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: ipsec@ietf.org, "" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 9:52 AM +0300 5/30/05, Yoav Nir wrote: >So if I'm using the UI suite VPN-A, whenever I'm using IKEv1 I will >use the integrity algorithm SHA1 (with a 160-bit checksum field), >but whenever I'm using IKEv2 I will use the SHA1_96 integrity >algorithm (with a 96-bit checksum field). > >Is this correct? No. In IKEv1, you will use the hash algorithm SHA1, and the integrity algorithm HMAC-SHA1, just as you do now. The UI suite doesn't change that at all. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec