From ipsec-bounces@ietf.org Thu Jun 01 04:45:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlinI-0007yf-Gk; Thu, 01 Jun 2006 04:44:40 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FlinH-0007ya-Jz for ipsec@ietf.org; Thu, 01 Jun 2006 04:44:39 -0400 Received: from bay20-f1.bay20.hotmail.com ([64.4.54.90] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlinF-0004r5-Bk for ipsec@ietf.org; Thu, 01 Jun 2006 04:44:39 -0400 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 1 Jun 2006 01:44:36 -0700 Message-ID: Received: from 213.139.170.197 by by20fd.bay20.hotmail.msn.com with HTTP; Thu, 01 Jun 2006 08:44:36 GMT X-Originating-IP: [213.139.170.197] X-Originating-Email: [pekka747@hotmail.com] X-Sender: pekka747@hotmail.com From: "pekka huikenen" To: ipsec@ietf.org Bcc: Date: Thu, 01 Jun 2006 11:44:36 +0300 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 01 Jun 2006 08:44:36.0814 (UTC) FILETIME=[9CEE26E0:01C68557] X-Spam-Score: 0.5 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Ipsec] Clarification about Configuration Attributes 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: , Errors-To: ipsec-bounces@ietf.org Hi all How are multiple values of an attribute encoded in the configuration payload? For example, DNS is multi-valued, and we may have two DNS server. Do I encode just one attribute structure with length 8 and the value field contains two DNS addresses, or do I encode two separate attribute structures, each with length 4 and just one DNS server address? Thanks. _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jun 01 11:25:00 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flp2a-0007q6-Ni; Thu, 01 Jun 2006 11:24:52 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Flp2X-0007Z9-Uc for ipsec@ietf.org; Thu, 01 Jun 2006 11:24:49 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FlozG-0006H9-LO for ipsec@ietf.org; Thu, 01 Jun 2006 11:21:28 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k51FLKUC021018; Thu, 1 Jun 2006 18:21:20 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 18:20:22 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Jun 2006 18:20:21 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Clarification about Configuration Attributes in IKEv2 Date: Thu, 1 Jun 2006 18:20:22 +0300 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ipsec] Clarification about Configuration Attributes in IKEv2 Thread-Index: AcaFV/SKglmvDqqOSmOnEq/X1jKVMgANrozw From: To: , X-OriginalArrivalTime: 01 Jun 2006 15:20:21.0171 (UTC) FILETIME=[E5AB8030:01C6858E] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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: , Errors-To: ipsec-bounces@ietf.org Two separate INTERNAL_IP4_DNS attributes, each with length 4.=20 Best regards, Pasi > -----Original Message----- > From: ext pekka huikenen [mailto:pekka747@hotmail.com]=20 > Sent: 01 June, 2006 11:45 > To: ipsec@ietf.org > Subject: [Ipsec] Clarification about Configuration Attributes in IKEv2 >=20 > Hi all >=20 > How are multiple values of an attribute encoded in the configuration=20 > payload? For example, DNS is multi-valued, and we may have=20 > two DNS server. >=20 > Do I encode just one attribute structure with length 8 and=20 > the value field contains two DNS addresses, or do I encode two=20 > separate attribute structures, each with length 4 and just one=20 > DNS server address? >=20 > Thanks. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 02 02:52:44 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm3WF-0007s0-Qw; Fri, 02 Jun 2006 02:52:27 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm3Vn-0006wV-Hh for Ipsec@ietf.org; Fri, 02 Jun 2006 02:51:59 -0400 Received: from hsrmx1.hsr.ch ([152.96.36.50]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm3Vk-0007AJ-Q8 for Ipsec@ietf.org; Fri, 02 Jun 2006 02:51:59 -0400 Received: from localhost (hsrmx1 [127.0.0.1]) by hsrmx1.hsr.ch (Postfix) with ESMTP id A0CE21138FF for ; Fri, 2 Jun 2006 08:51:55 +0200 (CEST) X-Virus-Scanned: amavisd-new at hsr.ch Received: from hsrmx1.hsr.ch ([127.0.0.1]) by localhost (hsrmx1.hsr.ch [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D8MGAH+oGs1I for ; Fri, 2 Jun 2006 08:51:54 +0200 (CEST) Received: by hsrmx1.hsr.ch (Postfix, from userid 3004) id A785E11390E; Fri, 2 Jun 2006 08:51:54 +0200 (CEST) Received: from sid00062.hsr.ch (unknown [152.96.21.100]) by hsrmx1.hsr.ch (Postfix) with ESMTP id 6F0251138FF for ; Fri, 2 Jun 2006 08:51:54 +0200 (CEST) Received: from sid00060.hsr.ch ([152.96.22.60]) by sid00062.hsr.ch with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 08:51:54 +0200 Received: from nin6110018.hsr.ch ([152.96.200.161]) by sid00060.hsr.ch over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 08:51:54 +0200 From: Martin Willi To: Ipsec@ietf.org Date: Fri, 2 Jun 2006 08:50:52 +0200 User-Agent: KMail/1.9.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200606020850.52931.martin@strongswan.org> X-OriginalArrivalTime: 02 Jun 2006 06:51:54.0328 (UTC) FILETIME=[08966D80:01C68611] X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: Subject: [Ipsec] Rekeing of a CHILD_SA with AH+ESP 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: , Errors-To: ipsec-bounces@ietf.org Dear subscribers, It is not absolutely clear to me how to do the rekeying of a CHILD_SA, if its traffic is protected by AH AND ESP. The use of both protocols may be questionable, but it's possible in IKEv2 and therefore I want to support it. I've done the following assumptions: - a CHILD_SA consists of a AH and/or ESP security assocation, this means it's just ONE CHILD_SA, even if there are two/four (kernel level) security associations involved. Correct? - If I set up AH and ESP in one CHILD_SA, those SAs may be identified by different SPIs. Correct? I haven't found a clear statement about this, but the inclusion of an SPI in every proposal substructure leads to this assumption. Now what means "rekeing a CHILD_SA"? What's to do if one of those SAs (ESP or AH) expire? For me, two approaches are possible: 1. Rekey the full CHILD_SA (ESP and AH SA) at once. If so: - Which SPI should be included in the REKEY_SA notify? Or include two of them? 2. Rekey every SA seperately. If so: - What sould be included in the SA-payload? Only proposals for the specific protocol? I hope someone can give me clarity about this. Thanks in advance Martin Willi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 02 03:04:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm3hu-0004k2-9b; Fri, 02 Jun 2006 03:04:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm3hs-0004gt-Ap for Ipsec@ietf.org; Fri, 02 Jun 2006 03:04:28 -0400 Received: from mail.um.es ([155.54.212.109]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm3hp-00007D-MH for Ipsec@ietf.org; Fri, 02 Jun 2006 03:04:28 -0400 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 82E301FAE95; Fri, 2 Jun 2006 09:04:24 +0200 (CEST) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 13843-01-9; Fri, 2 Jun 2006 09:04:24 +0200 (CEST) Received: from mail.dif.um.es (dif.um.es [155.54.204.60]) by mail.um.es (Postfix) with ESMTP id 175D11FAE77; Fri, 2 Jun 2006 09:04:24 +0200 (CEST) Received: from diffie (unknown [155.54.210.175]) by mail.dif.um.es (Postfix) with ESMTP id D18B88D4002; Fri, 2 Jun 2006 08:59:52 +0200 (CEST) Subject: Re: [Ipsec] Rekeing of a CHILD_SA with AH+ESP in IKEv2 From: Alejandro Perez Mendez To: Martin Willi In-Reply-To: <200606020850.52931.martin@strongswan.org> References: <200606020850.52931.martin@strongswan.org> Content-Type: text/plain; charset=utf-8 Date: Fri, 02 Jun 2006 09:04:24 +0200 Message-Id: <1149231864.5287.7.camel@diffie> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 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: , Errors-To: ipsec-bounces@ietf.org Hi! Some time ago I did the same question. You can read the discussion here http://www1.ietf.org/mail-archive/web/ipsec/current/msg01781.html At the end, we decide to eliminate all the SA bundles support from OpenIKEv2, due it is not clear how to support them and it was not a very important feature for us. Best regards! -- Alejandro Perez Mendez OpenIKEv2 developer http://openikev2.sf.net El vie, 02-06-2006 a las 08:50 +0200, Martin Willi escribi=C3=B3: > Dear subscribers, >=20 > It is not absolutely clear to me how to do the rekeying of a CHILD_SA, = if its > traffic is protected by AH AND ESP. The use of both protocols may be > questionable, but it's possible in IKEv2 and therefore I want to suppor= t it. >=20 > I've done the following assumptions: > - a CHILD_SA consists of a AH and/or ESP security assocation, this me= ans > it's just ONE CHILD_SA, even if there are two/four (kernel level) > security associations involved. Correct? > - If I set up AH and ESP in one CHILD_SA, those SAs may be identified= by > different SPIs. Correct? I haven't found a clear statement about th= is, but > the inclusion of an SPI in every proposal substructure leads to thi= s > assumption. >=20 > Now what means "rekeing a CHILD_SA"? What's to do if one of those=20 > SAs (ESP or AH) expire? For me, two approaches are possible: > 1. Rekey the full CHILD_SA (ESP and AH SA) at once. If so: > - Which SPI should be included in the REKEY_SA notify? Or include two= of > them? > 2. Rekey every SA seperately. If so: > - What sould be included in the SA-payload? Only proposals for the sp= ecific=20 > protocol? >=20 > I hope someone can give me clarity about this. >=20 > Thanks in advance > Martin Willi >=20 > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 02 05:31:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm5zj-0008Mn-Rc; Fri, 02 Jun 2006 05:31:03 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm5zi-0008Me-M1 for Ipsec@ietf.org; Fri, 02 Jun 2006 05:31:02 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm5zh-0006Ss-7N for Ipsec@ietf.org; Fri, 02 Jun 2006 05:31:02 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k529Usmp031767; Fri, 2 Jun 2006 12:30:59 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 12:30:34 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 12:30:33 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Rekeing of a CHILD_SA with AH+ESP in IKEv2 Date: Fri, 2 Jun 2006 12:30:34 +0300 Message-ID: In-Reply-To: <200606020850.52931.martin@strongswan.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ipsec] Rekeing of a CHILD_SA with AH+ESP in IKEv2 Thread-Index: AcaGEYGvmfSwr7hWTXO+mKftTw6RwgAFQVvA From: To: , X-OriginalArrivalTime: 02 Jun 2006 09:30:33.0992 (UTC) FILETIME=[32BFE080:01C68627] X-Spam-Score: 0.2 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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: , Errors-To: ipsec-bounces@ietf.org Hi, You probably want to check out Section 7.13 (Combining ESP and AH) in draft-eronen-ipsec-ikev2-clarifications.=20 Best regards, Pasi > -----Original Message----- > From: ext Martin Willi [mailto:martin@strongswan.org]=20 > Sent: 02 June, 2006 09:51 > To: Ipsec@ietf.org > Subject: [Ipsec] Rekeing of a CHILD_SA with AH+ESP in IKEv2 >=20 > Dear subscribers, >=20 > It is not absolutely clear to me how to do the rekeying of a=20 > CHILD_SA, if its traffic is protected by AH AND ESP. The use of both=20 > protocols may be questionable, but it's possible in IKEv2 and=20 > therefore I want to support it. >=20 > I've done the following assumptions: > - a CHILD_SA consists of a AH and/or ESP security assocation,=20 > this means it's just ONE CHILD_SA, even if there are two/four=20 > (kernel level) security associations involved. Correct? > - If I set up AH and ESP in one CHILD_SA, those SAs may be=20 > identified by different SPIs. Correct? I haven't found a=20 > clear statement about this, but the inclusion of an SPI in=20 > every proposal substructure leads to this assumption. >=20 > Now what means "rekeing a CHILD_SA"? What's to do if one of those=20 > SAs (ESP or AH) expire? For me, two approaches are possible: > 1. Rekey the full CHILD_SA (ESP and AH SA) at once. If so: > - Which SPI should be included in the REKEY_SA notify? Or=20 > include two of them? > 2. Rekey every SA seperately. If so: > - What sould be included in the SA-payload? Only proposals=20 > for the specific protocol? >=20 > I hope someone can give me clarity about this. >=20 > Thanks in advance > Martin Willi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 02 07:23:31 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm7kT-00057j-7w; Fri, 02 Jun 2006 07:23:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm7kS-00057b-5x for Ipsec@ietf.org; Fri, 02 Jun 2006 07:23:24 -0400 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 1Fm7kQ-0001KE-KN for Ipsec@ietf.org; Fri, 02 Jun 2006 07:23:24 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.5.20060308/8.12.10) with ESMTP id k52BNKN0018942 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 2 Jun 2006 14:23:20 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.5.20060308/8.12.11) id k52BNJ0I014556; Fri, 2 Jun 2006 14:23: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: <17536.8103.203132.924584@fireball.kivinen.iki.fi> Date: Fri, 2 Jun 2006 14:23:19 +0300 From: Tero Kivinen To: Martin Willi Subject: [Ipsec] Rekeing of a CHILD_SA with AH+ESP in IKEv2 In-Reply-To: <200606020850.52931.martin@strongswan.org> References: <200606020850.52931.martin@strongswan.org> X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 13 min X-Total-Time: 13 min X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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: , Errors-To: ipsec-bounces@ietf.org Martin Willi writes: > Dear subscribers, > > It is not absolutely clear to me how to do the rekeying of a CHILD_SA, if its > traffic is protected by AH AND ESP. The use of both protocols may be > questionable, but it's possible in IKEv2 and therefore I want to support it. There is not really AH AND ESP in RFC4301 architecture. There is TCP/UDP inside ESP and ESP inside AH. I.e. AH+ESP is generated by first creating SA encrypting traffic with ESP and then creating separate SA that will authenticate the ESP packets by adding AH around them. Those two SAs are created as two separate IKE CREATE CHILD SA exchanges. > I've done the following assumptions: > - a CHILD_SA consists of a AH and/or ESP security assocation, this means > it's just ONE CHILD_SA, even if there are two/four (kernel level) > security associations involved. Correct? Wrong. AH and ESP are separate SAs each having different traffic selectors. The ESP have traffic selectors of the real traffic to be protected, and the AH has traffic selectors matching the ESP traffic. > - If I set up AH and ESP in one CHILD_SA, those SAs may be identified by > different SPIs. Correct? I haven't found a clear statement about this, but > the inclusion of an SPI in every proposal substructure leads to this > assumption. You create AH and ESP as two CREATE_CHILD_SAs, each having one SPI in SA payload, and only one protocol in each proposal. Each of those CREATE_CHILD_SAs also have different traffic selectors matching the data to be protected, i.e. for the AH it is going to be protocol = ESP etc. > Now what means "rekeing a CHILD_SA"? What's to do if one of those > SAs (ESP or AH) expire? For me, two approaches are possible: > 1. Rekey the full CHILD_SA (ESP and AH SA) at once. If so: > - Which SPI should be included in the REKEY_SA notify? Or include two of > them? As the ESP and AH SA are not bundled together, you cannot do that. > 2. Rekey every SA seperately. If so: Yes, you do this, i.e. rekey them separately, just like you created them too. > - What sould be included in the SA-payload? Only proposals for the specific > protocol? You use same data you used when you created them, i.e. only proposals for the specific protocol, and including the traffic selectors set properly. > I hope someone can give me clarity about this. In RFC4301 there is no more SA bundles, i.e. AH+ESP is not a special case anymore, you create ESP and AH separately, and set the traffic selectors so that after packets are encrypted by ESP, the packets match selectors of the AH, and are reprocessed by the IPsec and authenticated by using AH. See the section 5.1 of the RFC4301, and notice that the SPD cache returns you exactly one SA, which is used to process the pcaket with either AH or ESP (but not both), and then the packets goes to the Forwarding check, that will resend the packet to beginning again, now with new selectors and then the SPD cache will return another SA and you do the second process step for the packet. Same thing is described in the section 5.2 for the inbound packets. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 02 07:53:56 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm8Ds-0007J6-JN; Fri, 02 Jun 2006 07:53:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm8Dq-0007Iw-Mm for Ipsec@ietf.org; Fri, 02 Jun 2006 07:53:46 -0400 Received: from burp.tkv.asdf.org ([212.16.99.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm8Dp-0003tA-4S for Ipsec@ietf.org; Fri, 02 Jun 2006 07:53:46 -0400 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.6/8.13.6/Debian-1) with ESMTP id k52BrhJO031481; Fri, 2 Jun 2006 14:53:43 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.6/8.13.6/Submit) id k52BrhlO031478; Fri, 2 Jun 2006 14:53:43 +0300 Date: Fri, 2 Jun 2006 14:53:43 +0300 Message-Id: <200606021153.k52BrhlO031478@burp.tkv.asdf.org> From: Markku Savela To: kivinen@iki.fi In-reply-to: <17536.8103.203132.924584@fireball.kivinen.iki.fi> (message from Tero Kivinen on Fri, 2 Jun 2006 14:23:19 +0300) Subject: Re: [Ipsec] Rekeing of a CHILD_SA with AH+ESP in IKEv2 References: <200606020850.52931.martin@strongswan.org> <17536.8103.203132.924584@fireball.kivinen.iki.fi> 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: , Errors-To: ipsec-bounces@ietf.org > From: Tero Kivinen > Wrong. AH and ESP are separate SAs each having different traffic > selectors. The ESP have traffic selectors of the real traffic to be > protected, and the AH has traffic selectors matching the ESP traffic. ... > See the section 5.1 of the RFC4301, and notice that the SPD cache > returns you exactly one SA, which is used to process the pcaket with > either AH or ESP (but not both), and then the packets goes to the > Forwarding check, that will resend the packet to beginning again, now > with new selectors and then the SPD cache will return another SA and > you do the second process step for the packet. I'm somewhat troubled by above description. I heartily support the idea that AH and ESP are negotiated independently. This was my prime objection for IKEv1 from the start. But, your selector thing is a bit problematic. In IPv6, AH and ESP are extension headers. Seems odd that after extension header processing, the packet would go into "forwarding check" etc. This not the way our stack works. I believe the selectors should always be for "transport level". If you protect TCP or UDP traffic with AH + ESP, I say the selectors for AH and ESP should still be the TCP/UDP and ports. This way the basic IPsec implementations (not including IKE) would be compatible between RFC-2401 and 4301 implementations. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 02 09:40:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm9sU-0003vM-T5; Fri, 02 Jun 2006 09:39:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fm9sT-0003vH-NJ for Ipsec@ietf.org; Fri, 02 Jun 2006 09:39:49 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fm9sT-0007tf-Lt for Ipsec@ietf.org; Fri, 02 Jun 2006 09:39:49 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fm9sS-0004gz-4D for Ipsec@ietf.org; Fri, 02 Jun 2006 09:39:49 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k52DdiEG020331; Fri, 2 Jun 2006 16:39:45 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 16:39:45 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Jun 2006 16:39:45 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Rekeing of a CHILD_SA with AH+ESP in IKEv2 Date: Fri, 2 Jun 2006 16:39:44 +0300 Message-ID: In-Reply-To: <200606021153.k52BrhlO031478@burp.tkv.asdf.org> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ipsec] Rekeing of a CHILD_SA with AH+ESP in IKEv2 Thread-Index: AcaGO9s6Vzf0QfpaQhuGFqPTEb+/7gACxQpA From: To: X-OriginalArrivalTime: 02 Jun 2006 13:39:45.0946 (UTC) FILETIME=[02CEFFA0:01C6864A] X-Spam-Score: -2.6 (--) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a 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: , Errors-To: ipsec-bounces@ietf.org Markku Savela wrote: > I'm somewhat troubled by above description. I heartily support the > idea that AH and ESP are negotiated independently. This was my prime > objection for IKEv1 from the start. >=20 > But, your selector thing is a bit problematic. In IPv6, AH and ESP are > extension headers. Seems odd that after extension header processing, > the packet would go into "forwarding check" etc. This not the way our > stack works. Going back to forwarding check is required to handle nested IPsec SAs between different endpoints. E.g. suppose that I have an IPsec tunnel (ESP or AH) between my laptop=20 at home and the company VPN gateway. Inside that tunnel, there can be another SA (ESP or AH) for protecting traffic between the laptop and=20 some server X located inside the company intranet. So when a packet arrives down from UDP/TCP, it's first processed using the latter SA (laptop-server X), then goes to forwarding check, and then processed using the former SA (laptop-gateway). In RFC4301, AH+ESP between the same endpoints is basically handled same way as two nested SAs with different endpoints (and there's no difference between IPv4 and IPv6 here). Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 02 10:36:55 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmAlc-0003yC-O3; Fri, 02 Jun 2006 10:36:48 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmAla-0003xm-O6 for Ipsec@ietf.org; Fri, 02 Jun 2006 10:36:46 -0400 Received: from burp.tkv.asdf.org ([212.16.99.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmAlZ-0004WW-9F for Ipsec@ietf.org; Fri, 02 Jun 2006 10:36:46 -0400 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.6/8.13.6/Debian-1) with ESMTP id k52EahVv003927; Fri, 2 Jun 2006 17:36:43 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.6/8.13.6/Submit) id k52EahtL003924; Fri, 2 Jun 2006 17:36:43 +0300 Date: Fri, 2 Jun 2006 17:36:43 +0300 Message-Id: <200606021436.k52EahtL003924@burp.tkv.asdf.org> From: Markku Savela To: Pasi.Eronen@nokia.com In-reply-to: (Pasi.Eronen@nokia.com) Subject: Re: [Ipsec] Rekeing of a CHILD_SA with AH+ESP in IKEv2 References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea 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: , Errors-To: ipsec-bounces@ietf.org > Going back to forwarding check is required to handle nested IPsec > SAs between different endpoints. That's ok, in this context the inner IP header provides the right trigger. That is not the problem. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ariegrayson@bostream.com Sat Jun 03 11:46:58 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FmYL4-0002RU-7u for ipsec-archive@lists.ietf.org; Sat, 03 Jun 2006 11:46:58 -0400 Received: from 61-225-207-122.dynamic.hinet.net ([61.225.207.122] helo=BABY) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FmYL3-0007LB-5X for ipsec-archive@lists.ietf.org; Sat, 03 Jun 2006 11:46:58 -0400 Message-Id: <007b01c6871b$333adc00$3da0fbba@mpzsnsky> From: "yancy daniels" To: "eliot rutledge" Subject: Refinnace your loan, Anti-trinitarianism Date: Sat, 03 Jun 2006 10:42:18 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007B_01C6871B.333ADC00" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 3.4 (+++) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 This is a multi-part message in MIME format. ------=_NextPart_000_007B_01C6871B.333ADC00 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable How much are you paying for your Home? To much?=20 You have been pre-approved to fill out for a ref inance laon,=20 if you need some cash to spend ANY way you like, or simply wish=20 to LOWER your monthly payments by a third or more, etc. We skip the middle man to save hundreds with deals we have!=20 This offer is for you, we DONT CARE about your credit.=20 Apply online now for your instant quote. Stop over paying...=20 http://bayanmc.org/d2/ stiff-bosomed well-grassed swift-running pseudo author quasi declaration Ar-chang foot mange close-gleaning near-guessed card tenter salt water vice-caliph ground moss well-ascertained animal size balance watch ray pod bottle brush stair tower pike whale parrot-beaked tron weight tapestry-covered well-graveled lake dweller cross-brush self-wise world-forsaken deal board punching press Plymouth colony ------=_NextPart_000_007B_01C6871B.333ADC00 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
How much are you paying for your Home? To much?
You have been pre-approved to fill out for a ref inance laon,
if you need some cash to spend ANY way you like, or simply wish
to LOWER your monthly payments by a third or more, etc.

We skip the middle man to save hundreds with deals we have!
This offer is for you, we DONT CARE about your credit.

Apply online now for your instant quote. Stop over paying...

http://bayanmc.org/d2/

stiff-bosomed well-grassed swift-running pseudo author quasi declaration
Ar-chang foot mange
close-gleaning near-guessed card tenter salt water vice-caliph ground moss<= BR> well-ascertained animal size balance watch ray pod bottle brush
stair tower pike whale parrot-beaked
tron weight tapestry-covered well-graveled
lake dweller cross-brush self-wise world-forsaken deal board
punching press Plymouth colony
= ------=_NextPart_000_007B_01C6871B.333ADC00-- From ipsec-bounces@ietf.org Fri Jun 09 06:33:49 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoeIp-0007Dn-D1; Fri, 09 Jun 2006 06:33:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoeIo-0007BE-BY for Ipsec@ietf.org; Fri, 09 Jun 2006 06:33:18 -0400 Received: from wx-out-0102.google.com ([66.249.82.198]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoeIn-00025u-5N for Ipsec@ietf.org; Fri, 09 Jun 2006 06:33:18 -0400 Received: by wx-out-0102.google.com with SMTP id h26so490414wxd for ; Fri, 09 Jun 2006 03:33:16 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=QGXGToQKCxV+hlwuQm5Zjz9zrwNqtcZh5eJQYSgltsSEb6xB5I3RO3bpBs2TnFzlbWXMslQkEJV28c2bU8yCBl46g9UL90HflJWExHizpERS0st6T9yAYI51Ew6jULq97dKrNNrC2d+7jJBLuITQcLvTRbm9QzolCDFILS42sv0= Received: by 10.70.100.8 with SMTP id x8mr3321154wxb; Fri, 09 Jun 2006 03:33:16 -0700 (PDT) Received: by 10.70.29.18 with HTTP; Fri, 9 Jun 2006 03:33:16 -0700 (PDT) Message-ID: Date: Fri, 9 Jun 2006 16:03:16 +0530 From: "Poorna Pushkala B" To: Ipsec@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.3 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Subject: [Ipsec] Is it mandatory to have the incoming and outgoing SA protocol and encryption/auth algorithms same? 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="===============2068858970==" Errors-To: ipsec-bounces@ietf.org --===============2068858970== Content-Type: multipart/alternative; boundary="----=_Part_13277_18899293.1149849196013" ------=_Part_13277_18899293.1149849196013 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I am relatively new to ipsec. Is it mandatory to have the incoming and outgoing Security Association protocol (AH/ESP) and encryption/auth algorithms same? I went through RFC 2401, though it defines a Security Association, it is not clear if for a given VPN tunnel, the incoming and outgoing SAs should use the same protocol ( AH/ESP). Can you help me? Thanks & Regards Kala. B ------=_Part_13277_18899293.1149849196013 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,
I am relatively new to ipsec. 
Is it mandatory to have the incoming and outgoing Security Association protocol (AH/ESP) and encryption/auth algorithms same?
I went through RFC 2401, though it defines a Security Association, it is not clear if for a given VPN tunnel, the incoming and outgoing SAs should use the same protocol ( AH/ESP).

Can you help me?

Thanks & Regards
Kala. B

------=_Part_13277_18899293.1149849196013-- --===============2068858970== 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 --===============2068858970==-- From ipsec-bounces@ietf.org Fri Jun 09 06:39:11 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoeOT-0008Qc-1s; Fri, 09 Jun 2006 06:39:09 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoeOQ-0008QX-Tx for Ipsec@ietf.org; Fri, 09 Jun 2006 06:39:06 -0400 Received: from mail.pune.nevisnetworks.com ([220.225.34.210]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoeOP-0002gh-6Z for Ipsec@ietf.org; Fri, 09 Jun 2006 06:39:06 -0400 Received: from nevismail02.pune.nevisnetworks.com (nevismail02.pune.nevisnetworks.com [192.168.2.9]) by mail.pune.nevisnetworks.com (8.13.6/8.13.4) with ESMTP id k59Acx4e008540; Fri, 9 Jun 2006 16:08:59 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ipsec] Is it mandatory to have the incoming and outgoing SAprotocol and encryption/auth algorithms same? Date: Fri, 9 Jun 2006 16:08:57 +0530 Message-ID: <5BB5F96644960045BD3D1D85261FCE6C9EDE27@nevismail02.pune.nevisnetworks.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ipsec] Is it mandatory to have the incoming and outgoing SAprotocol and encryption/auth algorithms same? Thread-Index: AcaLsC5hWS2PZigRRfSdspk4ROO4wgAAESug From: "Gandhar Gokhale" To: "Poorna Pushkala B" X-Scanned-By: MIMEDefang 2.52 on 192.168.2.10 X-Spam-Score: 0.2 (/) X-Scan-Signature: 34d35111647d654d033d58d318c0d21a 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="===============1542456776==" Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1542456776== content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C68BB0.E94F669E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C68BB0.E94F669E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Does IKE negotiation not put this restriction automatically? As far as I remember there's no facility of negotiating inbound and outbound protocols separately.=20 BTW, what is the use case for such an asymmetry? =20 =20 Thanks and regards, Gandhar Gokhale -----Original Message----- From: Poorna Pushkala B [mailto:pushkala@gmail.com]=20 Sent: Friday, June 09, 2006 4:03 PM To: Ipsec@ietf.org Subject: [Ipsec] Is it mandatory to have the incoming and outgoing SAprotocol and encryption/auth algorithms same? Hi, I am relatively new to ipsec.=20=20 Is it mandatory to have the incoming and outgoing Security Association protocol (AH/ESP) and encryption/auth algorithms same? I went through RFC 2401, though it defines a Security Association, it is not clear if for a given VPN tunnel, the incoming and outgoing SAs should use the same protocol ( AH/ESP). Can you help me?=20 Thanks & Regards Kala. B ------_=_NextPart_001_01C68BB0.E94F669E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message Does=20 IKE negotiation not put this restriction automatically? As far as I remembe= r=20 there's no facility of negotiating inbound and outbound protocols separatel= y.=20 BTW,=20 what is the use case for such an asymmetry?     Thanks and regards, Gandhar Gokhale
-----Original Message-----
From: Poorna = Pushkala=20 B [mailto:pushkala@gmail.com]
Sent: Friday, June 09, 2006 4:03= =20 PM
To: Ipsec@ietf.org
Subject: [Ipsec] Is it mandator= y to=20 have the incoming and outgoing SAprotocol and encryption/auth algorithms= =20 same?

Hi,
I am relatively new to ipsec.&n= bsp;
Is it=20 mandatory to have the incoming and outgoing Security Association protocol= =20 (AH/ESP) and encryption/auth algorithms same?
I went through RFC 2401,= =20 though it defines a Security Association, it is not clear if for a given = VPN=20 tunnel, the incoming and outgoing SAs should use the same protocol (=20 AH/ESP).

Can you help me?

Thanks & Regards
Kala.=20 B

------_=_NextPart_001_01C68BB0.E94F669E-- --===============1542456776== 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 --===============1542456776==-- From ipsec-bounces@ietf.org Fri Jun 09 06:50:22 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoeZF-0001E6-QA; Fri, 09 Jun 2006 06:50:17 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoeZE-0001Ba-Op for Ipsec@ietf.org; Fri, 09 Jun 2006 06:50:16 -0400 Received: from wx-out-0102.google.com ([66.249.82.202]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FoeZC-000413-FV for Ipsec@ietf.org; Fri, 09 Jun 2006 06:50:16 -0400 Received: by wx-out-0102.google.com with SMTP id h26so492414wxd for ; Fri, 09 Jun 2006 03:50:14 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=EtYP5ueajrRjHqqwPz8+ZXn0Wnrkz3mxkTvry+lyZkCDreU67IV9eoCsyZqEtBwYWpLC5NXQx2NWGBEG6dgVSdTfpXngIpSAy9oMjJ3/Ge4BRgZDDAe4MaaFldlkh2xm1zd3/7AMpYbfGjqe2qaFeuQwwsvY9dS5eZSr0UtYHuk= Received: by 10.70.44.16 with SMTP id r16mr3301396wxr; Fri, 09 Jun 2006 03:50:14 -0700 (PDT) Received: by 10.70.29.18 with HTTP; Fri, 9 Jun 2006 03:50:14 -0700 (PDT) Message-ID: Date: Fri, 9 Jun 2006 16:20:14 +0530 From: "Poorna Pushkala B" To: "Gandhar Gokhale" Subject: Re: [Ipsec] Is it mandatory to have the incoming and outgoing SAprotocol and encryption/auth algorithms same? In-Reply-To: <5BB5F96644960045BD3D1D85261FCE6C9EDE27@nevismail02.pune.nevisnetworks.com> MIME-Version: 1.0 References: <5BB5F96644960045BD3D1D85261FCE6C9EDE27@nevismail02.pune.nevisnetworks.com> X-Spam-Score: 0.1 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be 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="===============1477881985==" Errors-To: ipsec-bounces@ietf.org --===============1477881985== Content-Type: multipart/alternative; boundary="----=_Part_13405_12919270.1149850214099" ------=_Part_13405_12919270.1149850214099 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, Thanks for your reply. Say I want a tunnel where I want all incoming traffic to be encrypted whereas outgoing traffic to be just authenticated and not encrypted? Thanks & Regards Kala On 6/9/06, Gandhar Gokhale wrote: > > Does IKE negotiation not put this restriction automatically? As far as I > remember there's no facility of negotiating inbound and outbound protocols > separately. BTW, what is the use case for such an asymmetry? Thanks > and regards, Gandhar Gokhale > > -----Original Message----- > *From:* Poorna Pushkala B [mailto:pushkala@gmail.com] > *Sent:* Friday, June 09, 2006 4:03 PM > *To:* Ipsec@ietf.org > *Subject:* [Ipsec] Is it mandatory to have the incoming and outgoing > SAprotocol and encryption/auth algorithms same? > > Hi, > I am relatively new to ipsec. > Is it mandatory to have the incoming and outgoing Security Association > protocol (AH/ESP) and encryption/auth algorithms same? > I went through RFC 2401, though it defines a Security Association, it is > not clear if for a given VPN tunnel, the incoming and outgoing SAs should > use the same protocol ( AH/ESP). > > Can you help me? > > Thanks & Regards > Kala. B > > ------=_Part_13405_12919270.1149850214099 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,
Thanks for your reply. Say I want a tunnel where I want all incoming traffic to be encrypted whereas outgoing traffic to be just authenticated and not encrypted?

Thanks & Regards
Kala

On 6/9/06, Gandhar Gokhale <gandhar.gokhale@nevisnetworks.com> wrote:
Does IKE negotiation not put this restriction automatically? As far as I remember there's no facility of negotiating inbound and outbound protocols separately. BTW, what is the use case for such an asymmetry?     Thanks and regards, Gandhar Gokhale
-----Original Message-----
From: Poorna Pushkala B [mailto:pushkala@gmail.com]
Sent: Friday, June 09, 2006 4:03 PM
To: Ipsec@ietf.org
Subject: [Ipsec] Is it mandatory to have the incoming and outgoing SAprotocol and encryption/auth algorithms same?

Hi,
I am relatively new to ipsec. 
Is it mandatory to have the incoming and outgoing Security Association protocol (AH/ESP) and encryption/auth algorithms same?
I went through RFC 2401, though it defines a Security Association, it is not clear if for a given VPN tunnel, the incoming and outgoing SAs should use the same protocol ( AH/ESP).

Can you help me?

Thanks & Regards
Kala. B


------=_Part_13405_12919270.1149850214099-- --===============1477881985== 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 --===============1477881985==-- From ipsec-bounces@ietf.org Fri Jun 09 07:22:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fof4g-000187-Ey; Fri, 09 Jun 2006 07:22:46 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fof4f-000181-Dl for Ipsec@ietf.org; Fri, 09 Jun 2006 07:22:45 -0400 Received: from burp.tkv.asdf.org ([212.16.99.49]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fof4d-0007WX-Tt for Ipsec@ietf.org; Fri, 09 Jun 2006 07:22:45 -0400 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.6/8.13.6/Debian-1) with ESMTP id k59BMf37016693; Fri, 9 Jun 2006 14:22:41 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.6/8.13.6/Submit) id k59BMehx016690; Fri, 9 Jun 2006 14:22:40 +0300 Date: Fri, 9 Jun 2006 14:22:40 +0300 Message-Id: <200606091122.k59BMehx016690@burp.tkv.asdf.org> From: Markku Savela To: pushkala@gmail.com In-reply-to: (pushkala@gmail.com) Subject: Re: [Ipsec] Is it mandatory to have the incoming and outgoing SAprotocol and encryption/auth algorithms same? References: <5BB5F96644960045BD3D1D85261FCE6C9EDE27@nevismail02.pune.nevisnetworks.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Cc: Ipsec@ietf.org, gandhar.gokhale@nevisnetworks.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: , Errors-To: ipsec-bounces@ietf.org > Thanks for your reply. Say I want a tunnel where I want all incoming > traffic to be encrypted whereas outgoing traffic to be just > authenticated and not encrypted? IKE has the limitation/simplification that symmetric SA's are used. The only way to get asymmetric is to use manual keys or some other private key negotiation (if your IPsec implementation can express asymmetric policy for inbound and outbound). _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 09 10:49:40 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoiIl-0005ag-Ss; Fri, 09 Jun 2006 10:49:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FoiIl-0005ZR-04 for Ipsec@ietf.org; Fri, 09 Jun 2006 10:49:31 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Foi7o-0006lo-Ny for Ipsec@ietf.org; Fri, 09 Jun 2006 10:38:13 -0400 Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Foi7o-0002fp-4F; Fri, 09 Jun 2006 10:38:12 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 9 Jun 2006 09:51:41 -0400 To: "Poorna Pushkala B" From: Stephen Kent Subject: Re: [Ipsec] Is it mandatory to have the incoming and outgoing SA protocol and encryption/auth algorithms same? Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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: , Errors-To: ipsec-bounces@ietf.org At 4:03 PM +0530 6/9/06, Poorna Pushkala B wrote: >Hi, >I am relatively new to ipsec. >Is it mandatory to have the incoming and outgoing Security >Association protocol (AH/ESP) and encryption/auth algorithms same? >I went through RFC 2401, though it defines a Security Association, >it is not clear if for a given VPN tunnel, the incoming and outgoing >SAs should use the same protocol ( AH/ESP). > >Can you help me? > >Thanks & Regards >Kala. B Yes, both SAs make use of the same security protocol and algorithms. Look at the definition of an SPD entry for confirmation of this convention. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 09 21:00:52 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1ForqA-0008Mj-U7; Fri, 09 Jun 2006 21:00:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Forq9-0008L1-95 for Ipsec@ietf.org; Fri, 09 Jun 2006 21:00:37 -0400 Received: from web55509.mail.re4.yahoo.com ([206.190.58.218]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Forq7-0002gq-Qp for Ipsec@ietf.org; Fri, 09 Jun 2006 21:00:37 -0400 Received: (qmail 22723 invoked by uid 60001); 10 Jun 2006 01:00:35 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com.ar; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=Jlti0UWbxjwPNP/OseMrcgUXOcECKx/k7ZlfOgJawDSjYL1ensJigKVY4G6dJrM/EUDsaQpYMUCj95nBjHLrb/cHD/jg+ZuWis11IB5SGXY8sOwYJ5iC2Ic0L5HTFsK8QW1FtXMeVgxMaHopQRYm60qRlC9EakhhJLIhsxGtfkk= ; Message-ID: <20060610010035.22721.qmail@web55509.mail.re4.yahoo.com> Received: from [201.198.239.67] by web55509.mail.re4.yahoo.com via HTTP; Sat, 10 Jun 2006 01:00:35 GMT Date: Sat, 10 Jun 2006 01:00:35 +0000 (GMT) From: Noel Keith To: Ipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 1.8 (+) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Cc: Subject: [Ipsec] IPsec support 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: , Errors-To: ipsec-bounces@ietf.org Hello All: I´d like to know if i use IPsec(only transport mode with ESP and AH) i need that my routers supports IPsec or just my Media Gateway Controller and Media Gateway. Cheers, Noel __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ˇgratis! ˇAbrí tu cuenta ya! - http://correo.yahoo.com.ar _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 12 11:01:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpnuH-00019I-CD; Mon, 12 Jun 2006 11:00:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpnuG-00019D-Jl for Ipsec@ietf.org; Mon, 12 Jun 2006 11:00:44 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FpnuF-0008Vr-DL for Ipsec@ietf.org; Mon, 12 Jun 2006 11:00:44 -0400 Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FpnuE-0000FH-6F; Mon, 12 Jun 2006 11:00:43 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <20060610010035.22721.qmail@web55509.mail.re4.yahoo.com> References: <20060610010035.22721.qmail@web55509.mail.re4.yahoo.com> Date: Mon, 12 Jun 2006 10:43:01 -0400 To: Noel Keith From: Stephen Kent Subject: Re: [Ipsec] IPsec support Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable 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: , Errors-To: ipsec-bounces@ietf.org At 1:00 AM +0000 6/10/06, Noel Keith wrote: >Hello All: > >I=B4d like to know if i use IPsec(only transport mode >with ESP and AH) i need that my routers supports IPsec >or just my Media Gateway Controller and Media Gateway. > >Cheers, > >Noel only the endpoints (e.g., the MGC and MG) need to=20 be aware of IPsec use in this context, not the=20 intermediate routers. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From agnellaabbott@cenara.com Mon Jun 12 14:58:19 2006 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FprcB-0001lF-Sg for ipsec-archive@lists.ietf.org; Mon, 12 Jun 2006 14:58:19 -0400 Received: from home-pool-174-2.com2com.ru ([195.98.174.2] helo=BABY) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fprc6-0007ne-AB for ipsec-archive@lists.ietf.org; Mon, 12 Jun 2006 14:58:15 -0400 Message-Id: <00ca01c68e48$20758500$171595cd@irvthvrm> From: "constantino fischer" To: "waylon corbett" Subject: Cash, guitar-shaped Date: Mon, 12 Jun 2006 13:48:40 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00CA_01C68E48.20758500" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Spam-Score: 4.9 (++++) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 This is a multi-part message in MIME format. ------=_NextPart_000_00CA_01C68E48.20758500 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Join and Play at the best Emperial zCASINOz!=20 As a Special Welcome TODAY, we will DOUBL your 1 Deposit up to 200 bucks!= =20 For example: Deposit 50 play with 100! Deposit 100 play with 200! Your FREE Bonuses will be INSTANTLY added to your acount! http://dennie.dogclb.org/dcas/ bad-headed ruby-set young-ladyfied cloak presser face hammer binnacle list cross hair well-reflected buckwheat tree Anti-christianism laurel-leaf oil ill-accoute= red quasi-formal sand-groper school section batule board connection angle sun plane worm conveyer bastard canna town-bred solar plexus dry-press sergeant-majorship key pin reddish-haired inheritance tax butt joint drill mounting trust maker world-excelling ------=_NextPart_000_00CA_01C68E48.20758500 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Join and Play at the best Emperial zCASINOz!
As a Special Welcome TODAY, we will DOUBL your 1 Deposit up to 200 bucks! <= BR>
For example:
Deposit 50 play with 100!
Deposit 100 play with 200!

Your FREE Bonuses will be INSTANTLY added to your acount!

Try us, inhere


bad-headed ruby-set young-ladyfied cloak presser face hammer
binnacle list cross hair
well-reflected buckwheat tree Anti-christianism laurel-leaf oil ill-accoute= red quasi-formal
sand-groper school section batule board connection angle sun plane
worm conveyer bastard canna town-bred
solar plexus dry-press sergeant-majorship
key pin reddish-haired inheritance tax butt joint drill mounting
trust maker world-excelling
= ------=_NextPart_000_00CA_01C68E48.20758500-- From ipsec-bounces@ietf.org Mon Jun 12 18:02:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpuUd-0002pi-9C; Mon, 12 Jun 2006 18:02:43 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FpuUb-0002ev-TQ for ipsec@ietf.org; Mon, 12 Jun 2006 18:02:41 -0400 Received: from web51309.mail.yahoo.com ([206.190.38.175]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FpuUa-00077B-MU for ipsec@ietf.org; Mon, 12 Jun 2006 18:02:41 -0400 Received: (qmail 8198 invoked by uid 60001); 12 Jun 2006 22:02:38 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=yVcAm0dl85VFXuEhzc8bB/81fG4GuX16pJSW8yk7J9SfeJWmR2gQJ4tGkJHSARf5rONTJsiSH1GEV3oA4KsQuaeW1CZI7TT+yzfrE0qkFnNcrCVyUt8uXMJCJxSHCZGGDPHJlTok8Ekvv8wmZpYT4hFza4yz62e/pbxhK2svP7w= ; Message-ID: <20060612220238.8196.qmail@web51309.mail.yahoo.com> Received: from [66.80.10.146] by web51309.mail.yahoo.com via HTTP; Mon, 12 Jun 2006 15:02:38 PDT Date: Mon, 12 Jun 2006 15:02:38 -0700 (PDT) From: Subha Venkataramanan To: ipsec@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Ipsec] Patent issues with IKE 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: , Errors-To: ipsec-bounces@ietf.org Hi List-members, Recently I came across some information that there are Certicom and Microsoft related patent issues with respect to IKE. Has anyone in the list gone through them, and are they valid? Certicom IPR has claims on DH Group weak key detection method. Microsoft patent relates to NAT-Traversal (port float). I haven't gone through the patent in details. Has anyone gone over it, and would like to share some information on the same ? Thanks, Subha __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 13 08:33:28 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq855-0004nS-VT; Tue, 13 Jun 2006 08:33:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fq853-0004nM-W8 for ipsec@ietf.org; Tue, 13 Jun 2006 08:33:13 -0400 Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fq852-0004tO-MI for ipsec@ietf.org; Tue, 13 Jun 2006 08:33:13 -0400 Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 13 Jun 2006 05:33:12 -0700 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id k5DCXCdq017277; Tue, 13 Jun 2006 05:33:12 -0700 Received: from irp-view7.cisco.com (irp-view7.cisco.com [171.70.65.144]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id k5DCX79t021907; Tue, 13 Jun 2006 05:33:07 -0700 (PDT) Date: Tue, 13 Jun 2006 05:33:06 -0700 (PDT) From: Scott Fluhrer To: Subha Venkataramanan Subject: Re: [Ipsec] Patent issues with IKE In-Reply-To: <20060612220238.8196.qmail@web51309.mail.yahoo.com> Message-ID: References: <20060612220238.8196.qmail@web51309.mail.yahoo.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed DKIM-Signature: a=rsa-sha1; q=dns; l=1752; t=1150201992; x=1151065992; c=relaxed/simple; s=sjdkim3001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sfluhrer@cisco.com; z=From:Scott=20Fluhrer=20 |Subject:Re=3A=20[Ipsec]=20Patent=20issues=20with=20IKE; X=v=3Dcisco.com=3B=20h=3Dz6eQuujNaIvvTs3/KShXFsx4aWA=3D; b=PUtISBhNTEpYwRjWR12vL2/VVt0wKSgd33nqYSe+/adHeczFiJ4E99WYGQKsCROD0ALZ8iHo zwS9iqQeH4K155vPVBYbx9xulvNqs5r69ydUcsLqIG9ml2Vz+KigKhVK; Authentication-Results: sj-dkim-3.cisco.com; header.From=sfluhrer@cisco.com; dkim=pass ( sig from cisco.com verified; ); X-Spam-Score: 1.8 (+) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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: , Errors-To: ipsec-bounces@ietf.org On Mon, 12 Jun 2006, Subha Venkataramanan wrote: > Hi List-members, > > Recently I came across some information that there are > Certicom and Microsoft related patent issues with > respect to IKE. > > Has anyone in the list gone through them, and are they > valid? > > Certicom IPR has claims on DH Group weak key detection > method. I have gone through it. I am not a lawyer, but it appeared to me to be totally spurious, at least as IKE is concerned. Their relevant patents were about ways to detect if the peer sent you a DH public value from a small subgroup (which an attacker might use in an active attack scenario). In the MODP DH groups that IKE uses, this amounts to comparing the received value against the value 1 (as there are no other subgroups of the group that IKE uses [1]). In the ECC DH groups that IKE uses, I believe this amounts to comparing the received value against the point at infinity, for the same reason. However: - The IKE RFCs never mandate (or even mention) such a check - This check is not required for security, as IKE has other methods of detecting if an active attacker modifies the DH public value in an IKE packet. > Microsoft patent relates to NAT-Traversal > (port float). I haven't gone through the patent in > details. > > Has anyone gone over it, and would like to share some > information on the same ? > > Thanks, > Subha > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.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 Jun 16 08:31:50 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrDUA-0004Go-0Z; Fri, 16 Jun 2006 08:31:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FrDU8-0004Gj-Qs for ipsec@ietf.org; Fri, 16 Jun 2006 08:31:36 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FrDU6-0000Z6-8c for ipsec@ietf.org; Fri, 16 Jun 2006 08:31:36 -0400 Received: from YSHEFFER (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id k5GCVRNH027495 for ; Fri, 16 Jun 2006 15:31:32 +0300 (IDT) Message-Id: <200606161231.k5GCVRNH027495@michael.checkpoint.com> Date: Fri, 16 Jun 2006 15:31:27 +0300 From: Yaron Sheffer To: ipsec@ietf.org MIME-Version: 1.0 X-Mailer: Sun Outlook Connector 7.1.228.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: QUOTED-PRINTABLE X-Spam-Score: 0.0 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Subject: [Ipsec] FW: I-D ACTION:draft-sheffer-ipsec-secure-beacon-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: ipsec-bounces@ietf.org Hi All, This is an individual submission, but I would appreciate your comments to t= he IPsec mailing list. Thanks, =09Yaron=20 -----Original Message----- From: Internet-Drafts@ietf.org [mailto:Internet-Drafts@ietf.org]=20 Sent: Thursday, June 15, 2006 22:50 To: i-d-announce@ietf.org Subject: I-D ACTION:draft-sheffer-ipsec-secure-beacon-00.txt=20 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. =09Title=09=09: Secure Beacon: Securely Detecting a Trusted Network =09Author(s)=09: Y. Sheffer =09Filename=09: draft-sheffer-ipsec-secure-beacon-00.txt =09Pages=09=09: 15 =09Date=09=09: 2006-6-15 =09 Remote access clients, in particular IPsec-based ones, are heavily deployed= in enterprise environments. In many enterprises the security policy allow= s remote-access clients to switch to unprotected operation when entering th= e trusted network. This document specifies a method that lets a client det= ect this situation in a secure manner, with the help of a security gateway.= We propose a minor extension to IKEv2 to achieve this goal. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-sheffer-ipsec-secure-beacon-00.tx= t To remove yourself from the I-D Announcement list, send a message to i-d-an= nounce-request@ietf.org with the word unsubscribe in the body of the messag= e. =20 You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the usernam= e "anonymous" and a password of your e-mail address. After logging in, type= "cd internet-drafts" and then =09"get draft-sheffer-ipsec-secure-beacon-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/s= hadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: =09mailserv@ietf.org. In the body type: =09"FILE /internet-drafts/draft-sheffer-ipsec-secure-beacon-00.txt". =09 NOTE:=09The mail server at ietf.org can return the document in =09MIME-encoded form by using the "mpack" utility. To use this =09feature, insert the command "ENCODING mime" before the "FILE" =09command. To decode the response(s), you will need "munpack" or =09a MIME-compliant mail reader. Different MIME-compliant mail readers =09exhibit different behavior, especially when dealing with =09"multipart" MIME messages (i.e. documents which have been split =09up into multiple messages), so check your local documentation on =09how to manipulate these messages. =09=09 =09=09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 20 12:38:53 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsjFO-0000mQ-Le; Tue, 20 Jun 2006 12:38:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsjFN-0000ig-H4 for ipsec@ietf.org; Tue, 20 Jun 2006 12:38:37 -0400 Received: from web54715.mail.yahoo.com ([206.190.49.205]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FsjFM-0004MW-6o for ipsec@ietf.org; Tue, 20 Jun 2006 12:38:37 -0400 Received: (qmail 80505 invoked by uid 60001); 20 Jun 2006 16:38:35 -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=ld6u+weuAnGjr9NrSdaU0FA7kHmlWBen75W1+858it8VmeypG/FE2EY+QZL9ML5NSgjEhNooKCQm8TiScX5HbsIx5pnSKpdFIzzpWnK7M2qGKgBxVmrqIojCO++Q+494jYoSsPeYG5PCoNcbo57SalsQJ8McfoTi9gNqqLgZ1Zo= ; Message-ID: <20060620163835.80503.qmail@web54715.mail.yahoo.com> Received: from [72.16.237.66] by web54715.mail.yahoo.com via HTTP; Tue, 20 Jun 2006 09:38:35 PDT Date: Tue, 20 Jun 2006 09:38:35 -0700 (PDT) From: siddhartha gandhi To: ipsec@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Ipsec] IPsec manual keying 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="===============0152801008==" Errors-To: ipsec-bounces@ietf.org --===============0152801008== Content-Type: multipart/alternative; boundary="0-181127306-1150821515=:78727" Content-Transfer-Encoding: 8bit --0-181127306-1150821515=:78727 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I am looking for documents that specify how to do manual keying in IPsec. any pointers ?? - Siddhartha --------------------------------- Ring'em or ping'em. Make PC-to-phone calls as low as 1˘/min with Yahoo! Messenger with Voice. --0-181127306-1150821515=:78727 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: 8bit I am looking for documents that specify how to do manual keying in IPsec.

any pointers ??

- Siddhartha

Ring'em or ping'em. Make PC-to-phone calls as low as 1˘/min with Yahoo! Messenger with Voice. --0-181127306-1150821515=:78727-- --===============0152801008== 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 --===============0152801008==-- From ipsec-bounces@ietf.org Tue Jun 20 13:34:34 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsk7T-0001gN-Qy; Tue, 20 Jun 2006 13:34:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fsk7S-0001fK-B6 for ipsec@ietf.org; Tue, 20 Jun 2006 13:34:30 -0400 Received: from nwkea-mail-5.sun.com ([192.18.42.27]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fsk7Q-0003zn-VA for ipsec@ietf.org; Tue, 20 Jun 2006 13:34:30 -0400 Received: from eastmail4bur.east.Sun.COM ([129.148.13.1]) by nwkea-mail-5.sun.com (8.13.6+Sun/8.12.9) with ESMTP id k5KHYRNY027530 for ; Tue, 20 Jun 2006 10:34:28 -0700 (PDT) Received: from kebe.east.sun.com (kebe.East.Sun.COM [129.148.174.48]) by eastmail4bur.east.Sun.COM (8.13.6+Sun/8.13.6/ENSMAIL, v2.2) with ESMTP id k5KHYRFk015288 for ; Tue, 20 Jun 2006 13:34:27 -0400 (EDT) Received: from kebe.east.sun.com (localhost [127.0.0.1]) by kebe.east.sun.com (8.13.6+Sun/8.13.6) with ESMTP id k5KHWtsm024946; Tue, 20 Jun 2006 13:32:55 -0400 (EDT) Received: (from danmcd@localhost) by kebe.east.sun.com (8.13.6+Sun/8.13.6/Submit) id k5KHWtBx024945; Tue, 20 Jun 2006 13:32:55 -0400 (EDT) Date: Tue, 20 Jun 2006 13:32:55 -0400 From: Dan McDonald To: siddhartha gandhi Subject: Re: [Ipsec] IPsec manual keying Message-ID: <20060620173255.GD24844@kebe.East.Sun.COM> References: <20060620163835.80503.qmail@web54715.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060620163835.80503.qmail@web54715.mail.yahoo.com> User-Agent: Mutt/1.4.1i Organization: Sun Microsystems, Inc. - Solaris Networking & Security X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 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: , Errors-To: ipsec-bounces@ietf.org On Tue, Jun 20, 2006 at 09:38:35AM -0700, siddhartha gandhi wrote: > I am looking for documents that specify how to do manual keying in IPsec. > > any pointers ?? If you have a Solaris/OpenSolaris box, read the ipseckey(1m) man page. BSD's based on the KAME stack have their setkey(8) utility also. (I even think Linux, while not KAME per se, has adopted setkey(8) also.) Dan _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 21 05:18:19 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsyqY-0001o4-JL; Wed, 21 Jun 2006 05:18:02 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FsyqW-0001ml-J5 for ipsec@ietf.org; Wed, 21 Jun 2006 05:18:00 -0400 Received: from szxga01-in.huawei.com ([61.144.161.53] helo=huawei.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FsyqU-0003I8-ON for ipsec@ietf.org; Wed, 21 Jun 2006 05:18:00 -0400 Received: from huawei.com (szxga01-in [172.24.2.3]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J17006OLDKFSA@szxga01-in.huawei.com> for ipsec@ietf.org; Wed, 21 Jun 2006 17:12:16 +0800 (CST) Received: from huawei.com ([172.24.1.24]) by szxga01-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTP id <0J1700CZXDKFU3@szxga01-in.huawei.com> for ipsec@ietf.org; Wed, 21 Jun 2006 17:12:15 +0800 (CST) Received: from l52008 ([10.110.114.60]) by szxml04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 1.25 (built Mar 3 2004)) with ESMTPA id <0J1700ML3DZJPF@szxml04-in.huawei.com> for ipsec@ietf.org; Wed, 21 Jun 2006 17:21:20 +0800 (CST) Date: Wed, 21 Jun 2006 17:10:34 +0800 From: Liu Ya To: ipsec@ietf.org Message-id: <00d101c69512$8df261e0$3c726e0a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-Priority: 3 X-MSMail-priority: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Ipsec] A question about Combined Mode Algorithms 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="===============0122336066==" Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0122336066== Content-type: multipart/alternative; boundary="Boundary_(ID_ixX1CPpE3fNdMAM83S3kxA)" This is a multi-part message in MIME format. --Boundary_(ID_ixX1CPpE3fNdMAM83S3kxA) Content-type: text/plain; charset=WINDOWS-1252 Content-transfer-encoding: 7BIT Hi all, I have a question about "Combined Mode Algorithms" metioned in 3.2.3 of RFC4303. But IKEv2, RFC4306, does not provide any transforms about that type of algorithms. Can you tell me if there is standard combined mode algorithm for ESP? If any, how to use it in ESP? Negotiate with IKEv2? Thanks. Liu Ya --Boundary_(ID_ixX1CPpE3fNdMAM83S3kxA) Content-type: text/html; charset=WINDOWS-1252 Content-transfer-encoding: 7BIT
Hi all,
 
I have a question about "Combined Mode Algorithms" metioned in 3.2.3 of RFC4303. But IKEv2, RFC4306, does not provide any transforms about that type of algorithms. Can you tell me if there is standard combined mode algorithm for ESP? If any, how to use it in ESP? Negotiate with IKEv2? 
Thanks.
Liu Ya
--Boundary_(ID_ixX1CPpE3fNdMAM83S3kxA)-- --===============0122336066== 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 --===============0122336066==-- From ipsec-bounces@ietf.org Wed Jun 21 05:54:51 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FszQ5-0005ce-QS; Wed, 21 Jun 2006 05:54:45 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FszQ4-0005cP-F8 for ipsec@ietf.org; Wed, 21 Jun 2006 05:54:44 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FszQ2-0001SD-W4 for ipsec@ietf.org; Wed, 21 Jun 2006 05:54:44 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5L9saSr028112; Wed, 21 Jun 2006 12:54:38 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Jun 2006 12:54:37 +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 Jun 2006 12:54:36 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] A question about Combined Mode Algorithms Date: Wed, 21 Jun 2006 12:54:38 +0300 Message-ID: In-Reply-To: <00d101c69512$8df261e0$3c726e0a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ipsec] A question about Combined Mode Algorithms Thread-Index: AcaVFS1XS8XMduD9T+6iuUzBnQJn/AAAjT0Q From: To: , X-OriginalArrivalTime: 21 Jun 2006 09:54:36.0204 (UTC) FILETIME=[B43936C0:01C69518] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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: , Errors-To: ipsec-bounces@ietf.org Hi, There are currently two combined-mode algorithms for ESP, AES-CCM=20 (RFC 4309) and AES-GCM (RFC 4106). In IKEv2, they're negotiated as encryption algorithms: for example, to propose "AES CCM with an 8-octet ICV", you would include one type 1 transform (encryption algorithm) with value 14 (and the key length attribute), but no=20 type 3 transforms (integrity algorithm). Best regards, Pasi -----Original Message----- > From: ext Liu Ya [mailto:liuya@huawei.com]=20 > Sent: 21 June, 2006 12:11 > To: ipsec@ietf.org > Subject: [Ipsec] A question about Combined Mode Algorithms > > Hi all, > > I have a question about "Combined Mode Algorithms" metioned in 3.2.3 > of RFC4303. But IKEv2, RFC4306, does not provide any transforms > about that type of algorithms. Can you tell me if there is standard > combined mode algorithm for ESP? If any, how to use it in ESP? > Negotiate with IKEv2? > > Thanks. > Liu Ya =20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 21 08:27:23 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft1nf-0002St-KI; Wed, 21 Jun 2006 08:27:15 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Ft1nd-0002So-Mx for ipsec@ietf.org; Wed, 21 Jun 2006 08:27:13 -0400 Received: from woodstock.binhost.com ([66.150.120.2]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1Ft1nc-0006Pw-8N for ipsec@ietf.org; Wed, 21 Jun 2006 08:27:13 -0400 Received: (qmail 14600 invoked by uid 0); 21 Jun 2006 12:27:10 -0000 Received: from unknown (HELO THINKPADR52.vigilsec.com) (71.126.181.11) by woodstock.binhost.com with SMTP; 21 Jun 2006 12:27:10 -0000 Message-Id: <7.0.0.16.2.20060621082433.0715cb78@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.16 Date: Wed, 21 Jun 2006 08:27:02 -0400 To: Liu Ya ,ipsec@ietf.org From: Russ Housley Subject: Re: [Ipsec] A question about Combined Mode Algorithms In-Reply-To: <00d101c69512$8df261e0$3c726e0a@china.huawei.com> References: <00d101c69512$8df261e0$3c726e0a@china.huawei.com> Mime-Version: 1.0 X-Spam-Score: 1.3 (+) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 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: , Content-Type: multipart/mixed; boundary="===============0537173506==" Errors-To: ipsec-bounces@ietf.org --===============0537173506== Content-Type: text/html; charset="us-ascii" See RFC 4309, which is the first combined mode specification that was published.  Also see RFC 4106, which is the second combined mode specification that was pubished.

Russ


At 05:10 AM 6/21/2006, Liu Ya wrote:
Hi all,
 
I have a question about "Combined Mode Algorithms" metioned in 3.2.3 of RFC4303. But IKEv2, RFC4306, does not provide any transforms about that type of algorithms. Can you tell me if there is standard combined mode algorithm for ESP? If any, how to use it in ESP? Negotiate with IKEv2?
Thanks.
Liu Ya
_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec
--===============0537173506== 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 --===============0537173506==-- From ipsec-bounces@ietf.org Thu Jun 22 13:05:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtSbp-0001QE-5N; Thu, 22 Jun 2006 13:04:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtSbn-0001Q8-Ls for ipsec@ietf.org; Thu, 22 Jun 2006 13:04:47 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtSbm-00010G-Ey for ipsec@ietf.org; Thu, 22 Jun 2006 13:04:47 -0400 Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FtSbl-0003e0-5c; Thu, 22 Jun 2006 13:04:45 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <00d101c69512$8df261e0$3c726e0a@china.huawei.com> References: <00d101c69512$8df261e0$3c726e0a@china.huawei.com> Date: Thu, 22 Jun 2006 12:55:28 -0400 To: Liu Ya From: Stephen Kent Subject: Re: [Ipsec] A question about Combined Mode Algorithms X-Spam-Score: 0.1 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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="===============0034690100==" Errors-To: ipsec-bounces@ietf.org --===============0034690100== Content-Type: multipart/alternative; boundary="============_-1061126610==_ma============" --============_-1061126610==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 5:10 PM +0800 6/21/06, Liu Ya wrote: >Hi all, > >I have a question about "Combined Mode Algorithms" metioned in 3.2.3 >of RFC4303. But IKEv2, RFC4306, does not provide any transforms >about that type of algorithms. Can you tell me if there is standard >combined mode algorithm for ESP? If any, how to use it in ESP? >Negotiate with IKEv2? > >Thanks. > >Liu Ya RFCs 4106 and 4309 define examples combined modes for use with ESP. Steve --============_-1061126610==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Ipsec] A question about Combined Mode Algorithms
At 5:10 PM +0800 6/21/06, Liu Ya wrote:
Hi all,
 
I have a question about "Combined Mode Algorithms" metioned in 3.2.3 of RFC4303. But IKEv2, RFC4306, does not provide any transforms about that type of algorithms. Can you tell me if there is standard combined mode algorithm for ESP? If any, how to use it in ESP? Negotiate with IKEv2? 
Thanks.
Liu Ya

RFCs 4106 and 4309 define examples combined modes for use with ESP.

Steve
--============_-1061126610==_ma============-- --===============0034690100== 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 --===============0034690100==-- From ipsec-bounces@ietf.org Thu Jun 22 14:00:10 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtTTK-0007RE-Du; Thu, 22 Jun 2006 14:00:06 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtTTJ-0007QH-1Z for ipsec@ietf.org; Thu, 22 Jun 2006 14:00:05 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtTTH-00044A-MB for ipsec@ietf.org; Thu, 22 Jun 2006 14:00:05 -0400 Received: from [10.20.30.249] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5MI01Of007618 for ; Thu, 22 Jun 2006 11:00:02 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 22 Jun 2006 11:00:01 -0700 To: IPsec WG From: The IESG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Ipsec] Last Call: 'IKE and IKEv2 Authentication Using ECDSA' to Proposed Standard (draft-ietf-ipsec-ike-auth-ecdsa) 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: , Errors-To: ipsec-bounces@ietf.org The IESG has received a request from an individual submitter to consider the following document: - 'IKE and IKEv2 Authentication Using ECDSA ' as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-07-20. The file can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ike-auth-ecdsa-05.txt Also, this IPR disclosure may be of inerest https://datatracker.ietf.org/public/ipr_detail_show.cgi?ipr_id=695 Finally, this document contains a normative reference to a document in the RFC Editor queue that will be published as an Informational RFC. The normative reference is to draft-ietf-ipsec-ike-ecp-groups-02.txt. _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jun 22 15:47:41 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtV9G-00059A-Ic; Thu, 22 Jun 2006 15:47:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FtV9F-00058s-QA for ipsec@ietf.org; Thu, 22 Jun 2006 15:47:29 -0400 Received: from outbound-res.frontbridge.com ([63.161.60.49] helo=outbound2-res-R.bigfish.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FtV9E-0004BA-Gq for ipsec@ietf.org; Thu, 22 Jun 2006 15:47:29 -0400 Received: from outbound2-res.bigfish.com (localhost.localdomain [127.0.0.1]) by outbound2-res-R.bigfish.com (Postfix) with ESMTP id 9B60773B0CB for ; Thu, 22 Jun 2006 19:46:51 +0000 (UTC) Received: from mail3-res-R.bigfish.com (unknown [172.18.16.1]) by outbound2-res.bigfish.com (Postfix) with ESMTP id 947F873B0CA for ; Thu, 22 Jun 2006 19:46:51 +0000 (UTC) Received: from mail3-res.bigfish.com (localhost.localdomain [127.0.0.1]) by mail3-res-R.bigfish.com (Postfix) with ESMTP id 878BC6D3A38 for ; Thu, 22 Jun 2006 19:46:51 +0000 (UTC) X-BigFish: VP Received: by mail3-res (MessageSwitch) id 1151005610945402_7374; Thu, 22 Jun 2006 19:46:50 +0000 (UCT) Received: from sjcxch03.tbu.com (mailman1.hifn.com [208.10.194.50]) by mail3-res.bigfish.com (Postfix) with ESMTP id A16B16D4479 for ; Thu, 22 Jun 2006 19:46:50 +0000 (UTC) Received: from RTPXCH01.tbu.com ([172.18.3.251]) by sjcxch03.tbu.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 22 Jun 2006 12:46:49 -0700 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Thu, 22 Jun 2006 15:46:44 -0400 Message-ID: <5FF564CB81DEE64EB76254D49013DC3362A51B@RTPXCH01.tbu.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Clarification on rfc4543 Thread-Index: AcaWNJdX4qeWqV/UR4mPKT9WO/W7Qw== From: "Ray Savarda" To: X-OriginalArrivalTime: 22 Jun 2006 19:46:49.0563 (UTC) FILETIME=[9A2B42B0:01C69634] X-Spam-Score: 0.1 (/) X-Scan-Signature: c83ccb5cc10e751496398f1233ca9c3a Subject: [Ipsec] Clarification on rfc4543 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="===============0153608520==" Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0153608520== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C69634.976FA47F" This is a multi-part message in MIME format. ------_=_NextPart_001_01C69634.976FA47F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Excuse me if this has been asked/answered already, but I spent a fair amount of time looking and didn't find any previous conversations regarding it anywhere online. =20 In RFC4543, Section 3.5, Figure 4, it (to me, anyway) clearly shows the IV included in the ICV calculation for ENCR_NULL_AUTH_AES_GMAC.=20 Section 3.3 also specifies that the AAD includes the payload, and 3.1 specifies that the IV is included in the ESP payload, collectively implying the IV is included in the AAD. =20 However, in section 7, second sentence, we have: " In ENCR_NULL_AUTH_AES_GMAC, the IV is not included in either the plaintext or the additional authenticated data." Am I misinterpreting something?=20 =20 Also, is it correct to assume that in AH mode, since the IV is present at the beginning of the ICV field in the AH header, that it is also included in the ICV calculation for that mode?=20 =20 Lastly (bear with me), any chance there are a couple sample test vectors available somewhere that would help ensure there is no ambiguity in the interpretation of these new ESP/AH Algorithms?=20 =20 Thanks! Ray =20 ------_=_NextPart_001_01C69634.976FA47F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Excuse = me if this=20 has been asked/answered already, but I spent a fair amount of time = looking and=20 didn't find any previous conversations regarding it anywhere=20 online.
 
In = RFC4543, Section=20 3.5, Figure 4, it (to me, anyway) clearly shows the IV included in the = ICV=20 calculation for ENCR_NULL_AUTH_AES_GMAC.
Section 3.3 also=20 specifies that the AAD includes the payload, and 3.1 specifies that = the IV=20 is included in the ESP payload, collectively implying the IV is = included in=20 the AAD.
 
However, in section=20 7, second sentence, we have:

" = In=20 ENCR_NULL_AUTH_AES_GMAC, the IV = is not=20 included in either the plaintext or the additional authenticated data."

=
Am I = misinterpreting=20 something?
 
Also, = is it correct=20 to assume that in AH mode, since the IV is present at the beginning of = the ICV=20 field in the AH header, that it is also included in the ICV calculation = for that=20 mode?
 
Lastly = (bear with=20 me), any chance there are a couple sample test vectors available = somewhere=20 that would help ensure there is no ambiguity in the interpretation of = these new=20 ESP/AH Algorithms?
 
Thanks!
Ray
 
------_=_NextPart_001_01C69634.976FA47F-- --===============0153608520== 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 --===============0153608520==-- From ipsec-bounces@ietf.org Mon Jun 26 12:19:01 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FutnK-0007a2-93; Mon, 26 Jun 2006 12:18:38 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FutnI-0007Zo-IF for ipsec@ietf.org; Mon, 26 Jun 2006 12:18:36 -0400 Received: from balder-227.proper.com ([192.245.12.227]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FutnH-0005BJ-6F for ipsec@ietf.org; Mon, 26 Jun 2006 12:18:36 -0400 Received: from [10.20.30.249] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id k5QGIXYU087298 for ; Mon, 26 Jun 2006 09:18:34 -0700 (MST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 26 Jun 2006 09:18:31 -0700 To: IPsec WG From: The IESG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Ipsec] Last Call: 'Multiple Authentication Exchanges in IKEv2' to Experimental RFC (draft-eronen-ipsec-ikev2-multiple-auth) 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: , Errors-To: ipsec-bounces@ietf.org The IESG has received a request from an individual submitter to consider the following document: - 'Multiple Authentication Exchanges in IKEv2 ' as an Experimental RFC IKEv2 supports several mechanisms for authenticating the parties, including signatures with public-key certificates, shared secrets, and Extensible Authentication Protocol (EAP) methods. Currently, each endpoint uses only one of these mechanisms to authenticate itself. This document specifies an extension to IKEv2 that allows the use of multiple authentication exchanges, either using different mechanisms or the same mechanism. The document has been stable for some time. It is also a 3GPP dependency for their "WLAN Interworking - Private Network access from WLAN 3GPP IP Access" work item. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-07-24. The file can be obtained via http://www.ietf.org/internet-drafts/draft-eronen-ipsec-ikev2-multiple-auth-01.tx t _______________________________________________ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 26 15:19:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuwc8-0003Rv-Dv; Mon, 26 Jun 2006 15:19:16 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fuwc6-0003Py-HU for ipsec@ietf.org; Mon, 26 Jun 2006 15:19:15 -0400 Received: from mx11.bbn.com ([128.33.0.80]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fuwc5-0004l6-Ay for ipsec@ietf.org; Mon, 26 Jun 2006 15:19:14 -0400 Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1Fuwc2-0002nw-5V; Mon, 26 Jun 2006 15:19:10 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200606161231.k5GCVRNH027495@michael.checkpoint.com> References: <200606161231.k5GCVRNH027495@michael.checkpoint.com> Date: Mon, 26 Jun 2006 15:19:11 -0400 To: Yaron Sheffer From: Stephen Kent Subject: Re: [Ipsec] FW: I-D ACTION:draft-sheffer-ipsec-secure-beacon-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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: , Errors-To: ipsec-bounces@ietf.org At 3:31 PM +0300 6/16/06, Yaron Sheffer wrote: >Hi All, > >This is an individual submission, but I would appreciate your >comments to the IPsec mailing list. > >Thanks, > Yaron > Yaron, The I-D talks about the extension to IKE to support the indicated functionality. It does not say how the client behaves (in the context of the IPsec model in 4301) in response to the SECURE_NETWORK_DETECTED notification in message 2. for example, this notification might be interpreted as temporarily changing the SPD entry for the address space in the IKE proposal, to make it a BYPASS entry. Or maybe the intent is to leave the SPD entry alone, but put an SAD (and SPD cache) entry in place for the specified address/protocol/port fields. However, the document provides no description of the intended behavior relative to 4301, so it is incomplete in that important respect. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 27 07:57:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvCBZ-0006hn-AU; Tue, 27 Jun 2006 07:56:53 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvCBX-0006hi-WB for ipsec@ietf.org; Tue, 27 Jun 2006 07:56:52 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvCBW-00075I-Gt for ipsec@ietf.org; Tue, 27 Jun 2006 07:56:51 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5RBumYx011236 for ; Tue, 27 Jun 2006 14:56:49 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 14:56:40 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 27 Jun 2006 14:56:39 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 27 Jun 2006 14:56:39 +0300 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Error notification in IKE_AUTH response? Thread-Index: AcaZ4L++BNEl0i3YTCKMqqUQEdMC2w== From: To: X-OriginalArrivalTime: 27 Jun 2006 11:56:39.0476 (UTC) FILETIME=[BFB65740:01C699E0] X-Spam-Score: 0.2 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Subject: [Ipsec] Error notification in IKE_AUTH response? 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: , Errors-To: ipsec-bounces@ietf.org Hi, Section 4.2 of the clarifications draft says that if the initiator receives an error notification during IKE_AUTH, the IKE_SA is created as usual _if_ the error is related to the CHILD_SA creation piggybacked on the IKE_AUTH exchange (NO_PROPOSAL_CHOSEN, TS_UNACCEPTABLE, SINGLE_PAIR_REQUIRED, INTERNAL_ADDRESS_FAILURE, or FAILED_CP_REQUIRED). Presumably, the notification would be placed in the IKE_AUTH response that would usually contain the SA/TSi/TSr payloads, and SA/TSi/TSr are omitted. The peers could continue using the IKE_SA for new INFORMATIONAL/CREATE_CHILD_SA exchanges, or if they don't want to, must close the IKE_SA with an INFORMATIONAL exchange containing the Delete payload. However, neither RFC4306 nor the clarifications draft explicitly=20 says what should happen if an error notification other than those=20 listed in Section 4.2 is received. RFC 4306 Section 3.10.1 also says that "An implementation receiving a Notify payload with one of these types that it does not recognize in a response MUST assume that the corresponding request has failed entirely." Presumably, this means that the IKE_SA has not been succesfully created, so it cannot be used for any additional=20 exchanges (such as Delete), and the conversation stops there. But what about the other error notification types listed in Section 3.10.1, such as AUTHENTICATION_FAILED? Do they also mean that creating the IKE_SA failed (and thus conversation stops there), or would some of them allow continuing the use of the IKE_SA? And explicitly deleting it with Delete payload if the IKE_SA is not needed anymore? Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 27 18:37:48 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvMBS-0002sO-Cx; Tue, 27 Jun 2006 18:37:26 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvMBQ-0002lS-RU for ipsec@ietf.org; Tue, 27 Jun 2006 18:37:24 -0400 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 1FvMBP-0004AU-98 for ipsec@ietf.org; Tue, 27 Jun 2006 18:37:24 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.5.20060308/8.12.10) with ESMTP id k5RMbFir011336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 28 Jun 2006 01:37:15 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.5.20060308/8.12.11) id k5RMbE08002505; Wed, 28 Jun 2006 01:37:14 +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: <17569.45850.498950.974466@fireball.kivinen.iki.fi> Date: Wed, 28 Jun 2006 01:37:14 +0300 From: Tero Kivinen To: Subject: [Ipsec] Error notification in IKE_AUTH response? In-Reply-To: References: X-Mailer: VM 7.19 under Emacs 21.4.1 X-Edit-Time: 5 min X-Total-Time: 4 min X-Spam-Score: 0.1 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 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: , Errors-To: ipsec-bounces@ietf.org Pasi.Eronen@nokia.com writes: > However, neither RFC4306 nor the clarifications draft explicitly > says what should happen if an error notification other than those > listed in Section 4.2 is received. You you receive error notification (notify code < 16383) then the exchange failed, meaning if this was IKE_AUTH or IKE_SA_INIT then the exchange failed, and no IKE SA was created. Sending delete notification will not help after that as most likely the other end didn't manage to create IKE SA context and deleted the IKE SA already. > RFC 4306 Section 3.10.1 also says that "An implementation receiving a > Notify payload with one of these types that it does not recognize in a > response MUST assume that the corresponding request has failed > entirely." Presumably, this means that the IKE_SA has not been > succesfully created, so it cannot be used for any additional > exchanges (such as Delete), and the conversation stops there. Yes, I would say that is the only way to interpret that situation. > But what about the other error notification types listed in Section > 3.10.1, such as AUTHENTICATION_FAILED? Do they also mean that > creating the IKE_SA failed (and thus conversation stops there), > or would some of them allow continuing the use of the IKE_SA? > And explicitly deleting it with Delete payload if the IKE_SA > is not needed anymore? Same thing with those error codes. For example the AUTHENTICATION_FAILED or INVALID_SYNTAX always means that the other end could not create the IKE SA (either authentication failed, or something else went wrong). -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 27 22:07:07 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvPS5-0001dd-D9; Tue, 27 Jun 2006 22:06:49 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvPS3-0001dY-SD for ipsec@ietf.org; Tue, 27 Jun 2006 22:06:47 -0400 Received: from athena.kddi.com ([210.141.112.39] helo=UTMC1104.kddi.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvPS3-0004Hq-6n for ipsec@ietf.org; Tue, 27 Jun 2006 22:06:47 -0400 Received: from usjk1038 (unknown [10.5.16.70]) by UTMC1104.kddi.com (Postfix) with SMTP id 2A38E27DE for ; Wed, 28 Jun 2006 11:06:45 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with SMTP id 382621A77 for ; Wed, 28 Jun 2006 11:06:40 +0900 (JST) Received: from UTMC1112.kddi.com (unknown [10.5.16.9]) by UTMC1122.kddi.com (Postfix) with ESMTP id 66BBA1A0C; Wed, 28 Jun 2006 11:06:34 +0900 (JST) Received: from [10.100.120.154] ([10.100.120.154] [10.100.120.154]) by post-ims.kddi.com with ESMTP; Wed, 28 Jun 2006 11:06:34 +0900 Message-Id: <44A1E428.3040003@kddi.com> Date: Wed, 28 Jun 2006 11:06:32 +0900 From: Kimihiro OHKI User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit X-WAuditID: 0606281106400000125358 X-Spam-Score: 0.0 (/) X-Scan-Signature: ff03b0075c3fc728d7d60a15b4ee1ad2 Subject: [Ipsec] IPv6 Configuration 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: , Errors-To: ipsec-bounces@ietf.org Hi All, I would like to clarify IKEv2 specification regarding IPv6 configuration. Assumptions: - Host A is an IKEv2 initiator. - Gateway B is an IKEv2 responder. - The Gateway B has policy to allocate a globally unique /64 prefix to each host (per IKE_SA). - The Host A wants to use multiple interface identifiers under the assigned /64 prefix. The Host A itself may use them (e.g. using privacy extensions), or other hosts which connect to the Host A may use some of them. - The Host A wants to use common IPsec_SA for the multiple interface identifiers. Clarifications: I would like to know if the following example scenarios comply with IKEv2 specification. To be more precise, it is not clear for me how to configure (add/change/delete) inner IP addresses on the existing IPsec_SA. [Scenario-1] In case that the following exchange is performed during initial (IKE_AUTH) negotiation, CP(CFG_REQUEST) = INTERNAL_IP6_ADDRESS(::2:3:4:5/64) TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) CP(CFG_REPLY) = INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5) TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) Note: The negotiated TSi is identical to the authorized INTERNAL_IP6_ADDRESS in this scenario. If the Host A wants to use additional interface identifiers, is it OK for the Host A to activates INFORMATIONAL exchange as follows? CP(CFG_REQUEST) = INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) INTERNAL_IP6_ADDRESS(2001:DB8:0:1:6:7:8:9/64) TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) CP(CFG_REPLY) = INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) INTERNAL_IP6_ADDRESS(2001:DB8:0:1:6:7:8:9/64) TSi = ((0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5), (0, 0-65535, 2001:DB8:0:1:6:7:8:9 - 2001:DB8:0:1:6:7:8:9)) TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) Then the Host A wants to change the secondary interface identifier. Is it OK for the Host A to activates INFORMATIONAL exchange as follows? Although the Host A may needs to delete the identifier after creating the new identifier in practice, this is just an example for clarification if the exchange complies the standard. CP(CFG_REQUEST) = INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) INTERNAL_IP6_ADDRESS(2001:DB8:0:1:A:B:C:D/64) TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) CP(CFG_REPLY) = INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) INTERNAL_IP6_ADDRESS(2001:DB8:0:1:A:B:C:D/64) TSi = ((0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5), (0, 0-65535, 2001:DB8:0:1:A:B:C:D - 2001:DB8:0:1:A:B:C:D)) TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) And then, the Host A activates another INFORMATIONAL exchange if the Host A wants to delete the secondary interface identifier. CP(CFG_REQUEST) = INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) CP(CFG_REPLY) = INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5) TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) What I want to clarify here is, - Can such configuration (add/change/delete) negotiation can be performed using INFORMATIONAL exchanges like above? - Is CP in INFORMATIONAL exchanges well defined? For example, if Configuration payloads are contained in INFORMATIONAL exchanges, is there any definition or guideline how to set or interpret the contents of the payloads? [Scenario-2] In case that the following exchange is performed during initial (IKE_AUTH) negotiation, CP(CFG_REQUEST) = INTERNAL_IP6_ADDRESS(::2:3:4:5/64) TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) CP(CFG_REPLY) = INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) TSi = (0, 0-65535, 2001:DB8:0:1:: - 2001:DB8:0:1:FFFF:FFFF:FFFF:FFFF) TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) Note: TSi in CFG_REPLY shows the /64 prefix range in this scenario. Can The Host A use any interface identifiers in the range of the negotiated TSi without any exchanges over the IKE_SA? What I want to clarify here is, if the above understanding is correct or the Host A must activate some exchanges to use interface identifiers other than ::1:2:3:4. Best Regards, Kimihiro Ohki _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 28 04:34:58 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvVVH-0002XA-NT; Wed, 28 Jun 2006 04:34:31 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvVVF-0002Wb-Kl for ipsec@ietf.org; Wed, 28 Jun 2006 04:34:29 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvVNp-0002Pl-Qa for ipsec@ietf.org; Wed, 28 Jun 2006 04:26:49 -0400 Received: from mgw-ext14.nokia.com ([131.228.20.173]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1FvVGk-0001J3-Bi for ipsec@ietf.org; Wed, 28 Jun 2006 04:19:30 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext14.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5S8JOX7025158; Wed, 28 Jun 2006 11:19:28 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 11:18:44 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 11:18:44 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] IPv6 Configuration in IKEv2 Date: Wed, 28 Jun 2006 11:18:43 +0300 Message-ID: In-Reply-To: <44A1E428.3040003@kddi.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ipsec] IPv6 Configuration in IKEv2 Thread-Index: AcaaV5d0JXOkbWOvQ/im+pwvioZJHQAMGl2Q From: To: , X-OriginalArrivalTime: 28 Jun 2006 08:18:44.0336 (UTC) FILETIME=[78BC0F00:01C69A8B] X-Spam-Score: -2.6 (--) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 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: , Errors-To: ipsec-bounces@ietf.org Kimihiro OHKI wrote: > Hi All, > > I would like to clarify IKEv2 specification regarding IPv6 > configuration. > > Assumptions: > - Host A is an IKEv2 initiator. > - Gateway B is an IKEv2 responder. > - The Gateway B has policy to allocate a globally unique /64 prefix > to each host (per IKE_SA). > - The Host A wants to use multiple interface identifiers under the > assigned /64 prefix. The Host A itself may use them (e.g. using > privacy extensions), or other hosts which connect to the Host A > may use some of them. > - The Host A wants to use common IPsec_SA for the multiple interface > identifiers. > > Clarifications: > I would like to know if the following example scenarios comply with > IKEv2 specification. To be more precise, it is not clear for me how to > configure (add/change/delete) inner IP addresses on the > existing IPsec_SA. IKEv2 does not allow modifying the traffic selectors ("inner IP addresses") of an existing IPsec SA: instead, you have to create a new IPsec SA (using CREATE_CHILD_SA exchange) and delete the old one. Moreover, your scenario really requires two operations to be carried out: assigning an IP address to the host (giving permission to configure the host's TCP/IP stack with the address and use it as source address for traffic), and creating IPsec SAs that allow traffic with that address to be properly protected. In IKEv2, the former is done with configuration payloads, and the latter with CREATE_CHILD_SA exchange. These are quite separate operations, since it's possible that a host is assigned an IP address but does not currently have IPsec SAs that match that address, and it's possible to have IPsec SAs that match addresses that are not assigned to the host. > [Scenario-1] > In case that the following exchange is performed during initial > (IKE_AUTH) negotiation, > > CP(CFG_REQUEST) =3D > INTERNAL_IP6_ADDRESS(::2:3:4:5/64) > TSi =3D (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) > TSr =3D (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) > > CP(CFG_REPLY) =3D > INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) > TSi =3D (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5) > TSr =3D (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) > > Note: The negotiated TSi is identical to the authorized > INTERNAL_IP6_ADDRESS in this scenario. Looks OK so far. > If the Host A wants to use additional interface identifiers, is it OK > for the Host A to activates INFORMATIONAL exchange as follows? > > CP(CFG_REQUEST) =3D > INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) > INTERNAL_IP6_ADDRESS(2001:DB8:0:1:6:7:8:9/64) > TSi =3D (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) > TSr =3D (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) > > CP(CFG_REPLY) =3D > INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) > INTERNAL_IP6_ADDRESS(2001:DB8:0:1:6:7:8:9/64) > TSi =3D ((0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5), > (0, 0-65535, 2001:DB8:0:1:6:7:8:9 - 2001:DB8:0:1:6:7:8:9)) > TSr =3D (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) The new IPsec SA has to be created using the CREATE_CHILD_SA exchange; after that, a separate INFORMATIONAL exchange can be used to delete the old IPsec SA pair. Furthermore, IKEv2 does not really support releasing addresses assigned via configuration payloads (except by closing the whole SA), and usually it's not even necessary. Thus, it's not necessary to list the existing address (the one ending :4:5) in the CFG_REQUEST/REPLY. > [Scenario-2] > In case that the following exchange is performed during initial > (IKE_AUTH) negotiation, > > CP(CFG_REQUEST) =3D > INTERNAL_IP6_ADDRESS(::2:3:4:5/64) > TSi =3D (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) > TSr =3D (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) > > CP(CFG_REPLY) =3D > INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) > TSi =3D (0, 0-65535, 2001:DB8:0:1:: - > 2001:DB8:0:1:FFFF:FFFF:FFFF:FFFF) > TSr =3D (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) > > Note: TSi in CFG_REPLY shows the /64 prefix range in this scenario. > > Can The Host A use any interface identifiers in the range of the > negotiated TSi without any exchanges over the IKE_SA? No. The INTERNAL_IP6_ADDRESS attribute CFG_REPLY assigns host A _one_ IPv6 address, not the whole /64 block. Although TSi/TSr specifies that traffic within the whole block can be protected with this SA, TSi/TSr do not give Host A the permission to actually use the whole block. (But it would be possible to define a new configuration attribute, say, INTERNAL_IP6_ADDRESS_BLOCK, to allow assigning a whole block...) In general, the IKEv2 configuration payloads for IPv6 are a bit messy, since the remote access IPsec tunnels created with IKEv2 are=20 not fully-featured "interfaces" in the IPv6 addressing architecture sense (although they could have been designed that way, an in hindsight, maybe should have been...). Best regards, Pasi=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 28 07:00:02 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvXm0-0006fI-AM; Wed, 28 Jun 2006 06:59:56 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvXly-0006Zl-PB for ipsec@ietf.org; Wed, 28 Jun 2006 06:59:54 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvXlx-0003cF-98 for ipsec@ietf.org; Wed, 28 Jun 2006 06:59:54 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id k5SAxpNG028905 for ; Wed, 28 Jun 2006 13:59:51 +0300 (IDT) Mime-Version: 1.0 (Apple Message framework v750) Content-Transfer-Encoding: 7bit Message-Id: <81FDDBF6-4CCC-451D-BCE1-21FC28DD721F@checkpoint.com> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed To: ipsec@ietf.org From: Yoav Nir Date: Wed, 28 Jun 2006 13:59:49 +0300 X-Mailer: Apple Mail (2.750) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Ipsec] Question re INTERNAL_IP*_SUBNET attribute and SPD 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: , Errors-To: ipsec-bounces@ietf.org Hi. Steve Kent's reply about the secure beacon document, prompted me to look at the description of the INTERNAL_IP*_SUBNET attributes in RFC 4306 and the clarifications draft. The attributes in the Configuration payload are used by the IKE responder (call it a gateway) to tell the IKE initiator (call it a client) what addresses it protects. My question is, how does this affect the SPD on the client? I have two possible answers in mind: 1. The client begins with an empty SPD (or maybe one entry that says BYPASS everything). It forces IKE, and then when it learns what subnets are protected, it adds PROTECT SPD entries that match the subnets described in the Configuration payload. 2. The client begins with a PROTECT entry for everything. When it receives the Configuration payload, it replaces that entry with more granular entries. Which (if any) do you think is correct? Yoav _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 28 07:01:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvXnW-0006vG-7U; Wed, 28 Jun 2006 07:01:30 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvXnU-0006v4-LU for ipsec@ietf.org; Wed, 28 Jun 2006 07:01:28 -0400 Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvXnT-0003fR-4E for ipsec@ietf.org; Wed, 28 Jun 2006 07:01:28 -0400 Received: from ysheffer.ad.checkpoint.com (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id k5SB18NH029456; Wed, 28 Jun 2006 14:01:09 +0300 (IDT) Message-Id: <200606281101.k5SB18NH029456@michael.checkpoint.com> Date: Wed, 28 Jun 2006 14:01:08 +0300 From: Yaron Sheffer Subject: RE: [Ipsec] FW: I-D ACTION:draft-sheffer-ipsec-secure-beacon-00.txt To: Stephen Kent In-reply-to: MIME-Version: 1.0 X-Mailer: Sun Outlook Connector 7.1.228.0 Content-type: TEXT/PLAIN; CHARSET=US-ASCII Content-transfer-encoding: QUOTED-PRINTABLE X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 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: , Errors-To: ipsec-bounces@ietf.org Hi Kent, Thanks for your review. Please let me know if the following added text would address the issue that= you raised: 3.5 Client Security Policy If the client sent the SECURE_NETWORK_DETECT notification and did not recei= ve an indication of a secure network, it SHOULD NOT change its existing SPD= . If the client sent the SECURE_NETWORK_DETECT notification and received the = SECURE_NETWORK_DETECTED notification, it should alter its behavior dependin= g on how the SPD is configured. 3.5.1 Statically configured SPD If the SPD is pre-configured, then upon receiving the SECURE_NETWORK_DETECT= ED notification, the client SHOULD temporarily convert all PROTECT entries = in the SPD which are associated with the peer gateway into BYPASS entries. = An entry is said to be associated with this peer gateway if it is a transpo= rt mode entry and the remote address is the peer gateway address, or if it = is a tunnel mode entry, and the remote tunnel address is the peer gateway a= ddress. 3.5.2 Dynamically discovered SPD IKEv2 allows the client to populate the SPD dynamically based on the INTERN= AL_IPv*_SUBNET attributes in the configuration payload (see section 6.3 in = [clarifications]). However the client cannot reach this state in the curren= t protocol, in the case of SECURE_NETWORK_DETECTED. Best regards, =09Yaron > -----Original Message----- > From: Stephen Kent [mailto:kent@bbn.com] > Sent: Monday, June 26, 2006 22:19 > To: Yaron Sheffer > Cc: ipsec@ietf.org > Subject: Re: [Ipsec] FW: I-D ACTION:draft-sheffer-ipsec-secure-beacon- > 00.txt >=20 > At 3:31 PM +0300 6/16/06, Yaron Sheffer wrote: > >Hi All, > > > >This is an individual submission, but I would appreciate your > >comments to the IPsec mailing list. > > > >Thanks, > >=09Yaron > > >=20 > Yaron, >=20 > The I-D talks about the extension to IKE to support the indicated > functionality. It does not say how the client behaves (in the > context of the IPsec model in 4301) in response to the > SECURE_NETWORK_DETECTED notification in message 2. for example, this > notification might be interpreted as temporarily changing the SPD > entry for the address space in the IKE proposal, to make it a BYPASS > entry. Or maybe the intent is to leave the SPD entry alone, but put > an SAD (and SPD cache) entry in place for the specified > address/protocol/port fields. However, the document provides no > description of the intended behavior relative to 4301, so it is > incomplete in that important respect. >=20 > Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 28 08:55:33 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvZZl-0003RL-Ai; Wed, 28 Jun 2006 08:55:25 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvZZj-0003Qf-Fm for ipsec@ietf.org; Wed, 28 Jun 2006 08:55:23 -0400 Received: from 84-121-36-229.onocable.ono.com ([84.121.36.229] helo=localhost.localdomain) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvZZi-0005fV-4W for ipsec@ietf.org; Wed, 28 Jun 2006 08:55:23 -0400 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by localhost.localdomain (Postfix) with ESMTP id 9D82F8E1B2; Wed, 28 Jun 2006 14:55:18 +0200 (CEST) Subject: Re: [Ipsec] Question re INTERNAL_IP*_SUBNET attribute and SPD From: Alejandro Perez Mendez To: Yoav Nir In-Reply-To: <81FDDBF6-4CCC-451D-BCE1-21FC28DD721F@checkpoint.com> References: <81FDDBF6-4CCC-451D-BCE1-21FC28DD721F@checkpoint.com> Content-Type: text/plain Date: Wed, 28 Jun 2006 14:55:18 +0200 Message-Id: <1151499318.5159.5.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.2 (/) 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: , Errors-To: ipsec-bounces@ietf.org > Hi. > > Steve Kent's reply about the secure beacon document, prompted me to > look at the description of the INTERNAL_IP*_SUBNET attributes in RFC > 4306 and the clarifications draft. > > The attributes in the Configuration payload are used by the IKE > responder (call it a gateway) to tell the IKE initiator (call it a > client) what addresses it protects. > > My question is, how does this affect the SPD on the client? > > I have two possible answers in mind: > > 1. The client begins with an empty SPD (or maybe one entry that says > BYPASS everything). It forces IKE, and then when it learns what > subnets are protected, it adds PROTECT SPD entries that match the > subnets described in the Configuration payload. > > 2. The client begins with a PROTECT entry for everything. When it > receives the Configuration payload, it replaces that entry with more > granular entries. > > Which (if any) do you think is correct? I prefer option 2 but, IMHO, this is a concrete implementation decision and the two options are valid -- Alejandro Perez Mendez _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 28 11:13:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvbio-000261-IL; Wed, 28 Jun 2006 11:12:54 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvbiM-0001h5-59 for ipsec@ietf.org; Wed, 28 Jun 2006 11:12:26 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvbgY-0001YN-GS for ipsec@ietf.org; Wed, 28 Jun 2006 11:10:35 -0400 Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FvbgX-0005jc-5W; Wed, 28 Jun 2006 11:10:34 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <200606281101.k5SB18NH029456@michael.checkpoint.com> References: <200606281101.k5SB18NH029456@michael.checkpoint.com> Date: Wed, 28 Jun 2006 11:05:54 -0400 To: Yaron Sheffer From: Stephen Kent Subject: RE: [Ipsec] FW: I-D ACTION:draft-sheffer-ipsec-secure-beacon-00.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f 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: , Errors-To: ipsec-bounces@ietf.org At 2:01 PM +0300 6/28/06, Yaron Sheffer wrote: >Hi Kent, > >Thanks for your review. > >Please let me know if the following added text would address the >issue that you raised: > >3.5 Client Security Policy > >If the client sent the SECURE_NETWORK_DETECT notification and did >not receive an indication of a secure network, it SHOULD NOT change >its existing SPD. > >If the client sent the SECURE_NETWORK_DETECT notification and >received the SECURE_NETWORK_DETECTED notification, it should alter >its behavior depending on how the SPD is configured. > >3.5.1 Statically configured SPD >If the SPD is pre-configured, then upon receiving the >SECURE_NETWORK_DETECTED notification, the client SHOULD temporarily >convert all PROTECT entries in the SPD which are associated with the >peer gateway into BYPASS entries. An entry is said to be associated >with this peer gateway if it is a transport mode entry and the >remote address is the peer gateway address, or if it is a tunnel >mode entry, and the remote tunnel address is the peer gateway >address. We have no notion of "temporarily converting" SPD entries in 4301. Maybe it would be better to say that all SPD cache entries created in response to this response will be set to BYPASS, even if they were marked as PROTECT in the SPD. That sort of description is consistent with the current processing model, although it still raises the question of when to time out these entries. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 28 11:22:36 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvbsA-0003eA-8b; Wed, 28 Jun 2006 11:22:34 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvbs8-0003bB-MS for ipsec@ietf.org; Wed, 28 Jun 2006 11:22:32 -0400 Received: from mgw-ext11.nokia.com ([131.228.20.170]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvbs7-00039N-83 for ipsec@ietf.org; Wed, 28 Jun 2006 11:22:32 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext11.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5SFMNCi010897; Wed, 28 Jun 2006 18:22:26 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 18:22:20 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 28 Jun 2006 18:22:21 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Question re INTERNAL_IP*_SUBNET attribute and SPD Date: Wed, 28 Jun 2006 18:22:19 +0300 Message-ID: In-Reply-To: <81FDDBF6-4CCC-451D-BCE1-21FC28DD721F@checkpoint.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ipsec] Question re INTERNAL_IP*_SUBNET attribute and SPD Thread-Index: AcaaoiFnU6ubf1psT9C8NP/tAsxROQAI1V0g From: To: , X-OriginalArrivalTime: 28 Jun 2006 15:22:21.0069 (UTC) FILETIME=[A649BBD0:01C69AC6] X-Spam-Score: 0.2 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c 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: , Errors-To: ipsec-bounces@ietf.org It's good to note that the INTERNAL_IP*_SUBNET attributes do not=20 necessarily affect the SPD at all. They contain the gateway's policy=20 about what traffic it would like to see sent via this tunnel... but=20 unless the client trusts the gateway unconditionally, it should not=20 change its SPD based on the information. But I guess you were considering the case where the client does trust the information to be correct. I'd say that in most cases it does not really change the SPD, but rather the routing table (and thus source address selection). Traffic that is sent via the=20 tunnel uses the IP address assigned by the gateway as the source=20 address; traffic that should bypass the tunnel most likely would=20 use the IP address assigned by the local DHCP server. Best regards, Pasi > -----Original Message----- > From: ext Yoav Nir [mailto:ynir@checkpoint.com]=20 > Sent: 28 June, 2006 14:00 > To: ipsec@ietf.org > Subject: [Ipsec] Question re INTERNAL_IP*_SUBNET attribute and SPD >=20 > Hi. >=20 > Steve Kent's reply about the secure beacon document, prompted me to =20 > look at the description of the INTERNAL_IP*_SUBNET attributes in RFC =20 > 4306 and the clarifications draft. >=20 > The attributes in the Configuration payload are used by the IKE =20 > responder (call it a gateway) to tell the IKE initiator (call it a =20 > client) what addresses it protects. >=20 > My question is, how does this affect the SPD on the client? >=20 > I have two possible answers in mind: >=20 > 1. The client begins with an empty SPD (or maybe one entry that says =20 > BYPASS everything). It forces IKE, and then when it learns what =20 > subnets are protected, it adds PROTECT SPD entries that match the =20 > subnets described in the Configuration payload. >=20 > 2. The client begins with a PROTECT entry for everything. When it =20 > receives the Configuration payload, it replaces that entry with more =20 > granular entries. >=20 > Which (if any) do you think is correct? >=20 > Yoav _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 28 13:16:47 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvdeS-0006F0-2Y; Wed, 28 Jun 2006 13:16:32 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvdeQ-0006Ev-Mb for ipsec@ietf.org; Wed, 28 Jun 2006 13:16:30 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FvdeP-0005Yv-Fp for ipsec@ietf.org; Wed, 28 Jun 2006 13:16:30 -0400 Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FvdeK-0007RD-4o; Wed, 28 Jun 2006 13:16:24 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 28 Jun 2006 12:11:57 -0400 To: From: Stephen Kent Subject: RE: [Ipsec] Question re INTERNAL_IP*_SUBNET attribute and SPD Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Cc: ipsec@ietf.org, ynir@checkpoint.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: , Errors-To: ipsec-bounces@ietf.org At 6:22 PM +0300 6/28/06, wrote: >It's good to note that the INTERNAL_IP*_SUBNET attributes do not >necessarily affect the SPD at all. They contain the gateway's policy >about what traffic it would like to see sent via this tunnel... but >unless the client trusts the gateway unconditionally, it should not >change its SPD based on the information. > >But I guess you were considering the case where the client does >trust the information to be correct. I'd say that in most cases >it does not really change the SPD, but rather the routing table >(and thus source address selection). Traffic that is sent via the >tunnel uses the IP address assigned by the gateway as the source >address; traffic that should bypass the tunnel most likely would >use the IP address assigned by the local DHCP server. > >Best regards, >Pasi Thanks for clarifying the "clarification." I was worried by the suggestion that sending this attribute via IKE caused a change to the SPD. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jun 29 01:34:24 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvpA3-000246-Ty; Thu, 29 Jun 2006 01:33:55 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FvpA2-000241-De for ipsec@ietf.org; Thu, 29 Jun 2006 01:33:54 -0400 Received: from athena.kddi.com ([210.141.112.39] helo=UTMC1104.kddi.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvp9z-0008KP-Kq for ipsec@ietf.org; Thu, 29 Jun 2006 01:33:54 -0400 Received: from usjk1037 (unknown [10.5.16.67]) by UTMC1104.kddi.com (Postfix) with SMTP id AA9AA259C; Thu, 29 Jun 2006 14:33:49 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with SMTP id A7BA71A7E; Thu, 29 Jun 2006 14:33:42 +0900 (JST) Received: from UTMC1112.kddi.com (unknown [10.5.16.9]) by UTMC1122.kddi.com (Postfix) with ESMTP id D46971A18; Thu, 29 Jun 2006 14:33:38 +0900 (JST) Received: from [10.100.120.154] ([10.100.120.154] [10.100.120.154]) by post-ims.kddi.com with ESMTP; Thu, 29 Jun 2006 14:33:38 +0900 Message-Id: <44A3662E.5010802@kddi.com> Date: Thu, 29 Jun 2006 14:33:34 +0900 From: Kimihiro OHKI User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [Ipsec] IPv6 Configuration in IKEv2 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-WAuditID: 0606291433420000021272 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b6657e60309a1317174c9db2ae5f227 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: , Errors-To: ipsec-bounces@ietf.org Thanks for your reply. Excuse me for some educational questions. Pasi.Eronen@nokia.com wrote: > Kimihiro OHKI wrote: >> Hi All, >> >> I would like to clarify IKEv2 specification regarding IPv6 >> configuration. >> >> Assumptions: >> - Host A is an IKEv2 initiator. >> - Gateway B is an IKEv2 responder. >> - The Gateway B has policy to allocate a globally unique /64 prefix >> to each host (per IKE_SA). >> - The Host A wants to use multiple interface identifiers under the >> assigned /64 prefix. The Host A itself may use them (e.g. using >> privacy extensions), or other hosts which connect to the Host A >> may use some of them. >> - The Host A wants to use common IPsec_SA for the multiple interface >> identifiers. >> >> Clarifications: >> I would like to know if the following example scenarios comply with >> IKEv2 specification. To be more precise, it is not clear for me how to >> configure (add/change/delete) inner IP addresses on the >> existing IPsec_SA. > > IKEv2 does not allow modifying the traffic selectors ("inner IP > addresses") of an existing IPsec SA: instead, you have to create a new > IPsec SA (using CREATE_CHILD_SA exchange) and delete the old one. OK. I've understood that the traffic selectors negotiated at creating the CHILD_SA are valid until the CHILD_SA is expired or deleted, but can not be changed (i.e. TS must not be included in INFORMATIONAL exchanges). > Moreover, your scenario really requires two operations to be carried > out: assigning an IP address to the host (giving permission to > configure the host's TCP/IP stack with the address and use it as > source address for traffic), and creating IPsec SAs that allow traffic > with that address to be properly protected. > > In IKEv2, the former is done with configuration payloads, and the > latter with CREATE_CHILD_SA exchange. These are quite separate > operations, since it's possible that a host is assigned an IP address > but does not currently have IPsec SAs that match that address, and > it's possible to have IPsec SAs that match addresses that are not > assigned to the host. I'd like to clarify this meaning below. However I've understood that negotiation of configuration payloads and traffic selectors are entire separate operations. >> [Scenario-1] >> In case that the following exchange is performed during initial >> (IKE_AUTH) negotiation, >> >> CP(CFG_REQUEST) = >> INTERNAL_IP6_ADDRESS(::2:3:4:5/64) >> TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) >> TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) >> >> CP(CFG_REPLY) = >> INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) >> TSi = (0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5) >> TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) >> >> Note: The negotiated TSi is identical to the authorized >> INTERNAL_IP6_ADDRESS in this scenario. > > Looks OK so far. > >> If the Host A wants to use additional interface identifiers, is it OK >> for the Host A to activates INFORMATIONAL exchange as follows? >> >> CP(CFG_REQUEST) = >> INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) >> INTERNAL_IP6_ADDRESS(2001:DB8:0:1:6:7:8:9/64) >> TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) >> TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) >> >> CP(CFG_REPLY) = >> INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) >> INTERNAL_IP6_ADDRESS(2001:DB8:0:1:6:7:8:9/64) >> TSi = ((0, 0-65535, 2001:DB8:0:1:2:3:4:5 - 2001:DB8:0:1:2:3:4:5), >> (0, 0-65535, 2001:DB8:0:1:6:7:8:9 - 2001:DB8:0:1:6:7:8:9)) >> TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) > > The new IPsec SA has to be created using the CREATE_CHILD_SA exchange; > after that, a separate INFORMATIONAL exchange can be used to delete > the old IPsec SA pair. I've understood this exchange is wrong because this includes traffic selectors' negotiation in an INFORMATIONAL exchange. Meanwhile from the point of view of configuration payloads, can INFORMATIONAL exchanges be used to request additional inner IP addresses if the traffic selectors are NOT necessary to be modified? > Furthermore, IKEv2 does not really support releasing addresses > assigned via configuration payloads (except by closing the whole SA), > and usually it's not even necessary. Thus, it's not necessary > to list the existing address (the one ending :4:5) in the > CFG_REQUEST/REPLY. Some clarifications on this statement: - Are all configurations via configuration payloads commonly related to all CHILD_SAs regardless of the CHILD_SA which has carried the configuration payloads, although traffic selectors are related to each specific (associated) CHILD_SA? In other words, configuration payloads works on not the CHILD_SA but the IKE_SA? For example, Inner IP address A is configured via a configuration payload over CHILD_SA(1). Inner IP address B is configured via a configuration payload over CHILD_SA(2). TS1 is negotiated for CHILD_SA(1). TS2 is negotiated for CHILD_SA(2). In this case, when CHILD_SA(1) is deleted, TS2 and both IP addresses A and B are valid on CHILD_SA(2). Is this understanding correct? - With regards to your statement "IKEv2 does not really support releasing addresses assigned via configuration payloads (except by closing the whole SA)", does INTERNAL_ADDRESS_EXPIRY attribute also work for releasing addresses? In other words, does this attribute work for releasing some specific addresses or releasing IKE_SA? > > >> [Scenario-2] >> In case that the following exchange is performed during initial >> (IKE_AUTH) negotiation, >> >> CP(CFG_REQUEST) = >> INTERNAL_IP6_ADDRESS(::2:3:4:5/64) >> TSi = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) >> TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) >> >> CP(CFG_REPLY) = >> INTERNAL_IP6_ADDRESS(2001:DB8:0:1:2:3:4:5/64) >> TSi = (0, 0-65535, 2001:DB8:0:1:: - >> 2001:DB8:0:1:FFFF:FFFF:FFFF:FFFF) >> TSr = (0, 0-65535, :: - FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF) >> >> Note: TSi in CFG_REPLY shows the /64 prefix range in this scenario. >> >> Can The Host A use any interface identifiers in the range of the >> negotiated TSi without any exchanges over the IKE_SA? > > No. The INTERNAL_IP6_ADDRESS attribute CFG_REPLY assigns host A _one_ > IPv6 address, not the whole /64 block. Although TSi/TSr specifies that > traffic within the whole block can be protected with this SA, TSi/TSr > do not give Host A the permission to actually use the whole block. I assumed that inner IP address assignment on IKEv2 is optional behavior (i.e. static address configuration and using other protocols such as DHCP are also acceptable). Then my understanding was, although CFG_REQUEST/REPLY just works for providing useful information to the initiator, how to configure the routing table at both the initiator and the responder is implementation specific, outside of the scope of rfc4306 specification or necessary to rely on other specifications/ guidelines. So I guessed this scenario works from the point of view of rfc4306 if both the initiator and the responder have prior agreement. In rfc4306, section 2.9 (Traffic Selector Negotiation) says "For example, if the original initiator request the creation of a CHILD_SA pair, and wishes to tunnel all traffic from subnet 192.0.1.* on the initiator's side to subnet 192.0.2.* on the responder's side, the initiator would include a single traffic selector in each TS payload. TSi would specify the address range (192.0.1.0 - 192.0.1.255) and TSr would specify the address range (192.0.2.0 - 192.0.2.255)." In this case for example, if configuration via configuration payloads is mandatory to effect on the routing table at the responder, all addresses in the subnet of the initiator side are necessary to be included in the configuration payloads? > (But it would be possible to define a new configuration attribute, say, > INTERNAL_IP6_ADDRESS_BLOCK, to allow assigning a whole block...) I've understood that the INTERNAL_IP6_ADDRESS is not enough to assign /64 prefix or some block. Best Regards, Kimihiro Ohki > In general, the IKEv2 configuration payloads for IPv6 are a bit > messy, since the remote access IPsec tunnels created with IKEv2 are > not fully-featured "interfaces" in the IPv6 addressing architecture > sense (although they could have been designed that way, an in hindsight, > maybe should have been...). > > Best regards, > Pasi > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jun 29 11:01:06 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvy0g-000331-Tv; Thu, 29 Jun 2006 11:00:50 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fvy0e-0002gq-Bk for ipsec@ietf.org; Thu, 29 Jun 2006 11:00:48 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fvx43-0001Fk-9f for ipsec@ietf.org; Thu, 29 Jun 2006 10:00:15 -0400 Received: from mgw-ext13.nokia.com ([131.228.20.172]) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fvwn2-0004XL-8B for ipsec@ietf.org; Thu, 29 Jun 2006 09:42:40 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.1.8/Switch-3.1.7) with ESMTP id k5TDgYJq012047; Thu, 29 Jun 2006 16:42:34 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 16:42:34 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Jun 2006 16:42:34 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] IPv6 Configuration in IKEv2 Date: Thu, 29 Jun 2006 16:42:34 +0300 Message-ID: In-Reply-To: <44A3662E.5010802@kddi.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Ipsec] IPv6 Configuration in IKEv2 Thread-Index: AcabPbDXDEGeIN10S3ysKIg/i8njqwARAUGw From: To: X-OriginalArrivalTime: 29 Jun 2006 13:42:34.0126 (UTC) FILETIME=[E0347AE0:01C69B81] X-Spam-Score: -2.6 (--) X-Scan-Signature: 5d7a7e767f20255fce80fa0b77fb2433 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: , Errors-To: ipsec-bounces@ietf.org Kimihiro OHKI wrote: > > The new IPsec SA has to be created using the CREATE_CHILD_SA > > exchange; after that, a separate INFORMATIONAL exchange can be > > used to delete the old IPsec SA pair. >=20 > I've understood this exchange is wrong because this includes traffic=20 > selectors' negotiation in an INFORMATIONAL exchange. > Meanwhile from the point of view of configuration payloads, can=20 > INFORMATIONAL exchanges be used to request additional inner IP=20 > addresses if the traffic selectors are NOT necessary to be modified? Yes, CFG_REQUEST/REPLY can be sent in INFORMATIONAL exchanges. > > Furthermore, IKEv2 does not really support releasing addresses > > assigned via configuration payloads (except by closing the whole > > SA), and usually it's not even necessary. Thus, it's not necessary > > to list the existing address (the one ending :4:5) in the > > CFG_REQUEST/REPLY. >=20 > Some clarifications on this statement: >=20 > - Are all configurations via configuration payloads commonly related=20 > to all CHILD_SAs regardless of the CHILD_SA which has carried the=20 > configuration payloads, although traffic selectors are=20 > related to each specific (associated) CHILD_SA? In other words, > configuration payloads works on not the CHILD_SA but the IKE_SA? That's right; the configuration information in CFG_REQUEST/REPLY is not related to any particular CHILD_SA, but the IKE_SA as whole. > For example, >=20 > Inner IP address A is configured via a configuration payload over > CHILD_SA(1). > Inner IP address B is configured via a configuration payload over > CHILD_SA(2). > TS1 is negotiated for CHILD_SA(1). > TS2 is negotiated for CHILD_SA(2). >=20 > In this case, when CHILD_SA(1) is deleted, TS2 and both IP=20 > addresses A and B are valid on CHILD_SA(2). Is this understanding=20 > correct? Both IP addresses A and B are still valid, even when CHILD_SA(1) is deleted. Whether the traffic can be actually sent with CHILD_SA(2) depends on what TS2 contains=20 > - With regards to your statement "IKEv2 does not really support > releasing addresses assigned via configuration payloads (except by > closing the whole SA)", does INTERNAL_ADDRESS_EXPIRY attribute also > work for releasing addresses? In other words, does this attribute > work for releasing some specific addresses or releasing IKE_SA? INTERNAL_ADDRESS_EXPIRY allows the gateway to set a lifetime for the addresses (after which they expire), but it does not allow the client to request releasing some specific address. > > No. The INTERNAL_IP6_ADDRESS attribute CFG_REPLY assigns host A > > _one_ IPv6 address, not the whole /64 block. Although TSi/TSr > > specifies that traffic within the whole block can be protected > > with this SA, TSi/TSr do not give Host A the permission to > > actually use the whole block. >=20 > I assumed that inner IP address assignment on IKEv2 is optional > behavior (i.e. static address configuration and using other > protocols such as DHCP are also acceptable). Then my understanding > was, although CFG_REQUEST/REPLY just works for providing useful > information to the initiator, how to configure the routing table at > both the initiator and the responder is implementation specific, > outside of the scope of rfc4306 specification or necessary to rely > on other specifications/ guidelines. So I guessed this scenario > works from the point of view of rfc4306 if both the initiator and > the responder have prior agreement. Yes, the scenario works if assigning the whole /64 block to host A=20 is done by some other means (e.g. manual configuration). > In rfc4306, section 2.9 (Traffic Selector Negotiation) says "For=20 > example, if the original initiator request the creation of a CHILD_SA=20 > pair, and wishes to tunnel all traffic from subnet 192.0.1.* on the=20 > initiator's side to subnet 192.0.2.* on the responder's side, the=20 > initiator would include a single traffic selector in each TS payload.=20 > TSi would specify the address range (192.0.1.0 - 192.0.1.255) and=20 > TSr would specify the address range (192.0.2.0 - 192.0.2.255)." > In this case for example, if configuration via configuration payloads=20 > is mandatory to effect on the routing table at the responder, all=20 > addresses in the subnet of the initiator side are necessary to be=20 > included in the configuration payloads? Hmm... not really, since the routing table is not necessarily involved at all: the IPsec architecture (RFC4301) does not consider IPsec tunnels to be "interfaces"; rather, IPsec processing is applied to packets that match entries in the SPD (and the SPD could be interface-specific). In the example above, the responder ("host B") would probably have SPD entry saying that "traffic with local address 192.0.2.0/24 and remote address 192.0.1.0/24" must be protected by IPsec", and PAD entry saying "peer authenticated as host-a.example.com is authorized to represent addresses 192.0.1.0/24". Now when Host A requests the creation of a CHILD_SA pair as explained above, host B would check the request against its PAD and SPD, and since everything is OK, would create the SA and an entry in the SPD cache containing 192.0.1.0/24,192.0.2.0/24 and a pointer to the SA. When host B now has an outgoing packet from 192.0.2.0/24 to 192.0.1.0/24, it would match this SPD cache entry, and would be processed as agreed for the SA, and sent to host A. (But it's good to note that actual IPsec implementations may use the words "interface", "SPD", etc., to mean slightly different things than RFC 4301. E.g. some operating systems might call every IPsec tunnel-mode SA an "interface"; others might have a single global "interface" called "ipsec", and so on. But these are implementation details not covered in RFC 4301 or 4306.) Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jun 29 23:11:13 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw9PI-0000lX-V9; Thu, 29 Jun 2006 23:11:00 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1Fw9PH-0000lM-8W for ipsec@ietf.org; Thu, 29 Jun 2006 23:10:59 -0400 Received: from stsc1260-eth-s1-s1p1-vip.va.neustar.com ([156.154.16.129] helo=chiedprmail1.ietf.org) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Fw7z3-0005Qo-84 for ipsec@ietf.org; Thu, 29 Jun 2006 21:39:49 -0400 Received: from athena.kddi.com ([210.141.112.39] helo=UTMC1101.kddi.com) by chiedprmail1.ietf.org with esmtp (Exim 4.43) id 1Fw7sc-000463-G7 for ipsec@ietf.org; Thu, 29 Jun 2006 21:33:11 -0400 Received: from usjk1037 (unknown [10.5.16.67]) by UTMC1101.kddi.com (Postfix) with SMTP id 32E1E2434; Fri, 30 Jun 2006 10:33:04 +0900 (JST) Received: from localhost (localhost [127.0.0.1]) by localhost.kddi.com (Postfix) with SMTP id BA0601A97; Fri, 30 Jun 2006 10:32:55 +0900 (JST) Received: from UTMC1113.kddi.com (unknown [10.5.16.13]) by UTMC1124.kddi.com (Postfix) with ESMTP id CB4A51A7F; Fri, 30 Jun 2006 10:32:51 +0900 (JST) Received: from [10.100.120.154] ([10.100.120.154] [10.100.120.154]) by post-ims.kddi.com with ESMTP; Fri, 30 Jun 2006 10:32:51 +0900 Message-Id: <44A47F41.1030008@kddi.com> Date: Fri, 30 Jun 2006 10:32:49 +0900 From: Kimihiro OHKI User-Agent: Thunderbird 1.5 (Windows/20051201) MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [Ipsec] IPv6 Configuration in IKEv2 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-WAuditID: 0606301032550000020088 X-Spam-Score: -2.6 (--) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 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: , Errors-To: ipsec-bounces@ietf.org Pasi.Eronen@nokia.com wrote: >> In rfc4306, section 2.9 (Traffic Selector Negotiation) says "For >> example, if the original initiator request the creation of a CHILD_SA >> pair, and wishes to tunnel all traffic from subnet 192.0.1.* on the >> initiator's side to subnet 192.0.2.* on the responder's side, the >> initiator would include a single traffic selector in each TS payload. >> TSi would specify the address range (192.0.1.0 - 192.0.1.255) and >> TSr would specify the address range (192.0.2.0 - 192.0.2.255)." >> In this case for example, if configuration via configuration payloads >> is mandatory to effect on the routing table at the responder, all >> addresses in the subnet of the initiator side are necessary to be >> included in the configuration payloads? > > Hmm... not really, since the routing table is not necessarily involved > at all: the IPsec architecture (RFC4301) does not consider IPsec > tunnels to be "interfaces"; rather, IPsec processing is applied to > packets that match entries in the SPD (and the SPD could be > interface-specific). > > In the example above, the responder ("host B") would probably have SPD > entry saying that "traffic with local address 192.0.2.0/24 and remote > address 192.0.1.0/24" must be protected by IPsec", and PAD entry > saying "peer authenticated as host-a.example.com is authorized to > represent addresses 192.0.1.0/24". > > Now when Host A requests the creation of a CHILD_SA pair as explained > above, host B would check the request against its PAD and SPD, and > since everything is OK, would create the SA and an entry in the SPD > cache containing 192.0.1.0/24,192.0.2.0/24 and a pointer to the SA. > > When host B now has an outgoing packet from 192.0.2.0/24 to > 192.0.1.0/24, > it would match this SPD cache entry, and would be processed as agreed > for the SA, and sent to host A. > > (But it's good to note that actual IPsec implementations may use the > words "interface", "SPD", etc., to mean slightly different things than > RFC 4301. E.g. some operating systems might call every IPsec > tunnel-mode SA an "interface"; others might have a single global > "interface" called "ipsec", and so on. But these are implementation > details not covered in RFC 4301 or 4306.) Actually my confusion on this whole discussion might be, it was not clear for me how the negotiation of configuration payloads / traffic selectors affects its SPD or routing to the "interface". It seems, it is clearly defined that the negotiation of traffic selectors affects its SPD, on the other hand actual IPsec implementations may need to take care of any other details such as the difference between "SPD" and "interface" for the interoperability. Best Regards, Kimihiro Ohki _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 30 11:55:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwLKl-00088H-In; Fri, 30 Jun 2006 11:55:07 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwLKj-00088C-MN for ipsec@ietf.org; Fri, 30 Jun 2006 11:55:05 -0400 Received: from mx12.bbn.com ([128.33.0.81]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1FwLKi-0001Hk-GO for ipsec@ietf.org; Fri, 30 Jun 2006 11:55:05 -0400 Received: from dhcp89-089-106.bbn.com ([128.89.89.106]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from ) id 1FwLKg-0004iV-68; Fri, 30 Jun 2006 11:55:03 -0400 Mime-Version: 1.0 Message-Id: In-Reply-To: <44A47F41.1030008@kddi.com> References: <44A47F41.1030008@kddi.com> Date: Fri, 30 Jun 2006 11:08:09 -0400 To: Kimihiro OHKI From: Stephen Kent Subject: Re: [Ipsec] IPv6 Configuration in IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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: , Errors-To: ipsec-bounces@ietf.org At 10:32 AM +0900 6/30/06, Kimihiro OHKI wrote: >>... > >Actually my confusion on this whole discussion might be, it was not >clear for me how the negotiation of configuration payloads / traffic >selectors affects its SPD or routing to the "interface". >It seems, it is clearly defined that the negotiation of traffic >selectors affects its SPD, on the other hand actual IPsec >implementations may need to take care of any other details such as >the difference between "SPD" and "interface" for the >interoperability. > >Best Regards, >Kimihiro Ohki the SPD is not modified by IKE negotiation of traffic selectors. The SPD controls the traffic selector negotiation process. The SAD entry and SPD cache entry created for an SA are affected by the IKE negotiation. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jun 30 12:56:30 2006 Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwMHz-0001Fp-2I; Fri, 30 Jun 2006 12:56:19 -0400 Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1FwMHx-0001B2-6Y for ipsec@ietf.org; Fri, 30 Jun 2006 12:56:17 -0400 Received: from web80615.mail.yahoo.com ([66.94.235.82]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1FwMHu-0005Wm-Oc for ipsec@ietf.org; Fri, 30 Jun 2006 12:56:17 -0400 Received: (qmail 4835 invoked by uid 60001); 30 Jun 2006 16:49:33 -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=WIcLYvSRduQxwQK/KsympwKygD1kwIUQ9+9E7+KgEOkToXR4W4yMp8WD8DRBLqF3E12ZjBC22J58x97xG9fqXI4CUY7MpsIW5j4bEeJwi9moo7YsQB4s6jZ5WFVw5ZZlQij8eugHE2084n+99K8nfTk2WwKx8AzBi7kGNp+ssks= ; Message-ID: <20060630164933.4833.qmail@web80615.mail.yahoo.com> Received: from [206.132.194.3] by web80615.mail.yahoo.com via HTTP; Fri, 30 Jun 2006 09:49:33 PDT Date: Fri, 30 Jun 2006 09:49:33 -0700 (PDT) From: Mohan Parthasarathy Subject: Re: [Ipsec] IPv6 Configuration in IKEv2 To: Stephen Kent , Kimihiro OHKI In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 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: , Errors-To: ipsec-bounces@ietf.org > >Actually my confusion on this whole discussion > might be, it was not > >clear for me how the negotiation of configuration > payloads / traffic > >selectors affects its SPD or routing to the > "interface". > >It seems, it is clearly defined that the > negotiation of traffic > >selectors affects its SPD, on the other hand actual > IPsec > >implementations may need to take care of any other > details such as > >the difference between "SPD" and "interface" for > the > >interoperability. > > > >Best Regards, > >Kimihiro Ohki > > the SPD is not modified by IKE negotiation of > traffic selectors. The > SPD controls the traffic selector negotiation > process. The SAD entry > and SPD cache entry created for an SA are affected > by the IKE > negotiation. > In the road warrior case, the IP address is assigned by the security gateway and this would result in SPD modification ("inner-address --> 0.0.0.0 PROTECT) as this address is not known a priori. This is a modification, right ? The value in INTERNAL_IP*SUBNET tells the host (initiator) that the traffic to these addresses should be protected. As per 4301, SPD is the only place that i can find suitable for adding this. But then, this would result in source address selection problems. Hence, as suggested in Pasi's earlier mail, it normally affects the routing table entry. These routes would point to an interface where the address returned in CFG-REPLY is assigned. With this, you have just one SPD entry : "inner-address -> 0.0.0.0 PROTECT". -mohan > Steve > > _______________________________________________ > 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