From ipsec-bounces@ietf.org Thu Sep 01 12:29:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EArwR-0003zD-R4; Thu, 01 Sep 2005 12:29:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EArwP-0003wq-Lo for ipsec@megatron.ietf.org; Thu, 01 Sep 2005 12:29:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13517 for ; Thu, 1 Sep 2005 12:29:27 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EAryN-00040o-Sz for ipsec@ietf.org; Thu, 01 Sep 2005 12:31:33 -0400 Received: (qmail 23268 invoked by uid 0); 1 Sep 2005 16:29:23 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.39.220) by woodstock.binhost.com with SMTP; 1 Sep 2005 16:29:23 -0000 Message-Id: <6.2.1.2.2.20050901122754.07058890@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 01 Sep 2005 12:29:17 -0400 To: ipsec@ietf.org From: Russ Housley Mime-Version: 1.0 X-Spam-Score: 0.8 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Subject: [Ipsec] IESG approved draft-hoffman-rfc3664bis-04 today 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="===============1983498118==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1983498118== Content-Type: text/html; charset="us-ascii" This document ( draft-hoffman-rfc3664bis-04.txt) was approved today.  It should appear in the RFC Editor queue soon.

Russ --===============1983498118== 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 --===============1983498118==-- From ipsec-bounces@ietf.org Fri Sep 02 19:36:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBL5W-0006nv-9z; Fri, 02 Sep 2005 19:36:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBL5U-0006jk-Pk for ipsec@megatron.ietf.org; Fri, 02 Sep 2005 19:36:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18562 for ; Fri, 2 Sep 2005 19:36:45 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBL7i-0001iA-V3 for ipsec@ietf.org; Fri, 02 Sep 2005 19:39:08 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j82NaNG31947 for ; Sat, 3 Sep 2005 01:36:23 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j82NaO9A078955 for ; Sat, 3 Sep 2005 01:36:24 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509022336.j82NaO9A078955@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipsec@ietf.org Date: Sat, 03 Sep 2005 01:36:24 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Ipsec] ICMP and MH TSs for 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 Even with the clarification draft the real world use of traffic selectors with ICMP type/code or MH (Mobile IPv6 Header message) type is not very clear: - IKEv2 (and IKEv1) establishes SAs by pairs, so if traffic from the initiator matches TSi -> TSr then is protected, the traffic from the responder which matches TSr -> TSi is protected too. - applied to ICMP does this mean that the selected type(s)/code(s) is/are protected in both way? (I think so according to the RFC 2401bis 4.4.1 about SPD-S directionality) - the MH type is in the local "port" selector. What is the "local" TS, TSi only, or MH type and ICMP type/code are "aligned" (and how)? Regards Francis.Dupont@enst-bretagne.fr PS: ipsec-tools seems to put the type in the source port and the code in the destination port. The RFC 2401bis SPD syntax has 0, 1 or 2 upper layer protocol items with at most one for ICMP, MH and ICMPv6. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Sep 03 05:19:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBUBW-0005pq-KJ; Sat, 03 Sep 2005 05:19:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBUBU-0005pi-5d for ipsec@megatron.ietf.org; Sat, 03 Sep 2005 05:19:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23973 for ; Sat, 3 Sep 2005 05:19:34 -0400 (EDT) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBUDm-0001TX-JN for ipsec@ietf.org; Sat, 03 Sep 2005 05:22:01 -0400 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.4/8.13.4/Debian-3) with ESMTP id j839JPuY019063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 3 Sep 2005 12:19:25 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.4/8.13.4/Submit) id j839JOXk019059; Sat, 3 Sep 2005 12:19:24 +0300 Date: Sat, 3 Sep 2005 12:19:24 +0300 Message-Id: <200509030919.j839JOXk019059@burp.tkv.asdf.org> From: Markku Savela To: Francis.Dupont@enst-bretagne.fr In-reply-to: <200509022336.j82NaO9A078955@givry.rennes.enst-bretagne.fr> (message from Francis Dupont on Sat, 03 Sep 2005 01:36:24 +0200) Subject: Re: [Ipsec] ICMP and MH TSs for IKEv2 References: <200509022336.j82NaO9A078955@givry.rennes.enst-bretagne.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 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 > From: Francis Dupont > Even with the clarification draft the real world use of traffic selectors > with ICMP type/code or MH (Mobile IPv6 Header message) type is not > very clear: > - IKEv2 (and IKEv1) establishes SAs by pairs, so if traffic from > the initiator matches TSi -> TSr then is protected, the traffic > from the responder which matches TSr -> TSi is protected too. > - applied to ICMP does this mean that the selected type(s)/code(s) is/are > protected in both way? (I think so according to the RFC 2401bis 4.4.1 > about SPD-S directionality) > - the MH type is in the local "port" selector. What is the "local" TS, > TSi only, or MH type and ICMP type/code are "aligned" (and how)? I'm starting to lean on solution, where ICMP/MH type/code's in SA's TS would always be in both local/remote port (or src/dst port). This way, even multicast SA's would work without any special handling (an MC SA that would be used for both receiving and sending). _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Sep 03 06:13:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBV1v-000641-NW; Sat, 03 Sep 2005 06:13:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EBV1s-00063w-E7 for ipsec@megatron.ietf.org; Sat, 03 Sep 2005 06:13:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27730 for ; Sat, 3 Sep 2005 06:13:42 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EBV4C-00037r-FO for ipsec@ietf.org; Sat, 03 Sep 2005 06:16:09 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j83ADIG02085; Sat, 3 Sep 2005 12:13:18 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j83ADIgg081020; Sat, 3 Sep 2005 12:13:18 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509031013.j83ADIgg081020@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku Savela Subject: Re: [Ipsec] ICMP and MH TSs for IKEv2 In-reply-to: Your message of Sat, 03 Sep 2005 12:19:24 +0300. <200509030919.j839JOXk019059@burp.tkv.asdf.org> Date: Sat, 03 Sep 2005 12:13:18 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 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 In your previous mail you wrote: > - the MH type is in the local "port" selector. What is the "local" TS, > TSi only, or MH type and ICMP type/code are "aligned" (and how)? I'm starting to lean on solution, where ICMP/MH type/code's in SA's TS would always be in both local/remote port (or src/dst port). This way, even multicast SA's would work without any special handling (an MC SA that would be used for both receiving and sending). => I agree this solution seems good but it was only suggested and only for ICMP in the clarifications I-D. Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 05 13:06:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECKQi-0008VF-Le; Mon, 05 Sep 2005 13:06:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECKQg-0008VA-BW for ipsec@megatron.ietf.org; Mon, 05 Sep 2005 13:06:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24930 for ; Mon, 5 Sep 2005 13:06:43 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECKTS-00033Q-6z for ipsec@ietf.org; Mon, 05 Sep 2005 13:09:40 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j85H5F8L003561; Mon, 5 Sep 2005 20:05:20 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Sep 2005 20:06:35 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 5 Sep 2005 20:01:26 +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] ICMP and MH TSs for IKEv2 Date: Mon, 5 Sep 2005 20:01:26 +0300 Message-ID: Thread-Topic: [Ipsec] ICMP and MH TSs for IKEv2 Thread-Index: AcWwcNxfq9YxFHrxS0GAtVw3q1B27gByoxcQ To: , X-OriginalArrivalTime: 05 Sep 2005 17:01:26.0815 (UTC) FILETIME=[73F492F0:01C5B23B] X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 Francis Dupont wrote: > In your previous mail you wrote: >=20 > > - the MH type is in the local "port" selector. What is=20 > > the "local" TS, TSi only, or MH type and ICMP type/code=20 > > are "aligned" (and how)? > =20 > I'm starting to lean on solution, where ICMP/MH type/code's=20 > in SA's TS would always be in both local/remote port (or=20 < src/dst port). This way, even multicast SA's would work=20 > without any special handling (an MC SA that would be used=20 > for both receiving and sending). > =20 > =3D> I agree this solution seems good but it was only suggested and=20 > only for ICMP in the clarifications I-D. I agree, this solution seems to apply both to ICMP and MH. We'll=20 add some text about this in the next version of the clarifications=20 I-D (hopefully appearing before the Toronto IPsec/IKEv2 interop). Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 06 11:11:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECf79-0000fq-Ar; Tue, 06 Sep 2005 11:11:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ECf77-0000fb-VO for ipsec@megatron.ietf.org; Tue, 06 Sep 2005 11:11:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03055 for ; Tue, 6 Sep 2005 11:11:55 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ECfA6-0007yI-HI for ipsec@ietf.org; Tue, 06 Sep 2005 11:15:03 -0400 Received: from [192.168.0.175] (dommiel.bbn.com [192.1.122.15]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j86FB1Dh008806; Tue, 6 Sep 2005 11:11:28 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 6 Sep 2005 10:40:43 -0400 To: Pasi.Eronen@nokia.com From: Stephen Kent Subject: RE: [Ipsec] ICMP and MH TSs for IKEv2 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: 52e1467c2184c31006318542db5614d5 Cc: ipsec@ietf.org, Francis.Dupont@enst-bretagne.fr 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:01 PM +0300 9/5/05, Pasi.Eronen@nokia.com wrote: >Francis Dupont wrote: >> In your previous mail you wrote: >> >> > - the MH type is in the local "port" selector. What is >> > the "local" TS, TSi only, or MH type and ICMP type/code >> > are "aligned" (and how)? >> >> I'm starting to lean on solution, where ICMP/MH type/code's >> in SA's TS would always be in both local/remote port (or >< src/dst port). This way, even multicast SA's would work >> without any special handling (an MC SA that would be used >> for both receiving and sending). >> >> => I agree this solution seems good but it was only suggested and >> only for ICMP in the clarifications I-D. > >I agree, this solution seems to apply both to ICMP and MH. We'll >add some text about this in the next version of the clarifications >I-D (hopefully appearing before the Toronto IPsec/IKEv2 interop). > >Best regards, >Pasi Guys, We specifically allow asymmetry for ICMP traffic for an SA, e.g., so that one can send but not accept traffic for a given ICMP message type for an SA. I believe we discussed this issue on the list at the time the decision was made, so please do not plan to just change by treating it as a clarification. 2401-bis would also have to change, not just IKEv2. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 07 03: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 1ECuoo-0008Jc-LN; Wed, 07 Sep 2005 03: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 1ECuol-0008J0-Bs for ipsec@megatron.ietf.org; Wed, 07 Sep 2005 03:58:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03449 for ; Wed, 7 Sep 2005 03:58:02 -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.43) id 1ECurt-0004k2-NH for ipsec@ietf.org; Wed, 07 Sep 2005 04:01:18 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j877vftE006853; Wed, 7 Sep 2005 10:57:48 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Sep 2005 10:55:51 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Sep 2005 10:55:51 +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] ICMP and MH TSs for IKEv2 Date: Wed, 7 Sep 2005 10:55:50 +0300 Message-ID: Thread-Topic: [Ipsec] ICMP and MH TSs for IKEv2 Thread-Index: AcWy+tj7PZ3Gnke5Tb2+Sp8eIgngBgAgNiyA To: X-OriginalArrivalTime: 07 Sep 2005 07:55:51.0262 (UTC) FILETIME=[90DF17E0:01C5B381] X-Spam-Score: 0.3 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 Stephen Kent wrote: > Guys, >=20 > We specifically allow asymmetry for ICMP traffic for an SA, > e.g., so that one can send but not accept traffic for a given > ICMP message type for an SA. I believe we discussed this issue > on the list at the time the decision was made, so please do > not plan to just change by treating it as a clarification. >=20 > 2401-bis would also have to change, not just IKEv2. I agree that having this kind of asymmetry makes sense in some situations (and is very easy to accomplish in 2401-bis). However,=20 it's not clear whether IKEv2 can actually negotiate such SAs,=20 since it assumes SAs are created in (roughly) symmetrical pairs. (I don't see this as a big problem, though; e.g. 2401-bis allows asymmetrical SAs for UDP traffic as well, and IKEv2 doesn't seem to support that either.) What we're trying to clarify is what exactly the TSi/TSr payloads in CREATE_CHILD_SA exchange should contain even in the (presumably simpler) case where you want symmetrical treatment for ICMP. The reason some kind of clarification is needed is that in 2401-bis, an SPD entry for ICMP has only one "port" field ("OneNextLayerProtocol" element in ASN.1 code of Appendix C). But in IKEv2, both TSi and TSr payloads have port fields, so if we have only one value (ICMP type/code or MH type), what to do. The obvious solutions seem to be (1) put the one value in TSi payload and leave the port in TSr as zero, (2) vice versa, or (3) put the same value both to TSi and TSr payloads. IKEv2 spec doesn't say which was intended, so some kind of clarification is needed (and currently we're leaning towards option 3, although the choice doesn't really matter as long as all implementors agree which it is). Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 07 12:07:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED2S3-0002qp-MX; Wed, 07 Sep 2005 12:07:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED2S1-0002qg-IB for ipsec@megatron.ietf.org; Wed, 07 Sep 2005 12:07:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA29046 for ; Wed, 7 Sep 2005 12:07:03 -0400 (EDT) Received: from coliposte.enst-bretagne.fr ([192.108.115.12]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ED2VB-0001rh-1y for ipsec@ietf.org; Wed, 07 Sep 2005 12:10:24 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by coliposte.enst-bretagne.fr (8.12.10/8.12.10/2004.10.03) with ESMTP id j87G6Td3030011; Wed, 7 Sep 2005 18:06:29 +0200 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by coliposte.enst-bretagne.fr (8.12.10/8.12.10/2004.09.01) with ESMTP id j87G6OlO029974; Wed, 7 Sep 2005 18:06:24 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j87G6OkU000855; Wed, 7 Sep 2005 18:06:24 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509071606.j87G6OkU000855@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com Subject: Re: [Ipsec] ICMP and MH TSs for IKEv2 In-reply-to: Your message of Wed, 07 Sep 2005 10:55:50 +0300. Date: Wed, 07 Sep 2005 18:06:24 +0200 X-Virus-Scanned: amavisd-new at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ipsec@ietf.org, kent@bbn.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 In your previous mail you wrote: I agree that having this kind of asymmetry makes sense in some situations (and is very easy to accomplish in 2401-bis). However, it's not clear whether IKEv2 can actually negotiate such SAs, since it assumes SAs are created in (roughly) symmetrical pairs. => in fact there is a real issue about what means symmetrical in this context... (I don't see this as a big problem, though; e.g. 2401-bis allows asymmetrical SAs for UDP traffic as well, and IKEv2 doesn't seem to support that either.) => where is it in the 2401-bis? What we're trying to clarify is what exactly the TSi/TSr payloads in CREATE_CHILD_SA exchange should contain even in the (presumably simpler) case where you want symmetrical treatment for ICMP. => I agree but if we can solve the asymmetrical case too... The reason some kind of clarification is needed is that in 2401-bis, an SPD entry for ICMP has only one "port" field ("OneNextLayerProtocol" element in ASN.1 code of Appendix C). => IMHO this OneNextLayerProtocol specifies explicitely symmetrical case. But in IKEv2, both TSi and TSr payloads have port fields, so if we have only one value (ICMP type/code or MH type), what to do. The obvious solutions seem to be (1) put the one value in TSi payload and leave the port in TSr as zero, (2) vice versa, or (3) put the same value both to TSi and TSr payloads. IKEv2 spec doesn't say which was intended, so some kind of clarification is needed (and currently we're leaning towards option 3, although the choice doesn't really matter as long as all implementors agree which it is). => for the asymmetrical case we can imagine a (4) with the value for traffic from local to remote in the local port and the value for the other way in the remote port. This makes more sense for Mobility where traffics are known to be always asymmetrical! Thanks Francis.Dupont@enst-bretagne.fr PS: BTW both IKEv2 and RFC 2401bis should be updated about this point. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 07 12:34:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED2sf-00037o-Lq; Wed, 07 Sep 2005 12:34:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ED2se-000379-0b for ipsec@megatron.ietf.org; Wed, 07 Sep 2005 12:34:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00625 for ; Wed, 7 Sep 2005 12:34:33 -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.43) id 1ED2vp-0002lI-Nt for ipsec@ietf.org; Wed, 07 Sep 2005 12:37:55 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j87GYFCG007376; Wed, 7 Sep 2005 19:34:16 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Sep 2005 19:34:16 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 7 Sep 2005 19:34:16 +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] ICMP and MH TSs for IKEv2 Date: Wed, 7 Sep 2005 19:34:15 +0300 Message-ID: Thread-Topic: [Ipsec] ICMP and MH TSs for IKEv2 Thread-Index: AcWzxkPi6IGV+vYDS4ORLjJc+2wSVwAAR+Cw To: , X-OriginalArrivalTime: 07 Sep 2005 16:34:16.0279 (UTC) FILETIME=[FCE80670:01C5B3C9] X-Spam-Score: 0.3 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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 Francis Dupont wrote: >=20 > In your previous mail you wrote: >=20 > I agree that having this kind of asymmetry makes sense in some > situations (and is very easy to accomplish in 2401-bis). However,=20 > it's not clear whether IKEv2 can actually negotiate such SAs,=20 > since it assumes SAs are created in (roughly) symmetrical pairs. > =20 > =3D> in fact there is a real issue about what means symmetrical in > this context... Yes, there are probably several possible meanings. I meant a situation where, say, ICMP type 8 from host A to B is protected one way (say, ESP with AES), but ICMP type 8 in the=20 other direction (B to A) is done some other way (say, no IPsec=20 processing at all, or AH only). > (I don't see this as a big problem, though; e.g. 2401-bis allows > asymmetrical SAs for UDP traffic as well, and IKEv2 doesn't seem > to support that either.) > =20 > =3D> where is it in the 2401-bis? It's probably not explicitly mentioned, but it's easy to get that situation if you configure your SPD/SAD manually. > What we're trying to clarify is what exactly the TSi/TSr > payloads in CREATE_CHILD_SA exchange should contain even in the > (presumably simpler) case where you want symmetrical treatment > for ICMP. > =20 > =3D> I agree but if we can solve the asymmetrical case too... >=20 > The reason some kind of clarification is needed is that in > 2401-bis, an SPD entry for ICMP has only one "port" field > ("OneNextLayerProtocol" element in ASN.1 code of Appendix C). >=20 > =3D> IMHO this OneNextLayerProtocol specifies explicitely=20 > symmetrical case. Depends on what exactly is meant by "symmetrical", I guess. It's not symmetrical in the sense that it allows the situation I described above (traffic in different directions get different treatment). > But in IKEv2, both TSi and TSr payloads have port fields, so if > we have only one value (ICMP type/code or MH type), what to do. > =20 > The obvious solutions seem to be (1) put the one value in TSi > payload and leave the port in TSr as zero, (2) vice versa, or > (3) put the same value both to TSi and TSr payloads. IKEv2 spec > doesn't say which was intended, so some kind of clarification is > needed (and currently we're leaning towards option 3, although > the choice doesn't really matter as long as all implementors > agree which it is). > =20 > =3D> for the asymmetrical case we can imagine a (4) with the value for > traffic from local to remote in the local port and the value for the > other way in the remote port. This makes more sense for Mobility > where traffics are known to be always asymmetrical! > PS: BTW both IKEv2 and RFC 2401bis should be updated about this point. I don't see why 2401bis would need any updates. And I'm definitely against adding any new functionality to IKEv2 at this stage. Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 08 02:28:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDFtV-0000ui-H9; Thu, 08 Sep 2005 02:28:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDFtS-0000uX-DS for ipsec@megatron.ietf.org; Thu, 08 Sep 2005 02:28:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01521 for ; Thu, 8 Sep 2005 02:28:16 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDFwm-0001EM-DT for ipsec@ietf.org; Thu, 08 Sep 2005 02:31:44 -0400 Received: from [192.168.0.195] (dommiel.bbn.com [192.1.122.15]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j886S2Dd010224; Thu, 8 Sep 2005 02:28:03 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 8 Sep 2005 02:27:56 -0400 To: Pasi.Eronen@nokia.com From: Stephen Kent Subject: RE: [Ipsec] ICMP and MH TSs for IKEv2 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.6 (/) X-Scan-Signature: 850245b51c39701e2700a112f3032caa 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: , Content-Type: multipart/mixed; boundary="===============1356190761==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1356190761== Content-Type: multipart/alternative; boundary="============_-1085961612==_ma============" --============_-1085961612==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 10:55 AM +0300 9/7/05, Pasi.Eronen@nokia.com wrote: >Stephen Kent wrote: >> Guys, >> >> We specifically allow asymmetry for ICMP traffic for an SA, >> e.g., so that one can send but not accept traffic for a given >> ICMP message type for an SA. I believe we discussed this issue >> on the list at the time the decision was made, so please do >> not plan to just change by treating it as a clarification. >> >> 2401-bis would also have to change, not just IKEv2. > >I agree that having this kind of asymmetry makes sense in some >situations (and is very easy to accomplish in 2401-bis). However, >it's not clear whether IKEv2 can actually negotiate such SAs, >since it assumes SAs are created in (roughly) symmetrical pairs. My recollection was that Charlie Lynn provided the text to Charlie Kaufman to try to ensure that the two specs were compatible. In any case, 2401-bis makes an explicit statement about the asymmetry, so irrespective of how IKEv2 thinks of the data it exchanged, IPsec says how to interpret the received data re local access controls. In 4.4.1.3 2401-bis says: D. To indicate that a system is willing to receive traffic with a particular "port" value but NOT send that kind of traffic, the system's traffic selectors are set as follows in the relevant SPD entry: Local's next layer protocol = ICMP "port" selector = OPAQUE Remote's next layer protocol = ICMP "port" selector = For example, if a security gateway is willing to allow systems behind it to send ICMP traceroutes, but is not willing to let outside systems run ICMP traceroutes to systems behind it, then the security gateway's traffic selectors are set as follows in the relevant SPD entry: Local's next layer protocol = 1 (ICMPv4) "port" selector = 30 (traceroute) Remote's next layer protocol = 1 (ICMPv4) "port" selector = OPAQUE This is a pretty explicit description of how to express asymmetry for exactly this purpose, with an example and rationale. >(I don't see this as a big problem, though; e.g. 2401-bis allows >asymmetrical SAs for UDP traffic as well, and IKEv2 doesn't seem >to support that either.) Could you clarify the statement that IKEv2 doesn't support this asymmetry? IKE has two functions re these traffic selectors: it exchanges them and it interprets them as being acceptable relative to the SPD. I'd like to think that since 2401-bis defines how the non-IKE part of IPsec works, that it's definition of how to interpret SPD entries takes precedence in local processing. I know we lost this argument last time when we discovered, belatedly, that IKEv2 didn't have the same semantics for multiple pairs of S/D addresses for an entry. We modified the 2401-bis text to accommodate IKEv2 because the needed change was too great, despite the fact that the semantics were unduly limiting. I am not inclined to do this again. >What we're trying to clarify is what exactly the TSi/TSr >payloads in CREATE_CHILD_SA exchange should contain even in the >(presumably simpler) case where you want symmetrical treatment >for ICMP. > >The reason some kind of clarification is needed is that in >2401-bis, an SPD entry for ICMP has only one "port" field >("OneNextLayerProtocol" element in ASN.1 code of Appendix C). >But in IKEv2, both TSi and TSr payloads have port fields, so if >we have only one value (ICMP type/code or MH type), what to do. > >The obvious solutions seem to be (1) put the one value in TSi >payload and leave the port in TSr as zero, (2) vice versa, or >(3) put the same value both to TSi and TSr payloads. IKEv2 spec >doesn't say which was intended, so some kind of clarification is >needed (and currently we're leaning towards option 3, although >the choice doesn't really matter as long as all implementors >agree which it is). I agree that clarification on how to translate into IKE payloads is needed, but the intent in 2401-bis is very clear. Steve --============_-1085961612==_ma============ Content-Type: text/html; charset="us-ascii" RE: [Ipsec] ICMP and MH TSs for IKEv2
At 10:55 AM +0300 9/7/05, Pasi.Eronen@nokia.com wrote:
Stephen Kent wrote:
> Guys,
>
> We specifically allow asymmetry for ICMP traffic for an SA,
> e.g., so that one can send but not accept traffic for a given
> ICMP message type for an SA. I believe we discussed this issue
> on the list at the time the decision was made, so please do
> not plan to just change by treating it as a clarification.
>
> 2401-bis would also have to change, not just IKEv2.

I agree that having this kind of asymmetry makes sense in some
situations (and is very easy to accomplish in 2401-bis). However,
it's not clear whether IKEv2 can actually negotiate such SAs,
since it assumes SAs are created in (roughly) symmetrical pairs.

My recollection was that Charlie Lynn provided the text to Charlie Kaufman to try to ensure that the two specs were compatible. In any case, 2401-bis makes an explicit statement about the asymmetry, so irrespective of how IKEv2 thinks of the data it exchanged, IPsec says how to interpret the received data re local access controls.  In 4.4.1.3 2401-bis says:


        D. To indicate that a system is willing to receive traffic
           with a particular "port" value but NOT send that kind of
           traffic, the system's traffic selectors are set as follows
           in the relevant SPD entry:

           Local's
             next layer protocol = ICMP
             "port" selector     = OPAQUE
           Remote's
             next layer protocol = ICMP
             "port" selector     = <specific ICMP type & code>

            For example, if a security gateway is willing to allow
           systems behind it to send ICMP traceroutes, but is not
           willing to let outside systems run ICMP traceroutes to
           systems behind it, then the security gateway's traffic
           selectors are set as follows in the relevant SPD entry:

           Local's
             next layer protocol = 1 (ICMPv4)
             "port" selector     = 30 (traceroute)

           Remote's
             next layer protocol = 1 (ICMPv4)
             "port" selector     = OPAQUE
This is a pretty explicit description of how to express asymmetry for exactly this purpose, with an example and rationale.

(I don't see this as a big problem, though; e.g. 2401-bis allows
asymmetrical SAs for UDP traffic as well, and IKEv2 doesn't seem
to support that either.)

Could you clarify the statement that IKEv2 doesn't support this asymmetry? IKE has two functions re these traffic selectors: it exchanges them and it interprets them as being acceptable relative to the SPD. I'd like to think that since 2401-bis defines how the non-IKE part of IPsec works, that it's definition of how to interpret SPD entries takes precedence in local processing. I know we lost this argument last time when we discovered, belatedly, that IKEv2 didn't have the same semantics for multiple pairs of S/D addresses for an entry. We modified the 2401-bis text to accommodate IKEv2 because the needed change was too great, despite the fact that the semantics were unduly limiting.  I am not inclined to do this again.

What we're trying to clarify is what exactly the TSi/TSr
payloads in CREATE_CHILD_SA exchange should contain even in the
(presumably simpler) case where you want symmetrical treatment
for ICMP.

The reason some kind of clarification is needed is that in
2401-bis, an SPD entry for ICMP has only one "port" field
("OneNextLayerProtocol" element in ASN.1 code of Appendix C).
But in IKEv2, both TSi and TSr payloads have port fields, so if
we have only one value (ICMP type/code or MH type), what to do.

The obvious solutions seem to be (1) put the one value in TSi
payload and leave the port in TSr as zero, (2) vice versa, or
(3) put the same value both to TSi and TSr payloads. IKEv2 spec
doesn't say which was intended, so some kind of clarification is
needed (and currently we're leaning towards option 3, although
the choice doesn't really matter as long as all implementors
agree which it is).

I agree that clarification on how to translate into IKE payloads is needed, but the intent in 2401-bis is very clear.

Steve
--============_-1085961612==_ma============-- --===============1356190761== 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 --===============1356190761==-- From ipsec-bounces@ietf.org Thu Sep 08 06:13:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDJPX-0000UV-Ht; Thu, 08 Sep 2005 06:13:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDJPV-0000TE-CN for ipsec@megatron.ietf.org; Thu, 08 Sep 2005 06:13:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA10504 for ; Thu, 8 Sep 2005 06:13:34 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDJSq-0007Dh-B6 for ipsec@ietf.org; Thu, 08 Sep 2005 06:17:06 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j88ACwU13022; Thu, 8 Sep 2005 12:12:58 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j88ACvdW004388; Thu, 8 Sep 2005 12:12:57 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509081012.j88ACvdW004388@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pasi.Eronen@nokia.com Subject: Re: [Ipsec] ICMP and MH TSs for IKEv2 In-reply-to: Your message of Wed, 07 Sep 2005 19:34:15 +0300. Date: Thu, 08 Sep 2005 12:12:57 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Cc: ipsec@ietf.org, kent@bbn.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 In your previous mail you wrote: Francis Dupont wrote: > > In your previous mail you wrote: > > I agree that having this kind of asymmetry makes sense in some > situations (and is very easy to accomplish in 2401-bis). However, > it's not clear whether IKEv2 can actually negotiate such SAs, > since it assumes SAs are created in (roughly) symmetrical pairs. > > => in fact there is a real issue about what means symmetrical in > this context... Yes, there are probably several possible meanings. I meant a situation where, say, ICMP type 8 from host A to B is protected one way (say, ESP with AES), but ICMP type 8 in the other direction (B to A) is done some other way (say, no IPsec processing at all, or AH only). => so call this situation the asymmetrical case for ICMP. It is not (yet) possible with 2401bis/IKEv2 mainly by lack of accurate wording. > (I don't see this as a big problem, though; e.g. 2401-bis allows > asymmetrical SAs for UDP traffic as well, and IKEv2 doesn't seem > to support that either.) > > => where is it in the 2401-bis? It's probably not explicitly mentioned, but it's easy to get that situation if you configure your SPD/SAD manually. => I can't see how to configure the SPD-S to get this. IMHO it seems the rfc2041bis SPD-S and IKEv2 have now equivalent capabilities, i.e., on the contrary of RFC 2401 and IKEv1, the rfc2401bis is not more "powerful" than IKEv2. > The reason some kind of clarification is needed is that in > 2401-bis, an SPD entry for ICMP has only one "port" field > ("OneNextLayerProtocol" element in ASN.1 code of Appendix C). > > => IMHO this OneNextLayerProtocol specifies explicitely > symmetrical case. Depends on what exactly is meant by "symmetrical", I guess. => the opposite of the "asymetrical situation". It's not symmetrical in the sense that it allows the situation I described above (traffic in different directions get different treatment). => how? the OneNextLayerProtocol is not attached to one side. > The obvious solutions seem to be (1) put the one value in TSi > payload and leave the port in TSr as zero, (2) vice versa, or > (3) put the same value both to TSi and TSr payloads. IKEv2 spec > doesn't say which was intended, so some kind of clarification is > needed (and currently we're leaning towards option 3, although > the choice doesn't really matter as long as all implementors > agree which it is). > > => for the asymmetrical case we can imagine a (4) with the value for > traffic from local to remote in the local port and the value for the > other way in the remote port. This makes more sense for Mobility > where traffics are known to be always asymmetrical! => I should have added that (4) is the natural extension of (3), i.e., if (4) is the rule a symmetrical config will give (3). > PS: BTW both IKEv2 and RFC 2401bis should be updated about this point. I don't see why 2401bis would need any updates. => how the asymmetrical situation is handled is not described in a sound (or even clear enough) way. And I'm definitely against adding any new functionality to IKEv2 at this stage. => according to Stephen, this is not a new functionality, it is a functionality we agreed about but which is not described in a clear enough/ sound way (and here only the "clear enough" applies to IKEv2). Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 08 08:34:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDLc3-00065U-8U; Thu, 08 Sep 2005 08:34:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDLc1-000632-AO for ipsec@megatron.ietf.org; Thu, 08 Sep 2005 08:34:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16441 for ; Thu, 8 Sep 2005 08:34:39 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDLfN-0002Jc-5R for ipsec@ietf.org; Thu, 08 Sep 2005 08:38:11 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j88CY5U22109; Thu, 8 Sep 2005 14:34:05 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j88CY44h005537; Thu, 8 Sep 2005 14:34:04 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509081234.j88CY44h005537@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Stephen Kent Subject: Re: [Ipsec] ICMP and MH TSs for IKEv2 In-reply-to: Your message of Thu, 08 Sep 2005 02:27:56 EDT. Date: Thu, 08 Sep 2005 14:34:04 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 In your previous mail you wrote: >I agree that having this kind of asymmetry makes sense in some >situations (and is very easy to accomplish in 2401-bis). However, >it's not clear whether IKEv2 can actually negotiate such SAs, >since it assumes SAs are created in (roughly) symmetrical pairs. My recollection was that Charlie Lynn provided the text to Charlie Kaufman to try to ensure that the two specs were compatible. In any case, 2401-bis makes an explicit statement about the asymmetry, so irrespective of how IKEv2 thinks of the data it exchanged, IPsec says how to interpret the received data re local access controls. In 4.4.1.3 2401-bis says: D. To indicate that a system is willing to receive traffic with a particular "port" value but NOT send that kind of traffic, the system's traffic selectors are set as follows in the relevant SPD entry: Local's next layer protocol = ICMP "port" selector = OPAQUE Remote's next layer protocol = ICMP "port" selector = => this is fine: - we know how to express asymmetry for ICMP in 2401-bis - we can derive what to put in IKEv2 TSs But IMHO there are some small details to fix: - what is the difference between B and C? - remove the local in "the 16-bit local "port" selector." for MH, 4.4.1.1 - should B mention that C and D are valid options (i.e., MH and ICMP are handled the same way)? I agree that clarification on how to translate into IKE payloads is needed, but the intent in 2401-bis is very clear. => as soon as 2401-bis will be really "very clear" I believe the clarification will be "very easy". Thanks Francis.Dupont@enst-bretagne.fr PS: BTW what is the first/second in AnyNextLayers? _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 08 08:42:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDLjy-0008Dh-BN; Thu, 08 Sep 2005 08:42:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDLju-0008D4-5y for ipsec@megatron.ietf.org; Thu, 08 Sep 2005 08:42:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16965 for ; Thu, 8 Sep 2005 08:42:48 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDLnF-0002a7-HX for ipsec@ietf.org; Thu, 08 Sep 2005 08:46:20 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j88Cf7Rh008252; Thu, 8 Sep 2005 15:41:09 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Sep 2005 15:42:33 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Sep 2005 15:42:26 +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] ICMP and MH TSs for IKEv2 Date: Thu, 8 Sep 2005 15:42:22 +0300 Message-ID: Thread-Topic: [Ipsec] ICMP and MH TSs for IKEv2 Thread-Index: AcW0PpzE1u3S3kkMQDCcTueauhzOIAAM/XRQ To: X-OriginalArrivalTime: 08 Sep 2005 12:42:26.0343 (UTC) FILETIME=[C459FB70:01C5B472] X-Spam-Score: 0.3 (/) X-Scan-Signature: 37af5f8fbf6f013c5b771388e24b09e7 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 Hmm, it seems that I was wrong in my earlier messages about this=20 (and the text I wrote for ikev2-clarifications-04 section 4.8 is=20 wrong, too -- will be fixed in the next version). Re-reading=20 2401bis Section 4.4.1.3 very carefully seems to actually clarify=20 this issue. ...except that "Case B" probably has a typo: if the SPD entry applies both to sending and receiving, the MH message type (or ICMP type/code) should be in both local and remote port, right? (Otherwise it's indistinguishable from Case C which=20 applies only to sending.) Best regards, Pasi -----Original Message----- From: ext Stephen Kent [mailto:kent@bbn.com] Sent: Thursday, September 08, 2005 9:28 AM To: Eronen Pasi (Nokia-NRC/Helsinki) Cc: ipsec@ietf.org Subject: RE: [Ipsec] ICMP and MH TSs for IKEv2 At 10:55 AM +0300 9/7/05, Pasi.Eronen@nokia.com wrote: Stephen Kent wrote: > Guys, > > We specifically allow asymmetry for ICMP traffic for an SA, > e.g., so that one can send but not accept traffic for a given > ICMP message type for an SA. I believe we discussed this issue > on the list at the time the decision was made, so please do > not plan to just change by treating it as a clarification. > > 2401-bis would also have to change, not just IKEv2. I agree that having this kind of asymmetry makes sense in some situations (and is very easy to accomplish in 2401-bis). However, it's not clear whether IKEv2 can actually negotiate such SAs, since it assumes SAs are created in (roughly) symmetrical pairs. My recollection was that Charlie Lynn provided the text to Charlie Kaufman to try to ensure that the two specs were compatible. In any case, 2401-bis makes an explicit statement about the asymmetry, so irrespective of how IKEv2 thinks of the data it exchanged, IPsec says how to interpret the received data re local access controls. In 4.4.1.3 2401-bis says: D. To indicate that a system is willing to receive traffic with a particular "port" value but NOT send that kind of traffic, the system's traffic selectors are set as follows in the relevant SPD entry: Local's next layer protocol =3D ICMP "port" selector =3D OPAQUE Remote's next layer protocol =3D ICMP "port" selector =3D For example, if a security gateway is willing to allow systems behind it to send ICMP traceroutes, but is not willing to let outside systems run ICMP traceroutes to systems behind it, then the security gateway's traffic selectors are set as follows in the relevant SPD entry: Local's next layer protocol =3D 1 (ICMPv4) "port" selector =3D 30 (traceroute) Remote's next layer protocol =3D 1 (ICMPv4) "port" selector =3D OPAQUE This is a pretty explicit description of how to express asymmetry for exactly this purpose, with an example and rationale. (I don't see this as a big problem, though; e.g. 2401-bis allows asymmetrical SAs for UDP traffic as well, and IKEv2 doesn't seem to support that either.) Could you clarify the statement that IKEv2 doesn't support this asymmetry? IKE has two functions re these traffic selectors: it exchanges them and it interprets them as being acceptable relative to the SPD. I'd like to think that since 2401-bis defines how the non-IKE part of IPsec works, that it's definition of how to interpret SPD entries takes precedence in local processing. I know we lost this argument last time when we discovered, belatedly, that IKEv2 didn't have the same semantics for multiple pairs of S/D addresses for an entry. We modified the 2401-bis text to accommodate IKEv2 because the needed change was too great, despite the fact that the semantics were unduly limiting. I am not inclined to do this again. What we're trying to clarify is what exactly the TSi/TSr payloads in CREATE_CHILD_SA exchange should contain even in the (presumably simpler) case where you want symmetrical treatment for ICMP. The reason some kind of clarification is needed is that in 2401-bis, an SPD entry for ICMP has only one "port" field ("OneNextLayerProtocol" element in ASN.1 code of Appendix C). But in IKEv2, both TSi and TSr payloads have port fields, so if we have only one value (ICMP type/code or MH type), what to do. The obvious solutions seem to be (1) put the one value in TSi payload and leave the port in TSr as zero, (2) vice versa, or (3) put the same value both to TSi and TSr payloads. IKEv2 spec doesn't say which was intended, so some kind of clarification is needed (and currently we're leaning towards option 3, although the choice doesn't really matter as long as all implementors agree which it is). I agree that clarification on how to translate into IKE payloads is needed, but the intent in 2401-bis is very clear. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 08 08:57:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDLy8-0003DU-VJ; Thu, 08 Sep 2005 08:57:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDLy5-0003DA-7c for ipsec@megatron.ietf.org; Thu, 08 Sep 2005 08:57:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17823 for ; Thu, 8 Sep 2005 08:57:26 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDM1R-00030T-Fk for ipsec@ietf.org; Thu, 08 Sep 2005 09:00:58 -0400 Received: from [192.168.0.195] (dommiel.bbn.com [192.1.122.15]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j88Cv8Df020295; Thu, 8 Sep 2005 08:57:11 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <200509081234.j88CY44h005537@givry.rennes.enst-bretagne.fr> References: <200509081234.j88CY44h005537@givry.rennes.enst-bretagne.fr> Date: Thu, 8 Sep 2005 08:55:42 -0400 To: Francis Dupont From: Stephen Kent Subject: Re: [Ipsec] ICMP and MH TSs for IKEv2 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.6 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b 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: , Content-Type: multipart/mixed; boundary="===============1506814073==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1506814073== Content-Type: multipart/alternative; boundary="============_-1085938264==_ma============" --============_-1085938264==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Francis, I just spoke with Pasi (here in Athens) and I agree that "B" is wrong and thus confusing. Here is my planned fixed text: B. Even if a Next Layer Protocol has only one selector, e.g., Mobility Header type, then the Local and Remote "port" selectors are used to indicate whether a system is willing to send and/or receive traffic with the specified "port" values. For example, if Mobility Headers of a specified type are allowed to be sent and received via an SA, then the relevant SPD entry would be set as follows: Local's next layer protocol = Mobility Header "port" selector = Mobility Header message type Remote's next layer protocol = Mobility Header "port" selector = Mobility Header message type --============_-1085938264==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Ipsec] ICMP and MH TSs for IKEv2
Francis,

I just spoke with Pasi (here in Athens) and I agree that "B" is wrong and thus confusing.  Here is my planned fixed text:

B. Even if a Next Layer Protocol has only one selector, e.g.,
           Mobility Header type, then the Local and Remote "port"
           selectors are used to indicate whether a system is
           willing to send and/or receive traffic with the specified
          "port" values. For example, if Mobility Headers of a
           specified type are allowed to be sent and received via an
           SA, then the relevant SPD entry would be set as follows:

           Local's
             next layer protocol = Mobility Header
             "port" selector     = Mobility Header message type

           Remote's
             next layer protocol = Mobility Header
             "port" selector     = Mobility Header message type
--============_-1085938264==_ma============-- --===============1506814073== 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 --===============1506814073==-- From ipsec-bounces@ietf.org Thu Sep 08 08:59:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDLzZ-0003gK-Gj; Thu, 08 Sep 2005 08:59:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDLzW-0003dQ-Jk for ipsec@megatron.ietf.org; Thu, 08 Sep 2005 08:58:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA17901 for ; Thu, 8 Sep 2005 08:58:56 -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.43) id 1EDM2s-00032m-TY for ipsec@ietf.org; Thu, 08 Sep 2005 09:02:28 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j88CvSCF012620 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Sep 2005 15:57:28 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j88CvSnp019139; Thu, 8 Sep 2005 15:57:28 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17184.13624.443068.191551@fireball.kivinen.iki.fi> Date: Thu, 8 Sep 2005 15:57:28 +0300 From: Tero Kivinen To: Stephen Kent Subject: RE: [Ipsec] ICMP and MH TSs for IKEv2 In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 12 min 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 Stephen Kent writes: > D. To indicate that a system is willing to receive traffic > with a particular "port" value but NOT send that kind of > traffic, the system's traffic selectors are set as follows > in the relevant SPD entry: > > Local's > next layer protocol = ICMP > "port" selector = OPAQUE > Remote's > next layer protocol = ICMP > "port" selector = > > For example, if a security gateway is willing to allow > systems behind it to send ICMP traceroutes, but is not > willing to let outside systems run ICMP traceroutes to > systems behind it, then the security gateway's traffic > selectors are set as follows in the relevant SPD entry: > > Local's > next layer protocol = 1 (ICMPv4) > "port" selector = 30 (traceroute) > > Remote's > next layer protocol = 1 (ICMPv4) > "port" selector = OPAQUE > > This is a pretty explicit description of how to express asymmetry for > exactly this purpose, with an example and rationale. As the IKEv2 simply specifies that the ICMP type and code are put to the start and end port fields of the traffic selector payload, and it also defines that if the OPAQUE needs to be expressed then it is expressed as setting start port to 65535 and end port to 0, I do not think there is any problem to express that kind of RFC2401bis asymmetric SA within the IKEv2. I.e. the TSi for the traceroute example will be TS type = 4 (TS_IPV4_ADDR_RANGE) IP Protocol ID = 1 (ICMPv4) Start port = 7680 (0x1E00 = type 30 (traceroute), code = 0) End port = 7935 (0x1EFF = type 30 (traceroute), code = 255) Starting address = xxx (the network behind the sgw) Ending address = yyy (the network behind the sgw) And the TSr will be TS type = 4 (TS_IPV4_ADDR_RANGE) IP Protocol ID = 1 (ICMPv4) Start port = 65535 (OPAQUE) End port = 0 (OPAQUE) Starting address = xxx (the network outside the sgw) Ending address = yyy (the network outside the sgw) -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 08 11:19:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDOBd-0005aU-9c; Thu, 08 Sep 2005 11:19:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDOBb-0005Zl-Bq for ipsec@megatron.ietf.org; Thu, 08 Sep 2005 11:19:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA25954 for ; Thu, 8 Sep 2005 11:19:32 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDOEx-0006rg-7W for ipsec@ietf.org; Thu, 08 Sep 2005 11:23:06 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j88FJ8U02396; Thu, 8 Sep 2005 17:19:08 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j88FJ8n0006690; Thu, 8 Sep 2005 17:19:08 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509081519.j88FJ8n0006690@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Stephen Kent Subject: Re: [Ipsec] ICMP and MH TSs for IKEv2 In-reply-to: Your message of Thu, 08 Sep 2005 08:55:42 EDT. Date: Thu, 08 Sep 2005 17:19:08 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 In your previous mail you wrote: I just spoke with Pasi (here in Athens) and I agree that "B" is wrong and thus confusing. Here is my planned fixed text: B. Even if a Next Layer Protocol has only one selector, e.g., Mobility Header type, then the Local and Remote "port" selectors are used to indicate whether a system is willing to send and/or receive traffic with the specified "port" values. For example, if Mobility Headers of a specified type are allowed to be sent and received via an SA, then the relevant SPD entry would be set as follows: Local's next layer protocol = Mobility Header "port" selector = Mobility Header message type Remote's next layer protocol = Mobility Header "port" selector = Mobility Header message type => fine! Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 08 19:24:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDVkp-0005D5-S0; Thu, 08 Sep 2005 19:24:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDVkn-0005CJ-JC for ipsec@megatron.ietf.org; Thu, 08 Sep 2005 19:24:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04607 for ; Thu, 8 Sep 2005 19:24:22 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EDVoF-0006aY-Nd for ipsec@ietf.org; Thu, 08 Sep 2005 19:28:01 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j88NO6S12411; Fri, 9 Sep 2005 01:24:06 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j88NO6aF008898; Fri, 9 Sep 2005 01:24:06 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509082324.j88NO6aF008898@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Stephen Kent Subject: Re: [Ipsec] ICMP and MH TSs for IKEv2 In-reply-to: Your message of Thu, 08 Sep 2005 08:55:42 EDT. Date: Fri, 09 Sep 2005 01:24:06 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 I have another related question: is this valid: Local's next layer protocol = ICMP "port" selector = Remote's next layer protocol = ICMP "port" selector = If yes, is the meaning that systems are willing to send and receive traffic with type1/code1 for traffic from local to remote and type2/code2 for traffic from remote to local? I expect the answer is yes for both questions because IMHO this reflects the intention of 4.4.1.3 for ICMP/MH "ports". Thanks Francis.Dupont@enst-bretagne.fr PS: I believe a message in the list is enough, i.e., no clarification in the 2401-bis document is necessary. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Sep 10 03:11:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDzWa-0008Oo-IK; Sat, 10 Sep 2005 03:11:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EDzWY-0008Oe-Hi for ipsec@megatron.ietf.org; Sat, 10 Sep 2005 03:11:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20296 for ; Sat, 10 Sep 2005 03:11:40 -0400 (EDT) Received: from web61225.mail.yahoo.com ([209.73.179.59]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EDzaC-0007X3-9d for ipsec@ietf.org; Sat, 10 Sep 2005 03:15:34 -0400 Received: (qmail 62189 invoked by uid 60001); 10 Sep 2005 07:11:25 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=L/tMa+I4Gdd+4AUX6k6zmoWkjGwi87SotL81Ud0MGFuyeXMHy7Beb5m4CCUmTFd9G07a/dYOvdjrgKxDVWDWSUdZXS1Rge2vv060cIlzaCzO4+bRotkPKnLXACRZ2llvfGW3YcHw+b4sQVDvlUiTW5Hh7PmoY1GeJq2Lb0DHjNY= ; Message-ID: <20050910071125.62187.qmail@web61225.mail.yahoo.com> Received: from [210.211.230.51] by web61225.mail.yahoo.com via HTTP; Sat, 10 Sep 2005 00:11:24 PDT Date: Sat, 10 Sep 2005 00:11:24 -0700 (PDT) From: venkatarama vishnubhotla To: ipsec@ietf.org, sastryvvr@yahoo.com MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: Subject: [Ipsec] Renual 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="===============1566330033==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1566330033== Content-Type: multipart/alternative; boundary="0-297672906-1126336284=:60904" Content-Transfer-Encoding: 8bit --0-297672906-1126336284=:60904 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Request to renual my maillist subcription for ieft. Thanks Sastry __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-297672906-1126336284=:60904 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit
Request to renual my maillist subcription for ieft.
 Thanks
 Sastry

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-297672906-1126336284=:60904-- --===============1566330033== 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 --===============1566330033==-- From ipsec-bounces@ietf.org Sat Sep 10 10:40:31 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EE6Wt-0004ba-8J; Sat, 10 Sep 2005 10:40:31 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EE6Wr-0004au-Nu for ipsec@megatron.ietf.org; Sat, 10 Sep 2005 10:40:29 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA05680 for ; Sat, 10 Sep 2005 10:40:12 -0400 (EDT) Received: from smtp1.suda.edu.cn ([202.195.128.15] helo=imss) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EE6aC-0008NL-Ed for ipsec@ietf.org; Sat, 10 Sep 2005 10:44:11 -0400 Received: from proxy3.suda.edu.cn ([202.195.140.226]) by imss with InterScan Messaging Security Suite; Sat, 10 Sep 2005 22:52:06 +0800 Received: from dcy (unknown [210.29.174.137]) by proxy3.suda.edu.cn (PMail) with ESMTP id AFBD66CA09 for ; Sat, 10 Sep 2005 22:30:36 +0800 (CST) Date: Sat, 10 Sep 2005 22:39:26 +0800 From: "=?gb2312?B?tsW0utHg?=" <210313041@suda.edu.cn> To: "ipsec@ietf.org" X-mailer: Foxmail 5.0 [cn] Mime-Version: 1.0 Message-Id: <20050910143036.AFBD66CA09@proxy3.suda.edu.cn> X-Spam-Score: 3.1 (+++) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Ipsec] Is there anyone who install 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: , Content-Type: multipart/mixed; boundary="===============1130054259==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1130054259== Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 SEkhDQoNCgkNCglJJ20gc3R1ZHlpbmcgSUtFdjIgbm93LiBSZWNlbnRseSBpIHdhbnQgdG8gaW5z dGFsbCBpa2V2Mi0yMDA1MDkwMiB3cml0dGVuIGJ5IG1hcmN1cGljIGFuZCBzZ3Jvcywgd2hpY2gg aXMgZG93bmxvYWQgZnJvbSBzb3VyY2Vmb3JnZS4gSG93ZXZlcixpdCBmYWlsZWQuIEhlcmUgaXMg c29tZSBlcnJvciBpbmZvLg0KDQoJKDEpIHdoZW4gaW5zdGFsbGluZyBsb2c0YyAxLjAuMTAgoaqh qiBmaXJzdCAuL2NvbmZpZ3VyZSwgdGhlbiBtYWtlLCBidXQgZXJyb3Igb2NjdXJyZWQ6ICANCiAg ICAgICJjZCAuICYmIFwNCiAgCQkvYmluL3NoIC9ob21lL3J1bm5pbmcvbG9nNGMtMS4wLjEwL2Nv bmZpZy9taXNzaW5nIC0tcnVuIGF1dG9tYWtlIC0tZ251ICBNYWtlZmlsZQ0KCQlhY2xvY2FsLm00 OiA0MjE6IGBhdXRvbWFrZSByZXF1aXJlcyBgQU1fQ09ORklHX0hFQURFUicsIG5vdCBgQUNfQ09O RklHX0hFQURFUicNCgkJY29uZmlndXJlLmluOiA0MjE6IHJlcXVpcmVkIGZpbGUgYC4vJEApXS5p bicgbm90IGZvdW5kDQoJCWNkIC4gJiYgL2Jpbi9zaCAvaG9tZS9ydW5uaW5nL2xvZzRjLTEuMC4x MC9jb25maWcvbWlzc2luZyAtLXJ1biBhdXRvY29uZg0KCQljb25maWd1cmUuaW46Mzk6IGVycm9y OiBwb3NzaWJseSB1bmRlZmluZWQgbWFjcm86IEFDX1BST0dfTElCVE9PTA0KICAgICAgSWYgdGhp cyB0b2tlbiBhbmQgb3RoZXJzIGFyZSBsZWdpdGltYXRlLCBwbGVhc2UgdXNlIG00X3BhdHRlcm5f YWxsb3cuDQogICAgICBTZWUgdGhlIEF1dG9jb25mIGRvY3VtZW50YXRpb24uDQoJCWNvbmZpZ3Vy ZS5pbjo4OTogZXJyb3I6IHBvc3NpYmx5IHVuZGVmaW5lZCBtYWNybzogQU1fUEFUSF9FWFBBVA0K CVdBUk5JTkc6IGBhdXRvY29uZicgaXMgbWlzc2luZyBvbiB5b3VyIHN5c3RlbS4gIFlvdSBzaG91 bGQgb25seSBuZWVkIGl0IGlmDQogICAgICAgICB5b3UgbW9kaWZpZWQgYGNvbmZpZ3VyZS5pbicu ICBZb3UgbWlnaHQgd2FudCB0byBpbnN0YWxsIHRoZQ0KICAgICAgICAgYEF1dG9jb25mJyBhbmQg YEdOVSBtNCcgcGFja2FnZXMuICBHcmFiIHRoZW0gZnJvbSBhbnkgR05VDQogICAgICAgICBhcmNo aXZlIHNpdGUuIg0KCQ0KCSgyKSB0aGVuIGkgZG93bmxvYWRlZCAgYEF1dG9jb25mJyBhbmQgYEdO VSBtNCcsYnV0IGkgY291bGRuJ3QgdW5kZXJzdGFuZCB3aGF0IEdOVSBtNCBpcy5Xb3VsZCB5b3Ug cGxlYXNlIG1ha2UgYW4gCQlleHBsYWluYXRpb24gPw0KDQqhoVRoYW5rcyBmb3IgYWhlYWQuDQog DQoJCQkJIA0KoaGhoaGhoaGhoaGhoaGhoUR1IENodW55YW4NCqGhoaGhoaGhoaGhoaGhoaEyMTAz MTMwNDFAc3VkYS5lZHUuY24NCqGhoaGhoaGhoaGhoaGhoaGhoaGhMjAwNS0wOS0xMA0KDQo= --===============1130054259== 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 --===============1130054259==-- From ipsec-bounces@ietf.org Sat Sep 10 12:47:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EE8Vm-0000ws-9M; Sat, 10 Sep 2005 12:47:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EE8Vk-0000wk-6S for ipsec@megatron.ietf.org; Sat, 10 Sep 2005 12:47:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09357 for ; Sat, 10 Sep 2005 12:47:17 -0400 (EDT) Received: from iluvatar.zemris.fer.hr ([161.53.65.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EE8ZM-0002Lq-0m for ipsec@ietf.org; Sat, 10 Sep 2005 12:51:18 -0400 Received: from localhost (iluvatar [127.0.0.1]) by iluvatar.zemris.fer.hr (Postfix) with ESMTP id 788BF13C00A; Sat, 10 Sep 2005 18:27:11 +0200 (CEST) Received: from iluvatar.zemris.fer.hr ([127.0.0.1]) by localhost (iluvatar.zemris.fer.hr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05834-07; Sat, 10 Sep 2005 18:27:07 +0200 (CEST) Received: from webmail.zemris.fer.hr (iluvatar [127.0.0.1]) by iluvatar.zemris.fer.hr (Postfix) with ESMTP id F34C513C007; Sat, 10 Sep 2005 18:27:06 +0200 (CEST) Received: from 193.198.136.97 (SquirrelMail authenticated user sgros) by webmail.zemris.fer.hr with HTTP; Sat, 10 Sep 2005 18:27:07 +0200 (CEST) Message-ID: <32823.193.198.136.97.1126369627.squirrel@webmail.zemris.fer.hr> Date: Sat, 10 Sep 2005 18:27:07 +0200 (CEST) From: Stjepan =?utf-8?Q?Gro=B9?= To: 210313041@suda.edu.cn, ikev2-devel@lists.sourceforge.net User-Agent: SquirrelMail/1.4.4-1.FC2 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new at zemris.fer.hr Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.9 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org Subject: [Ipsec] Re: Is there anyone who install IKEv2? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: sgros@zemris.fer.hr 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 one of the developers of IKEv2, and I'll gladly help you to compile IKEv2 daemon. But maybe this issue is not for ipsec mailing list, but rather for ikev2-devel@lists.sourceforge.net, so I'm sending this e-mail directly to You, to that list, but also as a reference to ipsec mailing list (i.e. if you reply to this mail, please remove ipsec@ietf.org address). Whatever linux distribution you have, it's best that you during os installation select development environment because it's easiest way. It might happen that you miss more than just autoconf/m4 on your computer. Anyway, check that you have at least the following libraries/tools/compilers: perl awk m4 autoconf (requires m4, perl, awk) automake (requires perl) libtool-libs libtool cpp gcc (glibc-devel, cpp) If you have those tools installed, then maybe it's best that you list all installed software on you linux (for fedora just execute rpm -qa) and sen= d it to a mailing list (or if you are concerned about privacy issues, send it to my mail). Then I can check your list. Stjepan P.S. m4 is a macro preprocessor (from man m4 :)), it has similar purpose like cpp. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 12 13:50:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEsRN-0006xE-WA; Mon, 12 Sep 2005 13:50:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEsRI-0006wU-6t for ipsec@megatron.ietf.org; Mon, 12 Sep 2005 13:50:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04494 for ; Mon, 12 Sep 2005 13:49:45 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEsVM-0003rR-2w for ipsec@ietf.org; Mon, 12 Sep 2005 13:54:09 -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 j8CHnRDd006575; Mon, 12 Sep 2005 13:49:28 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <200509082324.j88NO6aF008898@givry.rennes.enst-bretagne.fr> References: <200509082324.j88NO6aF008898@givry.rennes.enst-bretagne.fr> Date: Mon, 12 Sep 2005 13:48:15 -0400 To: Francis Dupont From: Stephen Kent Subject: Re: [Ipsec] ICMP and MH TSs for IKEv2 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: e5ba305d0e64821bf3d8bc5d3bb07228 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 At 1:24 AM +0200 9/9/05, Francis Dupont wrote: >I have another related question: is this valid: > > Local's > next layer protocol = ICMP > "port" selector = > > Remote's > next layer protocol = ICMP > "port" selector = > >If yes, is the meaning that systems are willing to send and >receive traffic with type1/code1 for traffic from local to remote >and type2/code2 for traffic from remote to local? > >I expect the answer is yes for both questions because IMHO this >reflects the intention of 4.4.1.3 for ICMP/MH "ports". > >Thanks > >Francis.Dupont@enst-bretagne.fr > >PS: I believe a message in the list is enough, i.e., no clarification >in the 2401-bis document is necessary. > Yes, this would be a valid SPD entry with the intent you noted, i.e., different allowed ICMP message type.code combinations for the SAs in each direction. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 12 15:03:21 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEtaL-0004Rn-Nx; Mon, 12 Sep 2005 15:03:21 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEtaJ-0004RD-ID for ipsec@megatron.ietf.org; Mon, 12 Sep 2005 15:03:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA08042 for ; Mon, 12 Sep 2005 15:03:10 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEteP-0005mC-UV for ipsec@ietf.org; Mon, 12 Sep 2005 15:07:35 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8CJ2ucU016626 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 12 Sep 2005 12:02:58 -0700 (PDT) Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.100]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8CJ2s7T019197 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 12 Sep 2005 12:02:55 -0700 (PDT) Message-Id: <6.2.2.1.2.20050912115245.02fcbb80@qcmail1.qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.2.1 Date: Mon, 12 Sep 2005 12:02:47 -0700 To: ipsec@ietf.org From: Lakshminath Dondeti Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages 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 all, I have a question about rekeying CHILD SAs in IKEv2 and whether Delete messages MUST always be sent. From Page 19 of ikev2-17, a notify payload MUST identify the IPsec SA being rekeyed. So, if both sides know that a given IPsec SA is being rekeyed, does it still need to be explicitly Deleted? My thinking is that if we are going to delete an SA explicitly, then we don't need the notify payload and if we do use the N payload then there is no need to explicitly delete the SAs (of course this only applies to the special case of rekeying). best regards, Lakshminath _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 12 15:49:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEuIx-0004N2-L8; Mon, 12 Sep 2005 15:49:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEuIn-0004Lu-Rq for ipsec@megatron.ietf.org; Mon, 12 Sep 2005 15:49:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11777 for ; Mon, 12 Sep 2005 15:48:57 -0400 (EDT) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEuMj-000769-Bs for ipsec@ietf.org; Mon, 12 Sep 2005 15:53:22 -0400 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.4/8.13.4/Debian-3) with ESMTP id j8CJmatW026490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Sep 2005 22:48:36 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.4/8.13.4/Submit) id j8CJmZLu026487; Mon, 12 Sep 2005 22:48:35 +0300 Date: Mon, 12 Sep 2005 22:48:35 +0300 Message-Id: <200509121948.j8CJmZLu026487@burp.tkv.asdf.org> From: Markku Savela To: kent@bbn.com In-reply-to: (message from Stephen Kent on Mon, 12 Sep 2005 13:48:15 -0400) Subject: Re: [Ipsec] ICMP and MH TSs for IKEv2 References: <200509082324.j88NO6aF008898@givry.rennes.enst-bretagne.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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 > From: Stephen Kent > > Yes, this would be a valid SPD entry with the intent you noted, i.e., > different allowed ICMP message type.code combinations for the SAs in > each direction. I fail to see how this trickery of putting ICMP/MH type/code into remote and/or local port selectors SPD relates to controlling whether such traffic is allowed only in, out or both ways? Doesn't seem to be needed at all (at least I don't). If you want to allow only inbound ICMP of specific type, you just write a selector that specifies this type code and has destination address that matches inbound. Same logic for outbound. Seems to derive from some specific implementation. Specifying asymmetric SPD for specific ICMP type is very simple in my implementation, just writing a selector logically as "outbound proto=ICMP type=X" I don't think 2401bis needs to tell how to impelemnt this internally. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 12 16:30:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEuwS-00074B-Fu; Mon, 12 Sep 2005 16:30:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEuwQ-00073R-7M for ipsec@megatron.ietf.org; Mon, 12 Sep 2005 16:30:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19011 for ; Mon, 12 Sep 2005 16:30:02 -0400 (EDT) Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEv0V-0001mZ-Fn for ipsec@ietf.org; Mon, 12 Sep 2005 16:34:28 -0400 Received: from unknown (HELO beta.jnpr.net) (172.24.18.109) by borg.juniper.net with ESMTP; 12 Sep 2005 13:29:52 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,102,1125903600"; d="scan'208"; a="500501329:sNHT21347520" Received: from gluon.jnpr.net ([172.24.15.23]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Sep 2005 13:29:52 -0700 Received: from ghuang-lnx.netscreen.com ([10.150.65.191]) by gluon.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 12 Sep 2005 13:29:51 -0700 Subject: Re: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages From: Geoffrey Huang To: Lakshminath Dondeti In-Reply-To: <6.2.2.1.2.20050912115245.02fcbb80@qcmail1.qualcomm.com> References: <6.2.2.1.2.20050912115245.02fcbb80@qcmail1.qualcomm.com> Content-Type: text/plain Date: Mon, 12 Sep 2005 13:29:51 -0700 Message-Id: <1126556991.10962.5.camel@ghuang-lnx.juniper.net> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Sep 2005 20:29:51.0578 (UTC) FILETIME=[BA443BA0:01C5B7D8] 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 There should be no such assumption based on rekeying. What I mean to say is that any party can request a rekey at any time, and you shouldn't make any assumptions on how the peer treats the old SA. The peer might continue to use the old SA to send traffic for some period of time. If you delete the old SA without explicitly notifying your peer, you can create a black hole. -g On Mon, 2005-09-12 at 12:02 -0700, Lakshminath Dondeti wrote: > Hi all, > > I have a question about rekeying CHILD SAs in IKEv2 and whether Delete > messages MUST always be sent. > > From Page 19 of ikev2-17, a notify payload MUST identify the IPsec SA > being rekeyed. So, if both sides know that a given IPsec SA is being > rekeyed, does it still need to be explicitly Deleted? My thinking is that > if we are going to delete an SA explicitly, then we don't need the notify > payload and if we do use the N payload then there is no need to explicitly > delete the SAs (of course this only applies to the special case of rekeying). > > best regards, > Lakshminath > > > _______________________________________________ > 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 Sep 12 18:57:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EExEt-0007zh-E7; Mon, 12 Sep 2005 18:57:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEw8k-00087P-5t for ipsec@megatron.ietf.org; Mon, 12 Sep 2005 17:47:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03892 for ; Mon, 12 Sep 2005 17:46:51 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEwCs-0007aq-Vm for ipsec@ietf.org; Mon, 12 Sep 2005 17:51:19 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8CLkbIr011653; Mon, 12 Sep 2005 14:46:38 -0700 (PDT) Received: from LDONDETI.qualcomm.com (qconnect-10-50-65-14.qualcomm.com [10.50.65.14]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8CLkZoZ003505 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Sep 2005 14:46:36 -0700 (PDT) Message-Id: <6.2.2.1.2.20050912135542.058d3008@qcmail1.qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.2.1 Date: Mon, 12 Sep 2005 14:46:35 -0700 To: Geoffrey Huang From: Lakshminath Dondeti Subject: Re: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages In-Reply-To: <1126556991.10962.5.camel@ghuang-lnx.juniper.net> References: <6.2.2.1.2.20050912115245.02fcbb80@qcmail1.qualcomm.com> <1126556991.10962.5.camel@ghuang-lnx.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 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, Thanks for your response. I don't see that problem; let me try and run through a scenario (perhaps I am leaving something out that you are considering): Let us assume that Alice sends a rekey CREATE_CHILD_SA message -- specifically, with the N payload from Alice to Bob identifying the SA being rekeyed, and that would be the SA from Alice to Bob, and that Bob sends a positive CREATE_CHILD_SA response with the SPI identifying the SA from Bob to Alice in the N payload, the following happens: 1. After Bob sends the response, he now knows that Alice wants to remove the SA from Alice to Bob and that he wants to remove the SA from Bob to Alice, so he can go ahead and delete both SAs. 2. When Alice receives the response, it can install the new SAs and delete both SAs. If the response message from Bob is lost, Alice would repeat the request as per the IKEv2 spec. If it cannot get a response from Bob, it needs to delete all the SAs with Bob anyway. One might say that Alice may send IPsec traffic to Bob, encapsulated with the old SA between events 1 and 2 above, but I don't think that applies to all cases. (i.e., this is an argument between MUST AND SHOULD). I know of use cases, where parties know that they don't want to use the old IPsec at the time rekeying is initiated (and know of others, e.g., remote access, where seamless rekying is necessary). So, I am not saying that the initiating party makes assumptions about how the peer treats the old SA. In effect, I am saying that inclusion of the N payload in the CREATE_CHILD_SA exchange allows the parties to explicitly "replace" the old SA with the new SA. Finally, what is the purpose of the N payload in the CREATE_CHILD_SA exchange? regards, Lakshminath At 01:29 PM 9/12/2005, Geoffrey Huang wrote: >There should be no such assumption based on rekeying. What I mean to >say is that any party can request a rekey at any time, and you shouldn't >make any assumptions on how the peer treats the old SA. The peer might >continue to use the old SA to send traffic for some period of time. If >you delete the old SA without explicitly notifying your peer, you can >create a black hole. > >-g > >On Mon, 2005-09-12 at 12:02 -0700, Lakshminath Dondeti wrote: > > Hi all, > > > > I have a question about rekeying CHILD SAs in IKEv2 and whether Delete > > messages MUST always be sent. > > > > From Page 19 of ikev2-17, a notify payload MUST identify the IPsec SA > > being rekeyed. So, if both sides know that a given IPsec SA is being > > rekeyed, does it still need to be explicitly Deleted? My thinking is that > > if we are going to delete an SA explicitly, then we don't need the notify > > payload and if we do use the N payload then there is no need to explicitly > > delete the SAs (of course this only applies to the special case of > rekeying). > > > > best regards, > > Lakshminath > > > > > > _______________________________________________ > > 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 Sep 12 19:22:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EExdB-0004mB-OW; Mon, 12 Sep 2005 19:22:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEwXu-0006fJ-Vz for ipsec@megatron.ietf.org; Mon, 12 Sep 2005 18:13:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05303 for ; Mon, 12 Sep 2005 18:12:55 -0400 (EDT) Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEwc7-00086W-0Z for ipsec@ietf.org; Mon, 12 Sep 2005 18:17:23 -0400 Received: from unknown (HELO beta.jnpr.net) (172.24.18.109) by kremlin.juniper.net with ESMTP; 12 Sep 2005 15:12:48 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,103,1125903600"; d="scan'208"; a="482126210:sNHT25232788" Received: from gluon.jnpr.net ([172.24.15.23]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Mon, 12 Sep 2005 15:12:48 -0700 Received: from ghuang-lnx.netscreen.com ([10.150.65.191]) by gluon.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Mon, 12 Sep 2005 15:12:47 -0700 Subject: Re: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages From: Geoffrey Huang To: Lakshminath Dondeti In-Reply-To: <6.2.2.1.2.20050912135542.058d3008@qcmail1.qualcomm.com> References: <6.2.2.1.2.20050912115245.02fcbb80@qcmail1.qualcomm.com> <1126556991.10962.5.camel@ghuang-lnx.juniper.net> <6.2.2.1.2.20050912135542.058d3008@qcmail1.qualcomm.com> Content-Type: text/plain Date: Mon, 12 Sep 2005 15:12:47 -0700 Message-Id: <1126563167.10962.10.camel@ghuang-lnx.juniper.net> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 12 Sep 2005 22:12:47.0704 (UTC) FILETIME=[1B864580:01C5B7E7] X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 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 Mon, 2005-09-12 at 14:46 -0700, Lakshminath Dondeti wrote: > Hi, > > Thanks for your response. I don't see that problem; let me try and run > through a scenario (perhaps I am leaving something out that you are > considering): > > Let us assume that Alice sends a rekey CREATE_CHILD_SA message -- > specifically, with the N payload from Alice to Bob identifying the SA being > rekeyed, and that would be the SA from Alice to Bob, and that Bob sends a > positive CREATE_CHILD_SA response with the SPI identifying the SA from Bob > to Alice in the N payload, the following happens: > > 1. After Bob sends the response, he now knows that Alice wants to remove > the SA from Alice to Bob and that he wants to remove the SA from Bob to > Alice, so he can go ahead and delete both SAs. I disagree. Bob only knows that Alice wants to rekey the SA with the given SPI. He doesn't know that Alice wants to delete the old SA. > 2. When Alice receives the response, it can install the new SAs and delete > both SAs. > > If the response message from Bob is lost, Alice would repeat the request as > per the IKEv2 spec. If it cannot get a response from Bob, it needs to > delete all the SAs with Bob anyway. > > One might say that Alice may send IPsec traffic to Bob, encapsulated with > the old SA between events 1 and 2 above, but I don't think that applies to > all cases. (i.e., this is an argument between MUST AND SHOULD). I know of > use cases, where parties know that they don't want to use the old IPsec at > the time rekeying is initiated (and know of others, e.g., remote access, > where seamless rekying is necessary). > > So, I am not saying that the initiating party makes assumptions about how > the peer treats the old SA. In effect, I am saying that inclusion of the N > payload in the CREATE_CHILD_SA exchange allows the parties to explicitly > "replace" the old SA with the new SA. > I think the inclusion of the Notify merely says, "I'm rekeying SA with SPI X in this CHILD exchange." This is different than "I'm replacing SA with SPI X with the new SA we're about to create." > Finally, what is the purpose of the N payload in the CREATE_CHILD_SA exchange? > To indicate that the SA you're negotiating is a rekey, and not a deliberate parallel SA. See section 2.8: Note that IKEv2 deliberately allows parallel SAs with the same traffic selectors between common endpoints. One of the purposes of this is to support traffic QoS differences among the SAs (see section 4.1 of [RFC2983]). Hence unlike IKEv1, the combination of the endpoints and the traffic selectors may not uniquely identify an SA between those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on the basis of duplicate traffic selectors SHOULD NOT be used. -g > regards, > Lakshminath > > > At 01:29 PM 9/12/2005, Geoffrey Huang wrote: > >There should be no such assumption based on rekeying. What I mean to > >say is that any party can request a rekey at any time, and you shouldn't > >make any assumptions on how the peer treats the old SA. The peer might > >continue to use the old SA to send traffic for some period of time. If > >you delete the old SA without explicitly notifying your peer, you can > >create a black hole. > > > >-g > > > >On Mon, 2005-09-12 at 12:02 -0700, Lakshminath Dondeti wrote: > > > Hi all, > > > > > > I have a question about rekeying CHILD SAs in IKEv2 and whether Delete > > > messages MUST always be sent. > > > > > > From Page 19 of ikev2-17, a notify payload MUST identify the IPsec SA > > > being rekeyed. So, if both sides know that a given IPsec SA is being > > > rekeyed, does it still need to be explicitly Deleted? My thinking is that > > > if we are going to delete an SA explicitly, then we don't need the notify > > > payload and if we do use the N payload then there is no need to explicitly > > > delete the SAs (of course this only applies to the special case of > > rekeying). > > > > > > best regards, > > > Lakshminath > > > > > > > > > _______________________________________________ > > > 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 Sep 12 23:05:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF17D-0005pn-Kc; Mon, 12 Sep 2005 23:05:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEwyQ-0004TF-Kk for ipsec@megatron.ietf.org; Mon, 12 Sep 2005 18:40:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06849 for ; Mon, 12 Sep 2005 18:40:15 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EEx2Z-0000CJ-Gz for ipsec@ietf.org; Mon, 12 Sep 2005 18:44:44 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8CMdwIr019746; Mon, 12 Sep 2005 15:39:58 -0700 (PDT) Received: from LDONDETI.qualcomm.com (qconnect-10-50-65-14.qualcomm.com [10.50.65.14]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8CMduoZ014614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 12 Sep 2005 15:39:56 -0700 (PDT) Message-Id: <6.2.2.1.2.20050912153002.059b6ed8@qcmail1.qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.2.1 Date: Mon, 12 Sep 2005 15:39:55 -0700 To: Geoffrey Huang From: Lakshminath Dondeti Subject: Re: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages In-Reply-To: <1126563167.10962.10.camel@ghuang-lnx.juniper.net> References: <6.2.2.1.2.20050912115245.02fcbb80@qcmail1.qualcomm.com> <1126556991.10962.5.camel@ghuang-lnx.juniper.net> <6.2.2.1.2.20050912135542.058d3008@qcmail1.qualcomm.com> <1126563167.10962.10.camel@ghuang-lnx.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: b2809b6f39decc6de467dcf252f42af1 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, Please see inline: At 03:12 PM 9/12/2005, Geoffrey Huang wrote: >On Mon, 2005-09-12 at 14:46 -0700, Lakshminath Dondeti wrote: > > Hi, > > > > Thanks for your response. I don't see that problem; let me try and run > > through a scenario (perhaps I am leaving something out that you are > > considering): > > > > Let us assume that Alice sends a rekey CREATE_CHILD_SA message -- > > specifically, with the N payload from Alice to Bob identifying the SA > being > > rekeyed, and that would be the SA from Alice to Bob, and that Bob sends a > > positive CREATE_CHILD_SA response with the SPI identifying the SA from Bob > > to Alice in the N payload, the following happens: > > > > 1. After Bob sends the response, he now knows that Alice wants to remove > > the SA from Alice to Bob and that he wants to remove the SA from Bob to > > Alice, so he can go ahead and delete both SAs. > >I disagree. Bob only knows that Alice wants to rekey the SA with the >given SPI. He doesn't know that Alice wants to delete the old SA. Sure it is saying rekey, but given the parallel SAs vs. rekey SAs differentiation, I am not sure what purpose the N payload serves. Hence, I think that "indication of rekeying via N payload" is an explicit declaration of intent to replace. > > 2. When Alice receives the response, it can install the new SAs and delete > > both SAs. > > > > If the response message from Bob is lost, Alice would repeat the > request as > > per the IKEv2 spec. If it cannot get a response from Bob, it needs to > > delete all the SAs with Bob anyway. > > > > One might say that Alice may send IPsec traffic to Bob, encapsulated with > > the old SA between events 1 and 2 above, but I don't think > that applies to > > all cases. (i.e., this is an argument between MUST AND SHOULD). I know of > > use cases, where parties know that they don't want to use the old IPsec at > > the time rekeying is initiated (and know of others, e.g., remote access, > > where seamless rekying is necessary). > > > > So, I am not saying that the initiating party makes assumptions about how > > the peer treats the old SA. In effect, I am saying that inclusion of > the N > > payload in the CREATE_CHILD_SA exchange allows the parties to explicitly > > "replace" the old SA with the new SA. > > > >I think the inclusion of the Notify merely says, "I'm rekeying SA with >SPI X in this CHILD exchange." This is different than "I'm replacing SA >with SPI X with the new SA we're about to create." I understand that. However, I am not sure what actions might be taken based on that information. > > Finally, what is the purpose of the N payload in the CREATE_CHILD_SA > exchange? > > > >To indicate that the SA you're negotiating is a rekey, and not a >deliberate parallel SA. See section 2.8: Not sure why the peer needs to indicate that an SA as being rekeyed, if it is going to send an explicit "delete" anyway. Other than an early warning :-), I cannot think of other reasons. regards, Lakshminath > Note that IKEv2 deliberately allows parallel SAs with the same > traffic selectors between common endpoints. One of the purposes of > this is to support traffic QoS differences among the SAs (see section > 4.1 of [RFC2983]). Hence unlike IKEv1, the combination of the > endpoints and the traffic selectors may not uniquely identify an SA > between those endpoints, so the IKEv1 rekeying heuristic of deleting > SAs on the basis of duplicate traffic selectors SHOULD NOT be used. > >-g > > > regards, > > Lakshminath > > > > > > At 01:29 PM 9/12/2005, Geoffrey Huang wrote: > > >There should be no such assumption based on rekeying. What I mean to > > >say is that any party can request a rekey at any time, and you shouldn't > > >make any assumptions on how the peer treats the old SA. The peer might > > >continue to use the old SA to send traffic for some period of time. If > > >you delete the old SA without explicitly notifying your peer, you can > > >create a black hole. > > > > > >-g > > > > > >On Mon, 2005-09-12 at 12:02 -0700, Lakshminath Dondeti wrote: > > > > Hi all, > > > > > > > > I have a question about rekeying CHILD SAs in IKEv2 and whether Delete > > > > messages MUST always be sent. > > > > > > > > From Page 19 of ikev2-17, a notify payload MUST identify the IPsec SA > > > > being rekeyed. So, if both sides know that a given IPsec SA is being > > > > rekeyed, does it still need to be explicitly Deleted? My thinking > is that > > > > if we are going to delete an SA explicitly, then we don't need the > notify > > > > payload and if we do use the N payload then there is no need to > explicitly > > > > delete the SAs (of course this only applies to the special case of > > > rekeying). > > > > > > > > best regards, > > > > Lakshminath > > > > > > > > > > > > _______________________________________________ > > > > 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 Sep 12 23:35:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF1aI-0002ld-29; Mon, 12 Sep 2005 23:35:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EEwz7-0004gV-MX for ipsec@megatron.ietf.org; Mon, 12 Sep 2005 18:41:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06863 for ; Mon, 12 Sep 2005 18:40:45 -0400 (EDT) Received: from smtp107.sbc.mail.mud.yahoo.com ([68.142.198.206]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EEx2y-0000Cj-LA for ipsec@ietf.org; Mon, 12 Sep 2005 18:45:13 -0400 Received: (qmail 9020 invoked from network); 12 Sep 2005 22:40:33 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.57.113 with login) by smtp107.sbc.mail.mud.yahoo.com with SMTP; 12 Sep 2005 22:40:33 -0000 Message-ID: <00b401c5b7ea$f68d1ac0$6701a8c0@adithya> From: "Mohan Parthasarathy" To: "Geoffrey Huang" , "Lakshminath Dondeti" References: <6.2.2.1.2.20050912115245.02fcbb80@qcmail1.qualcomm.com> <1126556991.10962.5.camel@ghuang-lnx.juniper.net> Subject: Re: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages Date: Mon, 12 Sep 2005 15:40:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 > There should be no such assumption based on rekeying. What I mean to Yes, this is what is specified in section 2.8: Hence unlike IKEv1, the combination of the endpoints and the traffic selectors may not uniquely identify an SA between those endpoints, so the IKEv1 rekeying heuristic of deleting SAs on the basis of duplicate traffic selectors SHOULD NOT be used. The node that initiated the surviving rekeyed SA SHOULD delete the replaced SA after the new one is established. But i wonder what the purpose of N(REKEY_SA) is ? What is the responder supposed to do with REKEY_SA notification ? If it just ignores it, then it is the same as the CREATE_CHILD_SA ? One can potentially use it to insert the new SA in front of the old SA so that outbound traffic can use the new SA. But you can't do so for the reasons given in the last paragraph of section 2.8. -mohan > say is that any party can request a rekey at any time, and you shouldn't > make any assumptions on how the peer treats the old SA. The peer might > continue to use the old SA to send traffic for some period of time. If > you delete the old SA without explicitly notifying your peer, you can > create a black hole. > > -g > > On Mon, 2005-09-12 at 12:02 -0700, Lakshminath Dondeti wrote: > > Hi all, > > > > I have a question about rekeying CHILD SAs in IKEv2 and whether Delete > > messages MUST always be sent. > > > > From Page 19 of ikev2-17, a notify payload MUST identify the IPsec SA > > being rekeyed. So, if both sides know that a given IPsec SA is being > > rekeyed, does it still need to be explicitly Deleted? My thinking is that > > if we are going to delete an SA explicitly, then we don't need the notify > > payload and if we do use the N payload then there is no need to explicitly > > delete the SAs (of course this only applies to the special case of rekeying). > > > > best regards, > > Lakshminath > > > > > > _______________________________________________ > > 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 Tue Sep 13 14:00:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFF5M-0006f1-7Y; Tue, 13 Sep 2005 14:00:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF2AM-0002OI-Jr for ipsec@megatron.ietf.org; Tue, 13 Sep 2005 00:13:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18486 for ; Tue, 13 Sep 2005 00:12:52 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EF2EU-0007BM-UI for ipsec@ietf.org; Tue, 13 Sep 2005 00:17:23 -0400 Received: from [10.150.152.56] (dommiel.bbn.com [192.1.122.15]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j8D4CNDj001066; Tue, 13 Sep 2005 00:12:30 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <200509121948.j8CJmZLu026487@burp.tkv.asdf.org> References: <200509082324.j88NO6aF008898@givry.rennes.enst-bretagne.fr> <200509121948.j8CJmZLu026487@burp.tkv.asdf.org> Date: Tue, 13 Sep 2005 00:12:03 -0400 To: Markku Savela From: Stephen Kent Subject: Re: [Ipsec] ICMP and MH TSs for IKEv2 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: 9ed51c9d1356100bce94f1ae4ec616a9 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 10:48 PM +0300 9/12/05, Markku Savela wrote: > > From: Stephen Kent > >> >> Yes, this would be a valid SPD entry with the intent you noted, i.e., >> different allowed ICMP message type.code combinations for the SAs in >> each direction. > >I fail to see how this trickery of putting ICMP/MH type/code into >remote and/or local port selectors SPD relates to controlling >whether such traffic is allowed only in, out or both ways? > >Doesn't seem to be needed at all (at least I don't). If you want to >allow only inbound ICMP of specific type, you just write a selector >that specifies this type code and has destination address that matches >inbound. Same logic for outbound. > >Seems to derive from some specific implementation. Specifying >asymmetric SPD for specific ICMP type is very simple in my >implementation, just writing a selector logically as > > "outbound proto=ICMP type=X" > >I don't think 2401bis needs to tell how to impelemnt this internally. 2401bis defines the SPD and the format for SPD entries in support of translating them into IKE payloads in a consistent, well-understood fashion. it also explains the associated semantics, so that each peer has a reference as to what is meant by the data transferred by the IKE payloads. finally, the SPD spec is an externally visible, minimum management capability mandated by 2401(bis) to ensure that users/admins have a basic set of knobs for access control. if your implementation provides external management controls equivalent to (or more capable than) what is specified in 2401bis, and if you explain how to map these visible controls to IKE payloads, then it is compliant. we have examples of non-complaint implementations that, for example, do not allow the user/admin to order the SPD entries, a serious deficiency. none of this is new, and it's way too late to comment on it. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 13 15:30:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGUZ-0003Yz-BP; Tue, 13 Sep 2005 15:30:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF41d-0003xw-8u for ipsec@megatron.ietf.org; Tue, 13 Sep 2005 02:12:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA03437 for ; Tue, 13 Sep 2005 02:12:00 -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.43) id 1EF45i-00012g-Jg for ipsec@ietf.org; Tue, 13 Sep 2005 02:16:29 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8D6Bo4K008459; Tue, 13 Sep 2005 09:11:54 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Sep 2005 09:11:53 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Sep 2005 09:11:53 +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] ICMP and MH TSs for IKEv2 Date: Tue, 13 Sep 2005 09:11:51 +0300 Message-ID: Thread-Topic: [Ipsec] ICMP and MH TSs for IKEv2 Thread-Index: AcW31Kh8srp6FiGPSraERCh1iNXwKQAVDfNw To: X-OriginalArrivalTime: 13 Sep 2005 06:11:53.0479 (UTC) FILETIME=[09577170:01C5B82A] X-Spam-Score: 0.3 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 Markku Savela wrote: > I fail to see how this trickery of putting ICMP/MH type/code > into remote and/or local port selectors SPD relates to > controlling whether such traffic is allowed only in, out or > both ways? >=20 > Doesn't seem to be needed at all (at least I don't). If you > want to allow only inbound ICMP of specific type, you just > write a selector that specifies this type code and has > destination address that matches inbound. Same logic for > outbound. Yes, you don't need this if you have a 2401-style SPD with separate entries for inbound and outbound traffic (or separate SPDs for inbound and outbound). But in 2401bis a single SPD entry covers both inbound and outbound (that's why it has "local/remote address/port" instead of "source/destination address/port"). > Seems to derive from some specific implementation. Specifying > asymmetric SPD for specific ICMP type is very simple in my > implementation, just writing a selector logically as > > "outbound proto=3DICMP type=3DX" > > I don't think 2401bis needs to tell how to impelemnt this > internally. Well, both 2401 and 2401bis stress the SAD/SPD/PAD model is only conceptual; the data structures in an actual implementation don't have to resemble it if you don't want to... Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 13 15:30:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGUb-0003aN-Od; Tue, 13 Sep 2005 15:30:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF4Ei-0005qw-Iy for ipsec@megatron.ietf.org; Tue, 13 Sep 2005 02:25:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05455 for ; Tue, 13 Sep 2005 02:25:32 -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.43) id 1EF4It-0001JF-LG for ipsec@ietf.org; Tue, 13 Sep 2005 02:30:04 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8D6PT1G009293; Tue, 13 Sep 2005 09:25:32 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Sep 2005 09:25:31 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Sep 2005 09:25:31 +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] Rekeying CHILD SAs in IKEv2 and Delete messages Date: Tue, 13 Sep 2005 09:25:29 +0300 Message-ID: Thread-Topic: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages Thread-Index: AcW4FTQYtkD0LNfvT3eiqwqBHLTCrwAFReDQ To: X-OriginalArrivalTime: 13 Sep 2005 06:25:31.0458 (UTC) FILETIME=[F0E52220:01C5B82B] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8fbbaa16f9fd29df280814cb95ae2290 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 Mohan Parthasarathy wrote: > But i wonder what the purpose of N(REKEY_SA) is ? What is the > responder supposed to do with REKEY_SA notification ? If it just > ignores it, then it is the same as the CREATE_CHILD_SA ? One can > potentially use it to insert the new SA in front of the old SA so > that outbound traffic can use the new SA. But you can't do so for > the reasons given in the last paragraph of section 2.8. An earlier version of the IKEv2 clarifications draft (-01) had=20 some text wondering the same thing: 2.10 Rekeying CHILD_SAs (Preliminary text, still open.) Section 2.8 describes that rekeying a CHILD_SA within an existing IKE_SA is done by first creating a new equivalent SA, and then deleting the old one. However, this section does not describe exactly what payloads are involved, and does not even mention the REKEY_SA notify payload. Another description about rekeying can be found in Section 1.3, but this section also omits some of the details that are in Section 2.8. A typical conversation that rekeys an existing CHILD_SA pair and then deletes the old SAs would look like this: Initiator Responder ----------- ----------- [traffic flowing via CHILD_SA pair with SPIi1/SPIr1] HDR, SK {N(REKEY_SA, SPIi1), SA(..., SPIi2, ...), Ni, [KEi], TSi, TSr} --> <-- HDR, SK {SA(..., SPIr2, ...), Nr, [KEr], TSi, TSr} HDR, SK {D(SPIi1)} --> <-- HDR, SK {D(SPIr1)} [traffic flowing via new CHILD_SA pair with SPIi2/SPIr2] However, it seems that exactly the same (or almost the same) end result would have been achieved if the REKEY_SA notify payload was not included. Not including REKEY_SA here is allowed in IKEv2; in that case, it is not called rekeying, but creating a parallel SA with identical traffic selectors, and coincidentally, deleting one of them very soon after that. Why, then, was the REKEY_SA notify payload included in the spec? This document's interpretation is that by including REKEY_SA, the initiator promises that (1) it will move its outbound traffic to the new SA as soon as it receives the CREATE_CHILD_SA response, (2) it will not use the old outbound SA after that, and (3) it will delete the old SA pair soon afterwards. If this interpretation is correct (which is not clear yet), there seems to be three main differences between the cases with and without REKEY_SA. First, if REKEY_SA is included, the responder can do certain optimizations that would not be possible without it. Second, the exact point when the responder moves the outbound traffic to the new SA may be different. Third, there may be some differences if rekeying is started simultaneously by both parties. Let's consider the optimization case first. It seems that when doing rekeying, a simple responder implementation could, in fact, replace the old SAs "in place". This can result in some packets being lost, so Section 2.8 recommends against this. Initiator Responder ----------- ----------- HDR, SK {N(REKEY_SA, SPIi1), SA(..., SPIi2, ...), Ni, [KEi], TSi, TSr} --> [responder replaces the old SAs with new ones, but remembers the values SPIi1/SPIr1] <-- HDR, SK {SA(..., SPIr2, ...), Nr, [KEr], TSi, TSr} HDR, SK {D(SPIi1)} --> [the old SA is already gone, but the responder still remembers SPIi1/SPIr1] <-- HDR, SK {D(SPIr1)} [now responder can forget SPIi1 and SPIr1] The second difference seems to be when exactly the responder should move the traffic to the new SA. When REKEY_SA is used, Section 2.8 says that the responder should continue using the old SA until it either receives a packet on the new inbound SA, or receives a Delete request for the old SA pair. When REKEY_SA is not used, the traffic is obviously moved when the old SA is deleted, but not necessarily earlier. The third difference may be what exactly happens when both parties start rekeying at the same time, and the requests cross in the network. Here REKEY_SA indicates that neither party wants to keep parallel CHILD_SAs around. (TO BE WRITTEN: details of exactly what happens in this case.) Yet another interpretation is that an IPsec implementation that does not work strictly on per-packet basis, but instead associates SAs with transport layer sockets, could use this information to update the socket instead of searching the SADB/SPD for a suitable SA. (TO BE WRITTEN: details, and whether this makes sense.) (References: Yoav Nir's mail "Re: New I-D: IKEv2 Clarifications and Implementation Guidelines", 2005-02-07.) This text got removed when some of the rekeying text was rewritten, and might be partly wrong... but some off-line conversations around that time were quite clear that even if you do rekeying, you still have to delete the old SAs explicitly, in a separate INFORMATIONAL exchange containing Delete payloads as usual. (But yes, it looks like IKEv2 could have been designed so that a separate Delete payloads would not be needed; but that's too late to change now.) Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 13 15:30:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGUd-0003bR-HF; Tue, 13 Sep 2005 15:30:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF4OM-0007ZO-4O for ipsec@megatron.ietf.org; Tue, 13 Sep 2005 02:35:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06068 for ; Tue, 13 Sep 2005 02:35:32 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EF4SY-0001XW-HW for ipsec@ietf.org; Tue, 13 Sep 2005 02:40:04 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8D6Xq8f012467 for ; Tue, 13 Sep 2005 09:33:52 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Sep 2005 09:35:29 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Sep 2005 09:35:30 +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 Date: Tue, 13 Sep 2005 09:35:28 +0300 Message-ID: Thread-Topic: IKEv2 clarifications -05 Thread-Index: AcW4LVV9qVqsRTBzS2qsC/ox78/+vQ== To: X-OriginalArrivalTime: 13 Sep 2005 06:35:30.0639 (UTC) FILETIME=[5608E5F0:01C5B82D] X-Spam-Score: 0.3 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] IKEv2 clarifications -05 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 version of the IKEv2 clarifications draft is now available: http://www.ietf.org/internet-drafts/draft-eronen-ipsec-ikev2-clarificatio= ns-05.txt Changes in this version include: - Fixed incorrect text about ICMP/MH port selectors and their direction semantics (Sections 4.8 and 4.9) - New text about simultaneous rekeying (Sections 5.11 and 5.12) - New text about address assignment failures, especially when requesting multiple addresses using configuration payloads =20 (Section 6.10) - Fixed text about N(INITIAL_CONTACT) to match discussions on the mailing list (Section 7.8) - Updated text about PRFs with fixed key size since 3664bis=20 has now been approved (Section 3.8) As usual, comments and corrections are most welcome. Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 13 15:31:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGUn-0003ig-2O; Tue, 13 Sep 2005 15:31:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF4xG-0005CX-HH for ipsec@megatron.ietf.org; Tue, 13 Sep 2005 03:11:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07351 for ; Tue, 13 Sep 2005 03:11:38 -0400 (EDT) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EF51T-0002Ni-M7 for ipsec@ietf.org; Tue, 13 Sep 2005 03:16:10 -0400 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.4/8.13.4/Debian-3) with ESMTP id j8D7BZfw020934 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Sep 2005 10:11:35 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.4/8.13.4/Submit) id j8D7BZvh020931; Tue, 13 Sep 2005 10:11:35 +0300 Date: Tue, 13 Sep 2005 10:11:35 +0300 Message-Id: <200509130711.j8D7BZvh020931@burp.tkv.asdf.org> From: Markku Savela To: Pasi.Eronen@nokia.com In-reply-to: (Pasi.Eronen@nokia.com) Subject: Re: [Ipsec] ICMP and MH TSs for IKEv2 References: X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 > From: > Markku Savela wrote: > > I fail to see how this trickery of putting ICMP/MH type/code > > into remote and/or local port selectors SPD relates to > > controlling whether such traffic is allowed only in, out or > > both ways? > > > > Doesn't seem to be needed at all (at least I don't). If you > > want to allow only inbound ICMP of specific type, you just > > write a selector that specifies this type code and has > > destination address that matches inbound. Same logic for > > outbound. > > Yes, you don't need this if you have a 2401-style SPD with > separate entries for inbound and outbound traffic (or separate > SPDs for inbound and outbound). But in 2401bis a single SPD entry > covers both inbound and outbound (that's why it has "local/remote > address/port" instead of "source/destination address/port"). I have always had the local/remote notation in SPD even with 2401. I definitely don't need separate SPD's for inbound and outbound, unless you explicitly want to have asymmetric policy. The inbound/outbound status is a property of a packet. You need to know this to choose how to map packets src/dst into local/remote. One can see that the suggested trickery with type/code is bogus, or at least illogical, by just condidering the protocol selector. Surely, you should be able to specify a policy selector for a specific protocol, that applies only to outbound or inbound? But, I don't see the equivalent hack for the protocol field in the specification. Note, I fully agree with the idea of packing the type/code into port selector. I have no problem with that. I just think, as I suggested, that the value should always be in both remote and local selector (just like the protocol value is). This is totally unrelated with the asymmetric policy issue, with which I have never had any problems. Finally, I think 2401 was (and is) great work. It only needed little clarifications. The new draft goes way too far into implementation details, IMHO. However, I do like - PFP flags - TS in SA _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 13 15:31:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGUp-0003kQ-MU; Tue, 13 Sep 2005 15:31:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EF5J7-00004z-MN for ipsec@megatron.ietf.org; Tue, 13 Sep 2005 03:34:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08044 for ; Tue, 13 Sep 2005 03:34:17 -0400 (EDT) Received: from mailalarm.checkpoint.com ([194.29.32.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EF5NO-0002tN-9s for ipsec@ietf.org; Tue, 13 Sep 2005 03:38:49 -0400 Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by mailalarm.checkpoint.com (8.12.11/8.12.11) with ESMTP id j8D7uF3a029226; Tue, 13 Sep 2005 10:56:20 +0300 Received: from YnirNew (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id j8D7XlnP018402; Tue, 13 Sep 2005 10:33:47 +0300 (IDT) Message-Id: <200509130733.j8D7XlnP018402@michael.checkpoint.com> From: "Yoav Nir" To: "'Lakshminath Dondeti'" , "'Geoffrey Huang'" Subject: RE: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages Date: Tue, 13 Sep 2005 10:34:07 +0300 Organization: Check Point MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Thread-Index: AcW4EPbTorGou150SRahCL1b3sK2VAAI1uyQ In-Reply-To: <6.2.2.1.2.20050912153002.059b6ed8@qcmail1.qualcomm.com> 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 This issue has come up before. The only reasonable interpretation we came up with is that IPSec is usually done by a machine that is also a firewall. Firewalls tend to be "stateful" in the sense that they follow connections. A firewall-vpn device may expect a single connection to use the same IPSec SA all the time, so the rekey notification serves as an early warning that future packets using the rekeyed SA may come from the new SA. I know this is a dagerous assumption to make, because there is no reason to think that the packets from a single connection shouldn't use different parallel SAs, but that's the only justification I can come up with for explicitly saying that this SA replaces that SA. -----Original Message----- >I think the inclusion of the Notify merely says, "I'm rekeying SA with >SPI X in this CHILD exchange." This is different than "I'm replacing SA >with SPI X with the new SA we're about to create." I understand that. However, I am not sure what actions might be taken based on that information. > > Finally, what is the purpose of the N payload in the CREATE_CHILD_SA > exchange? > > > >To indicate that the SA you're negotiating is a rekey, and not a >deliberate parallel SA. See section 2.8: Not sure why the peer needs to indicate that an SA as being rekeyed, if it is going to send an explicit "delete" anyway. Other than an early warning :-), I cannot think of other reasons. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 13 15:34:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGXY-0005HK-Hp; Tue, 13 Sep 2005 15:34:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFDe3-0001g4-7U for ipsec@megatron.ietf.org; Tue, 13 Sep 2005 12:28:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00421 for ; Tue, 13 Sep 2005 12:28:17 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFDiI-0006fb-GP for ipsec@ietf.org; Tue, 13 Sep 2005 12:32:56 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8DGRvcU021000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 13 Sep 2005 09:27:57 -0700 (PDT) Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.100]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8DGRtkN013597 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Sep 2005 09:27:55 -0700 (PDT) Message-Id: <6.2.2.1.2.20050913091925.05d527d0@qcmail1.qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.2.1 Date: Tue, 13 Sep 2005 09:27:55 -0700 To: "Yoav Nir" , "'Geoffrey Huang'" From: Lakshminath Dondeti Subject: RE: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages In-Reply-To: <200509130733.j8D7XlnP018402@michael.checkpoint.com> References: <6.2.2.1.2.20050912153002.059b6ed8@qcmail1.qualcomm.com> <200509130733.j8D7XlnP018402@michael.checkpoint.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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 Yoav, Thanks. I did some searching (a quick search) before I posted to the list, and did find detailed notes in ikev2-clarifications-00. Pasi and Paul seem to have wondered about this too, but the text in the current version (05 was posted yesterday) is the same as in ikev2-17 with some minor clarifications on which SPI to use in the N payload. There was nothing on what purpose the N payload serves. The notes you provide below are informative. Based on your message and other responses so far, I'd conclude that there is currently no reasonable case for why N payloads MUST be sent. thanks and regards, Lakshminath At 12:34 AM 9/13/2005, Yoav Nir wrote: >This issue has come up before. The only reasonable interpretation we came up >with is that IPSec is usually done by a machine that is also a firewall. >Firewalls tend to be "stateful" in the sense that they follow connections. >A firewall-vpn device may expect a single connection to use the same IPSec >SA all the time, so the rekey notification serves as an early warning that >future packets using the rekeyed SA may come from the new SA. > >I know this is a dagerous assumption to make, because there is no reason to >think that the packets from a single connection shouldn't use different >parallel SAs, but that's the only justification I can come up with for >explicitly saying that this SA replaces that SA. > >-----Original Message----- > > > > >I think the inclusion of the Notify merely says, "I'm rekeying SA with > >SPI X in this CHILD exchange." This is different than "I'm replacing SA > >with SPI X with the new SA we're about to create." > >I understand that. However, I am not sure what actions might be taken >based on that information. > > > > > Finally, what is the purpose of the N payload in the CREATE_CHILD_SA > > exchange? > > > > > > >To indicate that the SA you're negotiating is a rekey, and not a > >deliberate parallel SA. See section 2.8: > >Not sure why the peer needs to indicate that an SA as being rekeyed, if it >is going to send an explicit "delete" anyway. Other than an early warning >:-), I cannot think of other reasons. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 13 15:34:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGXd-0005KT-MW; Tue, 13 Sep 2005 15:34:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFDla-0002qE-Mp for ipsec@megatron.ietf.org; Tue, 13 Sep 2005 12:36:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA00868 for ; Tue, 13 Sep 2005 12:36:07 -0400 (EDT) Received: from kremlin.juniper.net ([207.17.137.120]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFDps-0006tC-Fw for ipsec@ietf.org; Tue, 13 Sep 2005 12:40:45 -0400 Received: from unknown (HELO alpha.jnpr.net) (172.24.18.126) by kremlin.juniper.net with ESMTP; 13 Sep 2005 09:35:55 -0700 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.97,106,1125903600"; d="scan'208"; a="482216185:sNHT21576704" Received: from gluon.jnpr.net ([172.24.15.23]) by alpha.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 13 Sep 2005 09:35:55 -0700 Received: from ghuang-lnx.netscreen.com ([10.150.65.191]) by gluon.jnpr.net with Microsoft SMTPSVC(5.0.2195.6713); Tue, 13 Sep 2005 09:35:54 -0700 Subject: RE: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages From: Geoffrey Huang To: Yoav Nir In-Reply-To: <200509130733.j8D7XlnP018402@michael.checkpoint.com> References: <200509130733.j8D7XlnP018402@michael.checkpoint.com> Content-Type: text/plain Date: Tue, 13 Sep 2005 09:35:54 -0700 Message-Id: <1126629354.25106.0.camel@ghuang-lnx.juniper.net> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Sep 2005 16:35:54.0765 (UTC) FILETIME=[36164BD0:01C5B881] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 Wouldn't the rekey notify payload also be useful for indicating that a rekey timer should stop? -g On Tue, 2005-09-13 at 10:34 +0300, Yoav Nir wrote: > This issue has come up before. The only reasonable interpretation we came up > with is that IPSec is usually done by a machine that is also a firewall. > Firewalls tend to be "stateful" in the sense that they follow connections. > A firewall-vpn device may expect a single connection to use the same IPSec > SA all the time, so the rekey notification serves as an early warning that > future packets using the rekeyed SA may come from the new SA. > > I know this is a dagerous assumption to make, because there is no reason to > think that the packets from a single connection shouldn't use different > parallel SAs, but that's the only justification I can come up with for > explicitly saying that this SA replaces that SA. > > -----Original Message----- > > > > >I think the inclusion of the Notify merely says, "I'm rekeying SA with > >SPI X in this CHILD exchange." This is different than "I'm replacing SA > >with SPI X with the new SA we're about to create." > > I understand that. However, I am not sure what actions might be taken > based on that information. > > > > > Finally, what is the purpose of the N payload in the CREATE_CHILD_SA > > exchange? > > > > > > >To indicate that the SA you're negotiating is a rekey, and not a > >deliberate parallel SA. See section 2.8: > > Not sure why the peer needs to indicate that an SA as being rekeyed, if it > is going to send an explicit "delete" anyway. Other than an early warning > :-), I cannot think of other reasons. > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 13 15:34:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFGXf-0005LL-P7; Tue, 13 Sep 2005 15:34:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFDnd-00033Z-GK for ipsec@megatron.ietf.org; Tue, 13 Sep 2005 12:38:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01014 for ; Tue, 13 Sep 2005 12:38:14 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFDrq-0006xd-BI for ipsec@ietf.org; Tue, 13 Sep 2005 12:42:52 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8DGbsIr020552; Tue, 13 Sep 2005 09:37:55 -0700 (PDT) Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.100]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8DGbq7T008889 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 13 Sep 2005 09:37:53 -0700 (PDT) Message-Id: <6.2.2.1.2.20050913093731.05e077e0@qcmail1.qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.2.1 Date: Tue, 13 Sep 2005 09:37:52 -0700 To: Geoffrey Huang , Yoav Nir From: Lakshminath Dondeti Subject: RE: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages In-Reply-To: <1126629354.25106.0.camel@ghuang-lnx.juniper.net> References: <200509130733.j8D7XlnP018402@michael.checkpoint.com> <1126629354.25106.0.camel@ghuang-lnx.juniper.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 09:35 AM 9/13/2005, Geoffrey Huang wrote: >Wouldn't the rekey notify payload also be useful for indicating that a >rekey timer should stop? I am not sure I understand. Please elaborate. thanks, Lakshminath >-g > >On Tue, 2005-09-13 at 10:34 +0300, Yoav Nir wrote: > > This issue has come up before. The only reasonable interpretation we > came up > > with is that IPSec is usually done by a machine that is also a firewall. > > Firewalls tend to be "stateful" in the sense that they follow connections. > > A firewall-vpn device may expect a single connection to use the same IPSec > > SA all the time, so the rekey notification serves as an early warning that > > future packets using the rekeyed SA may come from the new SA. > > > > I know this is a dagerous assumption to make, because there is no reason to > > think that the packets from a single connection shouldn't use different > > parallel SAs, but that's the only justification I can come up with for > > explicitly saying that this SA replaces that SA. > > > > -----Original Message----- > > > > > > > > >I think the inclusion of the Notify merely says, "I'm rekeying SA with > > >SPI X in this CHILD exchange." This is different than "I'm replacing SA > > >with SPI X with the new SA we're about to create." > > > > I understand that. However, I am not sure what actions might be taken > > based on that information. > > > > > > > > Finally, what is the purpose of the N payload in the CREATE_CHILD_SA > > > exchange? > > > > > > > > > >To indicate that the SA you're negotiating is a rekey, and not a > > >deliberate parallel SA. See section 2.8: > > > > Not sure why the peer needs to indicate that an SA as being rekeyed, if it > > is going to send an explicit "delete" anyway. Other than an early warning > > :-), I cannot think of other reasons. > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 15 06:05:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFqc1-0008W9-Rr; Thu, 15 Sep 2005 06:05:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFqbz-0008Vy-TP for ipsec@megatron.ietf.org; Thu, 15 Sep 2005 06:05:00 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01090 for ; Thu, 15 Sep 2005 06:04:57 -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.43) id 1EFqgj-0003fo-Um for ipsec@ietf.org; Thu, 15 Sep 2005 06:09:56 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j8FA3Kvs019236 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 15 Sep 2005 13:03:20 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j8FA3BJn013274; Thu, 15 Sep 2005 13:03:11 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17193.18143.691032.354648@fireball.kivinen.iki.fi> Date: Thu, 15 Sep 2005 13:03:11 +0300 From: Tero Kivinen To: "Mohan Parthasarathy" Subject: Re: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages In-Reply-To: <00b401c5b7ea$f68d1ac0$6701a8c0@adithya> References: <6.2.2.1.2.20050912115245.02fcbb80@qcmail1.qualcomm.com> <1126556991.10962.5.camel@ghuang-lnx.juniper.net> <00b401c5b7ea$f68d1ac0$6701a8c0@adithya> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 21 min X-Total-Time: 61 min X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d 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 Mohan Parthasarathy writes: > But i wonder what the purpose of N(REKEY_SA) is ? What is the > responder supposed to do with REKEY_SA notification ? If it just > ignores it, then it is the same as the CREATE_CHILD_SA ? One can > potentially use it to insert the new SA in front of the old SA so > that outbound traffic can use the new SA. But you can't do so for > the reasons given in the last paragraph of section 2.8. There are several resons for the N(REKEY_SA). The basic idea is to get rid of that heuristic that happened in IKEv1, where implementations searched their SAs trying to find out if this is rekey or not. To explicitly tell that is rekey get rid of that. Then we end up the question why does the responder need to know this is rekey. There are multiple reasons for that, and most of them depend on the implementations. Most commons ones (not in any particular order, and not all are applicable in all implementations) 1) To keep statistics over SAs over rekeys they need to know from which SA the old statistics need to be copied to this new SA (i.e. they want to show that this SA has moved XX bytes, and the whole SA family including all rekeys have moved YY bytes over ZZ rekeys etc). 2) They want to optimize the rekeying operation, meaning that they know that the sending to both new and IPsec SA is is not needed at the same time, so they can for example allocate shared crypto context to the outgoing traffic. I.e. they keep the current old outbound SA in the crypto core and use it, until they receive packet for the new inbound SA, and then they exchange the contents of the outbound crypto core to use new SA. They can also do this for the inbound traffic, in a way that they keep the old inbound SA in the crypto core, and just store the new inbound SA in memory, and when they got SPI not found from the crypto core, they can do processing on the slowpath and check if the new SPI they have matches the packet, and if so swap the new and old inboud SAs. They still need to be able to process inbound traffic with the old SA, but that is not very common, so it might be even done on the slowpath. 3) They want to make sure the new SA shares the same narrowed traffic selectors than the old SA before rekey, so that some of the traffic isn't suddenly left outside of the tunnel because of the different narrowing happening. I.e. initiator SPD has 10.0.0.0/8 <-> 192.168.0.0/16 and he proposes that on the rekey too. The responder SPD has 10.0.0.0/8 <-> 192.168.1.0/24, 192.168.4.0/24. The old traffic selectors of the rekeyed SA was 10.0.0.0/8 <-> 192.168.4.0/24 as the first packet happened to go to that network, and responder decided to have separate SAs per net. When rekeying the responder can check from the old SA what was the traffic selectors there, and try to match them in the rekeyed SA also (otherwise it might happen that this rekeyed SA is not matching the traffic old SA had, thus it wasn't working rekey). Initiator and responder want to send full decorellated SPD entry selt when rekeying so they will catch policy changes. 4) There is also implementations that will keep track on TCP flows and so on, and keep them on the same SA all the time. They want to know the new SA for those flows, so they are sure they are matching the rules specified for the flow. 5) The responder might have extra traffic selectors like QoS parameters, and he might want to keep the same traffic on the same SA after rekey also. 6) Responder might also want to keep track of SAs to support channel bindings or similars etc. Because of that it was considered better not to do IKEv1 style guessing on the responder, but explicitly mention what SA is rekeyed, so that responder can easily do those implementation dependend things. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 15 10:32:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFun4-0000Hl-I8; Thu, 15 Sep 2005 10:32:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFun2-0000HM-0i for ipsec@megatron.ietf.org; Thu, 15 Sep 2005 10:32:40 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14451 for ; Thu, 15 Sep 2005 10:32:37 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.206]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFurn-0002eQ-Sd for ipsec@ietf.org; Thu, 15 Sep 2005 10:37:39 -0400 Received: by rproxy.gmail.com with SMTP id r35so74135rna for ; Thu, 15 Sep 2005 07:32:33 -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=cfs9p/qsZWqhk+pnW8iCgWX3+eZw8dTus9EHz1J699yEgI/mQi3zVS10NuPgsGWrUh3lHzlsNaSGgDrzNXuFLPHchYxx37384Ci+dmGVMHDz+6p1YAhljCMdsA8u2e9VUKQQ/u2x7rrT3LQ94x4amuXDEzVI9ZSoXX27Qi0Rrgw= Received: by 10.39.1.28 with SMTP id d28mr168491rni; Thu, 15 Sep 2005 07:32:33 -0700 (PDT) Received: by 10.38.9.77 with HTTP; Thu, 15 Sep 2005 07:32:33 -0700 (PDT) Message-ID: Date: Thu, 15 Sep 2005 22:32:33 +0800 From: Wade Yin To: =?ISO-2022-JP?B?GyRCRU49VTFtGyhC?= <210313041@suda.edu.cn> Subject: Re: [Ipsec] Is there anyone who install IKEv2? In-Reply-To: <20050910143036.AFBD66CA09@proxy3.suda.edu.cn> Mime-Version: 1.0 References: <20050910143036.AFBD66CA09@proxy3.suda.edu.cn> X-Spam-Score: 1.9 (+) X-Scan-Signature: a87a9cdae4ac5d3fbeee75cd0026d632 Cc: "ipsec@ietf.org" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: yhuide@gmail.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0059331755==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0059331755== Content-Type: multipart/alternative; boundary="----=_Part_9681_15713809.1126794753174" ------=_Part_9681_15713809.1126794753174 Content-Type: text/plain; charset=GB2312 Content-Disposition: inline Content-Transfer-Encoding: base64 VGhhdCdzIG5vdCBhIGlwc2VjLXRvb2xzIHByb2JsZW0sIGEgc2ltcGxlIHJlc29sdXRpb24gaXM6 IGluc3RhbGwgYSBmdWxsIAp2ZXJzaW9uIGxpbnV4KGFjdHVhbGx5LCB0aGVyZSBpcyBubyBmdWxs IHZlcnNpb24sIGxpbnV4IHNvZnR3YXJlIGlzIHNvIG1hbnksIApidXQgRmVkb3JhIDMgaXMgbm90 IGJhZCksIGFsbCB0aGUgbmVjZXNzYXJ5IHRvb2xzIHNob3VsZCBiZSBpbnN0YWxsZWQgaW4gCnlv dXIgUEMsIGFuZCB0aGVuIHRyeSBpdCBhZ2Fpbi4KICDB7c3io6wguty439DLv7S1vcC019QuY261 xMXz09EuCgogT24gOS8xMC8wNSwgtsW0utHgIDwyMTAzMTMwNDFAc3VkYS5lZHUuY24+IHdyb3Rl OiAKPiAKPiBISSEKPiAKPiAKPiBJJ20gc3R1ZHlpbmcgSUtFdjIgbm93LiBSZWNlbnRseSBpIHdh bnQgdG8gaW5zdGFsbCBpa2V2Mi0yMDA1MDkwMiB3cml0dGVuIAo+IGJ5IG1hcmN1cGljIGFuZCBz Z3Jvcywgd2hpY2ggaXMgZG93bmxvYWQgZnJvbSBzb3VyY2Vmb3JnZS4gSG93ZXZlcixpdCAKPiBm YWlsZWQuIEhlcmUgaXMgc29tZSBlcnJvciBpbmZvLgo+IAo+ICgxKSB3aGVuIGluc3RhbGxpbmcg bG9nNGMgMS4wLjEwIKGqoaogZmlyc3QgLi9jb25maWd1cmUsIHRoZW4gbWFrZSwgYnV0IAo+IGVy cm9yIG9jY3VycmVkOgo+ICJjZCAuICYmIFwKPiAvYmluL3NoIC9ob21lL3J1bm5pbmcvbG9nNGMt MS4wLjEwL2NvbmZpZy9taXNzaW5nIC0tcnVuIGF1dG9tYWtlIC0tZ251IAo+IE1ha2VmaWxlCj4g YWNsb2NhbC5tNDogNDIxOiBgYXV0b21ha2UgcmVxdWlyZXMgYEFNX0NPTkZJR19IRUFERVInLCBu b3QgCj4gYEFDX0NPTkZJR19IRUFERVInCj4gY29uZmlndXJlLmluIDxodHRwOi8vY29uZmlndXJl LmluPjogNDIxOiByZXF1aXJlZCBmaWxlIGAuLyRAKV0uaW4nIG5vdCAKPiBmb3VuZAo+IGNkIC4g JiYgL2Jpbi9zaCAvaG9tZS9ydW5uaW5nL2xvZzRjLTEuMC4xMC9jb25maWcvbWlzc2luZyAtLXJ1 biBhdXRvY29uZgo+IGNvbmZpZ3VyZS5pbjozOSA8aHR0cDovL2NvbmZpZ3VyZS5pbjozOT46IGVy cm9yOiBwb3NzaWJseSB1bmRlZmluZWQgbWFjcm86IAo+IEFDX1BST0dfTElCVE9PTAo+IElmIHRo aXMgdG9rZW4gYW5kIG90aGVycyBhcmUgbGVnaXRpbWF0ZSwgcGxlYXNlIHVzZSBtNF9wYXR0ZXJu X2FsbG93Lgo+IFNlZSB0aGUgQXV0b2NvbmYgZG9jdW1lbnRhdGlvbi4KPiBjb25maWd1cmUuaW46 ODkgPGh0dHA6Ly9jb25maWd1cmUuaW46ODk+OiBlcnJvcjogcG9zc2libHkgdW5kZWZpbmVkIG1h Y3JvOiAKPiBBTV9QQVRIX0VYUEFUCj4gV0FSTklORzogYGF1dG9jb25mJyBpcyBtaXNzaW5nIG9u IHlvdXIgc3lzdGVtLiBZb3Ugc2hvdWxkIG9ubHkgbmVlZCBpdCBpZgo+IHlvdSBtb2RpZmllZCBg Y29uZmlndXJlLmluJy4gWW91IG1pZ2h0IHdhbnQgdG8gaW5zdGFsbCB0aGUKPiBgQXV0b2NvbmYn IGFuZCBgR05VIG00JyBwYWNrYWdlcy4gR3JhYiB0aGVtIGZyb20gYW55IEdOVQo+IGFyY2hpdmUg c2l0ZS4iCj4gCj4gKDIpIHRoZW4gaSBkb3dubG9hZGVkIGBBdXRvY29uZicgYW5kIGBHTlUgbTQn LGJ1dCBpIGNvdWxkbid0IHVuZGVyc3RhbmQgCj4gd2hhdCBHTlUgbTQgaXMuV291bGQgeW91IHBs ZWFzZSBtYWtlIGFuIGV4cGxhaW5hdGlvbiA/Cj4gCj4gVGhhbmtzIGZvciBhaGVhZC4KPiAKPiAK PiBEdSBDaHVueWFuCj4gMjEwMzEzMDQxQHN1ZGEuZWR1LmNuCj4gMjAwNS0wOS0xMAo+IAo+IAo+ IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCj4gSXBzZWMg bWFpbGluZyBsaXN0Cj4gSXBzZWNAaWV0Zi5vcmcKPiBodHRwczovL3d3dzEuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9pcHNlYwo+IAo+IAo+Cg== ------=_Part_9681_15713809.1126794753174 Content-Type: text/html; charset=GB2312 Content-Disposition: inline Content-Transfer-Encoding: base64 PGRpdj5UaGF0J3Mgbm90IGEgaXBzZWMtdG9vbHMgcHJvYmxlbSwmbmJzcDsgYSBzaW1wbGUgcmVz b2x1dGlvbiBpczogaW5zdGFsbCBhIGZ1bGwgdmVyc2lvbiBsaW51eChhY3R1YWxseSwgdGhlcmUg aXMgbm8gZnVsbCB2ZXJzaW9uLCBsaW51eCBzb2Z0d2FyZSBpcyBzbyBtYW55LCBidXQgRmVkb3Jh IDMgaXMgbm90IGJhZCksIGFsbCB0aGUgbmVjZXNzYXJ5IHRvb2xzIHNob3VsZCBiZSBpbnN0YWxs ZWQgaW4geW91ciBQQywgYW5kIHRoZW4gdHJ5IGl0IGFnYWluLgo8L2Rpdj4KPGRpdj4mbmJzcDs8 L2Rpdj4KPGRpdj4mbmJzcDs8L2Rpdj4KPGRpdj7B7c3io6wguty439DLv7S1vcC019QuY261xMXz 09EuPGJyPjxicj4mbmJzcDs8L2Rpdj4KPGRpdj48c3BhbiBjbGFzcz0iZ21haWxfcXVvdGUiPk9u IDkvMTAvMDUsIDxiIGNsYXNzPSJnbWFpbF9zZW5kZXJuYW1lIj62xbS60eA8L2I+ICZsdDs8YSBo cmVmPSJtYWlsdG86MjEwMzEzMDQxQHN1ZGEuZWR1LmNuIj4yMTAzMTMwNDFAc3VkYS5lZHUuY248 L2E+Jmd0OyB3cm90ZTo8L3NwYW4+CjxibG9ja3F1b3RlIGNsYXNzPSJnbWFpbF9xdW90ZSIgc3R5 bGU9IlBBRERJTkctTEVGVDogMWV4OyBNQVJHSU46IDBweCAwcHggMHB4IDAuOGV4OyBCT1JERVIt TEVGVDogI2NjYyAxcHggc29saWQiPkhJITxicj48YnI+PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyBJJ20gc3R1ZHlpbmcgSUtFdjIgbm93LiBSZWNlbnRseSBpIHdhbnQg dG8gaW5zdGFsbCBpa2V2Mi0yMDA1MDkwMiB3cml0dGVuIGJ5IG1hcmN1cGljIGFuZCBzZ3Jvcywg d2hpY2ggaXMgZG93bmxvYWQgZnJvbSBzb3VyY2Vmb3JnZS4gSG93ZXZlcixpdCBmYWlsZWQuIEhl cmUgaXMgc29tZSBlcnJvciBpbmZvLgo8YnI+PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAoMSkgd2hlbiBpbnN0YWxsaW5nIGxvZzRjIDEuMC4xMCChqqGqIGZpcnN0IC4v Y29uZmlndXJlLCB0aGVuIG1ha2UsIGJ1dCBlcnJvciBvY2N1cnJlZDo8YnI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7ICZxdW90O2NkIC4gJmFtcDsmYW1wOyBcPGJyPiZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyAvYmluL3NoIC9ob21lL3J1bm5pbmcvbG9nNGMtMS4wLjEwL2NvbmZpZy9taXNz aW5nIC0tcnVuIGF1dG9tYWtlIC0tZ251Jm5ic3A7Jm5ic3A7TWFrZWZpbGUKPGJyPiZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyBhY2xvY2FsLm00OiA0MjE6IGBhdXRvbWFrZSByZXF1aXJlcyBg QU1fQ09ORklHX0hFQURFUicsIG5vdCBgQUNfQ09ORklHX0hFQURFUic8YnI+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHA6Ly9jb25maWd1cmUuaW4iPmNvbmZpZ3VyZS5p bjwvYT46IDQyMTogcmVxdWlyZWQgZmlsZSBgLi8kQCldLmluJyBub3QgZm91bmQ8YnI+Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGNkIC4gJmFtcDsmYW1wOyAvYmluL3NoIC9ob21lL3J1bm5p bmcvbG9nNGMtCjEuMC4xMC9jb25maWcvbWlzc2luZyAtLXJ1biBhdXRvY29uZjxicj4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgPGEgaHJlZj0iaHR0cDovL2NvbmZpZ3VyZS5pbjozOSI+Y29u ZmlndXJlLmluOjM5PC9hPjogZXJyb3I6IHBvc3NpYmx5IHVuZGVmaW5lZCBtYWNybzogQUNfUFJP R19MSUJUT09MPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBJZiB0aGlzIHRva2VuIGFuZCBv dGhlcnMgYXJlIGxlZ2l0aW1hdGUsIHBsZWFzZSB1c2UgbTRfcGF0dGVybl9hbGxvdy4KPGJyPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBTZWUgdGhlIEF1dG9jb25mIGRvY3VtZW50YXRpb24uPGJy PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwOi8vY29uZmlndXJlLmlu Ojg5Ij5jb25maWd1cmUuaW46ODk8L2E+OiBlcnJvcjogcG9zc2libHkgdW5kZWZpbmVkIG1hY3Jv OiBBTV9QQVRIX0VYUEFUPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBX QVJOSU5HOiBgYXV0b2NvbmYnIGlzIG1pc3Npbmcgb24geW91ciBzeXN0ZW0uJm5ic3A7Jm5ic3A7 WW91IHNob3VsZCBvbmx5IG5lZWQgaXQgaWYKPGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO3lvdSBtb2RpZmllZCBgY29uZmlndXJlLmluJy4mbmJzcDsm bmJzcDtZb3UgbWlnaHQgd2FudCB0byBpbnN0YWxsIHRoZTxicj4mbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtgQXV0b2NvbmYnIGFuZCBgR05VIG00JyBwYWNr YWdlcy4mbmJzcDsmbmJzcDtHcmFiIHRoZW0gZnJvbSBhbnkgR05VPGJyPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2FyY2hpdmUgc2l0ZS4mcXVvdDs8YnI+ PGJyPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAoMikgdGhlbiBpIGRvd25s b2FkZWQmbmJzcDsmbmJzcDtgQXV0b2NvbmYnIGFuZCBgR05VIG00JyxidXQgaSBjb3VsZG4ndCB1 bmRlcnN0YW5kIHdoYXQgR05VIG00IAppcy5Xb3VsZCB5b3UgcGxlYXNlIG1ha2UgYW4mbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtleHBsYWluYXRpb24gPzxicj48YnI+VGhh bmtzIGZvciBhaGVhZC48YnI+PGJyPjxicj5EdSBDaHVueWFuPGJyPjxhIGhyZWY9Im1haWx0bzoy MTAzMTMwNDFAc3VkYS5lZHUuY24iPjIxMDMxMzA0MUBzdWRhLmVkdS5jbjwvYT48YnI+MjAwNS0w OS0xMDxicj48YnI+PGJyPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fCjxicj5JcHNlYyBtYWlsaW5nIGxpc3Q8YnI+PGEgaHJlZj0ibWFpbHRvOklwc2VjQGll dGYub3JnIj5JcHNlY0BpZXRmLm9yZzwvYT48YnI+PGEgaHJlZj0iaHR0cHM6Ly93d3cxLmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vaXBzZWMiPmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lwc2VjPC9hPjxicj48YnI+PGJyPjwvYmxvY2txdW90ZT48L2Rpdj48YnI+Cg== ------=_Part_9681_15713809.1126794753174-- --===============0059331755== 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 --===============0059331755==-- From ipsec-bounces@ietf.org Thu Sep 15 14:25:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFyQT-0003bH-9U; Thu, 15 Sep 2005 14:25:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFyQQ-0003bC-GK for ipsec@megatron.ietf.org; Thu, 15 Sep 2005 14:25:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25608 for ; Thu, 15 Sep 2005 14:25:32 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFyVH-0000FO-F5 for ipsec@ietf.org; Thu, 15 Sep 2005 14:30:35 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8FIPHIr021125; Thu, 15 Sep 2005 11:25:18 -0700 (PDT) Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.100]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8FIPFkN002446 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Sep 2005 11:25:15 -0700 (PDT) Message-Id: <6.2.2.1.2.20050915111812.02aa8488@qcmail1.qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.2.1 Date: Thu, 15 Sep 2005 11:25:13 -0700 To: Tero Kivinen , "Mohan Parthasarathy" From: Lakshminath Dondeti Subject: Re: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages In-Reply-To: <17193.18143.691032.354648@fireball.kivinen.iki.fi> References: <6.2.2.1.2.20050912115245.02fcbb80@qcmail1.qualcomm.com> <1126556991.10962.5.camel@ghuang-lnx.juniper.net> <00b401c5b7ea$f68d1ac0$6701a8c0@adithya> <17193.18143.691032.354648@fireball.kivinen.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 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 Tero, On your notes in item #3 of your email below: Are you saying that when two peers rekey an IPsec SA, they ought to use the same selectors? I think not. ( I don't recall anything like that specified in the ikev2 spec) Furthermore, are you saying that the Initiator must send the same TS payload as in the original IPsec SA proposal? Why? Even if we agree on the above statement of rekeyed SAs MUST use same selectors, I'd say that the Initiator then MUST propose the agreed upon (or narrowed) selectors (TSr) and expect that the responder would readily agree. But, back to the original point. I think that a CREATE_CHILD_SA exchange message, even in case of rekeying, can carry any TSi the initiator chooses and does not depend on the current selectors. regards, Lakshminath At 03:03 AM 9/15/2005, Tero Kivinen wrote: > > > >3) They want to make sure the new SA shares the same narrowed traffic > selectors than the old SA before rekey, so that some of the traffic > isn't suddenly left outside of the tunnel because of the different > narrowing happening. I.e. initiator SPD has 10.0.0.0/8 <-> > 192.168.0.0/16 and he proposes that on the rekey too. The responder > SPD has 10.0.0.0/8 <-> 192.168.1.0/24, 192.168.4.0/24. The old > traffic selectors of the rekeyed SA was 10.0.0.0/8 <-> > 192.168.4.0/24 as the first packet happened to go to that network, > and responder decided to have separate SAs per net. When rekeying > the responder can check from the old SA what was the traffic > selectors there, and try to match them in the rekeyed SA also > (otherwise it might happen that this rekeyed SA is not matching the > traffic old SA had, thus it wasn't working rekey). Initiator and > responder want to send full decorellated SPD entry selt when > rekeying so they will catch policy changes. > > >Because of that it was considered better not to do IKEv1 style >guessing on the responder, but explicitly mention what SA is rekeyed, >so that responder can easily do those implementation dependend things. >-- >kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 15 14:32:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFyXG-0006Cv-PQ; Thu, 15 Sep 2005 14:32:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFyXF-0006Cb-5e for ipsec@megatron.ietf.org; Thu, 15 Sep 2005 14:32:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA26312 for ; Thu, 15 Sep 2005 14:32:35 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFyc2-0000ZY-6h for ipsec@ietf.org; Thu, 15 Sep 2005 14:37:38 -0400 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j8FIWVHT025541; Thu, 15 Sep 2005 11:32:31 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j8FIWUUj015080; Thu, 15 Sep 2005 14:32:30 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j8FIWTEp018511; Thu, 15 Sep 2005 14:32:29 -0400 (EDT) Subject: Re: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages From: Bill Sommerfeld To: Lakshminath Dondeti In-Reply-To: <6.2.2.1.2.20050915111812.02aa8488@qcmail1.qualcomm.com> References: <6.2.2.1.2.20050912115245.02fcbb80@qcmail1.qualcomm.com> <1126556991.10962.5.camel@ghuang-lnx.juniper.net> <00b401c5b7ea$f68d1ac0$6701a8c0@adithya> <17193.18143.691032.354648@fireball.kivinen.iki.fi> <6.2.2.1.2.20050915111812.02aa8488@qcmail1.qualcomm.com> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1126809149.14802.406.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Thu, 15 Sep 2005 14:32:29 -0400 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Mohan Parthasarathy , Tero Kivinen 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 Thu, 2005-09-15 at 14:25, Lakshminath Dondeti wrote: > Are you saying that when two peers rekey an IPsec SA, they ought to use the > same selectors? I think not. ( I don't recall anything like that > specified in the ikev2 spec) if the selectors change, when would you consider this a rekey rather than a parallel SA? - Bill _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 15 14:46:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFykF-0001aw-Jy; Thu, 15 Sep 2005 14:46:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EFykD-0001aU-13 for ipsec@megatron.ietf.org; Thu, 15 Sep 2005 14:46:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27300 for ; Thu, 15 Sep 2005 14:45:59 -0400 (EDT) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EFyp3-00011i-5g for ipsec@ietf.org; Thu, 15 Sep 2005 14:51:02 -0400 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j8FIChN22004 for ; Thu, 15 Sep 2005 11:12:43 -0700 X-mProtect: <200509151812> Nokia Silicon Valley Messaging Protection Received: from mvdhcp14193.americas.nokia.com (172.18.141.93, claiming to be "[127.0.0.1]") by darkstar.iprg.nokia.com smtpdKnalo4; Thu, 15 Sep 2005 11:12:41 PDT Message-ID: <4329C151.9000906@iprg.nokia.com> Date: Thu, 15 Sep 2005 11:45:37 -0700 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0.6 (Windows/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Subject: [Ipsec] draft-ietf-mip6-ikev2-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 hi all, draft-ietf-mip6-ikev2-ipsec-03 describes how IKEv2 and rfc2401bis can be used with MIPv6 for securing MIPv6 signaling messages. http://www.ietf.org/internet-drafts/draft-ietf-mip6-ikev2-ipsec-03 this draft is under a WG last call in the MIP6 WG right now. it would be great if some of you could review this draft and provide comments. thanks Vijay _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 15 17:30:39 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG1JX-0002hO-RU; Thu, 15 Sep 2005 17:30:39 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG1JV-0002hG-K1 for ipsec@megatron.ietf.org; Thu, 15 Sep 2005 17:30:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA11553 for ; Thu, 15 Sep 2005 17:30:34 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EG1ON-0007Uk-8K for ipsec@ietf.org; Thu, 15 Sep 2005 17:35:40 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8FLUJIr014615; Thu, 15 Sep 2005 14:30:20 -0700 (PDT) Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.100]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8FLUH7T022962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Sep 2005 14:30:17 -0700 (PDT) Message-Id: <6.2.2.1.2.20050915142919.02f5ba08@qcmail1.qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.2.1 Date: Thu, 15 Sep 2005 14:30:14 -0700 To: Bill Sommerfeld From: Lakshminath Dondeti Subject: Re: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages In-Reply-To: <1126809149.14802.406.camel@thunk> References: <6.2.2.1.2.20050912115245.02fcbb80@qcmail1.qualcomm.com> <1126556991.10962.5.camel@ghuang-lnx.juniper.net> <00b401c5b7ea$f68d1ac0$6701a8c0@adithya> <17193.18143.691032.354648@fireball.kivinen.iki.fi> <6.2.2.1.2.20050915111812.02aa8488@qcmail1.qualcomm.com> <1126809149.14802.406.camel@thunk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: ipsec@ietf.org, Mohan Parthasarathy , Tero Kivinen 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 11:32 AM 9/15/2005, Bill Sommerfeld wrote: >On Thu, 2005-09-15 at 14:25, Lakshminath Dondeti wrote: > > Are you saying that when two peers rekey an IPsec SA, they ought to use > the > > same selectors? I think not. ( I don't recall anything like that > > specified in the ikev2 spec) > >if the selectors change, when would you consider this a rekey rather >than a parallel SA? > > - Bill If two parties know explicitly that they definitely don't want more than one IPsec SA between them. Lakshminath _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 15 17:46:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG1Yp-00070n-1J; Thu, 15 Sep 2005 17:46:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG1Yn-0006zv-8D for ipsec@megatron.ietf.org; Thu, 15 Sep 2005 17:46:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12245 for ; Thu, 15 Sep 2005 17:46:22 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EG1dc-0007wq-VO for ipsec@ietf.org; Thu, 15 Sep 2005 17:51:28 -0400 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j8FLkJHT012345; Thu, 15 Sep 2005 14:46:20 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j8FLkJUj015982; Thu, 15 Sep 2005 17:46:19 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j8FLkISe019252; Thu, 15 Sep 2005 17:46:19 -0400 (EDT) Subject: Re: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages From: Bill Sommerfeld To: Lakshminath Dondeti In-Reply-To: <6.2.2.1.2.20050915142919.02f5ba08@qcmail1.qualcomm.com> References: <6.2.2.1.2.20050912115245.02fcbb80@qcmail1.qualcomm.com> <1126556991.10962.5.camel@ghuang-lnx.juniper.net> <00b401c5b7ea$f68d1ac0$6701a8c0@adithya> <17193.18143.691032.354648@fireball.kivinen.iki.fi> <6.2.2.1.2.20050915111812.02aa8488@qcmail1.qualcomm.com> <1126809149.14802.406.camel@thunk> <6.2.2.1.2.20050915142919.02f5ba08@qcmail1.qualcomm.com> Content-Type: text/plain Message-Id: <1126820778.14802.439.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Thu, 15 Sep 2005 17:46:18 -0400 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Mohan Parthasarathy , Tero Kivinen 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 Thu, 2005-09-15 at 17:30, Lakshminath Dondeti wrote: > If two parties know explicitly that they definitely don't want more than > one IPsec SA between them. 2401bis and IKEv2 require support for multiple IPsec SA's. - Bill _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 15 18:17:05 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG22T-0007QC-0F; Thu, 15 Sep 2005 18:17:05 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EG22Q-0007OH-EX for ipsec@megatron.ietf.org; Thu, 15 Sep 2005 18:17:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA14652 for ; Thu, 15 Sep 2005 18:16:59 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EG27H-0000Lc-Dd for ipsec@ietf.org; Thu, 15 Sep 2005 18:22:05 -0400 Received: from sabrina.qualcomm.com (sabrina.qualcomm.com [129.46.61.150]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8FMGfcU006700 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 15 Sep 2005 15:16:42 -0700 (PDT) Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.100]) by sabrina.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8FMGd7T012062 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 15 Sep 2005 15:16:39 -0700 (PDT) Message-Id: <6.2.2.1.2.20050915150459.03145d70@qcmail1.qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.2.1 Date: Thu, 15 Sep 2005 15:16:37 -0700 To: Bill Sommerfeld From: Lakshminath Dondeti Subject: Re: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages In-Reply-To: <1126820778.14802.439.camel@thunk> References: <6.2.2.1.2.20050912115245.02fcbb80@qcmail1.qualcomm.com> <1126556991.10962.5.camel@ghuang-lnx.juniper.net> <00b401c5b7ea$f68d1ac0$6701a8c0@adithya> <17193.18143.691032.354648@fireball.kivinen.iki.fi> <6.2.2.1.2.20050915111812.02aa8488@qcmail1.qualcomm.com> <1126809149.14802.406.camel@thunk> <6.2.2.1.2.20050915142919.02f5ba08@qcmail1.qualcomm.com> <1126820778.14802.439.camel@thunk> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ipsec@ietf.org, Mohan Parthasarathy , Tero Kivinen 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 02:46 PM 9/15/2005, Bill Sommerfeld wrote: >On Thu, 2005-09-15 at 17:30, Lakshminath Dondeti wrote: > > If two parties know explicitly that they definitely don't want more than > > one IPsec SA between them. > >2401bis and IKEv2 require support for multiple IPsec SA's. > > - Bill I just checked the compliance requirements section (Sec 4) of ikev2-17, and the following are under " There are a series of optional features that can easily be ignored by a particular implementation if it does not support that feature. Those features include: ... Ability to establish multiple ESP and/or AH SAs within a single IKE_SA. Ability to rekey SAs. ... " I would like to rekey an SA, but don't care about supporting multiple SAs. My reading of the N payload was that I could actually do it. I do understand the implications of changing selectors as well as rekeying while deleting the old SA (i.e., some dropped packets on the old SA), but if my application is tolerant to the implications (both parties understand the implications and therefore are willing to stop traffic while an SA is rekeyed), but wants to be as efficient as possible (just for argument sake), it should be able to do that. As I make this case, I recall an old DARPA project, where the requirement was that when rekeying a group SA, the sender MUST stop transmission, rekey the GSA, and then start transmission via the new GSA. The premise is that the old group keys are (may have been) compromised, but we know that long term keys are not and would like to rekey the SA. Lakshminath _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 16 05:05:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGCAM-0006UD-DH; Fri, 16 Sep 2005 05:05:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGCAK-0006U8-II for ipsec@megatron.ietf.org; Fri, 16 Sep 2005 05:05:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03349 for ; Fri, 16 Sep 2005 05:05:49 -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.43) id 1EGCFJ-0007TE-4r for ipsec@ietf.org; Fri, 16 Sep 2005 05:11:01 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j8G94ipd002352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Sep 2005 12:04:44 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j8G94cA4004223; Fri, 16 Sep 2005 12:04:38 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17194.35494.329208.914504@fireball.kivinen.iki.fi> Date: Fri, 16 Sep 2005 12:04:38 +0300 From: Tero Kivinen To: Lakshminath Dondeti Subject: Re: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages In-Reply-To: <6.2.2.1.2.20050915111812.02aa8488@qcmail1.qualcomm.com> References: <6.2.2.1.2.20050912115245.02fcbb80@qcmail1.qualcomm.com> <1126556991.10962.5.camel@ghuang-lnx.juniper.net> <00b401c5b7ea$f68d1ac0$6701a8c0@adithya> <17193.18143.691032.354648@fireball.kivinen.iki.fi> <6.2.2.1.2.20050915111812.02aa8488@qcmail1.qualcomm.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 11 min X-Total-Time: 11 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Mohan Parthasarathy 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 Lakshminath Dondeti writes: > Are you saying that when two peers rekey an IPsec SA, they ought to use the > same selectors? I think not. ( I don't recall anything like that > specified in the ikev2 spec) Depends what you mean by same selectors. The actual traffic selectors in the IKE can and will be different, but the traffic selectors should be derived from the same SPD rule than before (otherwise it would not be rekey, right?). If the responder narrowed traffic selectors last time, initiator should still use the full rules from SPD not the narrowed traffic selectors, as the responders policy might have changed. If the SPD rules have changed since last time the traffic selectors resulted by this rekey can be different than last time, but both ends should make sure as much traffic as possible from the previous SA can be fitted to this new SA. > Furthermore, are you saying that the Initiator must send the same TS > payload as in the original IPsec SA proposal? The traffic selectors proposed should be based on the SPD entries, and they should be full set from SPD, not the narrowed set that was used in the SA being rekeyed. > Why? So that if either ends policy has changed, we actually take those changes in to account and create widest possible SAs that can pass the packets used by the old SA. It might even be wider than before. Example would be that initiator has policy 10.0.0.0/8 <-> 192.168.0.0/16 and responder had policy 10.0.0.0/8 <-> 192.168.2.0/24, but then new network 192.168.5.0/24 is added to the responder side, so after next rekey the SA will automatically have that network added to traffic selectors. > Even if we agree on > the above statement of rekeyed SAs MUST use same selectors, I'd say that > the Initiator then MUST propose the agreed upon (or narrowed) selectors > (TSr) and expect that the responder would readily agree. He could do that, but in that case SA selectors cannot never be expanded even when both end's policy has been changed. > But, back to the original point. I think that a CREATE_CHILD_SA exchange > message, even in case of rekeying, can carry any TSi the initiator chooses > and does not depend on the current selectors. I disagree. I think they MUST depend on same SPD rule that was used to create the current selectors. Otherwise it is not rekey, as it could be possible that the traffic we are transferring wno on the SA would not fit to that SA anymore. Remember that in the rekey we do have traffic we are supposed to move from that old SA to that new SA. If they have distincting set of traffic selectors, you cannot move that traffic. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 16 11:19:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGHzg-0000x1-RL; Fri, 16 Sep 2005 11:19:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGHze-0000wr-N4 for ipsec@megatron.ietf.org; Fri, 16 Sep 2005 11:19:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22950 for ; Fri, 16 Sep 2005 11:19:11 -0400 (EDT) From: tgschwendtner@reefpoint.com Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGI4f-0000a6-Ty for ipsec@ietf.org; Fri, 16 Sep 2005 11:24:27 -0400 Received: by email.quarrytech.com with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Sep 2005 11:15:30 -0400 Message-ID: <496A8683261CD211BF6C0008C733261A0551C6A5@email.quarrytech.com> To: ipsec@ietf.org Date: Fri, 16 Sep 2005 11:15:29 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: jcervantes@reefpoint.com Subject: [Ipsec] Clarification on error notifications, please 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 is not really clear to me what the scope of the following statement take from the IKEv2 draft, chapter 2.21, is. "A node receiving such an unprotected Notify payload MUST NOT respond and MUST NOT change the state of any existing SAs." My understanding is that this sentence only refers to the case where a node receives a message outside of the context of an IKE SA as outlined in the paragraph above this sentence, but not to the case where the node receives a notification on an IKE SA that is not (yet) completely negotiated. In particular, this sentence does not refer to an encrypted AUTHENTICATION_FAILED notification sent after a successful INIT exchange, although the notification will not be authenticated. (If this sentence were referring to such notifications, they would be not very meaningful.) Is my understanding correct? Thanks, Thomas G. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 16 11:44:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGINc-0000N2-W1; Fri, 16 Sep 2005 11:44:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGINb-0000Mh-OC for ipsec@megatron.ietf.org; Fri, 16 Sep 2005 11:43:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24849 for ; Fri, 16 Sep 2005 11:43:56 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGISb-0001VF-Pp for ipsec@ietf.org; Fri, 16 Sep 2005 11:49:12 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8GFhfIr018394; Fri, 16 Sep 2005 08:43:41 -0700 (PDT) Received: from LDONDETI.qualcomm.com (qconnect-10-50-65-103.qualcomm.com [10.50.65.103]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8GFhbkN021784 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 16 Sep 2005 08:43:39 -0700 (PDT) Message-Id: <6.2.2.1.2.20050916082148.02932390@qcmail1.qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.2.1 Date: Fri, 16 Sep 2005 08:43:37 -0700 To: Tero Kivinen From: Lakshminath Dondeti Subject: Re: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages In-Reply-To: <17194.35494.329208.914504@fireball.kivinen.iki.fi> References: <6.2.2.1.2.20050912115245.02fcbb80@qcmail1.qualcomm.com> <1126556991.10962.5.camel@ghuang-lnx.juniper.net> <00b401c5b7ea$f68d1ac0$6701a8c0@adithya> <17193.18143.691032.354648@fireball.kivinen.iki.fi> <6.2.2.1.2.20050915111812.02aa8488@qcmail1.qualcomm.com> <17194.35494.329208.914504@fireball.kivinen.iki.fi> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 Cc: ipsec@ietf.org, Mohan Parthasarathy 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 Tero, Many thanks for the clarifications. At 02:04 AM 9/16/2005, Tero Kivinen wrote: >Lakshminath Dondeti writes: > > Are you saying that when two peers rekey an IPsec SA, they ought to use > the > > same selectors? I think not. ( I don't recall anything like that > > specified in the ikev2 spec) > >Depends what you mean by same selectors. The actual traffic selectors >in the IKE can and will be different, but the traffic selectors should >be derived from the same SPD rule than before (otherwise it would not >be rekey, right?). If the responder narrowed traffic selectors last >time, initiator should still use the full rules from SPD not the >narrowed traffic selectors, as the responders policy might have >changed. Your note about the Initiator using the full rules from SPD makes sense to me now. Sorry I missed that before. Let me explore a couple of cases: Case 1: There are multiple IPsec SAs between 2 peers and one of the peers seeks to "rekey" one of the SAs. As you note, I think the initiator SHOULD start out with the same TS payloads as used in the original IPsec SA establishment (which in itself could have been the result of the initial IKE SA, or a CREATE-CHILD-SA exchange: rekey or a parallel SA). Case 2: There is a single IPsec SA between 2 peers and one of the peers' local policy changes -- there are dramatic changes in its SPD and it is still interested in a single IPsec SA with the peer with the new traffic policy. My take is that I'd use rekey -- since intent is still to replace that one IPsec SA -- with the new SPD information in the TS payloads. The Responder of course is welcome to accept or deny the new proposal. Some more inline notes below: >If the SPD rules have changed since last time the traffic selectors >resulted by this rekey can be different than last time, but both ends >should make sure as much traffic as possible from the previous SA can >be fitted to this new SA. This makes sense to me in Case 2 above. In Case 1, there are so many scenarios, including the following which makes me think that the above is just a rule of thumb. For instance an Initiator proposes a range of IP addresses to the Responder which let's say narrows the range down drastically. Let us further assume that the Initiator accepts the narrower range. The Responder in the future might propose a new CREATE_CHILD_SA exchange with a wider range and the Initiator accepts. Some implementations might choose to consolidate the SAs in a rekeying attempt and some might not. If I were implementing (or continuing my old hack at IKEv2 code), I'd guess that another implementation might choose any combination and willing to work with it. > > Furthermore, are you saying that the Initiator must send the same TS > > payload as in the original IPsec SA proposal? > >The traffic selectors proposed should be based on the SPD entries, and >they should be full set from SPD, not the narrowed set that was used >in the SA being rekeyed. I agree here, with the understanding that sometimes the "full set" might have been narrowed due to local policy changes -- either by firewall rules or other apps. > > Why? > >So that if either ends policy has changed, we actually take those >changes in to account and create widest possible SAs that can pass the >packets used by the old SA. It might even be wider than before. > >Example would be that initiator has policy 10.0.0.0/8 <-> >192.168.0.0/16 and responder had policy 10.0.0.0/8 <-> 192.168.2.0/24, >but then new network 192.168.5.0/24 is added to the responder side, so >after next rekey the SA will automatically have that network added to >traffic selectors. > > > Even if we agree on > > the above statement of rekeyed SAs MUST use same selectors, I'd say that > > the Initiator then MUST propose the agreed upon (or narrowed) selectors > > (TSr) and expect that the responder would readily agree. > >He could do that, but in that case SA selectors cannot never be >expanded even when both end's policy has been changed. > > > But, back to the original point. I think that a CREATE_CHILD_SA exchange > > message, even in case of rekeying, can carry any TSi the initiator chooses > > and does not depend on the current selectors. > >I disagree. I think they MUST depend on same SPD rule that was used to >create the current selectors. Otherwise it is not rekey, as it could >be possible that the traffic we are transferring wno on the SA would >not fit to that SA anymore. Tero, I think I can use some help here to understand the SPD rule. If that SPD rule you refer to has changed dramatically (recall Case 2 above), is it okay still to use rekey semantics? thanks and regards, Lakshminath >Remember that in the rekey we do have traffic we are supposed to move >from that old SA to that new SA. If they have distincting set of >traffic selectors, you cannot move that traffic. >-- >kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 16 17:19:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGNbv-0001xJ-1Q; Fri, 16 Sep 2005 17:19:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EGNbr-0001wB-0b for ipsec@megatron.ietf.org; Fri, 16 Sep 2005 17:19:03 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA20054 for ; Fri, 16 Sep 2005 17:18:59 -0400 (EDT) From: tgschwendtner@reefpoint.com Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EGNgv-0004TG-W1 for ipsec@ietf.org; Fri, 16 Sep 2005 17:24:18 -0400 Received: by email.quarrytech.com with Internet Mail Service (5.5.2653.19) id ; Fri, 16 Sep 2005 17:15:15 -0400 Message-ID: <496A8683261CD211BF6C0008C733261A0551C6A8@email.quarrytech.com> To: charliek@exchange.microsoft.com, ipsec@ietf.org Subject: RE: [Ipsec] Clarification on error notifications, please Date: Fri, 16 Sep 2005 17:15:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.3 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: jcervantes@reefpoint.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 To what messages do you refer to in the sentence "Such messages MUST NOT kill an SA"? In the next sentence, you say that "a cryptographically protected AUTHENTICATION_FAILED message should kill the SA". So, I infer that you mean AUTHENTICATION_FAILED messages that are in the clear, right? Thanks, Thomas G. > -----Original Message----- > From: Charlie Kaufman [mailto:charliek@exchange.microsoft.com] > Sent: Friday, September 16, 2005 4:23 PM > To: tgschwendtner@reefpoint.com; ipsec@ietf.org > Cc: jcervantes@reefpoint.com > Subject: RE: [Ipsec] Clarification on error notifications, please > > > Yes and no. > > The sentence only applies to SAs that have completed enough > initialization that cryptographic protection of messages is > possible. So > a failure response to an INIT message will not be > authenticated but that > message should not be ignored (though an implementation might wait a > while for a success response in case the failure was sent by a third > party in a DOS attempt). > > An AUTHENTICATION_FAILED notification, however, occurs after the first > two messages and can be cryptographically protected even though the SA > has not been authenticated. Such messages MUST NOT kill an SA. Only a > cryptographically protected AUTHENTICATION_FAILED message should kill > the SA. > > --Charlie Kaufman > > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of tgschwendtner@reefpoint.com > Sent: Friday, September 16, 2005 8:15 AM > To: ipsec@ietf.org > Cc: jcervantes@reefpoint.com > Subject: [Ipsec] Clarification on error notifications, please > > It is not really clear to me what the scope of the following statement > take > from the IKEv2 draft, chapter 2.21, is. > > "A node receiving such an unprotected Notify payload MUST NOT respond > and > MUST NOT change the state of any existing SAs." > > My understanding is that this sentence only refers to the case where a > node > receives a message outside of the context of an IKE SA as outlined in > the > paragraph above this sentence, but not to the case where the node > receives a > notification on an IKE SA that is not (yet) completely negotiated. In > particular, this sentence does not refer to an encrypted > AUTHENTICATION_FAILED notification sent after a successful INIT > exchange, > although the notification will not be authenticated. (If this sentence > were > referring to such notifications, they would be not very meaningful.) > Is my understanding correct? > > Thanks, > > Thomas G. > > > > _______________________________________________ > 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 Sep 18 20:41:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EH9ie-00029X-NS; Sun, 18 Sep 2005 20:41:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EH9id-00029S-SW for ipsec@megatron.ietf.org; Sun, 18 Sep 2005 20:41:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05447 for ; Sun, 18 Sep 2005 20:41:14 -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.43) id 1EH9o9-0006co-0n for ipsec@ietf.org; Sun, 18 Sep 2005 20:46:58 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j8J0dpsO024516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Sep 2005 03:39:51 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j8J0dgSD025692; Mon, 19 Sep 2005 03:39:42 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17198.2254.772477.228426@fireball.kivinen.iki.fi> Date: Mon, 19 Sep 2005 03:39:42 +0300 From: Tero Kivinen To: tgschwendtner@reefpoint.com Subject: [Ipsec] Clarification on error notifications, please In-Reply-To: <496A8683261CD211BF6C0008C733261A0551C6A5@email.quarrytech.com> References: <496A8683261CD211BF6C0008C733261A0551C6A5@email.quarrytech.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 18 min X-Total-Time: 18 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, jcervantes@reefpoint.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 tgschwendtner@reefpoint.com writes: > It is not really clear to me what the scope of the following statement take > from the IKEv2 draft, chapter 2.21, is. > > "A node receiving such an unprotected Notify payload MUST NOT respond and > MUST NOT change the state of any existing SAs." > > My understanding is that this sentence only refers to the case where a node > receives a message outside of the context of an IKE SA as outlined in the > paragraph above this sentence, but not to the case where the node receives a > notification on an IKE SA that is not (yet) completely negotiated. If the IKE SA is not finished, then it is not finished, thus we do not have IKE SA ready, thus we cannot use the protection of the IKE SA to send error messages. > In particular, this sentence does not refer to an encrypted > AUTHENTICATION_FAILED notification sent after a successful INIT > exchange, although the notification will not be authenticated. (If > this sentence were referring to such notifications, they would be > not very meaningful.) Is my understanding correct? We do not know if the INIT exchange was successfull before we actually manage to verify the AUTH payload of the IKE_AUTH. Attacker can modify IKE_SA_INIT message at will, and we only notice that when we verify the AUTH payload. If we cannot verify the AUTH payload, that means that either there is something wrong with authentication data (keying material, certificates etc) or someone have modified the IKE_SA_INIT. Just encrypting and mac'ing the packets with some diffie-hellman key without authentication, does NOT give those messages any more protection than clear text notifies have. To get authenticated notify messages you need be able to parse and check the AUTH payloads, so in the sense AUTHENTICATION_FAILED notification can never be sent in a protected way. After you get through the first IKE_AUTH exchange, then you have authenticated IKE SA and you can send authenticated error messages, but on the other hand you do not send AUTHENTICATION_FAILED after that point (i.e. if you have EAP, you send EAP failure instead of AUTHENTICATION_FAILED). -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Sep 18 20:46:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EH9ne-0003em-Vc; Sun, 18 Sep 2005 20:46:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EH9nd-0003eH-4c for ipsec@megatron.ietf.org; Sun, 18 Sep 2005 20:46:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA05757 for ; Sun, 18 Sep 2005 20:46: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.43) id 1EH9t9-0006le-Dn for ipsec@ietf.org; Sun, 18 Sep 2005 20:52:07 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j8J0jDwi005936 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Sep 2005 03:45:13 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j8J0j8lW016297; Mon, 19 Sep 2005 03:45:08 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17198.2580.148487.995517@fireball.kivinen.iki.fi> Date: Mon, 19 Sep 2005 03:45:08 +0300 From: Tero Kivinen To: Lakshminath Dondeti Subject: Re: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages In-Reply-To: <6.2.2.1.2.20050916082148.02932390@qcmail1.qualcomm.com> References: <6.2.2.1.2.20050912115245.02fcbb80@qcmail1.qualcomm.com> <1126556991.10962.5.camel@ghuang-lnx.juniper.net> <00b401c5b7ea$f68d1ac0$6701a8c0@adithya> <17193.18143.691032.354648@fireball.kivinen.iki.fi> <6.2.2.1.2.20050915111812.02aa8488@qcmail1.qualcomm.com> <17194.35494.329208.914504@fireball.kivinen.iki.fi> <6.2.2.1.2.20050916082148.02932390@qcmail1.qualcomm.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 2 min X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Mohan Parthasarathy 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 Lakshminath Dondeti writes: > >I disagree. I think they MUST depend on same SPD rule that was used to > >create the current selectors. Otherwise it is not rekey, as it could > >be possible that the traffic we are transferring wno on the SA would > >not fit to that SA anymore. > > Tero, I think I can use some help here to understand the SPD rule. If that > SPD rule you refer to has changed dramatically (recall Case 2 above), is it > okay still to use rekey semantics? If it is still same SPD rule, I think it should use the rekey. If there is no overlapping traffic with the old and new SPD entries, then it should probably simply destroy the old SA and create new SA (as there is no traffic that could be moved from old SA to new SA). The rekey do have an idea behind it that you move old traffic from the SA to this newly created SA... -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Sep 18 20:53:24 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EH9uO-00054i-Jg; Sun, 18 Sep 2005 20:53:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EH9uM-00054X-Ry for ipsec@megatron.ietf.org; Sun, 18 Sep 2005 20:53:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06217 for ; Sun, 18 Sep 2005 20:53:21 -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.43) id 1EH9zt-0006xj-3k for ipsec@ietf.org; Sun, 18 Sep 2005 20:59:05 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j8J0q4A5009940 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Sep 2005 03:52:04 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j8J0q0cd002270; Mon, 19 Sep 2005 03:52:00 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17198.2992.152739.366114@fireball.kivinen.iki.fi> Date: Mon, 19 Sep 2005 03:52:00 +0300 From: Tero Kivinen To: tgschwendtner@reefpoint.com Subject: RE: [Ipsec] Clarification on error notifications, please In-Reply-To: <496A8683261CD211BF6C0008C733261A0551C6A8@email.quarrytech.com> References: <496A8683261CD211BF6C0008C733261A0551C6A8@email.quarrytech.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 5 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: charliek@exchange.microsoft.com, ipsec@ietf.org, jcervantes@reefpoint.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 tgschwendtner@reefpoint.com writes: > To what messages do you refer to in the sentence "Such messages MUST NOT > kill an SA"? I think he is refereing the AUTHENTICATION_FAILED notifies. Thus getting AUTHENTICATION_FAILED notify message before you have finished checking AUTH payloads MUST NOT kill an SA, which means they are ignored, so there is really no point of even seding them ever. Also AUTHENTICATION_FAILED messages cannot be sent after the IKE_AUTH finishes, so the only case where they would be send authenticated would be when the first AUTH payload check works with EAP, and the EAP exchange itself succeeds (i.e. returns EAP(SUCCESS)), but the actual keying material generated by the EAP does not match, thus the AUTH payload verification of the second AUTH payload fails. > In the next sentence, you say that "a cryptographically > protected AUTHENTICATION_FAILED message should kill the SA". So, I infer > that you mean AUTHENTICATION_FAILED messages that are in the clear, right? He might be refering the case of getting AUTHENTICATION_FAILED after the first AUTH payload has already be verified (i.e. when we have already authenticated the responder of the exchange). > > -----Original Message----- > > From: Charlie Kaufman [mailto:charliek@exchange.microsoft.com] > > Sent: Friday, September 16, 2005 4:23 PM > > To: tgschwendtner@reefpoint.com; ipsec@ietf.org > > Cc: jcervantes@reefpoint.com > > Subject: RE: [Ipsec] Clarification on error notifications, please > > > > > > Yes and no. > > > > The sentence only applies to SAs that have completed enough > > initialization that cryptographic protection of messages is > > possible. So > > a failure response to an INIT message will not be > > authenticated but that > > message should not be ignored (though an implementation might wait a > > while for a success response in case the failure was sent by a third > > party in a DOS attempt). > > > > An AUTHENTICATION_FAILED notification, however, occurs after the first > > two messages and can be cryptographically protected even though the SA > > has not been authenticated. Such messages MUST NOT kill an SA. Only a > > cryptographically protected AUTHENTICATION_FAILED message should kill > > the SA. > > > > --Charlie Kaufman -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Sep 18 21:20:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHAL0-0003Er-T1; Sun, 18 Sep 2005 21:20:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHAKy-0003EP-Mr for ipsec@megatron.ietf.org; Sun, 18 Sep 2005 21:20:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07237 for ; Sun, 18 Sep 2005 21:20:51 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHAQV-0007Vs-8c for ipsec@ietf.org; Sun, 18 Sep 2005 21:26:35 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8J1KWIr003823; Sun, 18 Sep 2005 18:20:33 -0700 (PDT) Received: from NAEXBR01.na.qualcomm.com (naexbr01.qualcomm.com [172.30.32.40]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8J1KUoX001846; Sun, 18 Sep 2005 18:20:30 -0700 (PDT) Received: from NAEX05.na.qualcomm.com ([129.46.134.168]) by NAEXBR01.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.211); Sun, 18 Sep 2005 18:20:30 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages Date: Sun, 18 Sep 2005 18:20:17 -0700 Message-ID: <992BC8ECDE438E4B8F5789A0FCCC92AD090BA5@NAEX05.na.qualcomm.com> Thread-Topic: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages Thread-Index: AcW8s5mljeit3X06Tten0qZ/ozL8hAABLG0S References: <6.2.2.1.2.20050912115245.02fcbb80@qcmail1.qualcomm.com><1126556991.10962.5.camel@ghuang-lnx.juniper.net><00b401c5b7ea$f68d1ac0$6701a8c0@adithya><17193.18143.691032.354648@fireball.kivinen.iki.fi><6.2.2.1.2.20050915111812.02aa8488@qcmail1.qualcomm.com><17194.35494.329208.914504@fireball.kivinen.iki.fi><6.2.2.1.2.20050916082148.02932390@qcmail1.qualcomm.com> <17198.2580.148487.995517@fireball.kivinen.iki.fi> From: "Dondeti, Lakshminath" To: "Tero Kivinen" X-OriginalArrivalTime: 19 Sep 2005 01:20:30.0161 (UTC) FILETIME=[52F35410:01C5BCB8] X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Cc: ipsec@ietf.org, Mohan Parthasarathy 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="===============1769385988==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1769385988== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5BCB8.52A04B1B" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5BCB8.52A04B1B Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Thanks again Tero. best wishes, Lakshminath -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi] Sent: Sun 9/18/2005 5:45 PM To: Dondeti, Lakshminath Cc: ipsec@ietf.org; Mohan Parthasarathy Subject: Re: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages =20 Lakshminath Dondeti writes: > >I disagree. I think they MUST depend on same SPD rule that was used = to > >create the current selectors. Otherwise it is not rekey, as it could > >be possible that the traffic we are transferring wno on the SA would > >not fit to that SA anymore. >=20 > Tero, I think I can use some help here to understand the SPD rule. If = that=20 > SPD rule you refer to has changed dramatically (recall Case 2 above), = is it=20 > okay still to use rekey semantics? If it is still same SPD rule, I think it should use the rekey. If there is no overlapping traffic with the old and new SPD entries, then it should probably simply destroy the old SA and create new SA (as there is no traffic that could be moved from old SA to new SA). The rekey do have an idea behind it that you move old traffic from the SA to this newly created SA... --=20 kivinen@safenet-inc.com ------_=_NextPart_001_01C5BCB8.52A04B1B Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete = messages

Thanks again Tero.

best wishes,
Lakshminath


-----Original Message-----
From: Tero Kivinen [mailto:kivinen@iki.fi]
Sent: Sun 9/18/2005 5:45 PM
To: Dondeti, Lakshminath
Cc: ipsec@ietf.org; Mohan Parthasarathy
Subject: Re: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages

Lakshminath Dondeti writes:
> >I disagree. I think they MUST depend on same SPD rule that was = used to
> >create the current selectors. Otherwise it is not rekey, as it = could
> >be possible that the traffic we are transferring wno on the SA = would
> >not fit to that SA anymore.
>
> Tero, I think I can use some help here to understand the SPD = rule.  If that
> SPD rule you refer to has changed dramatically (recall Case 2 = above), is it
> okay still to use rekey semantics?

If it is still same SPD rule, I think it should use the rekey. If
there is no overlapping traffic with the old and new SPD entries, = then
it should probably simply destroy the old SA and create new SA (as
there is no traffic that could be moved from old SA to new SA).

The rekey do have an idea behind it that you move old traffic from = the
SA to this newly created SA...
--
kivinen@safenet-inc.com

------_=_NextPart_001_01C5BCB8.52A04B1B-- --===============1769385988== 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 --===============1769385988==-- From ipsec-bounces@ietf.org Mon Sep 19 03:37:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHGDQ-00060c-Jr; Mon, 19 Sep 2005 03:37:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHGDP-00060X-58 for ipsec@megatron.ietf.org; Mon, 19 Sep 2005 03:37:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03985 for ; Mon, 19 Sep 2005 03:37:23 -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.43) id 1EHGIv-0006MG-Sp for ipsec@ietf.org; Mon, 19 Sep 2005 03:43:11 -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 j8J7aACf014850; Mon, 19 Sep 2005 10:36:10 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Sep 2005 10:37:22 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Sep 2005 10:37:21 +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] Clarification on error notifications, please Date: Mon, 19 Sep 2005 10:37:20 +0300 Message-ID: Thread-Topic: [Ipsec] Clarification on error notifications, please Thread-Index: AcW8tLPlyE5OwdY9TZ2gEX4tzs2aEAANrgvg To: X-OriginalArrivalTime: 19 Sep 2005 07:37:21.0403 (UTC) FILETIME=[F84D0CB0:01C5BCEC] X-Spam-Score: 0.3 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 Tero Kivinen wrote: > I think he is refereing the AUTHENTICATION_FAILED > notifies. Thus getting AUTHENTICATION_FAILED notify message > before you have finished checking AUTH payloads MUST NOT kill > an SA, which means they are ignored, so there is really no > point of even seding them ever. No, I don't think this is right... if you receive a protected AUTHENTICATION_FAILED notify message during the IKE_AUTH exchange, you must kill the IKE_SA. Since the MAC of the message was correct, the recipient knows the notification was sent by the same party as the KE/nonce payloads in IKE_SA_INIT exchange. Most likely this was the "real" peer, who is just telling us that something went wrong in the authentication. And if it was an attacker, then the IKE_SA will fail anyway, since AUTH verification later will fail. Or in other words, there is no case where ignoring AUTHENTICATION_FAILED would provide any kind of benefit:=20 if we really do have a man-in-the-middle who can insert a=20 fake AUTHENTICATION_FAILED notification, then it automatically=20 means that AUTH payload verification will also fail. (Unless the attacker can really do MitM against the IKE_SA without causing AUTH verification to fail, but then we have much, much worse problems than DoS...) Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 19 08:26:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHKis-0003It-7N; Mon, 19 Sep 2005 08:26:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHKiq-0003Hs-9w for ipsec@megatron.ietf.org; Mon, 19 Sep 2005 08:26:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16706 for ; Mon, 19 Sep 2005 08:26:10 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHKoO-0005Eh-8F for ipsec@ietf.org; Mon, 19 Sep 2005 08:32:00 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8JCPSr23278 for ; Mon, 19 Sep 2005 14:25:28 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8JCPSgD064059 for ; Mon, 19 Sep 2005 14:25:28 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509191225.j8JCPSgD064059@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipsec@ietf.org Date: Mon, 19 Sep 2005 14:25:28 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Ipsec] forward to transport mode 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'd like to know the common opinion about this problem: Alice and Bob have a transport mode IPsec SA between them, Alice is a router and a bad guy sends to Alice a packet with Alice's address as the source and Bob's address at the destination. Alice forwards the packet to Bob but it matches the SPD entry and is protected by the IPsec SA. I believe this must not happen because: a- only tunnel mode SAs may be applied to forwarded traffic b- implementations must explicitely avoid the application of transport mode SAs to forwarded traffic (same thing than a with a stronger wording). What do you believe and do you know wrong implementations? Regards Francis.Dupont@enst-bretagne.fr PS: my arguments are the definition of the transport mode (explicitely end-to-end) and the data origin authentication function (clearly not provided in the example). _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 19 09:17:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHLWj-0000Tp-5M; Mon, 19 Sep 2005 09:17:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHLWh-0000Tb-0L for ipsec@megatron.ietf.org; Mon, 19 Sep 2005 09:17:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20328 for ; Mon, 19 Sep 2005 09:17:41 -0400 (EDT) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHLcG-0006vs-Hq for ipsec@ietf.org; Mon, 19 Sep 2005 09:23:32 -0400 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.4/8.13.4/Debian-3) with ESMTP id j8JDHLaN028633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Sep 2005 16:17:21 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.4/8.13.4/Submit) id j8JDHLba028630; Mon, 19 Sep 2005 16:17:21 +0300 Date: Mon, 19 Sep 2005 16:17:21 +0300 Message-Id: <200509191317.j8JDHLba028630@burp.tkv.asdf.org> From: Markku Savela To: Francis.Dupont@enst-bretagne.fr In-reply-to: <200509191225.j8JCPSgD064059@givry.rennes.enst-bretagne.fr> (message from Francis Dupont on Mon, 19 Sep 2005 14:25:28 +0200) Subject: Re: [Ipsec] forward to transport mode References: <200509191225.j8JCPSgD064059@givry.rennes.enst-bretagne.fr> X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 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 > From: Francis Dupont > > I'd like to know the common opinion about this problem: > Alice and Bob have a transport mode IPsec SA between them, > Alice is a router and a bad guy sends to Alice a packet with > Alice's address as the source and Bob's address at the destination. > Alice forwards the packet to Bob but it matches the SPD entry and > is protected by the IPsec SA. One might argue - if incoming packet has src address of the node self, shouldn't the packet be dropped as faked (or looped), even without IPsec? - and, if the router code doesn't do this, one could have an IPsec policy that drops incoming packets with src=Alice. > I believe this must not happen because: > a- only tunnel mode SAs may be applied to forwarded traffic > b- implementations must explicitely avoid the application of > transport mode SAs to forwarded traffic (same thing than a > with a stronger wording). Thus, fixing the "problem" is configuration and policy issue. Not something that IPsec specification needs to get involved. However, I see that this may be a pitfall for some, so some warning about this in some document could be considered. Note, that the "problem" happens only if forwarded packet does have src=some Alice's address. Anything else, and the transport mode really does not work, as the src address doesn't match any SA. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 19 10:15:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHMQQ-0004OZ-1G; Mon, 19 Sep 2005 10:15:18 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHMQJ-0004Nc-Uu for ipsec@megatron.ietf.org; Mon, 19 Sep 2005 10:15:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA23307 for ; Mon, 19 Sep 2005 10:15:09 -0400 (EDT) Received: from imr1.ericy.com ([198.24.6.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHMVw-0008D0-CD for ipsec@ietf.org; Mon, 19 Sep 2005 10:21:01 -0400 Received: from eamrcnt760.exu.ericsson.se (eamrcnt760.exu.ericsson.se [138.85.133.38]) by imr1.ericy.com (8.13.1/8.13.1) with ESMTP id j8JEEclT017128 for ; Mon, 19 Sep 2005 09:14:38 -0500 Received: by eamrcnt760 with Internet Mail Service (5.5.2657.72) id ; Mon, 19 Sep 2005 09:14:38 -0500 Message-ID: From: "James Comen (NC/TNT)" To: "'ipsec@ietf.org'" Date: Mon, 19 Sep 2005 09:14:15 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Subject: [Ipsec] Simultaneous initial keying on an IPsec SA in 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: , Content-Type: multipart/mixed; boundary="===============1808646587==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --===============1808646587== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5BD24.6A5107F4" This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C5BD24.6A5107F4 Content-Type: text/plain; charset="iso-8859-1" I have seen discussions addressing simultaneous RE-keying of IPsec SAs in IKEv1. The issue can be addressed by adjusting the rekey timeout based on whether a peer is initiator or responder. However, I have not seen simultaneous keying addressed as part of the initial keying. In a normal situation this should not occur. In a normal situation, one side attempts to send a packet which requires IPsec protection. Based on that, normal keying occurs. Consider a testing scenario in which a traffic generator is connected to either peer (and the peers are connected directly or indirectly). When the traffic generator starts, it sends packets to both peers (destined for the 'other' peer) causing each peer to attempt to create IKE/IPsec SAs. In this case, each peer is acting as both initiator and responder. Given this, I assume the best that could happen would be duplicate SAs. I assume the worst that could happen woud be the following: Each peer, acting as initiator, allocates an SPI value for the for the incoming SA and then initiates a P2 exchange. Each P2 exchange stalls later when each peer receives the first p2 message and, then, acting as responder, tries to allocate an incoming SPI. It will fail because a SPI value has already been allocated for the incoming SA. Is this a problem? Has it been addressed or is it local to my implementation? Thanks, Jim ------_=_NextPart_001_01C5BD24.6A5107F4 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Simultaneous initial keying on an IPsec SA in IKEv1

I have seen discussions addressing = simultaneous RE-keying of IPsec SAs in IKEv1.  The issue can be = addressed by adjusting the rekey timeout based on whether a peer is = initiator or responder.

However, I have not seen simultaneous = keying addressed as part of the initial keying.  In a normal = situation this should not occur. In a normal situation, one side = attempts to send a packet which requires IPsec protection.  Based = on that, normal keying occurs.

Consider a testing scenario in which a = traffic generator is connected to either peer (and the peers are = connected directly or indirectly).  When the traffic generator = starts, it sends packets to both peers (destined for the 'other' peer) = causing each peer to attempt to create IKE/IPsec SAs.  In this = case, each peer is acting as both initiator and responder.  =


Given this, I assume the best that = could happen would be duplicate SAs.

I assume the worst that could happen = woud be the following:
Each peer, acting as initiator, = allocates an SPI value for the for the incoming SA and then initiates a = P2 exchange.  Each P2 exchange stalls later when each peer = receives the first p2 message and, then, acting as responder, tries to = allocate an incoming SPI. It will fail because a SPI value has already = been allocated for the incoming SA.

Is this a problem?
Has it been addressed or is it local = to my implementation?

Thanks,
Jim

------_=_NextPart_001_01C5BD24.6A5107F4-- --===============1808646587== 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 --===============1808646587==-- From ipsec-bounces@ietf.org Mon Sep 19 10:24:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHMZ9-0006kx-0W; Mon, 19 Sep 2005 10:24:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHMZ7-0006kg-HU for ipsec@megatron.ietf.org; Mon, 19 Sep 2005 10:24:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24175 for ; Mon, 19 Sep 2005 10:24:15 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHMej-0008Tt-S1 for ipsec@ietf.org; Mon, 19 Sep 2005 10:30:07 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8JENv832426; Mon, 19 Sep 2005 16:23:57 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8JENv83064780; Mon, 19 Sep 2005 16:23:57 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509191423.j8JENv83064780@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Markku Savela Subject: Re: [Ipsec] forward to transport mode In-reply-to: Your message of Mon, 19 Sep 2005 16:17:21 +0300. <200509191317.j8JDHLba028630@burp.tkv.asdf.org> Date: Mon, 19 Sep 2005 16:23:57 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 In your previous mail you wrote: > From: Francis Dupont > > I'd like to know the common opinion about this problem: > Alice and Bob have a transport mode IPsec SA between them, > Alice is a router and a bad guy sends to Alice a packet with > Alice's address as the source and Bob's address at the destination. > Alice forwards the packet to Bob but it matches the SPD entry and > is protected by the IPsec SA. One might argue - if incoming packet has src address of the node self, shouldn't the packet be dropped as faked (or looped), even without IPsec? - and, if the router code doesn't do this, one could have an IPsec policy that drops incoming packets with src=Alice. => both are variations about a standard anti-spoofing rule. One can assume there is no such anti-spoofing on Alice... > I believe this must not happen because: > a- only tunnel mode SAs may be applied to forwarded traffic > b- implementations must explicitely avoid the application of > transport mode SAs to forwarded traffic (same thing than a > with a stronger wording). Thus, fixing the "problem" is configuration and policy issue. Not something that IPsec specification needs to get involved. => I am not sure: IPsec has inbound and outbound, not forward direction. (at least in formal description). However, I see that this may be a pitfall for some, so some warning about this in some document could be considered. => one of my concerns is the data origin authentication is fooled if the issue is not solved. Note, that the "problem" happens only if forwarded packet does have src=some Alice's address. Anything else, and the transport mode really does not work, as the src address doesn't match any SA. => this doesn't really fix the issue: can a forwarded packet be given to a transport mode SA? The RFC 2409 says the default policy is to refuse... Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 19 10:48:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHMwz-0004E0-S6; Mon, 19 Sep 2005 10:48:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHMwx-0004Cn-W6 for ipsec@megatron.ietf.org; Mon, 19 Sep 2005 10:48:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25645 for ; Mon, 19 Sep 2005 10:48:53 -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.43) id 1EHN2a-0000ik-Ew for ipsec@ietf.org; Mon, 19 Sep 2005 10:54:45 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8JEmlVZ024019; Mon, 19 Sep 2005 17:48:50 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Sep 2005 17:48:14 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 19 Sep 2005 17:46:38 +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] Simultaneous initial keying on an IPsec SA in IKEv1 Date: Mon, 19 Sep 2005 17:46:37 +0300 Message-ID: Thread-Topic: [Ipsec] Simultaneous initial keying on an IPsec SA in IKEv1 Thread-Index: AcW9JTUMYykxHG0/StqvocRm2B2HdgAATvpA To: , X-OriginalArrivalTime: 19 Sep 2005 14:46:38.0449 (UTC) FILETIME=[F0B25E10:01C5BD28] X-Spam-Score: 0.3 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 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 James Comen (NC/TNT) wrote: > I assume the worst that could happen woud be the following:=20 > > Each peer, acting as initiator, allocates an SPI value for the for > the incoming SA and then initiates a P2 exchange. Each P2 exchange > stalls later when each peer receives the first p2 message and, then, > acting as responder, tries to allocate an incoming SPI. It will fail > because a SPI value has already been allocated for the incoming SA. Why would allocating an incoming SPI fail in this case?=20 (Or does your implementation support only a single incoming IPsec SA? But then it probably wouldn't be compliant with 2401bis...) Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 19 11:49:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHNtY-0001Nq-Iz; Mon, 19 Sep 2005 11:49:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHNtW-0001Nl-6i for ipsec@megatron.ietf.org; Mon, 19 Sep 2005 11:49:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04097 for ; Mon, 19 Sep 2005 11:49:23 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHNz7-0004D3-D2 for ipsec@ietf.org; Mon, 19 Sep 2005 11:55:16 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8JFn4M07461; Mon, 19 Sep 2005 17:49:04 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8JFn43e065535; Mon, 19 Sep 2005 17:49:04 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509191549.j8JFn43e065535@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Dan McDonald Subject: Re: [Ipsec] forward to transport mode In-reply-to: Your message of Mon, 19 Sep 2005 11:38:31 EDT. <20050919153831.GB568@everywhere.SFBay.Sun.COM> Date: Mon, 19 Sep 2005 17:49:04 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c 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 In your previous mail you wrote: Especially in transport mode, IPsec is applied only to packets that *originate* from a node. => so you agree this is an essential property of the transport mode. Your scenario as describe is quite broken - any implementations that behave in such a manner are toxic, and should be smashed into little bits. => half bits (harder to repair :-)... Thanks Francis.Dupont@enst-bretagne.fr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 19 13:37:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHPaK-0005Y2-RI; Mon, 19 Sep 2005 13:37:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHPaI-0005Xx-N3 for ipsec@megatron.ietf.org; Mon, 19 Sep 2005 13:37:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09489 for ; Mon, 19 Sep 2005 13:37:41 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHPfw-0006tD-1K for ipsec@ietf.org; Mon, 19 Sep 2005 13:43:34 -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 j8JHbCDd016599; Mon, 19 Sep 2005 13:37:12 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <200509191549.j8JFn43e065535@givry.rennes.enst-bretagne.fr> References: <200509191549.j8JFn43e065535@givry.rennes.enst-bretagne.fr> Date: Mon, 19 Sep 2005 13:35:07 -0400 To: Francis Dupont From: Stephen Kent Subject: Re: [Ipsec] forward to transport mode 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: cf4fa59384e76e63313391b70cd0dd25 Cc: ipsec@ietf.org, Dan McDonald 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 Francis, I agree that the example you cite describes behavior that we do not want to take place. As you noted, transport mode is to be applied to packets that originate from a node, as far as the packet's IP header indicates. If the packet was forwarded, as in an overlay net, the there has to be an inner IP header and the receiver needs to be aware that this sort of tunneling, external to Ipsec, is taking place. When folks say that they don't see tunnel and transport modes as different enough to need to be labelled in the SAD, I think they are saying that they do not see a need to signal to a receiver this sort of fundamental distinction. I disagree and your example shows why this can be a problem. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 19 13: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 1EHPcT-0005zu-FE; Mon, 19 Sep 2005 13: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 1EHPcR-0005zC-A4 for ipsec@megatron.ietf.org; Mon, 19 Sep 2005 13:39:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09605 for ; Mon, 19 Sep 2005 13:39:53 -0400 (EDT) From: jcervantes@reefpoint.com Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHPi5-0006wV-Kr for ipsec@ietf.org; Mon, 19 Sep 2005 13:45:46 -0400 Received: by email.quarrytech.com with Internet Mail Service (5.5.2653.19) id ; Mon, 19 Sep 2005 13:36:07 -0400 Message-ID: <496A8683261CD211BF6C0008C733261A0688AE25@email.quarrytech.com> To: ipsec@ietf.org Subject: RE: [Ipsec] Clarification on error notifications, please Date: Mon, 19 Sep 2005 13:36:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 we have obtained privacy and integrity protection, but not yet authenticated our peer, we can break down the analysis into precisely two cases: a. we are talking with the intended peer b. we are not talking with the intended peer (includes all man-in-the-middle scenarios) In case a. it is safe to respond to an AUTHENTICATION_FAILED notification by tearing down our local state because we trust the message was generated by the intended peer. In case b it is safe to respond to an AUTHENTICATION_FAILED notification by tearing down our local state because we never want to interact with an incorrect peer. We cannot know whether we are dealing with case a or b, but since tearing down local state is safe and desirable in both cases, I think it is a defensible approach. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 19 13:49:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHPm8-0000FZ-5L; Mon, 19 Sep 2005 13:49:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHPm6-0000F4-9l for ipsec@megatron.ietf.org; Mon, 19 Sep 2005 13:49:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10162 for ; Mon, 19 Sep 2005 13:49:52 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHPrl-0007IH-KC for ipsec@ietf.org; Mon, 19 Sep 2005 13:55:46 -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 j8JHniDd017324; Mon, 19 Sep 2005 13:49:45 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.2.1.2.20050915150459.03145d70@qcmail1.qualcomm.com> References: <6.2.2.1.2.20050912115245.02fcbb80@qcmail1.qualcomm.com> <1126556991.10962.5.camel@ghuang-lnx.juniper.net> <00b401c5b7ea$f68d1ac0$6701a8c0@adithya> <17193.18143.691032.354648@fireball.kivinen.iki.fi> <6.2.2.1.2.20050915111812.02aa8488@qcmail1.qualcomm.com> <1126809149.14802.406.camel@thunk> <6.2.2.1.2.20050915142919.02f5ba08@qcmail1.qualcomm.com> <1126820778.14802.439.camel@thunk> <6.2.2.1.2.20050915150459.03145d70@qcmail1.qualcomm.com> Date: Mon, 19 Sep 2005 13:49:41 -0400 To: Lakshminath Dondeti From: Stephen Kent Subject: Re: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages 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.9 (/) X-Scan-Signature: a7d2e37451f7f22841e3b6f40c67db0f Cc: ipsec@ietf.org, Bill Sommerfeld , Tero Kivinen , Mohan Parthasarathy 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="===============1034416691==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1034416691== Content-Type: multipart/alternative; boundary="============_-1084970312==_ma============" --============_-1084970312==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 3:16 PM -0700 9/15/05, Lakshminath Dondeti wrote: >At 02:46 PM 9/15/2005, Bill Sommerfeld wrote: >>On Thu, 2005-09-15 at 17:30, Lakshminath Dondeti wrote: >>> If two parties know explicitly that they definitely don't want more than >>> one IPsec SA between them. >> >>2401bis and IKEv2 require support for multiple IPsec SA's. >> >> - Bill > >I just checked the compliance requirements section (Sec 4) of >ikev2-17, and the following are under " >There are a series > of optional features that can easily be ignored by a particular > implementation if it does not support that feature. Those features > include: > >... > > > Ability to establish multiple ESP and/or AH SAs within a single > IKE_SA. > > Ability to rekey SAs. >... >" >I would like to rekey an SA, but don't care about supporting multiple SAs. In section 4.1 of 2401bis (page 13) the text says: To permit this, the IPsec implementation MUST permit establishment and maintenance of multiple SAs between a given sender and receiver, with the same selectors. This is unambiguous, so if you don't support multiple SAs, you will be non-compliant. Steve --============_-1084970312==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete message
At 3:16 PM -0700 9/15/05, Lakshminath Dondeti wrote:
At 02:46 PM 9/15/2005, Bill Sommerfeld wrote:
On Thu, 2005-09-15 at 17:30, Lakshminath Dondeti wrote:
> If two parties know explicitly that they definitely don't want more than
> one IPsec SA between them.

2401bis and IKEv2 require support for multiple IPsec SA's.

                                                - Bill

I just checked the compliance requirements section (Sec 4) of ikev2-17, and the following are under "
There are a series
   of optional features that can easily be ignored by a particular
   implementation if it does not support that feature. Those features
   include:

...


      Ability to establish multiple ESP and/or AH SAs within a single
      IKE_SA.

      Ability to rekey SAs.
...
"
I would like to rekey an SA, but don't care about supporting multiple SAs.

In section 4.1 of 2401bis (page 13) the text says: To permit this, the
   IPsec implementation MUST permit establishment and maintenance of
   multiple SAs between a given sender and receiver, with the same
   selectors.

This is unambiguous, so if you don't support multiple SAs, you will be non-compliant.

Steve
--============_-1084970312==_ma============-- --===============1034416691== 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 --===============1034416691==-- From ipsec-bounces@ietf.org Mon Sep 19 14:17:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHQD3-0007mB-8X; Mon, 19 Sep 2005 14:17:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHQD1-0007m6-Og for ipsec@megatron.ietf.org; Mon, 19 Sep 2005 14:17:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA11810 for ; Mon, 19 Sep 2005 14:17:41 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHQIg-00089S-1W for ipsec@ietf.org; Mon, 19 Sep 2005 14:23:35 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8JIH8Ir001446; Mon, 19 Sep 2005 11:17:09 -0700 (PDT) Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.100]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8JIH4S4012894 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Sep 2005 11:17:06 -0700 (PDT) Message-Id: <6.2.2.1.2.20050919105827.05c5e3a8@qcmail1.qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.2.1 Date: Mon, 19 Sep 2005 11:16:59 -0700 To: Stephen Kent From: Lakshminath Dondeti Subject: Re: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages In-Reply-To: References: <6.2.2.1.2.20050912115245.02fcbb80@qcmail1.qualcomm.com> <1126556991.10962.5.camel@ghuang-lnx.juniper.net> <00b401c5b7ea$f68d1ac0$6701a8c0@adithya> <17193.18143.691032.354648@fireball.kivinen.iki.fi> <6.2.2.1.2.20050915111812.02aa8488@qcmail1.qualcomm.com> <1126809149.14802.406.camel@thunk> <6.2.2.1.2.20050915142919.02f5ba08@qcmail1.qualcomm.com> <1126820778.14802.439.camel@thunk> <6.2.2.1.2.20050915150459.03145d70@qcmail1.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Cc: ipsec@ietf.org, Bill Sommerfeld , Tero Kivinen , Mohan Parthasarathy 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 10:49 AM 9/19/2005, Stephen Kent wrote: >At 3:16 PM -0700 9/15/05, Lakshminath Dondeti wrote: >>At 02:46 PM 9/15/2005, Bill Sommerfeld wrote: >>>On Thu, 2005-09-15 at 17:30, Lakshminath Dondeti wrote: >>> > If two parties know explicitly that they definitely don't want more than >>> > one IPsec SA between them. >>> >>>2401bis and IKEv2 require support for multiple IPsec SA's. >>> >>> - Bill >> >>I just checked the compliance requirements section (Sec 4) of ikev2-17, >>and the following are under " >>There are a series >> of optional features that can easily be ignored by a particular >> implementation if it does not support that feature. Those features >> include: >> >>... >> >> >> Ability to establish multiple ESP and/or AH SAs within a single >> IKE_SA. >> >> Ability to rekey SAs. >>... >>" >>I would like to rekey an SA, but don't care about supporting multiple SAs. > >In section 4.1 of 2401bis (page 13) the text says: To permit this, the > IPsec implementation MUST permit establishment and maintenance of > multiple SAs between a given sender and receiver, with the same > selectors. > >This is unambiguous, so if you don't support multiple SAs, you will be >non-compliant. > >Steve Thanks for the reference Steve. It appears then the compliance requirements of IKEv2 and 2401bis are at odds with each other. The ikev2-17 draft does say that a minimal implementation can support only the base exchange to establish an IPsec SA -- no scope for multiple SAs there. I can see an IPsec implementation that supports multiple IPsec SAs -- one manual (or via another key management protocol) and another supported by IKEv2 (but don't want to really go there in this thread). Do you think the ikev2-17's compliance requirements need to be rewritten? You seem to have followed this thread, so let me pose the original question that led us here: In IKEv2 CREATE_CHILD_SA exchange, the N payload is supposed to carry the SPI of the IPsec SA being rekeyed. I was wondering if that allows us to "replace" the old IPsec SA with the new one (with the understanding that some traffic encapsulated with the old SA might be dropped, if sent after rekeying -- and in some cases that's ok since both sides have decided to stop using the old SA). The alternative of course if to create a parallel SA and delete the old one, which could have been done without including the N payload in the rekey message. The N payload, as has been pointed out in this discussion, only serves the purpose of say, book keeping (e.g., statistics, optimization of rekeying). Many thanks for your time. regards, Lakshminath _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 19 16:27:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHSER-0006xm-4z; Mon, 19 Sep 2005 16:27:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHSEP-0006xb-Gy for ipsec@megatron.ietf.org; Mon, 19 Sep 2005 16:27:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25955 for ; Mon, 19 Sep 2005 16:27:14 -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.43) id 1EHSK4-0005Jd-Tv for ipsec@ietf.org; Mon, 19 Sep 2005 16:33:10 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j8JKPxKS023065 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 19 Sep 2005 23:25:59 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j8JKPwq9025528; Mon, 19 Sep 2005 23:25:58 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17199.7894.650029.750751@fireball.kivinen.iki.fi> Date: Mon, 19 Sep 2005 23:25:58 +0300 From: Tero Kivinen To: jcervantes@reefpoint.com Subject: RE: [Ipsec] Clarification on error notifications, please In-Reply-To: <496A8683261CD211BF6C0008C733261A0688AE25@email.quarrytech.com> References: <496A8683261CD211BF6C0008C733261A0688AE25@email.quarrytech.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 2 min X-Total-Time: 2 min X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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 jcervantes@reefpoint.com writes: > Once we have obtained privacy and integrity protection, but not yet > authenticated our peer, we can break down the analysis into precisely two > cases: > > a. we are talking with the intended peer > > b. we are not talking with the intended peer (includes all man-in-the-middle > scenarios) c. We are talking to the intended peer, but attacker has modified the cipher/prf/hash etc algorithms proposed by the initiator. > In case a. it is safe to respond to an AUTHENTICATION_FAILED notification by > tearing down our local state because we trust the message was generated by > the intended peer. > > In case b it is safe to respond to an AUTHENTICATION_FAILED notification by > tearing down our local state because we never want to interact with an > incorrect peer. And do we want to tear down the SA as attacker modified the cipher to be null in IKE SA level, and we are now sending all that error information in clear? Note, that we haven't yet verified that the SA payload cipher/hash/prf etc exchange is done properly without someone attacking against those. > We cannot know whether we are dealing with case a or b, but since tearing > down local state is safe and desirable in both cases, I think it is a > defensible approach. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 19 17:00:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHSkV-00086H-FN; Mon, 19 Sep 2005 17:00:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHSkT-00085q-Lo for ipsec@megatron.ietf.org; Mon, 19 Sep 2005 17:00:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29073 for ; Mon, 19 Sep 2005 17:00:22 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHSq8-0006Ax-Mf for ipsec@ietf.org; Mon, 19 Sep 2005 17:06:19 -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 j8JL0BDd028352; Mon, 19 Sep 2005 17:00:11 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.2.1.2.20050919105827.05c5e3a8@qcmail1.qualcomm.com> References: <6.2.2.1.2.20050912115245.02fcbb80@qcmail1.qualcomm.com> <1126556991.10962.5.camel@ghuang-lnx.juniper.net> <00b401c5b7ea$f68d1ac0$6701a8c0@adithya> <17193.18143.691032.354648@fireball.kivinen.iki.fi> <6.2.2.1.2.20050915111812.02aa8488@qcmail1.qualcomm.com> <1126809149.14802.406.camel@thunk> <6.2.2.1.2.20050915142919.02f5ba08@qcmail1.qualcomm.com> <1126820778.14802.439.camel@thunk> <6.2.2.1.2.20050915150459.03145d70@qcmail1.qualcomm.com> <6.2.2.1.2.20050919105827.05c5e3a8@qcmail1.qualcomm.com> Date: Mon, 19 Sep 2005 15:39:36 -0400 To: Lakshminath Dondeti From: Stephen Kent Subject: Re: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages 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: e1e48a527f609d1be2bc8d8a70eb76cb Cc: ipsec@ietf.org, Bill Sommerfeld , Tero Kivinen , Mohan Parthasarathy 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 11:16 AM -0700 9/19/05, Lakshminath Dondeti wrote: >>... > >Thanks for the reference Steve. It appears then the compliance >requirements of IKEv2 and 2401bis are at odds with each other. The >ikev2-17 draft does say that a minimal implementation can support >only the base exchange to establish an IPsec SA -- no scope for >multiple SAs there. I can see an IPsec implementation that supports >multiple IPsec SAs -- one manual (or via another key management >protocol) and another supported by IKEv2 (but don't want to really >go there in this thread). Do you think the ikev2-17's compliance >requirements need to be rewritten? A clarification is is order, at a minimum. It should be included in the in-progress IKEv2 c;larifications document. I didn't quote the rest of the IPsec text, but it provided the rationale for this requirement, and it is something that the WG agreed upon, e.g., to support different SAs for QoS purposes. >You seem to have followed this thread, so let me pose the original >question that led us here: > >In IKEv2 CREATE_CHILD_SA exchange, the N payload is supposed to >carry the SPI of the IPsec SA being rekeyed. I was wondering if >that allows us to "replace" the old IPsec SA with the new one (with >the understanding that some traffic encapsulated with the old SA >might be dropped, if sent after rekeying -- and in some cases that's >ok since both sides have decided to stop using the old SA). The >alternative of course if to create a parallel SA and delete the old >one, which could have been done without including the N payload in >the rekey message. The N payload, as has been pointed out in this >discussion, only serves the purpose of say, book keeping (e.g., >statistics, optimization of rekeying). Rekeying ultimately does replace an old SA (pair) with a new SA (pair). But, I think the intent is to create a new SA and have both in place simultaneously, to facilitate the transition and minimize packet loss during rekey. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 19 17:04:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHSoS-0000mt-7E; Mon, 19 Sep 2005 17:04:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHSoP-0000jw-Nd for ipsec@megatron.ietf.org; Mon, 19 Sep 2005 17:04:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29400 for ; Mon, 19 Sep 2005 17:04:27 -0400 (EDT) From: jcervantes@reefpoint.com Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHSu6-0006It-T7 for ipsec@ietf.org; Mon, 19 Sep 2005 17:10:23 -0400 Received: by email.quarrytech.com with Internet Mail Service (5.5.2653.19) id ; Mon, 19 Sep 2005 17:00:43 -0400 Message-ID: <496A8683261CD211BF6C0008C733261A0688AE26@email.quarrytech.com> To: kivinen@iki.fi Subject: RE: [Ipsec] Clarification on error notifications, please Date: Mon, 19 Sep 2005 17:00:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.3 (/) X-Scan-Signature: 0a7aa2e6e558383d84476dc338324fab 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 My intent in defining case a. is to describe the situation where there is no modification of messages by any third party (i.e., no man in the middle) and we are in fact talking with the intended peer. Case b. is the complement - literally everything else. Your case c. is therefore a sub-case of case b. and everything I said before still applies. In your case c. there is an attacker modifying messages and the desirable outcome is to abandon the negotiation. Are you suggesting there is something better to be done in this case? Null encryption is not legal so I don't understand your point about sending an error notification in the clear. Jim -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi] Sent: Monday, September 19, 2005 4:26 PM To: jcervantes@reefpoint.com Cc: ipsec@ietf.org Subject: RE: [Ipsec] Clarification on error notifications, please jcervantes@reefpoint.com writes: > Once we have obtained privacy and integrity protection, but not yet > authenticated our peer, we can break down the analysis into precisely two > cases: > > a. we are talking with the intended peer > > b. we are not talking with the intended peer (includes all man-in-the-middle > scenarios) c. We are talking to the intended peer, but attacker has modified the cipher/prf/hash etc algorithms proposed by the initiator. > In case a. it is safe to respond to an AUTHENTICATION_FAILED notification by > tearing down our local state because we trust the message was generated by > the intended peer. > > In case b it is safe to respond to an AUTHENTICATION_FAILED notification by > tearing down our local state because we never want to interact with an > incorrect peer. And do we want to tear down the SA as attacker modified the cipher to be null in IKE SA level, and we are now sending all that error information in clear? Note, that we haven't yet verified that the SA payload cipher/hash/prf etc exchange is done properly without someone attacking against those. > We cannot know whether we are dealing with case a or b, but since tearing > down local state is safe and desirable in both cases, I think it is a > defensible approach. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 19 17:07:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHSra-0002Az-Jw; Mon, 19 Sep 2005 17:07:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHSrZ-0002Ak-3I for ipsec@megatron.ietf.org; Mon, 19 Sep 2005 17:07:45 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA29628 for ; Mon, 19 Sep 2005 17:07:42 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHSxF-0006Pk-0l for ipsec@ietf.org; Mon, 19 Sep 2005 17:13:38 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8JL7KIr024568; Mon, 19 Sep 2005 14:07:21 -0700 (PDT) Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.100]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8JL7IS4025644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Sep 2005 14:07:18 -0700 (PDT) Message-Id: <6.2.2.1.2.20050919140255.062b38d8@qcmail1.qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.2.1 Date: Mon, 19 Sep 2005 14:07:17 -0700 To: Stephen Kent From: Lakshminath Dondeti Subject: Re: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages In-Reply-To: References: <6.2.2.1.2.20050912115245.02fcbb80@qcmail1.qualcomm.com> <1126556991.10962.5.camel@ghuang-lnx.juniper.net> <00b401c5b7ea$f68d1ac0$6701a8c0@adithya> <17193.18143.691032.354648@fireball.kivinen.iki.fi> <6.2.2.1.2.20050915111812.02aa8488@qcmail1.qualcomm.com> <1126809149.14802.406.camel@thunk> <6.2.2.1.2.20050915142919.02f5ba08@qcmail1.qualcomm.com> <1126820778.14802.439.camel@thunk> <6.2.2.1.2.20050915150459.03145d70@qcmail1.qualcomm.com> <6.2.2.1.2.20050919105827.05c5e3a8@qcmail1.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Cc: ipsec@ietf.org, Bill Sommerfeld , Tero Kivinen , Mohan Parthasarathy 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 12:39 PM 9/19/2005, Stephen Kent wrote: >At 11:16 AM -0700 9/19/05, Lakshminath Dondeti wrote: >>>... >> >>Thanks for the reference Steve. It appears then the compliance >>requirements of IKEv2 and 2401bis are at odds with each other. The >>ikev2-17 draft does say that a minimal implementation can support only >>the base exchange to establish an IPsec SA -- no scope for multiple SAs >>there. I can see an IPsec implementation that supports multiple IPsec >>SAs -- one manual (or via another key management protocol) and another >>supported by IKEv2 (but don't want to really go there in this >>thread). Do you think the ikev2-17's compliance requirements need to be >>rewritten? > >A clarification is is order, at a minimum. It should be included in the >in-progress IKEv2 c;larifications document. > >I didn't quote the rest of the IPsec text, but it provided the rationale >for this requirement, and it is something that the WG agreed upon, e.g., >to support different SAs for QoS purposes. Yes indeed. However, my understanding was that QoS considerations do not apply to all implementations. In any event, a clarification one way or another should happen in some form -- ikev2-clarifications would be a start. But, the ikev2 draft can also be edited during the RFC Ed processes to note that supporting multiple simultaneous child SAs with the same TSs is not optional. >>You seem to have followed this thread, so let me pose the original >>question that led us here: >> >>In IKEv2 CREATE_CHILD_SA exchange, the N payload is supposed to carry the >>SPI of the IPsec SA being rekeyed. I was wondering if that allows us to >>"replace" the old IPsec SA with the new one (with the understanding that >>some traffic encapsulated with the old SA might be dropped, if sent after >>rekeying -- and in some cases that's ok since both sides have decided to >>stop using the old SA). The alternative of course if to create a >>parallel SA and delete the old one, which could have been done without >>including the N payload in the rekey message. The N payload, as has been >>pointed out in this discussion, only serves the purpose of say, book >>keeping (e.g., statistics, optimization of rekeying). > >Rekeying ultimately does replace an old SA (pair) with a new SA (pair). >But, I think the intent is to create a new SA and have both in place >simultaneously, to facilitate the transition and minimize packet loss >during rekey. ok, thanks for the clarification Steve. best regards, Lakshminath >Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 19 17:56:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHTdB-0007Hn-4q; Mon, 19 Sep 2005 17:56:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHTd8-0007Hi-Nf for ipsec@megatron.ietf.org; Mon, 19 Sep 2005 17:56:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01165 for ; Mon, 19 Sep 2005 17:56:51 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHTip-0007Kl-4q for ipsec@ietf.org; Mon, 19 Sep 2005 18:02:48 -0400 Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j8JLup5E056571 for ; Mon, 19 Sep 2005 14:56:51 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.2.1.2.20050919140255.062b38d8@qcmail1.qualcomm.com> References: <6.2.2.1.2.20050912115245.02fcbb80@qcmail1.qualcomm.com> <1126556991.10962.5.camel@ghuang-lnx.juniper.net> <00b401c5b7ea$f68d1ac0$6701a8c0@adithya> <17193.18143.691032.354648@fireball.kivinen.iki.fi> <6.2.2.1.2.20050915111812.02aa8488@qcmail1.qualcomm.com> <1126809149.14802.406.camel@thunk> <6.2.2.1.2.20050915142919.02f5ba08@qcmail1.qualcomm.com> <1126820778.14802.439.camel@thunk> <6.2.2.1.2.20050915150459.03145d70@qcmail1.qualcomm.com> <6.2.2.1.2.20050919105827.05c5e3a8@qcmail1.qualcomm.com> <6.2.2.1.2.20050919140255.062b38d8@qcmail1.qualcomm.com> Date: Mon, 19 Sep 2005 14:56:52 -0700 To: IPsec WG From: Paul Hoffman Subject: Re: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 2:07 PM -0700 9/19/05, Lakshminath Dondeti wrote: >Yes indeed. However, my understanding was that QoS considerations >do not apply to all implementations. In any event, a clarification >one way or another should happen in some form -- >ikev2-clarifications would be a start. That could happen if this group agrees. But... > But, the ikev2 draft can also be edited during the RFC Ed >processes to note that supporting multiple simultaneous child SAs >with the same TSs is not optional. I don't believe it can. This is a serious technical change, which would mean that it would have to go back to the IESG and the WG (which no longer exists). From what I have heard from a huge number of implementers, they want IKEv2 as an RFC as soon as possible. Such a delay would probably be unacceptable. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 19 18:12:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHTse-0004G2-4W; Mon, 19 Sep 2005 18:12:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHTsb-0004Fj-Of for ipsec@megatron.ietf.org; Mon, 19 Sep 2005 18:12:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03194 for ; Mon, 19 Sep 2005 18:12:50 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHTyI-0007yR-9K for ipsec@ietf.org; Mon, 19 Sep 2005 18:18:47 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8JMCacU010248 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 19 Sep 2005 15:12:36 -0700 (PDT) Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.100]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8JMCYS4022277 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Sep 2005 15:12:34 -0700 (PDT) Message-Id: <6.2.2.1.2.20050919150326.0603d618@qcmail1.qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.2.1 Date: Mon, 19 Sep 2005 15:12:32 -0700 To: Paul Hoffman , IPsec WG From: Lakshminath Dondeti Subject: Re: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages In-Reply-To: References: <6.2.2.1.2.20050912115245.02fcbb80@qcmail1.qualcomm.com> <1126556991.10962.5.camel@ghuang-lnx.juniper.net> <00b401c5b7ea$f68d1ac0$6701a8c0@adithya> <17193.18143.691032.354648@fireball.kivinen.iki.fi> <6.2.2.1.2.20050915111812.02aa8488@qcmail1.qualcomm.com> <1126809149.14802.406.camel@thunk> <6.2.2.1.2.20050915142919.02f5ba08@qcmail1.qualcomm.com> <1126820778.14802.439.camel@thunk> <6.2.2.1.2.20050915150459.03145d70@qcmail1.qualcomm.com> <6.2.2.1.2.20050919105827.05c5e3a8@qcmail1.qualcomm.com> <6.2.2.1.2.20050919140255.062b38d8@qcmail1.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 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 At 02:56 PM 9/19/2005, Paul Hoffman wrote: >At 2:07 PM -0700 9/19/05, Lakshminath Dondeti wrote: >>Yes indeed. However, my understanding was that QoS considerations do not >>apply to all implementations. In any event, a clarification one way or >>another should happen in some form -- ikev2-clarifications would be a start. > >That could happen if this group agrees. But... > >> But, the ikev2 draft can also be edited during the RFC Ed processes to >> note that supporting multiple simultaneous child SAs with the same TSs >> is not optional. > >I don't believe it can. This is a serious technical change, which would >mean that it would have to go back to the IESG and the WG (which no longer >exists). From what I have heard from a huge number of implementers, they >want IKEv2 as an RFC as soon as possible. Such a delay would probably be >unacceptable. Hi Paul, That makes sense. However, from the discussion over the past several days on the topic, it looks like the consensus is either 1) support for multiple CHILD SAs is not optional -- this was based on the 2401bis requirement. 2) at least if rekeying is implemented, support for multiple CHILD SAs is not optional (in other words the optional features in page 84 are not independent of each other as the text above the list seems to imply)-- this was based on the DELETE exchange requirement. Is that not the case? I am among those who would like to see the RFC immediately, but I'd prefer to see it with uncontested clarifications incorporated. thanks and regards, Lakshminath >--Paul Hoffman, Director >--VPN Consortium > >_______________________________________________ >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 Sep 19 18:33:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHUCO-0001li-AS; Mon, 19 Sep 2005 18:33:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHUCM-0001kc-0C for ipsec@megatron.ietf.org; Mon, 19 Sep 2005 18:33:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA04679 for ; Mon, 19 Sep 2005 18:33:14 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHUI0-0008QA-Ef for ipsec@ietf.org; Mon, 19 Sep 2005 18:39:12 -0400 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j8JMXC2B006696 for ; Mon, 19 Sep 2005 15:33:13 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j8JMXCUj024844 for ; Mon, 19 Sep 2005 18:33:12 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j8JMXBBS115970; Mon, 19 Sep 2005 18:33:12 -0400 (EDT) Subject: Re: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages From: Bill Sommerfeld To: Lakshminath Dondeti In-Reply-To: <6.2.2.1.2.20050919150326.0603d618@qcmail1.qualcomm.com> References: <6.2.2.1.2.20050912115245.02fcbb80@qcmail1.qualcomm.com> <1126556991.10962.5.camel@ghuang-lnx.juniper.net> <00b401c5b7ea$f68d1ac0$6701a8c0@adithya> <17193.18143.691032.354648@fireball.kivinen.iki.fi> <6.2.2.1.2.20050915111812.02aa8488@qcmail1.qualcomm.com> <1126809149.14802.406.camel@thunk> <6.2.2.1.2.20050915142919.02f5ba08@qcmail1.qualcomm.com> <1126820778.14802.439.camel@thunk> <6.2.2.1.2.20050915150459.03145d70@qcmail1.qualcomm.com> <6.2.2.1.2.20050919105827.05c5e3a8@qcmail1.qualcomm.com> <6.2.2.1.2.20050919140255.062b38d8@qcmail1.qualcomm.com> <6.2.2.1.2.20050919150326.0603d618@qcmail1.qualcomm.com> Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1127169191.113524.195.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.323 Date: Mon, 19 Sep 2005 18:33:11 -0400 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: IPsec WG , Paul Hoffman 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 Mon, 2005-09-19 at 18:12, Lakshminath Dondeti wrote: > 1) support for multiple CHILD SAs is not optional -- this was based on the > 2401bis requirement. > 2) at least if rekeying is implemented, support for multiple CHILD SAs is > not optional (in other words the optional features in page 84 are not > independent of each other as the text above the list seems to imply)-- this > was based on the DELETE exchange requirement. so, as I understand the specs at present, the place where you can prune functionality in an IKEv2 implementation without affecting interoperability is the ability to *initiate* multiple IPsec SA-pairs from a single IKE SA. In other words, in a simplified implementation, you can omit code which initiates a CREATE_CHILD_SA, but if you refuse to accept it when offered by a peer, you may create an interoperability barrier. - Bill _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 19 19:13:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHUp8-0004j5-Uv; Mon, 19 Sep 2005 19:13:22 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHUp6-0004j0-P4 for ipsec@megatron.ietf.org; Mon, 19 Sep 2005 19:13:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06692 for ; Mon, 19 Sep 2005 19:13:17 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHUul-0000wU-F0 for ipsec@ietf.org; Mon, 19 Sep 2005 19:19:13 -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 j8JNDAEa062995; Mon, 19 Sep 2005 16:13:11 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <6.2.2.1.2.20050919150326.0603d618@qcmail1.qualcomm.com> References: <6.2.2.1.2.20050912115245.02fcbb80@qcmail1.qualcomm.com> <1126556991.10962.5.camel@ghuang-lnx.juniper.net> <00b401c5b7ea$f68d1ac0$6701a8c0@adithya> <17193.18143.691032.354648@fireball.kivinen.iki.fi> <6.2.2.1.2.20050915111812.02aa8488@qcmail1.qualcomm.com> <1126809149.14802.406.camel@thunk> <6.2.2.1.2.20050915142919.02f5ba08@qcmail1.qualcomm.com> <1126820778.14802.439.camel@thunk> <6.2.2.1.2.20050915150459.03145d70@qcmail1.qualcomm.com> <6.2.2.1.2.20050919105827.05c5e3a8@qcmail1.qualcomm.com> <6.2.2.1.2.20050919140255.062b38d8@qcmail1.qualcomm.com> <6.2.2.1.2.20050919150326.0603d618@qcmail1.qualcomm.com> Date: Mon, 19 Sep 2005 16:13:12 -0700 To: Lakshminath Dondeti , IPsec WG From: Paul Hoffman Subject: Re: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 At 3:12 PM -0700 9/19/05, Lakshminath Dondeti wrote: >That makes sense. However, from the discussion over the past >several days on the topic, it looks like the consensus is either > >1) support for multiple CHILD SAs is not optional -- this was based >on the 2401bis requirement. To date, fewer people have been as concerned about requirements in 2401bis as they have been in IKEv2. >2) at least if rekeying is implemented, support for multiple CHILD >SAs is not optional (in other words the optional features in page 84 >are not independent of each other as the text above the list seems >to imply)-- this was based on the DELETE exchange requirement. I don't agree that there is consensus on that yet, given how few implementers have said anything. This part of the IKEv2 document was reviewed many times and discussed in the WG many times. The issue can be covered as recommendations in the IKEv2 clarification document. >I am among those who would like to see the RFC immediately, but I'd >prefer to see it with uncontested clarifications incorporated. We do not have that option; that's why Pasi and I are working on the clarifications document. I would note, however, that we are hearing less and less about the open issues in that document, and that's a tad disturbing. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 19 19:16:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHUru-00052P-NW; Mon, 19 Sep 2005 19:16:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHUrs-00051z-4r for ipsec@megatron.ietf.org; Mon, 19 Sep 2005 19:16:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06777 for ; Mon, 19 Sep 2005 19:16:08 -0400 (EDT) Received: from ithilien.qualcomm.com ([129.46.51.59]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHUxY-0000zy-22 for ipsec@ietf.org; Mon, 19 Sep 2005 19:22:06 -0400 Received: from neophyte.qualcomm.com (neophyte.qualcomm.com [129.46.61.149]) by ithilien.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8JNFrIr010603; Mon, 19 Sep 2005 16:15:54 -0700 (PDT) Received: from LDONDETI.qualcomm.com (ldondeti.na.qualcomm.com [129.46.173.100]) by neophyte.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j8JNFpS4017099 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Sep 2005 16:15:52 -0700 (PDT) Message-Id: <6.2.2.1.2.20050919161439.0609f0e0@qcmail1.qualcomm.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.2.1 Date: Mon, 19 Sep 2005 16:15:50 -0700 To: Paul Hoffman , IPsec WG From: Lakshminath Dondeti Subject: Re: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages In-Reply-To: References: <6.2.2.1.2.20050912115245.02fcbb80@qcmail1.qualcomm.com> <1126556991.10962.5.camel@ghuang-lnx.juniper.net> <00b401c5b7ea$f68d1ac0$6701a8c0@adithya> <17193.18143.691032.354648@fireball.kivinen.iki.fi> <6.2.2.1.2.20050915111812.02aa8488@qcmail1.qualcomm.com> <1126809149.14802.406.camel@thunk> <6.2.2.1.2.20050915142919.02f5ba08@qcmail1.qualcomm.com> <1126820778.14802.439.camel@thunk> <6.2.2.1.2.20050915150459.03145d70@qcmail1.qualcomm.com> <6.2.2.1.2.20050919105827.05c5e3a8@qcmail1.qualcomm.com> <6.2.2.1.2.20050919140255.062b38d8@qcmail1.qualcomm.com> <6.2.2.1.2.20050919150326.0603d618@qcmail1.qualcomm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 At 04:13 PM 9/19/2005, Paul Hoffman wrote: >At 3:12 PM -0700 9/19/05, Lakshminath Dondeti wrote: >>That makes sense. However, from the discussion over the past several >>days on the topic, it looks like the consensus is either >> >>1) support for multiple CHILD SAs is not optional -- this was based on >>the 2401bis requirement. > >To date, fewer people have been as concerned about requirements in 2401bis >as they have been in IKEv2. > >>2) at least if rekeying is implemented, support for multiple CHILD SAs is >>not optional (in other words the optional features in page 84 are not >>independent of each other as the text above the list seems to imply)-- >>this was based on the DELETE exchange requirement. > >I don't agree that there is consensus on that yet, given how few >implementers have said anything. This part of the IKEv2 document was >reviewed many times and discussed in the WG many times. The issue can be >covered as recommendations in the IKEv2 clarification document. > >>I am among those who would like to see the RFC immediately, but I'd >>prefer to see it with uncontested clarifications incorporated. > >We do not have that option; that's why Pasi and I are working on the >clarifications document. I would note, however, that we are hearing less >and less about the open issues in that document, and that's a tad disturbing. Thanks for the clarifications (no pun intended) Paul. On the open issues, perhaps an issue list and a tracker might get discussions going. regards, Lakshminath >--Paul Hoffman, Director >--VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 20 03:30:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHcae-0002H3-2S; Tue, 20 Sep 2005 03:30:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHcac-0002Fh-Hm for ipsec@megatron.ietf.org; Tue, 20 Sep 2005 03:30:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13122 for ; Tue, 20 Sep 2005 03:30:52 -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.43) id 1EHcgN-0003xQ-Ty for ipsec@ietf.org; Tue, 20 Sep 2005 03:36:53 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8K7UkFB031033; Tue, 20 Sep 2005 10:30:51 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Sep 2005 10:30:50 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Sep 2005 10:30:49 +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] Clarification on error notifications, please Date: Tue, 20 Sep 2005 10:30:48 +0300 Message-ID: Thread-Topic: [Ipsec] Clarification on error notifications, please Thread-Index: AcW9WNiC3WC/ATcKTHG2d560crHBKwAWygCw To: X-OriginalArrivalTime: 20 Sep 2005 07:30:49.0664 (UTC) FILETIME=[39382C00:01C5BDB5] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 Tero Kivinen wrote: > jcervantes@reefpoint.com writes: > > Once we have obtained privacy and integrity protection, but not=20 > > yet authenticated our peer, we can break down the analysis into=20 > > precisely two cases: > >=20 > > a. we are talking with the intended peer > >=20 > > b. we are not talking with the intended peer (includes all=20 > > man-in-the-middle scenarios) >=20 > c. We are talking to the intended peer, but attacker has modified=20 > the cipher/prf/hash etc algorithms proposed by the initiator.=20 > And do we want to tear down the SA as attacker modified the cipher=20 > to be null in IKE SA level, and we are now sending all that error > information in clear? > > Note, that we haven't yet verified that the SA payload cipher/hash/prf > etc exchange is done properly without someone attacking against those. If the attacker has modified the algorithm proposals, the SA will be torn down anyway because verification of the AUTH payload will fail. Also, even if the attacker has modified the proposals, the selected algorithms are still something that the peers consider as providing sufficient level of security for them (and certainly not NULL).=20 If it's sufficient for all other purposes as well, it's IMHO=20 sufficient for encrypting an AUTHENTICATION_FAILED notification, too. Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 20 06:47:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHfeo-000387-3h; Tue, 20 Sep 2005 06:47:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHfel-00036B-SW for ipsec@megatron.ietf.org; Tue, 20 Sep 2005 06:47:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21948 for ; Tue, 20 Sep 2005 06:47:20 -0400 (EDT) Received: from laposte.rennes.enst-bretagne.fr ([192.44.77.17]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHfkY-0000OZ-QX for ipsec@ietf.org; Tue, 20 Sep 2005 06:53:24 -0400 Received: from givry.rennes.enst-bretagne.fr (givry.rennes.enst-bretagne.fr [193.52.74.194]) by laposte.rennes.enst-bretagne.fr (8.11.6p2/8.11.6/2003.04.01) with ESMTP id j8KAkxE22100; Tue, 20 Sep 2005 12:46:59 +0200 Received: from givry.rennes.enst-bretagne.fr (localhost.rennes.enst-bretagne.fr [127.0.0.1]) by givry.rennes.enst-bretagne.fr (8.13.1/8.13.1) with ESMTP id j8KAkw2k070284; Tue, 20 Sep 2005 12:46:59 +0200 (CEST) (envelope-from dupont@givry.rennes.enst-bretagne.fr) Message-Id: <200509201046.j8KAkw2k070284@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Vijay Devarapalli Subject: Re: [Ipsec] draft-ietf-mip6-ikev2-ipsec In-reply-to: Your message of Thu, 15 Sep 2005 11:45:37 PDT. <4329C151.9000906@iprg.nokia.com> Date: Tue, 20 Sep 2005 12:46:58 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 In your previous mail you wrote: draft-ietf-mip6-ikev2-ipsec-03 describes how IKEv2 and rfc2401bis can be used with MIPv6 for securing MIPv6 signaling messages. http://www.ietf.org/internet-drafts/draft-ietf-mip6-ikev2-ipsec-03 this draft is under a WG last call in the MIP6 WG right now. it would be great if some of you could review this draft and provide comments. => to summary my concerns about the I-D for IPsec people: we have the choice between a 2401bis/IKEv2 version of RFC 3776 or a really new document which is based on 2401bis/IKEv2 and ignores the RFC 3776. Publics are not the same: in the one case it is for guys who have already implemented RFC 3776 and would like to go to 2401bis/IKEv2, in the other case it is for future implementors who will directly go to 2401bis/ IKEv2. As it seems the first population is very small, I prefer the second choice so: - more terminology from 2401bis should be used, for instance: * local/remote in place of source/destination * protect with in place of use - an annex specifying the SPD entries in the ASN.1 format from 2401bis should be added (I am ready to help but if someone has a parser/ checker for this it will be very useful). Regards Francis.Dupont@enst-bretagne.fr _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 20 08:48:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHhXi-0007Jq-HR; Tue, 20 Sep 2005 08:48:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHhXf-0007Jh-9e for ipsec@megatron.ietf.org; Tue, 20 Sep 2005 08:48:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA27197 for ; Tue, 20 Sep 2005 08:48:09 -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.43) id 1EHhdU-0003N4-Fu for ipsec@ietf.org; Tue, 20 Sep 2005 08:54:13 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j8KCkrZE023419 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Sep 2005 15:46:53 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j8KCkjTj023155; Tue, 20 Sep 2005 15:46:45 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17200.1205.101043.357218@fireball.kivinen.iki.fi> Date: Tue, 20 Sep 2005 15:46:45 +0300 From: Tero Kivinen To: jcervantes@reefpoint.com Subject: RE: [Ipsec] Clarification on error notifications, please In-Reply-To: <496A8683261CD211BF6C0008C733261A0688AE26@email.quarrytech.com> References: <496A8683261CD211BF6C0008C733261A0688AE26@email.quarrytech.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 11 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 jcervantes@reefpoint.com writes: > My intent in defining case a. is to describe the situation where there is no > modification of messages by any third party (i.e., no man in the middle) and > we are in fact talking with the intended peer. Case b. is the complement - > literally everything else. Your case c. is therefore a sub-case of case b. > and everything I said before still applies. But as you have not authenticated you do not know if you are talking to the intended peer. > In your case c. there is an attacker modifying messages and the desirable > outcome is to abandon the negotiation. Are you suggesting there is > something better to be done in this case? In case the real responder also gets the packets and answers to them too, then you do not want to be tricked by the attacker sending packets to you too (i.e. if you implement the 3rd last paragraph of 2.4, you must not abort the negotiation if you receive notify from one of those messages). > Null encryption is not legal so I don't understand your point about sending > an error notification in the clear. That was just to point you out that we haven't yet authenticated the SA parameters, so you might be tricked to use weaker (or even broken) cipher/hash by the attacker and that might have other security properties. As we have not authenticated those yet, we have to consider that as a completele different case and it makes security analysis of the protocol quite hard, and there might be new attacks opened because of that. As authentication failure is usually permanent condition that can only be fixed by the human interaction, there is no real reason to use that as special case requiring faster error messages than normally (i.e. normal timeouts). Note, that those should not happen in case there is interactive authentication going on using EAP, as then you do send EAP(FAILURE) instead of error notify. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 20 08:59:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHhi8-0002z0-M0; Tue, 20 Sep 2005 08:59:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHhi5-0002w5-TM for ipsec@megatron.ietf.org; Tue, 20 Sep 2005 08:58:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28006 for ; Tue, 20 Sep 2005 08:58:56 -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.43) id 1EHhnv-0003lL-5u for ipsec@ietf.org; Tue, 20 Sep 2005 09:04:59 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j8KCvh40020198 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Sep 2005 15:57:43 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j8KCvcE9007851; Tue, 20 Sep 2005 15:57:38 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17200.1858.186740.648267@fireball.kivinen.iki.fi> Date: Tue, 20 Sep 2005 15:57:38 +0300 From: Tero Kivinen To: Paul Hoffman Subject: Re: [Ipsec] Rekeying CHILD SAs in IKEv2 and Delete messages In-Reply-To: References: <6.2.2.1.2.20050912115245.02fcbb80@qcmail1.qualcomm.com> <1126556991.10962.5.camel@ghuang-lnx.juniper.net> <00b401c5b7ea$f68d1ac0$6701a8c0@adithya> <17193.18143.691032.354648@fireball.kivinen.iki.fi> <6.2.2.1.2.20050915111812.02aa8488@qcmail1.qualcomm.com> <1126809149.14802.406.camel@thunk> <6.2.2.1.2.20050915142919.02f5ba08@qcmail1.qualcomm.com> <1126820778.14802.439.camel@thunk> <6.2.2.1.2.20050915150459.03145d70@qcmail1.qualcomm.com> <6.2.2.1.2.20050919105827.05c5e3a8@qcmail1.qualcomm.com> <6.2.2.1.2.20050919140255.062b38d8@qcmail1.qualcomm.com> <6.2.2.1.2.20050919150326.0603d618@qcmail1.qualcomm.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 1 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: IPsec WG 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: > I don't agree that there is consensus on that yet, given how few > implementers have said anything. This part of the IKEv2 document was > reviewed many times and discussed in the WG many times. The issue can > be covered as recommendations in the IKEv2 clarification document. I think most of the implementors do not really care about the minimal requirements of the IKEv2 draft, as they need to implement more anyways. And if they are working on the VERY limited environment, they are going to cut corners anyways, and they KNOW their implementation is not doing even the minimal required things, but that does not matter as it is supported to be limited use implementation. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 20 09:36:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHiIp-0005Gs-1s; Tue, 20 Sep 2005 09:36:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHiIm-0005Gk-Nb for ipsec@megatron.ietf.org; Tue, 20 Sep 2005 09:36:52 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00056 for ; Tue, 20 Sep 2005 09:36:50 -0400 (EDT) From: jcervantes@reefpoint.com Received: from email.quarrytech.com ([4.17.144.4] helo=qtech1.quarrytech.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHiOc-0004pk-HO for ipsec@ietf.org; Tue, 20 Sep 2005 09:42:54 -0400 Received: by email.quarrytech.com with Internet Mail Service (5.5.2653.19) id ; Tue, 20 Sep 2005 09:33:03 -0400 Message-ID: <496A8683261CD211BF6C0008C733261A0688AE27@email.quarrytech.com> To: kivinen@iki.fi Subject: RE: [Ipsec] Clarification on error notifications, please Date: Tue, 20 Sep 2005 09:33:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" X-Spam-Score: 0.3 (/) X-Scan-Signature: b7b9551d71acde901886cc48bfc088a6 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 As I pointed out previously, you cannot know (until verification via the AUTH payload) whether or not you are talking securely with the intended peer. The strategy I am proposing for an initiator responding to an authentication failure notification (by tearing down local state) is independent of such knowledge, so I don't see why you complain about not possessing this knowledge. Regarding the third paragraph of section 2.4, the DOS attack and avoidance strategy describe here is relevant to the INIT exchange. This thread is only concerned with the AUTH exchange. For diagnostic purposes, it is much better to receive an immediate notification, especially in testing scenarios. Furthermore, if an initiator has something useful to do in response to an authentication failure, such as attempting to establish a tunnel with a different peer or with the same peer in a different way, it can do so without a long delay. I don't want a long delay when I try to make a phone call on my UMA mobile phone. Lastly, it is in fact the case that an unsuccessful EAP authentication dialogue can end without an EAP failure message. Consider a responder that acts as a pass-through NAS to a RADIUS AAA backend. It may receive an authentication failure response via RADIUS that does not include an EAP failure message. A pass-through NAS is not supposed to generate its own EAP failure message in this situation, so the only option remaining is to send an AUTHENTICATION_FAILED error notification back to the initiator. Jim -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi] Sent: Tuesday, September 20, 2005 8:47 AM To: jcervantes@reefpoint.com Cc: ipsec@ietf.org Subject: RE: [Ipsec] Clarification on error notifications, please jcervantes@reefpoint.com writes: > My intent in defining case a. is to describe the situation where there is no > modification of messages by any third party (i.e., no man in the middle) and > we are in fact talking with the intended peer. Case b. is the complement - > literally everything else. Your case c. is therefore a sub-case of case b. > and everything I said before still applies. But as you have not authenticated you do not know if you are talking to the intended peer. > In your case c. there is an attacker modifying messages and the desirable > outcome is to abandon the negotiation. Are you suggesting there is > something better to be done in this case? In case the real responder also gets the packets and answers to them too, then you do not want to be tricked by the attacker sending packets to you too (i.e. if you implement the 3rd last paragraph of 2.4, you must not abort the negotiation if you receive notify from one of those messages). > Null encryption is not legal so I don't understand your point about sending > an error notification in the clear. That was just to point you out that we haven't yet authenticated the SA parameters, so you might be tricked to use weaker (or even broken) cipher/hash by the attacker and that might have other security properties. As we have not authenticated those yet, we have to consider that as a completele different case and it makes security analysis of the protocol quite hard, and there might be new attacks opened because of that. As authentication failure is usually permanent condition that can only be fixed by the human interaction, there is no real reason to use that as special case requiring faster error messages than normally (i.e. normal timeouts). Note, that those should not happen in case there is interactive authentication going on using EAP, as then you do send EAP(FAILURE) instead of error notify. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 20 12:44:36 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHlES-0006dF-0L; Tue, 20 Sep 2005 12:44:36 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHlEQ-0006d3-4m for ipsec@megatron.ietf.org; Tue, 20 Sep 2005 12:44:34 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13959 for ; Tue, 20 Sep 2005 12:44:28 -0400 (EDT) Received: from e4.ny.us.ibm.com ([32.97.182.144]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHlKE-0002SM-IG for ipsec@ietf.org; Tue, 20 Sep 2005 12:50:35 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e4.ny.us.ibm.com (8.12.11/8.12.11) with ESMTP id j8KGiJpd010941 for ; Tue, 20 Sep 2005 12:44:19 -0400 Received: from d01av01.pok.ibm.com (d01av01.pok.ibm.com [9.56.224.215]) by d01relay02.pok.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id j8KGiJ2T095652 for ; Tue, 20 Sep 2005 12:44:19 -0400 Received: from d01av01.pok.ibm.com (loopback [127.0.0.1]) by d01av01.pok.ibm.com (8.12.11/8.13.3) with ESMTP id j8KGiJQt010785 for ; Tue, 20 Sep 2005 12:44:19 -0400 Received: from d27ml101.rchland.ibm.com (d27ml101.rchland.ibm.com [9.10.229.40]) by d01av01.pok.ibm.com (8.12.11/8.12.11) with ESMTP id j8KGiIL6010774 for ; Tue, 20 Sep 2005 12:44:18 -0400 From: Dennis Frett To: ipsec@ietf.org Message-ID: Date: Tue, 20 Sep 2005 11:44:16 -0500 X-MIMETrack: Serialize by Router on d27ml101/27/M/IBM(Release 6.5.4|March 27, 2005) at 09/20/2005 11:44:17 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d62ab47271805379d7172ee693a45db Subject: [Ipsec] Dennis Frett/Rochester/IBM is out of the office. 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 will be out of the office starting 09/20/2005 and will not return until 09/21/2005. Testing my out of office Response. I'm not really out of office today. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 20 14:26:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHmpM-0002cJ-LR; Tue, 20 Sep 2005 14:26:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHmpL-0002cC-1u for ipsec@megatron.ietf.org; Tue, 20 Sep 2005 14:26:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20864 for ; Tue, 20 Sep 2005 14:26: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.43) id 1EHmvD-0005nw-33 for ipsec@ietf.org; Tue, 20 Sep 2005 14:32:51 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j8KIPUJw010644 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Sep 2005 21:25:30 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j8KIPTIN027583; Tue, 20 Sep 2005 21:25:29 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17200.21529.618674.660409@fireball.kivinen.iki.fi> Date: Tue, 20 Sep 2005 21:25:29 +0300 From: Tero Kivinen To: jcervantes@reefpoint.com Subject: RE: [Ipsec] Clarification on error notifications, please In-Reply-To: <496A8683261CD211BF6C0008C733261A0688AE27@email.quarrytech.com> References: <496A8683261CD211BF6C0008C733261A0688AE27@email.quarrytech.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 12 min X-Total-Time: 12 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a 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 jcervantes@reefpoint.com writes: > Regarding the third paragraph of section 2.4, the DOS attack and avoidance > strategy describe here is relevant to the INIT exchange. This thread is > only concerned with the AUTH exchange. They are not limited to the INIT exchange. You only know that it is really the person you wanteed to talk to after you have processed the valid AUTH payload from the other end. Meaning: Initiator Attacker Responder IKE_SA_INIT -> <- IKE_SA_INIT_A <- IKE_SA_INIT_B <- IKE_SA_INIT_R now the Initiator will continue with all those packets, and send out IKE_AUTH_A -> IKE_AUTH_B -> IKE_AUTH_R -> Attacker can decrypt those packets, and they can send valid cryptographically protecteed error message, but they still cannot generate AUTH payload that Initiator would accept. The Responder can return IKE_AUTH packet with valid AUTH payload and then Initiator will know that A, and B were bogus, and he can remove those, and only keep the R. <- IKE_AUTH_A(AUTHENTICATION_FAILURE) <- IKE_AUTH_B(INVALID_SYNTAX) <- IKE_AUTH(valid) > For diagnostic purposes, it is much better to receive an immediate > notification, especially in testing scenarios. Furthermore, if an initiator Changes made because of testing purposes should be considered as testing aids, and they should not affect the security of the protocol. > has something useful to do in response to an authentication failure, such as > attempting to establish a tunnel with a different peer or with the same peer > in a different way, it can do so without a long delay. I don't want a long > delay when I try to make a phone call on my UMA mobile phone. As there is no indication how to fix the situation, the initiator cannot really do anything there. If your UMA mobile phone sim card is rejected because of you haven't paid your bills, I do not think immediate error messages really can solve the situation any faster... Trying to get contact with the operators helpdesk will take hours anyways :) > Lastly, it is in fact the case that an unsuccessful EAP authentication > dialogue can end without an EAP failure message. Consider a responder that > acts as a pass-through NAS to a RADIUS AAA backend. It may receive an > authentication failure response via RADIUS that does not include an EAP > failure message. A pass-through NAS is not supposed to generate its own EAP > failure message in this situation, so the only option remaining is to send > an AUTHENTICATION_FAILED error notification back to the initiator. The IKEv2 does not really allow that kind of behavior (section 2.16): Once the protocol exchange defined by the chosen EAP authentication method has successfully terminated, the responder MUST send an EAP payload containing the Success message. Similarly, if the authentication method has failed, the responder MUST send an EAP payload containing the Failure message. The responder MAY at any time terminate the IKE exchange by sending an EAP payload containing the Failure message. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 20 15:06:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHnS4-0004or-TM; Tue, 20 Sep 2005 15:06:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHnS2-0004oj-Vl for ipsec@megatron.ietf.org; Tue, 20 Sep 2005 15:06:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23316 for ; Tue, 20 Sep 2005 15:06: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.43) id 1EHnXv-0006rz-Ao for ipsec@ietf.org; Tue, 20 Sep 2005 15:12:51 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j8KJ5Sxk006096 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Sep 2005 22:05:28 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j8KJ5SU9025793; Tue, 20 Sep 2005 22:05:28 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17200.23928.483265.806706@fireball.kivinen.iki.fi> Date: Tue, 20 Sep 2005 22:05:28 +0300 From: Tero Kivinen To: jcervantes@reefpoint.com, ipsec@ietf.org Subject: RE: [Ipsec] Clarification on error notifications, please In-Reply-To: <17200.21529.618674.660409@fireball.kivinen.iki.fi> References: <496A8683261CD211BF6C0008C733261A0688AE27@email.quarrytech.com> <17200.21529.618674.660409@fireball.kivinen.iki.fi> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 3 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit 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: > > For diagnostic purposes, it is much better to receive an immediate > > notification, especially in testing scenarios. Furthermore, if an initiator > > Changes made because of testing purposes should be considered as > testing aids, and they should not affect the security of the protocol. To clarify this point a bit more, sending error notifications in that kind of situations is usefull for diagnostic purposes. Acting based on such unauthetnicated (though encrypted and mac'ed) notifies do affect the security of the protocol in a way that is not necessarely understood properly by the casual observer. There are quite a lot of tiny things there that needs to be taken account, and I would not recommend acting based on those messages unless you really understand what it means from the security point of view. The current security considerations does not cover that as the current document says you do not act based on unauthenticated notifies. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 20 16:10:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHoS6-0007NX-6x; Tue, 20 Sep 2005 16:10:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHoS3-0007Ml-3s for ipsec@megatron.ietf.org; Tue, 20 Sep 2005 16:10:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00749 for ; Tue, 20 Sep 2005 16:10:48 -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.43) id 1EHoXv-0001HY-5U for ipsec@ietf.org; Tue, 20 Sep 2005 16:16:56 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j8KK9VWh019603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 20 Sep 2005 23:09:31 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j8KK9UPa029293; Tue, 20 Sep 2005 23:09:30 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17200.27770.769931.674789@fireball.kivinen.iki.fi> Date: Tue, 20 Sep 2005 23:09:30 +0300 From: Tero Kivinen To: ipsec@ietf.org X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 14 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Subject: [Ipsec] INVALID_KE_PAYLOAD and clarifications document 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 There are couple of issues noticed here in the ipsec bake-off event about the INVALID_KE_PAYLOAD that could use some more clarification in clarifications document. ---------------------------------------------------------------------- 2.1 SPI values in IKE_SA_INIT exchange ... Since the IKE_SA_INIT request always has a zero responder SPI, the value will not be actually used by the initiator. Thus, we think sending a zero value is correct also in this case. ---------------------------------------------------------------------- I think another possible interpreation would be that if responder allocated responder SPI in those error messages, it actually also generated some state, thus the initiator should use that responder SPI to help the responder to keep track of that state. On the other hand there is no reason to generate state in those cases, thus the responder should always send responder SPI as zero. So for the responder: Use SPIr as zero unless you allocate state. For initiator: copy the SPIr from the previous message (most likely it is zero). Another issue is the section 2.4. It is missing the most common case that everybody is using: Initiator Responder ----------- ----------- HDR(A,0), SAi1, KEi, Ni --> <-- HDR(A,0), N(COOKIE) HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> <-- HDR(A,0), N(INVALID_KE_PAYLOAD) HDR(A,0), N(COOKIE), SAi1, KEi', Ni --> <-- HDR(A,B), SAr1, KEr, Nr I.e. if you have received a cookie during the exchange, you need to use that in all the future versions of the IKE_SA_INIT messages. This will cut out one round trip in the exchange. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 20 21:58:44 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHtsi-0003vg-6Y; Tue, 20 Sep 2005 21:58:44 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EHtsg-0003vb-0R for ipsec@megatron.ietf.org; Tue, 20 Sep 2005 21:58:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20019 for ; Tue, 20 Sep 2005 21:58:39 -0400 (EDT) Received: from mailalarm.checkpoint.com ([194.29.32.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EHtya-0001XB-HQ for ipsec@ietf.org; Tue, 20 Sep 2005 22:04:50 -0400 Received: from michael.checkpoint.com (michael.checkpoint.com [194.29.32.68]) by mailalarm.checkpoint.com (8.12.11/8.12.11) with ESMTP id j8L2LspB010610; Wed, 21 Sep 2005 05:21:54 +0300 Received: from [172.31.24.191] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id j8L1wHnP016647; Wed, 21 Sep 2005 04:58:18 +0300 (IDT) In-Reply-To: <17200.27770.769931.674789@fireball.kivinen.iki.fi> References: <17200.27770.769931.674789@fireball.kivinen.iki.fi> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <80f7817156ff263f29b11fd152cba10b@checkpoint.com> Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] INVALID_KE_PAYLOAD and clarifications document Date: Tue, 20 Sep 2005 21:58:14 -0400 To: Tero Kivinen X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 Comments inline. On Sep 20, 2005, at 4:09 PM, Tero Kivinen wrote: > There are couple of issues noticed here in the ipsec bake-off event > about the INVALID_KE_PAYLOAD that could use some more clarification in > clarifications document. > > ---------------------------------------------------------------------- > 2.1 SPI values in IKE_SA_INIT exchange > ... > Since the IKE_SA_INIT request always has a zero responder SPI, the > value will not be actually used by the initiator. Thus, we think > sending a zero value is correct also in this case. > ---------------------------------------------------------------------- > > I think another possible interpreation would be that if responder > allocated responder SPI in those error messages, it actually also > generated some state, thus the initiator should use that responder SPI > to help the responder to keep track of that state. > > On the other hand there is no reason to generate state in those cases, > thus the responder should always send responder SPI as zero. > > So for the responder: Use SPIr as zero unless you allocate state. > > For initiator: copy the SPIr from the previous message (most likely it > is zero). > Is this really necessary? I think it needlessly complicates things for the initiator. It creates two distinct behaviors the initiator can expect. When the initiator tries again, suppose the responder responds with another SPIr. Does this matter? Should the initiator stop the exchange? > Another issue is the section 2.4. It is missing the most common case > that everybody is using: > > Initiator Responder > ----------- ----------- > HDR(A,0), SAi1, KEi, Ni --> > <-- HDR(A,0), N(COOKIE) > HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> > <-- HDR(A,0), N(INVALID_KE_PAYLOAD) > HDR(A,0), N(COOKIE), SAi1, KEi', Ni --> > <-- HDR(A,B), SAr1, KEr, Nr > > I.e. if you have received a cookie during the exchange, you need to > use that in all the future versions of the IKE_SA_INIT messages. This > will cut out one round trip in the exchange. This assumes that the cookie is still valid. If you use the algorithm suggested in section 2.6 of the draft (bottom of page 19), then it is. But the draft does not mandate this algorithm, and it's certainly possible that the cookie is calculated based on the contents of the KE payload. In such a case the original cookie is not valid. This brings up another issue. Does the draft specify what a responder should do if it receives an invalid cookie? We know what it should do with a valid cookie and what it should do with no cookie at all (send a cookie), but what if the cookie does not compute? Silently discard? Send the correct cookie? _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 21 09:02:18 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI4Er-0007AL-Uf; Wed, 21 Sep 2005 09:02:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI4En-0007A6-Et for ipsec@megatron.ietf.org; Wed, 21 Sep 2005 09:02:15 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17366 for ; Wed, 21 Sep 2005 09:02:12 -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.43) id 1EI4Kp-0000sq-6T for ipsec@ietf.org; Wed, 21 Sep 2005 09:08:27 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j8LD0Yjr029848 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Sep 2005 16:00:34 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j8LD0Twu013704; Wed, 21 Sep 2005 16:00:29 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17201.22893.470410.506303@fireball.kivinen.iki.fi> Date: Wed, 21 Sep 2005 16:00:29 +0300 From: Tero Kivinen To: Yoav Nir Subject: Re: [Ipsec] INVALID_KE_PAYLOAD and clarifications document In-Reply-To: <80f7817156ff263f29b11fd152cba10b@checkpoint.com> References: <17200.27770.769931.674789@fireball.kivinen.iki.fi> <80f7817156ff263f29b11fd152cba10b@checkpoint.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 18 min X-Total-Time: 22 min X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 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 Yoav Nir writes: > > For initiator: copy the SPIr from the previous message (most likely it > > is zero). > > > > Is this really necessary? I think it needlessly complicates things for > the initiator. It creates two distinct behaviors the initiator can > expect. Actually no it does not. Initiator will simply use the same SPIr that was sent to him. He does not need to know how or why the other end selected his SPIr, so he simply uses that as normally. > When the initiator tries again, suppose the responder responds > with another SPIr. Why would the responder respond with another SPIr? If he has allocated some SPIr because of he allocated some state, he are going to use the same SPIr. If he allocated SPIr because of bug in his code, that should be fixed, or at least he should except to get it back. > Does this matter? Should the initiator stop the > exchange? Initiator should process it just like normally when SPIr changes in the middle. Some implementations will consider it new IKE SA, some will simply continue checking the SPI they allocated (SPIi in this case), and continue with that IKE SA (or even update the SPIr). The IKEv2 used to have feature where the responder could change his own SPIr, but that was removed. The current text says: ---------------------------------------------------------------------- 2.6 Cookies ... message. Since the SPI chosen by the original initiator of the IKE_SA is always sent first, an endpoint with multiple IKE_SAs open that wants to find the appropriate IKE_SA using the SPI it assigned must look at the I(nitiator) Flag bit in the header to determine whether it assigned the first or the second eight octets. ... ---------------------------------------------------------------------- So that does not really say what you should do in case the SPI that the other end allocated changes. Anyways as the responder should not allocate state in either cookie nor in the invalid ke payload messages, the easiest thing is to say that SPIr must be zero for all of those cases, and in that case it does not really matter what initiator does if the SPIr is non-zero. I myself have implemented it so that we always send SPIr as zero in those cases, but if the other end used some other SPIr in those cases, I will copy that SPIr to the next message I send out (as I assume there was some reason for it to use non-zero SPIr). > > Another issue is the section 2.4. It is missing the most common case > > that everybody is using: > > > > Initiator Responder > > ----------- ----------- > > HDR(A,0), SAi1, KEi, Ni --> > > <-- HDR(A,0), N(COOKIE) > > HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> > > <-- HDR(A,0), N(INVALID_KE_PAYLOAD) > > HDR(A,0), N(COOKIE), SAi1, KEi', Ni --> > > <-- HDR(A,B), SAr1, KEr, Nr > > > > I.e. if you have received a cookie during the exchange, you need to > > use that in all the future versions of the IKE_SA_INIT messages. This > > will cut out one round trip in the exchange. > > This assumes that the cookie is still valid. If you use the algorithm > suggested in section 2.6 of the draft (bottom of page 19), then it is. True. Note also that is completely valid for the cookie not be valid in any of the cases, as it might be the responder has just changed the cookie calculation secret so many times during the exchange that old cookies are not valid. > But the draft does not mandate this algorithm, and it's certainly > possible that the cookie is calculated based on the contents of the KE > payload. In such a case the original cookie is not valid. Yes, and in that case the responder returns me the new cookie: Initiator Responder ----------- ----------- HDR(A,0), SAi1, KEi, Ni --> <-- HDR(A,0), N(COOKIE) HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> <-- HDR(A,0), N(INVALID_KE_PAYLOAD) HDR(A,0), N(COOKIE), SAi1, KEi', Ni --> <-- HDR(A,0), N(COOKIE') HDR(A,0), N(COOKIE'), SAi1, KEi', Ni --> <-- HDR(A,B), SAr1, KEr, Nr > This brings up another issue. Does the draft specify what a responder > should do if it receives an invalid cookie? As he cannot distinguish an old cookie before laste secret version change, and completely random cookie, I assume it is supposed to generate new cookie, and send that to the initiator: ---------------------------------------------------------------------- If a new value for is chosen while there are connections in the process of being initialized, an IKE_SA_INIT might be returned with other than the current . The responder in that case MAY reject the message by sending another response with a new cookie or it MAY keep the old value of around for a short time and accept cookies computed from either one. ---------------------------------------------------------------------- > We know what it should do with a valid cookie and what it should do > with no cookie at all (send a cookie), but what if the cookie does > not compute? Silently discard? Send the correct cookie? Send correct cookie. Cookie generartion is cheap, so why not allow connections to work also under attack (even if there is thousands of faked messages coming in requesting cookies, there might be still one valid message coming in and it should respond to it with cookie). -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 21 09:07:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI4JZ-0007cy-CY; Wed, 21 Sep 2005 09:07:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI4JW-0007c2-KH for ipsec@megatron.ietf.org; Wed, 21 Sep 2005 09:07:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17586 for ; Wed, 21 Sep 2005 09:07:05 -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.43) id 1EI4PX-000111-GE for ipsec@ietf.org; Wed, 21 Sep 2005 09:13:21 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8LD5htQ022280; Wed, 21 Sep 2005 16:05:47 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Sep 2005 16:07:00 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Sep 2005 16:06:53 +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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] INVALID_KE_PAYLOAD and clarifications document Date: Wed, 21 Sep 2005 16:06:54 +0300 Message-ID: Thread-Topic: [Ipsec] INVALID_KE_PAYLOAD and clarifications document Thread-Index: AcW+IDwZlj3vCmXmSVGAyacdePrEAwAiltZw To: , X-OriginalArrivalTime: 21 Sep 2005 13:06:53.0877 (UTC) FILETIME=[5670A650:01C5BEAD] X-Spam-Score: 0.3 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe 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 wrote: > There are couple of issues noticed here in the ipsec bake-off event > about the INVALID_KE_PAYLOAD that could use some more clarification > in clarifications document. >=20 > ---------------------------------------------------------------------- > 2.1 SPI values in IKE_SA_INIT exchange > ... > Since the IKE_SA_INIT request always has a zero responder SPI, the > value will not be actually used by the initiator. Thus, we think > sending a zero value is correct also in this case. > ---------------------------------------------------------------------- >=20 > I think another possible interpreation would be that if responder > allocated responder SPI in those error messages, it actually also > generated some state, thus the initiator should use that responder > SPI to help the responder to keep track of that state. >=20 > On the other hand there is no reason to generate state in those > cases, thus the responder should always send responder SPI as zero. >=20 > So for the responder: Use SPIr as zero unless you allocate state. >=20 > For initiator: copy the SPIr from the previous message (most=20 > likely it is zero). No, I think this advice is incorrect: the initiator must send SPIr as zero, regardless of what it received from the responder. This case is always required to work; doing something else just gets into trouble with the text about Message IDs. > Another issue is the section 2.4. It is missing the most common=20 > case that everybody is using: >=20 > Initiator Responder > ----------- ----------- > HDR(A,0), SAi1, KEi, Ni --> > <-- HDR(A,0), N(COOKIE) > HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> > <-- HDR(A,0), N(INVALID_KE_PAYLOAD) > HDR(A,0), N(COOKIE), SAi1, KEi', Ni --> > <-- HDR(A,B), SAr1, KEr, Nr >=20 > I.e. if you have received a cookie during the exchange, you need=20 > to use that in all the future versions of the IKE_SA_INIT > messages. This will cut out one round trip in the exchange. Section 2.4 does point out that doing something like this would cut out one roundtrip, but this is not allowed by the spec (it says "all other payloads unchanged", which includes KEi). So doing this is a violation of the spec, and leads to=20 interoperability problems if the responder includes KEi when generating the cookie (which is clearly allowed by the current spec). (I fully agree that your proposal makes much more sense, but it's not what got written in the spec -- and IMHO it's way too late to make technical changes now.) Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 21 09:46:40 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI4vo-0000tK-1S; Wed, 21 Sep 2005 09:46:40 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI4vl-0000tF-8b for ipsec@megatron.ietf.org; Wed, 21 Sep 2005 09:46:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20418 for ; Wed, 21 Sep 2005 09:46:35 -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.43) id 1EI51n-0002MP-Ip for ipsec@ietf.org; Wed, 21 Sep 2005 09:52:52 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j8LDjKFm013061 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Sep 2005 16:45:20 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j8LDjKMg027618; Wed, 21 Sep 2005 16:45:20 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17201.25584.294719.121148@fireball.kivinen.iki.fi> Date: Wed, 21 Sep 2005 16:45:20 +0300 From: Tero Kivinen To: Subject: RE: [Ipsec] INVALID_KE_PAYLOAD and clarifications document In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 11 min X-Total-Time: 12 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 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 Pasi.Eronen@nokia.com writes: > No, I think this advice is incorrect: the initiator must send > SPIr as zero, regardless of what it received from the responder. > This case is always required to work; doing something else just > gets into trouble with the text about Message IDs. Where does it say it is required to work? The normal operation is to use the SPIr that is set by the responder when he sets it. Where is the exception to this case. Note, that responder is supposed to be using SPIr zero, but this is the case where he decided not to use SPIr zero. > > Another issue is the section 2.4. It is missing the most common > > case that everybody is using: > > > > Initiator Responder > > ----------- ----------- > > HDR(A,0), SAi1, KEi, Ni --> > > <-- HDR(A,0), N(COOKIE) > > HDR(A,0), N(COOKIE), SAi1, KEi, Ni --> > > <-- HDR(A,0), N(INVALID_KE_PAYLOAD) > > HDR(A,0), N(COOKIE), SAi1, KEi', Ni --> > > <-- HDR(A,B), SAr1, KEr, Nr > > > > I.e. if you have received a cookie during the exchange, you need > > to use that in all the future versions of the IKE_SA_INIT > > messages. This will cut out one round trip in the exchange. > > Section 2.4 does point out that doing something like this would > cut out one roundtrip, but this is not allowed by the spec (it > says "all other payloads unchanged", which includes KEi). All payloads are unchanged in the first cookie exchange. The KEi was changed only after the INVALID_KE_PAYLOAD, but the difference was that we also kept the N(COOKIE) we have received before. As this was not reply to the N(COOKIE) request in the beginning. > So doing this is a violation of the spec, and leads to > interoperability problems if the responder includes KEi when > generating the cookie (which is clearly allowed by the current > spec). It is NOT violation of the spec. Show me the point where it says you are not allowed to include N(COOKIE) for the 2nd messaga. It does say that COOKIE MUST be inlucded in the IKE_SA_INIT request retry if one was received before. ---------------------------------------------------------------------- COOKIE 16390 This notification MAY be included in an IKE_SA_INIT response. It indicates that the request should be retried with a copy of this notification as the first payload. This notification MUST be included in an IKE_SA_INIT request retry if a COOKIE notification was included in the initial response. The data associated with this notification MUST be between 1 and 64 octets in length (inclusive). ---------------------------------------------------------------------- I would actually say not including the cookie in the request retries (i.e. the reply to the INVALID_KE_PAYLOAD is also retry of the IKE_SA_INIT request). Note, also that it is completely valid for the COOKIE to change along the exchange. That is expected to happen when the secret is changed, and if KE is included to the COOKIE that will also happen when the KE payload is changed. That is expected operation. > (I fully agree that your proposal makes much more sense, but > it's not what got written in the spec -- and IMHO it's way too > late to make technical changes now.) I disagree with your interpretation of the spec... Can you show me the place where it says that you are not allowed to include N(COOKIE) to the all retries IKE_SA_INIT messages? -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 21 10:36:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI5iT-0000Jr-L3; Wed, 21 Sep 2005 10:36:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI5iR-0000Jd-MD for ipsec@megatron.ietf.org; Wed, 21 Sep 2005 10:36:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA24862 for ; Wed, 21 Sep 2005 10:36:53 -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.43) id 1EI5oR-0003sr-Hw for ipsec@ietf.org; Wed, 21 Sep 2005 10:43:10 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8LEalOF031368; Wed, 21 Sep 2005 17:36:51 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Sep 2005 17:36:50 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Sep 2005 17:36:50 +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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] INVALID_KE_PAYLOAD and clarifications document Date: Wed, 21 Sep 2005 17:36:52 +0300 Message-ID: Thread-Topic: [Ipsec] INVALID_KE_PAYLOAD and clarifications document Thread-Index: AcW+swnOW9cM90luTMO/s6/5920DHAAA5CEg To: X-OriginalArrivalTime: 21 Sep 2005 14:36:50.0418 (UTC) FILETIME=[E7077520:01C5BEB9] X-Spam-Score: 0.3 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 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 Tero Kivinen wrote: > Where does it say it is required to work? The normal operation > is to use the SPIr that is set by the responder when he sets > it. Where is the exception to this case. Note, that responder > is supposed to be using SPIr zero, but this is the case where > he decided not to use SPIr zero. It's required to work, because the responder cannot distinguish=20 it from a completely new attempt to establish an IKE_SA. (Also, if you would send a non-zero SPIr, what Message ID do you use? If the responder is keeping state (and you agree to that), than that would imply incrementing the message ID... and if you don't increment it, then the text about Message IDs in=20 Section 2.2 is incorrect.) > I disagree with your interpretation of the spec... >=20 > Can you show me the place where it says that you are not allowed to > include N(COOKIE) to the all retries IKE_SA_INIT messages? The spec in general seems to follow the principle that it describes how the protocol works, but not how it doesn't. For instance, there's nothing saying that you're not allowed to include N(COOKIE) in the CREATE_CHILD_SA exchange. Nevertheless, I would not consider that to be part of the interoperable behavior defined by the specification. Thus, we're not looking for text saying "N(COOKIE) MUST NOT be included"; we're looking for text saying it is. Currently, what I see is text essentially saying "if the response contains a cookie, retry the request with the cookie and all other payloads unchanged". IMHO this would imply (even without an explicit "MUST NOT") that if the response doesn't contain a=20 cookie, you don't include it in the request either...? Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 21 11:18:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI6Md-0004UV-Qi; Wed, 21 Sep 2005 11:18:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI6Mb-0004UG-3m for ipsec@megatron.ietf.org; Wed, 21 Sep 2005 11:18:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27699 for ; Wed, 21 Sep 2005 11:18:20 -0400 (EDT) Received: from cod.sandelman.ca ([192.139.46.139] helo=lists.sandelman.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EI6SL-0005Fa-Kf for ipsec@ietf.org; Wed, 21 Sep 2005 11:24:38 -0400 Received: from sandelman.ottawa.on.ca ([216.191.74.170]) by lists.sandelman.ca (8.11.6p3/8.11.6) with ESMTP id j8LFHVB10735 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Wed, 21 Sep 2005 11:17:37 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 780E0E9989; Wed, 21 Sep 2005 07:29:45 -0400 (EDT) To: Tero Kivinen Subject: Re: [Ipsec] Clarification on error notifications, please In-Reply-To: Message from Tero Kivinen of "Mon, 19 Sep 2005 03:52:00 +0300." <17198.2992.152739.366114@fireball.kivinen.iki.fi> References: <496A8683261CD211BF6C0008C733261A0551C6A8@email.quarrytech.com> <17198.2992.152739.366114@fireball.kivinen.iki.fi> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 17) Date: Wed, 21 Sep 2005 07:29:45 -0400 Message-ID: <7681.1127302185@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: 0.7 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Cc: charliek@exchange.microsoft.com, 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 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Tero" == Tero Kivinen writes: >> To what messages do you refer to in the sentence "Such messages MUST NOT >> kill an SA"? Tero> I think he is refereing the AUTHENTICATION_FAILED notifies. Thus Tero> getting AUTHENTICATION_FAILED notify message before you have finished Tero> checking AUTH payloads MUST NOT kill an SA, which means they are Tero> ignored, so there is really no point of even seding them ever. Also I would disagree. I think that they are useful to send, and for the recipient to rate-limit log. It's a signal to "please fetch human". Tero> He might be refering the case of getting AUTHENTICATION_FAILED after Tero> the first AUTH payload has already be verified (i.e. when we have Tero> already authenticated the responder of the exchange). - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQzFEJYqHRg3pndX9AQF4mQQAocfZFRcPCtj+2fyOv9dfgGWb/cmb18gK juJwhcMGNALwysRa13S+YPP+mofD+V7vQyjpEnkh4MziYk/wBFlS1kUanVtl+U2s efU7kdLZZCJ4u1hn15ntEc4gDe2JKe4EMJ/Ys0SITRYUjw8Dir+aXPnMKsGji/EU QHzE7XBa9kE= =2m7O -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 21 12:03:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI74R-0007e8-MV; Wed, 21 Sep 2005 12:03:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI74Q-0007e3-4q for ipsec@megatron.ietf.org; Wed, 21 Sep 2005 12:03:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01193 for ; Wed, 21 Sep 2005 12:03:39 -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.43) id 1EI7AQ-0006jb-EC for ipsec@ietf.org; Wed, 21 Sep 2005 12:09:58 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j8LG2KGc007071 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Sep 2005 19:02:20 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j8LG2Jvw027006; Wed, 21 Sep 2005 19:02:19 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17201.33803.836034.35496@fireball.kivinen.iki.fi> Date: Wed, 21 Sep 2005 19:02:19 +0300 From: Tero Kivinen To: Pasi.Eronen@nokia.com Subject: RE: [Ipsec] INVALID_KE_PAYLOAD and clarifications document In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 13 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 Pasi.Eronen@nokia.com writes: > It's required to work, because the responder cannot distinguish > it from a completely new attempt to establish an IKE_SA. True. > (Also, if you would send a non-zero SPIr, what Message ID do > you use? If the responder is keeping state (and you agree to that), > than that would imply incrementing the message ID... and if you > don't increment it, then the text about Message IDs in > Section 2.2 is incorrect.) I am using Message ID 0, as it is IKE_SA_INIT. On the other hand I am trying to cope with the implementation which is doing something differently anyways, so I just try to be cope with it (I do assume he did have some reason I do not know, and he returned me SPIr because of he needs it). > The spec in general seems to follow the principle that it > describes how the protocol works, but not how it doesn't. For > instance, there's nothing saying that you're not allowed to > include N(COOKIE) in the CREATE_CHILD_SA exchange. Nevertheless, > I would not consider that to be part of the interoperable > behavior defined by the specification. N(COOKIE) payloads are allowed in CREATE_CHILD_SA exchanges too. On the other hand there is no requirement for the other end to copy them back in any places. Notify payloads are specifically allowed anywhere: ---------------------------------------------------------------------- A Notify Payload may appear in a response message (usually specifying why a request was rejected), in an INFORMATIONAL Exchange (to report an error not in an IKE request), or in any other message to indicate sender capabilities or to modify the meaning of the request. ---------------------------------------------------------------------- > Thus, we're not looking for text saying "N(COOKIE) MUST NOT be > included"; we're looking for text saying it is. The text which says it must be replied to IKE_SA_INIT if it was returned by the responder, do apply for later IKE_SA_INITs too. So I would say it is mandatory to include it in all IKE_SA_INIT messages if responder gave it to you based on the "This notification MUST be included in an IKE_SA_INIT request retry if a COOKIE notification was included in the initial response.". > Currently, what I see is text essentially saying "if the response > contains a cookie, retry the request with the cookie and all > other payloads unchanged". COOKIE description I quoted above is quite clear saying it must be included in an IKE_SA_INIT request retry, and it does not say it should be only limited to the first retry. > IMHO this would imply (even without an explicit "MUST NOT") that if > the response doesn't contain a cookie, you don't include it in the > request either...? But the "initial response" did include the ocokie, and we are retrying that exchange, thus we MUST include it... -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Sep 21 12:05:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI75s-0007wT-Jk; Wed, 21 Sep 2005 12:05:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EI75q-0007wL-JC for ipsec@megatron.ietf.org; Wed, 21 Sep 2005 12:05:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01279 for ; Wed, 21 Sep 2005 12:05:08 -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.43) id 1EI7Bt-0006mY-Vc for ipsec@ietf.org; Wed, 21 Sep 2005 12:11:26 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j8LG3nGu024429 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Sep 2005 19:03:49 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j8LG3mjk010512; Wed, 21 Sep 2005 19:03:48 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17201.33892.693386.721129@fireball.kivinen.iki.fi> Date: Wed, 21 Sep 2005 19:03:48 +0300 From: Tero Kivinen To: Michael Richardson Subject: Re: [Ipsec] Clarification on error notifications, please In-Reply-To: <7681.1127302185@marajade.sandelman.ottawa.on.ca> References: <496A8683261CD211BF6C0008C733261A0551C6A8@email.quarrytech.com> <17198.2992.152739.366114@fireball.kivinen.iki.fi> <7681.1127302185@marajade.sandelman.ottawa.on.ca> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 0 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Content-Transfer-Encoding: 7bit Cc: charliek@exchange.microsoft.com, 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 Michael Richardson writes: > I think that they are useful to send, and for the recipient to > rate-limit log. It's a signal to "please fetch human". I agree in that there is some use for sending them, but I still think the responder MUST NOT act based on them... -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Sep 22 11:32:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIT3k-0000aD-MN; Thu, 22 Sep 2005 11:32:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIT3i-0000a7-DY for ipsec@megatron.ietf.org; Thu, 22 Sep 2005 11:32:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07002 for ; Thu, 22 Sep 2005 11:32:24 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EIT9x-0004EY-Fv for ipsec@ietf.org; Thu, 22 Sep 2005 11:38:54 -0400 Received: (qmail 7204 invoked by uid 0); 22 Sep 2005 15:32:20 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.133.5) by woodstock.binhost.com with SMTP; 22 Sep 2005 15:32:20 -0000 Message-Id: <6.2.1.2.2.20050922112954.06cddd40@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 22 Sep 2005 11:32:04 -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.2 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Subject: [Ipsec] Authentication of DHCP Relay Agent Options Using 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 The following document is on the agenda for the IESG telechat next week for approval as a Proposed Standard. I would appreciate review from the members of this mail list in the next week. Authentication of DHCP Relay Agent Options Using IPsec draft-ietf-dhc-relay-agent-ipsec-02.txt Thanks, Russ _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 23 06:58:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIlGR-00014o-Rs; Fri, 23 Sep 2005 06:58:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIlGQ-00014j-8c for ipsec@megatron.ietf.org; Fri, 23 Sep 2005 06:58:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07364 for ; Fri, 23 Sep 2005 06:58:43 -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.43) id 1EIlMo-0002wd-CA for ipsec@ietf.org; Fri, 23 Sep 2005 07:05:24 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8NAweh6030091; Fri, 23 Sep 2005 13:58:41 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Sep 2005 13:58:40 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Sep 2005 13:58:38 +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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Clarification on error notifications, please Date: Fri, 23 Sep 2005 13:58:42 +0300 Message-ID: Thread-Topic: [Ipsec] Clarification on error notifications, please Thread-Index: AcW+xpTgy+mkO4f8QYmayrC9txC6ggBZEjYg To: X-OriginalArrivalTime: 23 Sep 2005 10:58:38.0776 (UTC) FILETIME=[C0A0EB80:01C5C02D] X-Spam-Score: 0.3 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 What exactly do you mean by "MUST NOT act based on them"? For instance, if the authentication of the initiator fails (e.g. responder doesn't like the certificate), I think the=20 exchange would look something like this: 1. HDR, SAi1, KEi, Ni --> <-- 2. HDR, SAr1, KEr, Nr 3. HDR, SK { IDi, CERT, AUTH, SAi2, TSi, TSr } --> <-- 4. HDR, SK { N(AUTHENTICATION_FAILED) } What exactly should the initiator do after it receives messsage 4? ("Doing nothing" is not an option) IMHO the sensible action would be to log an error (maybe), terminate=20 this IKE_SA, and if the initiator is really concerned about DoS attacks, maybe try again from the start a couple of times. The option "pretend that we didn't receive message 4 at all=20 (=3Dcontinue retransmitting message 3)" doesn't make any sense, because the message had a valid MAC, and there's no way the initiator is=20 going to receive a different message 4 with valid MAC. ...unless it also receives a different message 2, that is (perhaps the attacker was faster than the real responder in replying to message 1). In this case, receiving AUTHENTICATION_FAILED could sort of "roll back" the state to the situation where we've just sent message 1 (so the initiator would continue retransmitting message 1 in a hope that it gets a different message 2 back). But this gets quite complicated, and I'm not totally convinced of its usefulness... Best regards, Pasi=20 > -----Original Message----- > From: Tero Kivinen > Sent: 21 September, 2005 19:04 > To: Michael Richardson > Cc: charliek@exchange.microsoft.com; ipsec@ietf.org > Subject: Re: [Ipsec] Clarification on error notifications, please=20 >=20 > Michael Richardson writes: > > I think that they are useful to send, and for the recipient to > > rate-limit log. It's a signal to "please fetch human". >=20 > I agree in that there is some use for sending them, but I still think > the responder MUST NOT act based on them... > --=20 > kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 23 08:24:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EImb0-0004vr-7f; Fri, 23 Sep 2005 08:24:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EImay-0004u2-Ib for ipsec@megatron.ietf.org; Fri, 23 Sep 2005 08:24:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA11281 for ; Fri, 23 Sep 2005 08:24:03 -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.43) id 1EImhO-00055Z-1s for ipsec@ietf.org; Fri, 23 Sep 2005 08:30:43 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8NCNx03002739; Fri, 23 Sep 2005 15:24:01 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Sep 2005 15:23:58 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 23 Sep 2005 15:23: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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] INVALID_KE_PAYLOAD and clarifications document Date: Fri, 23 Sep 2005 15:23:56 +0300 Message-ID: Thread-Topic: [Ipsec] INVALID_KE_PAYLOAD and clarifications document Thread-Index: AcW+xiI80WVJi5ShSbWXobWTnTiLDQBceYig To: X-OriginalArrivalTime: 23 Sep 2005 12:23:57.0348 (UTC) FILETIME=[AB890640:01C5C039] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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 Tero Kivinen: > I am using Message ID 0, as it is IKE_SA_INIT. On the other hand I > am trying to cope with the implementation which is doing something > differently anyways, so I just try to be cope with it (I do assume > he did have some reason I do not know, and he returned me SPIr > because of he needs it). IMHO you should assume the reason is an implementation bug; if the other end really needs it (doesn't work just fine if you send 0), it's not compliant with the IKEv2 spec anyway. While in general coping the implementation quirks is a good thing, it can also lead to a situation where implementators learn to expect that the other end does this, and gradually the "de-facto protocol" drifts away from what was actually written in the spec. Here "be liberal in what you receive but conservative in what you send" principle would IMHO tell that you don't fail if you receive something else than zero, but you always send zero. > > The spec in general seems to follow the principle that it > > describes how the protocol works, but not how it doesn't. For > > instance, there's nothing saying that you're not allowed to > > include N(COOKIE) in the CREATE_CHILD_SA exchange. Nevertheless, > > I would not consider that to be part of the interoperable > > behavior defined by the specification. >=20 > N(COOKIE) payloads are allowed in CREATE_CHILD_SA exchanges too. On > the other hand there is no requirement for the other end to copy them > back in any places.=20 In other words, the specification doesn't say what including N(COOKIE) in CREATE_CHILD_SA exchange "means". Thus if some party expects it to mean something, it's not following the IKEv2 base specification (but this might be specified in some future extension). > The text which says it must be replied to IKE_SA_INIT if it was > returned by the responder, do apply for later IKE_SA_INITs too. So I > would say it is mandatory to include it in all IKE_SA_INIT messages > if responder gave it to you based on the "This notification MUST be > included in an IKE_SA_INIT request retry if a COOKIE notification > was included in the initial response.". Hmm... maybe it could be interpreted that way too; but then it needs=20 to be clarified that COOKIE calculation cannot expect "all other=20 payloads unchanged" to apply to all requests that include the COOKIE. I'll try to write some text for the clarifications draft about this... (but it seems that in IKEv2, one of the main security=20 features is "job security", for those trying to interprete and=20 clarify the spec :-) Cheers, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 23 09:03:06 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EInCk-0006Fi-MA; Fri, 23 Sep 2005 09:03:06 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EInCi-0006Eq-Bi for ipsec@megatron.ietf.org; Fri, 23 Sep 2005 09:03:04 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12944 for ; Fri, 23 Sep 2005 09:03:03 -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.43) id 1EInJ9-00060h-I0 for ipsec@ietf.org; Fri, 23 Sep 2005 09:09:44 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j8ND1YHK027685 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Sep 2005 16:01:34 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j8ND1YWn021158; Fri, 23 Sep 2005 16:01:34 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17203.64686.355322.992569@fireball.kivinen.iki.fi> Date: Fri, 23 Sep 2005 16:01:34 +0300 From: Tero Kivinen To: Pasi.Eronen@nokia.com Subject: RE: [Ipsec] Clarification on error notifications, please In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 32 min X-Total-Time: 35 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 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 Pasi.Eronen@nokia.com writes: > What exactly do you mean by "MUST NOT act based on them"? > > For instance, if the authentication of the initiator fails > (e.g. responder doesn't like the certificate), I think the > exchange would look something like this: > > 1. HDR, SAi1, KEi, Ni --> > <-- 2. HDR, SAr1, KEr, Nr > 3. HDR, SK { IDi, CERT, AUTH, SAi2, TSi, TSr } --> > <-- 4. HDR, SK { N(AUTHENTICATION_FAILED) } > > What exactly should the initiator do after it receives messsage 4? > ("Doing nothing" is not an option) > > IMHO the sensible action would be to log an error (maybe), terminate > this IKE_SA, and if the initiator is really concerned about DoS > attacks, maybe try again from the start a couple of times. He should probably log it, but I would say he should otherwise ignore the packet (or use it as hint), and continue trying until it times out, or after the policy is modified. The IKEv2 draft is quite clear about that (section 2.21): A node receiving such an unprotected Notify payload MUST NOT respond and MUST NOT change the state of any existing SAs. The message might be a forgery or might be a response the genuine correspondent was tricked into sending. A node SHOULD treat such a message (and also a network message like ICMP destination unreachable) as a hint that there might be problems with SAs to that IP address and SHOULD initiate a liveness test for any such IKE_SA. An implementation SHOULD limit the frequency of such tests to avoid being tricked into participating in a denial of service attack. Before we have processed the other ends AUTH payload the notifies are unprotected, as we do not know who the other end is. So the only option draft really gives you is to use it as a hint (i.e. you can log it, and you can perhaps make you time out faster, and limit the number of retranmissions). > The option "pretend that we didn't receive message 4 at all > (=continue retransmitting message 3)" doesn't make any sense, because > the message had a valid MAC, and there's no way the initiator is > going to receive a different message 4 with valid MAC. Currently people doing that have another problem. They do not rete limit the IKE SA requests they are sending. I.e. they fail immediately when they receive the AUTHENTICATION_FAILED, and the delete IKE SA and for the next ping packet or so they trigger again, and start to recreate the IKE SA again, thus going to endless loop of renegotiations without rate limits. To cope with that problem they need to add separate rate limiter. If they would do the normal timing out of the IKE SA that would act as a nice rate limiter automatically. I.e. they would not fail the negotiation so quickly, they would wait for the timeout before it fails, and then they could restart the exchange, and do those retries only every few minutes after each timeout. AUTHENTICATION_FAILED will not normally disappear without user interaction. There are few cases where that can happen (network to the OCSP/LDAP etc server was down and is now up again), but usually those takes also some minutes to do, so retrying every second is not really usefull in those cases. > ...unless it also receives a different message 2, that is (perhaps > the attacker was faster than the real responder in replying to > message 1). In this case, receiving AUTHENTICATION_FAILED could > sort of "roll back" the state to the situation where we've > just sent message 1 (so the initiator would continue retransmitting > message 1 in a hope that it gets a different message 2 back). > But this gets quite complicated, and I'm not totally convinced > of its usefulness... That mechanism is defined in the draft, so you MAY implement it and in that case you do want to ignore the AUTHENTICATION_FAILED messages. Also I agree that in AUTHENTICATION_FAILED is probably one of those notifies that you could act based on unauthenticated notifies, but in general the IKE SA is only authenticated after we have done the AUTH processing, and before that it is not authenticated, and all notifies before that are unauthenticated, and the IKEv2 draft do not point out some errors as special case which you can act on based on unauthenticated information. You can use them as hints, you MUST NOT change the state of any existing SA. I would consider tearing down the IKE SA in process of being created as changing state of an SA, thus actually violating the spec. I do not think this is so important feature that we would need to start pulling back IKE draft and start making modifications because of that. Also I do not think we can change MUST NOT of the IKEv2 draft in the clarification draft. So lets live with this and continue working with the draft we have. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 23 09:19:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EInSO-0001G6-FG; Fri, 23 Sep 2005 09:19:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EInSG-0001Av-Tx for ipsec@megatron.ietf.org; Fri, 23 Sep 2005 09:19:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13607 for ; Fri, 23 Sep 2005 09:19:07 -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.43) id 1EInYi-0006NS-7A for ipsec@ietf.org; Fri, 23 Sep 2005 09:25:48 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j8NDHm0r025942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Sep 2005 16:17:48 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j8NDHmf2006804; Fri, 23 Sep 2005 16:17:48 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17204.124.429081.300975@fireball.kivinen.iki.fi> Date: Fri, 23 Sep 2005 16:17:48 +0300 From: Tero Kivinen To: Subject: RE: [Ipsec] INVALID_KE_PAYLOAD and clarifications document In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 13 min X-Total-Time: 13 min X-Spam-Score: 0.0 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a 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 Pasi.Eronen@nokia.com writes: > Tero Kivinen: > > > I am using Message ID 0, as it is IKE_SA_INIT. On the other hand I > > am trying to cope with the implementation which is doing something > > differently anyways, so I just try to be cope with it (I do assume > > he did have some reason I do not know, and he returned me SPIr > > because of he needs it). > > IMHO you should assume the reason is an implementation bug; if the > other end really needs it (doesn't work just fine if you send 0), > it's not compliant with the IKEv2 spec anyway. Unfortunately the spec can be interpreted two ways there. The text in 3.1 says: o Responder's SPI (8 octets) - A value chosen by the responder to identify a unique IKE security association. This value MUST be zero in the first message of an IKE Initial Exchange (including repeats of that message including a cookie) and MUST NOT be zero in any other message. which says that it MUST be zero for the cookie request. It does not clearly say what should be used for the invalid ke payload. In the COOKIE notifies there is similar text in 3.10.1: COOKIE 16390 This notification MAY be included in an IKE_SA_INIT response. It indicates that the request should be retried with a copy of this notification as the first payload. This notification MUST be included in an IKE_SA_INIT request retry if a COOKIE notification was included in the initial response. The data associated with this notification MUST If I have understood correctly, you interpret the text in 3.1 include all IKE_SA_INIT packets (not just cookie retry), but you interpreted the 3.10.1 you interpreted it to include only the first retry (only the cookie retry). I think we should interpret both of those texts to include all IKE_SA_INIT retries, i.e both COOKIE and INVALID_KE_PAYLOAD retries. I.e. SPIr MUST be zero for all of IKE_SA_INIT replies, and COOKIE must be included by the initiator to the all the retries of the IKE_SA_INIT after it was first returned by the responder to the initiator. > While in general coping the implementation quirks is a good thing, it > can also lead to a situation where implementators learn to expect that > the other end does this, and gradually the "de-facto protocol" drifts > away from what was actually written in the spec. Here "be liberal in > what you receive but conservative in what you send" principle would > IMHO tell that you don't fail if you receive something else than zero, > but you always send zero. There might be reason for the responder to allocate state in the invalid ke payload, thus he might want to allocate SPIr for that. The general text there in 2.6 says: initial two eight octet fields in the header are used as a connection identifier at the beginning of IKE packets. Each endpoint chooses one of the two SPIs and SHOULD choose them so as to be unique identifiers of an IKE_SA. An SPI value of zero is special and indicates that the remote SPI value is not yet known by the sender. which would indicate that if the initiator do know the remote SPI (SPIr), he should use it. I.e. if the responder have returned SPIr to initiator, then initiator cannot claim he do not know it and he wants to use zero because of that. That text would indicate that if the responder do return SPIr in the COOKIE/INVALID_KE_PAYLOAD (against the MUST in the document), then initiator should then use that same value when sending next packet. But if consider the text in 3.1 to cover all IKE_SA_INIT messages, then this MUST NOT happen in any valid implementation of the draft, it will not really matter what initiator does in that case :-) > In other words, the specification doesn't say what including N(COOKIE) > in CREATE_CHILD_SA exchange "means". Thus if some party expects it to > mean something, it's not following the IKEv2 base specification (but > this might be specified in some future extension). Yes. > > > The text which says it must be replied to IKE_SA_INIT if it was > > returned by the responder, do apply for later IKE_SA_INITs too. So I > > would say it is mandatory to include it in all IKE_SA_INIT messages > > if responder gave it to you based on the "This notification MUST be > > included in an IKE_SA_INIT request retry if a COOKIE notification > > was included in the initial response.". > > Hmm... maybe it could be interpreted that way too; but then it needs > to be clarified that COOKIE calculation cannot expect "all other > payloads unchanged" to apply to all requests that include the COOKIE. All other payloads were returned unchanged for the first reply, but not for the later requests, as he did himself request the initiator to do some changes. > I'll try to write some text for the clarifications draft about > this... (but it seems that in IKEv2, one of the main security > features is "job security", for those trying to interprete and > clarify the spec :-) Good for us... :-) -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 23 12:45:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIqfg-0002eQ-QP; Fri, 23 Sep 2005 12:45:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIqfe-0002eI-R1 for ipsec@megatron.ietf.org; Fri, 23 Sep 2005 12:45:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24519 for ; Fri, 23 Sep 2005 12:45:08 -0400 (EDT) Received: from web80603.mail.yahoo.com ([66.218.79.92]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EIqm2-0002tu-Nj for ipsec@ietf.org; Fri, 23 Sep 2005 12:51:52 -0400 Received: (qmail 83812 invoked by uid 60001); 23 Sep 2005 16:44:49 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=VxFoEidUfo5pVVcyi2nVohTqhftLt8rwoKDFVKp47q7/Oslxf5C+bWfZgM/JTh5fjpx5V25KZV0BGajuRU1Mbl47lNfa9KXM+rNpNmq7hKqTNbnh/NzmJPkGQolTXbbCeHdqLVjrNWysl0AseV4x7zDnthsHs1m8yO1jc3pHbPE= ; Message-ID: <20050923164449.83810.qmail@web80603.mail.yahoo.com> Received: from [206.132.194.2] by web80603.mail.yahoo.com via HTTP; Fri, 23 Sep 2005 09:44:49 PDT Date: Fri, 23 Sep 2005 09:44:49 -0700 (PDT) From: Mohan Parthasarathy Subject: RE: [Ipsec] Clarification on error notifications, please To: Tero Kivinen , Pasi.Eronen@nokia.com In-Reply-To: <17203.64686.355322.992569@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93e7fb8fef2e780414389440f367c879 Content-Transfer-Encoding: 8bit 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 > > A node receiving such an unprotected Notify > payload MUST NOT > respond and MUST NOT change the state of any > existing SAs. The > message might be a forgery or might be a response > the genuine > correspondent was tricked into sending. A node > SHOULD treat such a > message (and also a network message like ICMP > destination > unreachable) as a hint that there might be > problems with SAs to > that IP address and SHOULD initiate a liveness > test for any such > IKE_SA. An implementation SHOULD limit the > frequency of such tests > to avoid being tricked into participating in a > denial of service > attack. > > Before we have processed the other ends AUTH payload > the notifies are > unprotected, as we do not know who the other end is. > The draft uses the word unprotected in a few other places. I guess this meaning would make sense only in this context i guess. Mostly, unprotected means "packets that don't have cryptographic protection". Perhaps, the above should be changed to "unauthenticated". > So the only > option draft really gives you is to use it as a hint > (i.e. you can log > it, and you can perhaps make you time out faster, > and limit the number > of retranmissions). > > > The option "pretend that we didn't receive message > 4 at all > > (=continue retransmitting message 3)" doesn't make > any sense, because > > the message had a valid MAC, and there's no way > the initiator is > > going to receive a different message 4 with valid > MAC. > > Currently people doing that have another problem. > They do not rete > limit the IKE SA requests they are sending. I.e. > they fail immediately > when they receive the AUTHENTICATION_FAILED, and the > delete IKE SA and > for the next ping packet or so they trigger again, > and start to > recreate the IKE SA again, thus going to endless > loop of > renegotiations without rate limits. To cope with > that problem they > need to add separate rate limiter. > This is given in section 2.4: Since IKE is designed to operate in spite of Denial of Service (DoS) attacks from the network, an endpoint MUST NOT conclude that the other endpoint has failed based on any routing information (e.g., ICMP messages) or IKE messages that arrive without cryptographic protection (e.g., Notify messages complaining about unknown SPIs)...... Implementations MUST limit the rate at which they take actions based on unprotected messages. So, the draft is very clear on this. > If they would do the normal timing out of the IKE SA > that would act as > a nice rate limiter automatically. I.e. they would > not fail the > negotiation so quickly, they would wait for the > timeout before it > fails, and then they could restart the exchange, and > do those retries > only every few minutes after each timeout. > > AUTHENTICATION_FAILED will not normally disappear > without user > interaction. There are few cases where that can > happen (network to the > OCSP/LDAP etc server was down and is now up again), > but usually those > takes also some minutes to do, so retrying every > second is not really > usefull in those cases. > Retry a few times and stop. The user would retry once more but eventually he stops. This happens in lot of cases today. > > You can use them as hints, you MUST NOT change the > state of any > existing SA. I would consider tearing down the IKE > SA in process of > being created as changing state of an SA, thus > actually violating the > spec. > > I do not think this is so important feature that we > would need to > start pulling back IKE draft and start making > modifications because of > that. Also I do not think we can change MUST NOT of > the IKEv2 draft in > the clarification draft. > I still think the implementation can do either way in this case. -mohan > So lets live with this and continue working with the > draft we have. > -- > 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 Fri Sep 23 12:55:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIqq6-0005Bj-Ox; Fri, 23 Sep 2005 12:55:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIqq1-00059d-Ou for ipsec@megatron.ietf.org; Fri, 23 Sep 2005 12:55:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25098 for ; Fri, 23 Sep 2005 12:55:51 -0400 (EDT) Received: from web80603.mail.yahoo.com ([66.218.79.92]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EIqwU-0003D3-Rj for ipsec@ietf.org; Fri, 23 Sep 2005 13:02:35 -0400 Received: (qmail 85208 invoked by uid 60001); 23 Sep 2005 16:55:43 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=B2WV+5MqBdUoolvpT+P0s0vETJpRfPlfOhYSEyS/tMaKTFW34iaAMcqo+JnYTtBlP9NBGoTVvpMTtudpLkvlDFrimI9ZfSjE1Urcz8MvoghA3CxJcu33rjLVBp/Ygiwdke07WAfBEBGHYaa80z2DQdFsKu549XMOwnX+xsbeuug= ; Message-ID: <20050923165543.85206.qmail@web80603.mail.yahoo.com> Received: from [206.132.194.2] by web80603.mail.yahoo.com via HTTP; Fri, 23 Sep 2005 09:55:43 PDT Date: Fri, 23 Sep 2005 09:55:43 -0700 (PDT) From: Mohan Parthasarathy Subject: RE: [Ipsec] INVALID_KE_PAYLOAD and clarifications document To: Tero Kivinen , Pasi.Eronen@nokia.com In-Reply-To: <17204.124.429081.300975@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Content-Transfer-Encoding: 8bit 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 > > > While in general coping the implementation quirks > is a good thing, it > > can also lead to a situation where implementators > learn to expect that > > the other end does this, and gradually the > "de-facto protocol" drifts > > away from what was actually written in the spec. > Here "be liberal in > > what you receive but conservative in what you > send" principle would > > IMHO tell that you don't fail if you receive > something else than zero, > > but you always send zero. > > There might be reason for the responder to allocate > state in the > invalid ke payload, thus he might want to allocate > SPIr for that. > Is there a valid reason as to why the responder would allocate state in the invalid KE payload case ? The responder can do anything :-) But coping for all this makes it more complicated. > The general text there in 2.6 says: > > initial two eight octet fields in the header are > used as a > connection identifier at the beginning of IKE > packets. Each > endpoint chooses one of the two SPIs and SHOULD > choose them so as > to be unique identifiers of an IKE_SA. An SPI > value of zero is > special and indicates that the remote SPI value > is not yet known by > the sender. > > which would indicate that if the initiator do know > the remote SPI > (SPIr), he should use it. I.e. if the responder have > returned SPIr to > initiator, then initiator cannot claim he do not > know it and he wants > to use zero because of that. That text would > indicate that if the > responder do return SPIr in the > COOKIE/INVALID_KE_PAYLOAD (against the > MUST in the document), then initiator should then > use that same value > when sending next packet. > > But if consider the text in 3.1 to cover all > IKE_SA_INIT messages, > then this MUST NOT happen in any valid > implementation of the draft, it > will not really matter what initiator does in that > case :-) > I think the clarification draft should just clarify that the cookie case and invalid ke payload case should be treated the same way unless there is a *real* convincing reason that the responder wants to allocate state for invalid ke payload. -mohan _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 23 13:32:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIrPI-00065C-NK; Fri, 23 Sep 2005 13:32:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIrPG-000650-W4 for ipsec@megatron.ietf.org; Fri, 23 Sep 2005 13:32:19 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26413 for ; Fri, 23 Sep 2005 13:32:16 -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.43) id 1EIrVj-00042v-JY for ipsec@ietf.org; Fri, 23 Sep 2005 13:39:01 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j8NHUs2X014996 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 23 Sep 2005 20:30:54 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j8NHUsgB019881; Fri, 23 Sep 2005 20:30:54 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17204.15310.424320.512841@fireball.kivinen.iki.fi> Date: Fri, 23 Sep 2005 20:30:54 +0300 From: Tero Kivinen To: Mohan Parthasarathy Subject: RE: [Ipsec] INVALID_KE_PAYLOAD and clarifications document In-Reply-To: <20050923165543.85206.qmail@web80603.mail.yahoo.com> References: <17204.124.429081.300975@fireball.kivinen.iki.fi> <20050923165543.85206.qmail@web80603.mail.yahoo.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 6 min X-Total-Time: 6 min X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 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 Mohan Parthasarathy writes: > Is there a valid reason as to why the responder would > allocate state in the invalid KE payload case ? Hmm.. not that I can think of right now. Someone might think something later, for example allocate some crypto resources for the coming diffie-hellman calculation or something, but I do not think we need to think about that now. > The responder can do anything :-) But coping for all this makes it > more complicated. Actually at least for me the copying comes automatically. Immediately wen we receive a message having SPIr set we update the current SA to have that SPIr. Then we continue processing the packet and if we notice that it was INVALID_KE_PAYLOAD we retry with new group. In the responder end I do allocate SPIr when I get the packet in, but then when sending the error message back (COOKIE or INVALID_KE_PAYLOAD) I clear up the SPIr before sending the error, and after that I delete the state I created to be able to process the request. I could do same thing in the initiator i.e. when I notice that I need to restart from the beginning, but it requires more stuff there as I need to downgrade the SA back to the half-open state if it was already upgraded to have SPIr. Thats why I am not likely going to do it just to cope with some buggy implementations on the other end, unless those buggy implementations start to be more common... > I think the clarification draft should just clarify > that the cookie case and invalid ke payload case > should be treated the same way unless there is a > *real* convincing reason that the responder wants to > allocate state for invalid ke payload. I agree. I think the clarification document should say that use SPIr of zero every time when responding with those notifies. I think that clarification does not really need to specify what the other end should do in case the responder does not follow that recommendation (i.e. I do not think we need to specify how to cope around bugs in other implementations). -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 23 14:42:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIsUt-0005Cb-MI; Fri, 23 Sep 2005 14:42:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EIsUr-0005CW-Tu for ipsec@megatron.ietf.org; Fri, 23 Sep 2005 14:42:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29352 for ; Fri, 23 Sep 2005 14:42:08 -0400 (EDT) Received: from web80604.mail.yahoo.com ([66.218.79.93]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EIsbB-0005cK-9G for ipsec@ietf.org; Fri, 23 Sep 2005 14:48:52 -0400 Received: (qmail 92964 invoked by uid 60001); 23 Sep 2005 18:41:48 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=sbcglobal.net; h=Message-ID:Received:Date:From:Subject:To:Cc:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=weYUrNFCAtW3t6/zFtgiUeLO7NLQoxSd7KtRx9Kh/qvlTvNPiS0p6g22ZvDgej8/n21iDlptcxXQ2tku8Xn9VMD7UsHS9a8tlUbtVOcUodagGxaad1ZtXfC6C5Q2Bu4sAdwT3g4vJ2esxqMACJrENorZHnHgt/0SrLpOGspmMLM= ; Message-ID: <20050923184148.92962.qmail@web80604.mail.yahoo.com> Received: from [206.132.194.2] by web80604.mail.yahoo.com via HTTP; Fri, 23 Sep 2005 11:41:48 PDT Date: Fri, 23 Sep 2005 11:41:48 -0700 (PDT) From: Mohan Parthasarathy Subject: RE: [Ipsec] INVALID_KE_PAYLOAD and clarifications document To: Tero Kivinen In-Reply-To: <17204.15310.424320.512841@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 8bit 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 > > > The responder can do anything :-) But coping for > all this makes it > > more complicated. > > Actually at least for me the copying comes > automatically. Immediately > wen we receive a message having SPIr set we update > the current SA to > have that SPIr. Then we continue processing the > packet and if we > notice that it was INVALID_KE_PAYLOAD we retry with > new group. > My implementation assumes that one has to retry if SPIr is zero and it is IKE_SA_INIT response. I need to do this check to reset my msgid to zero so that the next packet goes out with the right msgid. > In the responder end I do allocate SPIr when I get > the packet in, but > then when sending the error message back (COOKIE or > INVALID_KE_PAYLOAD) I clear up the SPIr before > sending the error, and > after that I delete the state I created to be able > to process the > request. > In the responder, i don't allocate SPIr until both cookie and KE payload checks are successful. > > I think the clarification draft should just > clarify > > that the cookie case and invalid ke payload case > > should be treated the same way unless there is a > > *real* convincing reason that the responder wants > to > > allocate state for invalid ke payload. > > I agree. I think the clarification document should > say that use SPIr > of zero every time when responding with those > notifies. > > I think that clarification does not really need to > specify what the > other end should do in case the responder does not > follow that > recommendation (i.e. I do not think we need to > specify how to cope > around bugs in other implementations). Agreed. -mohan > -- > 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 Mon Sep 26 00:06:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJkFf-00061a-Sj; Mon, 26 Sep 2005 00:06:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJkFe-00060u-1l for ipsec@megatron.ietf.org; Mon, 26 Sep 2005 00:06:02 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18818 for ; Mon, 26 Sep 2005 00:05:58 -0400 (EDT) Received: from cod.sandelman.ca ([192.139.46.139] helo=lists.sandelman.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJkMb-0008Il-4k for ipsec@ietf.org; Mon, 26 Sep 2005 00:13:14 -0400 Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lists.sandelman.ca (8.11.6p3/8.11.6) with ESMTP id j8Q45g809182 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK) for ; Mon, 26 Sep 2005 00:05:48 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 461CEE9951 for ; Mon, 26 Sep 2005 00:05:12 -0400 (EDT) From: "Michael Richardson" To: ipsec@ietf.org X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 17) Date: Mon, 26 Sep 2005 00:05:12 -0400 Message-ID: <11420.1127707512@marajade.sandelman.ottawa.on.ca> X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Ipsec] certificate payloads/requests 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 -----BEGIN PGP SIGNED MESSAGE----- Is it permissible to send a certificate payload or certificate request when the authentication method is PSK? It is forbidden? I don't ask for any reason. I just changed some code in IKEv1 to log the reason for not sending a certificate as being because, we are using PSK. - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQzdzdYqHRg3pndX9AQFSvAP9HtT/R0yAWJ7LZUXq2QQwSr05gDSgH+2R rvtEOftBsv7Ee/3oCiMXeHW0zsDkg8xTtmCyZQHcVQmescETTuvxUvLBVAqGqCls cu0aIuD4vMz2aAF4IB4c45OqDlJJtj+Bt7MgAh9S/4Q2/EH9/WSh5yDARL17AwdA rcMM/LLJBlA= =3HtA -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 26 05:10:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJp0K-0006Zf-RN; Mon, 26 Sep 2005 05:10:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJp0J-0006ZH-9N for ipsec@megatron.ietf.org; Mon, 26 Sep 2005 05:10:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13331 for ; Mon, 26 Sep 2005 05:10:21 -0400 (EDT) Received: from xproxy.gmail.com ([66.249.82.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJp7B-0006S5-L1 for ipsec@ietf.org; Mon, 26 Sep 2005 05:17:38 -0400 Received: by xproxy.gmail.com with SMTP id t14so999813wxc for ; Mon, 26 Sep 2005 02:10:06 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=DZUetRzhuPMhf6SiiTXplBg//WC5BTGDretfQqFDwmyhNvV5k94/d4vJY8aXZlKCTYGO1SZ+rVPOj4P5cntiUYgl7Y66utJLDvvwjwXazYGtg1hddQtluFWqhHCiLbDApy5S31NvHfjHD28JXtliqkjPXRzDWj4QOasgtwnI5QA= Received: by 10.70.34.10 with SMTP id h10mr2121625wxh; Mon, 26 Sep 2005 02:10:06 -0700 (PDT) Received: from ?192.168.2.190? ( [84.121.24.204]) by mx.gmail.com with ESMTP id i18sm1963410wxd.2005.09.26.02.10.05; Mon, 26 Sep 2005 02:10:06 -0700 (PDT) From: Alejandro Perez Mendez To: ipsec@ietf.org Content-Type: text/plain; charset=UTF-8 Date: Mon, 26 Sep 2005 11:10:04 +0200 Message-Id: <1127725804.16774.10.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id FAA13331 Subject: [Ipsec] Invalid Cookie 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 need some clarifications about cookies, please. What is the spected behaviour when an invalid cookie is received? There are three options: a) Omit request until initiator spend all its retransmitions. b) Send the correct cookie to the initiator.=20 c) Ban the source IP address for a time to avoid DoS attacks. I think the most adequate option is c) or a) adequate, because=20 b) whould falls in DoS attacks. Regards. Alejandro P=C3=A9rez Pedro J. Fern=C3=A1ndez _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 26 05:51:42 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJpeA-0004pD-QQ; Mon, 26 Sep 2005 05:51:42 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJpe7-0004o4-2N for ipsec@megatron.ietf.org; Mon, 26 Sep 2005 05:51:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA15140 for ; Mon, 26 Sep 2005 05:51:27 -0400 (EDT) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJpkt-0007Uo-9H for ipsec@ietf.org; Mon, 26 Sep 2005 05:58:45 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.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] Invalid Cookie Date: Mon, 26 Sep 2005 02:53:43 -0700 Message-ID: Thread-Topic: [Ipsec] Invalid Cookie Thread-Index: AcXCe0l+C4wJImBFRg+5dJdEEOWO8QAA3EvQ From: "Vishwas Manral" To: "Alejandro Perez Mendez" , X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 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 Alejandro, The IKE draft states that:- An IKE implementation SHOULD implement its responder cookie generation in such a way as to not require any saved state to recognize its valid cookie when the second IKE_SA_INIT message arrives. Also responder uses minimal CPU and commits no state=20 This would mean in case an unexpected cookie value is received, the = responder would just ignore the packet. I think option 3 would not help as an IP Address can be easily spoofed. Thanks, Vishwas -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf = Of Alejandro Perez Mendez Sent: Monday, September 26, 2005 2:40 PM To: ipsec@ietf.org Subject: [Ipsec] Invalid Cookie Hi. I need some clarifications about cookies, please. What is the spected behaviour when an invalid cookie is received? There are three options: a) Omit request until initiator spend all its retransmitions. b) Send the correct cookie to the initiator.=20 c) Ban the source IP address for a time to avoid DoS attacks. I think the most adequate option is c) or a) adequate, because=20 b) whould falls in DoS attacks. Regards. Alejandro P=E9rez Pedro J. Fern=E1ndez _______________________________________________ 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 Sep 26 06:15:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJq1V-0000Bd-Sq; Mon, 26 Sep 2005 06:15:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJq1R-0000BQ-Cg for ipsec@megatron.ietf.org; Mon, 26 Sep 2005 06:15:47 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16313 for ; Mon, 26 Sep 2005 06:15:42 -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.43) id 1EJq8R-000897-Et for ipsec@ietf.org; Mon, 26 Sep 2005 06:23:01 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j8QADsmQ011324 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Sep 2005 13:13:54 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j8QADpVg017453; Mon, 26 Sep 2005 13:13:51 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17207.51679.910627.276790@fireball.kivinen.iki.fi> Date: Mon, 26 Sep 2005 13:13:51 +0300 From: Tero Kivinen To: "Michael Richardson" Subject: [Ipsec] certificate payloads/requests in IKEv2 In-Reply-To: <11420.1127707512@marajade.sandelman.ottawa.on.ca> References: <11420.1127707512@marajade.sandelman.ottawa.on.ca> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 6 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 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 Michael Richardson writes: > Is it permissible to send a certificate payload or certificate request > when the authentication method is PSK? It is allowed both in IKEv1 and IKEv2. In IKEv1 certifiate and certificate request payloads are allowed in any packet, as long as they do not extend the basic exchange (i.e. certificate request cannot be in the last message sent by the responder, as initiator cannot answer to it). In the IKEv2 you do not even know what method the other end is going to use to authenticate himself, so you can include certificate requests there. The certificate payload says you SHOULD be included in an exchange if certificates are available to the sender... > It is forbidden? I do not think so. > I don't ask for any reason. I just changed some code in IKEv1 to log > the reason for not sending a certificate as being because, we are using > PSK. Not sending them when you have only PSK configured to the other end is probably preferred, as it makes the packets smaller (i.e. no fragmentation). -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 26 06:23:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJq90-000261-G0; Mon, 26 Sep 2005 06:23:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJq8y-00022j-OG for ipsec@megatron.ietf.org; Mon, 26 Sep 2005 06:23:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16686 for ; Mon, 26 Sep 2005 06:23:30 -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.43) id 1EJqG0-0008Kf-9T for ipsec@ietf.org; Mon, 26 Sep 2005 06:30:48 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id j8QAM20k015943 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Sep 2005 13:22:02 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id j8QAM1Km027928; Mon, 26 Sep 2005 13:22:01 +0300 (EEST) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17207.52169.884715.152568@fireball.kivinen.iki.fi> Date: Mon, 26 Sep 2005 13:22:01 +0300 From: Tero Kivinen To: Alejandro Perez Mendez Subject: [Ipsec] Invalid Cookie In-Reply-To: <1127725804.16774.10.camel@localhost.localdomain> References: <1127725804.16774.10.camel@localhost.localdomain> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 6 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 Alejandro Perez Mendez writes: > Hi. I need some clarifications about cookies, please. > What is the spected behaviour when an invalid cookie is received? > > There are three options: > a) Omit request until initiator spend all its retransmitions. Note, that there are valid cases when the cookie can be changed too, i.e. if you change your cookie generation secret, all previous cookies are invalidated, and if someone just happened to have exchange going with you that cookie will be changed too. Another option is in case the NAT decided to change the mapping after sending the first request and before the message with cookie was sent. Also note that if you omit future requests, even when they later have valid cookie, then attacker can cause DoS by simply sending one message with invalid cookie before the real peer can do that. > b) Send the correct cookie to the initiator. I think this should be the default. Cookie generation should be so fast that generation of them do not matter. Also there is no amplification factor there, so you can simply answer with one packet to each one packet request you get. > c) Ban the source IP address for a time to avoid DoS attacks. This would allow very easy DoS done by the attacker, i.e. just start sending random cookies to the host with IP address taken from the VPN box of the other end, and you can forbid connections between the boxes. > I think the most adequate option is c) or a) adequate, because > b) whould falls in DoS attacks. C would be really bad, A would be better, but B is the one that is meant to be used. Note, that A and C both would require responder to store state to be able to filter packets out, so those are at least partly against the IKEv2 draft too. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 26 10:47:29 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuGP-0007Ku-Ia; Mon, 26 Sep 2005 10:47:29 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuGL-0007K2-Qf for ipsec@megatron.ietf.org; Mon, 26 Sep 2005 10:47:27 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01999 for ; Mon, 26 Sep 2005 10:47:16 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJuNE-0007Gb-UD for ipsec@ietf.org; Mon, 26 Sep 2005 10:54:36 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8QEipFq025008; Mon, 26 Sep 2005 17:44:55 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Sep 2005 17:47:11 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Sep 2005 17:47:11 +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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Invalid Cookie Date: Mon, 26 Sep 2005 17:47:13 +0300 Message-ID: Thread-Topic: [Ipsec] Invalid Cookie Thread-Index: AcXCe33eYTQZIEKkTl+LjR/5nUfVhQALaVQw To: , X-OriginalArrivalTime: 26 Sep 2005 14:47:11.0678 (UTC) FILETIME=[2D64F5E0:01C5C2A9] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 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 Alejandro Perez Mendez wrote: > Hi. I need some clarifications about cookies, please. > What is the spected behaviour when an invalid cookie is received? >=20 > There are three options: > a) Omit request until initiator spend all its retransmitions. > b) Send the correct cookie to the initiator.=20 > c) Ban the source IP address for a time to avoid DoS attacks. >=20 > I think the most adequate option is c) or a) adequate, because=20 > b) whould falls in DoS attacks. The only correct choice is b: if the responder receives an invalid cookie, the cookie is just ignored, and a new cookie is sent. (Option c is an especially bad idea: an attacker who knows my IP address could prevent me from opening connections just by sending bad cookies continuously...) Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 26 10:48:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuHB-0007Tz-TZ; Mon, 26 Sep 2005 10:48:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuH6-0007TV-Kh for ipsec@megatron.ietf.org; Mon, 26 Sep 2005 10:48:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02027 for ; Mon, 26 Sep 2005 10:48:10 -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.43) id 1EJuO9-0007Hw-97 for ipsec@ietf.org; Mon, 26 Sep 2005 10:55:30 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8QEm7Kg010816; Mon, 26 Sep 2005 17:48:09 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Sep 2005 17:48:08 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Sep 2005 17:48:08 +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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] certificate payloads/requests in IKEv2 Date: Mon, 26 Sep 2005 17:48:10 +0300 Message-ID: Thread-Topic: [Ipsec] certificate payloads/requests in IKEv2 Thread-Index: AcXCUMsOHtho0EAsTHGHa5ckYvioiAAWHRlA To: , X-OriginalArrivalTime: 26 Sep 2005 14:48:08.0376 (UTC) FILETIME=[4F306380:01C5C2A9] X-Spam-Score: 0.3 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 Michael Richardson wrote: > Is it permissible to send a certificate payload or certificate=20 > request when the authentication method is PSK? >=20 > It is forbidden? >=20 > I don't ask for any reason. I just changed some code in IKEv1 to=20 > log the reason for not sending a certificate as being because, we=20 > are using PSK. =20 Sending CERTREQ is allowd because at that point (message 2 or 3), you don't necessarily know yet which authentication method the other guy is going to use (it's possible to use shared secret in one direction and certificate/public-key in the other direction). On the other hand, if you do know that it's going to be shared secret in both directions (you're not going to accept a certificate no matter what), then sending CERTREQ doesn't make much sense. About CERT, it seems that it's not allowed: Section 1.2 says that "If any CERT payloads are included, the first certificate provided MUST contain the public key used to verify the AUTH field" (which it can't contain if the AUTH field is shared secret based). And it wouldn't make any sense anyway (at least with X.509/raw RSA key CERT types)... Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 26 11:02:20 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuUm-0003Ce-3z; Mon, 26 Sep 2005 11:02:20 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuUk-0003CX-NC for ipsec@megatron.ietf.org; Mon, 26 Sep 2005 11:02:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04340 for ; Mon, 26 Sep 2005 11:02:16 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJubn-0008Hy-WF for ipsec@ietf.org; Mon, 26 Sep 2005 11:09:37 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8QExxls009978; Mon, 26 Sep 2005 18:00:00 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Sep 2005 18:02:17 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 26 Sep 2005 18:02:16 +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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Clarification on error notifications, please Date: Mon, 26 Sep 2005 18:02:18 +0300 Message-ID: Thread-Topic: [Ipsec] Clarification on error notifications, please Thread-Index: AcXAP1yCppnHLsIdQeSSeo2KUdKsjgCaskPQ To: X-OriginalArrivalTime: 26 Sep 2005 15:02:16.0364 (UTC) FILETIME=[48A116C0:01C5C2AB] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7baded97d9887f7a0c7e8a33c2e3ea1b 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 Tero Kivinen wrote: > He should probably log it, but I would say he should otherwise ignore > the packet (or use it as hint), and continue trying until it times > out, or after the policy is modified. The IKEv2 draft is quite clear > about that (section 2.21): >=20 > A node receiving such an unprotected Notify payload MUST NOT > respond and MUST NOT change the state of any existing SAs. The > message might be a forgery or might be a response the genuine > correspondent was tricked into sending. A node SHOULD treat such a > message (and also a network message like ICMP destination > unreachable) as a hint that there might be problems with SAs to > that IP address and SHOULD initiate a liveness test for any such > IKE_SA. An implementation SHOULD limit the frequency of such tests > to avoid being tricked into participating in a denial of service > attack. >=20 > Before we have processed the other ends AUTH payload the notifies are > unprotected, as we do not know who the other end is. So the only > option draft really gives you is to use it as a hint (i.e. you can log > it, and you can perhaps make you time out faster, and limit the number > of retranmissions).=20 I think you're quoting the spec out of context. The paragraph before the one you quoted makes it quite clear that "such an unprotected Notify" means a Notify message sent totally outside of an IKE_SA (i.e.,=20 it's not encrypted and integrity-protected at all). If we receive a notification _inside_ the IKE_SA (inside SK{..}), we do know it came from the real peer of this IKE_SA, even if we don't=20 know anything more about the peer yet. Thus, it makes absolutely no=20 sense whatsoever to continue retransmitting the same request... (Rate-limiting the establishment of new IKE_SAs is a totally=20 different matter.) Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 26 11:05:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuXj-0004vz-Bo; Mon, 26 Sep 2005 11:05:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJuXh-0004vK-5z for ipsec@megatron.ietf.org; Mon, 26 Sep 2005 11:05:21 -0400 Received: from lists.sandelman.ca (cod.sandelman.ca [192.139.46.139]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA05184 for ; Mon, 26 Sep 2005 11:05:16 -0400 (EDT) Received: from sandelman.ottawa.on.ca (CPE0080c8d59fa8-CM0011aea1b6fc.cpe.net.cable.rogers.com [69.196.216.20]) by lists.sandelman.ca (8.11.6p3/8.11.6) with ESMTP id j8QF4jx17983 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Mon, 26 Sep 2005 11:04:51 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 1EB80E9951; Mon, 26 Sep 2005 11:04:45 -0400 (EDT) To: "Van Aken Dirk" In-Reply-To: Message from "Van Aken Dirk" of "Mon, 26 Sep 2005 08:25:40 +0200." <1F5308C5923F3B4DAA51D189BF255006BC7CA3@edgmsmail01.eu.thmulti.com> References: <1F5308C5923F3B4DAA51D189BF255006BC7CA3@edgmsmail01.eu.thmulti.com> X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 17) Date: Mon, 26 Sep 2005 11:04:45 -0400 Message-ID: <7898.1127747085@marajade.sandelman.ottawa.on.ca> From: Michael Richardson Cc: ipsec@ietf.org, dhcwg@ietf.org Subject: [Ipsec] Re: [dhcwg] Re: Authentication of DHCP Relay Agent Options Using 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 -----BEGIN PGP SIGNED MESSAGE----- {something rewrote the ipsec list to: ipsec@lists.tislabs.com.cnri.reston.va.us I'm guessing it gmane.org. Can you confirm what my message looked like when it hit dhcwg@ietf.org? } >>>>> "Van" == Van Aken Dirk writes: Van> How do you come to the conclusion that DHCP relays are rather Van> "small boxes" and as a consequence don't need a full IKE Van> implementation ? You are looking at this from the wrong point of view. I'm claiming that DHCP relays *CAN* be small boxes, and so setting a smaller footprint for what they need in terms of IKE benefits small boxes without harming bigger boxes. Nothing prevents you from having a superset of what is required. (And what passes for a "small box" these days can be quite big) - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQzgOCoqHRg3pndX9AQHn6AP9F0GqCRkOHI0nvMaAYyRvc5ss+BMZfsRy OIo/SvrPILkCsbdI8B4QX+fkpRs8m36boIIlVPQ24H8MpH4HtJD3thJhdMozF198 8kKtgNhnHUTd95GNhvCWaeZ6cOca0K1LogQxeduQhEt7y2CmRpyOYCv9+PyD1tuh uHn3WnmqE0s= =jZz3 -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Sep 26 12:00:59 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJvPX-00062D-Ct; Mon, 26 Sep 2005 12:00:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EJvPU-00061t-Q7 for ipsec@megatron.ietf.org; Mon, 26 Sep 2005 12:00:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20900 for ; Mon, 26 Sep 2005 12:00:54 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EJvWX-0006VQ-6M for ipsec@ietf.org; Mon, 26 Sep 2005 12:08: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 j8QG0eMi054660; Mon, 26 Sep 2005 09:00:40 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 26 Sep 2005 08:59:41 -0700 To: Pasi.Eronen@nokia.com, , From: Paul Hoffman Subject: RE: [Ipsec] certificate payloads/requests in IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 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 At 5:48 PM +0300 9/26/05, Pasi.Eronen@nokia.com wrote: >About CERT, it seems that it's not allowed: Section 1.2 says that >"If any CERT payloads are included, the first certificate >provided MUST contain the public key used to verify the AUTH >field" (which it can't contain if the AUTH field is shared secret >based). And it wouldn't make any sense anyway (at least with >X.509/raw RSA key CERT types)... That sentence from the spec can be read sensibly in two fashions: - If any CERT payloads are included and public keys are being used for authentication, then the first certificate provided is the one that contains the public key used to verify the AUTH field. - If any CERT payloads are included, that means that public keys are being used for authentication, and that the first certificate provided is the one that contains the public key used to verify the AUTH field. I read the sentence the first way, definitely. I cannot find anything on the mailing list that says that we intended the existence of a CERT payload to be a MUST-level signal that we were using public key authentication. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 27 03:23:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK9o7-0002Eh-A0; Tue, 27 Sep 2005 03:23:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EK9o5-0002Ec-0e for ipsec@megatron.ietf.org; Tue, 27 Sep 2005 03:23:17 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA20099 for ; Tue, 27 Sep 2005 03:23:15 -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.43) id 1EK9vG-00043Y-S0 for ipsec@ietf.org; Tue, 27 Sep 2005 03:30:44 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j8R7LjEk015026; Tue, 27 Sep 2005 10:21:45 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Sep 2005 10:23:10 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Sep 2005 10:23:10 +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="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] certificate payloads/requests in IKEv2 Date: Tue, 27 Sep 2005 10:23:07 +0300 Message-ID: Thread-Topic: [Ipsec] certificate payloads/requests in IKEv2 Thread-Index: AcXCs4pZq2u7gpxtQKODtRKiiET+UgAf9i/w To: , X-OriginalArrivalTime: 27 Sep 2005 07:23:10.0169 (UTC) FILETIME=[503B0C90:01C5C334] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d 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 =20 Paul Hoffman wrote: > At 5:48 PM +0300 9/26/05, Pasi.Eronen@nokia.com wrote: > >About CERT, it seems that it's not allowed: Section 1.2 says that > >"If any CERT payloads are included, the first certificate > >provided MUST contain the public key used to verify the AUTH > >field" (which it can't contain if the AUTH field is shared secret > >based). And it wouldn't make any sense anyway (at least with > >X.509/raw RSA key CERT types)... >=20 > That sentence from the spec can be read sensibly in two fashions: >=20 > - If any CERT payloads are included and public keys are being used=20 > for authentication, then the first certificate provided is the one=20 > that contains the public key used to verify the AUTH field. >=20 > - If any CERT payloads are included, that means that public keys are=20 > being used for authentication, and that the first certificate=20 > provided is the one that contains the public key used to verify the=20 > AUTH field. >=20 > I read the sentence the first way, definitely. I cannot find anything=20 > on the mailing list that says that we intended the existence of a=20 > CERT payload to be a MUST-level signal that we were using public key=20 > authentication. True, both ways seem sensible. And of course following the "be liberal=20 in what you accept" principle would mean that if you receive CERT=20 payloads when doing shared secret authentication, you should just ignore the CERTs (instead of failing the exchange). However, if an implementation sends CERTs when it's using shared secret authentication, and actually expects the peer to do something with the certificates, then those expectations are IMHO not justified by the IKEv2 spec... (which means that sending the CERTs is not necessary) Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 27 11:00:55 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKGwx-0005j6-8U; Tue, 27 Sep 2005 11:00:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKGwv-0005iL-CL for ipsec@megatron.ietf.org; Tue, 27 Sep 2005 11:00:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA15005 for ; Tue, 27 Sep 2005 11:00:51 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKH48-0007m5-RP for ipsec@ietf.org; Tue, 27 Sep 2005 11:08:24 -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 j8RF0epK096688; Tue, 27 Sep 2005 08:00:43 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 27 Sep 2005 08:00:37 -0700 To: , From: Paul Hoffman Subject: RE: [Ipsec] certificate payloads/requests in IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 At 10:23 AM +0300 9/27/05, wrote: >True, both ways seem sensible. And of course following the "be liberal >in what you accept" principle would mean that if you receive CERT >payloads when doing shared secret authentication, you should just >ignore the CERTs (instead of failing the exchange). Right. >However, if an implementation sends CERTs when it's using shared >secret authentication, and actually expects the peer to do something >with the certificates, then those expectations are IMHO not justified >by the IKEv2 spec... (which means that sending the CERTs is not >necessary) Of course it is not necessary, but it might happen due to some mis-implementation. As you said above, the certs should just be ignored. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Sep 27 13:56:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKJgb-000132-6r; Tue, 27 Sep 2005 13:56:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EKJgY-00012x-P2 for ipsec@megatron.ietf.org; Tue, 27 Sep 2005 13:56:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27626 for ; Tue, 27 Sep 2005 13:56:10 -0400 (EDT) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EKJnr-0004Vk-Ax for ipsec@ietf.org; Tue, 27 Sep 2005 14:03:43 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 27 Sep 2005 10:56:01 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8RHtT4t024505; Tue, 27 Sep 2005 10:55:58 -0700 (PDT) Received: from xmb-rtp-208.amer.cisco.com ([64.102.31.43]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.211); Tue, 27 Sep 2005 13:55:57 -0400 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] Invalid Cookie Date: Tue, 27 Sep 2005 13:55:56 -0400 Message-ID: <13E3DA8B48E17D4C96D261A36A23FCD69CF4B0@xmb-rtp-208.amer.cisco.com> Thread-Topic: [Ipsec] Invalid Cookie Thread-Index: AcXChInes1BsWfK3SACLiA6XUeVrYQBB0x4g From: "Stephane Beaulieu \(stephane\)" To: "Tero Kivinen" , "Alejandro Perez Mendez" X-OriginalArrivalTime: 27 Sep 2005 17:55:57.0078 (UTC) FILETIME=[B6459B60:01C5C38C] X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 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 >=20 > Alejandro Perez Mendez writes: > > Hi. I need some clarifications about cookies, please. > > What is the spected behaviour when an invalid cookie is received? > >=20 > > There are three options: > > a) Omit request until initiator spend all its retransmitions. >=20 > Note, that there are valid cases when the cookie can be=20 > changed too, i.e. if you change your cookie generation=20 > secret, all previous cookies are invalidated, and if someone=20 > just happened to have exchange going with you that cookie=20 > will be changed too. Another option is in case the NAT=20 > decided to change the mapping after sending the first request=20 > and before the message with cookie was sent. Just a clarification... One CAN keep info from previous cookie secrets for X amount of time to allow a seemless cookie secret chageover. It may not be worth doing as you can just re-challenge with the new cookie if the peer fell into your cookie refresh window, but it is fairly simple to do if you want to have accurate logging for real failures vs. bad timing failures. >=20 > Also note that if you omit future requests, even when they=20 > later have valid cookie, then attacker can cause DoS by=20 > simply sending one message with invalid cookie before the=20 > real peer can do that.=20 >=20 > > b) Send the correct cookie to the initiator.=20 >=20 > I think this should be the default. Cookie generation should=20 > be so fast that generation of them do not matter. Also there=20 > is no amplification factor there, so you can simply answer=20 > with one packet to each one packet request you get.=20 >=20 > > c) Ban the source IP address for a time to avoid DoS attacks. >=20 > This would allow very easy DoS done by the attacker, i.e.=20 > just start sending random cookies to the host with IP address=20 > taken from the VPN box of the other end, and you can forbid=20 > connections between the boxes.=20 >=20 > > I think the most adequate option is c) or a) adequate, because > > b) whould falls in DoS attacks. >=20 > C would be really bad, A would be better, but B is the one=20 > that is meant to be used. >=20 > Note, that A and C both would require responder to store=20 > state to be able to filter packets out, so those are at least=20 > partly against the > IKEv2 draft too. > -- > kivinen@safenet-inc.com >=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 Fri Sep 30 14:53:34 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELQ0k-0005Qg-SM; Fri, 30 Sep 2005 14:53:34 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELQ0i-0005QP-38 for ipsec@megatron.ietf.org; Fri, 30 Sep 2005 14:53:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28956 for ; Fri, 30 Sep 2005 14:53:30 -0400 (EDT) Received: from xproxy.gmail.com ([66.249.82.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ELQ8c-0006DC-5d for ipsec@ietf.org; Fri, 30 Sep 2005 15:01:43 -0400 Received: by xproxy.gmail.com with SMTP id t4so258214wxc for ; Fri, 30 Sep 2005 11:53:22 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding; b=hUrOEtfB2JkE2s09bYh8r32Pg4036ZBSo1N2bu/r46R07SWHYlxc3ovdVC1mafSTGRKF6K3jgjkimiHlYVTJZkUcUqk6XJDTICBc+HRa3+KVrEakHDWK0Jeanb/W5hTMcIcJlDmWmFlerHocdqFkLt17D3tmESk9336Wl5GEcdk= Received: by 10.70.25.7 with SMTP id 7mr963509wxy; Fri, 30 Sep 2005 11:53:22 -0700 (PDT) Received: from ?192.168.2.190? ( [84.121.24.204]) by mx.gmail.com with ESMTP id i10sm1175964wxd.2005.09.30.11.53.21; Fri, 30 Sep 2005 11:53:21 -0700 (PDT) From: Alejandro Perez Mendez To: ipsec@ietf.org Content-Type: text/plain Date: Fri, 30 Sep 2005 20:53:14 +0200 Message-Id: <1128106394.26144.21.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.0 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Subject: [Ipsec] SPI values in proposals 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 all! When an IKE_AUTH/CREATE_CHILD_SA exchange is performed, an SPI value must be included in the Protocol substructure of the Payload SA. If "Alice" is the initiator and "Bob" is the responder, the SPI values sent are SPI-A(SPI value sent by Alice) and SPI-B (SPI value sent by Bob). When the IPsec SA must be created, there are two ways to do this: case a) Alice Bob -------- -------- outbound ------ SPI-A ----- > inbound inbound <----- SPI-B ------ outbound case b) Alice Bob -------- -------- outbound ------ SPI-B ----- > inbound inbound <----- SPI-A ------ outbound What is the correct way? My opinion is that case a) is the correct way, but It's not clear. Regards! _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Sep 30 15:00:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELQ7P-0007bU-5d; Fri, 30 Sep 2005 15:00:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ELQ7N-0007b7-FZ for ipsec@megatron.ietf.org; Fri, 30 Sep 2005 15:00:25 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29386 for ; Fri, 30 Sep 2005 15:00:23 -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.43) id 1ELQFG-0006Sl-55 for ipsec@ietf.org; Fri, 30 Sep 2005 15:08:36 -0400 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-3.cisco.com with ESMTP; 30 Sep 2005 12:00:01 -0700 X-IronPort-AV: i="3.97,162,1125903600"; d="scan'208"; a="347193506:sNHT1419027992" Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j8UIxx4W015212; Fri, 30 Sep 2005 12:00:00 -0700 (PDT) Date: Fri, 30 Sep 2005 11:59:59 -0700 (PDT) From: Scott Fluhrer To: Alejandro Perez Mendez Subject: Re: [Ipsec] SPI values in proposals In-Reply-To: <1128106394.26144.21.camel@localhost.localdomain> Message-ID: References: <1128106394.26144.21.camel@localhost.localdomain> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 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 Fri, 30 Sep 2005, Alejandro Perez Mendez wrote: > Hi all! > When an IKE_AUTH/CREATE_CHILD_SA exchange is performed, an SPI value > must be included in the Protocol substructure of the Payload SA. > If "Alice" is the initiator and "Bob" is the responder, the SPI values > sent are SPI-A(SPI value sent by Alice) and SPI-B (SPI value sent by > Bob). > > When the IPsec SA must be created, there are two ways to do this: > > case a) > > Alice Bob > -------- -------- > outbound ------ SPI-A ----- > inbound > inbound <----- SPI-B ------ outbound > > case b) > > Alice Bob > -------- -------- > outbound ------ SPI-B ----- > inbound > inbound <----- SPI-A ------ outbound > > What is the correct way? > My opinion is that case a) is the correct way, but It's not clear. Nope, it's (B) -- everyone picks their own inbound SPIs. -- scott _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec