From ipsec-bounces@ietf.org Tue Mar 1 01:46:54 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26567 for ; Tue, 1 Mar 2005 01:46:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D617g-0008OC-3b; Tue, 01 Mar 2005 01:44:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D617c-0008Js-E5 for ipsec@megatron.ietf.org; Tue, 01 Mar 2005 01:44:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA26347 for ; Tue, 1 Mar 2005 01:44:43 -0500 (EST) Received: from [207.145.48.18] (helo=smtp.intoto.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D618U-0003XV-SH for ipsec@ietf.org; Tue, 01 Mar 2005 01:45:40 -0500 Received: from brahma.intotoind.com ([66.80.10.146]) by smtp.intoto.com (SMSSMTP 4.0.0.59) with SMTP id M2005022822440107712 ; Mon, 28 Feb 2005 22:44:01 -0800 Received: from [172.16.3.124] (3mc124.intotoind.com [172.16.3.124]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id j216iIKO011005; Tue, 1 Mar 2005 12:14:23 +0530 Subject: Re: [Ipsec] Simple IPSec question From: Someshwar Parate To: kallol_biswas@agilent.com In-Reply-To: References: X-Mailer: Ximian Evolution 1.0.8 (1.0.8-10) Date: 01 Mar 2005 12:21:26 +0530 Message-Id: <1109659891.13158.3.camel@rh.intotoind.com> Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 1.0 (+) X-Scan-Signature: b22590c27682ace61775ee7b453b40d3 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="===============0227916140==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0227916140== Content-Type: multipart/alternative; boundary="=-oJMKsv0i8B1qCJXzqn3A" --=-oJMKsv0i8B1qCJXzqn3A Content-Type: text/plain Content-Transfer-Encoding: 7bit Kallol, steps 2 and 3 happens everytime whenever previous SA lifetime expires. -somesh On Tue, 2005-03-01 at 08:06, kallol_biswas@agilent.com wrote: Folks, I have just read a tutorial on IPSec, and have a few questions. Hope they are not too trivial. I have downloaded the following five steps from a site on the internet. "How IPSec Works" 1) "Interesting traffic" initiates the IPSec process. Traffic is deemed interesting when the IPSec security policy configured in the IPSec peers starts the IKE process. 2) IKE phase 1. IKE authenticates IPSec peers and negotiates IKE SAs during this phase, setting up a secure channel for negotiating IPSec SAs in phase 2. 3) IKE phase 2. IKE negotiates IPSec SA parameters and sets up matching IPSec SAs in the peers. 4) Data transfer. Data is transferred between IPSec peers based on the IPSec parameters and keys stored in the SA database. 5) IPSec tunnel termination. IPSec SAs terminate through deletion or by timing out. The question is how often step 2 & 3 take place? My understanding is that only once for the first frame and then a SA remains valid till it times out or deleted, right? Do we have any performance figure of a system with IPSec enabled? Specially with iSCSI. Kallol _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec -- regards... - Somesh ========================================================= SOMESHWAR PARATE Intoto Software India Ltd., UMA Plaza, Nagarjuna Hills, Punjagutta, Hyderabad - 82 Ph: +91-40-23358927/28 X230 Email: srparate@intoto.com --------------------------------------------------------- --=-oJMKsv0i8B1qCJXzqn3A Content-Type: text/html; charset=utf-8 Kallol,

steps 2 and 3 happens everytime whenever previous SA lifetime expires.

-somesh
On Tue, 2005-03-01 at 08:06, kallol_biswas@agilent.com wrote: 
Folks,
     I have just read a tutorial on IPSec, and have a few questions. Hope they are not too trivial.

I have downloaded the following five steps from a site on the internet.
             "How IPSec Works"

1) "Interesting traffic" initiates the IPSec process. Traffic is deemed interesting when the IPSec security policy configured in the IPSec peers starts the IKE process.

2) IKE phase 1. IKE authenticates IPSec peers and negotiates IKE SAs during this phase, setting up a secure channel for negotiating IPSec SAs in phase 2.

3) IKE phase 2. IKE negotiates IPSec SA parameters and sets up matching IPSec SAs in the peers.

4) Data transfer. Data is transferred between IPSec peers based on the IPSec parameters and keys stored in the SA database.

5) IPSec tunnel termination. IPSec SAs terminate through deletion or by timing out.

The question is how often step 2 & 3 take place? My understanding is that only once for the first frame and then a SA remains valid till it times out or deleted, right?

Do we have any performance figure of a system with IPSec enabled? Specially with iSCSI.

Kallol

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec

-- 
regards...
- Somesh
=========================================================
SOMESHWAR PARATE
Intoto Software India Ltd.,
UMA Plaza, Nagarjuna Hills,
Punjagutta, Hyderabad - 82
Ph: +91-40-23358927/28 X230
Email: srparate@intoto.com
---------------------------------------------------------
--=-oJMKsv0i8B1qCJXzqn3A-- --===============0227916140== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0227916140==-- From ipsec-bounces@ietf.org Tue Mar 1 06:47:52 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15093 for ; Tue, 1 Mar 2005 06:47:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D65pL-0006E3-Np; Tue, 01 Mar 2005 06:46:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D65pH-0006Dy-Ga for ipsec@megatron.ietf.org; Tue, 01 Mar 2005 06:46:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA14968 for ; Tue, 1 Mar 2005 06:46:04 -0500 (EST) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D65qB-0000m4-6e for ipsec@ietf.org; Tue, 01 Mar 2005 06:47:05 -0500 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.7p1+Sun/8.11.6) with ESMTP id j21Bjir08304; Tue, 1 Mar 2005 13:45:44 +0200 (IST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] Technical change needed to IKEv2 before publication Date: Tue, 1 Mar 2005 13:45:43 +0200 To: Paul Hoffman X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: IPsec WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit I'd go with suggestion C On Mar 1, 2005, at 2:25 AM, Paul Hoffman wrote: > Greetings again. During the IKEv2 bakeoff last week, a technical > mistake was found in the current IKEv2 Internet Draft. This is not > something that simply needs to be clarified; it needs an actual fix to > the document because, without it, interoperability is literally > impossible. > > (FWIW, the bakeoff also led to about 25 clarifications that will be > sent to the list soon. These are all clarifications to areas that one > or more bakeoff participant felt was unclear. They are only > clarifications, not technical changes.) > > After discussing this briefly with Russ Housley, our AD, we decided to > poll the Working Group on how to fix the problem. If we can reach > consensus soon (such as within a week from today), it may not delay > the publication of the IKEv2 RFC. Russ will want to hear from the WG > co-chairs as to our consensus. > > ------------------- > > Issue: If a receiver doesn't support ESN, they require the sender > to send an ESN transform > > Some systems know that they don't support ESN, and therefore they > require the other side to actively say they won't expect it. The only > way for the other side to do so is for it to send a Transform Type > 5 with a value of 0. However, there is no way for the responder to > say that to the initiator, so interoperability is not possible. > > This is a technical error in the IKEv2 spec. There are three simple > possible ways to change this: > > SUGGESTION A: > The last sentence of 3.3.2 says: > If Transform Type 5 is not included in a proposal, use of > Extended Sequence Numbers is assumed. > Replace this with: > If Transform Type 5 is not included in a proposal, it is > assumed that the sending party does not support Extended > Sequence Numbers. > > SUGGESTION B: > Create a new response notification that says "I can't do ESN, start > again and include a 'no ESN' transform." > > SUGGESTION C: > Change the places that says Transform Type 5 is optional to say > it is mandatory. > > ------------------- > > The people I spoke with at the bakeoff agreed that suggestions A and C > would both work and be easy to implement. Personally, I think > suggestion C is better because having defaults tends to lead to > interoperability issues down the line when new implementers don't read > all the defaults. It's only a few extra bytes per proposal to always > be explicit. > > Please respond on the list soon so that the WG co-chairs can advise > the ADs of the WG consensus on this and prevent a delay in the > document's publication. > > --Paul Hoffman, Director > --VPN Consortium > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Mar 1 06:59:48 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA16072 for ; Tue, 1 Mar 2005 06:59:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D660J-0007rS-3H; Tue, 01 Mar 2005 06:57:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D660G-0007rM-Iy for ipsec@megatron.ietf.org; Tue, 01 Mar 2005 06:57:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15803 for ; Tue, 1 Mar 2005 06:57:26 -0500 (EST) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D661D-0000yj-5V for ipsec@ietf.org; Tue, 01 Mar 2005 06:58:27 -0500 Content-class: urn:content-classes:message Subject: RE: [Ipsec] Technical change needed to IKEv2 before publication MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Mar 2005 03:57:13 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: Thread-Topic: [Ipsec] Technical change needed to IKEv2 before publication thread-index: AcUd9erFnXKfjzpjQH+KXTGuJiTAsQAYC84Q From: "Vishwas Manral" To: "Paul Hoffman" , "IPsec WG" X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Cc: Russ Housley , "Theodore Y. Ts'o" , Barbara Fraser X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Paul, I am ok with C too. Besides I had raised some text requiring minor clarifications, which could be included too. Thanks, Vishwas -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Paul Hoffman Sent: Tuesday, March 01, 2005 5:56 AM To: IPsec WG Cc: Theodore Y. Ts'o; Russ Housley; Barbara Fraser Subject: [Ipsec] Technical change needed to IKEv2 before publication Greetings again. During the IKEv2 bakeoff last week, a technical=20 mistake was found in the current IKEv2 Internet Draft. This is not=20 something that simply needs to be clarified; it needs an actual fix=20 to the document because, without it, interoperability is literally=20 impossible. (FWIW, the bakeoff also led to about 25 clarifications that will be=20 sent to the list soon. These are all clarifications to areas that one=20 or more bakeoff participant felt was unclear. They are only=20 clarifications, not technical changes.) After discussing this briefly with Russ Housley, our AD, we decided=20 to poll the Working Group on how to fix the problem. If we can reach=20 consensus soon (such as within a week from today), it may not delay=20 the publication of the IKEv2 RFC. Russ will want to hear from the WG=20 co-chairs as to our consensus. ------------------- Issue: If a receiver doesn't support ESN, they require the sender to send an ESN transform Some systems know that they don't support ESN, and therefore they require the other side to actively say they won't expect it. The only way for the other side to do so is for it to send a Transform Type 5 with a value of 0. However, there is no way for the responder to say that to the initiator, so interoperability is not possible. This is a technical error in the IKEv2 spec. There are three simple possible ways to change this: SUGGESTION A: The last sentence of 3.3.2 says: If Transform Type 5 is not included in a proposal, use of Extended Sequence Numbers is assumed. Replace this with: If Transform Type 5 is not included in a proposal, it is assumed that the sending party does not support Extended Sequence Numbers. SUGGESTION B: Create a new response notification that says "I can't do ESN, start again and include a 'no ESN' transform." SUGGESTION C: Change the places that says Transform Type 5 is optional to say it is mandatory. ------------------- The people I spoke with at the bakeoff agreed that suggestions A and=20 C would both work and be easy to implement. Personally, I think=20 suggestion C is better because having defaults tends to lead to=20 interoperability issues down the line when new implementers don't=20 read all the defaults. It's only a few extra bytes per proposal to=20 always be explicit. Please respond on the list soon so that the WG co-chairs can advise=20 the ADs of the WG consensus on this and prevent a delay in the=20 document's publication. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Mar 1 07:03:21 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA16557 for ; Tue, 1 Mar 2005 07:03:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D661u-0008BE-6U; Tue, 01 Mar 2005 06:59:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D661s-0008B9-Ju for ipsec@megatron.ietf.org; Tue, 01 Mar 2005 06:59:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA15972 for ; Tue, 1 Mar 2005 06:59:05 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D662n-00012k-Bw for ipsec@ietf.org; Tue, 01 Mar 2005 07:00:07 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j21Bx6A27991; Tue, 1 Mar 2005 13:59:06 +0200 (EET) X-Scanned: Tue, 1 Mar 2005 13:55:38 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j21Btc2O023986; Tue, 1 Mar 2005 13:55:38 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00QIt97f; Tue, 01 Mar 2005 13:55:34 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j21BtXU10409; Tue, 1 Mar 2005 13:55:33 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 1 Mar 2005 13:55:25 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 1 Mar 2005 13:55:24 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Technical change needed to IKEv2 before publication Date: Tue, 1 Mar 2005 13:55:23 +0200 Message-ID: Thread-Topic: [Ipsec] Technical change needed to IKEv2 before publication thread-index: AcUd+uOGzXOqDc7kSlahmDtRA3UB5AAVyl8A To: , X-OriginalArrivalTime: 01 Mar 2005 11:55:24.0564 (UTC) FILETIME=[8D8A6D40:01C51E55] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7fa173a723009a6ca8ce575a65a5d813 Content-Transfer-Encoding: quoted-printable Cc: housley@vigilsec.com, tytso@mit.edu, byfraser@cisco.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi, I wasn't at the bakeoff, but I don't quite see what the=20 problem is.. My reading of the spec was that a proposal with no ESN transform=20 means exactly the same thing as the same proposal + ESN transform=20 containing value 1. ("If Transform Type 5 is not included in a=20 proposal, use of Extended Sequence Numbers is assumed.") Thus, a proposal with ESN(0) means "don't use ESNs", a proposal=20 with ESN(1) or no ESN transform at all means "use ESNs", and a=20 proposal containing both ESN(0) and ESN(1) means "either of=20 these alternatives is fine with me, you choose". So, if the initiator does not include the ESN transform at all, it really means "using normal sequence numbers is not acceptable according to my policy", so if the responder does not support ESNs, it will reply with NO_PROPOSAL_CHOSEN. (This would be consistent with how other transform types work; e.g., if initiator includes only ENCR(AES_CBC) it means that other choices are not acceptable, while including both both ENCR(3DES) and ENCR(AES_CBC) means "either of these=20 is fine with me, you choose".) (Or is there some non-obvious problem with this approach that I missed?) Best regards, Pasi > -----Original Message----- > From: ipsec-bounces@ietf.org=20 > [mailto:ipsec-bounces@ietf.org]On Behalf Of > ext Paul Hoffman > Sent: Tuesday, March 01, 2005 2:26 AM > To: IPsec WG > Cc: Theodore Y. Ts'o; Russ Housley; Barbara Fraser > Subject: [Ipsec] Technical change needed to IKEv2 before publication >=20 >=20 > Greetings again. During the IKEv2 bakeoff last week, a technical=20 > mistake was found in the current IKEv2 Internet Draft. This is not=20 > something that simply needs to be clarified; it needs an actual fix=20 > to the document because, without it, interoperability is literally=20 > impossible. >=20 > (FWIW, the bakeoff also led to about 25 clarifications that will be=20 > sent to the list soon. These are all clarifications to areas that one=20 > or more bakeoff participant felt was unclear. They are only=20 > clarifications, not technical changes.) >=20 > After discussing this briefly with Russ Housley, our AD, we decided=20 > to poll the Working Group on how to fix the problem. If we can reach=20 > consensus soon (such as within a week from today), it may not delay=20 > the publication of the IKEv2 RFC. Russ will want to hear from the WG=20 > co-chairs as to our consensus. >=20 > ------------------- >=20 > Issue: If a receiver doesn't support ESN, they require the sender > to send an ESN transform >=20 > Some systems know that they don't support ESN, and therefore they > require the other side to actively say they won't expect it. The only > way for the other side to do so is for it to send a Transform Type > 5 with a value of 0. However, there is no way for the responder to > say that to the initiator, so interoperability is not possible. >=20 > This is a technical error in the IKEv2 spec. There are three simple > possible ways to change this: >=20 > SUGGESTION A: > The last sentence of 3.3.2 says: > If Transform Type 5 is not included in a proposal, use of > Extended Sequence Numbers is assumed. > Replace this with: > If Transform Type 5 is not included in a proposal, it is > assumed that the sending party does not support Extended > Sequence Numbers. >=20 > SUGGESTION B: > Create a new response notification that says "I can't do ESN, start > again and include a 'no ESN' transform." >=20 > SUGGESTION C: > Change the places that says Transform Type 5 is optional to say > it is mandatory. >=20 > ------------------- >=20 > The people I spoke with at the bakeoff agreed that suggestions A and=20 > C would both work and be easy to implement. Personally, I think=20 > suggestion C is better because having defaults tends to lead to=20 > interoperability issues down the line when new implementers don't=20 > read all the defaults. It's only a few extra bytes per proposal to=20 > always be explicit. >=20 > Please respond on the list soon so that the WG co-chairs can advise=20 > the ADs of the WG consensus on this and prevent a delay in the=20 > document's publication. >=20 > --Paul Hoffman, Director > --VPN Consortium >=20 > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec >=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Mar 1 08:05:04 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21509 for ; Tue, 1 Mar 2005 08:05:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D66wg-0001IH-0K; Tue, 01 Mar 2005 07:57:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D66we-0001IC-L8 for ipsec@megatron.ietf.org; Tue, 01 Mar 2005 07:57:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20441 for ; Tue, 1 Mar 2005 07:57:45 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D66xa-0002DL-CY for ipsec@ietf.org; Tue, 01 Mar 2005 07:58:48 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j21CvhNV000875; Tue, 1 Mar 2005 04:57:43 -0800 (PST) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j21CvgQp017520; Tue, 1 Mar 2005 07:57:42 -0500 (EST) Subject: RE: [Ipsec] Technical change needed to IKEv2 before publication From: Bill Sommerfeld To: Pasi.Eronen@nokia.com In-Reply-To: References: Content-Type: text/plain Message-Id: <1109681791.66695.18581.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Tue, 01 Mar 2005 07:56:34 -0500 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, tytso@mit.edu, byfraser@cisco.com, Russ Housley , paul.hoffman@vpnc.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit > I wasn't at the bakeoff, but I don't quite see what the > problem is. I wasn't at the bakeoff, either, but I think I see what it is. I have this odd feeling that we are reinventing ethernet capability negotiation, badly. > So, if the initiator does not include the ESN transform at all, > it really means "using normal sequence numbers is not acceptable > according to my policy", so if the responder does not support > ESNs, it will reply with NO_PROPOSAL_CHOSEN. .. and bits don't move. I'm not sure how proposals "A" and "C" help interoperability. It looks to me more like a disagreement on the default. There is this bit in section 3.3.3: ... "A proposal MAY omit the optional types if the only value for them it will accept is NONE." which is inconsistent with the ESN default defined in the immediately previous section. Aside from fixing the above, to I'd think we'd need to codify one of: - if you can do ESN, double your fun: when in doubt, always include both ESN and non-ESN variants in your proposals. - psychic retry logic ("maybe I should try again with ESN turned off"). Option "B", or a richer variant ("I can {always, never, sometimes} do ESN with {AH, ESP}" would help both variants: 1) it lets the peer trim out proposals which it knows would be rejected 2) requires less psychic ability in the initiator That said, there is this bit in the next section: 3.3.3 Valid Transform Types by Protocol ... "A proposal MAY omit the optional types if the only value for them it will accept is NONE." which is inconsistent with the ESN default defined in the immediately previous section. - Bill _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Mar 1 08:19:25 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA23097 for ; Tue, 1 Mar 2005 08:19:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D67EY-00064d-N3; Tue, 01 Mar 2005 08:16:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D67EW-00064O-Lm for ipsec@megatron.ietf.org; Tue, 01 Mar 2005 08:16:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22729 for ; Tue, 1 Mar 2005 08:16:13 -0500 (EST) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D67FT-0002vn-Pv for ipsec@ietf.org; Tue, 01 Mar 2005 08:17:16 -0500 Content-class: urn:content-classes:message Subject: RE: [Ipsec] Technical change needed to IKEv2 before publication MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Mar 2005 05:16:06 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Message-ID: Thread-Topic: [Ipsec] Technical change needed to IKEv2 before publication thread-index: AcUd+uOGzXOqDc7kSlahmDtRA3UB5AAVyl8AAANV+dA= From: "Vishwas Manral" To: , , X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: quoted-printable Cc: tytso@mit.edu, housley@vigilsec.com, byfraser@cisco.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Pasi, I do not understand IKE well, however the place where I think clarification is needed is: - "If a transform is optional and the initiator wishes to propose that the transform be omitted, no transform of the given type is included in the proposal." from the above I assume it means that the responder should not have the transform in the response. however If Transform Type 5 is not included in a proposal, use of Extended Sequence Numbers is assumed. The simpler solution could be to respond with ESN (0). Does it make sense? I had another doubt about transform Id 0 being used for transform type 5. Is it ok to use a transform ID of 0(as I think it holds a special meaning)? Thanks, Vishwas -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Pasi.Eronen@nokia.com Sent: Tuesday, March 01, 2005 5:25 PM To: paul.hoffman@vpnc.org; ipsec@ietf.org Cc: housley@vigilsec.com; tytso@mit.edu; byfraser@cisco.com Subject: RE: [Ipsec] Technical change needed to IKEv2 before publication Hi, I wasn't at the bakeoff, but I don't quite see what the=20 problem is.. My reading of the spec was that a proposal with no ESN transform=20 means exactly the same thing as the same proposal + ESN transform=20 containing value 1. ("If Transform Type 5 is not included in a=20 proposal, use of Extended Sequence Numbers is assumed.") Thus, a proposal with ESN(0) means "don't use ESNs", a proposal=20 with ESN(1) or no ESN transform at all means "use ESNs", and a=20 proposal containing both ESN(0) and ESN(1) means "either of=20 these alternatives is fine with me, you choose". So, if the initiator does not include the ESN transform at all, it really means "using normal sequence numbers is not acceptable according to my policy", so if the responder does not support ESNs, it will reply with NO_PROPOSAL_CHOSEN. (This would be consistent with how other transform types work; e.g., if initiator includes only ENCR(AES_CBC) it means that other choices are not acceptable, while including both both ENCR(3DES) and ENCR(AES_CBC) means "either of these=20 is fine with me, you choose".) (Or is there some non-obvious problem with this approach that I missed?) Best regards, Pasi > -----Original Message----- > From: ipsec-bounces@ietf.org=20 > [mailto:ipsec-bounces@ietf.org]On Behalf Of > ext Paul Hoffman > Sent: Tuesday, March 01, 2005 2:26 AM > To: IPsec WG > Cc: Theodore Y. Ts'o; Russ Housley; Barbara Fraser > Subject: [Ipsec] Technical change needed to IKEv2 before publication >=20 >=20 > Greetings again. During the IKEv2 bakeoff last week, a technical=20 > mistake was found in the current IKEv2 Internet Draft. This is not=20 > something that simply needs to be clarified; it needs an actual fix=20 > to the document because, without it, interoperability is literally=20 > impossible. >=20 > (FWIW, the bakeoff also led to about 25 clarifications that will be=20 > sent to the list soon. These are all clarifications to areas that one=20 > or more bakeoff participant felt was unclear. They are only=20 > clarifications, not technical changes.) >=20 > After discussing this briefly with Russ Housley, our AD, we decided=20 > to poll the Working Group on how to fix the problem. If we can reach=20 > consensus soon (such as within a week from today), it may not delay=20 > the publication of the IKEv2 RFC. Russ will want to hear from the WG=20 > co-chairs as to our consensus. >=20 > ------------------- >=20 > Issue: If a receiver doesn't support ESN, they require the sender > to send an ESN transform >=20 > Some systems know that they don't support ESN, and therefore they > require the other side to actively say they won't expect it. The only > way for the other side to do so is for it to send a Transform Type > 5 with a value of 0. However, there is no way for the responder to > say that to the initiator, so interoperability is not possible. >=20 > This is a technical error in the IKEv2 spec. There are three simple > possible ways to change this: >=20 > SUGGESTION A: > The last sentence of 3.3.2 says: > If Transform Type 5 is not included in a proposal, use of > Extended Sequence Numbers is assumed. > Replace this with: > If Transform Type 5 is not included in a proposal, it is > assumed that the sending party does not support Extended > Sequence Numbers. >=20 > SUGGESTION B: > Create a new response notification that says "I can't do ESN, start > again and include a 'no ESN' transform." >=20 > SUGGESTION C: > Change the places that says Transform Type 5 is optional to say > it is mandatory. >=20 > ------------------- >=20 > The people I spoke with at the bakeoff agreed that suggestions A and=20 > C would both work and be easy to implement. Personally, I think=20 > suggestion C is better because having defaults tends to lead to=20 > interoperability issues down the line when new implementers don't=20 > read all the defaults. It's only a few extra bytes per proposal to=20 > always be explicit. >=20 > Please respond on the list soon so that the WG co-chairs can advise=20 > the ADs of the WG consensus on this and prevent a delay in the=20 > document's publication. >=20 > --Paul Hoffman, Director > --VPN Consortium >=20 >=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Mar 1 09:17:39 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28130 for ; Tue, 1 Mar 2005 09:17:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D685c-00006K-Bq; Tue, 01 Mar 2005 09:11:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D685a-00006F-4M for ipsec@megatron.ietf.org; Tue, 01 Mar 2005 09:11:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27466 for ; Tue, 1 Mar 2005 09:11:02 -0500 (EST) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D686W-00047j-Fz for ipsec@ietf.org; Tue, 01 Mar 2005 09:12:06 -0500 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.7p1+Sun/8.11.6) with ESMTP id j21EAr816018; Tue, 1 Mar 2005 16:10:53 +0200 (IST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <33ad74a782d6d09442979852569a21a9@checkpoint.com> Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] Technical change needed to IKEv2 before publication Date: Tue, 1 Mar 2005 16:10:50 +0200 To: "Vishwas Manral" X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 7bit Cc: IPsec WG , Paul Hoffman X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit On Mar 1, 2005, at 3:16 PM, Vishwas Manral wrote: If Transform Type 5 is not included in a proposal, use of > Extended Sequence Numbers is assumed. > > The simpler solution could be to respond with ESN (0). Does it make > sense? > > I had another doubt about transform Id 0 being used for transform type > 5. Is it ok to use a transform ID of 0(as I think it holds a special > meaning)? > > Thanks, > Vishwas The problem is that yes(1) and no(0) are the two valid values for the ESN transform type. Any IPsec SA uses this transform (with either a yes or no value) and any proposal includes it either explicitly or implicitly by omission. If the initiator proposed ESN(1), the responder cannot answer ESN(0) because the zero value was not proposed by the initiator. It's the same as if the initiator proposed ENCR(3DES) and the responder answered ENCR(AES_128). Another option would have been to have 1 as the only valid value, and then omission would be the same as saying that ESN is not supported, but in that case, how could the transform be optional? I also don't like Bill's idea of having a richer variant of "B". This makes for repeated exchanges with slightly differing proposals until something works. This is fine for Ethernet or PPP where you can have multiple such exchanges in a second, but on the Internet where packets may take a full second or more to make a round trip, this would make the setting up of tunnels very long. It would be nice to have an explanation accompanying the "NO PROPOSAL CHOSEN", so that administrators can better configure their VPN, but as it stands, making the specification mandatory is the best way out. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Mar 1 10:05:09 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02894 for ; Tue, 1 Mar 2005 10:05:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D68s3-00032Y-GP; Tue, 01 Mar 2005 10:01:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D68s2-00032T-3S for ipsec@megatron.ietf.org; Tue, 01 Mar 2005 10:01:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02505 for ; Tue, 1 Mar 2005 10:01:08 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.193]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D68sz-0005Oh-2X for Ipsec@ietf.org; Tue, 01 Mar 2005 10:02:10 -0500 Received: by wproxy.gmail.com with SMTP id 71so1259190wri for ; Tue, 01 Mar 2005 07:00:59 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=RzBzclfWQiRbutnsn0Lg4bLmbIYW3Wk7FnPAK9fGit7Pse+vCkHtTQygfg7iZTBO4btnH/nbiqp+iTvZa3BB9NvGaDUCVnj6jCZ4TwNzeq/jQQR1ZVtXIblGfK2gZWb16FkvTZxGa4gXlKuslhLVVmyPZaiW2dU73avRIWZt4b4= Received: by 10.54.5.75 with SMTP id 75mr79475wre; Tue, 01 Mar 2005 07:00:58 -0800 (PST) Received: by 10.54.36.63 with HTTP; Tue, 1 Mar 2005 07:00:58 -0800 (PST) Message-ID: <7f96c8390503010700553a2ccd@mail.gmail.com> Date: Tue, 1 Mar 2005 10:00:58 -0500 From: Mike Zheng To: Ipsec@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7bit Subject: [Ipsec] IPSec and X.509 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Mike Zheng List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi All, Do we need X.509 to do authentication before the IPSec setup the connection via IKE? Thanks, _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Mar 1 10:18:39 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04658 for ; Tue, 1 Mar 2005 10:18:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D697O-0005Ny-GW; Tue, 01 Mar 2005 10:17:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D697M-0005Nt-AF for ipsec@megatron.ietf.org; Tue, 01 Mar 2005 10:17:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA04412 for ; Tue, 1 Mar 2005 10:16:58 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D698J-0005in-0p for ipsec@ietf.org; Tue, 01 Mar 2005 10:18:00 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j21FGbU24085; Tue, 1 Mar 2005 17:16:38 +0200 (EET) X-Scanned: Tue, 1 Mar 2005 17:12:26 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j21FCQHx024935; Tue, 1 Mar 2005 17:12:26 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks004.ntc.nokia.com 00ANB82S; Tue, 01 Mar 2005 17:12:24 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j21FCIM23584; Tue, 1 Mar 2005 17:12:18 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 1 Mar 2005 17:12:17 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 1 Mar 2005 17:12:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Technical change needed to IKEv2 before publication Date: Tue, 1 Mar 2005 17:12:18 +0200 Message-ID: Thread-Topic: [Ipsec] Technical change needed to IKEv2 before publication thread-index: AcUeX8IDrlOaj8e6RXqM1RbS2r55swADO/kA To: X-OriginalArrivalTime: 01 Mar 2005 15:12:17.0900 (UTC) FILETIME=[0ED672C0:01C51E71] X-Spam-Score: 0.3 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, byfraser@cisco.com, housley@vigilsec.com, tytso@mit.edu, paul.hoffman@vpnc.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Bill Sommerfeld writes: > > So, if the initiator does not include the ESN transform at > > all, it really means "using normal sequence numbers is not > > acceptable according to my policy", so if the responder does > > not support ESNs, it will reply with NO_PROPOSAL_CHOSEN. >=20 > .. and bits don't move. Yes (which is exactly what should happen, since doing otherwise would violate the initiator's policy -- not that such a policy would be very common or sensible, though). > I'm not sure how proposals "A" and "C" help interoperability. > It looks to me more like a disagreement on the default. >=20 > There is this bit in section 3.3.3: >=20 > ... "A proposal MAY omit the optional types if the only value=20 > for them it will accept is NONE." >=20 > which is inconsistent with the ESN default defined in the=20 > immediately previous section. Hmm... this depends on whether you consider ESN something that can be omitted (just like you can omit integrity protection for ESP), or whether sequence numbers is something that you always have, and we currently have two different "algorithms" for handling them. >From the latter viewpoint, the choices are "normal" and "extended" (there is no value "NONE"), and the current text is (mostly) consistent. It would also imply that initiators that support ESN will almost always include both ESN(0=3Dnormal) and ESN(1=3Dextended) in their proposals. But if you like the former viewpoint better, then the current text is inconsistent (at least the text you quoted from 3.3.3). It seems that suggestion A from Paul's email (no ESN transform in the proposal means no ESNs) would make it consistent, though. It would still imply that an initiator who supports ESNs but accepts also normal sequence numbers has to include both ESN(0) and ESN(1) transforms in proposals. A third alternative would be to adopt option A, but in addition change the negotiation logic so that including ESN(1) also implies that ESN(0) is acceptable. I don't think we should do this, since it's not consistent with how other transforms are negotiated (e.g., proposing ENCR(AES) does not mean that you're willing to accept ENCR(NONE)). Any which way, I don't see any need for new notification=20 payloads here.=20 Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Mar 1 10:32:49 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06779 for ; Tue, 1 Mar 2005 10:32:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D69Jg-0000UZ-IJ; Tue, 01 Mar 2005 10:29:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D69Jd-0000UP-JA for ipsec@megatron.ietf.org; Tue, 01 Mar 2005 10:29:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06427 for ; Tue, 1 Mar 2005 10:29:39 -0500 (EST) Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D69Kb-00065A-C4 for ipsec@ietf.org; Tue, 01 Mar 2005 10:30:41 -0500 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id j21FTVjY019948 for ; Tue, 1 Mar 2005 10:29:31 -0500 Received: from M30.equallogic.com (m30 [172.16.1.30]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id j21FTUIT019943; Tue, 1 Mar 2005 10:29:30 -0500 Received: from PKONING.equallogic.com ([172.16.1.108]) by M30.equallogic.com with Microsoft SMTPSVC(5.0.2195.6713); Tue, 1 Mar 2005 10:29:30 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16932.35417.457000.888750@gargle.gargle.HOWL> Date: Tue, 1 Mar 2005 10:29:29 -0500 From: Paul Koning To: sommerfeld@sun.com Subject: RE: [Ipsec] Technical change needed to IKEv2 before publication References: <1109681791.66695.18581.camel@unknown.hamachi.org> X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid X-OriginalArrivalTime: 01 Mar 2005 15:29:30.0510 (UTC) FILETIME=[76523AE0:01C51E73] X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, tytso@mit.edu, byfraser@cisco.com, Pasi.Eronen@nokia.com, housley@vigilsec.com, paul.hoffman@vpnc.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit >>>>> "Bill" == Bill Sommerfeld writes: Bill> I'm not sure how proposals "A" and "C" help interoperability. Bill> It looks to me more like a disagreement on the default. Perhaps, but so what? I'm wondering the same thing as Pasi mentioned. All things being equal, it seems reasonable to make the ESN transform type code mandatory rather than optional. But unless I'm missing something, that doesn't affect the original issue at all. I believe the original problem statement was: a. Sender insists on ESN b. Responder doesn't support ESN Clearly "no proposal chosen" is the expected and correct outcome then. If the sender actually wanted to allow ESN either on or off, it should have proposed that. Right now, the sender can express "I insist on ESN" two ways (by sending ESN(1) or by not sending ESN at all). But the semantics are the same either way. Yes, the encoding rule for ESN is inconsistent with other rules, and yes, it would be reasonable to clean that up, but that won't affect the outcome of the negotiation in the case under discussion. Bill> - if you can do ESN, double your fun: when in doubt, always Bill> include both ESN and non-ESN variants in your proposals. Bill> - psychic retry logic ("maybe I should try again with ESN Bill> turned off"). Right. That's just a specific case of this general observation: If you propose lots of things, something may end up being chosen. If you propose few things, you may get "no proposal chosen" at which point you're either out of luck or you have to make some guesses about what to do next. I prefer the former, but either is permitted. paul _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Mar 1 10:50:45 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08330 for ; Tue, 1 Mar 2005 10:50:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D69cP-0004ZJ-TU; Tue, 01 Mar 2005 10:49:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D69cP-0004ZE-2Z for ipsec@megatron.ietf.org; Tue, 01 Mar 2005 10:49:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08204 for ; Tue, 1 Mar 2005 10:49:03 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D69dM-0006VU-Ke for ipsec@ietf.org; Tue, 01 Mar 2005 10:50:06 -0500 Received: from [10.20.30.249] (dsl2-63-249-109-245.cruzio.com [63.249.109.245]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j21FltYe015906; Tue, 1 Mar 2005 07:47:56 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1109681791.66695.18581.camel@unknown.hamachi.org> References: <1109681791.66695.18581.camel@unknown.hamachi.org> Date: Tue, 1 Mar 2005 07:47:53 -0800 To: IPsec WG From: Paul Hoffman Subject: RE: [Ipsec] Technical change needed to IKEv2 before publication Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: tytso@mit.edu, housley@vigilsec.com, byfraser@cisco.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 1:55 PM +0200 3/1/05, Pasi.Eronen@nokia.com wrote: >My reading of the spec was that a proposal with no ESN transform >means exactly the same thing as the same proposal + ESN transform >containing value 1. ("If Transform Type 5 is not included in a >proposal, use of Extended Sequence Numbers is assumed.") Correct; there was no disagreement there. >Thus, a proposal with ESN(0) means "don't use ESNs", a proposal >with ESN(1) or no ESN transform at all means "use ESNs", and a >proposal containing both ESN(0) and ESN(1) means "either of >these alternatives is fine with me, you choose". Right. >So, if the initiator does not include the ESN transform at all, >it really means "using normal sequence numbers is not acceptable >according to my policy", so if the responder does not support >ESNs, it will reply with NO_PROPOSAL_CHOSEN. Exactly. There is no way to say *why* no proposal was chosen, so that the initiator, if they actually want a tunnel up, has to randomly guess the reason. That leads to lack of interop, which we saw at the bakeoff. >(This would be consistent with how other transform types work; >e.g., if initiator includes only ENCR(AES_CBC) it means that >other choices are not acceptable, while including both >both ENCR(3DES) and ENCR(AES_CBC) means "either of these >is fine with me, you choose".) The major conceptual difference is that ESNs have *nothing* to do with either traffic flow or cryptography; they are simply a housekeeping feature that each side has. At 7:56 AM -0500 3/1/05, Bill Sommerfeld wrote: >I have this odd feeling that we are reinventing ethernet capability >negotiation, badly. s/are reinventing/have reinvented/ It is too late to change them now. If you look through the negotiation and announcement mechanisms we use in IKEv2, you see that some are done with transform proposals for which there is no response other than yes or no, others are through transform proposals for which there is an informative hint that can be attached to a failure, some are just through notifications, and some are through vendor-ids. >I'm not sure how proposals "A" and "C" help interoperability. >It looks to me more like a disagreement on the default. "A" (change the default) helps in the currently-common case where the recipient hasn't implemented ESNs; it hurts in the long-run case when most systems will have implemented ESNs. "C" (make the transform mandatory) helps all the time: it says exactly what the initiator is willing to do (ESN, no ESN, or either). Without sending the transform, it is not clear whether the initiator is insisting on ESN or simply preferring it. (This part is murky for all proposals, of course.) >There is this bit in section 3.3.3: > > ... "A proposal MAY > omit the optional types if the only value for them it will accept is > NONE." > >which is inconsistent with the ESN default defined in the immediately >previous section. ...and probably inconsistent with what "NONE" means. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Mar 1 10:56:49 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08915 for ; Tue, 1 Mar 2005 10:56:49 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D69gq-0005Mj-SR; Tue, 01 Mar 2005 10:53:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D69go-0005MZ-Ga for ipsec@megatron.ietf.org; Tue, 01 Mar 2005 10:53:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08587 for ; Tue, 1 Mar 2005 10:53:36 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D69hl-0006cn-QT for ipsec@ietf.org; Tue, 01 Mar 2005 10:54:39 -0500 Received: from [10.20.30.249] (dsl2-63-249-109-245.cruzio.com [63.249.109.245]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j21FqTqt016348; Tue, 1 Mar 2005 07:52:30 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <16932.35417.457000.888750@gargle.gargle.HOWL> References: <1109681791.66695.18581.camel@unknown.hamachi.org> <16932.35417.457000.888750@gargle.gargle.HOWL> Date: Tue, 1 Mar 2005 07:52:27 -0800 To: IPsec WG From: Paul Hoffman Subject: RE: [Ipsec] Technical change needed to IKEv2 before publication Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: byfraser@cisco.com, housley@vigilsec.com, tytso@mit.edu X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org A different way to view this, one which does *not* require us to change the current IKEv2 spec, would be to make this a clarification. We could simply write a clarification (that would go into Pasi's clarification document) that would add a sentence to the end of Section 3.3.2 that says "Note that if the initiator is willing to accept either the use of extended sequence numbers or not, the initiator SHOULD send this transform in its proposals." --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Mar 1 11:23:38 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11915 for ; Tue, 1 Mar 2005 11:23:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6A6T-0003AJ-9Y; Tue, 01 Mar 2005 11:20:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6A6R-0003A4-ST for ipsec@megatron.ietf.org; Tue, 01 Mar 2005 11:20:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11383 for ; Tue, 1 Mar 2005 11:20:05 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6A7O-0007L5-Cv for ipsec@ietf.org; Tue, 01 Mar 2005 11:21:08 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j21GJvU16909; Tue, 1 Mar 2005 18:19:57 +0200 (EET) X-Scanned: Tue, 1 Mar 2005 18:18:27 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j21GIRuk032725; Tue, 1 Mar 2005 18:18:27 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 004lzBGT; Tue, 01 Mar 2005 18:18:25 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j21GINM04691; Tue, 1 Mar 2005 18:18:23 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 1 Mar 2005 18:18:22 +0200 Received: from esebe003.NOE.Nokia.com ([172.21.138.39]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 1 Mar 2005 18:18:22 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 1 Mar 2005 18:18:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Technical change needed to IKEv2 before publication Date: Tue, 1 Mar 2005 18:18:22 +0200 Message-ID: Thread-Topic: [Ipsec] Technical change needed to IKEv2 before publication thread-index: AcUed1rUBZo6GEYWRGyDRHGlwGWzowAAEIQQ To: , X-OriginalArrivalTime: 01 Mar 2005 16:18:22.0345 (UTC) FILETIME=[49D4BF90:01C51E7A] X-Spam-Score: 0.3 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: housley@vigilsec.com, tytso@mit.edu, byfraser@cisco.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Paul Hoffman writes: >=20 > At 1:55 PM +0200 3/1/05, Pasi.Eronen@nokia.com wrote: >> My reading of the spec was that a proposal with no ESN transform >> means exactly the same thing as the same proposal + ESN transform >> containing value 1. ("If Transform Type 5 is not included in a >> proposal, use of Extended Sequence Numbers is assumed.") >=20 > Correct; there was no disagreement there. >=20 >> Thus, a proposal with ESN(0) means "don't use ESNs", a proposal >> with ESN(1) or no ESN transform at all means "use ESNs", and a >> proposal containing both ESN(0) and ESN(1) means "either of >> these alternatives is fine with me, you choose". >=20 > Right. Except I guess here some people were interpreting a proposal=20 with only ESN(1) to mean "I support ESNs, but normal sequence=20 numbers are also fine"...? > >So, if the initiator does not include the ESN transform at all, > >it really means "using normal sequence numbers is not acceptable > >according to my policy", so if the responder does not support > >ESNs, it will reply with NO_PROPOSAL_CHOSEN. >=20 > Exactly. There is no way to say *why* no proposal was chosen, so=20 > that the initiator, if they actually want a tunnel up, has to=20 > randomly guess the reason. That leads to lack of interop, which=20 > we saw at the bakeoff. Well, it does not lead to (unnecessary) lack of interop if both=20 parties agree that omitting ESN transform means "normal sequence=20 numbers are not acceptable". Presumably a sensible initiator would not have such a policy=20 in the first place. And if it has, the protocol can't do much=20 about it: if the policies are fundamentally incompatible, they=20 can't be no interop. (I think this is not really that different from the situation where=20 the initiator's policy requires some FOOBAR encryption algorithm=20 (and nothing else is acceptable) which the responder does not=20 support: there's no way to say why no proposal was chosen in this=20 case, either.) >> (This would be consistent with how other transform types work; >> e.g., if initiator includes only ENCR(AES_CBC) it means that >> other choices are not acceptable, while including both >> both ENCR(3DES) and ENCR(AES_CBC) means "either of these >> is fine with me, you choose".) >=20 > The major conceptual difference is that ESNs have *nothing* to > do with either traffic flow or cryptography; they are simply a=20 > housekeeping feature that each side has. Right. But they're still using the same negotiation mechanisms,=20 and that leads to some complications. In hindsight, perhaps having something like IPCOMP_SUPPORTED notification would have been better, but it's too late to change that now... Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Mar 1 11:28:28 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12590 for ; Tue, 1 Mar 2005 11:28:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6ABZ-0004KS-Hl; Tue, 01 Mar 2005 11:25:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6ABU-0004Ia-32 for ipsec@megatron.ietf.org; Tue, 01 Mar 2005 11:25:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA12167 for ; Tue, 1 Mar 2005 11:25:18 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6ACS-0007Xz-0C for ipsec@ietf.org; Tue, 01 Mar 2005 11:26:21 -0500 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j21GPANV015244; Tue, 1 Mar 2005 08:25:11 -0800 (PST) Received: from thunk (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j21GPAOp005663; Tue, 1 Mar 2005 11:25:10 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j21GPAw7002630; Tue, 1 Mar 2005 11:25:10 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j21GP9o0002629; Tue, 1 Mar 2005 11:25:09 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: RE: [Ipsec] Technical change needed to IKEv2 before publication From: Bill Sommerfeld To: Paul Koning In-Reply-To: <16932.35417.457000.888750@gargle.gargle.HOWL> References: <1109681791.66695.18581.camel@unknown.hamachi.org> <16932.35417.457000.888750@gargle.gargle.HOWL> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1109694308.2268.37.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Tue, 01 Mar 2005 11:25:08 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, tytso@mit.edu, byfraser@cisco.com, Pasi.Eronen@nokia.com, housley@vigilsec.com, paul.hoffman@vpnc.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit On Tue, 2005-03-01 at 10:29, Paul Koning wrote: > I believe the original problem statement was: > > a. Sender insists on ESN > b. Responder doesn't support ESN I'm questioning the utility of (a) in real-world networks. What actual problems are solved by failing to move bits unless the responder supports ESN? The fix needs to include recommendations to implementors regarding how to avoid this little "wings-stay-on / wings-fall-off" option trap. - Bill _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Mar 1 11:39:30 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14581 for ; Tue, 1 Mar 2005 11:39:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6AMX-0008Iu-Fr; Tue, 01 Mar 2005 11:36:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6AMW-0008Ip-3p for ipsec@megatron.ietf.org; Tue, 01 Mar 2005 11:36:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14199 for ; Tue, 1 Mar 2005 11:36:41 -0500 (EST) Received: from ns.ca.certicom.com ([66.48.18.197] helo=mail.ca.certicom.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D6ANT-0007wy-Lk for ipsec@ietf.org; Tue, 01 Mar 2005 11:37:45 -0500 Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id F0D5F10087; Tue, 1 Mar 2005 11:36:31 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13382-49; Tue, 1 Mar 2005 11:36:19 -0500 (EST) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 2A2E51006C; Tue, 1 Mar 2005 11:36:19 -0500 (EST) In-Reply-To: <16932.35417.457000.888750@gargle.gargle.HOWL> Subject: RE: [Ipsec] Technical change needed to IKEv2 before publication To: Paul Koning X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Tom Stiemerling Date: Tue, 1 Mar 2005 11:27:34 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 03/01/2005 11:27:35 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org The problem that was found at the bake-off is that some vendors implementations (correctly) insisted that the ESN(off) transform was included in all proposals, since they did not support ESN, and not including the ESN transform meant ESN was on (as specified in the draft). Therefore to interoperate with all responders - without knowing whether they supported ESN or not - the initiator always has to include either ESN(off) if it does not support ESN, or ESN(off) | ESN(on) if the responder does support ESN. So the ESN transform is then not really optional any more, and it was decided to make this explicit in the draft. Cheers, Tom > >>>>> "Bill" == Bill Sommerfeld writes: > > Bill> I'm not sure how proposals "A" and "C" help interoperability. > Bill> It looks to me more like a disagreement on the default. > > Perhaps, but so what? I'm wondering the same thing as Pasi mentioned. > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Mar 1 11:44:01 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14945 for ; Tue, 1 Mar 2005 11:44:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6ARe-0000Ug-0t; Tue, 01 Mar 2005 11:42:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6ARd-0000UY-1A for ipsec@megatron.ietf.org; Tue, 01 Mar 2005 11:42:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14811 for ; Tue, 1 Mar 2005 11:41:58 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6ASb-00085H-4p for ipsec@ietf.org; Tue, 01 Mar 2005 11:43:02 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 01 Mar 2005 08:54:28 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j21GfmZV013112; Tue, 1 Mar 2005 08:41:48 -0800 (PST) Received: from ghuangw2k01 ([10.32.227.18]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id BCH26979; Tue, 1 Mar 2005 08:41:46 -0800 (PST) Message-Id: <200503011641.BCH26979@mira-sjc5-b.cisco.com> From: "Geoffrey Huang" To: "'Paul Hoffman'" , "'IPsec WG'" Subject: RE: [Ipsec] Technical change needed to IKEv2 before publication Date: Tue, 1 Mar 2005 08:41:46 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4942.400 Thread-Index: AcUd9fQiH4B7cT6LRVWAKQ4NAakJJQAh5DvA X-Spam-Score: 0.0 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: 7bit Cc: "'Russ Housley'" , "'Theodore Y. Ts'o'" , "'Barbara Fraser'" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit I prefer C. -g > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Paul Hoffman > Sent: Monday, February 28, 2005 4:26 PM > To: IPsec WG > Cc: Theodore Y. Ts'o; Russ Housley; Barbara Fraser > Subject: [Ipsec] Technical change needed to IKEv2 before publication > > Greetings again. During the IKEv2 bakeoff last week, a > technical mistake was found in the current IKEv2 Internet > Draft. This is not something that simply needs to be > clarified; it needs an actual fix to the document because, > without it, interoperability is literally impossible. > > (FWIW, the bakeoff also led to about 25 clarifications that > will be sent to the list soon. These are all clarifications > to areas that one or more bakeoff participant felt was > unclear. They are only clarifications, not technical changes.) > > After discussing this briefly with Russ Housley, our AD, we > decided to poll the Working Group on how to fix the problem. > If we can reach consensus soon (such as within a week from > today), it may not delay the publication of the IKEv2 RFC. > Russ will want to hear from the WG co-chairs as to our consensus. > > ------------------- > > Issue: If a receiver doesn't support ESN, they require the > sender to send an ESN transform > > Some systems know that they don't support ESN, and therefore > they require the other side to actively say they won't expect > it. The only way for the other side to do so is for it to > send a Transform Type > 5 with a value of 0. However, there is no way for the > responder to say that to the initiator, so interoperability > is not possible. > > This is a technical error in the IKEv2 spec. There are three > simple possible ways to change this: > > SUGGESTION A: > The last sentence of 3.3.2 says: > If Transform Type 5 is not included in a proposal, use of > Extended Sequence Numbers is assumed. > Replace this with: > If Transform Type 5 is not included in a proposal, it is > assumed that the sending party does not support Extended > Sequence Numbers. > > SUGGESTION B: > Create a new response notification that says "I can't do ESN, > start again and include a 'no ESN' transform." > > SUGGESTION C: > Change the places that says Transform Type 5 is optional to > say it is mandatory. > > ------------------- > > The people I spoke with at the bakeoff agreed that > suggestions A and C would both work and be easy to implement. > Personally, I think suggestion C is better because having > defaults tends to lead to interoperability issues down the > line when new implementers don't read all the defaults. It's > only a few extra bytes per proposal to always be explicit. > > Please respond on the list soon so that the WG co-chairs can > advise the ADs of the WG consensus on this and prevent a > delay in the document's publication. > > --Paul Hoffman, Director > --VPN Consortium > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Mar 1 12:16:12 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18794 for ; Tue, 1 Mar 2005 12:16:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Atz-0005XR-Hc; Tue, 01 Mar 2005 12:11:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Aty-0005XM-Dm for ipsec@megatron.ietf.org; Tue, 01 Mar 2005 12:11:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18098 for ; Tue, 1 Mar 2005 12:11:16 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Auw-0000Ri-KY for ipsec@ietf.org; Tue, 01 Mar 2005 12:12:20 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j21HBAc23535; Tue, 1 Mar 2005 19:11:11 +0200 (EET) X-Scanned: Tue, 1 Mar 2005 19:07:59 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j21H7x9F015395; Tue, 1 Mar 2005 19:07:59 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 005h1q0R; Tue, 01 Mar 2005 19:07:05 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j21H75U10439; Tue, 1 Mar 2005 19:07:05 +0200 (EET) Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 1 Mar 2005 19:07:03 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 1 Mar 2005 19:07:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Technical change needed to IKEv2 before publication Date: Tue, 1 Mar 2005 19:07:04 +0200 Message-ID: Thread-Topic: [Ipsec] Technical change needed to IKEv2 before publication thread-index: AcUefccRo+FJFDsqQLa/gUUpEpGdxAAAOAXw To: X-OriginalArrivalTime: 01 Mar 2005 17:07:04.0197 (UTC) FILETIME=[1763FB50:01C51E81] X-Spam-Score: 0.3 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Tom Stiemerling writes: >=20 > The problem that was found at the bake-off is that some > vendors implementations (correctly) insisted that the ESN(off) > transform was included in all proposals, since they did not > support ESN, and not including the ESN transform meant ESN was > on (as specified in the draft). Therefore to interoperate with > all responders - without knowing whether they supported ESN or > not - the initiator always has to include either ESN(off) if > it does not support ESN, or ESN(off) | ESN(on) if the > responder does support ESN. So the ESN transform is then not > really optional any more, and it was decided to make this > explicit in the draft. According to the current draft, it's optional only if the initiator insists on using ESNs (and wants the negotiation to fail otherwise). I can't think of any reason why any sane initiator would want to do this, so at least a clarification explicitly saying so is needed: but we do not necessarily need any technical changes in the protocol. This clarification could be either in the IKEv2 draft, or the separate "IKEv2 Clarifications" draft I've been working on. I think getting IKEv2 out as RFC is more important than making=20 it perfect, so any minor clarifications should probably go to=20 the separate draft... but this might be important enough to go=20 to the IKEv2 spec (considering the bakeoff situation). So either=20 way is fine with me. Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Mar 1 12:18:53 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19218 for ; Tue, 1 Mar 2005 12:18:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6B0B-0007we-0M; Tue, 01 Mar 2005 12:17:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6B09-0007uy-Ia for ipsec@megatron.ietf.org; Tue, 01 Mar 2005 12:17:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19095 for ; Tue, 1 Mar 2005 12:17:39 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6B19-0000iA-1H for ipsec@ietf.org; Tue, 01 Mar 2005 12:18:43 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 01 Mar 2005 09:30:11 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j21HHTZV005446; Tue, 1 Mar 2005 09:17:30 -0800 (PST) Received: from sfanningw2k (dhcp-128-107-176-68.cisco.com [128.107.176.68]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BCH31033; Tue, 1 Mar 2005 09:17:28 -0800 (PST) Message-Id: <200503011717.BCH31033@mira-sjc5-b.cisco.com> From: "Scott Fanning" To: , Subject: RE: [Ipsec] Technical change needed to IKEv2 before publication Date: Tue, 1 Mar 2005 09:17:29 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4927.1200 Thread-Index: AcUefccRo+FJFDsqQLa/gUUpEpGdxAAAOAXwAADeaQA= X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit So, I guess the advantage of having IKEv2 described in one doc is out the door? <*sigh*>. I would rather see the current doc correct. You would have to add a pointer to the "clarifications draft" in the IKEv2 doc at the very least, or we end up with interop issues. A complete and accurate protocol specification avoids many interop issues IMHO. Scott -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Pasi.Eronen@nokia.com Sent: Tuesday, March 01, 2005 9:07 AM To: TStiemerling@certicom.com Cc: ipsec@ietf.org Subject: RE: [Ipsec] Technical change needed to IKEv2 before publication Tom Stiemerling writes: > > The problem that was found at the bake-off is that some vendors > implementations (correctly) insisted that the ESN(off) transform was > included in all proposals, since they did not support ESN, and not > including the ESN transform meant ESN was on (as specified in the > draft). Therefore to interoperate with all responders - without > knowing whether they supported ESN or not - the initiator always has > to include either ESN(off) if it does not support ESN, or ESN(off) | > ESN(on) if the responder does support ESN. So the ESN transform is > then not really optional any more, and it was decided to make this > explicit in the draft. According to the current draft, it's optional only if the initiator insists on using ESNs (and wants the negotiation to fail otherwise). I can't think of any reason why any sane initiator would want to do this, so at least a clarification explicitly saying so is needed: but we do not necessarily need any technical changes in the protocol. This clarification could be either in the IKEv2 draft, or the separate "IKEv2 Clarifications" draft I've been working on. I think getting IKEv2 out as RFC is more important than making it perfect, so any minor clarifications should probably go to the separate draft... but this might be important enough to go to the IKEv2 spec (considering the bakeoff situation). So either way is fine with me. Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Mar 1 14:22:14 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00604 for ; Tue, 1 Mar 2005 14:22:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Cvt-0007An-Ut; Tue, 01 Mar 2005 14:21:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Cvr-0007AX-TP for ipsec@megatron.ietf.org; Tue, 01 Mar 2005 14:21:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00538 for ; Tue, 1 Mar 2005 14:21:20 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Cwr-0003il-8f for ipsec@ietf.org; Tue, 01 Mar 2005 14:22:26 -0500 Received: from [10.20.30.249] (dsl2-63-249-109-245.cruzio.com [63.249.109.245]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j21JLJ65030938 for ; Tue, 1 Mar 2005 11:21:20 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200503011717.BCH31033@mira-sjc5-b.cisco.com> References: <200503011717.BCH31033@mira-sjc5-b.cisco.com> Date: Tue, 1 Mar 2005 11:20:22 -0800 To: ipsec@ietf.org From: Paul Hoffman Subject: RE: [Ipsec] Technical change needed to IKEv2 before publication Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 9:17 AM -0800 3/1/05, Scott Fanning wrote: >So, I guess the advantage of having IKEv2 described in one doc is out the >door? <*sigh*>. We knew that years ago. Given our experience with IKEv1, and the kind of mishmash that went into the development of IKEv2, we knew this would happen. > I would rather see the current doc correct. ...and never come out. > You would have >to add a pointer to the "clarifications draft" in the IKEv2 doc at the very >least, or we end up with interop issues. We will end up with interop issues regardless; the idea is to reduce them where possible. > A complete and accurate protocol >specification avoids many interop issues IMHO. That can happen later. That is, we can do a rewrite of the IKEv2 document itself, making no technical changes, just clarifications. This has happened before, in PKIX. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Mar 1 15:16:59 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07149 for ; Tue, 1 Mar 2005 15:16:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Djt-0000Ah-GH; Tue, 01 Mar 2005 15:13:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Djr-0000Ac-GY for ipsec@megatron.ietf.org; Tue, 01 Mar 2005 15:13:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA06473 for ; Tue, 1 Mar 2005 15:12:59 -0500 (EST) Received: from mx2.trusecure.com ([208.251.192.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6Dkq-0004vs-Tq for ipsec@ietf.org; Tue, 01 Mar 2005 15:14:06 -0500 Received: by mx2.trusecure.com (Postfix, from userid 1006) id 485FEC928F; Tue, 1 Mar 2005 15:12:47 -0500 (EST) Received: from VAMAIL01.corp.trusecure.net (vamail01.corp.cybertrust.net [172.19.1.52]) by mx2.trusecure.com (Postfix) with ESMTP id 37CDEC9244 for ; Tue, 1 Mar 2005 15:12:47 -0500 (EST) Received: from HRN-MSC-EXCH-01.mscore.trusecure.net (hrn-msc-exch-01.corp.cybertrust.net [172.19.1.49]) by VAMAIL01.corp.trusecure.net (8.12.10/maybe_its_not_even_really_Sendmail....) with ESMTP id j21KClCZ023295 for ; Tue, 1 Mar 2005 15:12:47 -0500 (EST) Received: from hrn-msc-exch-02.mscore.trusecure.net ([172.19.1.56]) by HRN-MSC-EXCH-01.mscore.trusecure.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 1 Mar 2005 15:12:47 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Mar 2005 15:12:47 -0500 Message-ID: <04D8F83756A1A84BA156BBFF26FAE0F5A7AF17@hrn-msc-exch-02.mscore.trusecure.net> Thread-Topic: IKEv2 Bakeoff Results Thread-Index: AcUemwke8Er6CPLMTAufc78Xln5cgg== From: "Zimmerman, Mark" To: X-OriginalArrivalTime: 01 Mar 2005 20:12:47.0740 (UTC) FILETIME=[0975B3C0:01C51E9B] X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] IKEv2 Bakeoff Results X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable It looks like the issues brought up last week are well under way discussion-wise. I want to thank Paul Hoffman for participating at the Santa Clara Event and doing an outstanding job documenting the technical policy issues. I've posted a results compilation document at the following URL: http://www.icsalabs.com/html/communities/ipsec/index.shtml This is not meant to be an exhaustive description of the issues encountered and currently being discussed here, but it does give an idea of what tests were performed, and to what degree development teams have progressed. Any suggestions as to improvements to this process will gladly be accepted. I've already been approached about the possibility of planning another event. It was suggested strongly that a next event be held OUTSIDE of the US due to the major hassles of obtaining visa's for development engineers. Toronto, Ottawa and Vancouver have been suggested as possible North American venues and July or September have been thrown out as possible good months. Any other suggestions will be entertained... Regards, Mark Zimmerman Program Manager ICSA Labs mzimmerman@icsalabs.com www.icsalabs.com *********************************************************************** This message is intended only for the use of the intended recipient and may contain information that is PRIVILEGED and/or CONFIDENTIAL. If you are not the intended recipient, you are hereby notified that any use, dissemination, disclosure or copying of this communication is strictly prohibited. If you have received this communication in error, please destroy all copies of this message and its attachments and notify us immediately. *********************************************************************** _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 2 06:25:12 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29204 for ; Wed, 2 Mar 2005 06:25:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6RwJ-0007Aj-JU; Wed, 02 Mar 2005 06:22:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6RwI-0007Ad-Ds for ipsec@megatron.ietf.org; Wed, 02 Mar 2005 06:22:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA29016 for ; Wed, 2 Mar 2005 06:22:47 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6RxR-00060Q-2f for ipsec@ietf.org; Wed, 02 Mar 2005 06:24:01 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j22BMcAJ004635 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 2 Mar 2005 13:22:38 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j22BMbiC004632; Wed, 2 Mar 2005 13:22:37 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16933.41469.351149.32331@fireball.kivinen.iki.fi> Date: Wed, 2 Mar 2005 13:22:37 +0200 From: Tero Kivinen To: Stephen Kent Subject: [Ipsec] SPD & IKE v2 In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 17 min X-Total-Time: 18 min X-Spam-Score: 0.0 (/) X-Scan-Signature: b5d20af10c334b36874c0264b10f59f1 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Stephen Kent writes: > This brings me to the issue Tero raised in this discussion. Tero, I > think you suggested that there is a fundamental mismatch between what > the SPD allows to be expressed and what IKE v2 can negotiate. > Specifically, I think you indicated that the mismatch arises because > IKE semantics call for a "mix and match" approach to viewing TSi/TSr > payloads. Yes. The IKEv2 does not tie TSi and TSr together in anyway. It says you process TSi and TSr separately, i.e. there is no text there saying they would be tied together in any ways. > I looked at section 2.9 in IKE v2 and I don't see where it > suggests this. Do you see any text there which could indicate that the TS payload items are somehow paired? It does say that both TSi and TSr SHOULD have very specific entries as their first entries. > For example, the text describes how to pass triggering > packet header data as the FIRST selector set data in TSi and TSr > payloads, implying that the order of elements in these payloads is > important, and that one is expected to view them as pairs, matching > the corresponding S/D address and port fields. I cannot see how it implies that there is any order for the rest of the items, when you say that the first item must be from packet if you ant to include it. We needed some way to find the specific from packet TS item, and instead of adding a flag or using separate TS type for that we decided to put it as a first item in the list. We already found out in the interop event that this can cause confusion, as some people didn't understand that the first item can be very specific. And in some cases is it impossible to find out wheather there is one specific entry or not. > So, I have to admit > that I am confused by your comment. If I send a series of pairs of > TSi/TSr payloads, I would interpret this to represent pairs of S/D > data, with a common protocol, so that each matched pair represents > one selector set from an SPD entry, if the entry has more than one > selector set in it. One of the ideas is that the initiator can send TS: TSi = 0.0.0.0-255.255.255.255 TSr = 0.0.0.0-255.255.255.255 and the responder can narrow it down to: TSi = 10.0.11.22-10.0.11.22 TSr = 10.0.0.0-10.255.255.255, 192.168.0.0-192.168.255.255 etc. > Can you cite the parts of IKEv2 that suggest the "mix and match" > approach that you indicated? It does use mix and match in all other cases with similar lists. Can you find out where it says you should pairwise tie TS together? It does not say anywhere that there should be even equal number of items in the TSi and TSr. > Such semantics make no sense in the access control context that the > SPD represents. It does make perfect sense for me. I.e. the TSi lists the IP-address ranges which can be found from the initiators end of the network, and TSr contains the list of address ranges which can be found from the responders end. I.e. if you have VPN setup where the site A has networks 10.0.22.0/24 and 10.0.44.0/24, and the site B has 10.0.55.0/24,10.0.222.0/24,10.0.227.0/24, then the TSi will contain the networks from site A has, and TSr of the request will have 0.0.0.0-255.255.255.255, and the responde will narrow that any ip down so that TSi will still have 10.0.22.0/24 and 10.0.44.0/24 and the TSr will now have the networks site B has. This would not be possible if the TS items would be tied together, as it would cause lots of TS items to be created. We tried to avoid combinatory explosion in the IKEv2. > Also, I'd like to think that IKE should be trying to negotiate what > the SPD specifies, to minimize the likelihood that SAs are > established that later will not carry the intended traffic. I think you earlier said it other way around, i.e. the SPD was specified to be able to negotiate what the IKEv2 can negotiate. I think I did comment this earlier when you were writing the ASN1 version of the SPD, but as I am now behind bad network connections I cannot search the archives. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 2 06:33:35 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00557 for ; Wed, 2 Mar 2005 06:33:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6S4Q-00088F-9N; Wed, 02 Mar 2005 06:31:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6S4O-00088A-SS for ipsec@megatron.ietf.org; Wed, 02 Mar 2005 06:31:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00268 for ; Wed, 2 Mar 2005 06:31:09 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6S5X-0006CZ-Si for ipsec@ietf.org; Wed, 02 Mar 2005 06:32:24 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j22BU8Z6004689 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 2 Mar 2005 13:30:08 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j22BTgfT004661; Wed, 2 Mar 2005 13:29:42 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16933.41894.415648.894932@fireball.kivinen.iki.fi> Date: Wed, 2 Mar 2005 13:29:42 +0200 From: Tero Kivinen To: Paul Hoffman Subject: [Ipsec] Technical change needed to IKEv2 before publication In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 3 min X-Total-Time: 2 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: IPsec WG , Russ Housley , "Theodore Y. Ts'o" , Barbara Fraser X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Paul Hoffman writes: > SUGGESTION C: > Change the places that says Transform Type 5 is optional to say > it is mandatory. I think C is best, as it will also work with versions implemented using old version. I.e. if you always say that DO ESN and/or DONT ESN then there is no question which one is the default. For implementations which do not support ESN they can simply always add DONT ESN in the proposal and return no proposal chosen in case the other end proposes only DO ESN. For implementations doing both (and allowing both) will then send both values. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 2 07:55:06 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA06391 for ; Wed, 2 Mar 2005 07:55:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6TIZ-0000DF-Jg; Wed, 02 Mar 2005 07:49:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6TIX-0000DA-Dk for ipsec@megatron.ietf.org; Wed, 02 Mar 2005 07:49:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05974 for ; Wed, 2 Mar 2005 07:49:51 -0500 (EST) Received: from mail-eur.microsoft.com ([213.199.128.145]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6TJd-0007gw-Q5 for ipsec@ietf.org; Wed, 02 Mar 2005 07:51:05 -0500 Received: from EUR-MSG-20.europe.corp.microsoft.com ([65.53.210.18]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Mar 2005 12:49:38 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Technical change needed to IKEv2 before publication Date: Wed, 2 Mar 2005 12:49:35 -0000 Message-ID: <892867B805D4DA42A1C48103BF4CFA5A0122B91D@EUR-MSG-20.europe.corp.microsoft.com> Thread-Topic: [Ipsec] Technical change needed to IKEv2 before publication thread-index: AcUd9ela7ulDt++/SOOfVlD4F6Z+9gBLgv/w From: "Michael Roe" To: "Paul Hoffman" , "IPsec WG" X-OriginalArrivalTime: 02 Mar 2005 12:49:38.0703 (UTC) FILETIME=[4B9261F0:01C51F26] X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable As far as I can see, the specification as currently written works, but the default value isn't very sensible. As the spec is currently written: An initiator that is willing to negotiate either ESN off or ESN on should explicitly encode both options in a Transform Type 5 (because the default is to demand ESN on, which is not a good idea). An initiator that only supports ESN off should explicitly encode this in a Transform type 5. A responder that selects ESN off should explicitly encode this in a Transform type 5. A responder that selects ESN on may encode this in a Transform type 5, but doesn't need to, because this is the default. This all works, but the default value adds code complexity for little benefit. I'd suggest option C below, or leaving things as they are. Mike > SUGGESTION A: > The last sentence of 3.3.2 says: > If Transform Type 5 is not included in a proposal, use of > Extended Sequence Numbers is assumed. > Replace this with: > If Transform Type 5 is not included in a proposal, it is > assumed that the sending party does not support Extended > Sequence Numbers. >=20 > SUGGESTION B: > Create a new response notification that says "I can't do ESN, start > again and include a 'no ESN' transform." >=20 > SUGGESTION C: > Change the places that says Transform Type 5 is optional to say > it is mandatory. >=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 2 08:10:18 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07858 for ; Wed, 2 Mar 2005 08:10:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6TVp-000289-En; Wed, 02 Mar 2005 08:03:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6TVn-00027e-Rj for ipsec@megatron.ietf.org; Wed, 02 Mar 2005 08:03:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07155 for ; Wed, 2 Mar 2005 08:03:34 -0500 (EST) Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6TWx-0008Bq-8W for ipsec@ietf.org; Wed, 02 Mar 2005 08:04:47 -0500 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id j22D3PjW002325 for ; Wed, 2 Mar 2005 08:03:25 -0500 Received: from M30.equallogic.com (m30 [172.16.1.30]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id j22D3PIT002320; Wed, 2 Mar 2005 08:03:25 -0500 Received: from PKONING.equallogic.com ([172.16.2.2]) by M30.equallogic.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 2 Mar 2005 08:03:25 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16933.47504.763000.221233@gargle.gargle.HOWL> Date: Wed, 2 Mar 2005 08:03:12 -0500 From: Paul Koning To: mroe@microsoft.com Subject: RE: [Ipsec] Technical change needed to IKEv2 before publication References: <892867B805D4DA42A1C48103BF4CFA5A0122B91D@EUR-MSG-20.europe.corp.microsoft.com> X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid X-OriginalArrivalTime: 02 Mar 2005 13:03:25.0407 (UTC) FILETIME=[385366F0:01C51F28] X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, paul.hoffman@vpnc.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit >>>>> "Michael" == Michael Roe writes: Michael> As far as I can see, the specification as currently written Michael> works, but the default value isn't very sensible. I would agree, but it really doesn't matter much what the default values are. They are merely an encoding shorthand, nothing more. They add no new capabilities to the protocol. Michael> As the spec is currently written: Michael> An initiator that is willing to negotiate either ESN off or Michael> ESN on should explicitly encode both options in a Transform Michael> Type 5 (because the default is to demand ESN on, which is Michael> not a good idea). I don't think so -- such an initiator would have to send two proposals, one with ESN on, one with ESN off. The one with ESN on can be encoded either by explicitly saying ESN on, or by omitting ESN from that proposal. Michael> This all works, but the default value adds code complexity Michael> for little benefit. True. Things would be simpler if all the defaults were taken out and everything had to be stated explicitly. paul _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 2 10:21:38 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21335 for ; Wed, 2 Mar 2005 10:21:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Vd8-0007gk-WF; Wed, 02 Mar 2005 10:19:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6Vd6-0007gc-Vd for ipsec@megatron.ietf.org; Wed, 02 Mar 2005 10:19:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21016 for ; Wed, 2 Mar 2005 10:19:14 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6VeG-0002mA-BP for ipsec@ietf.org; Wed, 02 Mar 2005 10:20:30 -0500 Received: from [10.20.30.249] (dsl2-63-249-109-245.cruzio.com [63.249.109.245]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j22FJ36v044350 for ; Wed, 2 Mar 2005 07:19:05 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <16933.47504.763000.221233@gargle.gargle.HOWL> References: <892867B805D4DA42A1C48103BF4CFA5A0122B91D@EUR-MSG-20.europe.corp.microsoft .com> <16933.47504.763000.221233@gargle.gargle.HOWL> Date: Wed, 2 Mar 2005 07:14:19 -0800 To: ipsec@ietf.org From: Paul Hoffman Subject: RE: [Ipsec] Technical change needed to IKEv2 before publication Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 8:03 AM -0500 3/2/05, Paul Koning wrote: > >>>>> "Michael" == Michael Roe writes: > > Michael> As far as I can see, the specification as currently written > Michael> works, but the default value isn't very sensible. > >I would agree, but it really doesn't matter much what the default >values are. They are merely an encoding shorthand, nothing more. >They add no new capabilities to the protocol. Me three (or five, by my count). At this point, I don't think a technical change is needed, just a clarification. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 2 10:25:56 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22218 for ; Wed, 2 Mar 2005 10:25:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6VdJ-0007iZ-Tj; Wed, 02 Mar 2005 10:19:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6VdG-0007iT-QM for ipsec@megatron.ietf.org; Wed, 02 Mar 2005 10:19:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21038 for ; Wed, 2 Mar 2005 10:19:25 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6VeN-0002mQ-PJ for ipsec@ietf.org; Wed, 02 Mar 2005 10:20:40 -0500 Received: from [10.20.30.249] (dsl2-63-249-109-245.cruzio.com [63.249.109.245]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j22FJ36x044350; Wed, 2 Mar 2005 07:19:06 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <16933.41469.351149.32331@fireball.kivinen.iki.fi> References: <16933.41469.351149.32331@fireball.kivinen.iki.fi> Date: Wed, 2 Mar 2005 07:19:01 -0800 To: Tero Kivinen , Stephen Kent From: Paul Hoffman Subject: Re: [Ipsec] SPD & IKE v2 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: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 1:22 PM +0200 3/2/05, Tero Kivinen wrote: >Stephen Kent writes: > > For example, the text describes how to pass triggering >> packet header data as the FIRST selector set data in TSi and TSr >> payloads, implying that the order of elements in these payloads is > > important, and that one is expected to view them as pairs, matching >> the corresponding S/D address and port fields. > >I cannot see how it implies that there is any order for the rest of >the items, when you say that the first item must be from packet if you >ant to include it. We needed some way to find the specific from packet >TS item, and instead of adding a flag or using separate TS type for >that we decided to put it as a first item in the list. We already >found out in the interop event that this can cause confusion, as some >people didn't understand that the first item can be very specific. And >in some cases is it impossible to find out wheather there is one >specific entry or not. Tero is right. In fact, the document quite clearly says that the first transform does *not* need to be for an actual packet, if you want to start a tunnel without traffic. Further, I see nothing that suggests that "one is expected to view them as pairs". --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 2 13:18:20 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10872 for ; Wed, 2 Mar 2005 13:18:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6YN6-0007ij-7k; Wed, 02 Mar 2005 13:14:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6YN4-0007ie-8D for ipsec@megatron.ietf.org; Wed, 02 Mar 2005 13:14:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10681 for ; Wed, 2 Mar 2005 13:14:51 -0500 (EST) Received: from web90007.mail.scd.yahoo.com ([66.218.94.65]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D6YOE-0007BJ-JY for ipsec@ietf.org; Wed, 02 Mar 2005 13:16:09 -0500 Received: (qmail 59656 invoked by uid 60001); 2 Mar 2005 18:14:39 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=swB3FHyYz4Zlz0d5OzdXKG/lht72GYunUff/8fODgfKWv4J7BLgq0Vq8hAVeYkvLrpp3AA62OMw5ZnNP8kNhpIDKunnbsgO5fbo+G+zBng2Br9WGoIDyVrAPXt5gNN7e1Bb+hpC/Tbl2RTavfvHGI5wJVz2um4ZyrSq4HxEEN0Q= ; Message-ID: <20050302181439.59654.qmail@web90007.mail.scd.yahoo.com> Received: from [67.170.235.45] by web90007.mail.scd.yahoo.com via HTTP; Wed, 02 Mar 2005 10:14:39 PST Date: Wed, 2 Mar 2005 10:14:39 -0800 (PST) From: Surya Batchu Subject: Re: [Ipsec] SPD & IKE v2 To: Paul Hoffman , Tero Kivinen , Stephen Kent In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: 4b800b1eab964a31702fa68f1ff0e955 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="===============0225245292==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0225245292== Content-Type: multipart/alternative; boundary="0-693448745-1109787279=:59524" --0-693448745-1109787279=:59524 Content-Type: text/plain; charset=us-ascii IMO, it is good to have an indication in TS payload indicating that this payload has packet header selectors. For example, assume that IPsec 'protect' policy on one side has 11.1.5.0/24-->10.1.6.0/24 and the policy on the peer has 10.1.0.0/16 -> 11.1.5.0/24. Since, one side has smaller range of selectors, the SAs that get established will always be between 11.1.5.0/24 and 10.1.6.0/24. Upon packet reception from say 10.1.7.0/24 network to 11.1.5.0/24 network, the peer starts childSA transaction as there is no matching outbound SA. In this case, the initiator sends both packet header TS payloads and security policy selectors. If the responder considers packet selectors and other selectors in the same fashion, then , it again creates SA with the same selectors as previous SA ie 11.1.5.0/24 and 10.1.6.0/24. This might happen over and over again and it might flood the SA session table. Implementations can be smart to avoid SA flood or implementation can be smart to know that there is a TS payload pair with packet selectors. But, having protocol support to identify packet selectors from other selectors really helps in simplification of implementations. If responder knows that, this SA is being negotiated for a given packet selector without any ambiguity, then the responder can choose to return error notification to the Initiator, for above transaction. Surya Paul Hoffman wrote: At 1:22 PM +0200 3/2/05, Tero Kivinen wrote: >Stephen Kent writes: > > For example, the text describes how to pass triggering >> packet header data as the FIRST selector set data in TSi and TSr >> payloads, implying that the order of elements in these payloads is > > important, and that one is expected to view them as pairs, matching >> the corresponding S/D address and port fields. > >I cannot see how it implies that there is any order for the rest of >the items, when you say that the first item must be from packet if you >ant to include it. We needed some way to find the specific from packet >TS item, and instead of adding a flag or using separate TS type for >that we decided to put it as a first item in the list. We already >found out in the interop event that this can cause confusion, as some >people didn't understand that the first item can be very specific. And >in some cases is it impossible to find out wheather there is one >specific entry or not. Tero is right. In fact, the document quite clearly says that the first transform does *not* need to be for an actual packet, if you want to start a tunnel without traffic. Further, I see nothing that suggests that "one is expected to view them as pairs". --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --------------------------------- Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web --0-693448745-1109787279=:59524 Content-Type: text/html; charset=us-ascii
IMO, it is good to have an indication in TS payload indicating that this payload has packet header selectors.
 
For example, assume that IPsec 'protect' policy on one side has 11.1.5.0/24-->10.1.6.0/24 and
the policy on the peer has 10.1.0.0/16 -> 11.1.5.0/24. Since, one side has smaller range of selectors, the SAs that get established will always be between 11.1.5.0/24 and 10.1.6.0/24.
Upon packet reception from say 10.1.7.0/24 network to 11.1.5.0/24 network, the peer starts childSA transaction as there is no matching outbound SA. In this case, the initiator sends both packet header TS payloads and security policy selectors. If the responder considers packet selectors and other selectors in the same fashion, then , it again creates SA with the same selectors as previous SA ie 11.1.5.0/24 and 10.1.6.0/24.  This might happen over and over again and it might flood the SA session table.
 
Implementations can be smart to avoid SA flood or implementation can be smart to know that there is a TS payload pair with packet selectors. But, having protocol support to identify  packet selectors from other selectors  really helps in simplification of implementations. If responder knows that, this SA is being negotiated for a given packet selector without any ambiguity, then the responder can choose to return error notification to the Initiator, for above transaction.
 
Surya


Paul Hoffman <paul.hoffman@vpnc.org> wrote:
At 1:22 PM +0200 3/2/05, Tero Kivinen wrote:
>Stephen Kent writes:
> > For example, the text describes how to pass triggering
>> packet header data as the FIRST selector set data in TSi and TSr
>> payloads, implying that the order of elements in these payloads is
> > important, and that one is expected to view them as pairs, matching
>> the corresponding S/D address and port fields.
>
>I cannot see how it implies that there is any order for the rest of
>the items, when you say that the first item must be from packet if you
>ant to include it. We needed some way to find the specific from packet
>TS item, and instead of adding a flag or using separate TS type for
>that we decided to put it as a first item in the list. We already
>found out in the interop event that this can cause confus! ion, as some
>people didn't understand that the first item can be very specific. And
>in some cases is it impossible to find out wheather there is one
>specific entry or not.

Tero is right. In fact, the document quite clearly says that the
first transform does *not* need to be for an actual packet, if you
want to start a tunnel without traffic. Further, I see nothing that
suggests that "one is expected to view them as pairs".

--Paul Hoffman, Director
--VPN Consortium

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec


Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web --0-693448745-1109787279=:59524-- --===============0225245292== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0225245292==-- From ipsec-bounces@ietf.org Wed Mar 2 14:45:28 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18257 for ; Wed, 2 Mar 2005 14:45:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6ZjN-000413-PN; Wed, 02 Mar 2005 14:42:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6ZjM-00040y-5z for ipsec@megatron.ietf.org; Wed, 02 Mar 2005 14:42:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA17999 for ; Wed, 2 Mar 2005 14:41:58 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6ZkV-0000eu-Ix for ipsec@ietf.org; Wed, 02 Mar 2005 14:43:12 -0500 Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j22JfrFX066989 for ; Wed, 2 Mar 2005 11:41:54 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050302181439.59654.qmail@web90007.mail.scd.yahoo.com> References: <20050302181439.59654.qmail@web90007.mail.scd.yahoo.com> Date: Wed, 2 Mar 2005 11:41:50 -0800 To: ipsec@ietf.org From: Paul Hoffman Subject: Re: [Ipsec] SPD & IKE v2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 10:14 AM -0800 3/2/05, Surya Batchu wrote: >IMO, it is good to have an indication in TS payload indicating that >this payload has packet header selectors. I think it is *way* too late for that for the current spec. There is no space currently in the headers for that. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 2 15:15:23 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21083 for ; Wed, 2 Mar 2005 15:15:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6aE3-0000A6-Hi; Wed, 02 Mar 2005 15:13:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6aE1-00009Q-LB for ipsec@megatron.ietf.org; Wed, 02 Mar 2005 15:13:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20834 for ; Wed, 2 Mar 2005 15:13:39 -0500 (EST) Received: from web90004.mail.scd.yahoo.com ([66.218.94.62]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D6aFD-0001HF-Lz for ipsec@ietf.org; Wed, 02 Mar 2005 15:14:57 -0500 Received: (qmail 99182 invoked by uid 60001); 2 Mar 2005 20:13:29 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=e5TKd3QA2viPzfb60IjrRa0ZKG7WioNYSNgqfZ3QasrZk9WLFMlZYvfxIdduxSP5LY7Obf5wVwSwu8suSvEvMzLQviyw8rBBHbZnnlvdt6ZaDbN2/isakh9tUkG4bMJCbZQiNc/xbrfb6MIsORMAyhKgNkGc6HCVcy7afgpt+Vg= ; Message-ID: <20050302201329.99180.qmail@web90004.mail.scd.yahoo.com> Received: from [67.170.235.45] by web90004.mail.scd.yahoo.com via HTTP; Wed, 02 Mar 2005 12:13:29 PST Date: Wed, 2 Mar 2005 12:13:29 -0800 (PST) From: Surya Batchu Subject: Re: [Ipsec] SPD & IKE v2 To: Paul Hoffman , ipsec@ietf.org In-Reply-To: MIME-Version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca 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="===============0870822766==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0870822766== Content-Type: multipart/alternative; boundary="0-1666188029-1109794409=:99112" --0-1666188029-1109794409=:99112 Content-Type: text/plain; charset=us-ascii I understand that it is too late for a change in the headers. What is the best practice to tackle the kind of problems, which I described in my earlier email , with existing TS payload information? In the first place, is that a valid problem? Surya Paul Hoffman wrote: At 10:14 AM -0800 3/2/05, Surya Batchu wrote: >IMO, it is good to have an indication in TS payload indicating that >this payload has packet header selectors. I think it is *way* too late for that for the current spec. There is no space currently in the headers for that. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --------------------------------- Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web --0-1666188029-1109794409=:99112 Content-Type: text/html; charset=us-ascii
I understand that it is too late for a change in the headers. 
 
What is the best practice to tackle the kind of problems, which I described in my earlier email , with existing TS payload information? In the first place, is that a valid problem?
 
Surya


Paul Hoffman <paul.hoffman@vpnc.org> wrote:

At 10:14 AM -0800 3/2/05, Surya Batchu wrote:
>IMO, it is good to have an indication in TS payload indicating that
>this payload has packet header selectors.

I think it is *way* too late for that for the current spec. There is
no space currently in the headers for that.

 



--Paul Hoffman, Director
--VPN Consortium

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec

Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web --0-1666188029-1109794409=:99112-- --===============0870822766== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0870822766==-- From ipsec-bounces@ietf.org Wed Mar 2 15:36:08 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23803 for ; Wed, 2 Mar 2005 15:36:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6aZ3-0005pm-Bt; Wed, 02 Mar 2005 15:35:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6aZ0-0005pC-Qn for ipsec@megatron.ietf.org; Wed, 02 Mar 2005 15:35:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23704 for ; Wed, 2 Mar 2005 15:35:20 -0500 (EST) Received: from web90001.mail.scd.yahoo.com ([66.218.94.59]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D6aaE-0001zQ-Cd for ipsec@ietf.org; Wed, 02 Mar 2005 15:36:39 -0500 Received: (qmail 75890 invoked by uid 60001); 2 Mar 2005 20:35:12 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=VU7Ux4/GzAeHKWHD6u4z56JJTsuOOmpC45DC7NwSrzUWUwezhu3KIR1LGlJromRgRQeVuSJ+DaYnpFF1Shs2Kf9YxCWGKPfid9dnVoTRP4LdtYd43AXrx/9j1AHxM3gMh50f2Rp6w0AoivahdTppN8PrSjeli3/uD6aM9QiJVi4= ; Message-ID: <20050302203511.75886.qmail@web90001.mail.scd.yahoo.com> Received: from [67.170.235.45] by web90001.mail.scd.yahoo.com via HTTP; Wed, 02 Mar 2005 12:35:10 PST Date: Wed, 2 Mar 2005 12:35:10 -0800 (PST) From: Surya Batchu Subject: Re: [Ipsec] SPD & IKE v2 To: Tero Kivinen , Stephen Kent In-Reply-To: <16933.41469.351149.32331@fireball.kivinen.iki.fi> MIME-Version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: 156eddb66af16eef49a76ae923b15b92 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="===============0643909516==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0643909516== Content-Type: multipart/alternative; boundary="0-1907858985-1109795710=:75614" --0-1907858985-1109795710=:75614 Content-Type: text/plain; charset=us-ascii I went through the Appendix C of http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2401bis-05.txt. I think that SPD syntax mentioned in here can be negotiated through IKEv2 selector payloads. I am pasting here relevant portions of ASN1 syntax here: SelectorLists ::= SET OF SelectorList SelectorList ::= SEQUENCE { localAddr AddrList, remoteAddr AddrList, protocol ProtocolChoice } -- List of IP addresses AddrList ::= SEQUENCE { v4List IPv4List OPTIONAL, v6List [0] IPv6List OPTIONAL } -- IPv4 address representations IPv4List ::= SEQUENCE OF IPv4Range IPv4Range ::= SEQUENCE { -- close, but not quite right ... ipv4Start OCTET STRING (SIZE (4)), ipv4End OCTET STRING (SIZE (4)) } -- IPv6 address representations IPv6List ::= SEQUENCE OF IPv6Range IPv6Range ::= SEQUENCE { -- close, but not quite right ... ipv6Start OCTET STRING (SIZE (16)), ipv6End OCTET STRING (SIZE (16)) } Based on above, 'localAddr' and 'remoteAddr' are two differnet fields in SelectorList. Each one of them can have multiple IP address ranges. To me, it seems both rfc2401bis and IKEv2 TS are conforming to each other. Am I missing some thing? Surya Tero Kivinen wrote: Stephen Kent writes: > This brings me to the issue Tero raised in this discussion. Tero, I > think you suggested that there is a fundamental mismatch between what > the SPD allows to be expressed and what IKE v2 can negotiate. > Specifically, I think you indicated that the mismatch arises because > IKE semantics call for a "mix and match" approach to viewing TSi/TSr > payloads. Yes. The IKEv2 does not tie TSi and TSr together in anyway. It says you process TSi and TSr separately, i.e. there is no text there saying they would be tied together in any ways. > I looked at section 2.9 in IKE v2 and I don't see where it > suggests this. Do you see any text there which could indicate that the TS payload items are somehow paired? It does say that both TSi and TSr SHOULD have very specific entries as their first entries. > For example, the text describes how to pass triggering > packet header data as the FIRST selector set data in TSi and TSr > payloads, implying that the order of elements in these payloads is > important, and that one is expected to view them as pairs, matching > the corresponding S/D address and port fields. I cannot see how it implies that there is any order for the rest of the items, when you say that the first item must be from packet if you ant to include it. We needed some way to find the specific from packet TS item, and instead of adding a flag or using separate TS type for that we decided to put it as a first item in the list. We already found out in the interop event that this can cause confusion, as some people didn't understand that the first item can be very specific. And in some cases is it impossible to find out wheather there is one specific entry or not. > So, I have to admit > that I am confused by your comment. If I send a series of pairs of > TSi/TSr payloads, I would interpret this to represent pairs of S/D > data, with a common protocol, so that each matched pair represents > one selector set from an SPD entry, if the entry has more than one > selector set in it. One of the ideas is that the initiator can send TS: TSi = 0.0.0.0-255.255.255.255 TSr = 0.0.0.0-255.255.255.255 and the responder can narrow it down to: TSi = 10.0.11.22-10.0.11.22 TSr = 10.0.0.0-10.255.255.255, 192.168.0.0-192.168.255.255 etc. > Can you cite the parts of IKEv2 that suggest the "mix and match" > approach that you indicated? It does use mix and match in all other cases with similar lists. Can you find out where it says you should pairwise tie TS together? It does not say anywhere that there should be even equal number of items in the TSi and TSr. > Such semantics make no sense in the access control context that the > SPD represents. It does make perfect sense for me. I.e. the TSi lists the IP-address ranges which can be found from the initiators end of the network, and TSr contains the list of address ranges which can be found from the responders end. I.e. if you have VPN setup where the site A has networks 10.0.22.0/24 and 10.0.44.0/24, and the site B has 10.0.55.0/24,10.0.222.0/24,10.0.227.0/24, then the TSi will contain the networks from site A has, and TSr of the request will have 0.0.0.0-255.255.255.255, and the responde will narrow that any ip down so that TSi will still have 10.0.22.0/24 and 10.0.44.0/24 and the TSr will now have the networks site B has. This would not be possible if the TS items would be tied together, as it would cause lots of TS items to be created. We tried to avoid combinatory explosion in the IKEv2. > Also, I'd like to think that IKE should be trying to negotiate what > the SPD specifies, to minimize the likelihood that SAs are > established that later will not carry the intended traffic. I think you earlier said it other way around, i.e. the SPD was specified to be able to negotiate what the IKEv2 can negotiate. I think I did comment this earlier when you were writing the ASN1 version of the SPD, but as I am now behind bad network connections I cannot search the archives. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --------------------------------- Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web --0-1907858985-1109795710=:75614 Content-Type: text/html; charset=us-ascii
 
I went through the Appendix C of  http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2401bis-05.txt. I think that SPD syntax mentioned in here can be negotiated through IKEv2 selector payloads. I am pasting here relevant portions of ASN1 syntax here:

 SelectorLists ::= SET OF SelectorList

      SelectorList ::= SEQUENCE {
          localAddr   AddrList,
          remoteAddr  AddrList,
          protocol    ProtocolChoice }
 
  -- List of IP addresses
      AddrList ::= SEQUENCE {
          v4List      IPv4List OPTIONAL,
          v6List      [0] IPv6List OPTIONAL }

      -- IPv4 address representations
      IPv4List ::= SEQUENCE OF IPv4Range

      IPv4Range ::= SEQUENCE {    -- close, but not quite right ...
          ipv4Start   OCTET STRING (SIZE (4)),
          ipv4End     OCTET STRING (SIZE (4)) }

      -- IPv6 address representations
      IPv6List ::= SEQUENCE OF IPv6Range

      IPv6Range ! ::= SEQUENCE {    -- close, but not quite right ...
          ipv6Start   OCTET STRING (SIZE (16)),
          ipv6End     OCTET STRING (SIZE (16)) }
 
Based on above, 'localAddr' and 'remoteAddr' are two differnet fields in SelectorList.
Each one of them can have multiple IP address ranges.
 
To me, it seems both rfc2401bis and IKEv2 TS are conforming to each other.
Am I missing some thing?
 
Surya

Tero Kivinen <kivinen@iki.fi> wrote:
Stephen Kent writes:
> This brings me to the issue Tero raised in this discussion. Tero, I
> think you suggested that there is a fundamental mismatch between what
> the SPD allows to be expressed and what IKE v2 can negotiate.
> Specifically, I think you indicated that the mismatch arises because
> IKE semantics call for a "mix and match" approach to viewing TSi/TSr
> payloads.

Yes. The IKEv2 does not tie TSi and TSr together in anyway. It says
you process TSi and TSr separately, i.e. there is no text there saying
they would be tied together in any ways.

> I looked at section 2.9 in IKE v2 and I don't see where it
> suggests this.

Do you see any text there which could indicate that the TS payload
items are somehow paired? It does say that both TSi and TSr SHOULD
have very specific entries as t! heir first entries.

> For example, the text describes how to pass triggering
> packet header data as the FIRST selector set data in TSi and TSr
> payloads, implying that the order of elements in these payloads is
> important, and that one is expected to view them as pairs, matching
> the corresponding S/D address and port fields.

I cannot see how it implies that there is any order for the rest of
the items, when you say that the first item must be from packet if you
ant to include it. We needed some way to find the specific from packet
TS item, and instead of adding a flag or using separate TS type for
that we decided to put it as a first item in the list. We already
found out in the interop event that this can cause confusion, as some
people didn't understand that the first item can be very specific. And
in some cases is it impossible to find out wheather there is one
specific entry or not.

> So, I ! have to admit
> that I am confused by your comment. If I send a series of pairs of
> TSi/TSr payloads, I would interpret this to represent pairs of S/D
> data, with a common protocol, so that each matched pair represents
> one selector set from an SPD entry, if the entry has more than one
> selector set in it.

One of the ideas is that the initiator can send TS:

TSi = 0.0.0.0-255.255.255.255
TSr = 0.0.0.0-255.255.255.255

and the responder can narrow it down to:

TSi = 10.0.11.22-10.0.11.22
TSr = 10.0.0.0-10.255.255.255, 192.168.0.0-192.168.255.255

etc.

> Can you cite the parts of IKEv2 that suggest the "mix and match"
> approach that you indicated?

It does use mix and match in all other cases with similar lists. Can
you find out where it says you should pairwise tie TS together? It
does not say anywhere that there should be even equal number of items
in the TSi and TSr.
> Such semantics make no sense in the access control context that the
> SPD represents.

It does make perfect sense for me. I.e. the TSi lists the IP-address
ranges which can be found from the initiators end of the network, and
TSr contains the list of address ranges which can be found from the
responders end.

I.e. if you have VPN setup where the site A has networks 10.0.22.0/24
and 10.0.44.0/24, and the site B has
10.0.55.0/24,10.0.222.0/24,10.0.227.0/24, then the TSi will contain
the networks from site A has, and TSr of the request will have
0.0.0.0-255.255.255.255, and the responde will narrow that any ip down
so that TSi will still have 10.0.22.0/24 and 10.0.44.0/24 and the TSr
will now have the networks site B has.

This would not be possible if the TS items would be tied together, as
it would cause lots of TS items to be created. We tried to avoid
combinatory explosion in the IKEv2.

> Also, I'd like to ! think that IKE should be trying to negotiate what
> the SPD specifies, to minimize the likelihood that SAs are
> established that later will not carry the intended traffic.

I think you earlier said it other way around, i.e. the SPD was
specified to be able to negotiate what the IKEv2 can negotiate. I
think I did comment this earlier when you were writing the ASN1
version of the SPD, but as I am now behind bad network connections I
cannot search the archives.
--
kivinen@safenet-inc.com

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec

Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web --0-1907858985-1109795710=:75614-- --===============0643909516== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0643909516==-- From ipsec-bounces@ietf.org Wed Mar 2 16:00:39 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26092 for ; Wed, 2 Mar 2005 16:00:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6aqs-0000Ep-HP; Wed, 02 Mar 2005 15:53:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6aqr-0000Ek-7a for ipsec@megatron.ietf.org; Wed, 02 Mar 2005 15:53:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA25271 for ; Wed, 2 Mar 2005 15:53:43 -0500 (EST) Received: from web52501.mail.yahoo.com ([206.190.39.122]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D6as0-0002N2-Sw for ipsec@ietf.org; Wed, 02 Mar 2005 15:55:02 -0500 Received: (qmail 99790 invoked by uid 60001); 2 Mar 2005 20:53:26 -0000 Message-ID: <20050302205324.99785.qmail@web52501.mail.yahoo.com> Received: from [69.233.57.195] by web52501.mail.yahoo.com via HTTP; Wed, 02 Mar 2005 12:53:24 PST Date: Wed, 2 Mar 2005 12:53:24 -0800 (PST) From: Saroop Mathur Subject: Re: [Ipsec] SPD & IKE v2 To: Paul Hoffman , ipsec@ietf.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > At 10:14 AM -0800 3/2/05, Surya Batchu wrote: > >IMO, it is good to have an indication in TS payload indicating that > >this payload has packet header selectors. I believe such an indication will be really useful. It can be generalized to indicate "the responder must include this TS in the subset selected by the responder". This also allows an initiator to have some say in what the negotiated TS will be. e.g. if a initiator supports only a single SA for the entire subnet and does not want the responder to narrow the TS, it currently cannot indicate this. Most SOHO VPN boxes only support a few SAs and will be at the mercy of the responder to not narrow down the policy. > I think it is *way* too late for that for the current spec. There is > no space currently in the headers for that. I agree it is way too late for such a change, however, if a change is desired, space can be created in the TS header. Currently, the "Selector Length" field is 16 bits. It could be reduced to 8 bits and 1 bit out of the remaining 8 bits be used for this indication. This leaves 7 bits for future expansion. -Saroop _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 2 16:13:59 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27468 for ; Wed, 2 Mar 2005 16:13:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6b9V-0004e0-AB; Wed, 02 Mar 2005 16:13:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6b9T-0004dq-Bq for ipsec@megatron.ietf.org; Wed, 02 Mar 2005 16:13:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA27372 for ; Wed, 2 Mar 2005 16:13:00 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6bAg-00035I-Dw for ipsec@ietf.org; Wed, 02 Mar 2005 16:14:19 -0500 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j22LD0NV027995; Wed, 2 Mar 2005 13:13:00 -0800 (PST) Received: from thunk (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j22LCxOp026080; Wed, 2 Mar 2005 16:12:59 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j22LCxvA010717; Wed, 2 Mar 2005 16:12:59 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j22LCx8f010716; Wed, 2 Mar 2005 16:12:59 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: [Ipsec] SPD & IKE v2 From: Bill Sommerfeld To: Saroop Mathur In-Reply-To: <20050302205324.99785.qmail@web52501.mail.yahoo.com> References: <20050302205324.99785.qmail@web52501.mail.yahoo.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1109797975.8377.130.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Wed, 02 Mar 2005 16:12:58 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Paul Hoffman X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit On Wed, 2005-03-02 at 15:53, Saroop Mathur wrote: > > At 10:14 AM -0800 3/2/05, Surya Batchu wrote: > > >IMO, it is good to have an indication in TS payload indicating that > > >this payload has packet header selectors. > > I believe such an indication will be really useful. It can be > generalized to indicate "the responder must include this TS in the > subset selected by the responder". This also allows an initiator to > have some say in what the negotiated TS will be. e.g. if a initiator > supports only a single SA for the entire subnet and does not want the > responder to narrow the TS, it currently cannot indicate this. section 2.9 already says: To enable the responder to choose the appropriate range in this case, if the initiator has requested the SA due to a data packet, the initiator SHOULD include as the first traffic selector in each of TSi and TSr a very specific traffic selector including the addresses in the packet triggering the request. I think the feature you're looking for is already (mostly) there; clarifications may be in order but I don't think we need to change the encoding. > Most SOHO VPN boxes only support a few SAs and will be at the mercy of the > responder to not narrow down the policy. In my experence, the folks operating the security gateway generally specify requirements on the SOHO VPN boxes they allow to connect. Either the SG operators will avoid policies which force narrowing in this case, or they will pick SOHO VPN boxes without this limit. While I am well aware that many embedded systems operate in the face of severe memory limits, I also keep seeing hobbyist reports of things like: http://www.batbox.org/wrt54g-linux.html which suggest that hard limits which would constrain a SOHO device to only support a handful of SA's are largely a thing of the past. - Bill _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 2 16:21:56 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28347 for ; Wed, 2 Mar 2005 16:21:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6bGH-0006Jn-1I; Wed, 02 Mar 2005 16:20:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6bGF-0006JH-0Y for ipsec@megatron.ietf.org; Wed, 02 Mar 2005 16:20:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28140 for ; Wed, 2 Mar 2005 16:20:00 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6bHT-0003IW-A2 for ipsec@ietf.org; Wed, 02 Mar 2005 16:21:19 -0500 Received: from [67.102.148.148] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j22LJekP007466; Wed, 2 Mar 2005 16:19:51 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: <16933.41469.351149.32331@fireball.kivinen.iki.fi> Date: Wed, 2 Mar 2005 16:13:36 -0500 To: Paul Hoffman From: Stephen Kent Subject: Re: [Ipsec] SPD & IKE v2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 7:19 AM -0800 3/2/05, Paul Hoffman wrote: >At 1:22 PM +0200 3/2/05, Tero Kivinen wrote: >>Stephen Kent writes: >> > For example, the text describes how to pass triggering >>> packet header data as the FIRST selector set data in TSi and TSr >>> payloads, implying that the order of elements in these payloads is >> > important, and that one is expected to view them as pairs, matching >>> the corresponding S/D address and port fields. >> >>I cannot see how it implies that there is any order for the rest of >>the items, when you say that the first item must be from packet if you >>ant to include it. We needed some way to find the specific from packet >>TS item, and instead of adding a flag or using separate TS type for >>that we decided to put it as a first item in the list. We already >>found out in the interop event that this can cause confusion, as some >>people didn't understand that the first item can be very specific. And >>in some cases is it impossible to find out wheather there is one >>specific entry or not. > >Tero is right. In fact, the document quite clearly says that the >first transform does *not* need to be for an actual packet, if you >want to start a tunnel without traffic. Further, I see nothing that >suggests that "one is expected to view them as pairs". Paul, I did not say that the first pair of selectors were always from the triggering packet. what I said was that when the header data from a triggering packet is sent, it is sent as the first pair of entries in the TSi/r payloads. What that says to me is that IKE is conveying the initiator and responder address and port data from a single packet as a linked pair of TSi/r values. The semantics in this case seem clear, i.e., there is an specific relationship between the TSi/r values, based on the source of these values. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 2 16:29:38 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29088 for ; Wed, 2 Mar 2005 16:29:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6bLd-0007oM-AN; Wed, 02 Mar 2005 16:25:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6bLT-0007YR-7l for ipsec@megatron.ietf.org; Wed, 02 Mar 2005 16:25:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA28710 for ; Wed, 2 Mar 2005 16:25:24 -0500 (EST) Received: from web52502.mail.yahoo.com ([206.190.39.123]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D6bMh-0003TC-LR for ipsec@ietf.org; Wed, 02 Mar 2005 16:26:43 -0500 Received: (qmail 77834 invoked by uid 60001); 2 Mar 2005 21:25:17 -0000 Message-ID: <20050302212517.77832.qmail@web52502.mail.yahoo.com> Received: from [69.233.57.195] by web52502.mail.yahoo.com via HTTP; Wed, 02 Mar 2005 13:25:17 PST Date: Wed, 2 Mar 2005 13:25:17 -0800 (PST) From: Saroop Mathur Subject: Re: [Ipsec] SPD & IKE v2 To: Bill Sommerfeld In-Reply-To: <1109797975.8377.130.camel@thunk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Cc: ipsec@ietf.org, Paul Hoffman X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --- Bill Sommerfeld wrote: > > I think the feature you're looking for is already (mostly) there; There is no way currently for the initiator to tell the responder not to narrow a range. The packet header selectors are only specify that the narrowed range must include the packet selectors. > In my experence, the folks operating the security gateway generally > specify requirements on the SOHO VPN boxes they allow to connect. > > Either the SG operators will avoid policies which force narrowing in > this case, or they will pick SOHO VPN boxes without this limit. Of course all TS negotiation problems can be avoided by matched polices at both ends. But IKEv2 is designed for handling mismatched policies. -Saroop > On Wed, 2005-03-02 at 15:53, Saroop Mathur wrote: > > > At 10:14 AM -0800 3/2/05, Surya Batchu wrote: > > > >IMO, it is good to have an indication in TS payload indicating > that > > > >this payload has packet header selectors. > > > > I believe such an indication will be really useful. It can be > > generalized to indicate "the responder must include this TS in the > > subset selected by the responder". This also allows an initiator to > > have some say in what the negotiated TS will be. e.g. if a > initiator > > supports only a single SA for the entire subnet and does not want > the > > responder to narrow the TS, it currently cannot indicate this. > > section 2.9 already says: > > To enable the responder to choose the appropriate range in this > case, > if the initiator has requested the SA due to a data packet, the > initiator SHOULD include as the first traffic selector in each of > TSi > and TSr a very specific traffic selector including the addresses > in > the packet triggering the request. > > I think the feature you're looking for is already (mostly) there; > clarifications may be in order but I don't think we need to change > the > encoding. > > > Most SOHO VPN boxes only support a few SAs and will be at the mercy > of the > > responder to not narrow down the policy. > > In my experence, the folks operating the security gateway generally > specify requirements on the SOHO VPN boxes they allow to connect. > > Either the SG operators will avoid policies which force narrowing in > this > case, or they will pick SOHO VPN boxes without this limit. > > While I am well aware that many embedded systems operate in the face > of severe memory limits, I also keep seeing hobbyist reports of > things like: > http://www.batbox.org/wrt54g-linux.html > which suggest that hard limits which would constrain a SOHO device > to only support a handful of SA's are largely a thing of the past. > > - Bill > > > > > > > > > > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 2 16:43:03 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00550 for ; Wed, 2 Mar 2005 16:43:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6baG-0002Jb-Bt; Wed, 02 Mar 2005 16:40:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6baD-0002JW-S7 for ipsec@megatron.ietf.org; Wed, 02 Mar 2005 16:40:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00208 for ; Wed, 2 Mar 2005 16:40:39 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6bbQ-0003qn-6d for ipsec@ietf.org; Wed, 02 Mar 2005 16:41:58 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j22Lebhl018188; Wed, 2 Mar 2005 14:40:38 -0700 (MST) Received: from thunk (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j22LebQp012104; Wed, 2 Mar 2005 16:40:37 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j22Leb5U010831; Wed, 2 Mar 2005 16:40:37 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j22LebN6010830; Wed, 2 Mar 2005 16:40:37 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: [Ipsec] SPD & IKE v2 From: Bill Sommerfeld To: Saroop Mathur In-Reply-To: <20050302212517.77832.qmail@web52502.mail.yahoo.com> References: <20050302212517.77832.qmail@web52502.mail.yahoo.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1109799636.8377.142.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Wed, 02 Mar 2005 16:40:37 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Paul Hoffman X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit On Wed, 2005-03-02 at 16:25, Saroop Mathur wrote: > There is no way currently for the initiator to tell the responder not > to narrow a range. The packet header selectors are only specify that > the narrowed range must include the packet selectors. ... > Of course all TS negotiation problems can be avoided by matched polices > at both ends. But IKEv2 is designed for handling mismatched policies. yes. and it does that through narrowing. TANSTAAFL. If you disable narrowing, you lose the ability to find the policy intersection; if your client box can't cope with multiple SA's and wants to stop narrowing you'll need to change the SG's policy anyway to get bits to move. - Bill _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 2 16:48:00 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01200 for ; Wed, 2 Mar 2005 16:48:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6bdW-0002iG-DW; Wed, 02 Mar 2005 16:44:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6bdS-0002i3-Md for ipsec@megatron.ietf.org; Wed, 02 Mar 2005 16:44:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00645 for ; Wed, 2 Mar 2005 16:44:00 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6bee-0003yM-6U for ipsec@ietf.org; Wed, 02 Mar 2005 16:45:19 -0500 Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j22LhuXP079223 for ; Wed, 2 Mar 2005 13:43:57 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1109797975.8377.130.camel@thunk> References: <20050302205324.99785.qmail@web52501.mail.yahoo.com> <1109797975.8377.130.camel@thunk> Date: Wed, 2 Mar 2005 13:43:51 -0800 To: ipsec@ietf.org From: Paul Hoffman Subject: Re: [Ipsec] SPD & IKE v2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 4:12 PM -0500 3/2/05, Bill Sommerfeld wrote: >On Wed, 2005-03-02 at 15:53, Saroop Mathur wrote: >> > At 10:14 AM -0800 3/2/05, Surya Batchu wrote: >> > >IMO, it is good to have an indication in TS payload indicating that >> > >this payload has packet header selectors. >> >> I believe such an indication will be really useful. It can be >> generalized to indicate "the responder must include this TS in the >> subset selected by the responder". This also allows an initiator to >> have some say in what the negotiated TS will be. e.g. if a initiator >> supports only a single SA for the entire subnet and does not want the >> responder to narrow the TS, it currently cannot indicate this. > >section 2.9 already says: > > To enable the responder to choose the appropriate range in this case, > if the initiator has requested the SA due to a data packet, the > initiator SHOULD include as the first traffic selector in each of TSi > and TSr a very specific traffic selector including the addresses in > the packet triggering the request. > >I think the feature you're looking for is already (mostly) there; >clarifications may be in order but I don't think we need to change the >encoding. Disagree. There is no way to know whether the first proposal is for a first packet or for a future-desired flow. Further, the way the document is worded, you are supposed to make the first selector for the first packet *even if you don't want to actually have that flow*. For example, you might send an ICMP ping just to get the tunnel up, even if you don't intend to have ICMP in the enventual tunnel. In fact, that is quite common. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 2 17:08:04 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03441 for ; Wed, 2 Mar 2005 17:08:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6bzM-0007Vc-Nb; Wed, 02 Mar 2005 17:06:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6bzL-0007VN-0B for ipsec@megatron.ietf.org; Wed, 02 Mar 2005 17:06:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03244 for ; Wed, 2 Mar 2005 17:06:36 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6c0Y-0004aA-O8 for ipsec@ietf.org; Wed, 02 Mar 2005 17:07:56 -0500 Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j22M6ZCp081605; Wed, 2 Mar 2005 14:06:36 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1109800976.8377.147.camel@thunk> References: <20050302205324.99785.qmail@web52501.mail.yahoo.com> <1109797975.8377.130.camel@thunk> <1109800976.8377.147.camel@thunk> Date: Wed, 2 Mar 2005 14:06:34 -0800 To: Bill Sommerfeld From: Paul Hoffman Subject: Re: [Ipsec] SPD & IKE v2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 5:02 PM -0500 3/2/05, Bill Sommerfeld wrote: >On Wed, 2005-03-02 at 16:43, Paul Hoffman wrote: > >> Further, the way the >> document is worded, you are supposed to make the first selector for >> the first packet *even if you don't want to actually have that flow*. > >why would you ask for an SA you didn't intend to use? Because the IKEv2 document says you SHOULD. > > For example, you might send an ICMP ping just to get the tunnel up, >> even if you don't intend to have ICMP in the enventual tunnel. > >if the peer doesn't want to let ICMP in, it should reject all proposals. That leads to lack of interop, yes? >if, instead, the peer narrows to exclude non-ICMP, the initiator should >just ask for another child SA with the real selectors when real traffic >comes along. Right. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 2 17:08:28 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03490 for ; Wed, 2 Mar 2005 17:08:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6bvp-0006tz-1b; Wed, 02 Mar 2005 17:03:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6bvn-0006sz-1a for ipsec@megatron.ietf.org; Wed, 02 Mar 2005 17:02:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03036 for ; Wed, 2 Mar 2005 17:02:56 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6bx1-0004Vx-NT for ipsec@ietf.org; Wed, 02 Mar 2005 17:04:16 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j22M2vhl005876; Wed, 2 Mar 2005 15:02:57 -0700 (MST) Received: from thunk (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j22M2vQp017449; Wed, 2 Mar 2005 17:02:57 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j22M2vgZ010943; Wed, 2 Mar 2005 17:02:57 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j22M2vAV010942; Wed, 2 Mar 2005 17:02:57 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: [Ipsec] SPD & IKE v2 From: Bill Sommerfeld To: Paul Hoffman In-Reply-To: References: <20050302205324.99785.qmail@web52501.mail.yahoo.com> <1109797975.8377.130.camel@thunk> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1109800976.8377.147.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Wed, 02 Mar 2005 17:02:57 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit On Wed, 2005-03-02 at 16:43, Paul Hoffman wrote: > Further, the way the > document is worded, you are supposed to make the first selector for > the first packet *even if you don't want to actually have that flow*. why would you ask for an SA you didn't intend to use? > For example, you might send an ICMP ping just to get the tunnel up, > even if you don't intend to have ICMP in the enventual tunnel. if the peer doesn't want to let ICMP in, it should reject all proposals. if, instead, the peer narrows to exclude non-ICMP, the initiator should just ask for another child SA with the real selectors when real traffic comes along. - Bill _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 2 17:12:14 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03895 for ; Wed, 2 Mar 2005 17:12:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6c22-0008Eq-Jp; Wed, 02 Mar 2005 17:09:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6c20-0008E4-Mg for ipsec@megatron.ietf.org; Wed, 02 Mar 2005 17:09:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03593 for ; Wed, 2 Mar 2005 17:09:21 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6c3E-0004gL-Ek for ipsec@ietf.org; Wed, 02 Mar 2005 17:10:41 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 02 Mar 2005 14:22:07 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j22M99uC010145; Wed, 2 Mar 2005 14:09:10 -0800 (PST) Received: from [171.71.49.252] (dhcp-171-71-49-252.cisco.com [171.71.49.252]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BCJ81408; Wed, 2 Mar 2005 14:09:11 -0800 (PST) Message-ID: <42263987.2000402@cisco.com> Date: Wed, 02 Mar 2005 14:09:11 -0800 From: Kevin Li User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Bill Sommerfeld Subject: Re: [Ipsec] SPD & IKE v2 References: <20050302212517.77832.qmail@web52502.mail.yahoo.com> <1109799636.8377.142.camel@thunk> In-Reply-To: <1109799636.8377.142.camel@thunk> X-Spam-Score: 1.1 (+) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Cc: ipsec@ietf.org, Saroop Mathur , Paul Hoffman X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0867078793==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0867078793== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Bill Sommerfeld wrote: 
On Wed, 2005-03-02 at 16:25, Saroop Mathur wrote:
  
There is no way currently for the initiator to tell the responder not
to narrow a range. The packet header selectors are only specify that
the narrowed range must include the packet selectors.
    
...
  
Of course all TS negotiation problems can be avoided by matched polices
at both ends. But IKEv2 is designed for handling mismatched policies.
    

yes.  and it does that through narrowing.  TANSTAAFL.

If you disable narrowing, you lose the ability to find the policy 
intersection; if your client box can't cope with multiple SA's and wants
to stop narrowing you'll need to change the SG's policy anyway to get
bits to move.

							- Bill
There is a small problem for always narrowing TS in case the initiator want all (exact match) or nothing.
In this case, the ipsec SA has already been created on responder side for narrowing TS. But the initiator doesn't like it (policy "accept all or noththing"), then the initiator needs to explicitly tell the responder to delete the SA. This is ok, but undesirable.

It would be nice if the initiator can convey such information to the responder.

Thanks.

Kevin

--===============0867078793== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0867078793==-- From ipsec-bounces@ietf.org Wed Mar 2 17:23:02 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04826 for ; Wed, 2 Mar 2005 17:23:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6cBf-000222-0D; Wed, 02 Mar 2005 17:19:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6cBc-00021r-Fj for ipsec@megatron.ietf.org; Wed, 02 Mar 2005 17:19:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04540 for ; Wed, 2 Mar 2005 17:19:17 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6cCq-0004w2-Bc for ipsec@ietf.org; Wed, 02 Mar 2005 17:20:37 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-1.cisco.com with ESMTP; 02 Mar 2005 14:33:19 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,131,1107763200"; d="scan'208"; a="617399225:sNHT23712472" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j22MIvq8009799; Wed, 2 Mar 2005 14:18:57 -0800 (PST) Received: from [171.71.49.252] (dhcp-171-71-49-252.cisco.com [171.71.49.252]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BCJ82634; Wed, 2 Mar 2005 14:19:03 -0800 (PST) Message-ID: <42263BD7.6090506@cisco.com> Date: Wed, 02 Mar 2005 14:19:03 -0800 From: Kevin Li User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman Subject: Re: [Ipsec] SPD & IKE v2 References: <20050302205324.99785.qmail@web52501.mail.yahoo.com> <1109797975.8377.130.camel@thunk> <1109800976.8377.147.camel@thunk> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Bill Sommerfeld X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Paul Hoffman wrote: > At 5:02 PM -0500 3/2/05, Bill Sommerfeld wrote: > >> On Wed, 2005-03-02 at 16:43, Paul Hoffman wrote: >> >>> Further, the way the >>> document is worded, you are supposed to make the first selector for >>> the first packet *even if you don't want to actually have that flow*. >> >> >> why would you ask for an SA you didn't intend to use? > > > Because the IKEv2 document says you SHOULD. > I don't think IKEv2 spec should dictate how IKE negotiation is triggered. Agree with Paul that the first traffic selector doesn't have to be the traffic triggering the IKE negotiation. Thanks. Kevin _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 2 17:32:09 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05878 for ; Wed, 2 Mar 2005 17:32:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6cK1-000467-7c; Wed, 02 Mar 2005 17:28:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6cJy-00045u-VR for ipsec@megatron.ietf.org; Wed, 02 Mar 2005 17:27:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05419 for ; Wed, 2 Mar 2005 17:27:56 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6cLC-0005AS-S9 for ipsec@ietf.org; Wed, 02 Mar 2005 17:29:16 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j22MRuNV004003; Wed, 2 Mar 2005 14:27:56 -0800 (PST) Received: from thunk (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j22MRtQp022953; Wed, 2 Mar 2005 17:27:56 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j22MRtkW011043; Wed, 2 Mar 2005 17:27:55 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j22MRt4j011042; Wed, 2 Mar 2005 17:27:55 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: [Ipsec] SPD & IKE v2 From: Bill Sommerfeld To: Paul Hoffman In-Reply-To: References: <20050302205324.99785.qmail@web52501.mail.yahoo.com> <1109797975.8377.130.camel@thunk> <1109800976.8377.147.camel@thunk> Content-Type: text/plain Content-Transfer-Encoding: 7bit Message-Id: <1109802474.8377.156.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Wed, 02 Mar 2005 17:27:55 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit On Wed, 2005-03-02 at 17:06, Paul Hoffman wrote: > >why would you ask for an SA you didn't intend to use? > > Because the IKEv2 document says you SHOULD. can you be more specific? I don't see that at all. > > > For example, you might send an ICMP ping just to get the tunnel up, > > > even if you don't intend to have ICMP in the enventual tunnel. > > > >if the peer doesn't want to let ICMP in, it should reject all proposals. > > That leads to lack of interop, yes? correctly in this case (no intersection between the initiator's proposal and the peer's policy). when a real (non-speculative) packet comes along, a real tunnel would be set up. - Bill _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 2 18:01:48 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08189 for ; Wed, 2 Mar 2005 18:01:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6ckL-0000ak-Cj; Wed, 02 Mar 2005 17:55:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6ckK-0000af-9F for ipsec@megatron.ietf.org; Wed, 02 Mar 2005 17:55:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07598 for ; Wed, 2 Mar 2005 17:55:07 -0500 (EST) Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6clX-0005fp-3l for ipsec@ietf.org; Wed, 02 Mar 2005 17:56:28 -0500 Received: from unknown (HELO beta.jnpr.net) (172.24.18.109) by borg.juniper.net with ESMTP; 02 Mar 2005 14:55:00 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,131,1107763200"; d="scan'208"; a="236759832:sNHT19718520" Received: from hadron.jnpr.net ([172.24.15.25]) by beta.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Wed, 2 Mar 2005 14:54:59 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] SPD & IKE v2 Date: Wed, 2 Mar 2005 14:54:58 -0800 Message-ID: Thread-Topic: [Ipsec] SPD & IKE v2 Thread-Index: AcUfdELfMbO7ZKMwR4W0kQMBZ4xtiwAApfIQ From: "Timothy Liu" To: "Paul Hoffman" X-OriginalArrivalTime: 02 Mar 2005 22:54:59.0659 (UTC) FILETIME=[DC8C71B0:01C51F7A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable How about for the initiator to include a notification TS_EXACT_MATCH_REQUIRED, if exact TS match is required? In this case, the initiator MUST include exactly ONE TSi=20 and ONE Tsr. The responder SHOULD accept the TS as is or reject it. The initiator that sends TS_EXACT_MATCH_REQUIRED MUST reject narrowed TS=20 from the responder. (The 'responder SHOULD' clause relieve the responsibility from the responder in case the responder do not recognize the notification.) The responder side that need to enforce exact match can do so on its own. I think we are in a gray area where IKEv2 impose a interop requirement on policy 'enforcement', which is quite vendor specific. Timothy Liu Juniper Networks _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 2 19:35:47 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA17582 for ; Wed, 2 Mar 2005 19:35:46 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6eBH-0002OS-Hc; Wed, 02 Mar 2005 19:27:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6eBC-0002Ku-EZ for ipsec@megatron.ietf.org; Wed, 02 Mar 2005 19:27:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA16612 for ; Wed, 2 Mar 2005 19:26:58 -0500 (EST) Received: from [207.145.48.18] (helo=smtp.intoto.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D6eCR-0007hT-I3 for ipsec@ietf.org; Wed, 02 Mar 2005 19:28:20 -0500 Received: from not-angel.intoto.com ([66.80.10.146]) by smtp.intoto.com (SMSSMTP 4.0.0.59) with SMTP id M2005030216261909346 ; Wed, 02 Mar 2005 16:26:19 -0800 Received: from subha (dhcp-66.intoto.com [10.1.5.66]) (authenticated bits=0) by not-angel.intoto.com (8.13.1/8.13.1) with ESMTP id j230Qi8c015662; Wed, 2 Mar 2005 16:26:46 -0800 Message-ID: <01d901c51f87$ada89600$4205010a@subha> From: "Subha" To: "Surya Batchu" , "Tero Kivinen" , "Stephen Kent" References: <20050302203511.75886.qmail@web90001.mail.scd.yahoo.com> Subject: Re: [Ipsec] SPD & IKE v2 Date: Wed, 2 Mar 2005 16:26:43 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.5 (/) X-Scan-Signature: 32604d42645517c44d778f1d111b40a6 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="===============0494413827==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0494413827== Content-Type: multipart/alternative; boundary="----=_NextPart_000_01D6_01C51F44.9F12E520" This is a multi-part message in MIME format. ------=_NextPart_000_01D6_01C51F44.9F12E520 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi All, I also think that IKEv2 and 2401-bis are conforming to each other. I = would appreciate if someone could indicate why they are not. Thanks, Subha ----- Original Message -----=20 From: Surya Batchu=20 To: Tero Kivinen ; Stephen Kent=20 Cc: ipsec@ietf.org=20 Sent: Wednesday, March 02, 2005 12:35 PM Subject: Re: [Ipsec] SPD & IKE v2 I went through the Appendix C of = http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2401bis-05.txt. = I think that SPD syntax mentioned in here can be negotiated through = IKEv2 selector payloads. I am pasting here relevant portions of ASN1 = syntax here: SelectorLists ::=3D SET OF SelectorList SelectorList ::=3D SEQUENCE { localAddr AddrList, remoteAddr AddrList, protocol ProtocolChoice } -- List of IP addresses AddrList ::=3D SEQUENCE { v4List IPv4List OPTIONAL, v6List [0] IPv6List OPTIONAL } -- IPv4 address representations IPv4List ::=3D SEQUENCE OF IPv4Range IPv4Range ::=3D SEQUENCE { -- close, but not quite right ... ipv4Start OCTET STRING (SIZE (4)), ipv4End OCTET STRING (SIZE (4)) } -- IPv6 address representations IPv6List ::=3D SEQUENCE OF IPv6Range IPv6Range ! ::=3D SEQUENCE { -- close, but not quite right = ... ipv6Start OCTET STRING (SIZE (16)), ipv6End OCTET STRING (SIZE (16)) } Based on above, 'localAddr' and 'remoteAddr' are two differnet fields = in SelectorList.=20 Each one of them can have multiple IP address ranges. To me, it seems both rfc2401bis and IKEv2 TS are conforming to each = other. Am I missing some thing? Surya Tero Kivinen wrote: Stephen Kent writes: > This brings me to the issue Tero raised in this discussion. Tero, = I=20 > think you suggested that there is a fundamental mismatch between = what=20 > the SPD allows to be expressed and what IKE v2 can negotiate.=20 > Specifically, I think you indicated that the mismatch arises = because=20 > IKE semantics call for a "mix and match" approach to viewing = TSi/TSr=20 > payloads. Yes. The IKEv2 does not tie TSi and TSr together in anyway. It says you process TSi and TSr separately, i.e. there is no text there = saying they would be tied together in any ways. > I looked at section 2.9 in IKE v2 and I don't see where it=20 > suggests this. Do you see any text there which could indicate that the TS payload items are somehow paired? It does say that both TSi and TSr SHOULD have very specific entries as t! heir first entries.=20 > For example, the text describes how to pass triggering=20 > packet header data as the FIRST selector set data in TSi and TSr=20 > payloads, implying that the order of elements in these payloads is = > important, and that one is expected to view them as pairs, = matching=20 > the corresponding S/D address and port fields. I cannot see how it implies that there is any order for the rest of the items, when you say that the first item must be from packet if = you ant to include it. We needed some way to find the specific from = packet TS item, and instead of adding a flag or using separate TS type for that we decided to put it as a first item in the list. We already found out in the interop event that this can cause confusion, as = some people didn't understand that the first item can be very specific. = And in some cases is it impossible to find out wheather there is one specific entry or not. > So, I ! have to admit=20 > that I am confused by your comment. If I send a series of pairs of = > TSi/TSr payloads, I would interpret this to represent pairs of S/D = > data, with a common protocol, so that each matched pair represents = > one selector set from an SPD entry, if the entry has more than one = > selector set in it. One of the ideas is that the initiator can send TS: TSi =3D 0.0.0.0-255.255.255.255 TSr =3D 0.0.0.0-255.255.255.255 and the responder can narrow it down to: TSi =3D 10.0.11.22-10.0.11.22 TSr =3D 10.0.0.0-10.255.255.255, 192.168.0.0-192.168.255.255 etc. > Can you cite the parts of IKEv2 that suggest the "mix and match"=20 > approach that you indicated? It does use mix and match in all other cases with similar lists. Can you find out where it says you should pairwise tie TS together? It does not say anywhere that there should be even equal number of = items in the TSi and TSr.=20 > Such semantics make no sense in the access control context that = the > SPD represents. It does make perfect sense for me. I.e. the TSi lists the IP-address ranges which can be found from the initiators end of the network, = and TSr contains the list of address ranges which can be found from the responders end. I.e. if you have VPN setup where the site A has networks = 10.0.22.0/24 and 10.0.44.0/24, and the site B has 10.0.55.0/24,10.0.222.0/24,10.0.227.0/24, then the TSi will contain the networks from site A has, and TSr of the request will have 0.0.0.0-255.255.255.255, and the responde will narrow that any ip = down so that TSi will still have 10.0.22.0/24 and 10.0.44.0/24 and the = TSr will now have the networks site B has. This would not be possible if the TS items would be tied together, = as it would cause lots of TS items to be created. We tried to avoid combinatory explosion in the IKEv2. > Also, I'd like to ! think that IKE should be trying to negotiate = what > the SPD specifies, to minimize the likelihood that SAs are > established that later will not carry the intended traffic. I think you earlier said it other way around, i.e. the SPD was specified to be able to negotiate what the IKEv2 can negotiate. I think I did comment this earlier when you were writing the ASN1 version of the SPD, but as I am now behind bad network connections I cannot search the archives.=20 --=20 kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec -------------------------------------------------------------------------= ----- Celebrate Yahoo!'s 10th Birthday!=20 Yahoo! Netrospective: 100 Moments of the Web=20 -------------------------------------------------------------------------= ----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_01D6_01C51F44.9F12E520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi All,
 
I also think that IKEv2 and 2401-bis = are conforming=20 to each other. I would
appreciate if someone could indicate = why they are=20 not.
 
Thanks,
Subha
----- Original Message -----
From:=20 Surya=20 Batchu
Sent: Wednesday, March 02, 2005 = 12:35=20 PM
Subject: Re: [Ipsec] SPD & = IKE=20 v2

 
I went through the Appendix C of  http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2401bis-05= .txt.=20 I think that SPD syntax mentioned in here can be negotiated through = IKEv2=20 selector payloads. I am pasting here relevant portions of ASN1 syntax=20 here:

 SelectorLists ::=3D SET OF=20 SelectorList

      SelectorList ::=3D = SEQUENCE=20 {
         =20 localAddr  =20 AddrList,
         =20 remoteAddr =20 AddrList,
         =20 protocol    ProtocolChoice }
 
  -- List of IP addresses
      = AddrList=20 ::=3D SEQUENCE = {
         =20 v4List      IPv4List=20 OPTIONAL,
         =20 v6List      [0] IPv6List OPTIONAL=20 }

      -- IPv4 address=20 representations
      IPv4List ::=3D = SEQUENCE OF=20 IPv4Range

      IPv4Range ::=3D = SEQUENCE=20 {    -- close, but not quite right=20 ...
         =20 ipv4Start   OCTET STRING (SIZE=20 (4)),
         =20 ipv4End     OCTET STRING (SIZE (4))=20 }

      -- IPv6 address=20 representations
      IPv6List ::=3D = SEQUENCE OF=20 IPv6Range

      IPv6Range ! ::=3D = SEQUENCE=20 {    -- close, but not quite right=20 ...
         =20 ipv6Start   OCTET STRING (SIZE=20 (16)),
         =20 ipv6End     OCTET STRING (SIZE (16)) }
 
Based on above, 'localAddr' and 'remoteAddr' are two differnet = fields in=20 SelectorList.
Each one of them can have multiple IP address ranges.
 
To me, it seems both rfc2401bis and IKEv2 TS are conforming to = each=20 other.
Am I missing some thing?
 
Surya

Tero Kivinen <kivinen@iki.fi>=20 wrote:
Stephen=20 Kent writes:
> This brings me to the issue Tero raised in this = discussion. Tero, I
> think you suggested that there is a = fundamental=20 mismatch between what
> the SPD allows to be expressed and = what IKE=20 v2 can negotiate.
> Specifically, I think you indicated that = the=20 mismatch arises because
> IKE semantics call for a "mix and = match"=20 approach to viewing TSi/TSr
> payloads.

Yes. The IKEv2 = does=20 not tie TSi and TSr together in anyway. It says
you process TSi = and TSr=20 separately, i.e. there is no text there saying
they would be tied = together in any ways.

> I looked at section 2.9 in IKE v2 = and I=20 don't see where it
> suggests this.

Do you see any = text there=20 which could indicate that the TS payload
items are somehow = paired? It=20 does say that both TSi and TSr SHOULD
have very specific entries = as t!=20 heir first entries.

> For example, the text describes how = to pass=20 triggering
> packet header data as the FIRST selector set = data in TSi=20 and TSr
> payloads, implying that the order of elements in = these=20 payloads is
> important, and that one is expected to view = them as=20 pairs, matching
> the corresponding S/D address and port=20 fields.

I cannot see how it implies that there is any order = for the=20 rest of
the items, when you say that the first item must be from = packet=20 if you
ant to include it. We needed some way to find the specific = from=20 packet
TS item, and instead of adding a flag or using separate TS = type=20 for
that we decided to put it as a first item in the list. We=20 already
found out in the interop event that this can cause = confusion, as=20 some
people didn't understand that the first item can be very = specific.=20 And
in some cases is it impossible to find out wheather there is=20 one
specific entry or not.

> So, I ! have to admit =
>=20 that I am confused by your comment. If I send a series of pairs of =
>=20 TSi/TSr payloads, I would interpret this to represent pairs of S/D =
>=20 data, with a common protocol, so that each matched pair represents =
>=20 one selector set from an SPD entry, if the entry has more than one =
>=20 selector set in it.

One of the ideas is that the initiator = can send=20 TS:

TSi =3D 0.0.0.0-255.255.255.255
TSr =3D=20 0.0.0.0-255.255.255.255

and the responder can narrow it down=20 to:

TSi =3D 10.0.11.22-10.0.11.22
TSr =3D = 10.0.0.0-10.255.255.255,=20 192.168.0.0-192.168.255.255

etc.

> Can you cite the = parts=20 of IKEv2 that suggest the "mix and match"
> approach that you = indicated?

It does use mix and match in all other cases with = similar=20 lists. Can
you find out where it says you should pairwise tie TS=20 together? It
does not say anywhere that there should be even = equal number=20 of items
in the TSi and TSr.
> Such semantics make = no sense=20 in the access control context that the
> SPD = represents.

It=20 does make perfect sense for me. I.e. the TSi lists the = IP-address
ranges=20 which can be found from the initiators end of the network, = and
TSr=20 contains the list of address ranges which can be found from=20 the
responders end.

I.e. if you have VPN setup where the = site A=20 has networks 10.0.22.0/24
and 10.0.44.0/24, and the site B=20 has
10.0.55.0/24,10.0.222.0/24,10.0.227.0/24, then the TSi will=20 contain
the networks from site A has, and TSr of the request will = have
0.0.0.0-255.255.255.255, and the responde will narrow that = any ip=20 down
so that TSi will still have 10.0.22.0/24 and 10.0.44.0/24 = and the=20 TSr
will now have the networks site B has.

This would not = be=20 possible if the TS items would be tied together, as
it would = cause lots=20 of TS items to be created. We tried to avoid
combinatory = explosion in the=20 IKEv2.

> Also, I'd like to ! think that IKE should be = trying to=20 negotiate what
> the SPD specifies, to minimize the likelihood = that=20 SAs are
> established that later will not carry the intended=20 traffic.

I think you earlier said it other way around, i.e. = the SPD=20 was
specified to be able to negotiate what the IKEv2 can = negotiate.=20 I
think I did comment this earlier when you were writing the=20 ASN1
version of the SPD, but as I am now behind bad network = connections=20 I
cannot search the archives.
--=20 =
kivinen@safenet-inc.com

______________________________________= _________
Ipsec=20 mailing=20 = list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec

Celebrate Yahoo!'s 10th Birthday!
Yahoo! = Netrospective: 100=20 Moments of the Web=20

_______________________________________________
Ipsec = mailing=20 = list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_01D6_01C51F44.9F12E520-- --===============0494413827== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0494413827==-- From ipsec-bounces@ietf.org Wed Mar 2 19:45:16 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18779 for ; Wed, 2 Mar 2005 19:45:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6eQY-0006W3-GR; Wed, 02 Mar 2005 19:42:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6eQV-0006Uc-MD for ipsec@megatron.ietf.org; Wed, 02 Mar 2005 19:42:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18541 for ; Wed, 2 Mar 2005 19:42:48 -0500 (EST) Received: from [207.145.48.18] (helo=smtp.intoto.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D6eRl-00084g-7y for ipsec@ietf.org; Wed, 02 Mar 2005 19:44:10 -0500 Received: from not-angel.intoto.com ([66.80.10.146]) by smtp.intoto.com (SMSSMTP 4.0.0.59) with SMTP id M2005030216421509357 for ; Wed, 02 Mar 2005 16:42:15 -0800 Received: from SriniSony (dhcp-109.intoto.com [10.1.5.109]) (authenticated bits=0) by not-angel.intoto.com (8.13.1/8.13.1) with ESMTP id j230gcdD016876 for ; Wed, 2 Mar 2005 16:42:41 -0800 Message-Id: <200503030042.j230gcdD016876@not-angel.intoto.com> From: "Srinivasa Rao Addepalli" To: Subject: RE: [Ipsec] SPD & IKE v2 Date: Wed, 2 Mar 2005 16:42:34 -0800 Organization: Intoto Inc MIME-Version: 1.0 X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUfU+qu7rd5X/L5QdaUcIRmyrvFCwANNbKQ In-Reply-To: <20050302181439.59654.qmail@web90007.mail.scd.yahoo.com> X-Spam-Score: 0.9 (/) X-Scan-Signature: abb8110dde048486ea2be9c769692569 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="===============1722371027==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1722371027== Content-Type: multipart/alternative; boundary="----=_NextPart_000_00AF_01C51F46.D61CCA70" This is a multi-part message in MIME format. ------=_NextPart_000_00AF_01C51F46.D61CCA70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Multiple duplicate SA problems can happen for multiple reasons. You indicate one such scenario. It is a better implementation technique to use some sort of throttling on number of SAs (with same selectors) that can be present at any time. By the way, having an indication in TS that it has packet selectors is good. But as others indicated, it may be too late for that kind of change. Srini IMO, it is good to have an indication in TS payload indicating that this payload has packet header selectors. For example, assume that IPsec 'protect' policy on one side has 11.1.5.0/24-->10.1.6.0/24 and the policy on the peer has 10.1.0.0/16 -> 11.1.5.0/24. Since, one side has smaller range of selectors, the SAs that get established will always be between 11.1.5.0/24 and 10.1.6.0/24. Upon packet reception from say 10.1.7.0/24 network to 11.1.5.0/24 network, the peer starts childSA transaction as there is no matching outbound SA. In this case, the initiator sends both packet header TS payloads and security policy selectors. If the responder considers packet selectors and other selectors in the same fashion, then , it again creates SA with the same selectors as previous SA ie 11.1.5.0/24 and 10.1.6.0/24. This might happen over and over again and it might flood the SA session table. Implementations can be smart to avoid SA flood or implementation can be smart to know that there is a TS payload pair with packet selectors. But, having protocol support to identify packet selectors from other selectors really helps in simplification of implementations. If responder knows that, this SA is being negotiated for a given packet selector without any ambiguity, then the responder can choose to return error notification to the Initiator, for above transaction. Surya Paul Hoffman wrote: At 1:22 PM +0200 3/2/05, Tero Kivinen wrote: >Stephen Kent writes: > > For example, the text describes how to pass triggering >> packet header data as the FIRST selector set data in TSi and TSr >> payloads, implying that the order of elements in these payloads is > > important, and that one is expected to view them as pairs, matching >> the corresponding S/D address and port fields. > >I cannot see how it implies that there is any order for the rest of >the items, when you say that the first item must be from packet if you >ant to include it. We needed some way to find the specific from packet >TS item, and instead of adding a flag or using separate TS type for >that we decided to put it as a first item in the list. We already >found out in the interop event that this can cause confus! ion, as some >people didn't understand that the first item can be very specific. And >in some cases is it impossible to find out wheather there is one >specific entry or not. Tero is right. In fact, the document quite clearly says that the first transform does *not* need to be for an actual packet, if you want to start a tunnel without traffic. Further, I see nothing that suggests that "one is expected to view them as pairs". --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec _____ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web ------=_NextPart_000_00AF_01C51F46.D61CCA70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Multiple duplicate SA problems can = happen for multiple reasons. You indicate one such scenario. It is a better implementation technique to use some sort of throttling on number of SAs = (with same selectors) that can be present at any time. =  

 

By the way, having an indication in = TS that it has packet selectors is good. But as others indicated, it may be = too late for that kind of change.

 

Srini

 

 

IMO, it is good to have an indication in TS payload indicating = that this payload has packet header selectors.

 

For example, assume that IPsec 'protect' policy on one side has 11.1.5.0/24-->10.1.6.0/24 and

the policy on the peer has 10.1.0.0/16 -> 11.1.5.0/24. Since, = one side has smaller range of selectors, the SAs that get established = will always be between 11.1.5.0/24 and = 10.1.6.0/24.

Upon packet reception from say 10.1.7.0/24 network to = 11.1.5.0/24 network, the peer starts childSA transaction as there is no matching = outbound SA. In this case, the initiator sends both packet header TS payloads and security policy selectors. If the responder considers packet selectors = and other selectors in the same fashion, then , it again creates SA with the = same selectors as previous SA ie 11.1.5.0/24 and 10.1.6.0/24.  This might happen = over and over again and it might flood the SA session = table.

 

Implementations can be smart to avoid SA flood or = implementation can be smart to know that there is a TS payload pair with packet selectors. But, having protocol support to identify  = packet selectors from other selectors  really helps in simplification of implementations. If responder knows that, this SA is being negotiated = for a given packet selector without any ambiguity, then the responder can = choose to return error notification to the Initiator, for above = transaction.

 

Surya



Paul Hoffman <paul.hoffman@vpnc.org> = wrote:

At 1:22 PM +0200 3/2/05, Tero Kivinen wrote:
>Stephen Kent writes:
> > For example, the text describes how to pass triggering
>> packet header data as the FIRST selector set data in TSi and = TSr
>> payloads, implying that the order of elements in these payloads = is
> > important, and that one is expected to view them as pairs, = matching
>> the corresponding S/D address and port fields.
>
>I cannot see how it implies that there is any order for the rest = of
>the items, when you say that the first item must be from packet if = you
>ant to include it. We needed some way to find the specific from = packet
>TS item, and instead of adding a flag or using separate TS type = for
>that we decided to put it as a first item in the list. We = already
>found out in the interop event that this can cause confus! ion, as = some
>people didn't understand that the first item can be very specific. = And
>in some cases is it impossible to find out wheather there is one
>specific entry or not.

Tero is right. In fact, the document quite clearly says that the
first transform does *not* need to be for an actual packet, if you
want to start a tunnel without traffic. Further, I see nothing that
suggests that "one is expected to view them as pairs".

--Paul Hoffman, Director
--VPN Consortium

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec

=

 

Celebrate Yahoo!'s 10th Birthday!
Yahoo! = Netrospective: 100 Moments of the Web

------=_NextPart_000_00AF_01C51F46.D61CCA70-- --===============1722371027== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1722371027==-- From ipsec-bounces@ietf.org Thu Mar 3 04:01:09 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23233 for ; Thu, 3 Mar 2005 04:01:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6mB2-00064T-Pp; Thu, 03 Mar 2005 03:59:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6mAy-00063u-A6 for ipsec@megatron.ietf.org; Thu, 03 Mar 2005 03:59:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22801 for ; Thu, 3 Mar 2005 03:59:18 -0500 (EST) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6mCH-0001ZP-9f for ipsec@ietf.org; Thu, 03 Mar 2005 04:00:42 -0500 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.7p1+Sun/8.11.6) with ESMTP id j238x2309692; Thu, 3 Mar 2005 10:59:03 +0200 (IST) In-Reply-To: <1109800976.8377.147.camel@thunk> References: <20050302205324.99785.qmail@web52501.mail.yahoo.com> <1109797975.8377.130.camel@thunk> <1109800976.8377.147.camel@thunk> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] SPD & IKE v2 Date: Thu, 3 Mar 2005 10:59:01 +0200 To: Bill Sommerfeld X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Paul Hoffman X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit On Mar 3, 2005, at 12:02 AM, Bill Sommerfeld wrote: > On Wed, 2005-03-02 at 16:43, Paul Hoffman wrote: > >> Further, the way the >> document is worded, you are supposed to make the first selector for >> the first packet *even if you don't want to actually have that flow*. > > why would you ask for an SA you didn't intend to use? You might want to do this for a remote client. The client has a "Connect" button. The software has no way on knowing what the user is going to do after clicking "Connect". In IKEv1 it would do only Phase 1. In IKEv2 you can't do only phase 1, so you need to make some child SA in there. Making an SA for simple ICMP between the client and the gateway (just one address and protocol in each TS) is one way. You could also suggest the entire Internet (0.0.0.0-255.255.255.255) and have the gateway narrow that to some range or bunch of ranges which may or may not be useful later. In the case of a generic client I think the latter approach is more appropriate, especially if it doesn't have a matched policy with the gateway. Doing the whole thing with the "Connect" button and 4-8 packets only to fail because the gateway blocks ICMP is a bad idea. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Mar 3 08:32:17 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22803 for ; Thu, 3 Mar 2005 08:32:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6qOm-0003qV-UC; Thu, 03 Mar 2005 08:29:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6qOm-0003qQ-6g for ipsec@megatron.ietf.org; Thu, 03 Mar 2005 08:29:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22657 for ; Thu, 3 Mar 2005 08:29:50 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6qQ8-0000L3-NK for ipsec@ietf.org; Thu, 03 Mar 2005 08:31:17 -0500 Received: from [67.102.148.148] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j23DTYkJ003898; Thu, 3 Mar 2005 08:29:35 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <16933.41469.351149.32331@fireball.kivinen.iki.fi> References: <16933.41469.351149.32331@fireball.kivinen.iki.fi> Date: Thu, 3 Mar 2005 08:29:28 -0500 To: Tero Kivinen From: Stephen Kent Subject: Re: [Ipsec] SPD & IKE v2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 36b1f8810cb91289d885dc8ab4fc8172 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 1:22 PM +0200 3/2/05, Tero Kivinen wrote: > > > For example, the text describes how to pass triggering >> packet header data as the FIRST selector set data in TSi and TSr >> payloads, implying that the order of elements in these payloads is >> important, and that one is expected to view them as pairs, matching >> the corresponding S/D address and port fields. > >I cannot see how it implies that there is any order for the rest of >the items, when you say that the first item must be from packet if you >ant to include it. We needed some way to find the specific from packet >TS item, and instead of adding a flag or using separate TS type for >that we decided to put it as a first item in the list. We already >found out in the interop event that this can cause confusion, as some >people didn't understand that the first item can be very specific. And >in some cases is it impossible to find out wheather there is one >specific entry or not. We agree that if an initiator wants to send header data from a triggering packet, then the data is sent as the first pair of entries in the TSi/r payloads. In this case, it seems clear that the semantics here is that these entries are paired, i.e., the responder should interpret the pair of entries as representing the S/D address and port data from the triggering packet. Do you agree? But, there is no flag that indicates whether the first entry is from a triggering packet, not, as others have noted. Thus if the responder always treats the first pair of TSi/r addresses & ports as matched, which is the sensible interpretation when this first pair represents triggering packet data, then it will do so even when the first pair does NOT represent such data. So, why change the interpretation for later pairs of S/D addresses & ports? > > So, I have to admit >> that I am confused by your comment. If I send a series of pairs of >> TSi/TSr payloads, I would interpret this to represent pairs of S/D >> data, with a common protocol, so that each matched pair represents >> one selector set from an SPD entry, if the entry has more than one >> selector set in it. > >One of the ideas is that the initiator can send TS: > >TSi = 0.0.0.0-255.255.255.255 >TSr = 0.0.0.0-255.255.255.255 > >and the responder can narrow it down to: > >TSi = 10.0.11.22-10.0.11.22 >TSr = 10.0.0.0-10.255.255.255, 192.168.0.0-192.168.255.255 I don't disagree that you can save space in IKE messages under some circumstances by being able to associate one payload for one direction with multiple ones for the other direction. However, if we do not have a way to represent a one-to-one correspondence between TSi and TSr values, then we cannot convey the semantics of the SPD, and that is not OK. > > Can you cite the parts of IKEv2 that suggest the "mix and match" >> approach that you indicated? > >It does use mix and match in all other cases with similar lists. Can >you find out where it says you should pairwise tie TS together? It >does not say anywhere that there should be even equal number of items >in the TSi and TSr. The example I gave, for the first set of values in TSi/r implies a 1-to-1 (paired) matching in this case. Also, the purpose of the IKE negotiation is to represent an SPD entry to a peer. SPD entries, like analogous ACL entries, are paired. Because we create pairs of SAs that represent traffic bidirectional traffic flows that are common in the IP context, one expresses ACLs in terms of these bidirectional flows. > > Such semantics make no sense in the access control context that the >> SPD represents. > >It does make perfect sense for me. I.e. the TSi lists the IP-address >ranges which can be found from the initiators end of the network, and >TSr contains the list of address ranges which can be found from the >responders end. The example you provide is a reasonable one, but it represents a very simple case where the mix and match approach expresses the underlying access control semantics. However, in the more general case, I may want to express the notion that Host A in my net can be accesses by Host B in your net and Host C in my net can be accessed by Host D in your net, AND I want the traffic for both of these flows to be carried via one SA. The SPD allows one to express this notion, and IKE needs to be able to convey it. That is how firewalls express access control policy (modulo the use of SAs) and the IPsec SPD is a standardized representation of such an access control policy. >I.e. if you have VPN setup where the site A has networks 10.0.22.0/24 >and 10.0.44.0/24, and the site B has >10.0.55.0/24,10.0.222.0/24,10.0.227.0/24, then the TSi will contain >the networks from site A has, and TSr of the request will have >0.0.0.0-255.255.255.255, and the responde will narrow that any ip down >so that TSi will still have 10.0.22.0/24 and 10.0.44.0/24 and the TSr >will now have the networks site B has. > >This would not be possible if the TS items would be tied together, as >it would cause lots of TS items to be created. We tried to avoid >combinatory explosion in the IKEv2. I agree that we should minimize combinatorial explosion, but the SPD is a local representation of access control policy and one cannot express the sort of constraints that may be necessary if the TS proposals are treated as your suggest. IKE could have a different structure for the TS proposals, one that would satisfy both goals. It could allow for compact representation of the cases where one wants to list only selector range for one direction and bind multiple ranges to the other direction. But, we do not have that and I sense a lot of resistance to making a change of this sort at this point in time. > > Also, I'd like to think that IKE should be trying to negotiate what >> the SPD specifies, to minimize the likelihood that SAs are >> established that later will not carry the intended traffic. > >I think you earlier said it other way around, i.e. the SPD was >specified to be able to negotiate what the IKEv2 can negotiate. I >think I did comment this earlier when you were writing the ASN1 >version of the SPD, but as I am now behind bad network connections I >cannot search the archives. I'm afraid you have this backwards :-) I have said that we tried to work to align the SPD and IKE, so that we could negotiate in IKE what the SPD expresses. We had mismatches in 2401bis vs. IKE v1 in that we could express things in the SPD that IKE could not negotiate. While it is true that I have said that we wanted to make sure that IKE v2 and 2401bis are aligned, there is a priority here, i.e., 2401bis specifies access control policies and IKE v2 exists to negotiate SAs consistent with these policies, not the other way around. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Mar 3 09:03:01 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA25409 for ; Thu, 3 Mar 2005 09:03:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6qrd-0008OH-Um; Thu, 03 Mar 2005 08:59:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6qrc-0008O1-Dl for ipsec@megatron.ietf.org; Thu, 03 Mar 2005 08:59:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24913 for ; Thu, 3 Mar 2005 08:59:38 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6qsz-0000xc-BB for ipsec@ietf.org; Thu, 03 Mar 2005 09:01:05 -0500 Received: from [67.102.148.148] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j23DxSkL004967; Thu, 3 Mar 2005 08:59:30 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <01d901c51f87$ada89600$4205010a@subha> References: <20050302203511.75886.qmail@web90001.mail.scd.yahoo.com> <01d901c51f87$ada89600$4205010a@subha> Date: Thu, 3 Mar 2005 08:59:26 -0500 To: "Subha" From: Stephen Kent Subject: Re: [Ipsec] SPD & IKE v2 X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.5 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 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="===============0617304254==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0617304254== Content-Type: multipart/alternative; boundary="============_-1102264126==_ma============" --============_-1102264126==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 4:26 PM -0800 3/2/05, Subha wrote: >Hi All, > >I also think that IKEv2 and 2401-bis are conforming to each other. I would >appreciate if someone could indicate why they are not. > >Thanks, >Subha > I think the problem is that the SPD specifies pairs of TSi/r values, per protocol, to be bound to an individual SA (assuming no use of the PFP feature). If one interprets IKE proposals the way I suggest, then one can negotiate SAs consistent with the SPD. However, as Tero noted, in some cases this will result in significant IKE message size growth, that may cause fragmentation problems. The reason for the growth is that if we need to convey paired TSi/r address and port data, then one might have to replicate a TSi or TSr value to maintain the pairing. Tero gave examples of this. So we have a few options of how to address this problem: 1. change IKE to allow explicit binding of TSi/r values, so that one can unambiguously represent both 1-to-1 and 1-to-many relationships. this is the best answer, in principle, but folks are understandably reluctant to make a change to IKE syntax at this time. 2. require 1-to-1 matching of IKE payloads, to allow representation of SPD semantics. this does not change IKE syntax, but does change IKE processing rules, and can result in growth in the size of IKE messages in certain contexts, with attendant fragmentation concerns. 3. change the SPD syntax and semantics to accommodate the limitations of the IKE syntax. this will cause multiple SAs to be created in some contexts, where the current semantics would allow multiple traffic flows to be carried via a single SA. if we do not go with #1, then we have a tradeoff: we can create bigger proposals (#2) or create more SAs (#3) each undesirable outcome arising under certain conditions. Steve --============_-1102264126==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Ipsec] SPD & IKE v2
At 4:26 PM -0800 3/2/05, Subha wrote:
Hi All,
 
I also think that IKEv2 and 2401-bis are conforming to each other. I would
appreciate if someone could indicate why they are not.
 
Thanks,
Subha

I think the problem is that the SPD specifies pairs of TSi/r values, per protocol, to be bound to an individual SA (assuming no use of the PFP feature). If one interprets IKE proposals the way I suggest, then one can negotiate SAs consistent with the SPD. However, as Tero noted, in some cases this will result in significant IKE message size growth, that may cause fragmentation problems. The reason for the growth is that if we need to convey paired TSi/r address and port data, then one might have to replicate a TSi or TSr value to maintain the pairing. Tero gave examples of this.

So we have a few options of how to address this problem:

        1. change IKE to allow explicit binding of TSi/r values, so that one can unambiguously represent both 1-to-1 and 1-to-many relationships.  this is the best answer, in principle, but folks are understandably reluctant to make a change to IKE syntax at this time.

        2. require 1-to-1 matching of IKE payloads, to allow representation of SPD semantics. this does not change IKE syntax, but does change IKE processing rules, and can result in growth in the size of IKE messages in certain contexts, with attendant fragmentation concerns.

        3. change the SPD syntax and semantics to accommodate the limitations of the IKE syntax. this will cause multiple SAs to be created in some contexts, where the current semantics would allow multiple traffic flows to be carried via a single SA.

if we do not go with #1, then we have a tradeoff: we can create bigger proposals (#2) or create more SAs (#3) each undesirable outcome arising under certain conditions.

Steve

--============_-1102264126==_ma============-- --===============0617304254== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0617304254==-- From ipsec-bounces@ietf.org Thu Mar 3 12:24:40 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20760 for ; Thu, 3 Mar 2005 12:24:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6tzv-0002WE-F8; Thu, 03 Mar 2005 12:20:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6tzs-0002Vw-TE for ipsec@megatron.ietf.org; Thu, 03 Mar 2005 12:20:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20335 for ; Thu, 3 Mar 2005 12:20:22 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6u1G-0006Ib-HP for ipsec@ietf.org; Thu, 03 Mar 2005 12:21:52 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j23HKG4k021357 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Mar 2005 19:20:16 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j23HKEEN021354; Thu, 3 Mar 2005 19:20:14 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16935.18254.542091.417858@fireball.kivinen.iki.fi> Date: Thu, 3 Mar 2005 19:20:14 +0200 From: Tero Kivinen To: Paul Koning Subject: RE: [Ipsec] Technical change needed to IKEv2 before publication In-Reply-To: <16933.47504.763000.221233@gargle.gargle.HOWL> References: <892867B805D4DA42A1C48103BF4CFA5A0122B91D@EUR-MSG-20.europe.corp.microsoft.com> <16933.47504.763000.221233@gargle.gargle.HOWL> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 8 min X-Total-Time: 8 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, mroe@microsoft.com, paul.hoffman@vpnc.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Paul Koning writes: > Michael> An initiator that is willing to negotiate either ESN off or > Michael> ESN on should explicitly encode both options in a Transform > Michael> Type 5 (because the default is to demand ESN on, which is > Michael> not a good idea). > > I don't think so -- such an initiator would have to send two > proposals, one with ESN on, one with ESN off. The one with ESN on can > be encoded either by explicitly saying ESN on, or by omitting ESN from > that proposal. No he does not need to send two proposals, in fact there are mostly no reason ever to include multiple proposals. He should include two transform with identical transform type, and different transform ID. The only reason to include multiple proposals if you do not want to allow mix and match, meaning that you want to say that AES and ESN, or 3DES and NO ESN, but do not want to allow AES and NO ESN. There is no reason to do things in the complicated IKEv1 way of having multiple proposals. Actually if you follow rfc2401bis and IKEv2 the SA payload can always have exactly one proposal substructure, which will then have multiple transform substructures. I.e. there will not even be multiple protocols when using rfc2401bis, as it creates AH + ESP as routing the packets back to the IPsec instead of creating SA bundle with multiple protocols. The IKEv2 document still have some text saying that you could create AH + ESP using one exchange, and that can be used for non rfc2401bis or extended rfc2401bis implementations, but base rfc2401bis does not require you to support that. All this means that most implementations can simply use the first proposal substructure and only check the other proposal structures to check that if there is multiple protocols then they need to return error (but they do not need to really parse them etc). -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Mar 3 12:28:37 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21282 for ; Thu, 3 Mar 2005 12:28:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6u5N-0004WL-QD; Thu, 03 Mar 2005 12:26:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6u5K-0004Vq-Vu for ipsec@megatron.ietf.org; Thu, 03 Mar 2005 12:26:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20915 for ; Thu, 3 Mar 2005 12:25:59 -0500 (EST) Received: from thunk.org ([69.25.196.29] helo=thunker.thunk.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6u6i-0006SK-4z for ipsec@ietf.org; Thu, 03 Mar 2005 12:27:29 -0500 Received: from root (helo=thunk.org) by thunker.thunk.org with local-esmtp (Exim 3.35 #1 (Debian)) id 1D6u5E-000142-00; Thu, 03 Mar 2005 12:25:56 -0500 Received: from tytso by thunk.org with local (Exim 4.50) id 1D6u5D-0002lx-HZ; Thu, 03 Mar 2005 12:25:55 -0500 Date: Thu, 3 Mar 2005 12:25:55 -0500 From: "Theodore Ts'o" To: Paul Hoffman Message-ID: <20050303172555.GB10574@thunk.org> References: <892867B805D4DA42A1C48103BF4CFA5A0122B91D@EUR-MSG-20.europe.corp.microsoft.com> <16933.47504.763000.221233@gargle.gargle.HOWL> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.6+20040907i X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: ipsec@ietf.org Subject: [Ipsec] Proposed Straw Poll X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org A number of people have suggested just doing a clarification, although there were also a number of people who suggested making ESN's mandatory (Suggestion C). Some of these discussions were done while the discussion was still going on, however, so I'd like for us to do a quick straw poll so that people can clearly register their preferences. At this point, I believe this is would be a correct description of the question at hand. Do people agree this is the proper way to pose the question before we start the straw poll? - Ted -------------------- Issue: If a receiver doesn't support ESN, they require the sender to send an ESN transform Some systems know that they don't support ESN, and therefore they require the other side to actively say they won't expect it. The only way for the other side to do so is for it to send a Transform Type 5 with a value of 0. However, there is no way for the responder to say that to the initiator, so interoperability is not possible. There are four ways that have been discussed to resolve this issue: PROPOSAL A: ----------- The last sentence of 3.3.2 says: If Transform Type 5 is not included in a proposal, use of Extended Sequence Numbers is assumed. Replace this with: If Transform Type 5 is not included in a proposal, it is assumed that the sending party does not support Extended Sequence Numbers. PROPOSAL B: ----------- Create a new response notification that says "I can't do ESN, start again and include a 'no ESN' transform." [Note during the discussion on the mailig list, little or no support was seen for this alternative. PROPOSAL C: ----------- Change the places that says Transform Type 5 is optional to say it is mandatory. PROPOSAL D: ----------- Make a clarification (that would go into Pasi's clarification document) that would add a sentence to the end of Section 3.3.2 that says "Note that if the initiator is willing to accept either the use of extended sequence numbers or not, the initiator SHOULD send this transform in its proposals." PROPOSAL D_1: ------------- Do suggestion D above, but place the clarification in IKEv2. PROPOSAL D_2: ------------- Do Suggestion D_1 only if it can be done without delaying the publication of IKEv2. Please select one of proposals A, B, C, D. If proposal D is selected, please note if you support D_1 or D_2. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Mar 3 12:47:08 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23423 for ; Thu, 3 Mar 2005 12:47:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6uOk-0000ZV-T1; Thu, 03 Mar 2005 12:46:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6uOj-0000ZD-OM for ipsec@megatron.ietf.org; Thu, 03 Mar 2005 12:46:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23353 for ; Thu, 3 Mar 2005 12:46:02 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6uQ8-00072k-6T for ipsec@ietf.org; Thu, 03 Mar 2005 12:47:33 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j23Hk3hS021611 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Mar 2005 19:46:03 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j23Hk2kB021608; Thu, 3 Mar 2005 19:46:02 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16935.19802.411588.930940@fireball.kivinen.iki.fi> Date: Thu, 3 Mar 2005 19:46:02 +0200 From: Tero Kivinen To: Saroop Mathur Subject: Re: [Ipsec] SPD & IKE v2 In-Reply-To: <20050302205324.99785.qmail@web52501.mail.yahoo.com> References: <20050302205324.99785.qmail@web52501.mail.yahoo.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 22 min X-Total-Time: 25 min X-Spam-Score: 0.0 (/) X-Scan-Signature: e1b0e72ff1bbd457ceef31828f216a86 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Paul Hoffman X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Saroop Mathur writes: > > At 10:14 AM -0800 3/2/05, Surya Batchu wrote: > > >IMO, it is good to have an indication in TS payload indicating that > > >this payload has packet header selectors. > > I believe such an indication will be really useful. Yes it would be usefull, but not possible at this time. > It can be generalized to indicate "the responder must include this > TS in the subset selected by the responder". That is already there in the document. It says: ---------------------------------------------------------------------- If the responder's policy does not allow it to accept the entire set of traffic selectors in the initiator's request, but does allow him to accept the first selector of TSi and TSr, then the responder MUST narrow the traffic selectors to a subset that includes the initiator's first choices. In this example, the responder might respond with TSi being (192.0.1.43 - 192.0.1.43) with all ports and IP protocols. ---------------------------------------------------------------------- I.e. regardless wheather the first traffic selector item is from packet or not, it MUST be included in to the returned TS set. This is MUST, not SHOULD, so there is no other way to do that. This text does not say what to do if the initiators first traffic selector item is not completely allowed, but subset of it would be allowed. I would think that in that case the negotiation should fail with TS_UNACCEPTABLE. So if the initiator is creating the SA based on the policy not based on packet, and does not send TS items matching the packet, then the responder must still include the first TS item inside its narrowed selectors, i.e. it cannot narrow the first selector down at all. I.e. if initiator send TS 10.0.0.0-10.0.255.255, and responder has only 10.0.0.0-10.0.200.255 configured, then responder will return TS_UNACCEPTABLE. If responder has 10.0.0.0-10.255.255.255 configured, then it will return 10.0.0.0-10.0.255.255 back (i.e. no narrowing). I.e. in that case the policy must either match exactly or the responder must have wider policy. In most cases both ends will have same policy as this is statically configured vpn system. If the first packet is from packet it usually means that it is actually included to some other traffic selector too. I.e. initiator sends 10.0.0.1-10.0.0.1 proto y port x, and 10.0.0.0-10.0.0.255 proto any port any. Now if the responder have policy of 10.0.0.0-10.0.0.128 proto from packet port any, then he can return one TS of 10.0.0.0-10.0.0.128 proto x port any. That returned TS is subset of the union of all input TS items (actually subset of second TS item, but as the first TS item is subset of second their union is actually exactly same as second TS), and also the first TS item from the initiator is also included in this TS item. > This also allows an initiator to have some say in what the > negotiated TS will be. e.g. if a initiator supports only a single SA > for the entire subnet and does not want the responder to narrow the > TS, it currently cannot indicate this. Most SOHO VPN boxes only > support a few SAs and will be at the mercy of the responder to not > narrow down the policy. If the responder is configured to require separate SA for each port then there is nothing the initiator can do in the exchange. Their policies are simply not compatible with each other. > > > I think it is *way* too late for that for the current spec. There is > > no space currently in the headers for that. > > I agree it is way too late for such a change, however, if a change is > desired, space can be created in the TS header. Currently, the > "Selector Length" field is 16 bits. It could be reduced to 8 bits and 1 > bit out of the remaining 8 bits be used for this indication. This > leaves 7 bits for future expansion. All lengths inside the IKE payloads are 16 bits, and we might want to have TS type later having more than 256 bytes. It would be much easier to add a new TS type of TS_IPV4_PACKET and TS_IPV6 PACKET having format of: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! TS Type !IP Protocol ID | Selector Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ! ! ~ Address ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and use that to specify the information about the exact packet. But as said earlier, it is too late for this kind of changes. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Mar 3 12:51:58 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA24037 for ; Thu, 3 Mar 2005 12:51:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6uTF-0001Pg-S0; Thu, 03 Mar 2005 12:50:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6uTE-0001Pb-6s for ipsec@megatron.ietf.org; Thu, 03 Mar 2005 12:50:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23889 for ; Thu, 3 Mar 2005 12:50:41 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6uUc-0007C1-FE for ipsec@ietf.org; Thu, 03 Mar 2005 12:52:11 -0500 Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j23HoeXN046826 for ; Thu, 3 Mar 2005 09:50:41 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050303172555.GB10574@thunk.org> References: <892867B805D4DA42A1C48103BF4CFA5A0122B91D@EUR-MSG-20.europe.corp.microsoft .com> <16933.47504.763000.221233@gargle.gargle.HOWL> <20050303172555.GB10574@thunk.org> Date: Thu, 3 Mar 2005 09:50:42 -0800 To: ipsec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Ipsec] Re: Proposed Straw Poll X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org >PROPOSAL D: >----------- > >Make a clarification (that would go into Pasi's clarification >document) (I don't support D_1 or D_2 because there are literally at least two dozen other clarifications that are as important as this one; we can't even think of holding up the publication for them.) --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Mar 3 13:05:19 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25651 for ; Thu, 3 Mar 2005 13:05:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6ufB-0003ys-BX; Thu, 03 Mar 2005 13:03:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6uf9-0003yn-CT for ipsec@megatron.ietf.org; Thu, 03 Mar 2005 13:03:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25437 for ; Thu, 3 Mar 2005 13:03:00 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6ugY-0007Xc-BQ for ipsec@ietf.org; Thu, 03 Mar 2005 13:04:31 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j23I2tHa021762 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Mar 2005 20:02:55 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j23I2rja021759; Thu, 3 Mar 2005 20:02:54 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16935.20813.887829.57785@fireball.kivinen.iki.fi> Date: Thu, 3 Mar 2005 20:02:53 +0200 From: Tero Kivinen To: Yoav Nir Subject: Re: [Ipsec] SPD & IKE v2 In-Reply-To: References: <20050302205324.99785.qmail@web52501.mail.yahoo.com> <1109797975.8377.130.camel@thunk> <1109800976.8377.147.camel@thunk> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 11 min X-Total-Time: 10 min X-Spam-Score: 0.0 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Bill Sommerfeld , Paul Hoffman X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Yoav Nir writes: > On Mar 3, 2005, at 12:02 AM, Bill Sommerfeld wrote: > > > On Wed, 2005-03-02 at 16:43, Paul Hoffman wrote: > > > >> Further, the way the > >> document is worded, you are supposed to make the first selector for > >> the first packet *even if you don't want to actually have that flow*. > > > > why would you ask for an SA you didn't intend to use? > > You might want to do this for a remote client. The client has a > "Connect" button. The software has no way on knowing what the user is > going to do after clicking "Connect". If you press connect button the initiator is not requesting the SA due to the data packet, thus you do not send the packet specific data in the TS. The paragrap describing how to send the TS starts: ---------------------------------------------------------------------- To enable the responder to choose the appropriate range in this case, if the initiator has requested the SA due to a data packet, the initiator SHOULD include ... ---------------------------------------------------------------------- I.e. the SHOULD only matters if "the initiator has requested the SA due to a data packet". I think that SHOULD should be MUST instead of SHOULD, I do not really understand now why it is SHOULD as it does not cover this kind of "connect button" or "autostart" cases, thus there is no point of ever leaving that TS out. Anyways as it is SHOULD now, it will stay SHOULD, it is too late to change that. Note, that the section which says that responder MUST return TS which includes the the first TS from the initiator is NOT specific to this case. That MUST be followed always. I.e. responder do not have option to return TS which does not match the first TS completely. This actually solves those SOHO VPN users problem. They configure the TS to be "autostart", i.e. initiated from the beginning without data packet, and the first TS included is something that the responder must accept completely, or fail the negotiation. Of course it will still cause all the negotiations to fail if the responder is configured to only allow subset of the first TS. > In IKEv1 it would do only Phase 1. In IKEv2 you can't do only phase > 1, so you need to make some child SA in there. Why are you making the IKE SA if you do not intend to use it? > Making an SA for simple ICMP between the client and the gateway > (just one address and protocol in each TS) is one way. You could > also suggest the entire Internet (0.0.0.0-255.255.255.255) and have > the gateway narrow that to some range or bunch of ranges which may > or may not be useful later. In the case of a generic client I think > the latter approach is more appropriate, especially if it doesn't > have a matched policy with the gateway. Doing the whole thing with > the "Connect" button and 4-8 packets only to fail because the > gateway blocks ICMP is a bad idea. If you are doing the client, you should always include the entire internet as destination, and also for source unless you have IP address already configured. I.e. if you do not have IP address yet, you send TSi and TSr both to include full 0.0.0.0-255.255.255.255 and ::0-FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF, and allow the responder gateway to assign you both IPv4 and IPv6 addresses (using Configuration payload), and also narrow your TSi to only include IP addresses it assigned to you, and narrow TSr to include the IP-addresses which can be reaced through it. If you have IP-address already (statically configured), then you set your TSi to be exactly that, and still use full internet as TSr. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Mar 3 13:31:19 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27647 for ; Thu, 3 Mar 2005 13:31:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6v0E-0007Vj-4D; Thu, 03 Mar 2005 13:24:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6v0B-0007Ve-Fj for ipsec@megatron.ietf.org; Thu, 03 Mar 2005 13:24:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27025 for ; Thu, 3 Mar 2005 13:24:44 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6v1a-0007ye-OY for ipsec@ietf.org; Thu, 03 Mar 2005 13:26:15 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 03 Mar 2005 10:26:31 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,133,1107763200"; d="scan'208,217"; a="164879780:sNHT115674320" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j23IK1q8027387; Thu, 3 Mar 2005 10:20:01 -0800 (PST) Received: from [171.71.49.252] (dhcp-171-71-49-252.cisco.com [171.71.49.252]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BCK64704; Thu, 3 Mar 2005 10:20:05 -0800 (PST) Message-ID: <42275554.1070606@cisco.com> Date: Thu, 03 Mar 2005 10:20:04 -0800 From: Kevin Li User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen Subject: Re: [Ipsec] SPD & IKE v2 References: <20050302205324.99785.qmail@web52501.mail.yahoo.com> <1109797975.8377.130.camel@thunk> <1109800976.8377.147.camel@thunk> <16935.20813.887829.57785@fireball.kivinen.iki.fi> In-Reply-To: <16935.20813.887829.57785@fireball.kivinen.iki.fi> X-Spam-Score: 0.1 (/) X-Scan-Signature: 2086112c730e13d5955355df27e3074b Cc: ipsec@ietf.org, Bill Sommerfeld , Yoav Nir , Paul Hoffman X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1280221847==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1280221847== Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Why the initiator must/should have the first packet selector specifying first packet?
If initiator wants the first packet to be accepted by the responder, it could well be included in a TS range which he wants remote end to accept. There is no reason to extract this particular TS out from that range. If the remote end doesn't want to accept the traffic type in first packet according to its local policy, it will reject it any way either through TS_UNACCEPTIBLE or exclude that from the narrowing down TS.

Thanks.

Kevin

Tero Kivinen wrote: 
Yoav Nir writes:
  
On Mar 3, 2005, at 12:02 AM, Bill Sommerfeld wrote:

    
On Wed, 2005-03-02 at 16:43, Paul Hoffman wrote:

      
Further, the way the
document is worded, you are supposed to make the first selector for
the first packet *even if you don't want to actually have that flow*.
        
why would you ask for an SA you didn't intend to use?
      
You might want to do this for a remote client.  The client has a 
"Connect" button.  The software has no way on knowing what the user is 
going to do after clicking "Connect".
    

If you press connect button the initiator is not requesting the SA due
to the data packet, thus you do not send the packet specific data in
the TS.

The paragrap describing how to send the TS starts:
----------------------------------------------------------------------
   To enable the responder to choose the appropriate range in this case,
   if the initiator has requested the SA due to a data packet, the
   initiator SHOULD include ...
----------------------------------------------------------------------

I.e. the SHOULD only matters if "the initiator has requested the SA
due to a data packet".

I think that SHOULD should be MUST instead of SHOULD, I do not really
understand now why it is SHOULD as it does not cover this kind of
"connect button" or "autostart" cases, thus there is no point of ever
leaving that TS out.

Anyways as it is SHOULD now, it will stay SHOULD, it is too late to
change that.

Note, that the section which says that responder MUST return TS which
includes the the first TS from the initiator is NOT specific to this
case. That MUST be followed always. I.e. responder do not have option
to return TS which does not match the first TS completely.

This actually solves those SOHO VPN users problem. They configure the
TS to be "autostart", i.e. initiated from the beginning without data
packet, and the first TS included is something that the responder must
accept completely, or fail the negotiation. Of course it will still
cause all the negotiations to fail if the responder is configured to
only allow subset of the first TS.

  
In IKEv1 it would do only Phase 1. In IKEv2 you can't do only phase
1, so you need to make some child SA in there.
    

Why are you making the IKE SA if you do not intend to use it?

  
Making an SA for simple ICMP between the client and the gateway
(just one address and protocol in each TS) is one way. You could
also suggest the entire Internet (0.0.0.0-255.255.255.255) and have
the gateway narrow that to some range or bunch of ranges which may
or may not be useful later. In the case of a generic client I think
the latter approach is more appropriate, especially if it doesn't
have a matched policy with the gateway. Doing the whole thing with
the "Connect" button and 4-8 packets only to fail because the
gateway blocks ICMP is a bad idea.
    

If you are doing the client, you should always include the entire
internet as destination, and also for source unless you have IP
address already configured.

I.e. if you do not have IP address yet, you send TSi and TSr both to
include full 0.0.0.0-255.255.255.255 and
::0-FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF, and allow the responder
gateway to assign you both IPv4 and IPv6 addresses (using
Configuration payload), and also narrow your TSi to only include IP
addresses it assigned to you, and narrow TSr to include the
IP-addresses which can be reaced through it.

If you have IP-address already (statically configured), then you set
your TSi to be exactly that, and still use full internet as TSr.

--===============1280221847== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1280221847==-- From ipsec-bounces@ietf.org Thu Mar 3 13:41:21 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28865 for ; Thu, 3 Mar 2005 13:41:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6vEG-0001g5-PC; Thu, 03 Mar 2005 13:39:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6vEG-0001g0-18 for ipsec@megatron.ietf.org; Thu, 03 Mar 2005 13:39:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28527 for ; Thu, 3 Mar 2005 13:39:16 -0500 (EST) Received: from web52505.mail.yahoo.com ([206.190.39.126]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D6vFe-0008NZ-Nf for ipsec@ietf.org; Thu, 03 Mar 2005 13:40:48 -0500 Received: (qmail 63594 invoked by uid 60001); 3 Mar 2005 18:39:09 -0000 Message-ID: <20050303183909.63592.qmail@web52505.mail.yahoo.com> Received: from [69.233.57.195] by web52505.mail.yahoo.com via HTTP; Thu, 03 Mar 2005 10:39:09 PST Date: Thu, 3 Mar 2005 10:39:09 -0800 (PST) From: Saroop Mathur Subject: Re: [Ipsec] SPD & IKE v2 To: Tero Kivinen In-Reply-To: <16935.19802.411588.930940@fireball.kivinen.iki.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ipsec@ietf.org, Paul Hoffman X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --- Tero Kivinen wrote: > I.e. regardless wheather the first traffic selector item is from > packet or not, it MUST be included in to the returned TS set. This is > MUST, not SHOULD, so there is no other way to do that. This text does > not say what to do if the initiators first traffic selector item is > not completely allowed, but subset of it would be allowed. I would > think that in that case the negotiation should fail with > TS_UNACCEPTABLE. However, the very next paragraph states: ----------------------- If the initiator creates the CHILD_SA pair not in response to an arriving packet, but rather - say - upon startup, then there may be no specific addresses the initiator prefers for the initial tunnel over any other. In that case, the first values in TSi and TSr MAY be ranges rather than specific values, and the responder chooses a subset of the initiator's TSi and TSr that are acceptable. ------------------------ Hence the responder can narrow the first values in the TSi and TSr. -Saroop _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Mar 3 14:22:04 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03588 for ; Thu, 3 Mar 2005 14:22:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6vss-0001wL-Sh; Thu, 03 Mar 2005 14:21:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6vsr-0001wF-Pq for ipsec@megatron.ietf.org; Thu, 03 Mar 2005 14:21:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA03500 for ; Thu, 3 Mar 2005 14:21:16 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6vuG-00010q-Tg for ipsec@ietf.org; Thu, 03 Mar 2005 14:22:46 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j23JL4cw022378 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Mar 2005 21:21:04 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j23JL47E022375; Thu, 3 Mar 2005 21:21:04 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16935.25503.829410.831497@fireball.kivinen.iki.fi> Date: Thu, 3 Mar 2005 21:21:03 +0200 From: Tero Kivinen To: Stephen Kent Subject: Re: [Ipsec] SPD & IKE v2 In-Reply-To: References: <16933.41469.351149.32331@fireball.kivinen.iki.fi> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 61 min X-Total-Time: 77 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 83867a50fd8f547996ccdaf89af24437 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Stephen Kent writes: > We agree that if an initiator wants to send header data from a > triggering packet, then the data is sent as the first pair of entries Not "first pair" of entries. It says that in each of TSi and TSr the first traffic selector SHOULD be from packet. The document does not talk about them as pairs. The IKEv2 document does not refer items in TSi or TSr as pairs anywhere. > in the TSi/r payloads. In this case, it seems clear that the > semantics here is that these entries are paired, i.e., the responder > should interpret the pair of entries as representing the S/D address > and port data from the triggering packet. Do you agree? No. As there can be only one from packet item taken from the packet to be used in both TSi and TSr. We simply insert those specific items as a first items of the list of TSi and TSr. I do not think that makes items to be paired. The interpretation of pairs for all TSi and TSr items is entirely yours, and I cannot really see any support for that from the document. If we would consider them as pairs, why do we have two payloads then? It would be much better to define one TS payload having format: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! TS Type !IP Protocol ID*| Selector Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | initiator start port | initiator end port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | responder start port | responder end port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ initiator starting address ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ initiator ending address ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ responder startting address ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! ! ~ responder ending address ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ That would be much easier and would make it explicit that we are using them as pairs. We do not do that, and the reason is that we did want to say that all items inside the TSi are combined together (i.e. we take the union of all items), and any of them can be used as a initiator end selectors. And separately from that we take all items from the TSr and take the union of them and any of them can be used as a responder end selectors. > But, there is no flag that indicates whether the first entry is from > a triggering packet, not, as others have noted. Thus if the responder > always treats the first pair of TSi/r addresses & ports as matched, > which is the sensible interpretation when this first pair represents > triggering packet data, then it will do so even when the first pair > does NOT represent such data. So, why change the interpretation for > later pairs of S/D addresses & ports? The inclusion of the trigger packet data was added quite late, and we didn't want to change the format of the TS payloads at that point. That information was not there from the beginning, it was added around May 2002. Note also that the interpretation of the traffic selectors do not change depending if there is packet specific TS item or not. The first TS item in both TSi and TSr MUST be included in the narrowed reply of responder (always!). You could say that the first item in both lists is the most important TS item from the initiators point of view, and he does not even want to have an SA up if responder cannot include that first TS item. > I don't disagree that you can save space in IKE messages under some > circumstances by being able to associate one payload for one > direction with multiple ones for the other direction. However, if we > do not have a way to represent a one-to-one correspondence between > TSi and TSr values, then we cannot convey the semantics of the SPD, > and that is not OK. Yes, I agree that SPD currently does not match to the one what IKEv2 does. In my email <16399.12161.370070.285455@fireball.acr.fi> (http://www.vpnc.org/ietf-ipsec/mail-archive/msg00092.html) I tried to explain that: ---------------------------------------------------------------------- Also in the IKEv2 there is no construct of AddrList at all, we have two lists (source and destination) of Traffic Selectors (== SelectorSet), each having on start and end addresses (IPRange), and port range. Because in the IKEv2 we do have separate source and destination lists, it will remove the combinatory explosion, thus the same example can be expressed as (using the format described in the end of this email): ... Using same syntax the actual TrafficSelector which can be expressed in the IKEv2 is: SPD ::= SEQUENCE of SPDEntry -- List of SPD Entries SPDEntry ::= SEQUENCE { -- Each entry consist of source TrafficSelectorList, -- source and destination TrafficSelectorList } -- destination selectorlists TrafficSelectorList ::= SET OF TrafficSelector -- Each selectorList -- is list of selectors TrafficSelector ::= SEQUENCE { -- either source or -- destination selector Addr IPRange, protocol INTEGER, -- 8 bits next CHOICE { ports SEQUENCE { portStart INTEGER, -- 16 bits portEnd } INTEGER, -- 16 bits ICMP [0] SEQUENCE { typeStart INTEGER, -- 8 bits codeStart INTEGER, -- 8 bits typeEnd INTEGER, -- 8 bits codeEnd INTEGER } } } -- 8 bits IPRange ::= CHOICE { v4range SEQUENCE { start INTEGER, -- 32 bits end INTEGER } -- 32 bits v6range [0] SEQUENCE { start INTEGER, -- 128 bits end INTEGER } } -- 128 bits ---------------------------------------------------------------------- You replied in your email (http://www.vpnc.org/ietf-ipsec/mail-archive/msg00098.html) saying: ---------------------------------------------------------------------- >Also in the IKEv2 there is no construct of AddrList at all, we have >two lists (source and destination) of Traffic Selectors (== >SelectorSet), each having on start and end addresses (IPRange), and >port range. > >Because in the IKEv2 we do have separate source and destination lists, >it will remove the combinatory explosion, thus the same example can be >expressed as (using the format described in the end of this email): yes, but the SPD is also used to represent bypass and discard access controls. So, maybe we need to define two classes of entries, one for IPsec SA creation and one for bypass/discard, where the IKE selector payload conventions do not apply. Also, the PFP flag is not in this syntax, yet, and it does need to be in the syntax for the former class of SPD entries, even though it is not sent in the IKE payload. ... removed other discussion ... my version of ASN1 of SPD I like the more compact syntax, but we need to resolve the disagreement about the protocol field representation in IKE, and maybe adopt the conventions re ICMP type/code values. We also need text to accommodate the mobility header support. Plus, I need to add in the PFP flag, and create a separate entry type for bypass/discard. ---------------------------------------------------------------------- So that is the reason we have the more compact syntax which do not match the thing what IKEv2 does. > The example I gave, for the first set of values in TSi/r implies a > 1-to-1 (paired) matching in this case. It does not say word "pair" anywhere there. It says that both TSi and TSr lists will have the first entry from packet, it does not say anywhere that they are otherwise paired. > Also, the purpose of the IKE negotiation is to represent an SPD > entry to a peer. SPD entries, like analogous ACL entries, are > paired. Because we create pairs of SAs that represent traffic > bidirectional traffic flows that are common in the IP context, one > expresses ACLs in terms of these bidirectional flows. I assumed that rfc2401bis and IKEv2 were supposed to be aligned here. IKEv2 has been negotiating them mix and match all the time. I do not have any idea why we would like to have combinatory explosion of the TS payloads in case where you have 10 subnets in initiator end and 100 in the responders end. > The example you provide is a reasonable one, but it represents a very > simple case where the mix and match approach expresses the underlying > access control semantics. However, in the more general case, I may > want to express the notion that Host A in my net can be accesses by > Host B in your net and Host C in my net can be accessed by Host D in > your net, AND I want the traffic for both of these flows to be > carried via one SA. And that thing cannot be negotiated with IKEv2 with single SA. If you want that you need to request multiple SAs. > The SPD allows one to express this notion, and IKE needs to be able > to convey it. We cannot start doing big modifications to IKEv2 now. We already have implementations out there which are doing things as they are defined in the draft. You should have commented this year ago, when we discussed this on the list, and I pointed out that IKEv2 do use completely separate lists for TSi and TSr, and they are not paired together (as you can see from my ASN1, and from my comment about the combinatory explosion). > That is how firewalls express access control policy (modulo the use > of SAs) and the IPsec SPD is a standardized representation of such > an access control policy. The "modulo the use of SA" is very important difference here. SPD and IKEv2 are aligned already now with module the number of SAs used. We can always convert paired SPD list to multiple IKEv2 exchanges and create multiple SAs from them. This will satisfy the SPD firewall access control policy requirements. The other way is not true, if you do not allow mix and match you might end up in combinatory explosion which makes the UDP packet too big to be able passed through the net. We tried hard to make the UDP packets small, and remove all combinatory explosions we found, and this was one of them. > I agree that we should minimize combinatorial explosion, but the SPD > is a local representation of access control policy and one cannot > express the sort of constraints that may be necessary if the TS > proposals are treated as your suggest. I do not understand why not? The only difference there is weather you can negotiate it with one exchange in the IKEv2 and create one SA or not. You can take the paired output and create separate SAs for each pairs, if it really is important not to allow mix and match. I think in most cases the mix and match is much more common case than the paired case (i.e initiator have few IP-addresses, and responder have few subnets). This is especially true in the IPv6 environment or mixed IPv4 and IPv6 environment. > IKE could have a different structure for the TS proposals, one that > would satisfy both goals. It could allow for compact representation > of the cases where one wants to list only selector range for one > direction and bind multiple ranges to the other direction. But, we > do not have that and I sense a lot of resistance to making a change > of this sort at this point in time. We can still change rfc2401bis. We cannot really change IKEv2. IKEv2 does not say anything about TSs to be paired, and the intention was them to be mix and match. The ASN1 SPD is just example, so it is not normative. Is there any text in the rfc2401bis which says that you must be able to create non mix-and-match policies using exactly one SA (instead of creating separate SA for each of them). > I'm afraid you have this backwards :-) IKEv2 was finished first and approved, so I assumed that was ok for everybody, and we still want SPD and IKEv2 to align, so that leaves us the choices to modify SPD :-) > I have said that we tried to work to align the SPD and IKE, so that > we could negotiate in IKE what the SPD expresses. We had mismatches > in 2401bis vs. IKE v1 in that we could express things in the SPD that > IKE could not negotiate. While it is true that I have said that we > wanted to make sure that IKE v2 and 2401bis are aligned, there is a > priority here, i.e., 2401bis specifies access control policies and > IKE v2 exists to negotiate SAs consistent with these policies, not > the other way around. IKEv2 can negotiate that kind of non mix and match policies without any problem, but it will need to create separate SA for each of them. Do you really see that as a problem? It do cause more packets to be send through the network, and more SAs to be created, but the things will work and implementations will be interoperable. On the other hand if we allow combinatory explosion of TS items then IKEv2 packets might be disappearing because they are simply too big. That will not work, and it will cause problems in the real world uses. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Mar 3 14:28:09 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04278 for ; Thu, 3 Mar 2005 14:28:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6vxZ-0002tb-8D; Thu, 03 Mar 2005 14:26:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6vxX-0002tS-H3 for ipsec@megatron.ietf.org; Thu, 03 Mar 2005 14:26:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA04137 for ; Thu, 3 Mar 2005 14:26:06 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6vyx-00018i-GY for ipsec@ietf.org; Thu, 03 Mar 2005 14:27:35 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j23JPxiC022456 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Mar 2005 21:25:59 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j23JPx94022453; Thu, 3 Mar 2005 21:25:59 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16935.25798.914269.536471@fireball.kivinen.iki.fi> Date: Thu, 3 Mar 2005 21:25:58 +0200 From: Tero Kivinen To: Stephen Kent Subject: Re: [Ipsec] SPD & IKE v2 In-Reply-To: References: <20050302203511.75886.qmail@web90001.mail.scd.yahoo.com> <01d901c51f87$ada89600$4205010a@subha> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 4 min X-Total-Time: 3 min X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Stephen Kent writes: > So we have a few options of how to address this problem: Good summary. > 2. require 1-to-1 matching of IKE payloads, to allow > representation of SPD semantics. this does not change IKE syntax, but > does change IKE processing rules, and can result in growth in the > size of IKE messages in certain contexts, with attendant > fragmentation concerns. This will break already existing implementations. There are people who have started implementing the IKEv2 as it is in the rfc-editor queue... > 3. change the SPD syntax and semantics to accommodate the > limitations of the IKE syntax. this will cause multiple SAs to be > created in some contexts, where the current semantics would allow > multiple traffic flows to be carried via a single SA. > > if we do not go with #1, then we have a tradeoff: we can create > bigger proposals (#2) or create more SAs (#3) each undesirable > outcome arising under certain conditions. We cannot go with #1. The tradeoff between #2 and #3 is: #2 => sometimes the negotiations with certain policy will fail #3 => everything works, but we create more SAs I think getting working protocol is more important than creating minimalistic number of SAs. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Mar 3 14:53:08 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06724 for ; Thu, 3 Mar 2005 14:53:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6wMy-0007KX-4o; Thu, 03 Mar 2005 14:52:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6wMv-0007KS-RE for ipsec@megatron.ietf.org; Thu, 03 Mar 2005 14:52:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06676 for ; Thu, 3 Mar 2005 14:52:20 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6wOM-0001jQ-2K for ipsec@ietf.org; Thu, 03 Mar 2005 14:53:50 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j23JqJSD022841 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Mar 2005 21:52:19 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j23JqI4n022838; Thu, 3 Mar 2005 21:52:18 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16935.27378.504459.724434@fireball.kivinen.iki.fi> Date: Thu, 3 Mar 2005 21:52:18 +0200 From: Tero Kivinen To: "Theodore Ts'o" Subject: [Ipsec] Proposed Straw Poll In-Reply-To: <20050303172555.GB10574@thunk.org> References: <892867B805D4DA42A1C48103BF4CFA5A0122B91D@EUR-MSG-20.europe.corp.microsoft.com> <16933.47504.763000.221233@gargle.gargle.HOWL> <20050303172555.GB10574@thunk.org> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 5 min X-Total-Time: 4 min X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Paul Hoffman X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Theodore Ts'o writes: > A number of people have suggested just doing a clarification, although > there were also a number of people who suggested making ESN's > mandatory (Suggestion C). Some of these discussions were done while > the discussion was still going on, however, so I'd like for us to do a > quick straw poll so that people can clearly register their > preferences. I still think the C is the best one. > PROPOSAL D: > ----------- > > Make a clarification (that would go into Pasi's clarification > document) that would add a sentence to the end of Section 3.3.2 that > says "Note that if the initiator is willing to accept either the use > of extended sequence numbers or not, the initiator SHOULD send this > transform in its proposals." I do not think that clarification helps at all. It does not really clarify the situation at all. Making the option mandatory fixes the problem as there is no default value after that, and it can also be made in the backward compatible way (i.e. if no value then assume ESN is enabled). -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Mar 3 15:01:59 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07582 for ; Thu, 3 Mar 2005 15:01:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6wTp-00007c-D2; Thu, 03 Mar 2005 14:59:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6wTo-00007X-F3 for ipsec@megatron.ietf.org; Thu, 03 Mar 2005 14:59:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07220 for ; Thu, 3 Mar 2005 14:59:26 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6wVE-0001uK-HW for ipsec@ietf.org; Thu, 03 Mar 2005 15:00:57 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j23JxQrs022867 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Mar 2005 21:59:26 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j23JxPWo022864; Thu, 3 Mar 2005 21:59:25 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16935.27805.750529.611059@fireball.kivinen.iki.fi> Date: Thu, 3 Mar 2005 21:59:25 +0200 From: Tero Kivinen To: Saroop Mathur Subject: Re: [Ipsec] SPD & IKE v2 In-Reply-To: <20050303183909.63592.qmail@web52505.mail.yahoo.com> References: <16935.19802.411588.930940@fireball.kivinen.iki.fi> <20050303183909.63592.qmail@web52505.mail.yahoo.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 3 min X-Total-Time: 2 min X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Paul Hoffman X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Saroop Mathur writes: > > --- Tero Kivinen wrote: > > > I.e. regardless wheather the first traffic selector item is from > > packet or not, it MUST be included in to the returned TS set. This is > > MUST, not SHOULD, so there is no other way to do that. This text does > > not say what to do if the initiators first traffic selector item is > > not completely allowed, but subset of it would be allowed. I would > > think that in that case the negotiation should fail with > > TS_UNACCEPTABLE. > > However, the very next paragraph states: > ----------------------- > If the initiator creates the CHILD_SA pair not in response to an > arriving packet, but rather - say - upon startup, then there may be > no specific addresses the initiator prefers for the initial tunnel > over any other. In that case, the first values in TSi and TSr MAY > be > ranges rather than specific values, and the responder chooses a > subset of the initiator's TSi and TSr that are acceptable. > ------------------------ > > Hence the responder can narrow the first values in the TSi and TSr. Hmm... true, didn't read it that far now, and didn't remember there was that text there. I would say that this MAY actually conflicts with the MUST in the previous paragraph, or is the implicit "if the initiator has requested the SA due to a data packet" added to the beginning of that paragraph too? If so we end up problems as responder cannot know wheather the SA was requested due to a data packet. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Mar 3 18:45:07 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29835 for ; Thu, 3 Mar 2005 18:45:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6zw0-0002e9-27; Thu, 03 Mar 2005 18:40:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6zvy-0002e1-E4 for ipsec@megatron.ietf.org; Thu, 03 Mar 2005 18:40:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29492 for ; Thu, 3 Mar 2005 18:40:43 -0500 (EST) From: vjyothi@intoto.com Received: from [207.145.48.18] (helo=smtp.intoto.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D6zxP-0006da-Nt for ipsec@ietf.org; Thu, 03 Mar 2005 18:42:17 -0500 Received: from not-angel.intoto.com ([66.80.10.146]) by smtp.intoto.com (SMSSMTP 4.0.0.59) with SMTP id M2005030315400010319 for ; Thu, 03 Mar 2005 15:40:00 -0800 Received: from webmail.intoto.com (intoto.com [207.145.48.21]) (authenticated bits=0) by not-angel.intoto.com (8.13.1/8.13.1) with ESMTP id j23NeQu7019324 for ; Thu, 3 Mar 2005 15:40:26 -0800 Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146]) (SquirrelMail authenticated user vjyothi); by webmail.intoto.com with HTTP; Thu, 3 Mar 2005 15:40:26 -0800 (PST) Message-ID: <23701.66.80.10.146.1109893226.squirrel@66.80.10.146> In-Reply-To: <1109802474.8377.156.camel@thunk> References: <20050302205324.99785.qmail@web52501.mail.yahoo.com> <1109797975.8377.130.camel@thunk> <1109800976.8377.147.camel@thunk> <1109802474.8377.156.camel@thunk> Date: Thu, 3 Mar 2005 15:40:26 -0800 (PST) To: ipsec@ietf.org User-Agent: SquirrelMail/1.4.3a X-Mailer: SquirrelMail/1.4.3a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 0.3 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 8bit Subject: [Ipsec] message IDs and window size in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 8bit Hi all, I have some issues regarding the message ID in IKE header and window size in IKEv2. My understanding from the IKEv2 draft regarding message IDs is: 1. Requests has to be sent by incrementing message ID 2. Receiver must accept all the messages of window size, then only it should move its current accepted message ID. Suppose the window size is 2 and the current message ID is 2. and the sender starts sending two CREATE_CHILD_SA exchange requests of message IDs 3 and 4. May be due to some problem, receiver did not receive the message of message ID 3. Should the receiver accept the messages of message IDs 5 and 6 which fall outside the window?? My feeling is that it SHOULD accept the messages because the message IDs are authenticated. Even if the message id received is very big and falls outside the window, it SHOULD be accepted. Thanks, Jyothi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Mar 4 01:13:33 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01220 for ; Fri, 4 Mar 2005 01:13:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7611-0000C9-VN; Fri, 04 Mar 2005 01:10:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D760x-0000By-Oa for ipsec@megatron.ietf.org; Fri, 04 Mar 2005 01:10:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00597 for ; Fri, 4 Mar 2005 01:10:18 -0500 (EST) Received: from jaguar.gov.yk.ca ([199.247.128.32]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D762O-0005tC-NG for ipsec@ietf.org; Fri, 04 Mar 2005 01:11:53 -0500 Received: (qmail 18262 invoked by uid 0); 4 Mar 2005 06:40:20 -0000 Message-ID: <20050304064020.18261.qmail@jaguar.gov.yk.ca> X-Mozilla-Status: 0010 X-Mozilla-Status2: 00000000 Received: from cerberus.YNet.gov.yk.ca ([199.247.130.30]) by raptor.YNet.gov.yk.ca with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Mar 2005 00:59:59 -0800 Received: from Unknown [199.247.128.31] by cerberus.YNet.gov.yk.ca - SurfControl E-mail Filter (4.7); Thu, 03 Mar 2005 00:59:58 -0800 MIME-Version: 1.0 Received: (qmail 19385 invoked by uid 507); 3 Mar 2005 08:59:57 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Received: from 132.151.6.71 by spitfire.gov.yk.ca (envelope-from , uid 500) with qmail-scanner-1.24 (clamdscan: 0.80/653. Clear:RC:0(132.151.6.71):. Processed in 0.207472 secs); 03 Mar 2005 08:59:57 -0000 Received: from megatron.ietf.org (132.151.6.71) by spitfire.gov.yk.ca with SMTP; 3 Mar 2005 08:59:57 -0000 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6mB2-00064T-JC; Thu, 03 Mar 2005 03:59:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6mAy-00063u-A6 for ipsec@megatron.ietf.org; Thu, 03 Mar 2005 03:59:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA22801 for ; Thu, 3 Mar 2005 03:59:18 -0500 (EST) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6mCH-0001ZP-9f for ipsec@ietf.org; Thu, 03 Mar 2005 04:00:42 -0500 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.7p1+Sun/8.11.6) with ESMTP id j238x2309692; Thu, 3 Mar 2005 10:59:03 +0200 (IST) Content-class: urn:content-classes:message Subject: Re: [Ipsec] SPD & IKE v2 Date: Thu, 3 Mar 2005 00:59:01 -0800 Thread-Topic: [Ipsec] SPD & IKE v2 Thread-Index: AcUfz2Co/s6eU95ZR3mgkt0MVt9lvg== From: "Yoav Nir" To: "Bill Sommerfeld" X-Spam-Score: 1.2 (+) X-Scan-Signature: dbb8771284c7a36189745aa720dc20ab Cc: ipsec@ietf.org, Paul Hoffman X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0412310274==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0412310274== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C51FCF.60A45180" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C51FCF.60A45180 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable On Mar 3, 2005, at 12:02 AM, Bill Sommerfeld wrote: > On Wed, 2005-03-02 at 16:43, Paul Hoffman wrote: > >> Further, the way the >> document is worded, you are supposed to make the first selector for >> the first packet *even if you don't want to actually have that flow*. > > why would you ask for an SA you didn't intend to use? You might want to do this for a remote client. The client has a=20 "Connect" button. The software has no way on knowing what the user is=20 going to do after clicking "Connect". In IKEv1 it would do only Phase=20 1. In IKEv2 you can't do only phase 1, so you need to make some child=20 SA in there. Making an SA for simple ICMP between the client and the=20 gateway (just one address and protocol in each TS) is one way. You=20 could also suggest the entire Internet (0.0.0.0-255.255.255.255) and=20 have the gateway narrow that to some range or bunch of ranges which may=20 or may not be useful later. In the case of a generic client I think=20 the latter approach is more appropriate, especially if it doesn't have=20 a matched policy with the gateway. Doing the whole thing with the=20 "Connect" button and 4-8 packets only to fail because the gateway=20 blocks ICMP is a bad idea. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------_=_NextPart_001_01C51FCF.60A45180 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Ipsec] SPD & IKE v2

On Mar 3, 2005, at 12:02 AM, Bill Sommerfeld = wrote:

> On Wed, 2005-03-02 at 16:43, Paul Hoffman = wrote:
>
>> Further, the way the
>> document is worded, you are supposed to make = the first selector for
>> the first packet *even if you don't want to = actually have that flow*.
>
> why would you ask for an SA you didn't intend to = use?

You might want to do this for a remote client.  = The client has a
"Connect" button.  The software has no = way on knowing what the user is
going to do after clicking "Connect".  = In IKEv1 it would do only Phase
1.  In IKEv2 you can't do only phase 1, so you = need to make some child
SA in there.  Making an SA for simple ICMP = between the client and the
gateway (just one address and protocol in each TS) is = one way.  You
could also suggest the entire Internet = (0.0.0.0-255.255.255.255) and
have the gateway narrow that to some range or bunch = of ranges which may
or may not be useful later.  In the case of a = generic client I think
the latter approach is more appropriate, especially = if it doesn't have
a matched policy with the gateway.  Doing the = whole thing with the
"Connect" button and 4-8 packets only to = fail because the gateway
blocks ICMP is a bad idea.



_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/ipsec

------_=_NextPart_001_01C51FCF.60A45180-- --===============0412310274== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0412310274==-- From ipsec-bounces@ietf.org Fri Mar 4 01:15:29 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01676 for ; Fri, 4 Mar 2005 01:15:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D75zG-0008Pk-TD; Fri, 04 Mar 2005 01:08:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D75zD-0008Pa-GM for ipsec@megatron.ietf.org; Fri, 04 Mar 2005 01:08:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00360 for ; Fri, 4 Mar 2005 01:08:30 -0500 (EST) Received: from jaguar.gov.yk.ca ([199.247.128.32]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D760i-0005p1-F6 for ipsec@ietf.org; Fri, 04 Mar 2005 01:10:05 -0500 Received: (qmail 15710 invoked by uid 0); 4 Mar 2005 06:39:01 -0000 Message-ID: <20050304063901.15709.qmail@jaguar.gov.yk.ca> X-Mozilla-Status: 0010 X-Mozilla-Status2: 00000000 Received: from cerberus.YNet.gov.yk.ca ([199.247.130.30]) by raptor.YNet.gov.yk.ca with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Mar 2005 10:04:33 -0800 Received: from Unknown [199.247.128.31] by cerberus.YNet.gov.yk.ca - SurfControl E-mail Filter (4.7); Thu, 03 Mar 2005 10:04:12 -0800 MIME-Version: 1.0 Received: (qmail 11507 invoked by uid 507); 3 Mar 2005 18:04:11 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Received: from 132.151.6.71 by spitfire.gov.yk.ca (envelope-from , uid 500) with qmail-scanner-1.24 (clamdscan: 0.80/653. Clear:RC:0(132.151.6.71):. Processed in 0.447995 secs); 03 Mar 2005 18:04:11 -0000 Received: from megatron.ietf.org (132.151.6.71) by spitfire.gov.yk.ca with SMTP; 3 Mar 2005 18:04:11 -0000 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6ufB-0003ys-8O; Thu, 03 Mar 2005 13:03:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6uf9-0003yn-CT for ipsec@megatron.ietf.org; Thu, 03 Mar 2005 13:03:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25437 for ; Thu, 3 Mar 2005 13:03:00 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6ugY-0007Xc-BQ for ipsec@ietf.org; Thu, 03 Mar 2005 13:04:31 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j23I2tHa021762 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Mar 2005 20:02:55 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j23I2rja021759; Thu, 3 Mar 2005 20:02:54 +0200 (EET) Content-class: urn:content-classes:message Subject: Re: [Ipsec] SPD & IKE v2 Date: Thu, 3 Mar 2005 10:02:53 -0800 Thread-Topic: [Ipsec] SPD & IKE v2 Thread-Index: AcUgG3P0po83rxXmSJ6ZOb1UU7iTpw== From: "Tero Kivinen" To: "Yoav Nir" X-Spam-Score: 1.2 (+) X-Scan-Signature: 3b8eea209b62bd15620865bc4fbef8cd Cc: ipsec@ietf.org, Bill Sommerfeld , Paul Hoffman X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1023034855==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1023034855== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5201B.73DD0E80" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C5201B.73DD0E80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yoav Nir writes: > On Mar 3, 2005, at 12:02 AM, Bill Sommerfeld wrote: >=20 > > On Wed, 2005-03-02 at 16:43, Paul Hoffman wrote: > > > >> Further, the way the > >> document is worded, you are supposed to make the first selector for > >> the first packet *even if you don't want to actually have that = flow*. > > > > why would you ask for an SA you didn't intend to use? >=20 > You might want to do this for a remote client. The client has a=20 > "Connect" button. The software has no way on knowing what the user is = > going to do after clicking "Connect". If you press connect button the initiator is not requesting the SA due to the data packet, thus you do not send the packet specific data in the TS. The paragrap describing how to send the TS starts: ---------------------------------------------------------------------- To enable the responder to choose the appropriate range in this case, if the initiator has requested the SA due to a data packet, the initiator SHOULD include ... ---------------------------------------------------------------------- I.e. the SHOULD only matters if "the initiator has requested the SA due to a data packet". I think that SHOULD should be MUST instead of SHOULD, I do not really understand now why it is SHOULD as it does not cover this kind of "connect button" or "autostart" cases, thus there is no point of ever leaving that TS out. Anyways as it is SHOULD now, it will stay SHOULD, it is too late to change that. Note, that the section which says that responder MUST return TS which includes the the first TS from the initiator is NOT specific to this case. That MUST be followed always. I.e. responder do not have option to return TS which does not match the first TS completely. This actually solves those SOHO VPN users problem. They configure the TS to be "autostart", i.e. initiated from the beginning without data packet, and the first TS included is something that the responder must accept completely, or fail the negotiation. Of course it will still cause all the negotiations to fail if the responder is configured to only allow subset of the first TS. > In IKEv1 it would do only Phase 1. In IKEv2 you can't do only phase > 1, so you need to make some child SA in there. Why are you making the IKE SA if you do not intend to use it? > Making an SA for simple ICMP between the client and the gateway > (just one address and protocol in each TS) is one way. You could > also suggest the entire Internet (0.0.0.0-255.255.255.255) and have > the gateway narrow that to some range or bunch of ranges which may > or may not be useful later. In the case of a generic client I think > the latter approach is more appropriate, especially if it doesn't > have a matched policy with the gateway. Doing the whole thing with > the "Connect" button and 4-8 packets only to fail because the > gateway blocks ICMP is a bad idea. If you are doing the client, you should always include the entire internet as destination, and also for source unless you have IP address already configured. I.e. if you do not have IP address yet, you send TSi and TSr both to include full 0.0.0.0-255.255.255.255 and ::0-FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF, and allow the responder gateway to assign you both IPv4 and IPv6 addresses (using Configuration payload), and also narrow your TSi to only include IP addresses it assigned to you, and narrow TSr to include the IP-addresses which can be reaced through it. If you have IP-address already (statically configured), then you set your TSi to be exactly that, and still use full internet as TSr.=20 --=20 kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------_=_NextPart_001_01C5201B.73DD0E80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Ipsec] SPD & IKE v2

Yoav Nir writes:
> On Mar 3, 2005, at 12:02 AM, Bill Sommerfeld = wrote:
>
> > On Wed, 2005-03-02 at 16:43, Paul Hoffman = wrote:
> >
> >> Further, the way the
> >> document is worded, you are supposed to = make the first selector for
> >> the first packet *even if you don't = want to actually have that flow*.
> >
> > why would you ask for an SA you didn't = intend to use?
>
> You might want to do this for a remote = client.  The client has a
> "Connect" button.  The software = has no way on knowing what the user is
> going to do after clicking = "Connect".

If you press connect button the initiator is not = requesting the SA due
to the data packet, thus you do not send the packet = specific data in
the TS.

The paragrap describing how to send the TS = starts:
----------------------------------------------------------------= ------
   To enable the responder to choose the = appropriate range in this case,
   if the initiator has requested the SA = due to a data packet, the
   initiator SHOULD include ...
----------------------------------------------------------------= ------

I.e. the SHOULD only matters if "the initiator = has requested the SA
due to a data packet".

I think that SHOULD should be MUST instead of SHOULD, = I do not really
understand now why it is SHOULD as it does not cover = this kind of
"connect button" or "autostart" = cases, thus there is no point of ever
leaving that TS out.

Anyways as it is SHOULD now, it will stay SHOULD, it = is too late to
change that.

Note, that the section which says that responder MUST = return TS which
includes the the first TS from the initiator is NOT = specific to this
case. That MUST be followed always. I.e. responder do = not have option
to return TS which does not match the first TS = completely.

This actually solves those SOHO VPN users problem. = They configure the
TS to be "autostart", i.e. initiated from = the beginning without data
packet, and the first TS included is something that = the responder must
accept completely, or fail the negotiation. Of course = it will still
cause all the negotiations to fail if the responder = is configured to
only allow subset of the first TS.

> In IKEv1 it would do only Phase 1. In IKEv2 you = can't do only phase
> 1, so you need to make some child SA in = there.

Why are you making the IKE SA if you do not intend to = use it?

> Making an SA for simple ICMP between the client = and the gateway
> (just one address and protocol in each TS) is = one way. You could
> also suggest the entire Internet = (0.0.0.0-255.255.255.255) and have
> the gateway narrow that to some range or bunch = of ranges which may
> or may not be useful later. In the case of a = generic client I think
> the latter approach is more appropriate, = especially if it doesn't
> have a matched policy with the gateway. Doing = the whole thing with
> the "Connect" button and 4-8 packets = only to fail because the
> gateway blocks ICMP is a bad idea.

If you are doing the client, you should always include = the entire
internet as destination, and also for source unless = you have IP
address already configured.

I.e. if you do not have IP address yet, you send TSi = and TSr both to
include full 0.0.0.0-255.255.255.255 and
::0-FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF, and = allow the responder
gateway to assign you both IPv4 and IPv6 addresses = (using
Configuration payload), and also narrow your TSi to = only include IP
addresses it assigned to you, and narrow TSr to = include the
IP-addresses which can be reaced through it.

If you have IP-address already (statically = configured), then you set
your TSi to be exactly that, and still use full = internet as TSr.
--
kivinen@safenet-inc.com

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/ipsec

------_=_NextPart_001_01C5201B.73DD0E80-- --===============1023034855== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1023034855==-- From ipsec-bounces@ietf.org Fri Mar 4 01:19:51 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02677 for ; Fri, 4 Mar 2005 01:19:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D75z3-0008Ma-Mk; Fri, 04 Mar 2005 01:08:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D75yy-0008MN-FW for ipsec@megatron.ietf.org; Fri, 04 Mar 2005 01:08:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00344 for ; Fri, 4 Mar 2005 01:08:14 -0500 (EST) Received: from jaguar.gov.yk.ca ([199.247.128.32]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D760S-0005oV-0k for ipsec@ietf.org; Fri, 04 Mar 2005 01:09:49 -0500 Received: (qmail 15287 invoked by uid 0); 4 Mar 2005 06:38:47 -0000 Message-ID: <20050304063847.15285.qmail@jaguar.gov.yk.ca> X-Mozilla-Status: 0000 X-Mozilla-Status2: 00000000 Received: from cerberus.YNet.gov.yk.ca ([199.247.130.30]) by raptor.YNet.gov.yk.ca with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Mar 2005 09:27:33 -0800 Received: from Unknown [199.247.128.31] by cerberus.YNet.gov.yk.ca - SurfControl E-mail Filter (4.7); Thu, 03 Mar 2005 09:27:32 -0800 MIME-Version: 1.0 Received: (qmail 29293 invoked by uid 507); 3 Mar 2005 17:27:32 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Received: from 132.151.6.71 by spitfire.gov.yk.ca (envelope-from , uid 500) with qmail-scanner-1.24 (clamdscan: 0.80/653. Clear:RC:0(132.151.6.71):. Processed in 0.408997 secs); 03 Mar 2005 17:27:32 -0000 Received: from megatron.ietf.org (132.151.6.71) by spitfire.gov.yk.ca with SMTP; 3 Mar 2005 17:27:31 -0000 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6u5N-0004WL-LC; Thu, 03 Mar 2005 12:26:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6u5K-0004Vq-Vu for ipsec@megatron.ietf.org; Thu, 03 Mar 2005 12:26:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20915 for ; Thu, 3 Mar 2005 12:25:59 -0500 (EST) Received: from thunk.org ([69.25.196.29] helo=thunker.thunk.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6u6i-0006SK-4z for ipsec@ietf.org; Thu, 03 Mar 2005 12:27:29 -0500 Received: from root (helo=thunk.org) by thunker.thunk.org with local-esmtp (Exim 3.35 #1 (Debian)) id 1D6u5E-000142-00; Thu, 03 Mar 2005 12:25:56 -0500 Received: from tytso by thunk.org with local (Exim 4.50) id 1D6u5D-0002lx-HZ; Thu, 03 Mar 2005 12:25:55 -0500 Content-class: urn:content-classes:message Subject: [Ipsec] Proposed Straw Poll Date: Thu, 3 Mar 2005 09:25:55 -0800 Thread-Topic: [Ipsec] Proposed Straw Poll Thread-Index: AcUgFkkxnN4H8r5yRMmI4BaQs0ZpKQ== From: "Theodore Ts'o" To: "Paul Hoffman" X-Spam-Score: 1.6 (+) X-Scan-Signature: cbb41f2dbf0f142369614756642005e3 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="===============1040396477==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1040396477== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C52016.48A3F080" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C52016.48A3F080 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable A number of people have suggested just doing a clarification, although there were also a number of people who suggested making ESN's mandatory (Suggestion C). Some of these discussions were done while the discussion was still going on, however, so I'd like for us to do a quick straw poll so that people can clearly register their preferences. At this point, I believe this is would be a correct description of the question at hand. Do people agree this is the proper way to pose the question before we start the straw poll? - Ted -------------------- Issue: If a receiver doesn't support ESN, they require the sender to send an ESN transform Some systems know that they don't support ESN, and therefore they require the other side to actively say they won't expect it. The only way for the other side to do so is for it to send a Transform Type 5 with a value of 0. However, there is no way for the responder to say that to the initiator, so interoperability is not possible. There are four ways that have been discussed to resolve this issue: PROPOSAL A: ----------- The last sentence of 3.3.2 says: If Transform Type 5 is not included in a proposal, use of Extended Sequence Numbers is assumed. Replace this with: If Transform Type 5 is not included in a proposal, it is assumed that the sending party does not support Extended Sequence Numbers. PROPOSAL B: ----------- Create a new response notification that says "I can't do ESN, start again and include a 'no ESN' transform." [Note during the discussion on the mailig list, little or no support was seen for this alternative. PROPOSAL C: ----------- Change the places that says Transform Type 5 is optional to say it is mandatory. PROPOSAL D:=20 ----------- Make a clarification (that would go into Pasi's clarification document) that would add a sentence to the end of Section 3.3.2 that says "Note that if the initiator is willing to accept either the use of extended sequence numbers or not, the initiator SHOULD send this transform in its proposals." PROPOSAL D_1: ------------- Do suggestion D above, but place the clarification in IKEv2. PROPOSAL D_2: ------------- Do Suggestion D_1 only if it can be done without delaying the publication of IKEv2. =20 Please select one of proposals A, B, C, D. If proposal D is selected, please note if you support D_1 or D_2. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------_=_NextPart_001_01C52016.48A3F080 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Ipsec] Proposed Straw Poll

A number of people have suggested just doing a = clarification, although
there were also a number of people who suggested = making ESN's
mandatory (Suggestion C).  Some of these = discussions were done while
the discussion was still going on, however, so I'd = like for us to do a
quick straw poll so that people can clearly register = their
preferences.

At this point, I believe this is would be a correct = description of the
question at hand.  Do people agree this is the = proper way to pose the
question before we start the straw poll?

        =         =         =         =         =         - Ted

--------------------

Issue: If a receiver doesn't support ESN, they require = the sender
to send an ESN transform

Some systems know that they don't support ESN, and = therefore they
require the other side to actively say they won't = expect it. The only
way for the other side to do so is for it to send a = Transform Type
5 with a value of 0. However, there is no way for the = responder to
say that to the initiator, so interoperability is not = possible.

There are four ways that have been discussed to = resolve this issue:

PROPOSAL A:
-----------

The last sentence of 3.3.2 says:
          If = Transform Type 5 is not included in a proposal, use of
          Extended = Sequence Numbers is assumed.
Replace this with:
          If = Transform Type 5 is not included in a proposal, it is
          assumed = that the sending party does not support Extended
          Sequence = Numbers.

PROPOSAL B:
-----------

Create a new response notification that says "I = can't do ESN, start
again and include a 'no ESN' transform."  = [Note during the discussion
on the mailig list, little or no support was seen for = this
alternative.

PROPOSAL C:
-----------

Change the places that says Transform Type 5 is = optional to say
it is mandatory.

PROPOSAL D:
-----------

Make a clarification (that would go into Pasi's = clarification
document) that would add a sentence to the end of = Section 3.3.2 that
says "Note that if the initiator is willing to = accept either the use
of extended sequence numbers or not, the initiator = SHOULD send this
transform in its proposals."

        PROPOSAL = D_1:
        -------------
        Do = suggestion D above, but place the clarification in IKEv2.

        PROPOSAL = D_2:
        -------------
        Do = Suggestion D_1 only if it can be done without delaying the
        publication of IKEv2. 


Please select one of proposals A, B, C, D.  If = proposal D is selected,
please note if you support D_1 or D_2.


_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/ipsec

------_=_NextPart_001_01C52016.48A3F080-- --===============1040396477== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1040396477==-- From ipsec-bounces@ietf.org Fri Mar 4 01:20:02 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02710 for ; Fri, 4 Mar 2005 01:20:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7640-0000mv-7B; Fri, 04 Mar 2005 01:13:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D763w-0000lo-2o for ipsec@megatron.ietf.org; Fri, 04 Mar 2005 01:13:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01195 for ; Fri, 4 Mar 2005 01:13:23 -0500 (EST) Received: from jaguar.gov.yk.ca ([199.247.128.32]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D765M-000636-WF for ipsec@ietf.org; Fri, 04 Mar 2005 01:14:58 -0500 Received: (qmail 21416 invoked by uid 0); 4 Mar 2005 06:43:58 -0000 Message-ID: <20050304064358.21415.qmail@jaguar.gov.yk.ca> X-Mozilla-Status: 0010 X-Mozilla-Status2: 00000000 Received: from cerberus.YNet.gov.yk.ca ([199.247.130.30]) by raptor.YNet.gov.yk.ca with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Mar 2005 11:05:13 -0800 Received: from Unknown [199.247.128.31] by cerberus.YNet.gov.yk.ca - SurfControl E-mail Filter (4.7); Thu, 03 Mar 2005 10:41:28 -0800 MIME-Version: 1.0 Received: (qmail 22526 invoked by uid 507); 3 Mar 2005 18:41:27 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Received: from 132.151.6.71 by spitfire.gov.yk.ca (envelope-from , uid 500) with qmail-scanner-1.24 (clamdscan: 0.80/653. Clear:RC:0(132.151.6.71):. Processed in 0.376096 secs); 03 Mar 2005 18:41:27 -0000 Received: from megatron.ietf.org (132.151.6.71) by spitfire.gov.yk.ca with SMTP; 3 Mar 2005 18:41:27 -0000 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6vEG-0001g5-MB; Thu, 03 Mar 2005 13:39:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6vEG-0001g0-18 for ipsec@megatron.ietf.org; Thu, 03 Mar 2005 13:39:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28527 for ; Thu, 3 Mar 2005 13:39:16 -0500 (EST) Received: from web52505.mail.yahoo.com ([206.190.39.126]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D6vFe-0008NZ-Nf for ipsec@ietf.org; Thu, 03 Mar 2005 13:40:48 -0500 Received: (qmail 63594 invoked by uid 60001); 3 Mar 2005 18:39:09 -0000 Received: from [69.233.57.195] by web52505.mail.yahoo.com via HTTP; Thu, 03 Mar 2005 10:39:09 PST Content-class: urn:content-classes:message Subject: Re: [Ipsec] SPD & IKE v2 Date: Thu, 3 Mar 2005 10:39:09 -0800 Thread-Topic: [Ipsec] SPD & IKE v2 Thread-Index: AcUgI+4NVrVqMUR0TH6XWa6kpiya0A== From: "Saroop Mathur" To: "Tero Kivinen" X-Spam-Score: 1.2 (+) X-Scan-Signature: b1c41982e167b872076d0018e4e1dc3c Cc: ipsec@ietf.org, Paul Hoffman X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0395314836==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0395314836== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C52023.ED78FA80" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C52023.ED78FA80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable --- Tero Kivinen wrote: > I.e. regardless wheather the first traffic selector item is from > packet or not, it MUST be included in to the returned TS set. This is > MUST, not SHOULD, so there is no other way to do that. This text does > not say what to do if the initiators first traffic selector item is > not completely allowed, but subset of it would be allowed. I would > think that in that case the negotiation should fail with > TS_UNACCEPTABLE. However, the very next paragraph states: ----------------------- If the initiator creates the CHILD_SA pair not in response to an arriving packet, but rather - say - upon startup, then there may be no specific addresses the initiator prefers for the initial tunnel over any other. In that case, the first values in TSi and TSr MAY be ranges rather than specific values, and the responder chooses a subset of the initiator's TSi and TSr that are acceptable.=20 ------------------------ Hence the responder can narrow the first values in the TSi and TSr. -Saroop _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------_=_NextPart_001_01C52023.ED78FA80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Ipsec] SPD & IKE v2

--- Tero Kivinen <kivinen@iki.fi> wrote:

> I.e. regardless wheather the first traffic = selector item is from
> packet or not, it MUST be included in to the = returned TS set. This is
> MUST, not SHOULD, so there is no other way to do = that. This text does
> not say what to do if the initiators first = traffic selector item is
> not completely allowed, but subset of it would = be allowed. I would
> think that in that case the negotiation should = fail with
> TS_UNACCEPTABLE.

However, the very next paragraph states:
-----------------------
   If the initiator creates the CHILD_SA = pair not in response to an
   arriving packet, but rather - say - upon = startup, then there may be
   no specific addresses the initiator = prefers for the initial tunnel
   over any other.  In that case, the = first values in TSi and TSr MAY
be
   ranges rather than specific values, and = the responder chooses a
   subset of the initiator's TSi and TSr = that are acceptable.
------------------------

Hence the responder can narrow the first values in the = TSi and TSr.

-Saroop


_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/ipsec

------_=_NextPart_001_01C52023.ED78FA80-- --===============0395314836== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0395314836==-- From ipsec-bounces@ietf.org Fri Mar 4 01:22:58 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03550 for ; Fri, 4 Mar 2005 01:22:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D76B2-0002TY-9C; Fri, 04 Mar 2005 01:20:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D76Av-0002PZ-UL for ipsec@megatron.ietf.org; Fri, 04 Mar 2005 01:20:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02853 for ; Fri, 4 Mar 2005 01:20:37 -0500 (EST) Received: from jaguar.gov.yk.ca ([199.247.128.32]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D76CP-0006Vg-Th for ipsec@ietf.org; Fri, 04 Mar 2005 01:22:12 -0500 Received: (qmail 31142 invoked by uid 0); 4 Mar 2005 06:50:50 -0000 Message-ID: <20050304065050.31141.qmail@jaguar.gov.yk.ca> X-Mozilla-Status: 0010 X-Mozilla-Status2: 00000000 Received: from cerberus.YNet.gov.yk.ca ([199.247.130.30]) by raptor.YNet.gov.yk.ca with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Mar 2005 09:24:33 -0800 Received: from Unknown [199.247.128.31] by cerberus.YNet.gov.yk.ca - SurfControl E-mail Filter (4.7); Thu, 03 Mar 2005 09:24:33 -0800 MIME-Version: 1.0 Received: (qmail 28782 invoked by uid 507); 3 Mar 2005 17:24:32 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Received: from 132.151.6.71 by spitfire.gov.yk.ca (envelope-from , uid 500) with qmail-scanner-1.24 (clamdscan: 0.80/653. Clear:RC:0(132.151.6.71):. Processed in 0.338979 secs); 03 Mar 2005 17:24:32 -0000 Received: from megatron.ietf.org (132.151.6.71) by spitfire.gov.yk.ca with SMTP; 3 Mar 2005 17:24:32 -0000 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6tzv-0002WE-6F; Thu, 03 Mar 2005 12:20:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6tzs-0002Vw-TE for ipsec@megatron.ietf.org; Thu, 03 Mar 2005 12:20:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20335 for ; Thu, 3 Mar 2005 12:20:22 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6u1G-0006Ib-HP for ipsec@ietf.org; Thu, 03 Mar 2005 12:21:52 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j23HKG4k021357 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Mar 2005 19:20:16 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j23HKEEN021354; Thu, 3 Mar 2005 19:20:14 +0200 (EET) Content-class: urn:content-classes:message Subject: RE: [Ipsec] Technical change needed to IKEv2 before publication Date: Thu, 3 Mar 2005 09:20:14 -0800 Thread-Topic: [Ipsec] Technical change needed to IKEv2 before publication Thread-Index: AcUgFd3lISbYiaO5QpCQa3D7q4uUWw== From: "Tero Kivinen" To: "Paul Koning" X-Spam-Score: 1.2 (+) X-Scan-Signature: e8c5db863102a3ada84e0cd52a81a79e Cc: ipsec@ietf.org, mroe@microsoft.com, paul.hoffman@vpnc.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="===============0860371071==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0860371071== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C52015.DD5A1E80" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C52015.DD5A1E80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Paul Koning writes: > Michael> An initiator that is willing to negotiate either ESN off or > Michael> ESN on should explicitly encode both options in a Transform > Michael> Type 5 (because the default is to demand ESN on, which is > Michael> not a good idea). >=20 > I don't think so -- such an initiator would have to send two > proposals, one with ESN on, one with ESN off. The one with ESN on can > be encoded either by explicitly saying ESN on, or by omitting ESN from > that proposal. No he does not need to send two proposals, in fact there are mostly no reason ever to include multiple proposals. He should include two transform with identical transform type, and different transform ID. The only reason to include multiple proposals if you do not want to allow mix and match, meaning that you want to say that AES and ESN, or 3DES and NO ESN, but do not want to allow AES and NO ESN. There is no reason to do things in the complicated IKEv1 way of having multiple proposals. Actually if you follow rfc2401bis and IKEv2 the SA payload can always have exactly one proposal substructure, which will then have multiple transform substructures. I.e. there will not even be multiple protocols when using rfc2401bis, as it creates AH + ESP as routing the packets back to the IPsec instead of creating SA bundle with multiple protocols. The IKEv2 document still have some text saying that you could create AH + ESP using one exchange, and that can be used for non rfc2401bis or extended rfc2401bis implementations, but base rfc2401bis does not require you to support that. All this means that most implementations can simply use the first proposal substructure and only check the other proposal structures to check that if there is multiple protocols then they need to return error (but they do not need to really parse them etc).=20 --=20 kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------_=_NextPart_001_01C52015.DD5A1E80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: [Ipsec] Technical change needed to IKEv2 before = publication

Paul Koning writes:
>  Michael> An initiator that is willing = to negotiate either ESN off or
>  Michael> ESN on should explicitly = encode both options in a Transform
>  Michael> Type 5 (because the default is = to demand ESN on, which is
>  Michael> not a good idea).
>
> I don't think so -- such an initiator would have = to send two
> proposals, one with ESN on, one with ESN = off.  The one with ESN on can
> be encoded either by explicitly saying ESN on, = or by omitting ESN from
> that proposal.

No he does not need to send two proposals, in fact = there are mostly no
reason ever to include multiple proposals. He should = include two
transform with identical transform type, and = different transform ID.

The only reason to include multiple proposals if you = do not want to
allow mix and match, meaning that you want to say = that AES and ESN, or
3DES and NO ESN, but do not want to allow AES and NO = ESN.

There is no reason to do things in the complicated = IKEv1 way of having
multiple proposals. Actually if you follow rfc2401bis = and IKEv2 the SA
payload can always have exactly one proposal = substructure, which will
then have multiple transform substructures.

I.e. there will not even be multiple protocols when = using rfc2401bis,
as it creates AH + ESP as routing the packets back to = the IPsec
instead of creating SA bundle with multiple = protocols.

The IKEv2 document still have some text saying that = you could create
AH + ESP using one exchange, and that can be used for = non rfc2401bis
or extended rfc2401bis implementations, but base = rfc2401bis does not
require you to support that.

All this means that most implementations can simply = use the first
proposal substructure and only check the other = proposal structures to
check that if there is multiple protocols then they = need to return
error (but they do not need to really parse them = etc).
--
kivinen@safenet-inc.com

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/ipsec

------_=_NextPart_001_01C52015.DD5A1E80-- --===============0860371071== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0860371071==-- From ipsec-bounces@ietf.org Fri Mar 4 01:26:54 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04623 for ; Fri, 4 Mar 2005 01:26:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D768o-0001kU-4i; Fri, 04 Mar 2005 01:18:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D768j-0001jX-VL for ipsec@megatron.ietf.org; Fri, 04 Mar 2005 01:18:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA02326 for ; Fri, 4 Mar 2005 01:18:20 -0500 (EST) Received: from jaguar.gov.yk.ca ([199.247.128.32]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D76AE-0006Lt-Pu for ipsec@ietf.org; Fri, 04 Mar 2005 01:19:56 -0500 Received: (qmail 25165 invoked by uid 0); 4 Mar 2005 06:46:12 -0000 Message-ID: <20050304064612.25164.qmail@jaguar.gov.yk.ca> X-Mozilla-Status: 0010 X-Mozilla-Status2: 00000000 Received: from cerberus.YNet.gov.yk.ca ([199.247.130.30]) by raptor.YNet.gov.yk.ca with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Mar 2005 09:47:44 -0800 Received: from Unknown [199.247.128.31] by cerberus.YNet.gov.yk.ca - SurfControl E-mail Filter (4.7); Thu, 03 Mar 2005 09:47:30 -0800 MIME-Version: 1.0 Received: (qmail 5841 invoked by uid 507); 3 Mar 2005 17:47:29 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Received: from 132.151.6.71 by spitfire.gov.yk.ca (envelope-from , uid 500) with qmail-scanner-1.24 (clamdscan: 0.80/653. Clear:RC:0(132.151.6.71):. Processed in 0.555238 secs); 03 Mar 2005 17:47:29 -0000 Received: from megatron.ietf.org (132.151.6.71) by spitfire.gov.yk.ca with SMTP; 3 Mar 2005 17:47:29 -0000 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6uOk-0000ZV-PB; Thu, 03 Mar 2005 12:46:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6uOj-0000ZD-OM for ipsec@megatron.ietf.org; Thu, 03 Mar 2005 12:46:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23353 for ; Thu, 3 Mar 2005 12:46:02 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6uQ8-00072k-6T for ipsec@ietf.org; Thu, 03 Mar 2005 12:47:33 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j23Hk3hS021611 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 3 Mar 2005 19:46:03 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j23Hk2kB021608; Thu, 3 Mar 2005 19:46:02 +0200 (EET) Content-class: urn:content-classes:message Subject: Re: [Ipsec] SPD & IKE v2 Date: Thu, 3 Mar 2005 09:46:02 -0800 Thread-Topic: [Ipsec] SPD & IKE v2 Thread-Index: AcUgGRqs4Cgsgo8GSZepWTMgqDbR+Q== From: "Tero Kivinen" To: "Saroop Mathur" X-Spam-Score: 1.6 (+) X-Scan-Signature: 8aa7cbc518894eb04182283f0682f662 Cc: ipsec@ietf.org, Paul Hoffman X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1356369458==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1356369458== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C52019.1A73E000" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C52019.1A73E000 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Saroop Mathur writes: > > At 10:14 AM -0800 3/2/05, Surya Batchu wrote: > > >IMO, it is good to have an indication in TS payload indicating that = > > >this payload has packet header selectors. >=20 > I believe such an indication will be really useful. Yes it would be usefull, but not possible at this time. > It can be generalized to indicate "the responder must include this > TS in the subset selected by the responder". That is already there in the document. It says: ---------------------------------------------------------------------- If the responder's policy does not allow it to accept the entire set of traffic selectors in the initiator's request, but does allow him to accept the first selector of TSi and TSr, then the responder MUST narrow the traffic selectors to a subset that includes the initiator's first choices. In this example, the responder might respond with TSi being (192.0.1.43 - 192.0.1.43) with all ports and IP protocols. ---------------------------------------------------------------------- I.e. regardless wheather the first traffic selector item is from packet or not, it MUST be included in to the returned TS set. This is MUST, not SHOULD, so there is no other way to do that. This text does not say what to do if the initiators first traffic selector item is not completely allowed, but subset of it would be allowed. I would think that in that case the negotiation should fail with TS_UNACCEPTABLE.=20 So if the initiator is creating the SA based on the policy not based on packet, and does not send TS items matching the packet, then the responder must still include the first TS item inside its narrowed selectors, i.e. it cannot narrow the first selector down at all. I.e. if initiator send TS 10.0.0.0-10.0.255.255, and responder has only 10.0.0.0-10.0.200.255 configured, then responder will return TS_UNACCEPTABLE. If responder has 10.0.0.0-10.255.255.255 configured, then it will return 10.0.0.0-10.0.255.255 back (i.e. no narrowing). I.e. in that case the policy must either match exactly or the responder must have wider policy. In most cases both ends will have same policy as this is statically configured vpn system. If the first packet is from packet it usually means that it is actually included to some other traffic selector too. I.e. initiator sends 10.0.0.1-10.0.0.1 proto y port x, and 10.0.0.0-10.0.0.255 proto any port any. Now if the responder have policy of 10.0.0.0-10.0.0.128 proto from packet port any, then he can return one TS of 10.0.0.0-10.0.0.128 proto x port any. That returned TS is subset of the union of all input TS items (actually subset of second TS item, but as the first TS item is subset of second their union is actually exactly same as second TS), and also the first TS item from the initiator is also included in this TS item. > This also allows an initiator to have some say in what the > negotiated TS will be. e.g. if a initiator supports only a single SA > for the entire subnet and does not want the responder to narrow the > TS, it currently cannot indicate this. Most SOHO VPN boxes only > support a few SAs and will be at the mercy of the responder to not > narrow down the policy. If the responder is configured to require separate SA for each port then there is nothing the initiator can do in the exchange. Their policies are simply not compatible with each other.=20 >=20 > > I think it is *way* too late for that for the current spec. There is = > > no space currently in the headers for that. >=20 > I agree it is way too late for such a change, however, if a change is > desired, space can be created in the TS header. Currently, the > "Selector Length" field is 16 bits. It could be reduced to 8 bits and = 1 > bit out of the remaining 8 bits be used for this indication. This > leaves 7 bits for future expansion. All lengths inside the IKE payloads are 16 bits, and we might want to have TS type later having more than 256 bytes. It would be much easier to add a new TS type of TS_IPV4_PACKET and TS_IPV6 PACKET having format of: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ! TS Type !IP Protocol ID | Selector Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Port | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ! ! ~ Address ~ ! ! +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ and use that to specify the information about the exact packet. But as said earlier, it is too late for this kind of changes. --=20 kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------_=_NextPart_001_01C52019.1A73E000 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Ipsec] SPD & IKE v2

Saroop Mathur writes:
> > At 10:14 AM -0800 3/2/05, Surya Batchu = wrote:
> > >IMO, it is good to have an indication = in TS payload indicating that
> > >this payload has packet header = selectors.
>
> I believe such an indication will be really = useful.

Yes it would be usefull, but not possible at this = time.

> It can be generalized to indicate "the = responder must include this
> TS in the subset selected by the = responder".

That is already there in the document. It says:

----------------------------------------------------------------= ------
   If the responder's policy does not allow = it to accept the entire set
   of traffic selectors in the initiator's = request, but does allow him
   to accept the first selector of TSi and = TSr, then the responder MUST
   narrow the traffic selectors to a subset = that includes the
   initiator's first choices. In this = example, the responder might
   respond with TSi being (192.0.1.43 - = 192.0.1.43) with all ports and
   IP protocols.
----------------------------------------------------------------= ------

I.e. regardless wheather the first traffic selector = item is from
packet or not, it MUST be included in to the returned = TS set. This is
MUST, not SHOULD, so there is no other way to do = that. This text does
not say what to do if the initiators first traffic = selector item is
not completely allowed, but subset of it would be = allowed. I would
think that in that case the negotiation should fail = with
TS_UNACCEPTABLE.

So if the initiator is creating the SA based on the = policy not based
on packet, and does not send TS items matching the = packet, then the
responder must still include the first TS item inside = its narrowed
selectors, i.e. it cannot narrow the first selector = down at all.

I.e. if initiator send TS 10.0.0.0-10.0.255.255, and = responder has
only 10.0.0.0-10.0.200.255 configured, then responder = will return
TS_UNACCEPTABLE. If responder has = 10.0.0.0-10.255.255.255 configured,
then it will return 10.0.0.0-10.0.255.255 back (i.e. = no narrowing).
I.e. in that case the policy must either match = exactly or the
responder must have wider policy. In most cases both = ends will have
same policy as this is statically configured vpn = system.

If the first packet is from packet it usually means = that it is
actually included to some other traffic selector too. = I.e. initiator
sends 10.0.0.1-10.0.0.1 proto y port x, and = 10.0.0.0-10.0.0.255 proto
any port any. Now if the responder have policy of = 10.0.0.0-10.0.0.128
proto from packet port any, then he can return one TS = of
10.0.0.0-10.0.0.128 proto x port any. That returned = TS is subset of
the union of all input TS items (actually subset of = second TS item,
but as the first TS item is subset of second their = union is actually
exactly same as second TS), and also the first TS = item from the
initiator is also included in this TS item.



> This also allows an initiator to have some say in = what the
> negotiated TS will be. e.g. if a initiator = supports only a single SA
> for the entire subnet and does not want the = responder to narrow the
> TS, it currently cannot indicate this. Most SOHO = VPN boxes only
> support a few SAs and will be at the mercy of = the responder to not
> narrow down the policy.

If the responder is configured to require separate SA = for each port
then there is nothing the initiator can do in the = exchange. Their
policies are simply not compatible with each other. =

>
> > I think it is *way* too late for that for = the current spec. There is
> > no space currently in the headers for = that.
>
> I agree it is way too late for such a change, = however, if a change is
> desired, space can be created in the TS header. = Currently, the
> "Selector Length" field is 16 bits. It = could be reduced to 8 bits and 1
> bit out of the remaining 8 bits be used for this = indication. This
> leaves 7 bits for future expansion.

All lengths inside the IKE payloads are 16 bits, and = we might want to
have TS type later having more than 256 bytes. It = would be much easier
to add a new TS type of TS_IPV4_PACKET and TS_IPV6 = PACKET having
format of:

          &nbs= p;            = ;    = 1            =        = 2            =        3
       0 1 2 3 4 5 6 7 = 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      !   TS = Type     !IP Protocol ID = |       Selector = Length         |
      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      = |            = Port           &nb= sp;   = |            =             &= nbsp;      |
      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      &nbs= p;            = ;            = |
      = !            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;  !
      = ~            =              = Address           =             &= nbsp;       ~
      = !            =             &= nbsp;           &n= bsp;           &nb= sp;           &nbs= p;  !
      = +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

and use that to specify the information about the = exact packet. But
as said earlier, it is too late for this kind of = changes.
--
kivinen@safenet-inc.com

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/ipsec

------_=_NextPart_001_01C52019.1A73E000-- --===============1356369458== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1356369458==-- From ipsec-bounces@ietf.org Fri Mar 4 01:27:29 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04783 for ; Fri, 4 Mar 2005 01:27:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D76BM-0002YT-PA; Fri, 04 Mar 2005 01:21:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D76BJ-0002Xe-Jl for ipsec@megatron.ietf.org; Fri, 04 Mar 2005 01:21:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA03060 for ; Fri, 4 Mar 2005 01:21:00 -0500 (EST) Received: from jaguar.gov.yk.ca ([199.247.128.32]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D76Cj-0006Yq-LA for ipsec@ietf.org; Fri, 04 Mar 2005 01:22:35 -0500 Received: (qmail 31437 invoked by uid 0); 4 Mar 2005 06:51:05 -0000 Message-ID: <20050304065105.31436.qmail@jaguar.gov.yk.ca> X-Mozilla-Status: 0010 X-Mozilla-Status2: 00000000 Received: from cerberus.YNet.gov.yk.ca ([199.247.130.30]) by raptor.YNet.gov.yk.ca with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Mar 2005 06:02:47 -0800 Received: from Unknown [199.247.128.31] by cerberus.YNet.gov.yk.ca - SurfControl E-mail Filter (4.7); Thu, 03 Mar 2005 06:02:47 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C51FF9.AD9D1D80" Received: (qmail 20123 invoked by uid 507); 3 Mar 2005 14:02:46 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Received: from 132.151.6.71 by spitfire.gov.yk.ca (envelope-from , uid 500) with qmail-scanner-1.24 (clamdscan: 0.80/653. Clear:RC:0(132.151.6.71):. Processed in 0.451767 secs); 03 Mar 2005 14:02:46 -0000 Received: from megatron.ietf.org (132.151.6.71) by spitfire.gov.yk.ca with SMTP; 3 Mar 2005 14:02:45 -0000 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6qrd-0008OH-Qw; Thu, 03 Mar 2005 08:59:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6qrc-0008O1-Dl for ipsec@megatron.ietf.org; Thu, 03 Mar 2005 08:59:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24913 for ; Thu, 3 Mar 2005 08:59:38 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6qsz-0000xc-BB for ipsec@ietf.org; Thu, 03 Mar 2005 09:01:05 -0500 Received: from [67.102.148.148] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j23DxSkL004967; Thu, 3 Mar 2005 08:59:30 -0500 (EST) Content-class: urn:content-classes:message Subject: Re: [Ipsec] SPD & IKE v2 Date: Thu, 3 Mar 2005 05:59:26 -0800 X-MS-Has-Attach: yes Thread-Topic: [Ipsec] SPD & IKE v2 Thread-Index: AcUf+a3pQMrdGhuoQjmDat+MM1UYOQ== From: "Stephen Kent" To: "Subha" X-Spam-Score: 0.8 (/) X-Scan-Signature: d2b46e3b2dfbff2088e0b72a54104985 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C51FF9.AD9D1D80 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C51FF9.AD9D1D80" ------_=_NextPart_002_01C51FF9.AD9D1D80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 4:26 PM -0800 3/2/05, Subha wrote: Hi All, =20 I also think that IKEv2 and 2401-bis are conforming to each other. I = would appreciate if someone could indicate why they are not. =20 Thanks, Subha I think the problem is that the SPD specifies pairs of TSi/r values, per = protocol, to be bound to an individual SA (assuming no use of the PFP = feature). If one interprets IKE proposals the way I suggest, then one = can negotiate SAs consistent with the SPD. However, as Tero noted, in = some cases this will result in significant IKE message size growth, that = may cause fragmentation problems. The reason for the growth is that if = we need to convey paired TSi/r address and port data, then one might = have to replicate a TSi or TSr value to maintain the pairing. Tero gave = examples of this. So we have a few options of how to address this problem: 1. change IKE to allow explicit binding of TSi/r values, so that = one can unambiguously represent both 1-to-1 and 1-to-many relationships. = this is the best answer, in principle, but folks are understandably = reluctant to make a change to IKE syntax at this time. 2. require 1-to-1 matching of IKE payloads, to allow = representation of SPD semantics. this does not change IKE syntax, but = does change IKE processing rules, and can result in growth in the size = of IKE messages in certain contexts, with attendant fragmentation = concerns. 3. change the SPD syntax and semantics to accommodate the = limitations of the IKE syntax. this will cause multiple SAs to be = created in some contexts, where the current semantics would allow = multiple traffic flows to be carried via a single SA. if we do not go with #1, then we have a tradeoff: we can create bigger = proposals (#2) or create more SAs (#3) each undesirable outcome arising = under certain conditions. Steve ------_=_NextPart_002_01C51FF9.AD9D1D80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Ipsec] SPD & IKE v2
At 4:26 PM -0800 3/2/05, Subha wrote:
Hi All,
 
I also = think that IKEv2 and 2401-bis are conforming to each other. I would
appreciate if someone could indicate why they are not.
 
Thanks,
Subha

I think the problem is that the SPD specifies pairs of TSi/r values, per protocol, to be bound to an individual SA (assuming no use of the PFP feature). If one interprets IKE proposals the way I suggest, then one can negotiate SAs consistent with the SPD. However, as Tero noted, in some cases this will result in significant IKE message size growth, that may cause fragmentation problems. The reason for the growth is that if we need to convey paired TSi/r address and port data, then one might have to replicate a TSi or TSr value to maintain the pairing. Tero gave examples of this.

So we have a few options of how to address this problem:

        1. change IKE to allow explicit binding of TSi/r values, so that one can unambiguously represent both 1-to-1 and 1-to-many relationships.  this is the best answer, in principle, but folks are understandably reluctant to make a change to IKE syntax at this time.

        2. require 1-to-1 matching of IKE payloads, to allow representation of SPD semantics. this does not change IKE syntax, but does change IKE processing rules, and can result in growth in the size of IKE messages in certain contexts, with attendant fragmentation concerns.

        3. change the SPD syntax and semantics to accommodate the limitations of the IKE syntax. this will cause multiple SAs to be created in some contexts, where the current semantics would allow multiple traffic flows to be carried via a single SA.

if we do not go with #1, then we have a tradeoff: we can create bigger proposals (#2) or create more SAs (#3) each undesirable outcome arising under certain conditions.

Steve

------_=_NextPart_002_01C51FF9.AD9D1D80-- ------_=_NextPart_001_01C51FF9.AD9D1D80 Content-Type: text/plain; name="ATT36499.txt" Content-Transfer-Encoding: base64 Content-Description: ATT36499.txt Content-Disposition: inline; filename="ATT36499.txt" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklwc2VjIG1h aWxpbmcgbGlzdA0KSXBzZWNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lwc2VjDQo= ------_=_NextPart_001_01C51FF9.AD9D1D80 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------_=_NextPart_001_01C51FF9.AD9D1D80-- From ipsec-bounces@ietf.org Fri Mar 4 01:36:25 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06534 for ; Fri, 4 Mar 2005 01:36:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D76MN-0007eq-6c; Fri, 04 Mar 2005 01:32:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D76MH-0007bt-QD for ipsec@megatron.ietf.org; Fri, 04 Mar 2005 01:32:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05709 for ; Fri, 4 Mar 2005 01:32:20 -0500 (EST) Received: from jaguar.gov.yk.ca ([199.247.128.32]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D76Nj-0007Od-Er for ipsec@ietf.org; Fri, 04 Mar 2005 01:33:55 -0500 Received: (qmail 10538 invoked by uid 0); 4 Mar 2005 07:00:21 -0000 Message-ID: <20050304070021.10532.qmail@jaguar.gov.yk.ca> X-Mozilla-Status: 0010 X-Mozilla-Status2: 00000000 Received: from cerberus.YNet.gov.yk.ca ([199.247.130.30]) by raptor.YNet.gov.yk.ca with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Mar 2005 05:31:00 -0800 Received: from Unknown [199.247.128.31] by cerberus.YNet.gov.yk.ca - SurfControl E-mail Filter (4.7); Thu, 03 Mar 2005 05:31:00 -0800 MIME-Version: 1.0 Received: (qmail 16510 invoked by uid 507); 3 Mar 2005 13:30:59 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Received: from 132.151.6.71 by spitfire.gov.yk.ca (envelope-from , uid 500) with qmail-scanner-1.24 (clamdscan: 0.80/653. Clear:RC:0(132.151.6.71):. Processed in 0.922001 secs); 03 Mar 2005 13:30:59 -0000 Received: from megatron.ietf.org (132.151.6.71) by spitfire.gov.yk.ca with SMTP; 3 Mar 2005 13:30:58 -0000 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6qOm-0003qV-RA; Thu, 03 Mar 2005 08:29:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6qOm-0003qQ-6g for ipsec@megatron.ietf.org; Thu, 03 Mar 2005 08:29:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA22657 for ; Thu, 3 Mar 2005 08:29:50 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6qQ8-0000L3-NK for ipsec@ietf.org; Thu, 03 Mar 2005 08:31:17 -0500 Received: from [67.102.148.148] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j23DTYkJ003898; Thu, 3 Mar 2005 08:29:35 -0500 (EST) Content-class: urn:content-classes:message Subject: Re: [Ipsec] SPD & IKE v2 Date: Thu, 3 Mar 2005 05:29:28 -0800 Thread-Topic: [Ipsec] SPD & IKE v2 Thread-Index: AcUf9T2EMdu7PlVQTTKzFDxHtz7O2g== From: "Stephen Kent" To: "Tero Kivinen" X-Spam-Score: 1.2 (+) X-Scan-Signature: 90f8d7cac99eccf384c4cdc57475e98c 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="===============1416851762==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1416851762== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C51FF5.3CF40200" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C51FF5.3CF40200 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable At 1:22 PM +0200 3/2/05, Tero Kivinen wrote: > > > For example, the text describes how to pass triggering >> packet header data as the FIRST selector set data in TSi and TSr >> payloads, implying that the order of elements in these payloads is >> important, and that one is expected to view them as pairs, matching >> the corresponding S/D address and port fields. > >I cannot see how it implies that there is any order for the rest of >the items, when you say that the first item must be from packet if you >ant to include it. We needed some way to find the specific from packet >TS item, and instead of adding a flag or using separate TS type for >that we decided to put it as a first item in the list. We already >found out in the interop event that this can cause confusion, as some >people didn't understand that the first item can be very specific. And >in some cases is it impossible to find out wheather there is one >specific entry or not. We agree that if an initiator wants to send header data from a=20 triggering packet, then the data is sent as the first pair of entries=20 in the TSi/r payloads. In this case, it seems clear that the=20 semantics here is that these entries are paired, i.e., the responder=20 should interpret the pair of entries as representing the S/D address=20 and port data from the triggering packet. Do you agree? But, there is no flag that indicates whether the first entry is from=20 a triggering packet, not, as others have noted. Thus if the responder=20 always treats the first pair of TSi/r addresses & ports as matched,=20 which is the sensible interpretation when this first pair represents=20 triggering packet data, then it will do so even when the first pair=20 does NOT represent such data. So, why change the interpretation for=20 later pairs of S/D addresses & ports? > > So, I have to admit >> that I am confused by your comment. If I send a series of pairs of >> TSi/TSr payloads, I would interpret this to represent pairs of S/D >> data, with a common protocol, so that each matched pair represents >> one selector set from an SPD entry, if the entry has more than one >> selector set in it. > >One of the ideas is that the initiator can send TS: > >TSi =3D 0.0.0.0-255.255.255.255 >TSr =3D 0.0.0.0-255.255.255.255 > >and the responder can narrow it down to: > >TSi =3D 10.0.11.22-10.0.11.22 >TSr =3D 10.0.0.0-10.255.255.255, 192.168.0.0-192.168.255.255 I don't disagree that you can save space in IKE messages under some=20 circumstances by being able to associate one payload for one=20 direction with multiple ones for the other direction. However, if we=20 do not have a way to represent a one-to-one correspondence between=20 TSi and TSr values, then we cannot convey the semantics of the SPD,=20 and that is not OK. > > Can you cite the parts of IKEv2 that suggest the "mix and match" >> approach that you indicated? > >It does use mix and match in all other cases with similar lists. Can >you find out where it says you should pairwise tie TS together? It >does not say anywhere that there should be even equal number of items >in the TSi and TSr. The example I gave, for the first set of values in TSi/r implies a=20 1-to-1 (paired) matching in this case. Also, the purpose of the IKE=20 negotiation is to represent an SPD entry to a peer. SPD entries, like=20 analogous ACL entries, are paired. Because we create pairs of SAs=20 that represent traffic bidirectional traffic flows that are common in=20 the IP context, one expresses ACLs in terms of these bidirectional=20 flows. > > Such semantics make no sense in the access control context that the >> SPD represents. > >It does make perfect sense for me. I.e. the TSi lists the IP-address >ranges which can be found from the initiators end of the network, and >TSr contains the list of address ranges which can be found from the >responders end. The example you provide is a reasonable one, but it represents a very=20 simple case where the mix and match approach expresses the underlying=20 access control semantics. However, in the more general case, I may=20 want to express the notion that Host A in my net can be accesses by=20 Host B in your net and Host C in my net can be accessed by Host D in=20 your net, AND I want the traffic for both of these flows to be=20 carried via one SA. The SPD allows one to express this notion, and=20 IKE needs to be able to convey it. That is how firewalls express=20 access control policy (modulo the use of SAs) and the IPsec SPD is a=20 standardized representation of such an access control policy. >I.e. if you have VPN setup where the site A has networks 10.0.22.0/24 >and 10.0.44.0/24, and the site B has >10.0.55.0/24,10.0.222.0/24,10.0.227.0/24, then the TSi will contain >the networks from site A has, and TSr of the request will have >0.0.0.0-255.255.255.255, and the responde will narrow that any ip down >so that TSi will still have 10.0.22.0/24 and 10.0.44.0/24 and the TSr >will now have the networks site B has. > >This would not be possible if the TS items would be tied together, as >it would cause lots of TS items to be created. We tried to avoid >combinatory explosion in the IKEv2. I agree that we should minimize combinatorial explosion, but the SPD=20 is a local representation of access control policy and one cannot=20 express the sort of constraints that may be necessary if the TS=20 proposals are treated as your suggest. IKE could have a different=20 structure for the TS proposals, one that would satisfy both goals. It=20 could allow for compact representation of the cases where one wants=20 to list only selector range for one direction and bind multiple=20 ranges to the other direction. But, we do not have that and I sense a=20 lot of resistance to making a change of this sort at this point in=20 time. > > Also, I'd like to think that IKE should be trying to negotiate what >> the SPD specifies, to minimize the likelihood that SAs are >> established that later will not carry the intended traffic. > >I think you earlier said it other way around, i.e. the SPD was >specified to be able to negotiate what the IKEv2 can negotiate. I >think I did comment this earlier when you were writing the ASN1 >version of the SPD, but as I am now behind bad network connections I >cannot search the archives. I'm afraid you have this backwards :-) I have said that we tried to work to align the SPD and IKE, so that=20 we could negotiate in IKE what the SPD expresses. We had mismatches=20 in 2401bis vs. IKE v1 in that we could express things in the SPD that=20 IKE could not negotiate. While it is true that I have said that we=20 wanted to make sure that IKE v2 and 2401bis are aligned, there is a=20 priority here, i.e., 2401bis specifies access control policies and=20 IKE v2 exists to negotiate SAs consistent with these policies, not=20 the other way around. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------_=_NextPart_001_01C51FF5.3CF40200 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [Ipsec] SPD & IKE v2

At 1:22 PM +0200 3/2/05, Tero Kivinen wrote:

>       = <SNIP>
>  > For example, the text describes how = to pass triggering
>>  packet header data as the FIRST = selector set data in TSi and TSr
>>  payloads, implying that the order of = elements in these payloads is
>>  important, and that one is expected to = view them as pairs, matching
>>  the corresponding S/D address and port = fields.
>
>I cannot see how it implies that there is any = order for the rest of
>the items, when you say that the first item must = be from packet if you
>ant to include it. We needed some way to find the = specific from packet
>TS item, and instead of adding a flag or using = separate TS type for
>that we decided to put it as a first item in the = list. We already
>found out in the interop event that this can = cause confusion, as some
>people didn't understand that the first item can = be very specific. And
>in some cases is it impossible to find out = wheather there is one
>specific entry or not.

We agree that if an initiator wants to send header = data from a
triggering packet, then the data is sent as the first = pair of entries
in the TSi/r payloads. In this case, it seems clear = that the
semantics here is that these entries are paired, = i.e., the responder
should interpret the pair of entries as representing = the S/D address
and port data from the triggering packet.  Do = you agree?

But, there is no flag that indicates whether the first = entry is from
a triggering packet, not, as others have noted. Thus = if the responder
always treats the first pair of TSi/r addresses & = ports as matched,
which is the sensible interpretation when this first = pair represents
triggering packet data, then it will do so even when = the first pair
does NOT represent such data.  So, why change = the interpretation for
later pairs of S/D addresses & ports?


>  > So, I have to admit
>>  that I am confused by your comment. If = I send a series of pairs of
>>  TSi/TSr payloads, I would interpret = this to represent pairs of S/D
>>  data, with a common protocol, so that = each matched pair represents
>>  one selector set from an SPD entry, if = the entry has more than one
>>  selector set in it.
>
>One of the ideas is that the initiator can send = TS:
>
>TSi =3D 0.0.0.0-255.255.255.255
>TSr =3D 0.0.0.0-255.255.255.255
>
>and the responder can narrow it down to:
>
>TSi =3D 10.0.11.22-10.0.11.22
>TSr =3D 10.0.0.0-10.255.255.255, = 192.168.0.0-192.168.255.255

I don't disagree that you can save space in IKE = messages under some
circumstances by being able to associate one payload = for one
direction with multiple ones for the other direction. = However, if we
do not have a way to represent a one-to-one = correspondence between
TSi and TSr values, then we cannot convey the = semantics of the SPD,
and that is not OK.

>  > Can you cite the parts of IKEv2 that = suggest the "mix and match"
>>  approach that you indicated?
>
>It does use mix and match in all other cases with = similar lists. Can
>you find out where it says you should pairwise = tie TS together? It
>does not say anywhere that there should be even = equal number of items
>in the TSi and TSr.

The example I gave, for the first set of values in = TSi/r implies a
1-to-1 (paired) matching in this case. Also, the = purpose of the IKE
negotiation is to represent an SPD entry to a peer. = SPD entries, like
analogous ACL entries, are paired. Because we create = pairs of SAs
that represent traffic bidirectional traffic flows = that are common in
the IP context, one expresses ACLs in terms of these = bidirectional
flows.

>  > Such semantics make no sense in the = access control context that the
>>  SPD represents.
>
>It does make perfect sense for me. I.e. the TSi = lists the IP-address
>ranges which can be found from the initiators end = of the network, and
>TSr contains the list of address ranges which can = be found from the
>responders end.

The example you provide is a reasonable one, but it = represents a very
simple case where the mix and match approach = expresses the underlying
access control semantics. However, in the more = general case, I may
want to express the notion that Host A in my net can = be accesses by
Host B in your net and Host C in my net can be = accessed by Host D in
your net, AND I want the traffic for both of these = flows to be
carried via one SA. The SPD allows one to express = this notion, and
IKE needs to be able to convey it. That is how = firewalls express
access control policy (modulo the use of SAs) and the = IPsec SPD is a
standardized representation of such an access control = policy.

>I.e. if you have VPN setup where the site A has = networks 10.0.22.0/24
>and 10.0.44.0/24, and the site B has
>10.0.55.0/24,10.0.222.0/24,10.0.227.0/24, then = the TSi will contain
>the networks from site A has, and TSr of the = request will have
>0.0.0.0-255.255.255.255, and the responde will = narrow that any ip down
>so that TSi will still have 10.0.22.0/24 and = 10.0.44.0/24 and the TSr
>will now have the networks site B has.
>
>This would not be possible if the TS items would = be tied together, as
>it would cause lots of TS items to be created. We = tried to avoid
>combinatory explosion in the IKEv2.

I agree that we should minimize combinatorial = explosion, but the SPD
is a local representation of access control policy = and one cannot
express the sort of constraints that may be necessary = if the TS
proposals are treated as your suggest. IKE could have = a different
structure for the TS proposals, one that would = satisfy both goals. It
could allow for compact representation of the cases = where one wants
to list only selector range for one direction and = bind multiple
ranges to the other direction. But, we do not have = that and I sense a
lot of resistance to making a change of this sort at = this point in
time.

>  > Also, I'd like to think that IKE = should be trying to negotiate what
>>  the SPD specifies, to minimize the = likelihood that SAs are
>>  established that later will not carry = the intended traffic.
>
>I think you earlier said it other way around, = i.e. the SPD was
>specified to be able to negotiate what the IKEv2 = can negotiate. I
>think I did comment this earlier when you were = writing the ASN1
>version of the SPD, but as I am now behind bad = network connections I
>cannot search the archives.

I'm afraid you have this backwards :-)

I have said that we tried to work to align the SPD and = IKE, so that
we could negotiate in IKE what the SPD = expresses.  We had mismatches
in 2401bis vs. IKE v1 in that we could express things = in the SPD that
IKE could not negotiate. While it is true that I have = said that we
wanted to make sure that IKE v2 and 2401bis are = aligned, there is a
priority here, i.e., 2401bis specifies access control = policies and
IKE v2 exists to negotiate SAs consistent with these = policies, not
the other way around.

Steve

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/ipsec

------_=_NextPart_001_01C51FF5.3CF40200-- --===============1416851762== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1416851762==-- From ipsec-bounces@ietf.org Fri Mar 4 01:37:37 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06735 for ; Fri, 4 Mar 2005 01:37:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D76MO-0007f2-Mf; Fri, 04 Mar 2005 01:32:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D76MK-0007da-Mp for ipsec@megatron.ietf.org; Fri, 04 Mar 2005 01:32:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05715 for ; Fri, 4 Mar 2005 01:32:23 -0500 (EST) Received: from jaguar.gov.yk.ca ([199.247.128.32]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D76Np-0007Op-SD for ipsec@ietf.org; Fri, 04 Mar 2005 01:33:59 -0500 Received: (qmail 10992 invoked by uid 0); 4 Mar 2005 07:00:42 -0000 Message-ID: <20050304070042.10991.qmail@jaguar.gov.yk.ca> X-Mozilla-Status: 0010 X-Mozilla-Status2: 00000000 Received: from cerberus.YNet.gov.yk.ca ([199.247.130.30]) by raptor.YNet.gov.yk.ca with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Mar 2005 10:57:32 -0800 Received: from Unknown [199.247.128.31] by cerberus.YNet.gov.yk.ca - SurfControl E-mail Filter (4.7); Thu, 03 Mar 2005 10:30:03 -0800 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01C52022.DAB1F600" Received: (qmail 19368 invoked by uid 507); 3 Mar 2005 18:30:02 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Received: from 132.151.6.71 by spitfire.gov.yk.ca (envelope-from , uid 500) with qmail-scanner-1.24 (clamdscan: 0.80/653. Clear:RC:0(132.151.6.71):. Processed in 0.047026 secs); 03 Mar 2005 18:30:02 -0000 Received: from megatron.ietf.org (132.151.6.71) by spitfire.gov.yk.ca with SMTP; 3 Mar 2005 18:30:01 -0000 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6v0E-0007Vj-1E; Thu, 03 Mar 2005 13:24:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6v0B-0007Ve-Fj for ipsec@megatron.ietf.org; Thu, 03 Mar 2005 13:24:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27025 for ; Thu, 3 Mar 2005 13:24:44 -0500 (EST) Received: from sj-iport-5.cisco.com ([171.68.10.87]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6v1a-0007ye-OY for ipsec@ietf.org; Thu, 03 Mar 2005 13:26:15 -0500 Received: from sj-core-2.cisco.com (171.71.177.254) by sj-iport-5.cisco.com with ESMTP; 03 Mar 2005 10:26:31 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-2.cisco.com (8.12.10/8.12.6) with ESMTP id j23IK1q8027387; Thu, 3 Mar 2005 10:20:01 -0800 (PST) Received: from [171.71.49.252] (dhcp-171-71-49-252.cisco.com [171.71.49.252]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BCK64704; Thu, 3 Mar 2005 10:20:05 -0800 (PST) Content-class: urn:content-classes:message Subject: Re: [Ipsec] SPD & IKE v2 Date: Thu, 3 Mar 2005 10:20:04 -0800 X-MS-Has-Attach: yes Thread-Topic: [Ipsec] SPD & IKE v2 Thread-Index: AcUgItt1ToCleC3FQVaGpiSbpxUFMw== From: "Kevin Li" To: "Tero Kivinen" X-Spam-Score: 2.1 (++) X-Scan-Signature: e274a7d5658fb8b0d6fbc93f042d014b Cc: ipsec@ietf.org, Bill Sommerfeld , Yoav Nir , Paul Hoffman X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. ------_=_NextPart_001_01C52022.DAB1F600 Content-Type: multipart/alternative; boundary="----_=_NextPart_002_01C52022.DAB1F600" ------_=_NextPart_002_01C52022.DAB1F600 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Why the initiator must/should have the first packet selector specifying = first packet? If initiator wants the first packet to be accepted by the responder, it = could well be included in a TS range which he wants remote end to = accept. There is no reason to extract this particular TS out from that = range. If the remote end doesn't want to accept the traffic type in = first packet according to its local policy, it will reject it any way = either through TS_UNACCEPTIBLE or exclude that from the narrowing down = TS.=20 Thanks. Kevin Tero Kivinen wrote:=20 Yoav Nir writes: =20 On Mar 3, 2005, at 12:02 AM, Bill Sommerfeld wrote: =20 On Wed, 2005-03-02 at 16:43, Paul Hoffman wrote: =20 Further, the way the document is worded, you are supposed to make the first selector for the first packet *even if you don't want to actually have that flow*. =20 why would you ask for an SA you didn't intend to use? =20 You might want to do this for a remote client. The client has a=20 "Connect" button. The software has no way on knowing what the user is=20 going to do after clicking "Connect". =20 If you press connect button the initiator is not requesting the SA due to the data packet, thus you do not send the packet specific data in the TS. The paragrap describing how to send the TS starts: ---------------------------------------------------------------------- To enable the responder to choose the appropriate range in this case, if the initiator has requested the SA due to a data packet, the initiator SHOULD include ... ---------------------------------------------------------------------- I.e. the SHOULD only matters if "the initiator has requested the SA due to a data packet". I think that SHOULD should be MUST instead of SHOULD, I do not really understand now why it is SHOULD as it does not cover this kind of "connect button" or "autostart" cases, thus there is no point of ever leaving that TS out. Anyways as it is SHOULD now, it will stay SHOULD, it is too late to change that. Note, that the section which says that responder MUST return TS which includes the the first TS from the initiator is NOT specific to this case. That MUST be followed always. I.e. responder do not have option to return TS which does not match the first TS completely. This actually solves those SOHO VPN users problem. They configure the TS to be "autostart", i.e. initiated from the beginning without data packet, and the first TS included is something that the responder must accept completely, or fail the negotiation. Of course it will still cause all the negotiations to fail if the responder is configured to only allow subset of the first TS. =20 In IKEv1 it would do only Phase 1. In IKEv2 you can't do only phase 1, so you need to make some child SA in there. =20 Why are you making the IKE SA if you do not intend to use it? =20 Making an SA for simple ICMP between the client and the gateway (just one address and protocol in each TS) is one way. You could also suggest the entire Internet (0.0.0.0-255.255.255.255) and have the gateway narrow that to some range or bunch of ranges which may or may not be useful later. In the case of a generic client I think the latter approach is more appropriate, especially if it doesn't have a matched policy with the gateway. Doing the whole thing with the "Connect" button and 4-8 packets only to fail because the gateway blocks ICMP is a bad idea. =20 If you are doing the client, you should always include the entire internet as destination, and also for source unless you have IP address already configured. I.e. if you do not have IP address yet, you send TSi and TSr both to include full 0.0.0.0-255.255.255.255 and ::0-FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF, and allow the responder gateway to assign you both IPv4 and IPv6 addresses (using Configuration payload), and also narrow your TSi to only include IP addresses it assigned to you, and narrow TSr to include the IP-addresses which can be reaced through it. If you have IP-address already (statically configured), then you set your TSi to be exactly that, and still use full internet as TSr.=20 =20 ------_=_NextPart_002_01C52022.DAB1F600 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Why the initiator must/should have the first packet selector specifying first packet?
If initiator wants the first packet to be accepted by the responder, it could well be included in a TS range which he wants remote end to accept. There is no reason to extract this particular TS out from that range. If the remote end doesn't want to accept the traffic type in first packet according to its local policy, it will reject it any way either through TS_UNACCEPTIBLE or exclude that from the narrowing down TS.

Thanks.

Kevin

Tero Kivinen wrote: 
Yoav Nir writes:
  
On Mar 3, 2005, at 12:02 AM, Bill Sommerfeld wrote:

    
On Wed, 2005-03-02 at 16:43, Paul Hoffman wrote:

      
Further, the way the
document is worded, you are supposed to make the first selector for
the first packet *even if you don't want to actually have that flow*.
        
why would you ask for an SA you didn't intend to =
use?
      
You might want to do this for a remote client.  The =
client has a=20
"Connect" button.  The software has no way on knowing what the user is=20
going to do after clicking "Connect".
    

If you press connect button the initiator is not requesting the SA due
to the data packet, thus you do not send the packet specific data in
the TS.

The paragrap describing how to send the TS starts:
----------------------------------------------------------------------
   To enable the responder to choose the appropriate range in this case,
   if the initiator has requested the SA due to a data packet, the
   initiator SHOULD include ...
----------------------------------------------------------------------

I.e. the SHOULD only matters if "the initiator has requested the SA
due to a data packet".

I think that SHOULD should be MUST instead of SHOULD, I do not really
understand now why it is SHOULD as it does not cover this kind of
"connect button" or "autostart" cases, thus there is no point of ever
leaving that TS out.

Anyways as it is SHOULD now, it will stay SHOULD, it is too late to
change that.

Note, that the section which says that responder MUST return TS which
includes the the first TS from the initiator is NOT specific to this
case. That MUST be followed always. I.e. responder do not have option
to return TS which does not match the first TS completely.

This actually solves those SOHO VPN users problem. They configure the
TS to be "autostart", i.e. initiated from the beginning without data
packet, and the first TS included is something that the responder must
accept completely, or fail the negotiation. Of course it will still
cause all the negotiations to fail if the responder is configured to
only allow subset of the first TS.

  
In IKEv1 it would do only Phase 1. In IKEv2 you can't =
do only phase
1, so you need to make some child SA in there.
    

Why are you making the IKE SA if you do not intend to use it?

  
Making an SA for simple ICMP between the client and =
the gateway
(just one address and protocol in each TS) is one way. You could
also suggest the entire Internet (0.0.0.0-255.255.255.255) and have
the gateway narrow that to some range or bunch of ranges which may
or may not be useful later. In the case of a generic client I think
the latter approach is more appropriate, especially if it doesn't
have a matched policy with the gateway. Doing the whole thing with
the "Connect" button and 4-8 packets only to fail because the
gateway blocks ICMP is a bad idea.
    

If you are doing the client, you should always include the entire
internet as destination, and also for source unless you have IP
address already configured.

I.e. if you do not have IP address yet, you send TSi and TSr both to
include full 0.0.0.0-255.255.255.255 and
::0-FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF:FFFF, and allow the responder
gateway to assign you both IPv4 and IPv6 addresses (using
Configuration payload), and also narrow your TSi to only include IP
addresses it assigned to you, and narrow TSr to include the
IP-addresses which can be reaced through it.

If you have IP-address already (statically configured), then you set
your TSi to be exactly that, and still use full internet as TSr.=20

------_=_NextPart_002_01C52022.DAB1F600-- ------_=_NextPart_001_01C52022.DAB1F600 Content-Type: text/plain; name="ATT36679.txt" Content-Transfer-Encoding: base64 Content-Description: ATT36679.txt Content-Disposition: attachment; filename="ATT36679.txt" Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64 X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCklwc2VjIG1h aWxpbmcgbGlzdA0KSXBzZWNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3MS5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL2lwc2VjDQo= ------_=_NextPart_001_01C52022.DAB1F600 Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------_=_NextPart_001_01C52022.DAB1F600-- From ipsec-bounces@ietf.org Fri Mar 4 01:41:17 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07429 for ; Fri, 4 Mar 2005 01:41:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D76S9-0000Zy-Qs; Fri, 04 Mar 2005 01:38:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D76S7-0000Zq-62 for ipsec@megatron.ietf.org; Fri, 04 Mar 2005 01:38:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06832 for ; Fri, 4 Mar 2005 01:38:22 -0500 (EST) Received: from jaguar.gov.yk.ca ([199.247.128.32]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D76Ta-0007jo-MW for ipsec@ietf.org; Fri, 04 Mar 2005 01:39:57 -0500 Received: (qmail 17952 invoked by uid 0); 4 Mar 2005 07:05:59 -0000 Message-ID: <20050304070559.17951.qmail@jaguar.gov.yk.ca> X-Mozilla-Status: 0000 X-Mozilla-Status2: 00000000 Received: from cerberus.YNet.gov.yk.ca ([199.247.130.30]) by raptor.YNet.gov.yk.ca with Microsoft SMTPSVC(6.0.3790.211); Thu, 3 Mar 2005 09:52:14 -0800 Received: from Unknown [199.247.128.31] by cerberus.YNet.gov.yk.ca - SurfControl E-mail Filter (4.7); Thu, 03 Mar 2005 09:52:14 -0800 MIME-Version: 1.0 Received: (qmail 7928 invoked by uid 507); 3 Mar 2005 17:52:13 -0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Received: from 132.151.6.71 by spitfire.gov.yk.ca (envelope-from , uid 500) with qmail-scanner-1.24 (clamdscan: 0.80/653. Clear:RC:0(132.151.6.71):. Processed in 0.149553 secs); 03 Mar 2005 17:52:13 -0000 Received: from megatron.ietf.org (132.151.6.71) by spitfire.gov.yk.ca with SMTP; 3 Mar 2005 17:52:12 -0000 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6uTF-0001Pg-Nd; Thu, 03 Mar 2005 12:50:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D6uTE-0001Pb-6s for ipsec@megatron.ietf.org; Thu, 03 Mar 2005 12:50:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23889 for ; Thu, 3 Mar 2005 12:50:41 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D6uUc-0007C1-FE for ipsec@ietf.org; Thu, 03 Mar 2005 12:52:11 -0500 Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j23HoeXN046826 for ; Thu, 3 Mar 2005 09:50:41 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Content-class: urn:content-classes:message Subject: [Ipsec] Re: Proposed Straw Poll Date: Thu, 3 Mar 2005 09:50:42 -0800 Thread-Topic: [Ipsec] Re: Proposed Straw Poll Thread-Index: AcUgGbvWwzOrEgw9Qcisx29hy9n1dg== From: "Paul Hoffman" To: X-Spam-Score: 1.6 (+) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 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="===============0333517266==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0333517266== Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C52019.BB629B00" Content-class: urn:content-classes:message This is a multi-part message in MIME format. ------_=_NextPart_001_01C52019.BB629B00 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >PROPOSAL D: >----------- > >Make a clarification (that would go into Pasi's clarification >document) (I don't support D_1 or D_2 because there are literally at least two=20 dozen other clarifications that are as important as this one; we=20 can't even think of holding up the publication for them.) --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------_=_NextPart_001_01C52019.BB629B00 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [Ipsec] Re: Proposed Straw Poll

>PROPOSAL D:
>-----------
>
>Make a clarification (that would go into Pasi's = clarification
>document)

(I don't support D_1 or D_2 because there are = literally at least two
dozen other clarifications that are as important as = this one; we
can't even think of holding up the publication for = them.)

--Paul Hoffman, Director
--VPN Consortium

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/ipsec

------_=_NextPart_001_01C52019.BB629B00-- --===============0333517266== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0333517266==-- From ipsec-bounces@ietf.org Fri Mar 4 02:23:58 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01732 for ; Fri, 4 Mar 2005 02:23:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D778w-0000GB-UH; Fri, 04 Mar 2005 02:22:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D778m-0000EZ-Lz for ipsec@megatron.ietf.org; Fri, 04 Mar 2005 02:22:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01419 for ; Fri, 4 Mar 2005 02:22:27 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D77AH-0000PE-2m for ipsec@ietf.org; Fri, 04 Mar 2005 02:24:03 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 04 Mar 2005 00:38:29 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,134,1107734400"; d="scan'208"; a="231317443:sNHT19724640" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j247MEZV026341; Thu, 3 Mar 2005 23:22:15 -0800 (PST) Received: from ghuangw2k01 ([10.32.227.18]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id BCL46004; Thu, 3 Mar 2005 23:22:13 -0800 (PST) Message-Id: <200503040722.BCL46004@mira-sjc5-b.cisco.com> From: "Geoffrey Huang" To: "'Tero Kivinen'" , "'Theodore Ts'o'" Subject: RE: [Ipsec] Proposed Straw Poll Date: Thu, 3 Mar 2005 23:22:13 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: <16935.27378.504459.724434@fireball.kivinen.iki.fi> Thread-Index: AcUgKuyX6J/67SvvQpGnitXHkstVOgAX7nUg X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, "'Paul Hoffman'" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Tero Kivinen > Sent: Thursday, March 03, 2005 11:52 AM > To: Theodore Ts'o > Cc: ipsec@ietf.org; Paul Hoffman > Subject: [Ipsec] Proposed Straw Poll > > Theodore Ts'o writes: > > A number of people have suggested just doing a > clarification, although > > there were also a number of people who suggested making ESN's > > mandatory (Suggestion C). Some of these discussions were done while > > the discussion was still going on, however, so I'd like for > us to do a > > quick straw poll so that people can clearly register their > > preferences. > > I still think the C is the best one. I agree that C is the best one as well. I don't like implicit values. > > PROPOSAL D: > > ----------- > > > > Make a clarification (that would go into Pasi's clarification > > document) that would add a sentence to the end of Section 3.3.2 that > > says "Note that if the initiator is willing to accept either the use > > of extended sequence numbers or not, the initiator SHOULD send this > > transform in its proposals." > > I do not think that clarification helps at all. It does not really > clarify the situation at all. Making the option mandatory fixes the > problem as there is no default value after that, and it can also be > made in the backward compatible way (i.e. if no value then assume ESN > is enabled). I don't understand. If we made the transform mandatory, then wouldn't the omission of it be an error? If no value meant we should assume ESN is enabled, how would that differ from what we have now? -g > -- > kivinen@safenet-inc.com > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Mar 4 06:50:48 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05028 for ; Fri, 4 Mar 2005 06:50:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7BH8-0005k6-6f; Fri, 04 Mar 2005 06:47:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7BH6-0005jy-4V for ipsec@megatron.ietf.org; Fri, 04 Mar 2005 06:47:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04591 for ; Fri, 4 Mar 2005 06:47:17 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7BId-00084o-QE for ipsec@ietf.org; Fri, 04 Mar 2005 06:48:57 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j24BlFZ02152 for ; Fri, 4 Mar 2005 13:47:16 +0200 (EET) X-Scanned: Fri, 4 Mar 2005 13:47:10 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j24BlANw021517 for ; Fri, 4 Mar 2005 13:47:10 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 00lnqJRo; Fri, 04 Mar 2005 13:47:08 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j24Bl7M08205 for ; Fri, 4 Mar 2005 13:47:07 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 4 Mar 2005 13:47:05 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 4 Mar 2005 13:47:05 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 4 Mar 2005 13:47:04 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Proposed Straw Poll Date: Fri, 4 Mar 2005 13:47:04 +0200 Message-ID: Thread-Topic: [Ipsec] Proposed Straw Poll thread-index: AcUgFuYUMzqpaWcuTomyV4iQo07c+AAl+nAQ To: X-OriginalArrivalTime: 04 Mar 2005 11:47:04.0192 (UTC) FILETIME=[E288F800:01C520AF] X-Spam-Score: 0.3 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable > PROPOSAL D:=20 > ----------- >=20 > Make a clarification (that would go into Pasi's clarification > document) that would add a sentence to the end of Section 3.3.2 that > says "Note that if the initiator is willing to accept either the use > of extended sequence numbers or not, the initiator SHOULD send this > transform in its proposals." I think the current spec does not need any technical changes, and a clarification is enough. So, I support D. (But the correct phrasing would be something like "If the initiator=20 is willing to accept either the use of extended sequence numbers or=20 not, the initiator will include two ESN transforms in its proposals, one with value 0 and another with value 1." I don't support D_1 or D_2. Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Mar 4 10:06:40 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25878 for ; Fri, 4 Mar 2005 10:06:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7EJJ-0005zh-7m; Fri, 04 Mar 2005 10:01:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7EJH-0005zZ-0M for ipsec@megatron.ietf.org; Fri, 04 Mar 2005 10:01:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25251 for ; Fri, 4 Mar 2005 10:01:45 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7EKq-0004hh-RX for ipsec@ietf.org; Fri, 04 Mar 2005 10:03:25 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j24F1alf004011 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 4 Mar 2005 17:01:41 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j24F1Wo1004008; Fri, 4 Mar 2005 17:01:32 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16936.30796.561042.899151@fireball.kivinen.iki.fi> Date: Fri, 4 Mar 2005 17:01:32 +0200 From: Tero Kivinen To: vjyothi@intoto.com Subject: [Ipsec] message IDs and window size in IKEv2 In-Reply-To: <23701.66.80.10.146.1109893226.squirrel@66.80.10.146> References: <20050302205324.99785.qmail@web52501.mail.yahoo.com> <1109797975.8377.130.camel@thunk> <1109800976.8377.147.camel@thunk> <1109802474.8377.156.camel@thunk> <23701.66.80.10.146.1109893226.squirrel@66.80.10.146> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 59 min X-Total-Time: 67 min X-Spam-Score: 0.0 (/) X-Scan-Signature: ce732c7d36989a1bd55104ba259c40a1 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit vjyothi@intoto.com writes: > 1. Requests has to be sent by incrementing message ID > 2. Receiver must accept all the messages of window size, then only it > should move its current accepted message ID. > > Suppose the window size is 2 and the current message ID is 2. > and the sender starts sending two CREATE_CHILD_SA exchange requests of > message IDs 3 and 4. > > May be due to some problem, receiver did not receive the message of > message ID 3. Which means that initiator will never get ACK from responder to message ID 3, and after some time it will tear down the IKE SA and start over. > Should the receiver accept the messages of message IDs 5 and 6 which fall > outside the window?? It MUST ignore those messages, as they cannot be sent by proper initiator. Initiator cannot send those messages, as he cannot have received the ACK for the message ID 3, thus he must be waiting for that before he can start sending message ID 5. > My feeling is that it SHOULD accept the messages because the message IDs > are authenticated. If the messages are authenticated properly, it means that the initiator is not following the spec or there is attacker on the wire who has broken the keying material. In any case the initiator and responder has ended up in the inconsistent state, which means that responder should probably tear down the IKE SA and start over. I assume this question is because the IPsec window and IKE windows are completely different. In IKE window when you send message ID 2, you mark that you have sent message ID 2 out in the window. When you get reply back from the other end, you mark that you have received reply back for the ID 2, and if that is first item in the window you slide the window forward. If you want to send a message when you do not have space in the window, you fail the exchange internally before even allocating message ID for it. So lets take example of window code with responders window size of 2. IWindow = Input window, having n slots of packets, and start ID telling which is the message ID of the first packet in the window. RWindow = Response window, having n slots of packets, and start ID telling which is the message ID of the first packet in the window. OWindow = Output window, having n slots. Each slot can be empty, done or have a packet. Start ID telling which is the message ID of the first packet in the window. Initiator Responder --------- --------- OWindow = (empty, empty), start = 220, IWindow = (218, 219), start = 218 Allocating message ID, getting ID 220 Puts message ID 220 to window: OWindow = (220, empty), start = 220 220 -> Notices that haven't received reply to ID 220, retransmits 220 from the OWindow 220 -> Receives 220, slides the window, and stores the packet. IWindow = (219, 220), start = 218 Generates reply to 220 Stores reply to RWindow, after sliding it forward RWindow = (219R, 220R), start = 219 <- 220R Notices that haven't received reply to ID 220, retransmits 220 from the OWindow 220 -> Receives 220, notices it is retransmission from the initiator, checks that packet matches the copy in IWindow, retranmits 220R from the RWindow <- 220R Gets 220R, marks it in the OWindow that it is done, and slides window forward. OWindow = (empty, empty), start = 221 <- 220R Packet was duplicated in the nwtwork for some reason Receives 220R again, notices it is before the start if window, silently ignores it. Tries to start 3 new exchanges Allocating message ID, getting ID 221 Puts message ID 221 to window: OWindow = (221, empty), start = 221 Allocating message ID, getting ID 222 Puts message ID 222 to window: OWindow = (221, 222), start = 221 Allocating message ID, getting error as there is no space in the window, postpones the new exchange until there is space in window. sends 221 and 222 221 -> 222 -> < packets get reordered by network > Receives 222, slides the window, and stores the packet. Notices that there is one packet missing, but as this jump was less than window size then this is ok. IWindow = (empty, 222), start = 221 Generates reply to 222 Stores reply to RWindow, after sliding it forward RWindow = (empty, 222R), start = 221 <- 222R Gets 222R, marks it done in OWindow, cannot slide window as it haven't received 221R yet, so cannot start new exchanges. OWindow = (221, done), start = 221 Receives 221, no need to slide window (already done during 222), stores the packet. IWindow = (221, 222), start = 221 Generates reply to 221 Stores reply to RWindow RWindow = (221R, 222R), start = 221 <- 221R Gets 221R, marks it done in OWindow, slides window forward, sliding also over other done items. OWindow = (empty,empty), start = 223 Notices, that now he can start new exchange that was postponed earlier, so restarts that exchange. The IWindow and RWindow can also be combined, so that it has slots for input and output packets for each message id. The OWindow does not need that as it only stores one packet there, but it needs few status bits, i.e. one marking that slot is empty (free to be allocated), and one to mark that slot is done (no need to store the packet anymore). The IWindow does not need to store full packets, as it can also store only the hash of the input packet, as it is only used to verify that the packet is same retransmission than the previous one. The initialization is little bit special, as there can be multiple message ID 0 in the exchanges, but after the initialization the message ID 0 is not special case any more.. First sending normal IKE_SA_INIT packet, getting COOKIE notify back (as message ID 0), sending IKE_SA_INIT packet with COOKIE notify, getting INVALID_KE_PAYLOAD notify back (as message ID 0), sending IKE_SA_INIT packet with COOKIE notify and with another group, and then getting the IKE_SA_INIT reply back (as message ID 0). In initiator this is handled so that every time we start from the beginning after getting notify (COOKIE, INVALID_KE_PAYLOAD) we clear the OWindow completely, i.e. empty it and mark start to 0. In the responder there is not problem, as when it is sending the errors it will always simply send the error, and forget about the IKE SA completely (it does not even allocate SPIr for the SA). As it forgets the previous exchange completley, it will not have any IWindow or RWindow state which could mess up things. There will be separate OWindow, IWindow and RWindow in both directions. Note also that responder cannot really ever remove data from its IWindow and RWindow. By the spec the initiator can wait for one hour and then retransmit its message that is still in the window and assume to get reply back. Also there is problem that shrinking the window would be very hard. As the notify will tell how many items can be send to you, the other end might have too many exchanges out when it receives your shrink notify. It could at that point postpone processing of the shrink request until it has received enough responses so it can shrink its OWindow, and only after that continue sending the reply to shrink request (but it cannot include its own window size shrink in the reply message, as otherwise the initiator do not have option to wait until the window is small enough). Because of this I think it would be best to say in the IKEv2 document that window can only be enlarged by notify, not shrinken. Also we need to define what happens to the window size in the IKE SA rekey. I would like to propose that the new rekeyed IKE SA is started so that window size is reset to 1 after the rekey (for the new IKE SA). This would allow easy shrinking of the window size, by rekeying. After the rekey the deletation of old IKE SA should be delayed until there is no more exchanges out in either direction. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Mar 4 10:11:17 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26639 for ; Fri, 4 Mar 2005 10:11:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7EPQ-0006fh-O3; Fri, 04 Mar 2005 10:08:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7EPO-0006fZ-Al for ipsec@megatron.ietf.org; Fri, 04 Mar 2005 10:08:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26117 for ; Fri, 4 Mar 2005 10:08:04 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7EQy-0004rB-7m for ipsec@ietf.org; Fri, 04 Mar 2005 10:09:45 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j24F7sU5004057 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 4 Mar 2005 17:07:54 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j24F7rvw004053; Fri, 4 Mar 2005 17:07:53 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16936.31177.128986.507738@fireball.kivinen.iki.fi> Date: Fri, 4 Mar 2005 17:07:53 +0200 From: Tero Kivinen To: "Geoffrey Huang" Subject: RE: [Ipsec] Proposed Straw Poll In-Reply-To: <200503040722.BCL46004@mira-sjc5-b.cisco.com> References: <16935.27378.504459.724434@fireball.kivinen.iki.fi> <200503040722.BCL46004@mira-sjc5-b.cisco.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 3 min X-Total-Time: 3 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, "'Theodore Ts'o'" , "'Paul Hoffman'" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Geoffrey Huang writes: > I don't understand. If we made the transform mandatory, then wouldn't the > omission of it be an error? Yes if the old version is initiating. If the new version is initiating then everything will work. If the old version is initiating and responder notices there is no ESN types at all, it can either reject the proposal as incorrect, or it can try to do backward compatibility code and assume there was ESN option included. > If no value meant we should assume ESN is > enabled, how would that differ from what we have now? That would mean that as most implementations will send that ESN type, then people will pay attention to it, and the normal proposal selection works there properly. Most likely the backward compatibility is not really needed, as there might not be any released versions with old version. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Mar 4 13:31:30 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18203 for ; Fri, 4 Mar 2005 13:31:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7HWN-0007J8-T9; Fri, 04 Mar 2005 13:27:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7HWN-0007J3-4Z for ipsec@megatron.ietf.org; Fri, 04 Mar 2005 13:27:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17764 for ; Fri, 4 Mar 2005 13:27:28 -0500 (EST) Received: from web90006.mail.scd.yahoo.com ([66.218.94.64]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D7HXy-0002DT-IF for ipsec@ietf.org; Fri, 04 Mar 2005 13:29:12 -0500 Received: (qmail 18044 invoked by uid 60001); 4 Mar 2005 18:27:18 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=vmD9AeBYlAAFz/kKv3cDpk4ApDc1uNbFR8Tn1GDhY1I6gHJJXMMsjfOU/blNwUooNwYWeOzUUm/EUuwKRXW9vtg0vTLRO7REdx3AkA3avDi5Odswl/o6BbwWieB0S+mQzk3z3z37ayQAEnionNRQqnmyQJA+bdf+pb3xeiw0qb0= ; Message-ID: <20050304182718.18042.qmail@web90006.mail.scd.yahoo.com> Received: from [67.170.235.45] by web90006.mail.scd.yahoo.com via HTTP; Fri, 04 Mar 2005 10:27:17 PST Date: Fri, 4 Mar 2005 10:27:17 -0800 (PST) From: Surya Batchu Subject: Re: [Ipsec] message IDs and window size in IKEv2 To: Tero Kivinen , vjyothi@intoto.com In-Reply-To: <16936.30796.561042.899151@fireball.kivinen.iki.fi> MIME-Version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 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="===============0395067882==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0395067882== Content-Type: multipart/alternative; boundary="0-1414784661-1109960837=:14685" --0-1414784661-1109960837=:14685 Content-Type: text/plain; charset=us-ascii > My feeling is that it SHOULD accept the messages because the message IDs > are authenticated. If the messages are authenticated properly, it means that the initiator is not following the spec or there is attacker on the wire who has broken the keying material. In any case the initiator and responder has ended up in the inconsistent state, which means that responder should probably tear down the IKE SA and start over. I undestand that the draft specification does not allow this. What is the problem in accepting new message ID, as long as message ID value is not less than the expected sequence number. New message ID can be treated as right edge of window and adjust the window accordingly. Surya --------------------------------- Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web --0-1414784661-1109960837=:14685 Content-Type: text/html; charset=us-ascii

> My feeling is that it SHOULD accept the messages because the message IDs
> are authenticated.

If the messages are authenticated properly, it means that the
initiator is not following the spec or there is attacker on the wire
who has broken the keying material. In any case the initiator and
responder has ended up in the inconsistent state, which means that
responder should probably tear down the IKE SA and start over.

I undestand that the draft specification does not allow this. What is the problem in accepting new message ID, as long as message ID value is not less than the expected sequence number.  New message ID can be treated as right edge of window and adjust the window accordingly.

Surya

Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web --0-1414784661-1109960837=:14685-- --===============0395067882== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0395067882==-- From ipsec-bounces@ietf.org Fri Mar 4 13:39:12 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA19140 for ; Fri, 4 Mar 2005 13:39:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7HgT-0000j3-Sb; Fri, 04 Mar 2005 13:37:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7HgS-0000hB-TO for ipsec@megatron.ietf.org; Fri, 04 Mar 2005 13:37:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18996 for ; Fri, 4 Mar 2005 13:37:54 -0500 (EST) Received: from web90010.mail.scd.yahoo.com ([66.218.94.68]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D7Hi5-0002Wy-Ie for ipsec@ietf.org; Fri, 04 Mar 2005 13:39:38 -0500 Received: (qmail 90106 invoked by uid 60001); 4 Mar 2005 18:37:47 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=IHeJm8V0+SiI8bPASN5K4rvqIy8lmpFyDxwQovByJg+xWJtoecRgF1gLcq7NRu6OpFEA84oceCDmAXIH2QI7jiBzz4aXrFysK64Iuhswg45nvzE1EO/tJmz2e+Rtl8F0zoJ9MfqzDcUjPwjbqIpzsJGB8nvFsRWmV26X5PIXqK0= ; Message-ID: <20050304183747.90104.qmail@web90010.mail.scd.yahoo.com> Received: from [67.170.235.45] by web90010.mail.scd.yahoo.com via HTTP; Fri, 04 Mar 2005 10:37:47 PST Date: Fri, 4 Mar 2005 10:37:47 -0800 (PST) From: Surya Batchu Subject: Re: [Ipsec] SPD & IKE v2 To: Tero Kivinen , Saroop Mathur In-Reply-To: <16935.27805.750529.611059@fireball.kivinen.iki.fi> MIME-Version: 1.0 X-Spam-Score: 0.6 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: ipsec@ietf.org, Paul Hoffman X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0518443086==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0518443086== Content-Type: multipart/alternative; boundary="0-54486399-1109961467=:89056" --0-54486399-1109961467=:89056 Content-Type: text/plain; charset=us-ascii It looks like, SA flood situation is not avoidable with the current limitations in specifications. It is up to the implementations to come out with proper methods to control the SA flood. Is that right? Surya Tero Kivinen wrote: Saroop Mathur writes: > > --- Tero Kivinen wrote: > > > I.e. regardless wheather the first traffic selector item is from > > packet or not, it MUST be included in to the returned TS set. This is > > MUST, not SHOULD, so there is no other way to do that. This text does > > not say what to do if the initiators first traffic selector item is > > not completely allowed, but subset of it would be allowed. I would > > think that in that case the negotiation should fail with > > TS_UNACCEPTABLE. > > However, the very next paragraph states: > ----------------------- > If the initiator creates the CHILD_SA pair not in response to an > arriving packet, but rather - say - upon startup, then there may be > no specific addresses the initiator prefers for the initial tunnel > over any other. In that case, the first values in TSi and TSr MAY > be > ranges rather than specific values, and the responder chooses a > subset of the initiator's TSi and TSr that are acceptable. > ------------------------ > > Hence the responder can narrow the first values in the TSi and TSr. Hmm... true, didn't read it that far now, and didn't remember there was that text there. I would say that this MAY actually conflicts with the MUST in the previous paragraph, or is the implicit "if the initiator has requested the SA due to a data packet" added to the beginning of that paragraph too? If so we end up problems as responder cannot know wheather the SA was requested due to a data packet. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --------------------------------- Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web --0-54486399-1109961467=:89056 Content-Type: text/html; charset=us-ascii
It looks like, SA flood situation is not avoidable with the current limitations in specifications. It is up to the implementations to come out with proper methods to control the SA flood. Is that right?
 
Surya
 
 
Tero Kivinen <kivinen@iki.fi> wrote:
Saroop Mathur writes:
>
> --- Tero Kivinen wrote:
>
> > I.e. regardless wheather the first traffic selector item is from
> > packet or not, it MUST be included in to the returned TS set. This is
> > MUST, not SHOULD, so there is no other way to do that. This text does
> > not say what to do if the initiators first traffic selector item is
> > not completely allowed, but subset of it would be allowed. I would
> > think that in that case the negotiation should fail with
> > TS_UNACCEPTABLE.
>
> However, the very next paragraph states:
> -----------------------
> If the initiator creates the CHILD_SA pair not in response to an
> arriving packet, but rather - say - upon startup, then there may be
> no specific addresses the initiator prefers for ! the initial tunnel
> over any other. In that case, the first values in TSi and TSr MAY
> be
> ranges rather than specific values, and the responder chooses a
> subset of the initiator's TSi and TSr that are acceptable.
> ------------------------
>
> Hence the responder can narrow the first values in the TSi and TSr.

Hmm... true, didn't read it that far now, and didn't remember there
was that text there. I would say that this MAY actually conflicts with
the MUST in the previous paragraph, or is the implicit "if the
initiator has requested the SA due to a data packet" added to the
beginning of that paragraph too? If so we end up problems as responder
cannot know wheather the SA was requested due to a data packet.
--
kivinen@safenet-inc.com

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec

Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web --0-54486399-1109961467=:89056-- --===============0518443086== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0518443086==-- From ipsec-bounces@ietf.org Fri Mar 4 14:39:38 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24798 for ; Fri, 4 Mar 2005 14:39:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7IbJ-0002dK-Q5; Fri, 04 Mar 2005 14:36:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7IbI-0002cb-6z for ipsec@megatron.ietf.org; Fri, 04 Mar 2005 14:36:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24371 for ; Fri, 4 Mar 2005 14:36:39 -0500 (EST) Received: from thunk.org ([69.25.196.29] helo=thunker.thunk.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7Icu-0003vl-NC for ipsec@ietf.org; Fri, 04 Mar 2005 14:38:22 -0500 Received: from root (helo=thunk.org) by thunker.thunk.org with local-esmtp (Exim 3.35 #1 (Debian)) id 1D7IbE-0001Xw-00; Fri, 04 Mar 2005 14:36:36 -0500 Received: from tytso by thunk.org with local (Exim 4.50) id 1D7IbD-0002Mt-AT; Fri, 04 Mar 2005 14:36:35 -0500 To: ipsec@ietf.org From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Fri, 04 Mar 2005 14:36:35 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Subject: [Ipsec] STRAW POLL: Dealing with the ESN negotiation interop issue in IKEv2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org OK, we haven't had anyone complaining about the proposed alternatives or how they have been worded (except for four people who jumped the gun :-), so let's actually conduct the actual straw poll. Please reply to this message with your preference for dealing with this issues as described below, selecting one of proposals A, B, C, D. If proposal D is selected, please note if you support none, one, or both of sub-choices D_1 or D_2. The straw poll will close at 5pm EST on Monday, March 7th. - Ted Issue: If a receiver doesn't support ESN, they require the sender to send an ESN transform Some systems know that they don't support ESN, and therefore they require the other side to actively say they won't expect it. The only way for the other side to do so is for it to send a Transform Type 5 with a value of 0. However, there is no way for the responder to say that to the initiator, so interoperability is not possible. There are four ways that have been discussed to resolve this issue: PROPOSAL A: ----------- The last sentence of 3.3.2 says: If Transform Type 5 is not included in a proposal, use of Extended Sequence Numbers is assumed. Replace this with: If Transform Type 5 is not included in a proposal, it is assumed that the sending party does not support Extended Sequence Numbers. PROPOSAL B: ----------- Create a new response notification that says "I can't do ESN, start again and include a 'no ESN' transform." [Note during the discussion on the mailig list, little or no support was seen for this alternative. PROPOSAL C: ----------- Change the places that says Transform Type 5 is optional to say it is mandatory. PROPOSAL D: ----------- Make a clarification (that would go into Pasi's clarification document) that would add a sentence to the end of Section 3.3.2 that says "Note that if the initiator is willing to accept either the use of extended sequence numbers or not, the initiator SHOULD send this transform in its proposals." PROPOSAL D_1: ------------- Do suggestion D above, but place the clarification in IKEv2. PROPOSAL D_2: ------------- Do Suggestion D_1 only if it can be done without delaying the publication of IKEv2. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Mar 4 15:05:26 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27355 for ; Fri, 4 Mar 2005 15:05:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7J2K-0007vZ-T5; Fri, 04 Mar 2005 15:04:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7J2J-0007sz-Pw for ipsec@megatron.ietf.org; Fri, 04 Mar 2005 15:04:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27170 for ; Fri, 4 Mar 2005 15:04:34 -0500 (EST) Received: from [207.145.48.18] (helo=smtp.intoto.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D7J3x-0004an-BK for ipsec@ietf.org; Fri, 04 Mar 2005 15:06:17 -0500 Received: from not-angel.intoto.com ([66.80.10.146]) by smtp.intoto.com (SMSSMTP 4.0.0.59) with SMTP id M2005030412033511113 ; Fri, 04 Mar 2005 12:03:36 -0800 Received: from SriniSony (dhcp-109.intoto.com [10.1.5.109]) (authenticated bits=0) by not-angel.intoto.com (8.13.1/8.13.1) with ESMTP id j24K3xpC022320; Fri, 4 Mar 2005 12:04:02 -0800 Message-Id: <200503042004.j24K3xpC022320@not-angel.intoto.com> From: "Srinivasa Rao Addepalli" To: "'Theodore Ts'o'" , Subject: RE: [Ipsec] STRAW POLL: Dealing with the ESN negotiation interop issuein IKEv2 Date: Fri, 4 Mar 2005 12:03:54 -0800 Organization: Intoto Inc MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUg8b7JV0pweUsqTvOlCDlH8HOv3AAA39DA In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be Content-Transfer-Encoding: 7bit X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Proposal C Srini -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Theodore Ts'o Sent: Friday, March 04, 2005 11:37 AM To: ipsec@ietf.org Subject: [Ipsec] STRAW POLL: Dealing with the ESN negotiation interop issuein IKEv2 OK, we haven't had anyone complaining about the proposed alternatives or how they have been worded (except for four people who jumped the gun :-), so let's actually conduct the actual straw poll. Please reply to this message with your preference for dealing with this issues as described below, selecting one of proposals A, B, C, D. If proposal D is selected, please note if you support none, one, or both of sub-choices D_1 or D_2. The straw poll will close at 5pm EST on Monday, March 7th. - Ted Issue: If a receiver doesn't support ESN, they require the sender to send an ESN transform Some systems know that they don't support ESN, and therefore they require the other side to actively say they won't expect it. The only way for the other side to do so is for it to send a Transform Type 5 with a value of 0. However, there is no way for the responder to say that to the initiator, so interoperability is not possible. There are four ways that have been discussed to resolve this issue: PROPOSAL A: ----------- The last sentence of 3.3.2 says: If Transform Type 5 is not included in a proposal, use of Extended Sequence Numbers is assumed. Replace this with: If Transform Type 5 is not included in a proposal, it is assumed that the sending party does not support Extended Sequence Numbers. PROPOSAL B: ----------- Create a new response notification that says "I can't do ESN, start again and include a 'no ESN' transform." [Note during the discussion on the mailig list, little or no support was seen for this alternative. PROPOSAL C: ----------- Change the places that says Transform Type 5 is optional to say it is mandatory. PROPOSAL D: ----------- Make a clarification (that would go into Pasi's clarification document) that would add a sentence to the end of Section 3.3.2 that says "Note that if the initiator is willing to accept either the use of extended sequence numbers or not, the initiator SHOULD send this transform in its proposals." PROPOSAL D_1: ------------- Do suggestion D above, but place the clarification in IKEv2. PROPOSAL D_2: ------------- Do Suggestion D_1 only if it can be done without delaying the publication of IKEv2. _______________________________________________ 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 Mar 4 15:30:30 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00802 for ; Fri, 4 Mar 2005 15:30:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7JPj-00043d-O7; Fri, 04 Mar 2005 15:28:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7JPi-00043Y-CX for ipsec@megatron.ietf.org; Fri, 04 Mar 2005 15:28:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00595 for ; Fri, 4 Mar 2005 15:28:44 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7JRL-0005A0-Mw for ipsec@ietf.org; Fri, 04 Mar 2005 15:30:28 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 04 Mar 2005 13:44:55 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,136,1107734400"; d="scan'208"; a="231520440:sNHT42863080" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j24KSYuC025756; Fri, 4 Mar 2005 12:28:34 -0800 (PST) Received: from [171.71.49.252] (dhcp-171-71-49-252.cisco.com [171.71.49.252]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BCM03500; Fri, 4 Mar 2005 12:28:33 -0800 (PST) Message-ID: <4228C4F1.4060905@cisco.com> Date: Fri, 04 Mar 2005 12:28:33 -0800 From: Kevin Li User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Theodore Ts'o" Subject: Re: [Ipsec] STRAW POLL: Dealing with the ESN negotiation interop issue in IKEv2 References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit PROPOSAL A. If I don't send an optional transform, means that it is not supported. It reduces the software complexity and packet overhead. In another word, for all the optional parameters, if I don't support it, there is no reason to go through all the trouble to compose the payload and send it. IMHO. Thanks. Kevin Theodore Ts'o wrote: >OK, we haven't had anyone complaining about the proposed alternatives or >how they have been worded (except for four people who jumped the gun :-), >so let's actually conduct the actual straw poll. > >Please reply to this message with your preference for dealing with this >issues as described below, selecting one of proposals A, B, C, D. If >proposal D is selected, please note if you support none, one, or both of >sub-choices D_1 or D_2. > >The straw poll will close at 5pm EST on Monday, March 7th. > > - Ted > > >Issue: If a receiver doesn't support ESN, they require the sender >to send an ESN transform > >Some systems know that they don't support ESN, and therefore they >require the other side to actively say they won't expect it. The only >way for the other side to do so is for it to send a Transform Type >5 with a value of 0. However, there is no way for the responder to >say that to the initiator, so interoperability is not possible. > >There are four ways that have been discussed to resolve this issue: > >PROPOSAL A: >----------- > >The last sentence of 3.3.2 says: > If Transform Type 5 is not included in a proposal, use of > Extended Sequence Numbers is assumed. >Replace this with: > If Transform Type 5 is not included in a proposal, it is > assumed that the sending party does not support Extended > Sequence Numbers. > >PROPOSAL B: >----------- > >Create a new response notification that says "I can't do ESN, start >again and include a 'no ESN' transform." [Note during the discussion >on the mailig list, little or no support was seen for this >alternative. > >PROPOSAL C: >----------- > >Change the places that says Transform Type 5 is optional to say >it is mandatory. > >PROPOSAL D: >----------- > >Make a clarification (that would go into Pasi's clarification >document) that would add a sentence to the end of Section 3.3.2 that >says "Note that if the initiator is willing to accept either the use >of extended sequence numbers or not, the initiator SHOULD send this >transform in its proposals." > > PROPOSAL D_1: > ------------- > Do suggestion D above, but place the clarification in IKEv2. > > PROPOSAL D_2: > ------------- > Do Suggestion D_1 only if it can be done without delaying the > publication of IKEv2. > > >_______________________________________________ >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 Mar 4 17:07:23 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10267 for ; Fri, 4 Mar 2005 17:07:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7KvN-0004X2-6s; Fri, 04 Mar 2005 17:05:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7KvK-0004Wu-TQ for ipsec@megatron.ietf.org; Fri, 04 Mar 2005 17:05:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA10098 for ; Fri, 4 Mar 2005 17:05:28 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7Kwx-0007Z4-4H for ipsec@ietf.org; Fri, 04 Mar 2005 17:07:13 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-2.cisco.com with ESMTP; 04 Mar 2005 14:18:35 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j24M5FZX009877; Fri, 4 Mar 2005 14:05:17 -0800 (PST) Received: from ghuangw2k01 (dhcp-128-107-176-249.cisco.com [128.107.176.249]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BCM14956; Fri, 4 Mar 2005 14:05:14 -0800 (PST) Message-Id: <200503042205.BCM14956@mira-sjc5-b.cisco.com> From: "Geoffrey Huang" To: "'Theodore Ts'o'" , Subject: RE: [Ipsec] STRAW POLL: Dealing with the ESN negotiation interop issuein IKEv2 Date: Fri, 4 Mar 2005 14:05:14 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 Thread-index: AcUg8gboNNkaswkFQDCjKo/hxItBewAFDR3g X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit I prefer C. -g > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Theodore Ts'o > Sent: Friday, March 04, 2005 11:37 AM > To: ipsec@ietf.org > Subject: [Ipsec] STRAW POLL: Dealing with the ESN negotiation > interop issuein IKEv2 > > > OK, we haven't had anyone complaining about the proposed > alternatives or how they have been worded (except for four > people who jumped the gun :-), so let's actually conduct the > actual straw poll. > > Please reply to this message with your preference for dealing > with this issues as described below, selecting one of > proposals A, B, C, D. If proposal D is selected, please note > if you support none, one, or both of sub-choices D_1 or D_2. > > The straw poll will close at 5pm EST on Monday, March 7th. > > - Ted > > > Issue: If a receiver doesn't support ESN, they require the > sender to send an ESN transform > > Some systems know that they don't support ESN, and therefore > they require the other side to actively say they won't expect > it. The only way for the other side to do so is for it to > send a Transform Type > 5 with a value of 0. However, there is no way for the > responder to say that to the initiator, so interoperability > is not possible. > > There are four ways that have been discussed to resolve this issue: > > PROPOSAL A: > ----------- > > The last sentence of 3.3.2 says: > If Transform Type 5 is not included in a proposal, use of > Extended Sequence Numbers is assumed. > Replace this with: > If Transform Type 5 is not included in a proposal, it is > assumed that the sending party does not support Extended > Sequence Numbers. > > PROPOSAL B: > ----------- > > Create a new response notification that says "I can't do ESN, > start again and include a 'no ESN' transform." [Note during > the discussion on the mailig list, little or no support was > seen for this alternative. > > PROPOSAL C: > ----------- > > Change the places that says Transform Type 5 is optional to > say it is mandatory. > > PROPOSAL D: > ----------- > > Make a clarification (that would go into Pasi's clarification > document) that would add a sentence to the end of Section > 3.3.2 that says "Note that if the initiator is willing to > accept either the use of extended sequence numbers or not, > the initiator SHOULD send this transform in its proposals." > > PROPOSAL D_1: > ------------- > Do suggestion D above, but place the clarification in IKEv2. > > PROPOSAL D_2: > ------------- > Do Suggestion D_1 only if it can be done without delaying the > publication of IKEv2. > > > _______________________________________________ > 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 Sat Mar 5 23:37:20 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14699 for ; Sat, 5 Mar 2005 23:37:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7nTn-00073Z-Nb; Sat, 05 Mar 2005 23:34:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7nT1-0006xI-9E for ipsec@megatron.ietf.org; Sat, 05 Mar 2005 23:34:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14525 for ; Sat, 5 Mar 2005 23:34:08 -0500 (EST) Received: from web90006.mail.scd.yahoo.com ([66.218.94.64]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D7nUv-00049P-8S for ipsec@ietf.org; Sat, 05 Mar 2005 23:36:09 -0500 Received: (qmail 3984 invoked by uid 60001); 6 Mar 2005 04:34:00 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=ZsrX/XhUWZL7LCI/ZRpo4SUDOf8DBV6f43DXd5t8iaMATR9Erj7dDIsLpdH4pcUB5eKvWBABeImGgZcO77Q8EuAg0nibKo/GERzakzSwAMessfLe6s8IGPZn+hbAgfj1xLLRNFlAVGi3s0IV97USxjZybbDxgXB55L0DaBB3bAQ= ; Message-ID: <20050306043400.3982.qmail@web90006.mail.scd.yahoo.com> Received: from [68.127.185.34] by web90006.mail.scd.yahoo.com via HTTP; Sat, 05 Mar 2005 20:34:00 PST Date: Sat, 5 Mar 2005 20:34:00 -0800 (PST) From: Surya Batchu Subject: Re: [Ipsec] message IDs and window size in IKEv2 To: Surya Batchu , Tero Kivinen , vjyothi@intoto.com In-Reply-To: <20050304182718.18042.qmail@web90006.mail.scd.yahoo.com> MIME-Version: 1.0 X-Spam-Score: 0.5 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0625065245==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0625065245== Content-Type: multipart/alternative; boundary="0-2128819413-1110083640=:2587" --0-2128819413-1110083640=:2587 Content-Type: text/plain; charset=us-ascii I see one need for window change as in IPsec anti-replay window. IPsec anti replay window changes with the sequence number, if its value is more than the right edge of window. With strict windowing as defined in specifications, it makes it difficult to make IKEv2 work in high availability environment. Take an example of two VPN devices - one acting as active and another one acting as backup for the first one. If state-ful failover is required, then the active device needs to update the backup device with IKEv2 state. IKEv2 SA creation and deletion are two obvious events that need to be synchronized with the backup device. Due to rigidity of specification in this aspect, IKEv2 state needs to be updated with every change in window. Even with the best effort, it is possible that window events may not get synchronized at the backup device. If windows change is possible, then backup device, (when master device fails) can start with higher message id and then onwards new transactions will work fine. Comments? Thanks Surya Surya Batchu wrote: > My feeling is that it SHOULD accept the messages because the message IDs > are authenticated. If the messages are authenticated properly, it means that the initiator is not following the spec or there is attacker on the wire who has broken the keying material. In any case the initiator and responder has ended up in the inconsistent state, which means that responder should probably tear down the IKE SA and start over. I undestand that the draft specification does not allow this. What is the problem in accepting new message ID, as long as message ID value is not less than the expected sequence number. New message ID can be treated as right edge of window and adjust the window accordingly. Surya --------------------------------- Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --0-2128819413-1110083640=:2587 Content-Type: text/html; charset=us-ascii
I see one need for window change as in IPsec anti-replay window. IPsec anti replay window changes with the sequence number, if its value is more than the right edge of window.
 
With strict windowing as defined in specifications, it makes it difficult to make IKEv2 work in high availability environment.
 
Take an example of two VPN devices - one acting as active and another one acting as backup for the first one. If state-ful failover is required, then the active device needs to update the backup device with  IKEv2 state. IKEv2 SA creation and deletion are two obvious events that need to be synchronized with the backup device. Due to rigidity of specification in this aspect, IKEv2 state needs to be updated with every change in window. Even with the best effort, it is possible that window events may not get synchronized at the backup device.
 
If windows change is possible, then backup device, (when master device fails) can start with higher message id and then onwards new transactions will  work fine.
 
Comments?
 
Thanks
Surya
 

Surya Batchu <suryak_batchu@yahoo.com> wrote:

> My feeling is that it SHOULD accept the messages because the message IDs
> are authenticated.

If the messages are authenticated properly, it means that the
initiator is not following the spec or there is attacker on the wire
who has broken the keying material. In any case the initiator and
responder has ended up in the inconsistent state, which means that
responder should probably tear down the IKE SA and start over.

I undestand that the draft specification does not allow this. What is the problem in accepting new message ID, as long as message ID value is not less than the expected sequence number.  New message ID can be treated as right edge of window and adjust the window accordingly.

Surya

Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web _______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com --0-2128819413-1110083640=:2587-- --===============0625065245== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0625065245==-- From ipsec-bounces@ietf.org Sun Mar 6 12:12:18 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27549 for ; Sun, 6 Mar 2005 12:12:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7zHU-0002j0-IX; Sun, 06 Mar 2005 12:11:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D7zHR-0002hS-K7 for ipsec@megatron.ietf.org; Sun, 06 Mar 2005 12:11:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27342 for ; Sun, 6 Mar 2005 12:10:58 -0500 (EST) Received: from mail-eur1.microsoft.com ([213.199.128.139]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D7zJR-0007Yx-LS for ipsec@ietf.org; Sun, 06 Mar 2005 12:13:06 -0500 Received: from EUR-MSG-20.europe.corp.microsoft.com ([65.53.210.18]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Sun, 6 Mar 2005 17:10:47 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] STRAW POLL: Dealing with the ESN negotiation interop issuein IKEv2 Date: Sun, 6 Mar 2005 17:10:48 -0000 Message-ID: <892867B805D4DA42A1C48103BF4CFA5A0126BE2B@EUR-MSG-20.europe.corp.microsoft.com> Thread-Topic: [Ipsec] STRAW POLL: Dealing with the ESN negotiation interop issuein IKEv2 thread-index: AcUg8nBNyQYasSZRTEa2kn/BL63w9wBfNp0g From: "Michael Roe" To: X-OriginalArrivalTime: 06 Mar 2005 17:10:47.0453 (UTC) FILETIME=[7086E4D0:01C5226F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I prefer proposal C. > PROPOSAL C: > ----------- >=20 > Change the places that says Transform Type 5 is optional to say > it is mandatory. >=20 Mike _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Mar 6 18:07:10 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06808 for ; Sun, 6 Mar 2005 18:07:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D84le-0000sb-LF; Sun, 06 Mar 2005 18:02:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D84lc-0000sW-Tq for ipsec@megatron.ietf.org; Sun, 06 Mar 2005 18:02:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06216 for ; Sun, 6 Mar 2005 18:02:29 -0500 (EST) Received: from borg.juniper.net ([207.17.137.119]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D84ng-0000Cf-8h for ipsec@ietf.org; Sun, 06 Mar 2005 18:04:41 -0500 Received: from unknown (HELO gamma.jnpr.net) (172.24.245.25) by borg.juniper.net with ESMTP; 06 Mar 2005 15:02:23 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,139,1107763200"; d="scan'208"; a="238696092:sNHT16047744" Received: from hadron.jnpr.net ([172.24.15.25]) by gamma.jnpr.net with Microsoft SMTPSVC(6.0.3790.211); Sun, 6 Mar 2005 15:02:22 -0800 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] STRAW POLL: Dealing with the ESN negotiation interop issuein IKEv2 Date: Sun, 6 Mar 2005 15:02:21 -0800 Message-ID: Thread-Topic: [Ipsec] STRAW POLL: Dealing with the ESN negotiation interop issuein IKEv2 Thread-Index: AcUg8dpHFzz87gXATiqmjmmPv2P5rwBrpTbg From: "Timothy Liu" To: "Theodore Ts'o" , X-OriginalArrivalTime: 06 Mar 2005 23:02:22.0385 (UTC) FILETIME=[8E161210:01C522A0] X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Proposal A. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Mar 7 06:35:13 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01530 for ; Mon, 7 Mar 2005 06:35:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8GRw-00008F-R9; Mon, 07 Mar 2005 06:31:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8GRv-00008A-3Z for ipsec@megatron.ietf.org; Mon, 07 Mar 2005 06:30:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00868 for ; Mon, 7 Mar 2005 06:30:55 -0500 (EST) Received: from mxs2.siemens.at ([194.138.12.133]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8GTk-0008Ji-GA for ipsec@ietf.org; Mon, 07 Mar 2005 06:33:13 -0500 Received: from vies1kbx.sie.siemens.at ([158.226.129.82]) by mxs2.siemens.at with ESMTP id j27BSV3R012167 for ; Mon, 7 Mar 2005 12:28:31 +0100 Received: from vies141a.sie.siemens.at ([158.226.129.98]) by vies1kbx.sie.siemens.at (8.12.11/8.12.1) with ESMTP id j27BUQxh016499 for ; Mon, 7 Mar 2005 12:30:26 +0100 Received: by vies141a.sie.siemens.at with Internet Mail Service (5.5.2653.19) id ; Mon, 7 Mar 2005 12:31:15 +0100 Message-ID: <4D50D5110555D5119F270800062B41650532ACF8@viee10pa.erd.siemens.at> From: Grubmair Peter To: "IPsec WG (ipsec@ietf.org)" Subject: AW: [Ipsec] STRAW POLL: Dealing with the ESN negotiation interop issue in IKEv2 Date: Mon, 7 Mar 2005 12:29:49 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8eae9af85e4fcfe76f325e38493bf4 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Proposal C - make it mandatory _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Mar 7 16:53:42 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08143 for ; Mon, 7 Mar 2005 16:53:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8Q83-0002iQ-TT; Mon, 07 Mar 2005 16:51:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8Q7z-0002iL-0N for ipsec@megatron.ietf.org; Mon, 07 Mar 2005 16:51:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08003 for ; Mon, 7 Mar 2005 16:51:00 -0500 (EST) Received: from ns.ca.certicom.com ([66.48.18.197] helo=mail.ca.certicom.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D8QAE-0007fi-Ct for ipsec@ietf.org; Mon, 07 Mar 2005 16:53:23 -0500 Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 4C39E10079 for ; Mon, 7 Mar 2005 16:50:48 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02357-05 for ; Mon, 7 Mar 2005 16:50:37 -0500 (EST) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 0669E10083 for ; Mon, 7 Mar 2005 16:50:37 -0500 (EST) To: ipsec@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Tom Stiemerling Date: Mon, 7 Mar 2005 16:41:46 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 03/07/2005 04:41:47 PM, Serialize complete at 03/07/2005 04:41:47 PM X-Spam-Score: 0.5 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Subject: [Ipsec] interop testing 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="===============0897967969==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============0897967969== Content-Type: multipart/alternative; boundary="=_alternative 0078436285256FBD_=" This is a multipart message in MIME format. --=_alternative 0078436285256FBD_= Content-Type: text/plain; charset="US-ASCII" Anybody out there who was at the IKEv2 bake-off, or otherwise, interested in doing more interop testing? We are looking for responders to test our initiator implementation. Please contact me at tstiemer AT certicom DOT com. Thanks! --=_alternative 0078436285256FBD_= Content-Type: text/html; charset="US-ASCII"
Anybody out there who was at the IKEv2 bake-off, or otherwise,
interested in doing more interop testing? We are looking for
responders to test our initiator implementation. Please contact
me at tstiemer AT certicom DOT com.

Thanks! --=_alternative 0078436285256FBD_=-- --===============0897967969== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0897967969==-- From ipsec-bounces@ietf.org Tue Mar 8 09:58:30 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01359 for ; Tue, 8 Mar 2005 09:58:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8g7m-0000M4-NR; Tue, 08 Mar 2005 09:55:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D8g7k-0000Lu-EN for ipsec@megatron.ietf.org; Tue, 08 Mar 2005 09:55:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01039 for ; Tue, 8 Mar 2005 09:55:50 -0500 (EST) Received: from mx2.trusecure.com ([208.251.192.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D8gA8-0006Rf-LU for ipsec@ietf.org; Tue, 08 Mar 2005 09:58:21 -0500 Received: by mx2.trusecure.com (Postfix, from userid 1006) id DFD53C91EF; Tue, 8 Mar 2005 09:55:31 -0500 (EST) Received: from VAMAIL01.corp.trusecure.net (vamail01.corp.cybertrust.net [172.19.1.52]) by mx2.trusecure.com (Postfix) with ESMTP id D0948C91B6 for ; Tue, 8 Mar 2005 09:55:31 -0500 (EST) Received: from HRN-MSC-EXCH-01.mscore.trusecure.net (hrn-msc-exch-01.corp.cybertrust.net [172.19.1.49]) by VAMAIL01.corp.trusecure.net (8.12.10/maybe_its_not_even_really_Sendmail....) with ESMTP id j28EtVCZ011393 for ; Tue, 8 Mar 2005 09:55:31 -0500 (EST) Received: from hrn-msc-exch-02.mscore.trusecure.net ([172.19.1.56]) by HRN-MSC-EXCH-01.mscore.trusecure.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 8 Mar 2005 09:55:33 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 8 Mar 2005 09:55:33 -0500 Message-ID: <04D8F83756A1A84BA156BBFF26FAE0F5A7AF30@hrn-msc-exch-02.mscore.trusecure.net> Thread-Topic: IKEv2 Bakeoff #2 Thread-Index: AcUj7uCd2RH1vJZkR7yZvSfehgeyGQ== From: "Zimmerman, Mark" To: X-OriginalArrivalTime: 08 Mar 2005 14:55:33.0465 (UTC) FILETIME=[E10A1490:01C523EE] X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] IKEv2 Bakeoff #2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Another Bakeoff Interoperability event is being planned for the week of September 12th 2005 in Toronto, Canada. Details are being firmed up and will be posted on the ICSA Labs Web site. Results of the intial event held in Santa Clara are posted at: http://www.icsalabs.com/html/communities/ipsec/index.shtml Regards, Mark Zimmerman Program Manager ICSA Labs 1000 Bent Creek Blvd, Suite 200 Mechanicsburg PA 17050 Phone: 717.790.8144 Fax: 717.790.8170 mzimmerman@icsalabs.com www.icsalabs.com *********************************************************************** This message is intended only for the use of the intended recipient and may contain information that is PRIVILEGED and/or CONFIDENTIAL. If you are not the intended recipient, you are hereby notified that any use, dissemination, disclosure or copying of this communication is strictly prohibited. If you have received this communication in error, please destroy all copies of this message and its attachments and notify us immediately. *********************************************************************** _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Mar 10 06:02:14 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01517 for ; Thu, 10 Mar 2005 06:02:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9LOR-0006Km-Ic; Thu, 10 Mar 2005 05:59:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9LM7-000687-1d for ipsec@megatron.ietf.org; Thu, 10 Mar 2005 05:57:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA01228 for ; Thu, 10 Mar 2005 05:57:23 -0500 (EST) Received: from inet-tsb5.toshiba.co.jp ([202.33.96.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9LOm-0000wO-Jm for ipsec@ietf.org; Thu, 10 Mar 2005 06:00:19 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb5.toshiba.co.jp with ESMTP id j2AAvGL7017170 for ; Thu, 10 Mar 2005 19:57:16 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id j2AAvGnC019906 for ; Thu, 10 Mar 2005 19:57:16 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id VAA19904 ; Thu, 10 Mar 2005 19:57:16 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id j2AAvGTZ010687 for ; Thu, 10 Mar 2005 19:57:16 +0900 (JST) Received: by toshiba.co.jp id j2AAvFmP003491; Thu, 10 Mar 2005 19:57:15 +0900 (JST) Message-Id: <200503101057.j2AAvFmP003491@toshiba.co.jp> To: ipsec@ietf.org Date: Thu, 10 Mar 2005 19:57:14 +0900 From: Fukumoto Atsushi X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Subject: [Ipsec] IKEV2 questions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org draft-ietf-ipsec-ikev2-17.txt states in section 3.3.2: "If the initiator wishes to make use of the transform optional to the responder, it includes a transform substructure with transform ID = 0 as one of the options." and then: ---------------------------------------------------------------------- For Transform Type 5 (Extended Sequence Numbers), defined Transform IDs are: Name Number No Extended Sequence Numbers 0 Extended Sequence Numbers 1 RESERVED 2 - 65535 ---------------------------------------------------------------------- My question is: Am I right to understand that, if the initiator sends a transform with Transform Type 5 and Transform ID 0, it means No Extended Sequence Numbers, rather than Transform Optional to The Responder? Another question: section 2.18 states: "New initiator and responder SPIs are supplied in the SPI fields." Which SPI fields does this refer to? FUKUMOTO Atsushi atsushi.fukumoto@toshiba.co.jp _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Mar 10 07:21:52 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07582 for ; Thu, 10 Mar 2005 07:21:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9McO-0005rz-As; Thu, 10 Mar 2005 07:18:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9McM-0005rq-Mk for ipsec@megatron.ietf.org; Thu, 10 Mar 2005 07:18:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA07309 for ; Thu, 10 Mar 2005 07:18:15 -0500 (EST) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9Mf8-0004QG-HG for ipsec@ietf.org; Thu, 10 Mar 2005 07:21:12 -0500 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.7p1+Sun/8.11.6) with ESMTP id j2ACI5f22931; Thu, 10 Mar 2005 14:18:05 +0200 (IST) In-Reply-To: <200503101057.j2AAvFmP003491@toshiba.co.jp> References: <200503101057.j2AAvFmP003491@toshiba.co.jp> Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] IKEV2 questions Date: Thu, 10 Mar 2005 14:18:04 +0200 To: Fukumoto Atsushi X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Comments inline... On Mar 10, 2005, at 12:57 PM, Fukumoto Atsushi wrote: > > draft-ietf-ipsec-ikev2-17.txt states in section 3.3.2: "If the > initiator wishes to make use of the transform optional to the > responder, it includes a transform substructure with transform ID = 0 > as one of the options." > > and then: > ---------------------------------------------------------------------- > For Transform Type 5 (Extended Sequence Numbers), defined Transform > IDs are: > > Name Number > No Extended Sequence Numbers 0 > Extended Sequence Numbers 1 > RESERVED 2 - 65535 > ---------------------------------------------------------------------- > > > My question is: Am I right to understand that, if the initiator sends > a transform with Transform Type 5 and Transform ID 0, it means No > Extended Sequence Numbers, rather than Transform Optional to The > Responder? > Yes, you are right. Sending Type 5 ID 0 means no ESN. Type 5 ID 1 means ESN is mandatory. Sending both means it's optional. If you look up the archive, there was a lively discussion about this last week. > > Another question: section 2.18 states: "New initiator and responder > SPIs are supplied in the SPI fields." Which SPI fields does this > refer to? > This refers to the SPI fields of the Proposal structure in the SA payload. See section 3.3.1. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Mar 10 14:27:41 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21590 for ; Thu, 10 Mar 2005 14:27:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9TIc-0003hu-U7; Thu, 10 Mar 2005 14:26:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9TIa-0003hp-H8 for ipsec@megatron.ietf.org; Thu, 10 Mar 2005 14:26:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21418 for ; Thu, 10 Mar 2005 14:26:18 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9TLO-00013q-Qa for ipsec@ietf.org; Thu, 10 Mar 2005 14:29:18 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Thu, 10 Mar 2005 11:24:33 -0800 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1802); Thu, 10 Mar 2005 11:24:31 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 10 Mar 2005 11:24:29 -0800 Message-ID: Thread-Topic: Question / Remark on PRF/MAC in IKEv2 draft-spec (repeat) Thread-Index: AcUlWD+j6Mipw7K9TOmh/G6xtDis7gASru5w From: "Charlie Kaufman" To: , X-OriginalArrivalTime: 10 Mar 2005 19:24:31.0840 (UTC) FILETIME=[C9162E00:01C525A6] X-Spam-Score: 0.0 (/) X-Scan-Signature: d185fa790257f526fedfd5d01ed9c976 Content-Transfer-Encoding: quoted-printable Cc: Russ Housley , Paul Hoffman / VPNC Subject: [Ipsec] RE: Question / Remark on PRF/MAC in IKEv2 draft-spec (repeat) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable I don't know why your message was blocked from the ipsec list. Hopefully = my reply will make it and I've included your note below. In answer to your questions: 1) Yes, the label PRF_AES128_CBC in IKEv2 is inconsistent with the label = used for the same PRF function in RFC3664 where it is called = AES-XCBC-PRF-128. Part of this is because the IKEv2 document always puts = the algorithm type as the first element of the name (in this case PRF). = But it seems potentially confusing (to say the least) to have the IKEv2 = spec say CBC while RFC3664 says XCBC since these imply different = algorithms. I believe the intent was to use the XCBC algorithm and that the IKEv2 = spec is in error. I propose changing the IKEv2 spec during AUTH48 to = specify PRF_AES128_XCBC to reduce possible confusion. The IKEv2 already = refers to RFC3664 for the definition of the algorithm. 2) The current spec says that when using shared keys the AUTH payload is = computed using the negotiated PRF algorithm. One could argue that it = would be cryptographically preferable to do the outer computation with = the negotiated MAC algorithm rather than the negotiated PRF algorithm, = but I don't believe there are any weaknesses introduced by using the PRF = so I don't believe it should be changed at this late date given that = there are working implementations that such a change would break. Paul... can you confirm that PRF is what the implementations in the = bakeoff used? --Charlie ________________________________________ From: ventzislav.nikov@philips.com [mailto:ventzislav.nikov@philips.com] = Sent: Thursday, March 10, 2005 2:01 AM To: ipsec@lists.tislabs.com; Charlie Kaufman Subject: Question / Remark on PRF/MAC in IKEv2 draft-spec (repeat) Hello,=20 I send again the mail from 28.02.05 sent to ipsec@ietf.org which is = still waiting for the approval ?!?=20 ---------------=20 Your mail to 'Ipsec' with the subject =A0 =A0Question / Remark on PRF/MAC in IKEv2 draft-spec Is being held until the list moderator can review it for approval.=20 -----------------=20 1) In the draft-ietf-ipsec-ikev2-xx the PRF (pseudo random function) is = specified to has tag:=20 PRF_AES128_CBC (referring to RFC3664), but in RFC 3664 it is=20 "The AES-XCBC-PRF-128 Algorithm for the IKE".=20 So it is not CBC but XCBC right? 2)=20 In Section 2.15 "Authentication of the IKE_SA" the AUTH field is = explained.=20 First the document states that the signature or MAC is computed over a = with a .=20 In case the key is symmetric (e.g. derived from EAP-SIM subprotocol into = IKEv2) the document states that=20 AUTH =3D prf(prf(,"Key Pad for IKEv2"), ) i.e.=20 deciphered it is NewKey =3D prf(,"Key Pad for IKEv2") and then AUTH = =3D prf(NewKey, ).=20 But what I expected instead is AUTH =3D MAC(NewKey, ).=20 Note that there is subtle difference between PRF and MAC as = cryptographic functions from one side and=20 from other side (practical) even the algorithms are the same (e.g. = HMAC-MD5, HMAC-SHA1, AES-XCBC)=20 MAC is always truncated to 96 bits!=20 So, could you confirm that AUTH is computed using MAC instead of PRF?=20 Regards=20 Ventzislav Nikov _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Mar 10 14:38:21 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23020 for ; Thu, 10 Mar 2005 14:38:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9TRt-0005nm-Ri; Thu, 10 Mar 2005 14:35:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9TRs-0005nh-Ur for ipsec@megatron.ietf.org; Thu, 10 Mar 2005 14:35:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22650 for ; Thu, 10 Mar 2005 14:35:55 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9TUj-0001eC-CD for ipsec@ietf.org; Thu, 10 Mar 2005 14:38:54 -0500 Received: from [130.129.132.243] (wireless-130-129-132-243.ietf62.ietf.org [130.129.132.243]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2AJZqTj053279; Thu, 10 Mar 2005 11:35:53 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 10 Mar 2005 13:36:00 -0600 To: "Charlie Kaufman" , , From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Russ Housley Subject: [Ipsec] RE: Question / Remark on PRF/MAC in IKEv2 draft-spec (repeat) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 11:24 AM -0800 3/10/05, Charlie Kaufman wrote: >2) The current spec says that when using shared keys the AUTH >payload is computed using the negotiated PRF algorithm. One could >argue that it would be cryptographically preferable to do the outer >computation with the negotiated MAC algorithm rather than the >negotiated PRF algorithm, but I don't believe there are any >weaknesses introduced by using the PRF so I don't believe it should >be changed at this late date given that there are working >implementations that such a change would break. > >Paul... can you confirm that PRF is what the implementations in the >bakeoff used? You should check this with Tero and/or Geoffrey. However, since I didn't hear than anyone had any problem with this part of the spec, I suspect everyone understood that it was PRF. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Mar 11 00:24:19 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18934 for ; Fri, 11 Mar 2005 00:24:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9cbG-0001Wb-7z; Fri, 11 Mar 2005 00:22:14 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9cbD-0001WW-Bb for ipsec@megatron.ietf.org; Fri, 11 Mar 2005 00:22:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA18773 for ; Fri, 11 Mar 2005 00:22:08 -0500 (EST) Received: from inet-tsb5.toshiba.co.jp ([202.33.96.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9ce8-0005qi-KR for ipsec@ietf.org; Fri, 11 Mar 2005 00:25:14 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb5.toshiba.co.jp with ESMTP id j2B5M6L7001680 for ; Fri, 11 Mar 2005 14:22:06 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id j2B5M6KX027644 for ; Fri, 11 Mar 2005 14:22:06 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id QAA27639 ; Fri, 11 Mar 2005 14:22:06 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id j2B5M6h0024979 for ; Fri, 11 Mar 2005 14:22:06 +0900 (JST) Received: by toshiba.co.jp id j2B5M3so012198; Fri, 11 Mar 2005 14:22:03 +0900 (JST) Message-Id: <200503110522.j2B5M3so012198@toshiba.co.jp> To: ipsec@ietf.org Subject: Re: [Ipsec] IKEV2 questions In-reply-to: ynir's message of "Thu, 10 Mar 2005 14:18:04 +0200." Date: Fri, 11 Mar 2005 14:22:02 +0900 From: Fukumoto Atsushi X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Yoav Nir answered: > > My question is: Am I right to understand that, if the initiator sends > > a transform with Transform Type 5 and Transform ID 0, it means No > > Extended Sequence Numbers, rather than Transform Optional to The > > Responder? > > > > Yes, you are right. Sending Type 5 ID 0 means no ESN. Type 5 ID 1 > means ESN is mandatory. Sending both means it's optional. If you look > up the archive, there was a lively discussion about this last week. > Then I have to wonder why it is that way? It looks like replacing No ESN to some other value and ID=0 to mean Optional seems to be more consistent with other transform types. FUKUMOTO Atsushi atsushi.fukumoto@toshiba.co.jp _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Mar 11 01:06:34 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22986 for ; Fri, 11 Mar 2005 01:06:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9dEV-0000VQ-9h; Fri, 11 Mar 2005 01:02:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9dEP-0000VI-Oh for ipsec@megatron.ietf.org; Fri, 11 Mar 2005 01:02:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA22595 for ; Fri, 11 Mar 2005 01:02:41 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9dHM-0007lP-OO for ipsec@ietf.org; Fri, 11 Mar 2005 01:05:45 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 10 Mar 2005 23:20:05 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,155,1107734400"; d="scan'208"; a="233820316:sNHT22187892" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2B62OuE024364; Thu, 10 Mar 2005 22:02:26 -0800 (PST) Received: from ghuangw2k01 ([10.32.227.21]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id BCS52521; Thu, 10 Mar 2005 22:02:26 -0800 (PST) Message-Id: <200503110602.BCS52521@mira-sjc5-b.cisco.com> From: "Geoffrey Huang" To: "'Paul Hoffman'" , "'Charlie Kaufman'" , , Subject: RE: [Ipsec] RE: Question / Remark on PRF/MAC in IKEv2 draft-spec(repeat) Date: Thu, 10 Mar 2005 22:02:26 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 Thread-Index: AcUlq1xpkwB9W0HDRiOKwqnE9bKc6wAVC2bQ X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: "'Russ Housley'" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Yes, I understood it to be PRF. -g > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Paul Hoffman > Sent: Thursday, March 10, 2005 11:36 AM > To: Charlie Kaufman; ventzislav.nikov@philips.com; ipsec@ietf.org > Cc: Russ Housley > Subject: [Ipsec] RE: Question / Remark on PRF/MAC in IKEv2 > draft-spec(repeat) > > At 11:24 AM -0800 3/10/05, Charlie Kaufman wrote: > >2) The current spec says that when using shared keys the > AUTH payload > >is computed using the negotiated PRF algorithm. One could > argue that it > >would be cryptographically preferable to do the outer > computation with > >the negotiated MAC algorithm rather than the negotiated PRF > algorithm, > >but I don't believe there are any weaknesses introduced by using the > >PRF so I don't believe it should be changed at this late date given > >that there are working implementations that such a change > would break. > > > >Paul... can you confirm that PRF is what the implementations in the > >bakeoff used? > > You should check this with Tero and/or Geoffrey. However, > since I didn't hear than anyone had any problem with this > part of the spec, I suspect everyone understood that it was PRF. > > --Paul Hoffman, Director > --VPN Consortium > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Mar 11 09:47:36 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA28210 for ; Fri, 11 Mar 2005 09:47:36 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9lOs-0001vo-IL; Fri, 11 Mar 2005 09:46:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9lOq-0001vd-Vd for ipsec@megatron.ietf.org; Fri, 11 Mar 2005 09:46:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27997 for ; Fri, 11 Mar 2005 09:45:59 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9lRr-00070q-F1 for ipsec@ietf.org; Fri, 11 Mar 2005 09:49:08 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j2BEjsCj007901 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 11 Mar 2005 16:45:55 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j2BEjrae007898; Fri, 11 Mar 2005 16:45:53 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16945.44832.902817.576939@fireball.kivinen.iki.fi> Date: Fri, 11 Mar 2005 16:45:52 +0200 From: Tero Kivinen To: Fukumoto Atsushi Subject: Re: [Ipsec] IKEV2 questions In-Reply-To: <200503110522.j2B5M3so012198@toshiba.co.jp> References: <200503110522.j2B5M3so012198@toshiba.co.jp> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 0 min X-Total-Time: 0 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Fukumoto Atsushi writes: > Then I have to wonder why it is that way? It looks like replacing No > ESN to some other value and ID=0 to mean Optional seems to be more > consistent with other transform types. Or simply make it mandatory, so it cannot be left out. That will work with existing implementations too. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Mar 11 11:15:06 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09336 for ; Fri, 11 Mar 2005 11:15:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9mlY-0002aW-P9; Fri, 11 Mar 2005 11:13:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9mlW-0002aO-W0 for ipsec@megatron.ietf.org; Fri, 11 Mar 2005 11:13:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA09239 for ; Fri, 11 Mar 2005 11:13:29 -0500 (EST) Received: from web52510.mail.yahoo.com ([206.190.39.135]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D9moY-0003Nj-Sf for ipsec@ietf.org; Fri, 11 Mar 2005 11:16:39 -0500 Received: (qmail 14656 invoked by uid 60001); 11 Mar 2005 16:12:51 -0000 Message-ID: <20050311161251.14650.qmail@web52510.mail.yahoo.com> Received: from [67.123.175.226] by web52510.mail.yahoo.com via HTTP; Fri, 11 Mar 2005 08:12:50 PST Date: Fri, 11 Mar 2005 08:12:50 -0800 (PST) From: Saroop Mathur Subject: Re: [Ipsec] IKEV2 questions To: Fukumoto Atsushi , ipsec@ietf.org In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --- Fukumoto Atsushi wrote: > Then I have to wonder why it is that way? It looks like replacing No > ESN to some other value and ID=0 to mean Optional seems to be more > consistent with other transform types. Agreed that 0 should not have been defined as a transform value for ESN. But ID-O does not mean Optional for other transform types. ID-0 is a reserved value for most transform types and cannot be send in a SA proposal. -Saroop _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Mar 11 13:21:27 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23611 for ; Fri, 11 Mar 2005 13:21:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9ohV-0001K9-EY; Fri, 11 Mar 2005 13:17:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D9ohT-0001Ju-6h for ipsec@megatron.ietf.org; Fri, 11 Mar 2005 13:17:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23284 for ; Fri, 11 Mar 2005 13:17:24 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D9okU-00027p-TY for ipsec@ietf.org; Fri, 11 Mar 2005 13:20:36 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j2BIHMTq009976 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 11 Mar 2005 20:17:23 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j2BIHLDQ009973; Fri, 11 Mar 2005 20:17:21 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16945.57521.724349.384974@fireball.kivinen.iki.fi> Date: Fri, 11 Mar 2005 20:17:21 +0200 From: Tero Kivinen To: Saroop Mathur Subject: Re: [Ipsec] IKEV2 questions In-Reply-To: <20050311161251.14650.qmail@web52510.mail.yahoo.com> References: <20050311161251.14650.qmail@web52510.mail.yahoo.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 7 min X-Total-Time: 6 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Saroop Mathur writes: > Agreed that 0 should not have been defined as a transform value for > ESN. But ID-O does not mean Optional for other transform types. ID-0 is > a reserved value for most transform types and cannot be send in a SA > proposal. Actually not so. ID=0 is reserved in Encryption Algorithm nad Pseudo-random function. ID=0 is NONE for Integrity Algorithm and Diffie-Hellman Group. And if only value you would be sending would be NONE, then you are allowed to leave out the whole transform type (3.3.3 last sentence). As ID=0 is not NONE but "No extended sequence numbers" in the Extended sequence numbers transform type, it cause confusion when combined with 3.3.3.3. My recommendation is that we modify the 3.3.2 by removing the "If Transform Type 5 is not included in a proposal, use of Extended Sequence Numbers is assumed." and also modifying the Transform type values table to say "Extended Sequence Numbers (ESN) 5 (AH and ESP)" and also modifying the 3.3.3 so that we move ESN from Optional Types to Mandatory Types for ESP and AH. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Mar 14 16:08:00 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22262 for ; Mon, 14 Mar 2005 16:08:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAwgb-0006Zw-S9; Mon, 14 Mar 2005 16:01:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DAwga-0006Zr-8M for ipsec@megatron.ietf.org; Mon, 14 Mar 2005 16:01:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21216 for ; Mon, 14 Mar 2005 16:01:09 -0500 (EST) Received: from neon.tcs.hut.fi ([130.233.215.20]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DAwkF-0004yZ-V4 for ipsec@ietf.org; Mon, 14 Mar 2005 16:05:01 -0500 Received: from rhea.tcs.hut.fi (rhea.tcs.hut.fi [130.233.215.147]) by neon.tcs.hut.fi (Postfix) with ESMTP id 3CC1C8000B9 for ; Mon, 14 Mar 2005 23:00:59 +0200 (EET) Date: Mon, 14 Mar 2005 23:00:59 +0200 (EET) From: Wassim Haddad To: ipsec@ietf.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Ipsec] IKEv2 Tutorial X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, A question/comment on the IKEv2 Tutorial draft (Understanding IKEv2: Tutorial, and rationale for decisions): Would it be possible to update the existing old one and publish it as an informational RFC? Regards, Wassim H. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Mar 14 19:53:39 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13717 for ; Mon, 14 Mar 2005 19:53:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB0GF-0001cT-GM; Mon, 14 Mar 2005 19:50:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB0GE-0001cO-I6 for ipsec@megatron.ietf.org; Mon, 14 Mar 2005 19:50:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA13271 for ; Mon, 14 Mar 2005 19:50:11 -0500 (EST) Received: from thunk.org ([69.25.196.29] helo=thunker.thunk.org) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DB0Jw-0007F0-MI for ipsec@ietf.org; Mon, 14 Mar 2005 19:54:05 -0500 Received: from root (helo=thunk.org) by thunker.thunk.org with local-esmtp (Exim 3.35 #1 (Debian)) id 1DB0GB-0001KD-00; Mon, 14 Mar 2005 19:50:11 -0500 Received: from tytso by thunk.org with local (Exim 4.50) id 1DB0GA-00040P-Ox; Mon, 14 Mar 2005 19:50:10 -0500 To: ipsec@ietf.org From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Mon, 14 Mar 2005 19:50:10 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: "Theodore Y. Ts'o" , Charlie Kaufman , Russ Housley , Barbara Fraser Subject: [Ipsec] Results of straw poll regarding: IKEv2 interoperability issue X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Two weeks ago, there was a discussion about an interoperability problem in IKEv2 that was turned up during interoperability testing. A week ago, I called for a straw poll; based on the fact that the number of responses was a little sparse, and last week was the Minneapolis IETF, I let the straw poll go on all last week. The straw poll indicated a majority (although certainly not unanimity) preference for proposal C: PROPOSAL C: ----------- Change the places that says Transform Type 5 is optional to say it is mandatory. This choice unfortunately would require making changes to the IKEv2 RFC before it is published, and since it has already been through the IESG approval process and almost through the entire RFC editor process, presumably we would need to make a new I-D and then take it through most of this process all over again --- although hopefully it would take much less time the second time around. Russ, would you comment if there is anything special we need to do at this point? Many thanks, - Ted Proposal A: Kevin Li Timothy Liu Proposal C: Srinivasa Rao Addepalli Geoffrey Huang Michael Roe Grubmair Peter Tero Kivinen Geoffrey Huang Proposal D: Paul Hoffman Pasi.Eronen@nokia.com Yoav Nir _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Mar 14 21:56:38 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24657 for ; Mon, 14 Mar 2005 21:56:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB2C0-0006o7-Rd; Mon, 14 Mar 2005 21:54:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DB2Bz-0006nw-8Q for ipsec@megatron.ietf.org; Mon, 14 Mar 2005 21:53:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA24366 for ; Mon, 14 Mar 2005 21:53:56 -0500 (EST) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DB2Fi-0004EX-7e for ipsec@ietf.org; Mon, 14 Mar 2005 21:57:51 -0500 Received: from phys-bur1-1 ([129.148.13.15]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j2F2ruX8028746 for ; Mon, 14 Mar 2005 19:53:56 -0700 (MST) Received: from conversion-daemon.bur-mail2.east.sun.com by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IDD00K01GOIY9@bur-mail2.east.sun.com> (original mail from Radia.Perlman@Sun.COM) for ipsec@ietf.org; Mon, 14 Mar 2005 21:53:56 -0500 (EST) Received: from sun.com (vpn-129-150-25-171.SFBay.Sun.COM [129.150.25.171]) by bur-mail2.east.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTPA id <0IDD00972HDULR@bur-mail2.east.sun.com>; Mon, 14 Mar 2005 21:53:56 -0500 (EST) Date: Mon, 14 Mar 2005 18:53:56 -0800 From: Radia Perlman Subject: Re: [Ipsec] IKEv2 Tutorial In-reply-to: To: Wassim Haddad Message-id: <42364E44.2000003@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4.1) Gecko/20031008 References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7BIT Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7BIT I am planning on doing that. I was hoping to capture all the contentious issues, and I guess I was waiting for no more issues to crop up. Thanks for reminding me. Radia Wassim Haddad wrote: >Hi, > >A question/comment on the IKEv2 Tutorial draft (Understanding IKEv2: >Tutorial, and rationale for decisions): >Would it be possible to update the existing old one and publish it >as an informational RFC? > > >Regards, > >Wassim H. > > >_______________________________________________ >Ipsec mailing list >Ipsec@ietf.org >https://www1.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Mar 15 10:42:32 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07431 for ; Tue, 15 Mar 2005 10:42:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBDma-0004dd-TI; Tue, 15 Mar 2005 10:16:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBDmX-0004UG-JK for ipsec@megatron.ietf.org; Tue, 15 Mar 2005 10:16:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA27066 for ; Tue, 15 Mar 2005 10:16:27 -0500 (EST) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DBDqO-0003m7-0Y for ipsec@ietf.org; Tue, 15 Mar 2005 10:20:28 -0500 Received: (qmail 31543 invoked by uid 0); 15 Mar 2005 15:13:37 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.155.78) by woodstock.binhost.com with SMTP; 15 Mar 2005 15:13:37 -0000 Message-Id: <6.2.0.14.2.20050315100106.0624c8e0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Tue, 15 Mar 2005 10:13:27 -0500 To: "Theodore Ts'o" , ipsec@ietf.org From: Russ Housley In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: 41c17b4b16d1eedaa8395c26e9a251c4 Cc: Charlie Kaufman , Barbara Fraser Subject: [Ipsec] Re: Results of straw poll regarding: IKEv2 interoperability issue X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Ted: The fact that so few people responded to the straw poll causes alarm. The issue was raised at a bake-off, and some of the implementations represented at the bake-off are not represented in the straw poll responses. I have a question: Do you believe that this response represents WG consensus? If so, then please prepare an RFC Editor note that describes the change that needs to be made, send it to me, and I will work with the IESG to get it approved. If not, then we should not make any changes. The WG chairs must judge consensus. In this case, it is a subjective decision, and you may want to consult with WG participants that did not respond to the straw poll to figure it out. At least one person that was at the bake-off has told me that they had come up with a way to achieve interoperability without making changes. I think Paul Hoffman made a posting to the mail list about that approach half way through the straw poll. This is just one more dimension of your consensus decision. Russ At 07:50 PM 3/14/2005, Theodore Ts'o wrote: >Two weeks ago, there was a discussion about an interoperability problem >in IKEv2 that was turned up during interoperability testing. A week >ago, I called for a straw poll; based on the fact that the number of >responses was a little sparse, and last week was the Minneapolis IETF, I >let the straw poll go on all last week. > >The straw poll indicated a majority (although certainly not unanimity) >preference for proposal C: > > PROPOSAL C: > ----------- > > Change the places that says Transform Type 5 is optional to say > it is mandatory. > >This choice unfortunately would require making changes to the IKEv2 RFC >before it is published, and since it has already been through the IESG >approval process and almost through the entire RFC editor process, >presumably we would need to make a new I-D and then take it through most >of this process all over again --- although hopefully it would take much >less time the second time around. > >Russ, would you comment if there is anything special we need to do at >this point? Many thanks, > > - Ted > > >Proposal A: > Kevin Li > Timothy Liu > >Proposal C: > Srinivasa Rao Addepalli > Geoffrey Huang > Michael Roe > Grubmair Peter > Tero Kivinen > Geoffrey Huang > >Proposal D: > Paul Hoffman > Pasi.Eronen@nokia.com > Yoav Nir _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Mar 15 10:51:10 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA10200 for ; Tue, 15 Mar 2005 10:51:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBDgY-0001nx-OY; Tue, 15 Mar 2005 10:10:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DBDgS-0001ml-HS; Tue, 15 Mar 2005 10:10:12 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25016; Tue, 15 Mar 2005 10:10:10 -0500 (EST) Message-Id: <200503151510.KAA25016@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Tue, 15 Mar 2005 10:10:10 -0500 Cc: ipsec@ietf.org Subject: [Ipsec] I-D ACTION:draft-ietf-ipsec-esp-v3-10.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IP Encapsulating Security Payload (ESP) Author(s) : S. Kent Filename : draft-ietf-ipsec-esp-v3-10.txt Pages : 47 Date : 2005-3-10 This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-10.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-esp-v3-10.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-esp-v3-10.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-3-15102952.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-esp-v3-10.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-esp-v3-10.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-15102952.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --NextPart-- From ipsec-bounces@ietf.org Thu Mar 17 18:15:09 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA02360 for ; Thu, 17 Mar 2005 18:15:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC46u-00007B-0F; Thu, 17 Mar 2005 18:09:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC46r-000076-Kt for ipsec@megatron.ietf.org; Thu, 17 Mar 2005 18:08:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA01515 for ; Thu, 17 Mar 2005 18:08:54 -0500 (EST) Received: from ns.ca.certicom.com ([66.48.18.197] helo=mail.ca.certicom.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DC4BB-00019a-1L for ipsec@ietf.org; Thu, 17 Mar 2005 18:13:26 -0500 Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 3551110094 for ; Thu, 17 Mar 2005 18:08:47 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29249-38 for ; Thu, 17 Mar 2005 18:08:35 -0500 (EST) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 8D3E21008A for ; Thu, 17 Mar 2005 18:08:35 -0500 (EST) To: ipsec@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Tom Stiemerling Date: Thu, 17 Mar 2005 17:59:21 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 03/17/2005 05:59:23 PM, Serialize complete at 03/17/2005 05:59:23 PM X-Spam-Score: 0.5 (/) X-Scan-Signature: d8ae4fd88fcaf47c1a71c804d04f413d Subject: [Ipsec] handling delete payloads 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="===============0039697688==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============0039697688== Content-Type: multipart/alternative; boundary="=_alternative 007F60D085256FC7_=" This is a multipart message in MIME format. --=_alternative 007F60D085256FC7_= Content-Type: text/plain; charset="US-ASCII" Soliciting opinions on the issue of deleting IKE SA's. The spec says that: " To delete an SA, an INFORMATIONAL Exchange with one or more delete payloads is sent listing the SPIs (as they would be expected in the headers of inbound packets) of the SAs to be deleted. The recipient MUST close the designated SAs. Normally, the reply in the INFORMATIONAL Exchange will contain delete payloads for the paired SAs going in the other direction. " In the bakeoff I noticed some implementations actually sent an empty INFORMATIONAL response, and then initiated their own INFORMATIONAL exchange containing the paired SAs to be deleted. My question is whether this is considered to be compliant with the spec? The reason I want to know is whether I can consider the SAs to have been deleted when I receive the empty INFORMATIONAL or whether I have to wait to receive the INFORMATIONAL with the delete payloads to make that decision. Thanks, Tom ps. I am not considering the special case, where delete payloads are crossing in the network. --=_alternative 007F60D085256FC7_= Content-Type: text/html; charset="US-ASCII"
Soliciting opinions on the issue of deleting IKE SA's. The spec says
that:

   " To delete an SA,
   an INFORMATIONAL Exchange with one or more delete payloads is sent
   listing the SPIs (as they would be expected in the headers of inbound
   packets) of the SAs to be deleted. The recipient MUST close the
   designated SAs. Normally, the reply in the INFORMATIONAL Exchange
   will contain delete payloads for the paired SAs going in the other
   direction. "

In the bakeoff I noticed some implementations actually sent an
empty INFORMATIONAL response, and then initiated their own
INFORMATIONAL exchange containing the paired SAs to be deleted.

My question is whether this is considered to be compliant
with the spec? The reason I want to know is whether I can consider
the SAs to have been deleted when I receive the empty INFORMATIONAL
or whether I have to wait to receive the INFORMATIONAL with the
delete payloads to make that decision.

Thanks, Tom

ps. I am not considering the special case, where delete payloads are
crossing in the network.
--=_alternative 007F60D085256FC7_=-- --===============0039697688== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0039697688==-- From ipsec-bounces@ietf.org Thu Mar 17 21:22:25 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16088 for ; Thu, 17 Mar 2005 21:22:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC74b-0008QI-2S; Thu, 17 Mar 2005 21:18:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC74Y-0008QD-Oc for ipsec@megatron.ietf.org; Thu, 17 Mar 2005 21:18:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15918 for ; Thu, 17 Mar 2005 21:18:43 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DC78u-00059x-8K for ipsec@ietf.org; Thu, 17 Mar 2005 21:23:16 -0500 Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2I2IaXo007152; Thu, 17 Mar 2005 18:18:39 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 17 Mar 2005 18:07:45 -0800 To: Tom Stiemerling , ipsec@ietf.org From: Paul Hoffman Subject: Re: [Ipsec] handling delete payloads Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b431ad66d60be2d47c7bfeb879db82c X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 5:59 PM -0500 3/17/05, Tom Stiemerling wrote: >Soliciting opinions on the issue of deleting IKE SA's. The spec says >that: > > " To delete an SA, > an INFORMATIONAL Exchange with one or more delete payloads is sent > listing the SPIs (as they would be expected in the headers of inbound > packets) of the SAs to be deleted. The recipient MUST close the > designated SAs. Normally, the reply in the INFORMATIONAL Exchange > will contain delete payloads for the paired SAs going in the other > direction. " > >In the bakeoff I noticed some implementations actually sent an >empty INFORMATIONAL response, and then initiated their own >INFORMATIONAL exchange containing the paired SAs to be deleted. > >My question is whether this is considered to be compliant >with the spec? That is acceptable by the unfortunately-loose wording of "Normally, the reply...". In fact, Charlie described to me the reasoning for having the response being the delete payload for the opposite direction. It involves a race condition that would take at least a long paragraph to explain. But, the upshot is that: - The initiator's Informational exchange should only have one of the two parts of the SA pair - The responder's response really, really SHOULD include the other part of the SA pair - At the moment that the initiator receives the response, tear down both sides of the SA. >The reason I want to know is whether I can consider >the SAs to have been deleted when I receive the empty INFORMATIONAL >or whether I have to wait to receive the INFORMATIONAL with the >delete payloads to make that decision. That's another good question, and one which helps explain why doing it the way explained above prevents that question. >ps. I am not considering the special case, where delete payloads are >crossing in the network. But that is where the race condition can come in, so we want to avoid it. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Mar 17 21:34:51 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16710 for ; Thu, 17 Mar 2005 21:34:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC7IZ-0003pQ-O4; Thu, 17 Mar 2005 21:33:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC7IY-0003pL-MO for ipsec@megatron.ietf.org; Thu, 17 Mar 2005 21:33:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16623 for ; Thu, 17 Mar 2005 21:33:12 -0500 (EST) Received: from web52604.mail.yahoo.com ([206.190.39.142]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DC7Ms-0005RC-R3 for ipsec@ietf.org; Thu, 17 Mar 2005 21:37:45 -0500 Received: (qmail 85900 invoked by uid 60001); 18 Mar 2005 02:33:02 -0000 Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; b=ZfYkfuhfeelY1YuJGHL2tvPX60Xi5Qrjffm32KfZDleXArDWu2+CcHBPuKdWFYhYUPuW1Xe6ycl/A9I/GZjMdKGzGhPvHjdc9CRaH2tm4JYxhlU8fv43nOEdxPR4DNU9NJTb0GJaYkiMFYr9/76D5J5gV5iQ4OXw3n2N4nUvNcs= ; Message-ID: <20050318023302.85893.qmail@web52604.mail.yahoo.com> Received: from [69.109.178.244] by web52604.mail.yahoo.com via HTTP; Thu, 17 Mar 2005 18:33:02 PST Date: Thu, 17 Mar 2005 18:33:02 -0800 (PST) From: Subha Venkataramanan Subject: Re: [Ipsec] Next Layer Protocol (Ref: 2401-bis draft) To: Stephen Kent In-Reply-To: 6667 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Score: 2.0 (++) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi , I have a follow-up question. If an implementation understands says hop-to-hop, routing, fragmentation and Destination Options, it can parse these extension headers and look for the next protocol information. When it parses each extension header, it knows the length of bytes it needs to skip to reach the next extension header. If there are any new extension headers and the implemenation cannot interpret these extension headers, it cannot process the packet. In which case, it may choose to send an ICMP Error message. What additional help is given to the implementation, by configuring the extension headers that it needs to ignore while parsing the IPv6 header. 1) Does this kind of configuration in the implementation advise the user, that it has capabilities skip A,B,C extension headers ? 2) Does this kind of configuration mean, that if the implementation comes across any other extension headers which it can interpret but is not in the configured list, it should drop the packet ? 3) Does this kind of configuration mean, that when the user tries to add some extension header values, that the implementation does not support, it can throw an error indicating the same ? Can someone please clarify ? Thanks, Subha --- Stephen Kent wrote: > At 3:51 PM -0800 1/13/05, Subha Venkataramanan > wrote: > >Hi List-members, > > > >In Section 4.4.4.1 (Selectors) under Next- Layer > >Protocols, it is mentioned that "to simplify > locating > >the next header protocol, there SHOULD be a > mechanism > >for configuring which IPv6 extension headers to > SKIP" > > > >Could someone indicate to me what was the intent > >behind this kind of configuration ? > > > >Thanks, > >Subha > > In IPv6, the use of hop-by-hop and destination > extension headers can > make it harder than in Ipv4 to locate the next layer > protocol. This > text suggests that it would be useful to be able to > configure an > IPsec implementation with a list of which of these > extension headers > can safely be ignored when parsing the IPv6 header > to locate the next > protocol. > > Steve > __________________________________ Do you Yahoo!? Yahoo! Small Business - Try our new resources site! http://smallbusiness.yahoo.com/resources/ _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Mar 17 22:29:50 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA22114 for ; Thu, 17 Mar 2005 22:29:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC85s-0003cF-GG; Thu, 17 Mar 2005 22:24:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DC85q-0003cA-R1 for ipsec@megatron.ietf.org; Thu, 17 Mar 2005 22:24:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA21591 for ; Thu, 17 Mar 2005 22:24:08 -0500 (EST) Received: from [207.145.48.18] (helo=smtp.intoto.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DC8AD-0006TT-5S for ipsec@ietf.org; Thu, 17 Mar 2005 22:28:41 -0500 Received: from not-angel.intoto.com ([66.80.10.146]) by smtp.intoto.com (SMSSMTP 4.0.0.59) with SMTP id M2005031719231122119 ; Thu, 17 Mar 2005 19:23:11 -0800 Received: from SHREYADESKTOP (adsl-69-109-178-244.dsl.pltn13.pacbell.net [69.109.178.244]) (authenticated bits=0) by not-angel.intoto.com (8.13.1/8.13.1) with ESMTP id j2I3Nda7031690; Thu, 17 Mar 2005 19:23:39 -0800 Message-ID: <016601c52b69$dedea1e0$0500a8c0@SHREYADESKTOP> From: "Subha" To: , "Tom Stiemerling" References: Subject: Re: [Ipsec] handling delete payloads Date: Thu, 17 Mar 2005 19:23:32 -0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 0.8 (/) X-Scan-Signature: 31b28e25e9d13a22020d8b7aedc9832c 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="===============0684296424==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0684296424== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0163_01C52B26.CE94B150" This is a multi-part message in MIME format. ------=_NextPart_000_0163_01C52B26.CE94B150 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Since it is not made mandatory in the specification, that the response SHOULD have an DELETE payload, an empty INFORMATIONAL Response should be considered compliant.=20 IMO, When the Empty INFORMATIONAL Response arrives, the Initiator of the DELETE Payload Noficiation can consider that its side SA has been torn down by the peer. Initiator should however wait for an = explicit DELETE Payload Notification from the Peer to delete the Peer side SA. However, an implementation should not always send an Empty=20 INFORMATIONAL Response. It should send it only if the DELETE=20 Payload Notification has already been sent from its side.=20 (To avoid any potential race condition). I think IKEv2 draft should be updated with details to avoid ambiguity. Thanks, Subha ----- Original Message -----=20 From: Tom Stiemerling=20 To: ipsec@ietf.org=20 Sent: Thursday, March 17, 2005 2:59 PM Subject: [Ipsec] handling delete payloads Soliciting opinions on the issue of deleting IKE SA's. The spec says=20 that:=20 " To delete an SA,=20 an INFORMATIONAL Exchange with one or more delete payloads is sent=20 listing the SPIs (as they would be expected in the headers of = inbound=20 packets) of the SAs to be deleted. The recipient MUST close the=20 designated SAs. Normally, the reply in the INFORMATIONAL Exchange=20 will contain delete payloads for the paired SAs going in the other=20 direction. "=20 In the bakeoff I noticed some implementations actually sent an=20 empty INFORMATIONAL response, and then initiated their own=20 INFORMATIONAL exchange containing the paired SAs to be deleted.=20 My question is whether this is considered to be compliant=20 with the spec? The reason I want to know is whether I can consider=20 the SAs to have been deleted when I receive the empty INFORMATIONAL=20 or whether I have to wait to receive the INFORMATIONAL with the=20 delete payloads to make that decision.=20 Thanks, Tom=20 ps. I am not considering the special case, where delete payloads are=20 crossing in the network.=20 -------------------------------------------------------------------------= ----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec ------=_NextPart_000_0163_01C52B26.CE94B150 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,
 
Since it is not made mandatory in the specification, that the=20 response
SHOULD have an DELETE payload, an empty INFORMATIONAL
Response should be considered compliant.
 
IMO, When the Empty INFORMATIONAL Response arrives, the = Initiator
of the DELETE Payload Noficiation can consider that its side SA = has
been torn down by the peer. Initiator should however wait for an=20 explicit
DELETE Payload Notification from the Peer to delete the Peer side = SA.
 
However, an implementation should not always send an Empty
INFORMATIONAL Response. It should send it only if the DELETE
Payload Notification has already been sent from its side.
(To avoid any potential race condition).
 
I think IKEv2 draft  should be updated with details to = avoid
ambiguity.
 
Thanks,
Subha
----- Original Message -----
From:=20 Tom=20 Stiemerling
Sent: Thursday, March 17, 2005 = 2:59=20 PM
Subject: [Ipsec] handling = delete=20 payloads


Soliciting = opinions on the=20 issue of deleting IKE SA's. The spec says
that:

  =  " To=20 delete an SA,
  =  an=20 INFORMATIONAL Exchange with one or more delete payloads is sent =
   listing the SPIs (as = they would=20 be expected in the headers of inbound
   packets) of the SAs to be deleted. The recipient = MUST=20 close the
  =  designated SAs.=20 Normally, the reply in the INFORMATIONAL Exchange
   will contain delete payloads = for the=20 paired SAs going in the other
 =20  direction. "

In = the bakeoff=20 I noticed some implementations actually sent an
empty INFORMATIONAL response, and then = initiated their=20 own
INFORMATIONAL exchange = containing=20 the paired SAs to be deleted.

My=20 question is whether this is considered to be compliant =
with the spec? The reason I want to know is = whether I=20 can consider
the SAs to = have been=20 deleted when I receive the empty INFORMATIONAL
or whether I have to wait to receive the = INFORMATIONAL=20 with the
delete payloads = to make that=20 decision.

Thanks, = Tom=20

ps. I am not considering the = special=20 case, where delete payloads are
crossing in the network.

_______________________________________________
Ipsec = mailing=20 list
Ipsec@ietf.org
https://www1.ietf.o= rg/mailman/listinfo/ipsec ------=_NextPart_000_0163_01C52B26.CE94B150-- --===============0684296424== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0684296424==-- From ipsec-bounces@ietf.org Mon Mar 21 16:15:17 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA26765 for ; Mon, 21 Mar 2005 16:15:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDTaK-0005Jp-Gm; Mon, 21 Mar 2005 15:33:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDTaF-0005JM-Rn; Mon, 21 Mar 2005 15:33:07 -0500 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA15214; Mon, 21 Mar 2005 15:33:06 -0500 (EST) Message-Id: <200503212033.PAA15214@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: i-d-announce@ietf.org From: Internet-Drafts@ietf.org Date: Mon, 21 Mar 2005 15:33:05 -0500 Cc: ipsec@ietf.org Subject: [Ipsec] I-D ACTION:draft-ietf-ipsec-rfc2402bis-11.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : IP Authentication Header Author(s) : S. Kent Filename : draft-ietf-ipsec-rfc2402bis-11.txt Pages : 34 Date : 2005-3-21 This document describes an updated version of the IP Authentication Header (AH), which is designed to provide authentication services in IPv4 and IPv6. This document obsoletes RFC 2402 (November 1998). A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-rfc2402bis-11.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-rfc2402bis-11.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-rfc2402bis-11.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2005-3-21154259.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-rfc2402bis-11.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-rfc2402bis-11.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2005-3-21154259.I-D@ietf.org> --OtherAccess-- --NextPart Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --NextPart-- From ipsec-bounces@ietf.org Wed Mar 23 01:42:16 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01749 for ; Wed, 23 Mar 2005 01:42:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDzPU-0001ex-Pw; Wed, 23 Mar 2005 01:32:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DDzPP-0001eT-GL for ipsec@megatron.ietf.org; Wed, 23 Mar 2005 01:32:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA01085 for ; Wed, 23 Mar 2005 01:32:02 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DDzUo-0001HX-LY for ipsec@ietf.org; Wed, 23 Mar 2005 01:37:39 -0500 Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j2N6UfvF025120; Wed, 23 Mar 2005 01:30:42 -0500 (EST) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: Date: Wed, 23 Mar 2005 01:35:50 -0500 To: ipsec@ietf.org From: Karen Seo Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 41b2d478fce1e393ae0364b4260b8758 Cc: angelos@cs.columbia.edu, kseo@bbn.com, Barbara Fraser , "Theodore Ts'o" , Russ Housley , kivinen@iki.fi Subject: [Ipsec] IPsec 2401bis changes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org [Folks -- I sent a multi-colored version of the email below to the list. Unfortunately, it's "being held until the list moderator can review it for approval" because the "Message body is too big". I'm assuming this is due to the use of color. So I'm re-sending the email in black/white. Apologies if you receive both versions.] Russ, Below are the changes that we believe have been agreed upon to address (a) recent issues brought up on the mailing list, (b) the comments at: https://datatracker.ietf.org/public/pidtracker.cgi?command=print_ballot&ballot_id=1544&filename=draft-ietf-ipsec-rfc2401bis, and (c) other IDSG feedback. We have incorporated these changes into a new draft and submitted it to the IETF secretariat. Please let us know if you have any questions. Thank you, Karen Issues in IDSG tracker: ============================================================================ 1.1. Harald Alvestrand, Brian Carpenter >4.1 Definition and Scope ... > If different classes of traffic (distinguished by Differentiated > Services CodePoint (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on the > same SA, and if the receiver is employing the optional anti-replay > feature available in both AH and ESP, this could result in > inappropriate discarding of lower priority packets due to the > windowing mechanism used by this feature. Therefore a sender SHOULD > put traffic of different classes, but with the same selector values, > on different SAs to support QoS appropriately. To permit this, the > IPsec implementation MUST permit establishment and maintenance of > multiple SAs between a given sender and receiver, with the same > selectors. Distribution of traffic among these parallel SAs to > support QoS is locally determined by the sender and is not negotiated > by IKE. The receiver MUST process the packets from the different SAs > without prejudice. I think it would be helpful to remind readers that (as indicated in RFC 2983) we are talking here about the "inner" DSCP in a tunnel, which will not be changed en route (since in general, the DSCP value may be changed en route and that destroys the model described, since there would be no fixed relationship between DSCP value and SA). Per agreement with Brian, we added the following text at the end of the above paragraph. These requirements apply to both transport and tunnel mode SAs. In the case of tunnel mode SAs, the DSCP values in question appear in the inner IP header. In transport mode, the DSCP value might change en route, but this should not cause problems with respect to IPsec processing since the value is not employed for SA selection and MUST NOT be checked as part of SA/packet validation. However, if significant re-ordering of packets occurs in an SA, e.g., as a result of changes to DSCP values en route, this may trigger packet discarding by a receiver due to application of the anti-replay mechanism. --------------------------------------------------------------------------- 1.2. Harald Alvestrand, Brian Carpenter >I also note that there is no reference to the IPv6 Flow Label. Since this >is an e2e field (RFC 3697) it would actually be easier to handle than the >DSCP, if there was any need to do so. After discussion, we agreed to wait for some experience with flow label usage before trying to craft language. No change was made. --------------------------------------------------------------------------- 1.3. Harald Alvestrand, Brian Carpenter >>4.4.2.1 Data Items in the SAD >... >> o Bypass DF bit (T/F) - applicable to tunnel mode SAs Note that this only applies to IPv4 (ditto section 8.1). We changed the text to be: 4.4.2.1 Data Items in the SAD .... o Bypass DF bit (T/F) - applicable to tunnel mode SAs where both inner and outer headers are IPv4. 8.1 DF Bit All IPsec implementations MUST support the option of copying the DF bit from an outbound packet to the tunnel mode header that it emits, when traffic is carried via a tunnel mode SA. This means that it MUST be possible to configure the implementation's treatment of the DF bit (set, clear, copy from inner header) for each SA. This applies to SAs where both inner and outer headers are IPv4. --------------------------------------------------------------------------- 1.4. Harald Alvestrand, Brian Carpenter >>4.4.2.1 Data Items in the SAD >... >> o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if >> needed to restrict bypass of DSCP values - applicable to tunnel >> mode SAs This is unclear to me and needs some explanation. Actually, it's unclear how the earlier suggested treatment of DSCPs works, since the DSCP value(s) corresponding to an SA aren't stored anywhere that I noticed, so the model does not allow for demultiplexing on DSCP values in any case. Per agreement with Brian, we added the following text: o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if needed to restrict bypass of DSCP values - applicable to tunnel mode SAs. This feature maps DSCP values from an inner header to values in an outer header, e.g., to address covert channel signalling concerns. o DSCP values: the set of DSCP values allowed for packets carried over this SA. If no values are specified, no DSCP-specific filtering is applied. If one or more values are specified, these are used to select one SA among several that match the traffic selectors for an outbound packet. Note that these values are NOT checked against inbound traffic arriving on the SA. --------------------------------------------------------------------------- 1.5. Vishwas Manral and David Black (as part of above discussion with Brian Carpenter) See item 1.1 above. The last sentence was added which says "However, if significant re-ordering of packets occurs in an SA, e.g., as a result of changes to DSCP values en route, this may trigger packet discarding by a receiver due to application of the anti-replay mechanism." --------------------------------------------------------------------------- 2.1. Ted Hardie (and elsewhen Brian Carpenter) This seems to have a mix of RFC 2026 and RFC 3668 boilerplates. We believe we've addressed this. The document passes the checks done by the idnits tool. --------------------------------------------------------------------------- 2.2. Ted Hardie: In Section 4.1, the draft says: In many secure multicast (or anycast) architectures, e.g., [RFC3740], a central Group Controller/Key Server unilaterally assigns the Group Security Association's (GSA's) SPI. 3740 does not seem to mention anycast. Is there a similar reference for anycast? There isn't any RFC for secure anycast. We removed the "(or anycast)" from the above text and all other instances of anycast have been deleted. We really do not have appropriate provisions to support anycast, since the MSEC WG addresses only multicast. --------------------------------------------------------------------------- 2.3. Ted Hardie: Section 4.4.1 uses 192.168 addresses, rather than the example prefix 192.0.2.x/24 Replaced all 192.168.2.y with 192.0.2.x. --------------------------------------------------------------------------- 2.4. Ted Hardie: I found the use of "road warrior" in section 4.5.2 distracting. Deleted the "(road warrior)" from Section 4.5.3 Locating a Security Gateway, paragraph 2: "Consider a situation in which a remote host (SH1) is using the Internet to gain access to a server or other machine (H2) and there is a security gateway (SG2), e.g., a firewall, through which H1's traffic must pass. An example of this situation would be a mobile host (road warrior) crossing the Internet to his home organization's firewall (SG2)." --------------------------------------------------------------------------- 3.1. Sam Hartman: [issue 1] Added at the end of Section 3.3 (Where IPsec Can Be Implemented) A host implementation of IPsec may appear in devices that might not be viewed as "hosts." For example, a router might employ IPsec to protect routing protocols (e.g., BGP) and management functions (e.g., Telnet), without affecting subscriber traffic traversing the router. A security gateway might employ separate IPsec implementations to protect its management traffic and subscriber traffic. The architecture described in this document is very flexible. For example, a computer with a full-featured, compliant, native OS IPsec implementation should be capable of being configured to protect resident (host) applications and to provide security gateway protection for traffic traversing the computer. Such configuration would make use of the forwarding tables and the SPD selection function described in Sections 5.1 and 5.2. Added the following text to the beginning of section 11 (Security Considerations) IPsec imposes stringent constraints on bypass of IP header data in both directions across the IPsec barrier, especially when tunnel mode SAs are employed. Some constraints are absolute, while others are subject to local administrative controls, often on a per-SA basis. For outbound traffic, these constraints are designed to limit covert channel bandwidth. For inbound traffic, the constraints are designed to prevent an adversary who has the ability to tamper with one data stream (on the unprotected side of the IPsec barrier) from adversely affecting other data streams (on the protected side of the barrier). The discussion in Section 5 dealing with processing DSCP values for tunnel mode SAs illustrates this concern. --------------------------------------------------------------------------- 3.2. Sam Hartman: [issue 2] We changed 4.4.1.1 Selectors paragraphs re: Name as follows. Added a sentence to the paragraph re: named entry used by an initiator: "Support for this use is optional for multi-user, native host implementations and not applicable to other implementations. Note that this name is used only locally; it is not communicated by the key management protocol. Also, name forms other than those used for case 1 above (responder) are applicable in the initiator context (see below)." Altered the examples given for the types of names as shown below: "For case 1, responder, the identifiers employed in named SPD entries are one of the following four types: a. a fully qualified user name string (email), e.g., mozart@foo.example.com (this corresponds to ID_RFC822_ADDR in IKEv2) b. a fully qualified DNS name, e.g., foo.example.com (this corresponds to ID_FQDN in IKEv2) c. X.500 distinguished name, e.g., C = US, SP = MA O = BBN Technologies, CN = Stephen T. Kent (this corresponds to ID_DER_ASN1_DN in IKEv2, after decoding) d. a byte string (this corresponds to Key_ID in IKEv2) For case 2, initiator, the identifiers employed in named SPD entries are of type byte string. They are likely to be Unix UIDs, Windows security IDs or something similar, but could also be a user name or account name. In all cases, this identifier is only of local concern and is not transmitted." Modified the ASN.1 as shown below: NameSets ::= SEQUENCE { passed SET OF Names-R, -- Matched to IKE ID by responder local SET OF Names-I } -- Used internally by IKE initiator Names-R ::= CHOICE { -- IKEv2 IDs: dName DistinguishedName, -- ID_DER_ASN1_DN fqdn FQDN, -- ID_FQDN rfc822 [0] RFC822Name, -- ID_RFC822_ADDR keyID OCTET STRING } -- KEY_ID Names-I ::= OCTET STRING -- Used internally by IKE initiator --------------------------------------------------------------------------- 3.3. Sam Hartman: [issue 3] Per discussione with Sam Hartman, we modified Section 4.4.1.1 re: Name by re-ordering the components of the distinguished name as shown below and adding a Normative reference for RFC 2253: From: c. X.500 distinguished name, e.g., C = US, SP = MA, O = BBN Technologies, CN = Stephen T. Kent (this corresponds to ID_DER_ASN1_DN in IKEv2, after decoding) To: c. X.500 distinguished name, e.g., [WaKiHo97], CN = Stephen T. Kent, O = BBN Technologies, SP = MA, C = US (this corresponds to ID_DER_ASN1_DN in IKEv2, after decoding) Added: [WaKiHo97] Wahl, M., Kille, S., Howes, T., "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997 --------------------------------------------------------------------------- 3.4. Sam Hartman: [issue 4] Addressed Sam's concerns in email exchange -- no change was made. --------------------------------------------------------------------------- 3.5. Sam Hartman: [issue 5] Per discussion, we added the following text to - Section 4.4.2 Security Association Database (SAD) at the end of paragraph 2. - Section 5 IP Traffic Processing, paragraph 1: Note also, that there are a couple of situations in which the SAD can have entries for SAs that do not have corresponding entries in the SPD. Since 2401bis does not mandate that the SAD be selectively cleared when the SPD is changed, SAD entries can remain when the SPD entries that created them are changed or deleted. Also, if a manually keyed SA is created, there could be an SAD entry for this SA that does not correspond to any SPD entry. And changed Section 4.4.1, paragraph on "How To Derive the Values for an SAD entry" From: For inbound traffic not protected by IPsec, there are SPD-I cache entries and there is the SAD, which represents the cache for inbound IPsec-protected traffic (See Figure 3 in Section 5.2). To: For inbound traffic not protected by IPsec, there are SPD-I cache entries and there is the SAD, which represents the cache for inbound IPsec-protected traffic (See Section 4.4.2). And added two footnotes to Figure 3 to clarify where the SAD's role as an SPD inbound (**) = This processing includes using the packet's SPI, etc to look up the SA in the SAD, which forms a cache of the SPD for inbound packets (except for cases noted in Sections 4.4.2 and 5) - see step 3a below. (***) = This SAD check refers to step 4 below. --------------------------------------------------------------------------- 3.6. Sam Hartman: [Issue 6] Changed the text of Section 5.2 by taking the first paragraph after step 4 and turning it into step 5 and un-indenting the 2nd and 3rd paragraphs after step 4 so that they are NOT part of the processing steps: From: 4. Apply AH or ESP processing as specified, using the SAD entry selected in step 3a above. Then match the packet against the inbound selectors identified by the SAD entry to verify that the received packet is appropriate for the SA via which it was received. If an IPsec system receives an inbound packet on an SA and the packet's header fields are not consistent with the selectors for the SA, it MUST discard the packet...... To minimize the impact of a DoS attack, or a mis-configured peer, the IPsec system SHOULD include a management control to allow an administrator to configure .... After traffic is bypassed or processed through IPsec, it is handed to the inbound forwarding function for disposition... To: 4. Apply AH or ESP processing as specified, using the SAD entry selected in step 3a above. Then match the packet against the inbound selectors identified by the SAD entry to verify that the received packet is appropriate for the SA via which it was received. 5. If an IPsec system receives an inbound packet on an SA and the packet's header fields are not consistent with the selectors for the SA, it MUST discard the packet...... To minimize the impact of a DoS attack, or a mis-configured peer, the IPsec system SHOULD include a management control to allow an administrator to configure .... After traffic is bypassed or processed through IPsec, it is handed to the inbound forwarding function for disposition... --------------------------------------------------------------------------- 3.7. Sam Hartman: [Issue 7] We added the following text to Section 7.4 As noted above, in network configurations where fragments of a packet might be sent or received via different security gateways or BITW implementations, stateful strategies for tracking fragments may fail. --------------------------------------------------------------------------- 3.8. Sam Hartman: [Issue 8] Inserted new PAD text into section 4.4.3 replacing previous text. Added a reference for (IKEv1 (RFC2409) by Harkins and Carrel). --------------------------------------------------------------------------- 3.9. Sam Hartman: [Issue 9] The ASN.1 has been modified to compile as is. So the problem text at the top of the appendix has been replaced with text saying that this code compiles. Changes included: Replaced DistinguishedName with RDNSequence Changed ANY DEFINED BY to ANY -- DEFINED BY algorithm.... Checked for any duplicate tags --------------------------------------------------------------------------- 3.9. Sam Hartman: [No issue number assigned] Section 6.1.2 creates requirements for incoming ICMP packets on the protected side of the IPsec boundary. As best I can tell the attacks described in that section are potential problems for any Internet gateway and have nothing to do with IPsec. If so, why should the IPsec architecture add requirements for additional administrative controls to mitigate these attacks? (I think the administrative controls are a good idea; I'm just unsure why this specification is the right place for them.) Based on discussion, no changes were made. --------------------------------------------------------------------------- 3.10 Sam Hartman: [No issue number assigned] Section 4.5.3 Locating a Security Gateway. Since the IPSP working group was just closed, the last 2 sentences of this section were deleted. The corresponding text in Section 13. "Differences from RFC 2401" was also deleted. "The IP Security Policy (IPSP) Working Group is a possible future source of guidance. One of its goals is to produce an Internet Draft on a "Security Gateway Discovery, Policy Exchange and Negotiation Protocol". --------------------------------------------------------------------------- 4.1. Russ Housley: When will the module identifier be assigned for Appendix C? If you want IANA to do it, then it needs to be called out in the IANA Considerations section. There is currently no IPsec arc (just the ISAKMP and IKE arcs) So we requested one from IANA and we changed Section 12. IANA Considerations From: This document has no actions for IANA. To: This document contains a "magic" number to be maintained by the IANA. Upon approval of this draft for publication as an RFC, IANA is to create a registry for ASN.1 Modules under the Prefix: iso.org.dod.internet.security.mechanisms.ipsec (1.3.6.1.5.5.8) In Appendix C "ASN.1 for an SPD Entry", the number assigned to the ASN.1 Modules registry is to replace the xx corresponding to the asn1\(hymodules and the object identifier assigned to spd\(hymodule is to replace the "yy" for the spd\(hymodule. --------------------------------------------------------------------------- 4.2. Russ Housley: Section 4.1: s/Memory (TCAM0 features/Memory (TCAM) features/ Section 4.4.1: s/SPD-SPD-S, SPD-SPD-I, SPD-SPD-O/SPD-S, SPD-I, SPD-O/ s/The SPD-SPD-S/The SPD-S/ Section 4.4.2: s/Database(SAD),/Database (SAD),/ Section 8.2.1: s/SAD entry When/SAD entry. When/ The above changes have been made. --------------------------------------------------------------------------- 4.3. Russ Housley: In making the other changes to the document, you added the "addresses" element to the "TunnelOptions" structure. You forgot the comma after "DF" when this change was made. Here is an ASN.1 module that compiles (using the 1990 syntax). Updated ASN.1 module (Appendix C) --------------------------------------------------------------------------- 5.1. Alex Zinin: Discuss: How does the in/out-bound processing model defined in section 5 work in the case of a VPN gateway? In particular, how does presence of multiple routing realms and a two-stage forwarding process affect it (imagine a gw that uses dynamic routing over the VPN tunnels protected by IPsec transport mode as encapsulated packets leave the box)? What about locally-originated messages, such as routing messages in this case. I know how to make it work, the question is how the described model addresses these scenarios. We answered Alex's questions. No change was made. --------------------------------------------------------------------------- 5.2. Alex Zinin: Section 4.4 Major IPsec Databases: > Forwarding vs Security Decisions > The IPsec model described here embodies a clear separation between > forwarding (routing) and security decisions, to accommodate a wide > range of contexts where IPsec may be employed. Forwarding may be > trivial, in the case where there are only two interfaces, or it > may be complex, e.g., if there are multiple protected or > unprotected interfaces or if the context in which IPsec is > implemented employs a sophisticated forwarding function. minor note: complexity of forwarding doesn't depend directly on the number of local interfaces. We deleted "if there are multiple protected or unprotected interfaces or" so that the text now says: Forwarding vs Security Decisions The IPsec model described here embodies a clear separation between forwarding (routing) and security decisions, to accommodate a wide range of contexts where IPsec may be employed. Forwarding may be trivial, in the case where there are only two interfaces, or it may be complex, e.g., if the context in which IPsec is implemented employs a sophisticated forwarding function. --------------------------------------------------------------------------- 5.3. Alex Zinin: > IPsec assumes only that outbound and inbound traffic that has passed > through IPsec processing is forwarded in a fashion consistent with > the context in which IPsec is implemented. What does the above statement really mean? We answered Alex's question in email exchange. No change was made. --------------------------------------------------------------------------- 5.4. Alex Zinin: Though Appendix E is not normative, I should note that it is rather confusing. Specifically, though the document states that no changes to the forwarding function are introduced, the appendix mentions two different forwarding tables--one for protected, and one for unprotected side. Also, the representation of the forwarding tables themselves creates an impression that routes usually include both source and destination prefixes, which clearly isn't true (unless we're talking about a special case of policy-based routing). Again, I know how to make it work, but I don't think the doc is very good at explaining this. We answered Alex's questions in email exchange. No change was made. ============================================================================ Per discussion with Russ Housley, the following changes were made to address various issues brought up on the IPsec mailing list: Re: handling multicast: Section 4.4.1.1, added the text below after the paragraphs on remote and local IP address(es). Note: The SPD does not include support for multicast address entries. To support multicast SAs, an implementation should make use of a Group SPD (GSPD) as defined in [RFC3740]. GSPD entries require a different structure, i.e., one cannot use of the symmetric relationship associated with local and remote address values for unicast SAs in a multicast context. Specifically, outbound traffic directed to a multicast address on an SA would not be received on a companion, inbound SA with the multicast address as the source. Section 4.4.2, added the following text after the 2nd paragraph: Note: The SAD can support multicast SAs, if manually configured. An outbound multicast SA has the same structure as a unicast SA. The source address is that of the sender and the destination address is the multicast group address. An inbound, multicast SA must be configured with the source addresses of each peer authorized to transmit to the multicast SA in question. The SPI value for a multicast SA is provided by a multicast group controller, not by the receiver, as for a unicast SA. Because an SAD entry may be required to accommodate multiple, individual IP source addresses that were part of an SPD entry (for unicast SAs), the required facility for inbound, multicast SAs is a feature already present in an IPsec implementation. However, because the SPD has no provisions for accommodating multicast entries, this document does not specify an automated way to create an SAD entry for a multicast, inbound SA. Only manually configured SAD entries can be created to accommodate inbound, multicast traffic. Section 4.4.1.1, the 2 paragraphs on Remote and Local IP Address(es) -- references to "multicast group" were removed. --------------------------------------------------------------------------- Re: handling ECN or DS Section 5.2.2, replaced the bullet o IPsec describes how to handle ECN or DS. with o IPsec describes how to handle ECN and DS and provides the ability to control propagation of changes in these fields between unprotected and protected domains. In general, propagation from a protected to an unprotected domain is a covert channel and thus controls are provided to manage the bandwidth of this channel. Propagation of ECN values in the other direction are controlled so that only legitimate ECN changes (indicating occurrence of congestion between the tunnel endpoints) are propagated. By default, DS propagation from an unprotected domain to a protected domain is not permitted. However, if the sender and receiver do not share the same DS code space, and the receiver has no way of learning how to map between the two spaces, then it may be appropriate to deviate from the default. Specifically, an IPsec implementation MAY be configurable in terms of how it processes the outer DS field for tunnel mode for received packets. It may be configured to either discard the outer DS value (the default) OR to overwrite the inner DS field with the outer DS field. If offered the discard vs. overwrite behavior MAY be configured on a per SA basis. This configuration option allows a local administrator to decide whether the vulnerabilities created by copying these bits outweigh the benefits of copying. See [RFC 2983] for further information on when each of these behaviors may be useful, and also for the possible need for diffserv traffic conditioning prior or subsequent to IPsec processing (including tunnel decapsulation). In 5.1.2.2, changed the the header construction table for DS Field, so that the column for the decapsulator says "no change" (9) and added note 9: 9. An implementation MAY choose to provide a facility to pass the DS value from the outer header to the inner header, on a per SA basis, for received tunnel mode packets. The motivation for providing this feature is to accommodate situations in which the DS code space at the receiver is different from that of the sender and the receiver has no way of knowing how to translate from the sender's space. There is a danger in copying this value from the outer header to the inner header, since it enables an attacker to modify the outer DSCP value in a fashion that may adversely affect other traffic at the receiver. Hence the default behavior for IPsec implementations is NOT to permit such copying. --------------------------------------------------------------------------- Re: decorrelated vs not-decorrelated SPD and what is passed between peers to negotiate an SA. Also re: addressing the mis-alignment of the semantics of IKEv2 with those of the SPD Section 4.4.1, Decorrelation subsection, deleted last 4 sentences of 2nd paragraph: "Note also that if a decorrelated SPD is employed, the original entry from the (correlated) SPD should be retained and passed to the SA management protocol, e.g., IKE. Passing the correlated SPD entry to the SA management protocol keeps the use of a decorrelated SPD a local matter, not visible to peers. When acting as a responder, the peer uses a correlated SPD entry for matching, and for issuing a "narrowed" response. Then the decorrelated entries are used to populate the SPD-S cache." and replaced them with the following 5 paragraphs: If a decorrelated SPD is employed, there are three options for what an initiator sends to a peer via an SA management protocol (e.g., IKE). By sending the complete set of linked, decorrelated entries that were selected from the SPD, a peer is given the best possible information to enable selection of the appropriate SPD entry at its end, especially if the peer has also decorrelated its SPD. However, if a large number of decorrelated entries are linked, this may create large packets for SA negotiation, and hence fragmentation problems for the SA management protocol. Alternatively, the original entry from the (correlated) SPD may be retained and passed to the SA management protocol. Passing the correlated SPD entry keeps the use of a decorrelated SPD a local matter, not visible to peers, and avoids possible fragmentation concerns, although it provides less precise information to a responder for matching against the responder's SPD. An intermediate approach is to send a subset of the complete set of linked, decorrelated SPD entries. This approach can avoid the fragmentation problems cited above and yet provide better information than the original, correlated entry. The major shortcoming of this approach is that it may cause additional SAs to be created later, since only a subset of the linked, decorrelated entries are sent to a peer. Implementers are free to employ any of the approaches cited above. A responder uses the traffic selector proposals it receives via an SA management protocol to select an appropriate entry in its SPD. The intent of the matching is to select an SPD entry and create an SA that most closely matches the intent of the initiator, so that traffic traversing the resulting SA will be accepted at both ends. If the responder employs a decorrelated SPD, it SHOULD use the decorrelated SPD entries for matching, as this will generally result in creation of SAs that are more likely to match the intent of both peers. If the responder has a correlated SPD, then it SHOULD match the proposals against the correlated entries. For IKE v2, use of a decorrelated SPD offers the best opportunity for a responder to generate a "narrowed" response. In all cases, when a decorrelated SPD is available, the decorrelated entries are used to populate the SPD-S cache. If the SPD is not decorrelated, caching is not allowed and an ordered search of SPD MUST be performed to verify that inbound traffic arriving on an SA is consistent with the access control policy expressed in the SPD. Section 4.4.1.2, 2nd paragraph. Changed From: This text describes the SPD in a fashion that maps directly into IKE payloads to ensure that the policy required by SPD entries can be negotiated through IKE. The management GUI can offer the user other forms of data entry and display..... To: This text describes the SPD in a fashion that is intended to map directly into IKE payloads to ensure that the policy required by SPD entries can be negotiated through IKE. Unfortunately, the semantics of the version of IKE v2 published concurrently with this document [Kau05] do not align precisely with those defined for the SPD. Specifically, IKE v2 does not enable negotiation of a single SA that binds multiple pairs of local and remote addresses and ports to a single SA. Instead, when multiple local and remote addresses and ports are negotiated for an SA, IKE v2 treats these not as pairs, but as (unordered) sets of local and remote values that can be arbitrarily paired. Until IKE provides a facility that conveys the semantics that are expressed in the SPD via selector sets (as described below), users MUST NOT include multiple selector sets in a single SPD entry unless the access control intent aligns with the IKE "mix and match" semantics. An implementation MAY warn users, to alert them to this problem if users create SPD entries with multiple selector sets, the syntax of which indicates possible conflicts with current IKE semantics. The management GUI can offer the user other forms of data entry and display... Additional issue from the list ============================================================================ 2/15/05 Atul Sharma brought up the case of two tunnels protecting the same addresses/hosts but with different tunnel endpoints... To clarify matters, we made the following changes. Section 4.4.3 Peer Authorization Database (PAD) -- modified the last bullet of paragraph 3 in the new PAD text. from: o peer gateway location info, e.g., an IP address or a DNS name, MAY be included for peers that are known to be "behind" a security gateway to: o peer gateway location info, e.g., IP address(es) or DNS name(s), MAY be included for a peer that is known to be "behind" a security gateway or gateways. and added the following sentence at the end of the section: Note that the PAD information MAY be used to support creation of more than one tunnel mode SA at a time between two peers, e.g., two tunnels to protect the same addresses/hosts, but with different tunnel endpoints. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 23 04:57:34 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24263 for ; Wed, 23 Mar 2005 04:57:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE2aq-0007gV-7Y; Wed, 23 Mar 2005 04:56:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE2Z4-0007KO-7s for ipsec@megatron.ietf.org; Wed, 23 Mar 2005 04:54:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23546 for ; Wed, 23 Mar 2005 04:54:09 -0500 (EST) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE2eS-0008Sl-K9 for ipsec@ietf.org; Wed, 23 Mar 2005 04:59:50 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] IPsec 2401bis changes Date: Wed, 23 Mar 2005 01:53:59 -0800 Message-ID: Thread-Topic: [Ipsec] IPsec 2401bis changes Thread-Index: AcUvc4jqoeDbgv2KRsCMeUNJs7XM7AAGzkmg From: "Vishwas Manral" To: "Karen Seo" , X-Spam-Score: 0.0 (/) X-Scan-Signature: ed47526c119154eb728d7ff47d76b536 Content-Transfer-Encoding: quoted-printable Cc: angelos@cs.columbia.edu, "Theodore Ts'o" , Russ Housley , Barbara Fraser , kivinen@iki.fi X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Karen, There is another small update we may have missed.=20 I had raised an issue with the DSCP processing and in private mails between the AD's, Brian Carpenter, Stephen Kent, David Black as well as me we had come to a conclusion. One of the mails in the thread is=20 http://www1.ietf.org/mail-archive/web/ipsec/current/msg01172.html Thanks, Vishwas -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Karen Seo Sent: Wednesday, March 23, 2005 12:06 PM To: ipsec@ietf.org Cc: angelos@cs.columbia.edu; kseo@bbn.com; Barbara Fraser; Theodore Ts'o; Russ Housley; kivinen@iki.fi Subject: [Ipsec] IPsec 2401bis changes [Folks -- I sent a multi-colored version of the email below to the=20 list. Unfortunately, it's "being held until the list moderator can=20 review it for approval" because the "Message body is too big". I'm=20 assuming this is due to the use of color. So I'm re-sending the=20 email in black/white. Apologies if you receive both versions.] Russ, Below are the changes that we believe have been agreed upon to=20 address (a) recent issues brought up on the mailing list, (b) the=20 comments at:=20 https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dprint_ballot= & ballot_id=3D1544&filename=3Ddraft-ietf-ipsec-rfc2401bis,=20 and (c) other IDSG feedback. We have incorporated these changes into=20 a new draft and submitted it to the IETF secretariat. Please let us=20 know if you have any questions. Thank you, Karen Issues in IDSG tracker: =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D 1.1. Harald Alvestrand, Brian Carpenter >4.1 Definition and Scope ... > If different classes of traffic (distinguished by Differentiated > Services CodePoint (DSCP) bits [NiBlBaBL98], [Gro02]) are sent on the > same SA, and if the receiver is employing the optional anti-replay > feature available in both AH and ESP, this could result in > inappropriate discarding of lower priority packets due to the > windowing mechanism used by this feature. Therefore a sender SHOULD > put traffic of different classes, but with the same selector values, > on different SAs to support QoS appropriately. To permit this, the > IPsec implementation MUST permit establishment and maintenance of > multiple SAs between a given sender and receiver, with the same > selectors. Distribution of traffic among these parallel SAs to > support QoS is locally determined by the sender and is not negotiated > by IKE. The receiver MUST process the packets from the different SAs > without prejudice. I think it would be helpful to remind readers that (as indicated in RFC 2983) we are talking here about the "inner" DSCP in a tunnel, which will not be changed en route (since in general, the DSCP value may be changed en route and that destroys the model described, since there would be no fixed relationship between DSCP value and SA). Per agreement with Brian, we added the following text at the end of the above paragraph. These requirements apply to both transport and tunnel mode SAs. In the case of tunnel mode SAs, the DSCP values in question appear in the inner IP header. In transport mode, the DSCP value might change en route, but this should not cause problems with respect to IPsec processing since the value is not employed for SA selection and MUST NOT be checked as part of SA/packet validation. However, if significant re-ordering of packets occurs in an SA, e.g., as a result of changes to DSCP values en route, this may trigger packet discarding by a receiver due to application of the anti-replay mechanism. ------------------------------------------------------------------------ --- 1.2. Harald Alvestrand, Brian Carpenter >I also note that there is no reference to the IPv6 Flow Label. Since this >is an e2e field (RFC 3697) it would actually be easier to handle than the >DSCP, if there was any need to do so. After discussion, we agreed to wait for some experience with flow label usage before trying to craft language. No change was made. ------------------------------------------------------------------------ --- 1.3. Harald Alvestrand, Brian Carpenter >>4.4.2.1 Data Items in the SAD >... >> o Bypass DF bit (T/F) - applicable to tunnel mode SAs Note that this only applies to IPv4 (ditto section 8.1). We changed the text to be: 4.4.2.1 Data Items in the SAD .... o Bypass DF bit (T/F) - applicable to tunnel mode SAs where both inner and outer headers are IPv4. 8.1 DF Bit All IPsec implementations MUST support the option of copying the DF bit from an outbound packet to the tunnel mode header that it emits, when traffic is carried via a tunnel mode SA. This means that it MUST be possible to configure the implementation's treatment of the DF bit (set, clear, copy from inner header) for each SA. This applies to SAs where both inner and outer headers are IPv4. ------------------------------------------------------------------------ --- 1.4. Harald Alvestrand, Brian Carpenter >>4.4.2.1 Data Items in the SAD >... >> o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if >> needed to restrict bypass of DSCP values - applicable to tunnel >> mode SAs This is unclear to me and needs some explanation. Actually, it's unclear how the earlier suggested treatment of DSCPs works, since the DSCP value(s) corresponding to an SA aren't stored anywhere that I noticed, so the model does not allow for demultiplexing on DSCP values in any case. Per agreement with Brian, we added the following text: o Bypass DSCP (T/F) or map to unprotected DSCP values (array) if needed to restrict bypass of DSCP values - applicable to tunnel mode SAs. This feature maps DSCP values from an inner header to values in an outer header, e.g., to address covert channel signalling concerns. o DSCP values: the set of DSCP values allowed for packets carried over this SA. If no values are specified, no DSCP-specific filtering is applied. If one or more values are specified, these are used to select one SA among several that match the traffic selectors for an outbound packet. Note that these values are NOT checked against inbound traffic arriving on the SA. ------------------------------------------------------------------------ --- 1.5. Vishwas Manral and David Black (as part of above discussion with=20 Brian Carpenter) See item 1.1 above. The last sentence was added which says "However, if significant re-ordering of packets occurs in an SA, e.g., as a result of changes to DSCP values en route, this may trigger packet discarding by a receiver due to application of the anti-replay mechanism." ------------------------------------------------------------------------ --- 2.1. Ted Hardie (and elsewhen Brian Carpenter) This seems to have a mix of RFC 2026 and RFC 3668 boilerplates. We believe we've addressed this. The document passes the checks done by the idnits tool. ------------------------------------------------------------------------ --- 2.2. Ted Hardie: In Section 4.1, the draft says: In many secure multicast (or anycast) architectures, e.g., [RFC3740], a central Group Controller/Key Server unilaterally assigns the Group Security Association's (GSA's) SPI. 3740 does not seem to mention anycast. Is there a similar reference for anycast? There isn't any RFC for secure anycast. We removed the "(or anycast)" from the above text and all other instances of anycast have been deleted. We really do not have appropriate provisions to support anycast, since the MSEC WG addresses only multicast. ------------------------------------------------------------------------ --- 2.3. Ted Hardie: Section 4.4.1 uses 192.168 addresses, rather than the example prefix 192.0.2.x/24 Replaced all 192.168.2.y with 192.0.2.x. ------------------------------------------------------------------------ --- 2.4. Ted Hardie: I found the use of "road warrior" in section 4.5.2 distracting. Deleted the "(road warrior)" from Section 4.5.3 Locating a Security Gateway, paragraph 2: "Consider a situation in which a remote host (SH1) is using the Internet to gain access to a server or other machine (H2) and there is a security gateway (SG2), e.g., a firewall, through which H1's traffic must pass. An example of this situation would be a mobile host (road warrior) crossing the Internet to his home organization's firewall (SG2)." ------------------------------------------------------------------------ --- 3.1. Sam Hartman: [issue 1] Added at the end of Section 3.3 (Where IPsec Can Be Implemented) A host implementation of IPsec may appear in devices that might not be viewed as "hosts." For example, a router might employ IPsec to protect routing protocols (e.g., BGP) and management functions (e.g., Telnet), without affecting subscriber traffic traversing the router. A security gateway might employ separate IPsec implementations to protect its management traffic and subscriber traffic. The architecture described in this document is very flexible. For example, a computer with a full-featured, compliant, native OS IPsec implementation should be capable of being configured to protect resident (host) applications and to provide security gateway protection for traffic traversing the computer. Such configuration would make use of the forwarding tables and the SPD selection function described in Sections 5.1 and 5.2. Added the following text to the beginning of section 11 (Security Considerations) IPsec imposes stringent constraints on bypass of IP header data in both directions across the IPsec barrier, especially when tunnel mode SAs are employed. Some constraints are absolute, while others are subject to local administrative controls, often on a per-SA basis. For outbound traffic, these constraints are designed to limit covert channel bandwidth. For inbound traffic, the constraints are designed to prevent an adversary who has the ability to tamper with one data stream (on the unprotected side of the IPsec barrier) from adversely affecting other data streams (on the protected side of the barrier). The discussion in Section 5 dealing with processing DSCP values for tunnel mode SAs illustrates this concern. ------------------------------------------------------------------------ --- 3.2. Sam Hartman: [issue 2] We changed 4.4.1.1 Selectors paragraphs re: Name as follows. Added a sentence to the paragraph re: named entry used by an initiator: "Support for this use is optional for multi-user, native host implementations and not applicable to other implementations. Note that this name is used only locally; it is not communicated by the key management protocol. Also, name forms other than those used for case 1 above (responder) are applicable in the initiator context (see below)." Altered the examples given for the types of names as shown below: "For case 1, responder, the identifiers employed in named SPD entries are one of the following four types: a. a fully qualified user name string (email), e.g., mozart@foo.example.com (this corresponds to ID_RFC822_ADDR in IKEv2) b. a fully qualified DNS name, e.g., foo.example.com (this corresponds to ID_FQDN in IKEv2) c. X.500 distinguished name, e.g., C =3D US, SP =3D MA O =3D BBN Technologies, CN =3D Stephen T. Kent (this corresponds to ID_DER_ASN1_DN in IKEv2, after decoding) d. a byte string (this corresponds to Key_ID in IKEv2) For case 2, initiator, the identifiers employed in named SPD entries are of type byte string. They are likely to be Unix UIDs, Windows security IDs or something similar, but could also be a user name or account name. In all cases, this identifier is only of local concern and is not transmitted." Modified the ASN.1 as shown below: NameSets ::=3D SEQUENCE { passed SET OF Names-R, -- Matched to IKE ID by responder local SET OF Names-I } -- Used internally by IKE initiator Names-R ::=3D CHOICE { -- IKEv2 IDs: dName DistinguishedName, -- ID_DER_ASN1_DN fqdn FQDN, -- ID_FQDN rfc822 [0] RFC822Name, -- ID_RFC822_ADDR keyID OCTET STRING } -- KEY_ID Names-I ::=3D OCTET STRING -- Used internally by IKE initiator ------------------------------------------------------------------------ --- 3.3. Sam Hartman: [issue 3] Per discussione with Sam Hartman, we modified Section 4.4.1.1 re: Name by re-ordering the components of the distinguished name as shown below and adding a Normative reference for RFC 2253: From: c. X.500 distinguished name, e.g., C =3D US, SP =3D MA, O =3D BBN Technologies, CN =3D Stephen T. Kent (this corresponds to ID_DER_ASN1_DN in IKEv2, after decoding) To: c. X.500 distinguished name, e.g., [WaKiHo97], CN =3D Stephen T. Kent, O =3D BBN Technologies, SP =3D MA, C =3D US (this corresponds to ID_DER_ASN1_DN in IKEv2, after decoding) Added: [WaKiHo97] Wahl, M., Kille, S., Howes, T., "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253, December 1997 ------------------------------------------------------------------------ --- 3.4. Sam Hartman: [issue 4] Addressed Sam's concerns in email exchange -- no change was made. ------------------------------------------------------------------------ --- 3.5. Sam Hartman: [issue 5] Per discussion, we added the following text to - Section 4.4.2 Security Association Database (SAD) at the end of paragraph 2. - Section 5 IP Traffic Processing, paragraph 1: Note also, that there are a couple of situations in which the SAD can have entries for SAs that do not have corresponding entries in the SPD. Since 2401bis does not mandate that the SAD be selectively cleared when the SPD is changed, SAD entries can remain when the SPD entries that created them are changed or deleted. Also, if a manually keyed SA is created, there could be an SAD entry for this SA that does not correspond to any SPD entry. And changed Section 4.4.1, paragraph on "How To Derive the Values for an SAD entry" From: For inbound traffic not protected by IPsec, there are SPD-I cache entries and there is the SAD, which represents the cache for inbound IPsec-protected traffic (See Figure 3 in Section 5.2). To: For inbound traffic not protected by IPsec, there are SPD-I cache entries and there is the SAD, which represents the cache for inbound IPsec-protected traffic (See Section 4.4.2). And added two footnotes to Figure 3 to clarify where the SAD's role as an SPD inbound (**) =3D This processing includes using the packet's SPI, etc to look up the SA in the SAD, which forms a cache of the SPD for inbound packets (except for cases noted in Sections 4.4.2 and 5) - see step 3a below. (***) =3D This SAD check refers to step 4 below. ------------------------------------------------------------------------ --- 3.6. Sam Hartman: [Issue 6] Changed the text of Section 5.2 by taking the first paragraph after step 4 and turning it into step 5 and un-indenting the 2nd and 3rd paragraphs after step 4 so that they are NOT part of the processing steps: From: 4. Apply AH or ESP processing as specified, using the SAD entry selected in step 3a above. Then match the packet against the inbound selectors identified by the SAD entry to verify that the received packet is appropriate for the SA via which it was received. If an IPsec system receives an inbound packet on an SA and the packet's header fields are not consistent with the selectors for the SA, it MUST discard the packet...... To minimize the impact of a DoS attack, or a mis-configured peer, the IPsec system SHOULD include a management control to allow an administrator to configure .... After traffic is bypassed or processed through IPsec, it is handed to the inbound forwarding function for disposition... To: 4. Apply AH or ESP processing as specified, using the SAD entry selected in step 3a above. Then match the packet against the inbound selectors identified by the SAD entry to verify that the received packet is appropriate for the SA via which it was received. 5. If an IPsec system receives an inbound packet on an SA and the packet's header fields are not consistent with the selectors for the SA, it MUST discard the packet...... To minimize the impact of a DoS attack, or a mis-configured peer, the IPsec system SHOULD include a management control to allow an administrator to configure .... After traffic is bypassed or processed through IPsec, it is handed to the inbound forwarding function for disposition... ------------------------------------------------------------------------ --- 3.7. Sam Hartman: [Issue 7] We added the following text to Section 7.4 As noted above, in network configurations where fragments of a packet might be sent or received via different security gateways or BITW implementations, stateful strategies for tracking fragments may fail. ------------------------------------------------------------------------ --- 3.8. Sam Hartman: [Issue 8] Inserted new PAD text into section 4.4.3 replacing previous text. Added a reference for (IKEv1 (RFC2409) by Harkins and Carrel). ------------------------------------------------------------------------ --- 3.9. Sam Hartman: [Issue 9] The ASN.1 has been modified to compile as is. So the problem text at the top of the appendix has been replaced with text saying that this code compiles. Changes included: Replaced DistinguishedName with RDNSequence Changed ANY DEFINED BY to ANY -- DEFINED BY algorithm.... Checked for any duplicate tags ------------------------------------------------------------------------ --- 3.9. Sam Hartman: [No issue number assigned] Section 6.1.2 creates requirements for incoming ICMP packets on the protected side of the IPsec boundary. As best I can tell the attacks described in that section are potential problems for any Internet gateway and have nothing to do with IPsec. If so, why should the IPsec architecture add requirements for additional administrative controls to mitigate these attacks? (I think the administrative controls are a good idea; I'm just unsure why this specification is the right place for them.) Based on discussion, no changes were made. ------------------------------------------------------------------------ --- 3.10 Sam Hartman: [No issue number assigned] Section 4.5.3 Locating a Security Gateway. Since the IPSP working group was just closed, the last 2 sentences of this section were deleted. The corresponding text in Section 13. "Differences from RFC 2401" was also deleted. "The IP Security Policy (IPSP) Working Group is a possible future source of guidance. One of its goals is to produce an Internet Draft on a "Security Gateway Discovery, Policy Exchange and Negotiation Protocol". ------------------------------------------------------------------------ --- 4.1. Russ Housley: When will the module identifier be assigned for Appendix C? If you want IANA to do it, then it needs to be called out in the IANA Considerations section. There is currently no IPsec arc (just the ISAKMP and IKE arcs) So we requested one from IANA and we changed Section 12. IANA Considerations From: This document has no actions for IANA. To: This document contains a "magic" number to be maintained by the IANA. Upon approval of this draft for publication as an RFC, IANA is to create a registry for ASN.1 Modules under the Prefix: iso.org.dod.internet.security.mechanisms.ipsec (1.3.6.1.5.5.8) In Appendix C "ASN.1 for an SPD Entry", the number assigned to the ASN.1 Modules registry is to replace the xx corresponding to the asn1\(hymodules and the object identifier assigned to spd\(hymodule is to replace the "yy" for the spd\(hymodule. ------------------------------------------------------------------------ --- 4.2. Russ Housley: Section 4.1: s/Memory (TCAM0 features/Memory (TCAM) features/ Section 4.4.1: s/SPD-SPD-S, SPD-SPD-I, SPD-SPD-O/SPD-S, SPD-I, SPD-O/ s/The SPD-SPD-S/The SPD-S/ Section 4.4.2: s/Database(SAD),/Database (SAD),/ Section 8.2.1: s/SAD entry When/SAD entry. When/ The above changes have been made. ------------------------------------------------------------------------ --- 4.3. Russ Housley: In making the other changes to the document, you added the=20 "addresses" element to the "TunnelOptions" structure. You forgot the=20 comma after "DF" when this change was made. Here is an ASN.1 module=20 that compiles (using the 1990 syntax). Updated ASN.1 module (Appendix C) ------------------------------------------------------------------------ --- 5.1. Alex Zinin: Discuss: How does the in/out-bound processing model defined in section 5 work=20 in the case of a VPN gateway? In particular, how does presence of multiple routing realms and a two-stage forwarding process affect it (imagine a gw that uses dynamic routing over the VPN tunnels protected by IPsec transport mode as encapsulated packets leave the box)? What about locally-originated messages, such as routing messages in this case. I know how to make it work, the question is how the described model addresses these scenarios. We answered Alex's questions. No change was made. ------------------------------------------------------------------------ --- 5.2. Alex Zinin: Section 4.4 Major IPsec Databases: > Forwarding vs Security Decisions > The IPsec model described here embodies a clear separation between > forwarding (routing) and security decisions, to accommodate a wide > range of contexts where IPsec may be employed. Forwarding may be > trivial, in the case where there are only two interfaces, or it > may be complex, e.g., if there are multiple protected or > unprotected interfaces or if the context in which IPsec is > implemented employs a sophisticated forwarding function. minor note: complexity of forwarding doesn't depend directly on the number of local interfaces. We deleted "if there are multiple protected or unprotected interfaces or" so that the text now says: Forwarding vs Security Decisions The IPsec model described here embodies a clear separation between forwarding (routing) and security decisions, to accommodate a wide range of contexts where IPsec may be employed. Forwarding may be trivial, in the case where there are only two interfaces, or it may be complex, e.g., if the context in which IPsec is implemented employs a sophisticated forwarding function. ------------------------------------------------------------------------ --- 5.3. Alex Zinin: > IPsec assumes only that outbound and inbound traffic that has passed > through IPsec processing is forwarded in a fashion consistent with > the context in which IPsec is implemented. What does the above statement really mean? We answered Alex's question in email exchange. No change was made. ------------------------------------------------------------------------ --- 5.4. Alex Zinin: Though Appendix E is not normative, I should note that it is rather confusing. Specifically, though the document states that no changes to the forwarding function are introduced, the appendix mentions two different forwarding tables--one for protected, and one for unprotected side. Also, the representation of the forwarding tables themselves creates an impression that routes usually include both source and destination prefixes, which=20 clearly isn't true (unless we're talking about a special case of policy-based=20 routing). Again, I know how to make it work, but I don't think the doc is very good at=20 explaining this. We answered Alex's questions in email exchange. No change was made. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D Per discussion with Russ Housley, the following changes were made to=20 address various issues brought up on the IPsec mailing list: Re: handling multicast: Section 4.4.1.1, added the text below after the paragraphs on remote and local IP address(es). Note: The SPD does not include support for multicast address entries. To support multicast SAs, an implementation should make use of a Group SPD (GSPD) as defined in [RFC3740]. GSPD entries require a different structure, i.e., one cannot use of the symmetric relationship associated with local and remote address values for unicast SAs in a multicast context. Specifically, outbound traffic directed to a multicast address on an SA would not be received on a companion, inbound SA with the multicast address as the source. Section 4.4.2, added the following text after the 2nd paragraph: Note: The SAD can support multicast SAs, if manually configured. An outbound multicast SA has the same structure as a unicast SA. The source address is that of the sender and the destination address is the multicast group address. An inbound, multicast SA must be configured with the source addresses of each peer authorized to transmit to the multicast SA in question. The SPI value for a multicast SA is provided by a multicast group controller, not by the receiver, as for a unicast SA. Because an SAD entry may be required to accommodate multiple, individual IP source addresses that were part of an SPD entry (for unicast SAs), the required facility for inbound, multicast SAs is a feature already present in an IPsec implementation. However, because the SPD has no provisions for accommodating multicast entries, this document does not specify an automated way to create an SAD entry for a multicast, inbound SA. Only manually configured SAD entries can be created to accommodate inbound, multicast traffic. Section 4.4.1.1, the 2 paragraphs on Remote and Local IP Address(es) -- references to "multicast group" were removed. ------------------------------------------------------------------------ --- Re: handling ECN or DS Section 5.2.2, replaced the bullet o IPsec describes how to handle ECN or DS. with o IPsec describes how to handle ECN and DS and provides the ability to control propagation of changes in these fields between unprotected and protected domains. In general, propagation from a protected to an unprotected domain is a covert channel and thus controls are provided to manage the bandwidth of this channel. Propagation of ECN values in the other direction are controlled so that only legitimate ECN changes (indicating occurrence of congestion between the tunnel endpoints) are propagated. By default, DS propagation from an unprotected domain to a protected domain is not permitted. However, if the sender and receiver do not share the same DS code space, and the receiver has no way of learning how to map between the two spaces, then it may be appropriate to deviate from the default. Specifically, an IPsec implementation MAY be configurable in terms of how it processes the outer DS field for tunnel mode for received packets. It may be configured to either discard the outer DS value (the default) OR to overwrite the inner DS field with the outer DS field. If offered the discard vs. overwrite behavior MAY be configured on a per SA basis. This configuration option allows a local administrator to decide whether the vulnerabilities created by copying these bits outweigh the benefits of copying. See [RFC 2983] for further information on when each of these behaviors may be useful, and also for the possible need for diffserv traffic conditioning prior or subsequent to IPsec processing (including tunnel decapsulation). In 5.1.2.2, changed the the header construction table for DS Field, so that the column for the decapsulator says "no change" (9) and added note 9: 9. An implementation MAY choose to provide a facility to pass the DS value from the outer header to the inner header, on a per SA basis, for received tunnel mode packets. The motivation for providing this feature is to accommodate situations in which the DS code space at the receiver is different from that of the sender and the receiver has no way of knowing how to translate from the sender's space. There is a danger in copying this value from the outer header to the inner header, since it enables an attacker to modify the outer DSCP value in a fashion that may adversely affect other traffic at the receiver. Hence the default behavior for IPsec implementations is NOT to permit such copying. ------------------------------------------------------------------------ --- Re: decorrelated vs not-decorrelated SPD and what is passed between peers to negotiate an SA. Also re: addressing the mis-alignment of the semantics of IKEv2 with those of the SPD Section 4.4.1, Decorrelation subsection, deleted last 4 sentences of 2nd paragraph: "Note also that if a decorrelated SPD is employed, the original entry from the (correlated) SPD should be retained and passed to the SA management protocol, e.g., IKE. Passing the correlated SPD entry to the SA management protocol keeps the use of a decorrelated SPD a local matter, not visible to peers. When acting as a responder, the peer uses a correlated SPD entry for matching, and for issuing a "narrowed" response. Then the decorrelated entries are used to populate the SPD-S cache." and replaced them with the following 5 paragraphs: If a decorrelated SPD is employed, there are three options for what an initiator sends to a peer via an SA management protocol (e.g., IKE). By sending the complete set of linked, decorrelated entries that were selected from the SPD, a peer is given the best possible information to enable selection of the appropriate SPD entry at its end, especially if the peer has also decorrelated its SPD. However, if a large number of decorrelated entries are linked, this may create large packets for SA negotiation, and hence fragmentation problems for the SA management protocol. Alternatively, the original entry from the (correlated) SPD may be retained and passed to the SA management protocol. Passing the correlated SPD entry keeps the use of a decorrelated SPD a local matter, not visible to peers, and avoids possible fragmentation concerns, although it provides less precise information to a responder for matching against the responder's SPD. An intermediate approach is to send a subset of the complete set of linked, decorrelated SPD entries. This approach can avoid the fragmentation problems cited above and yet provide better information than the original, correlated entry. The major shortcoming of this approach is that it may cause additional SAs to be created later, since only a subset of the linked, decorrelated entries are sent to a peer. Implementers are free to employ any of the approaches cited above. A responder uses the traffic selector proposals it receives via an SA management protocol to select an appropriate entry in its SPD. The intent of the matching is to select an SPD entry and create an SA that most closely matches the intent of the initiator, so that traffic traversing the resulting SA will be accepted at both ends. If the responder employs a decorrelated SPD, it SHOULD use the decorrelated SPD entries for matching, as this will generally result in creation of SAs that are more likely to match the intent of both peers. If the responder has a correlated SPD, then it SHOULD match the proposals against the correlated entries. For IKE v2, use of a decorrelated SPD offers the best opportunity for a responder to generate a "narrowed" response. In all cases, when a decorrelated SPD is available, the decorrelated entries are used to populate the SPD-S cache. If the SPD is not decorrelated, caching is not allowed and an ordered search of SPD MUST be performed to verify that inbound traffic arriving on an SA is consistent with the access control policy expressed in the SPD. Section 4.4.1.2, 2nd paragraph. Changed From: This text describes the SPD in a fashion that maps directly into IKE payloads to ensure that the policy required by SPD entries can be negotiated through IKE. The management GUI can offer the user other forms of data entry and display..... To: This text describes the SPD in a fashion that is intended to map directly into IKE payloads to ensure that the policy required by SPD entries can be negotiated through IKE. Unfortunately, the semantics of the version of IKE v2 published concurrently with this document [Kau05] do not align precisely with those defined for the SPD. Specifically, IKE v2 does not enable negotiation of a single SA that binds multiple pairs of local and remote addresses and ports to a single SA. Instead, when multiple local and remote addresses and ports are negotiated for an SA, IKE v2 treats these not as pairs, but as (unordered) sets of local and remote values that can be arbitrarily paired. Until IKE provides a facility that conveys the semantics that are expressed in the SPD via selector sets (as described below), users MUST NOT include multiple selector sets in a single SPD entry unless the access control intent aligns with the IKE "mix and match" semantics. An implementation MAY warn users, to alert them to this problem if users create SPD entries with multiple selector sets, the syntax of which indicates possible conflicts with current IKE semantics. The management GUI can offer the user other forms of data entry and display... Additional issue from the list =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D =3D=3D=3D=3D 2/15/05 Atul Sharma brought up the case of two tunnels protecting the=20 same addresses/hosts but with different tunnel endpoints... To=20 clarify matters, we made the following changes. Section 4.4.3 Peer Authorization Database (PAD) -- modified the last bullet of paragraph 3 in the new PAD text. from: o peer gateway location info, e.g., an IP address or a DNS name, MAY be included for peers that are known to be "behind" a security gateway to: o peer gateway location info, e.g., IP address(es) or DNS name(s), MAY be included for a peer that is known to be "behind" a security gateway or gateways. and added the following sentence at the end of the section: Note that the PAD information MAY be used to support creation of more than one tunnel mode SA at a time between two peers, e.g., two tunnels to protect the same addresses/hosts, but with different tunnel endpoints. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 23 09:31:24 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19021 for ; Wed, 23 Mar 2005 09:31:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE6nF-0004eH-Bl; Wed, 23 Mar 2005 09:25:09 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE6nC-0004e1-3r for ipsec@megatron.ietf.org; Wed, 23 Mar 2005 09:25:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18271 for ; Wed, 23 Mar 2005 09:25:03 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE6sf-0007UL-Az for ipsec@ietf.org; Wed, 23 Mar 2005 09:30:45 -0500 Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j2NEOMvF008839; Wed, 23 Mar 2005 09:24:23 -0500 (EST) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: References: Date: Wed, 23 Mar 2005 09:29:33 -0500 To: "Vishwas Manral" From: Karen Seo Subject: Re: FW: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.4 (/) X-Scan-Signature: 509eeaf340e89c687918a6101c6def35 Cc: ipsec@ietf.org, angelos@cs.columbia.edu, "Theodore Ts'o" , Barbara Fraser , Russ Housley , kivinen@iki.fi X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0452596990==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0452596990== Content-Type: multipart/alternative; boundary="============_-1100534317==_ma============" --============_-1100534317==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Hi Vishwas, Thank you for the email below. I was worried for a moment there. I checked the list of changes I just sent out and the update you describe below is on the list (about 3/4's of the way down) and in the new draft. Karen >Hi Karen, > >This is what Steve had sent a month back. > >Thanks, >Vishwas > >From: Stephen Kent [mailto:kent@bbn.com] >Sent: Monday, February 28, 2005 9:59 PM >To: Black_David@emc.com >Cc: Vishwas Manral; hartmans-ietf@mit.edu; brc@zurich.ibm.com; >Black_David@emc.com; housley@vigilsec.com; Stephen Kent >Subject: RE: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt > >Folks, > >Here is the text I have crafted for the next rev of 2401bis, based >on David's suggested text from a few weeks ago: > >In 5.1.2 replace the bullet: > > o IPsec describes how to handle ECN or DS. > >with > > o IPsec describes how to handle ECN and DS and provides the ability > >to control propagation of changes in these fields between unprotected > >and protected domains. In general, propagation from a protected to an > >unprotected domain is a covert channel and thus controls are provided > >to manage the bandwidth of this channel. Propagation of ECN values in > >the other direction are controlled so that only legitimate > >ECN changes (indicating occurrence of congestion between the tunnel > >endpoints) are propagated. By default, DS propagation from an > >unprotected domain to a protected domain is not permitted. However, > >if the sender and receiver do not share the same DS code space, and > >the receiver has no way of learning how to map between the two spaces, > >then it may be appropriate to deviate from the default. Specifically, > >an IPsec implementation MAY be configurable in terms of how it processes > >the outer DS field for tunnel mode for received packets. It may be > >configured to either discard the outer DS value (the default) OR to > >overwrite the inner DS field with the outer DS field. If offered > >the discard vs. overwrite behavior MAY be configured on a per SA basis. > >This configuration option allows a local administrator to decide whether > >the vulnerabilities created by copying these bits outweigh the > >benefits of copying. See [RFC 2983] for further information on when > each of these behaviors may be useful, and also for the possible > need for diffserv traffic conditioning prior or subsequent to IPsec > >processing (including tunnel decapsulation). > >In 5.1.2.2, change the the header construction table for DS Field, >so that the column for the decapsulator says "no change" (9). > >add note 9 > > 9. An implementation MAY choose to provide a facility to bypass > >the DS value from the outer header to the inner header, on > >a per SA basis, for received tunnel mode packets. The motivation > >for providing this feature is to accommodate situations in which > >the DS code space at the receiver is different from that of the > >sender and the receiver has no way of knowing how to translate from > >the sender's space. There is a danger in copying this value from > >the outer header to the inner header, since it enables an attacker > >to modify the outer DSCP value in a fashion that may adversely affect > >other traffic at the receiver. Hence the default behavior for IPsec > >implementations is NOT to permit such copying. > > --============_-1100534317==_ma============ Content-Type: text/html; charset="us-ascii" Re: FW: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt
Hi Vishwas,

Thank you for the email below.  I was worried for a moment there.  I checked the list of changes I just sent out and the update you describe below is on the list (about 3/4's of the way down) and in the new draft.

Karen


Hi Karen,
 
This is what Steve had sent a month back.
 
Thanks,
Vishwas
From: Stephen Kent [mailto:kent@bbn.com]
Sent: Monday, February 28, 2005 9:59 PM
To: Black_David@emc.com
Cc: Vishwas Manral; hartmans-ietf@mit.edu; brc@zurich.ibm.com; Black_David@emc.com; housley@vigilsec.com; Stephen Kent
Subject: RE: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt
 
Folks,
 
Here is the text I have crafted for the next rev of 2401bis, based on David's suggested text from a few weeks ago:
 
In 5.1.2 replace the bullet:
 
 o IPsec describes how to handle ECN or DS.
 
with
 
  o IPsec describes how to handle ECN and DS and provides the ability
       
to control propagation of changes in these fields between unprotected
       
and protected domains. In general, propagation from a protected to an
       
unprotected domain is a covert channel and thus controls are provided
       
to manage the bandwidth of this channel. Propagation of ECN values in
       
the other direction are controlled so that only legitimate
       
ECN changes (indicating occurrence of congestion between the tunnel
       
endpoints) are propagated.  By default, DS propagation from an
       
unprotected domain to a protected domain is not permitted.  However,
       
if the sender and receiver do not share the same DS code space, and
       
the receiver has no way of learning how to map between the two spaces,
       
then it may be appropriate to deviate from the default. Specifically,
       
an IPsec implementation MAY be configurable in terms of how it processes
       
the outer DS field for tunnel mode for received packets. It may be
       
configured to either discard the outer DS value (the default) OR to
       
overwrite the inner DS field with the outer DS field.  If offered
       
the discard vs. overwrite behavior MAY be configured on a per SA basis.
       
This configuration option allows a local administrator to decide whether
       
the vulnerabilities created by copying these bits outweigh the
       
benefits of copying.  See [RFC 2983] for further information on when
    each of these behaviors may be useful, and also for the possible
        need for diffserv traffic conditioning prior or subsequent to IPsec
       
processing (including tunnel decapsulation).
 
In 5.1.2.2, change the the header construction table for DS Field, so that the column for the decapsulator says "no change" (9).
 
add note 9
 
     9. An implementation MAY choose to provide a facility to bypass
       
the DS value from the outer header to the inner header, on
       
a per SA basis, for received tunnel mode packets. The motivation
       
for providing this feature is to accommodate situations in which
       
the DS code space at the receiver is different from that of the
       
sender and the receiver has no way of knowing how to translate from
       
the sender's space. There is a danger in copying this value from
       
the outer header to the inner header, since it enables an attacker
       
to modify the outer DSCP value in a fashion that may adversely affect
       
other traffic at the receiver.  Hence the default behavior for IPsec
       
implementations is NOT to permit such copying.
 
 

--============_-1100534317==_ma============-- --===============0452596990== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0452596990==-- From ipsec-bounces@ietf.org Wed Mar 23 10:38:33 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA26504 for ; Wed, 23 Mar 2005 10:38:33 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE7sR-0007u7-On; Wed, 23 Mar 2005 10:34:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DE7sP-0007tz-Cy for ipsec@megatron.ietf.org; Wed, 23 Mar 2005 10:34:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25925 for ; Wed, 23 Mar 2005 10:34:30 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DE7xs-0000vn-Fj for ipsec@ietf.org; Wed, 23 Mar 2005 10:40:13 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j2NFWBvJ013483; Wed, 23 Mar 2005 10:32:13 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 23 Mar 2005 10:30:42 -0500 To: "Vishwas Manral" From: Stephen Kent Subject: RE: [Ipsec] IPsec 2401bis changes Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: ipsec@ietf.org, Karen Seo , "Theodore Ts'o" , kivinen@iki.fi, Barbara Fraser , Russ Housley , angelos@cs.columbia.edu X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Vishwas, I suggest you search the message for the string "DSCP" to locate all of the new text that deals with this topic. I believe the several changes we have made are consistent with the conclusions of the discussions we had on the topic with various parties. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Mar 25 15:03:02 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05236 for ; Fri, 25 Mar 2005 15:03:02 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEuzX-00024U-5j; Fri, 25 Mar 2005 15:01:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEuzV-00024P-0u for ipsec@megatron.ietf.org; Fri, 25 Mar 2005 15:01:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04919 for ; Fri, 25 Mar 2005 15:01:07 -0500 (EST) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DEv5Q-0003J0-PB for ipsec@ietf.org; Fri, 25 Mar 2005 15:07:18 -0500 Received: (qmail 21118 invoked by uid 0); 25 Mar 2005 20:01:01 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.136.53) by woodstock.binhost.com with SMTP; 25 Mar 2005 20:01:01 -0000 Message-Id: <6.2.0.14.2.20050325145539.07d2d170@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.0.14 Date: Fri, 25 Mar 2005 14:59:28 -0500 To: Karen Seo From: Russ Housley Subject: Re: [Ipsec] IPsec 2401bis changes In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 1.3 (+) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Karen: The document should simply ask IANA to assign the object identifier for the module in Appendix C. I think that only the last paragraph is needed to say that. The discussion of "magic" numbers is going to add confusion, I think. I spoke with Michelle Cotton at the IETF meeting, and she is prepared to make the assignment as soon as the document is approved. Russ >--------------------------------------------------------------------------- >4.1. Russ Housley: > > When will the module identifier be assigned for Appendix C? > If you want IANA to do it, then it needs to be called out in > the IANA Considerations section. > > There is currently no IPsec arc (just the ISAKMP and IKE arcs) > So we requested one from IANA and we changed Section 12. IANA > Considerations > > From: > > This document has no actions for IANA. > > To: > > This document contains a "magic" number to be maintained by > the IANA. Upon approval of this draft for publication as an > RFC, IANA is to create a registry for ASN.1 Modules under > the Prefix: > > iso.org.dod.internet.security.mechanisms.ipsec (1.3.6.1.5.5.8) > > In Appendix C "ASN.1 for an SPD Entry", the number assigned > to the ASN.1 Modules registry is to replace the xx > corresponding to the asn1\(hymodules and the object > identifier assigned to spd\(hymodule is to replace the "yy" > for the spd\(hymodule. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Mar 25 15:51:24 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10787 for ; Fri, 25 Mar 2005 15:51:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEvkx-0008Vv-Sj; Fri, 25 Mar 2005 15:50:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEvkw-0008Vq-Mh for ipsec@megatron.ietf.org; Fri, 25 Mar 2005 15:50:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10681 for ; Fri, 25 Mar 2005 15:50:08 -0500 (EST) From: shu1@gmu.edu Received: from mail03.gmu.edu ([129.174.0.113]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEvqs-0004bQ-SC for ipsec@ietf.org; Fri, 25 Mar 2005 15:56:20 -0500 Received: from gmu.edu (localhost [127.0.0.1]) by mserver3.gmu.edu (iPlanet Messaging Server 5.2 HotFix 1.21 (built Sep 8 2003)) with ESMTP id <0IDX0024RDVCMX@mserver3.gmu.edu> for ipsec@ietf.org; Fri, 25 Mar 2005 15:50:00 -0500 (EST) Received: from [216.177.47.67] by mserver3.gmu.edu (mshttpd); Fri, 25 Mar 2005 15:50:00 -0500 Date: Fri, 25 Mar 2005 15:50:00 -0500 To: ipsec@ietf.org Message-id: <3ad4c33b0c6d.3b0c6d3ad4c3@gmu.edu> MIME-version: 1.0 X-Mailer: iPlanet Messenger Express 5.2 HotFix 1.21 (built Sep 8 2003) Content-type: text/plain; charset=us-ascii Content-language: en Content-transfer-encoding: 7BIT Content-disposition: inline X-Accept-Language: en Priority: normal X-Spam-Score: 0.3 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Content-Transfer-Encoding: 7BIT Subject: [Ipsec] SA Life time and Certificate expiration date X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7BIT What shoud the IKE do if the user configure SA life time ( say 5 days) is more than the certificate remaining time (say, the certifcate will be expired in 3 days)? Should we pick the minimum of {the SA life time the user configured, the certificate remaining time}, or should we abort IKE and send audit to the user? I think this may be in RFC documnt or already discussed, but I couldn't find. Sorry if it's too trivial. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Mar 25 15:58:21 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11959 for ; Fri, 25 Mar 2005 15:58:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEvqM-0001Ky-0i; Fri, 25 Mar 2005 15:55:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DEvqK-0001Ko-K5 for ipsec@megatron.ietf.org; Fri, 25 Mar 2005 15:55:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA11740 for ; Fri, 25 Mar 2005 15:55:42 -0500 (EST) Received: from sj-iport-2-in.cisco.com ([171.71.176.71] helo=sj-iport-2.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DEvwG-00055W-PH for ipsec@ietf.org; Fri, 25 Mar 2005 16:01:54 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-2.cisco.com with ESMTP; 25 Mar 2005 12:55:34 -0800 Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j2PKtODr003986; Fri, 25 Mar 2005 12:55:24 -0800 (PST) Received: from [10.32.227.24] ([10.32.227.24]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id BDI14279; Fri, 25 Mar 2005 12:55:23 -0800 (PST) Message-ID: <42447A83.7030803@cisco.com> Date: Fri, 25 Mar 2005 12:54:27 -0800 From: Geoffrey Huang User-Agent: Mozilla Thunderbird 1.0 (X11/20050122) X-Accept-Language: en-us, en MIME-Version: 1.0 To: shu1@gmu.edu Subject: Re: [Ipsec] SA Life time and Certificate expiration date References: <3ad4c33b0c6d.3b0c6d3ad4c3@gmu.edu> In-Reply-To: <3ad4c33b0c6d.3b0c6d3ad4c3@gmu.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit This should be an implementation/policy decision. -g shu1@gmu.edu wrote: > What shoud the IKE do if the user configure SA life time ( say 5 days) is more than the certificate remaining time (say, the certifcate will be expired in 3 days)? Should we pick the minimum of {the SA life time the user configured, the certificate remaining time}, or should we abort IKE and send audit to the user? > > I think this may be in RFC documnt or already discussed, but I couldn't find. Sorry if it's too trivial. > > > > > _______________________________________________ > 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 Mar 25 23:36:15 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25586 for ; Fri, 25 Mar 2005 23:36:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DF2yt-00051i-Gp; Fri, 25 Mar 2005 23:33:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DF2yr-00051a-2u for ipsec@megatron.ietf.org; Fri, 25 Mar 2005 23:33:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA25182 for ; Fri, 25 Mar 2005 23:32:57 -0500 (EST) Received: from rs15.luxsci.com ([65.61.166.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DF34r-0004lb-JN for ipsec@ietf.org; Fri, 25 Mar 2005 23:39:13 -0500 Received: from rs15.luxsci.com (localhost [127.0.0.1]) by rs15.luxsci.com (8.12.11/8.12.11) with ESMTP id j2Q4Vhfb013107; Fri, 25 Mar 2005 22:31:43 -0600 Received: (from root@localhost) by rs15.luxsci.com (8.12.11/8.12.11/Submit) id j2Q4U2Tg012795; Sat, 26 Mar 2005 04:30:02 GMT Message-Id: <200503260430.j2Q4U2Tg012795@rs15.luxsci.com> Received: from ietf-wd@v6security.com by LuxSci SMTP Remailer; Sat, 26 Mar 2005 04:30:02 +0000 From: "William Dixon" To: "'Geoffrey Huang'" , Subject: RE: [Ipsec] SA Life time and Certificate expiration date Date: Fri, 25 Mar 2005 23:29:45 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: <42447A83.7030803@cisco.com> X-Lux-Comment: LuxSci remailer message ID code - 1111811402-6911900.42871174 [0] X-Spam-Score: 0.8 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit I think I know what Geoff means, but this is actually covered by RFC 2401 page 21, 22: "A compliant implementation MUST support both types of lifetimes, and must support a simultaneous use of both. If time is employed, and if IKE employs X.509 certificates for SA establishment, the SA lifetime must be constrained by the validity intervals of the certificates, and the NextIssueDate of the CRLs used in the IKE exchange for the SA. Both initiator and responder are responsible for constraining SA lifetime in this fashion. [REQUIRED for all implementations]" -Wm > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Geoffrey Huang > Sent: Friday, March 25, 2005 3:54 PM > To: shu1@gmu.edu > Cc: ipsec@ietf.org > Subject: Re: [Ipsec] SA Life time and Certificate expiration date > > This should be an implementation/policy decision. > > -g > > > shu1@gmu.edu wrote: > > What shoud the IKE do if the user configure SA life time ( > say 5 days) is more than the certificate remaining time (say, > the certifcate will be expired in 3 days)? Should we pick the > minimum of {the SA life time the user configured, the > certificate remaining time}, or should we abort IKE and send > audit to the user? > > > > I think this may be in RFC documnt or already discussed, > but I couldn't find. Sorry if it's too trivial. > > > > > > > > > > _______________________________________________ > > Ipsec mailing list > > Ipsec@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Mar 26 00:44:10 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00866 for ; Sat, 26 Mar 2005 00:44:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DF42m-00063z-1z; Sat, 26 Mar 2005 00:41:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DF42j-00063R-U9 for ipsec@megatron.ietf.org; Sat, 26 Mar 2005 00:41:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA00322 for ; Sat, 26 Mar 2005 00:41:02 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DF48l-000751-CZ for ipsec@ietf.org; Sat, 26 Mar 2005 00:47:19 -0500 Received: from sj-core-5.cisco.com (171.71.177.238) by sj-iport-3.cisco.com with ESMTP; 25 Mar 2005 21:40:56 -0800 X-IronPort-AV: i="3.91,124,1110182400"; d="scan'208"; a="241086599:sNHT28224960" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-5.cisco.com (8.12.10/8.12.6) with ESMTP id j2Q5erZV007407; Fri, 25 Mar 2005 21:40:54 -0800 (PST) Received: from [10.32.227.24] ([10.32.227.24]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id BDI49105; Fri, 25 Mar 2005 21:40:53 -0800 (PST) Message-ID: <4244F5AD.5060209@cisco.com> Date: Fri, 25 Mar 2005 21:39:57 -0800 From: Geoffrey Huang User-Agent: Mozilla Thunderbird 1.0 (X11/20050122) X-Accept-Language: en-us, en MIME-Version: 1.0 To: William Dixon Subject: Re: [Ipsec] SA Life time and Certificate expiration date References: <200503260430.j2Q4U2Tg012795@rs15.luxsci.com> In-Reply-To: <200503260430.j2Q4U2Tg012795@rs15.luxsci.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Doh - well, I stand corrected :-). -g William Dixon wrote: > I think I know what Geoff means, but this is actually covered by RFC 2401 > page 21, 22: > > "A compliant implementation MUST support > both types of lifetimes, and must support a simultaneous use > of both. If time is employed, and if IKE employs X.509 > certificates for SA establishment, the SA lifetime must be > constrained by the validity intervals of the certificates, > and the NextIssueDate of the CRLs used in the IKE exchange for the SA. > Both initiator and responder are responsible for > constraining SA lifetime in this fashion. > [REQUIRED for all implementations]" > > -Wm > > >>-----Original Message----- >>From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] >>On Behalf Of Geoffrey Huang >>Sent: Friday, March 25, 2005 3:54 PM >>To: shu1@gmu.edu >>Cc: ipsec@ietf.org >>Subject: Re: [Ipsec] SA Life time and Certificate expiration date >> >>This should be an implementation/policy decision. >> >>-g >> >> >>shu1@gmu.edu wrote: >> >>>What shoud the IKE do if the user configure SA life time ( >> >>say 5 days) is more than the certificate remaining time (say, >>the certifcate will be expired in 3 days)? Should we pick the >>minimum of {the SA life time the user configured, the >>certificate remaining time}, or should we abort IKE and send >>audit to the user? >> >>>I think this may be in RFC documnt or already discussed, >> >>but I couldn't find. Sorry if it's too trivial. >> >>> >>> >>> >>>_______________________________________________ >>>Ipsec mailing list >>>Ipsec@ietf.org >>>https://www1.ietf.org/mailman/listinfo/ipsec >> >>_______________________________________________ >>Ipsec mailing list >>Ipsec@ietf.org >>https://www1.ietf.org/mailman/listinfo/ipsec >> >> _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Mar 29 11:55:12 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00678 for ; Tue, 29 Mar 2005 11:55:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGJpW-0007Pi-P1; Tue, 29 Mar 2005 11:44:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGJpU-0007PK-PW for ipsec@megatron.ietf.org; Tue, 29 Mar 2005 11:44:36 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA27408 for ; Tue, 29 Mar 2005 11:44:33 -0500 (EST) Received: from [217.219.18.2] (helo=cc2.iut.ac.ir) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGJwC-0006Kr-Mo for ipsec@ietf.org; Tue, 29 Mar 2005 11:51:34 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by cc2.iut.ac.ir (Postfix) with ESMTP id EE39E6809F for ; Tue, 29 Mar 2005 20:29:04 +0430 (IRDT) Received: from cc2.iut.ac.ir ([127.0.0.1]) by localhost (cc2.iut.ac.ir [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 21624-03 for ; Tue, 29 Mar 2005 20:29:03 +0430 (IRDT) Received: from ec.iut.ac.ir (localhost.localdomain [127.0.0.1]) by cc2.iut.ac.ir (Postfix) with ESMTP id 77E1B6809B for ; Tue, 29 Mar 2005 20:29:03 +0430 (IRDT) From: "mahdavi" To: ipsec@ietf.org Date: Tue, 29 Mar 2005 19:29:03 +0330 Message-Id: <20050329155635.M39542@ec.iut.ac.ir> X-Mailer: Open WebMail 2.41 20041227 X-OriginatingIP: 217.219.18.67 (mahdavi@ec.iut.ac.ir) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Virus-Scanned: amavisd-new at cc2.iut.ac.ir X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Subject: [Ipsec] question about nested tunnelling and inbound X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi dear experts. (according to rfc2401 not rfc2401bis ) ( Rfc2401 part 5.2.1 "Do (1) and (2) for every IPsec header until a Transport Protocol Header or an IP header that is NOT for this system is encountered. Keep track of what SAs have been used and their order of application." ) ROUTER----- Security ---- Internet -- Security --- Host 2 | | Gwy 1 Gwy 2 | | | | | | ----Security Association 1 (tunnel)---- | | | ---------Security Association 2 (tunnel)------------- For Inbound process for above router, does above sentence means that we MUST check SPD for all tunnels at once (after all SA's applied for decapsulating) at the end of processing OR can we check SPD after decapsuling each tunnels ? regards mahdavi. <-:-> _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Mar 29 11:57:17 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01385 for ; Tue, 29 Mar 2005 11:57:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGJz0-00040E-K4; Tue, 29 Mar 2005 11:54:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGJyy-0003zQ-RZ for ipsec@megatron.ietf.org; Tue, 29 Mar 2005 11:54:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00496 for ; Tue, 29 Mar 2005 11:54:22 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGK5g-0007Ue-18 for ipsec@ietf.org; Tue, 29 Mar 2005 12:01:23 -0500 Received: from [128.33.244.153] (col-dhcp33-244-153.bbn.com [128.33.244.153]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j2TGs2vF013090; Tue, 29 Mar 2005 11:54:03 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <20050329155635.M39542@ec.iut.ac.ir> References: <20050329155635.M39542@ec.iut.ac.ir> Date: Tue, 29 Mar 2005 11:52:35 -0500 To: "mahdavi" From: Stephen Kent Subject: Re: [Ipsec] question about nested tunnelling and inbound Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 7:29 PM +0330 3/29/05, mahdavi wrote: >Hi dear experts. > >(according to rfc2401 not rfc2401bis ) ( Rfc2401 part 5.2.1 "Do (1) and (2) >for every IPsec header until a Transport Protocol Header or an IP header that >is NOT for this system is encountered. Keep track of what SAs have been used >and their order of application." ) > > > ROUTER----- Security ---- Internet -- Security --- Host 2 > | | Gwy 1 Gwy 2 | > | | | | > | ----Security Association 1 (tunnel)---- | > | | > ---------Security Association 2 (tunnel)------------- > >For Inbound process for above router, does above sentence means that we MUST >check SPD for all tunnels at once (after all SA's applied for decapsulating) >at the end of processing OR >can we check SPD after decapsuling each tunnels ? > > >regards >mahdavi. check each header against the SPD after each decapsulation is performed. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Mar 29 23:20:12 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06055 for ; Tue, 29 Mar 2005 23:20:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGUcT-0000zD-CS; Tue, 29 Mar 2005 23:15:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGUcR-0000z6-UG for ipsec@megatron.ietf.org; Tue, 29 Mar 2005 23:15:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05553 for ; Tue, 29 Mar 2005 23:15:49 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGUjG-0004i3-G0 for ipsec@ietf.org; Tue, 29 Mar 2005 23:22:55 -0500 Received: from [10.20.30.249] (dsl2-63-249-109-245.cruzio.com [63.249.109.245]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2U4FhcP013895; Tue, 29 Mar 2005 20:15:43 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 29 Mar 2005 20:15:39 -0800 To: IPsec WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: Pasi Eronen Subject: [Ipsec] IKEv2 clarifications document, -02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Greetings again. Pasi Eronen and I have published a new version of the IKEv2 clarifications document; you can find it at . We definitely would like comments on all the issues in the document. (Of course, if you are going to comment on a specific part, please do not reply to this message, but instead start a new thread.) Please note in specific section 7 which lists what Pasi and I think the status of each of the described issues are. Section 9 lists issues that aren't even covered in the document; we'll be starting threads here on those issues in the near term. We understand that some people do not want to comment on the list because they do not want to tell the world that they are implementing IKEv2 yet. This is not a WG document, so it is fine to send us off-list comments. Please let us know if you have any questions. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 30 11:20:39 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14553 for ; Wed, 30 Mar 2005 11:20:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGfpO-0006bd-Jn; Wed, 30 Mar 2005 11:13:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGfpM-0006bQ-MO for ipsec@megatron.ietf.org; Wed, 30 Mar 2005 11:13:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13897 for ; Wed, 30 Mar 2005 11:13:54 -0500 (EST) Received: from ns.ca.certicom.com ([66.48.18.197] helo=mail.ca.certicom.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DGfwJ-00048P-D9 for ipsec@ietf.org; Wed, 30 Mar 2005 11:21:07 -0500 Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 7892E100BA for ; Wed, 30 Mar 2005 11:13:47 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07796-100 for ; Wed, 30 Mar 2005 11:13:36 -0500 (EST) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id E5C8010091 for ; Wed, 30 Mar 2005 11:13:35 -0500 (EST) To: ipsec@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Tom Stiemerling Date: Wed, 30 Mar 2005 11:03:57 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 03/30/2005 11:03:59 AM, Serialize complete at 03/30/2005 11:03:59 AM X-Spam-Score: 0.5 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Subject: [Ipsec] ikev2 notify payloads 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="===============0148927073==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============0148927073== Content-Type: multipart/alternative; boundary="=_alternative 0059775785256FD4_=" This is a multipart message in MIME format. --=_alternative 0059775785256FD4_= Content-Type: text/plain; charset="US-ASCII" Good work on the clarifications draft, I am sure it will help. The draft spec and clarifications do mention where some of the notify payloads should go, but not all are covered. It would be useful if the clarifications document could give some hint about where all the informational/status notify payloads should go, ie. in which messages and where in the message (not all are obvious to me). Thanks, Tom --=_alternative 0059775785256FD4_= Content-Type: text/html; charset="US-ASCII"
Good work on the clarifications draft, I am sure it will help. The draft spec
and clarifications do mention where some of the notify payloads should go,
but not all are covered. It would be useful if the clarifications document could
give some hint about where all the informational/status notify payloads should
go, ie. in which messages and where in the message (not all are obvious to me).

Thanks, Tom --=_alternative 0059775785256FD4_=-- --===============0148927073== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0148927073==-- From ipsec-bounces@ietf.org Wed Mar 30 16:44:13 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29491 for ; Wed, 30 Mar 2005 16:44:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGkwO-0000Pj-Gf; Wed, 30 Mar 2005 16:41:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGkwM-0000P9-W5 for ipsec@megatron.ietf.org; Wed, 30 Mar 2005 16:41:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA29010 for ; Wed, 30 Mar 2005 16:41:28 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGl3L-0008Pe-3F for ipsec@ietf.org; Wed, 30 Mar 2005 16:48:44 -0500 Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2ULfMqk029798 for ; Wed, 30 Mar 2005 13:41:23 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 30 Mar 2005 13:41:21 -0800 To: IPsec WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Subject: [Ipsec] Revising RFC 3664 (AES-XCBC-PRF-128) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Greetings again. One of the issues in the IKEv2 clarifications shows that we cannot currently use AES-XCBC-PRF-128 in almost any circumstance, even though the WG decided it was a SHOULD+. This is due to the fact that the base spec for it requires that the keys be exactly 128 bits. That might make sense for a MAC, but not for a PRF: none of our other PRFs make this requirement. Thus, I'm proposing a short revision to AES-XCBC-PRF-128 (but not AES-XCBC-MAC-96). It actually causes no bits-on-the-wire differences from the current AES-XCBC-PRF-128; it just prevents rejection of many keys and tells how to handle those that would currently be rejected. Comments are welcome. >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > > Title : The AES-XCBC-PRF-128 Algorithm for the Internet Key > Exchange Protocol (IKE) > Author(s) : P. Hoffman > Filename : draft-hoffman-rfc3664bis-00.txt > Pages : 4 > Date : 2005-3-30 > >Some implementations of IP Security (IPsec) may want to use a > pseudo-random function derived from the Advanced Encryption Standard > (AES). This document describes such an algorithm, called AES-XCBC- > PRF-128. > >A URL for this Internet-Draft is: >http://www.ietf.org/internet-drafts/draft-hoffman-rfc3664bis-00.txt --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Mar 30 23:36:50 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA06097 for ; Wed, 30 Mar 2005 23:36:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGrNK-0007gR-OB; Wed, 30 Mar 2005 23:33:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DGrNC-0007gM-BG for ipsec@megatron.ietf.org; Wed, 30 Mar 2005 23:33:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA05664 for ; Wed, 30 Mar 2005 23:33:35 -0500 (EST) Received: from inet-tsb5.toshiba.co.jp ([202.33.96.24]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DGrU8-0008Um-RF for ipsec@ietf.org; Wed, 30 Mar 2005 23:40:55 -0500 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb5.toshiba.co.jp with ESMTP id j2V4WtOD028309; Thu, 31 Mar 2005 13:32:55 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id j2V4WtQX012898; Thu, 31 Mar 2005 13:32:55 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id PAA12891 ; Thu, 31 Mar 2005 13:32:55 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id j2V4WsPX005254; Thu, 31 Mar 2005 13:32:54 +0900 (JST) Received: by toshiba.co.jp id j2V4WpnA002122; Thu, 31 Mar 2005 13:32:51 +0900 (JST) Message-Id: <200503310432.j2V4WpnA002122@toshiba.co.jp> To: Paul Hoffman Subject: Re: [Ipsec] Revising RFC 3664 (AES-XCBC-PRF-128) In-reply-to: paul.hoffman's message of "Wed, 30 Mar 2005 13:41:21 PST." Date: Thu, 31 Mar 2005 13:32:50 +0900 From: Fukumoto Atsushi X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: IPsec WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org draft-hoffman-rfc3664bis-00.txt states: o The key length restriction of exactly 128 bits in [AES-XCBC-MAC] is changed. The key for the AES-XCBC-PRF-128 algorithm is created using the formula in [HMAC-definition]. This brings AES-XCBC-PRF-128 in alignment with HMAC-SHA1 and HMAC-MD5 when used as PRFs in IKE. I didn't understand which formula in [HMAC-definition] (RFC2104) this is refering to. RFC2104 states: The authentication key K can be of any length up to B, the block length of the hash function. Applications that use keys longer than B bytes will first hash the key using H and then use the resultant L byte string as the actual key to HMAC. But this assumes H to accept an arbitrary length of octets as its only input. What is the H for the case of AES-XCBC-PRF-128? FUKUMOTO Atsushi atsushi.fukumoto@toshiba.co.jp _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Mar 31 12:27:43 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14038 for ; Thu, 31 Mar 2005 12:27:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH3Mf-0000bn-Rl; Thu, 31 Mar 2005 12:21:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DH3Md-0000bh-Uc for ipsec@megatron.ietf.org; Thu, 31 Mar 2005 12:21:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13643 for ; Thu, 31 Mar 2005 12:21:49 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DH3Tm-0007F0-Jb for ipsec@ietf.org; Thu, 31 Mar 2005 12:29:15 -0500 Received: from [10.20.30.249] (dsl2-63-249-109-245.cruzio.com [63.249.109.245]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j2VHLkf0055930 for ; Thu, 31 Mar 2005 09:21:48 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 31 Mar 2005 09:21:43 -0800 To: IPsec WG From: The IESG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Ipsec] Last Call: 'The Camellia Cipher Algorithm and Its Use With IPsec' to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org The IESG has received a request from an individual submitter to consider the following document: - 'The Camellia Cipher Algorithm and Its Use With IPsec ' 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 2005-04-28. The file can be obtained via http://www.ietf.org/internet-drafts/draft-kato-ipsec-ciph-camellia-01.txt _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec