From ipsec-bounces@ietf.org Tue Jul 12 00:32:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsCRU-0000WN-WE; Tue, 12 Jul 2005 00:32:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsCRS-0000U9-AO for ipsec@megatron.ietf.org; Tue, 12 Jul 2005 00:32:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24550 for ; Tue, 12 Jul 2005 00:32:19 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsCta-0001cQ-Fq for ipsec@ietf.org; Tue, 12 Jul 2005 01:01:27 -0400 Received: from crowley.qualcomm.com (crowley.qualcomm.com [129.46.61.151]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6C4W42m015047 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 11 Jul 2005 21:32:05 -0700 (PDT) Received: from NAEXBR03.na.qualcomm.com (naexbr03.qualcomm.com [129.46.134.172]) by crowley.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6C4W2Rp024316 for ; Mon, 11 Jul 2005 21:32:02 -0700 (PDT) Received: from NAEX06.na.qualcomm.com ([129.46.135.161]) by NAEXBR03.na.qualcomm.com with Microsoft SMTPSVC(6.0.3790.211); Mon, 11 Jul 2005 21:32:02 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Mon, 11 Jul 2005 21:30:59 -0700 Message-ID: Thread-Topic: Need clarification on IKEv2 CP vs. MIPv4 IP address assignment Thread-Index: AcWGmoDNlC+nApJBTAKduz+Ly4kYcg== From: "Dondeti, Lakshminath" To: X-OriginalArrivalTime: 12 Jul 2005 04:32:02.0393 (UTC) FILETIME=[A65A0490:01C5869A] X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Cc: Subject: [Ipsec] Need clarification on IKEv2 CP vs. MIPv4 IP address assignment X-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="===============0657038555==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0657038555== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5869A.A56D9D10" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5869A.A56D9D10 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I was told that this issue came up in a 3GPP2-WLAN Interworking = discussion and is related to a conflict between IKEv2-CP address = assignment vs. MIPv4 IP address assignment. The IKEv2 spec seems to say = different things at different places, so a clarification might help = (perhaps in the ikev2-clarifications I-D). Some details below: In interpreting the CP requirements, the following = two excerpts from IKEv2 seem to take differing precedence for different = people. Section 2.19, Page 34 of ikev2-17 says: "CP(CFG_REQUEST) MUST contain at = least an INTERNAL_ADDRESS attribute (either IPv4 or IPv6) but MAY = contain any number of additional attributes the initiator wants returned = in the response." Section 4, Page 85 says: "Implementations are not required to support requesting temporary IP = addresses or responding to such requests. If an implementation does = support issuing such requests, it MUST include a CP payload in message 3 = containing at least a field of type INTERNAL_IP4_ADDRESS or = INTERNAL_IP6_ADDRESS. All other fields are optional. If an = implementation supports responding to such requests, it MUST parse the = CP payload of type CFG_REQUEST in message 3 and recognize a field of = type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports = leasing an address of the appropriate type, it MUST return a CP payload = of type CFG_REPLY containing an address of the requested type. The = responder SHOULD include all of the other related attributes if it has = them." In case of MIPv4, if a VPN gateway is also a FA, assuming all address = assignment is taken care of within MIPv4, can other protocol = specifications (e.g., 3GPP2 specs) using IKEv2 assume that compliant = implementations do not have to support CP-based address assignment? I am also concerned about a RAS sending a FAILED_CP_REQUIRED to a client = that wants to use MIPv4 based address assignment and not the CP-based = address assignment. Thoughts and comments welcome. Thanks in advance. best regards, Lakshminath ------_=_NextPart_001_01C5869A.A56D9D10 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Need clarification on IKEv2 CP vs. MIPv4 IP address = assignment

Hi,

I was told that this issue came up in a 3GPP2-WLAN Interworking = discussion and is related to a conflict between IKEv2-CP address = assignment vs. MIPv4 IP address assignment.  The IKEv2 spec seems = to say different things at different places, so a clarification might = help (perhaps in the ikev2-clarifications I-D).

Some details below:  In interpreting the CP requirements, the = following two excerpts from IKEv2 seem to take differing precedence for = different people.

Section 2.19, Page 34 of ikev2-17 says: "CP(CFG_REQUEST) MUST = contain at least an INTERNAL_ADDRESS attribute (either IPv4 or IPv6) but = MAY contain any number of additional attributes the initiator wants = returned in the response."

Section 4, Page 85 says:

"Implementations are not required to support requesting temporary = IP addresses or responding to such requests. If an implementation does = support issuing such requests, it MUST include a CP payload in message 3 = containing at least a field of type INTERNAL_IP4_ADDRESS or = INTERNAL_IP6_ADDRESS. All other fields are optional. If an = implementation supports responding to such requests, it MUST parse the = CP payload of type CFG_REQUEST in message 3 and recognize a field of = type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports = leasing an address of the appropriate type, it MUST return a CP payload = of type CFG_REPLY containing an address of the requested type. The = responder SHOULD include all of the other related attributes if it has = them."

In case of MIPv4, if a VPN gateway is also a FA, assuming all address = assignment is taken care of within MIPv4, can other protocol = specifications (e.g., 3GPP2 specs) using IKEv2 assume that compliant = implementations do not have to support CP-based address assignment?

I am also concerned about a RAS sending a FAILED_CP_REQUIRED to a client = that wants to use MIPv4 based address assignment and not the CP-based = address assignment.

Thoughts and comments welcome.  Thanks in advance.

best regards,
Lakshminath

------_=_NextPart_001_01C5869A.A56D9D10-- --===============0657038555== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0657038555==-- From ipsec-bounces@ietf.org Tue Jul 12 04:02:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsFii-0007qN-SX; Tue, 12 Jul 2005 04:02:24 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsFig-0007qI-A7 for ipsec@megatron.ietf.org; Tue, 12 Jul 2005 04:02:22 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28997 for ; Tue, 12 Jul 2005 04:02:20 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsGAp-0000MO-El for ipsec@ietf.org; Tue, 12 Jul 2005 04:31:28 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6C7wwov003936; Tue, 12 Jul 2005 10:58:59 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jul 2005 11:02:13 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jul 2005 11:02:13 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Need clarification on IKEv2 CP vs. MIPv4 IP addressassignment Date: Tue, 12 Jul 2005 11:02:13 +0300 Message-ID: Thread-Topic: Need clarification on IKEv2 CP vs. MIPv4 IP address assignment Thread-Index: AcWGmoDNlC+nApJBTAKduz+Ly4kYcgAGqaDg To: , X-OriginalArrivalTime: 12 Jul 2005 08:02:13.0587 (UTC) FILETIME=[03358230:01C586B8] X-Spam-Score: 0.3 (/) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, I don't see any conflict between the two excerpts...? It says that supporting CPs is not required (this kind of implementation never sends any CPs and silently ignores any=20 CPs it receives). The requirement "CP(CFG_REQUEST) MUST contain=20 at least an..." applies only to implementations that send CP(CFG_REQUEST)s. About FAILED_CP_REQUIRED: the responder sends this only when its local policy says so, so presumably 3GPP2 can say that "3GPP2-WLAN interworking gateways must not use a policy that causes this error to be sent" (or something like that). (BTW, if you're doing address assignment outside IKEv2 but inside the IPsec tunnel created by IKEv2, that's going to be a bit complicated. You first need to create IPsec SAs with traffic selectors matching the address assignment packets, then do the address assignment, and only after that create additional IPsec=20 SAs with traffic selectors containing the newly assigned address.=20 Something like RFC 3456 probably.) Best regards, Pasi > -----Original Message----- > From: Dondeti, Lakshminath > Sent: Tuesday, July 12, 2005 7:31 AM > To: ipsec@ietf.org > Subject: [Ipsec] Need clarification on IKEv2 CP vs. MIPv4 IP=20 > addressassignment >=20 > Hi, > > I was told that this issue came up in a 3GPP2-WLAN > Interworking discussion and is related to a conflict between > IKEv2-CP address assignment vs. MIPv4 IP address assignment. > The IKEv2 spec seems to say different things at different > places, so a clarification might help (perhaps in the > ikev2-clarifications I-D). > Some details below: In interpreting the CP requirements, the > following two excerpts from IKEv2 seem to take differing > precedence for different people. > > Section 2.19, Page 34 of ikev2-17 says: "CP(CFG_REQUEST) MUST > contain at least an INTERNAL_ADDRESS attribute (either IPv4 or > IPv6) but MAY contain any number of additional attributes the > initiator wants returned in the response." > > Section 4, Page 85 says: > > "Implementations are not required to support requesting > temporary IP addresses or responding to such requests. If an > implementation does support issuing such requests, it MUST > include a CP payload in message 3 containing at least a field > of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. All > other fields are optional. If an implementation supports > responding to such requests, it MUST parse the CP payload of > type CFG_REQUEST in message 3 and recognize a field of type > INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports > leasing an address of the appropriate type, it MUST return a > CP payload of type CFG_REPLY containing an address of the > requested type. The responder SHOULD include all of the other > related attributes if it has them." > > In case of MIPv4, if a VPN gateway is also a FA, assuming all > address assignment is taken care of within MIPv4, can other > protocol specifications (e.g., 3GPP2 specs) using IKEv2 assume > that compliant implementations do not have to support CP-based > address assignment? > > I am also concerned about a RAS sending a FAILED_CP_REQUIRED > to a client that wants to use MIPv4 based address assignment > and not the CP-based address assignment. > > Thoughts and comments welcome. Thanks in advance. > > best regards, > Lakshminath _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jul 12 07:35:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsJ37-0006Mk-FE; Tue, 12 Jul 2005 07:35:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsJ35-0006Mf-VW for ipsec@megatron.ietf.org; Tue, 12 Jul 2005 07:35:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12352 for ; Tue, 12 Jul 2005 07:35:39 -0400 (EDT) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsJVE-0008K1-Pc for ipsec@ietf.org; Tue, 12 Jul 2005 08:04:48 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id j6CBZHnP027951 for ; Tue, 12 Jul 2005 14:35:18 +0300 (IDT) Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <200506280548.j5S5m1ib019961@rs15.luxsci.com> References: <200506280548.j5S5m1ib019961@rs15.luxsci.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Yoav Nir Date: Tue, 12 Jul 2005 14:35:17 +0300 To: "'IPsec WG'" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Content-Transfer-Encoding: 7bit Subject: [Ipsec] Question regarding IKE SA validity X-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. Section 1.2 of draft -17 says on page 8, "At this point in the negotiation ... all but the headers of all the messages that follow are encrypted and integrity protected." This is right after the IKE_SA_INIT exchange, but before the IKE_AUTH exchange. Suppose at this point, the initiator needed to send an INFORMATIONAL exchange. Would it be appropriate to use the encryption keys, or is this prohibited until the IKE_AUTH exchange completes successfully? IOW, when section 1.4 says "INFORMATIONAL exchange MUST ONLY occur after the initial exchanges" what do they mean by "initial exchanges"? Is it only the IKE_SA_INIT, or the combination of IKE_SA_INIT and IKE_AUTH? Thanks. Yoav _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jul 12 07:51:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsJIq-0002ld-Cn; Tue, 12 Jul 2005 07:51:56 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsJIo-0002lY-NY for ipsec@megatron.ietf.org; Tue, 12 Jul 2005 07:51:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13362 for ; Tue, 12 Jul 2005 07:51:54 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsJkz-0000Nw-IS for ipsec@ietf.org; Tue, 12 Jul 2005 08:21:03 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6CBmKFZ010184; Tue, 12 Jul 2005 14:48:22 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jul 2005 14:51:34 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 12 Jul 2005 14:51:34 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Question regarding IKE SA validity Date: Tue, 12 Jul 2005 14:51:34 +0300 Message-ID: Thread-Topic: [Ipsec] Question regarding IKE SA validity Thread-Index: AcWG1xjOiQBY3bd6QP+cXjBf5I1qEgAADEFA To: , X-OriginalArrivalTime: 12 Jul 2005 11:51:34.0373 (UTC) FILETIME=[0D46D150:01C586D8] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Yoav, The "initial exchanges" include both IKE_SA_INIT and IKE_AUTH=20 (Section 1.2 describing them is even titled "the initial exchanges"). BTW, why would an initiator want to send an INFORMATIONAL message=20 at this point? Probably it's some kind of error message (since=20 the message would be unauthenticated anyway), but none of the notifications in Section 3.10.1 seem appropriate at this step... Best regards, Pasi > -----Original Message----- > From: Yoav Nir > Sent: Tuesday, July 12, 2005 2:35 PM > To: 'IPsec WG' > Subject: [Ipsec] Question regarding IKE SA validity >=20 >=20 > Hi. >=20 > Section 1.2 of draft -17 says on page 8, "At this point in the > negotiation ... all but the headers of all the messages that follow > are encrypted and integrity protected." This is right after the > IKE_SA_INIT exchange, but before the IKE_AUTH exchange. >=20 > Suppose at this point, the initiator needed to send an INFORMATIONAL > exchange. Would it be appropriate to use the encryption keys, or is > this prohibited until the IKE_AUTH exchange completes successfully? > IOW, when section 1.4 says "INFORMATIONAL exchange MUST ONLY occur > after the initial exchanges" what do they mean by "initial > exchanges"? Is it only the IKE_SA_INIT, or the combination of > IKE_SA_INIT and IKE_AUTH? >=20 > Thanks. >=20 > Yoav _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jul 12 08:15:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsJfN-0002mP-Az; Tue, 12 Jul 2005 08:15:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsJfL-0002mJ-PU for ipsec@megatron.ietf.org; Tue, 12 Jul 2005 08:15:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA15576 for ; Tue, 12 Jul 2005 08:15:10 -0400 (EDT) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsK7X-0001N4-4g for ipsec@ietf.org; Tue, 12 Jul 2005 08:44:20 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id j6CCF0nP011741; Tue, 12 Jul 2005 15:15:00 +0300 (IDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] Question regarding IKE SA validity Date: Tue, 12 Jul 2005 15:14:59 +0300 To: X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Thanks. The reason I asked was that I wasn't sure whether it was OK to move D-H derivation to the beginning of the IKE_AUTH exchange. This can reduce the load incurred by the responder if the initiator is trying to mount a DoS attack by sending single packets. It also follows the general principle of not computing it until you need it. If there's no possibility of anyone using the half-open IKE SA before the IKE_AUTH is done, then the derivation can be safely moved. Thanks again. Yoav On Jul 12, 2005, at 2:51 PM, wrote: > > Hi Yoav, > > The "initial exchanges" include both IKE_SA_INIT and IKE_AUTH > (Section 1.2 describing them is even titled "the initial exchanges"). > > BTW, why would an initiator want to send an INFORMATIONAL message > at this point? Probably it's some kind of error message (since > the message would be unauthenticated anyway), but none of the > notifications in Section 3.10.1 seem appropriate at this step... > > Best regards, > Pasi > >> -----Original Message----- >> From: Yoav Nir >> Sent: Tuesday, July 12, 2005 2:35 PM >> To: 'IPsec WG' >> Subject: [Ipsec] Question regarding IKE SA validity >> >> >> Hi. >> >> Section 1.2 of draft -17 says on page 8, "At this point in the >> negotiation ... all but the headers of all the messages that follow >> are encrypted and integrity protected." This is right after the >> IKE_SA_INIT exchange, but before the IKE_AUTH exchange. >> >> Suppose at this point, the initiator needed to send an INFORMATIONAL >> exchange. Would it be appropriate to use the encryption keys, or is >> this prohibited until the IKE_AUTH exchange completes successfully? >> IOW, when section 1.4 says "INFORMATIONAL exchange MUST ONLY occur >> after the initial exchanges" what do they mean by "initial >> exchanges"? Is it only the IKE_SA_INIT, or the combination of >> IKE_SA_INIT and IKE_AUTH? >> >> Thanks. >> >> Yoav _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jul 12 12:36:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsNk7-0006aD-1x; Tue, 12 Jul 2005 12:36:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DsNk4-0006a5-Hf for ipsec@megatron.ietf.org; Tue, 12 Jul 2005 12:36:20 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14157 for ; Tue, 12 Jul 2005 12:36:18 -0400 (EDT) Received: from numenor.qualcomm.com ([129.46.51.58]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DsOCI-0005eI-39 for ipsec@ietf.org; Tue, 12 Jul 2005 13:05:31 -0400 Received: from magus.qualcomm.com (magus.qualcomm.com [129.46.61.148]) by numenor.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6CGa22m015430 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 12 Jul 2005 09:36:02 -0700 (PDT) Received: from [10.4.42.144] (ldondeti.qualcomm.com [10.4.42.144]) by magus.qualcomm.com (8.12.10/8.12.5/1.0) with ESMTP id j6CGZs50027887 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 12 Jul 2005 09:35:55 -0700 (PDT) Message-ID: <42D3F169.2020009@qualcomm.com> Date: Tue, 12 Jul 2005 12:35:53 -0400 From: Lakshminath Dondeti Organization: Qualcomm User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com Subject: Re: [Ipsec] Need clarification on IKEv2 CP vs. MIPv4 IP addressassignment 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: 944ecb6e61f753561f559a497458fb4f Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ldondeti@qualcomm.com List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Pasi, Thanks. The conflict is a bit subtle in that one could use one of the following excerpts from ikev2-17 to claim that if there is address assignment it MUST be done using CP and the other to say that CP is optional, period. The FAILED_CP_REQUIRED is also an area of concern if an implementation is not MIPv4 address assignment sensitive. I am still exploring this topic and your thoughts are quite helpful! best regards, Lakshminath Pasi.Eronen@nokia.com wrote: >Hi, > >I don't see any conflict between the two excerpts...? > >It says that supporting CPs is not required (this kind of >implementation never sends any CPs and silently ignores any >CPs it receives). The requirement "CP(CFG_REQUEST) MUST contain >at least an..." applies only to implementations that send >CP(CFG_REQUEST)s. > >About FAILED_CP_REQUIRED: the responder sends this only >when its local policy says so, so presumably 3GPP2 can >say that "3GPP2-WLAN interworking gateways must not use >a policy that causes this error to be sent" (or something >like that). > >(BTW, if you're doing address assignment outside IKEv2 but >inside the IPsec tunnel created by IKEv2, that's going to be a >bit complicated. You first need to create IPsec SAs with traffic >selectors matching the address assignment packets, then do the >address assignment, and only after that create additional IPsec >SAs with traffic selectors containing the newly assigned address. >Something like RFC 3456 probably.) > >Best regards, >Pasi > > > >>-----Original Message----- >>From: Dondeti, Lakshminath >>Sent: Tuesday, July 12, 2005 7:31 AM >>To: ipsec@ietf.org >>Subject: [Ipsec] Need clarification on IKEv2 CP vs. MIPv4 IP >> addressassignment >> >>Hi, >> >>I was told that this issue came up in a 3GPP2-WLAN >>Interworking discussion and is related to a conflict between >>IKEv2-CP address assignment vs. MIPv4 IP address assignment. >>The IKEv2 spec seems to say different things at different >>places, so a clarification might help (perhaps in the >>ikev2-clarifications I-D). >> >> > > > >>Some details below: In interpreting the CP requirements, the >>following two excerpts from IKEv2 seem to take differing >>precedence for different people. >> >>Section 2.19, Page 34 of ikev2-17 says: "CP(CFG_REQUEST) MUST >>contain at least an INTERNAL_ADDRESS attribute (either IPv4 or >>IPv6) but MAY contain any number of additional attributes the >>initiator wants returned in the response." >> >>Section 4, Page 85 says: >> >>"Implementations are not required to support requesting >>temporary IP addresses or responding to such requests. If an >>implementation does support issuing such requests, it MUST >>include a CP payload in message 3 containing at least a field >>of type INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. All >>other fields are optional. If an implementation supports >>responding to such requests, it MUST parse the CP payload of >>type CFG_REQUEST in message 3 and recognize a field of type >>INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS. If it supports >>leasing an address of the appropriate type, it MUST return a >>CP payload of type CFG_REPLY containing an address of the >>requested type. The responder SHOULD include all of the other >>related attributes if it has them." >> >>In case of MIPv4, if a VPN gateway is also a FA, assuming all >>address assignment is taken care of within MIPv4, can other >>protocol specifications (e.g., 3GPP2 specs) using IKEv2 assume >>that compliant implementations do not have to support CP-based >>address assignment? >> >>I am also concerned about a RAS sending a FAILED_CP_REQUIRED >>to a client that wants to use MIPv4 based address assignment >>and not the CP-based address assignment. >> >>Thoughts and comments welcome. Thanks in advance. >> >>best regards, >>Lakshminath >> >> > > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Jul 17 19:27:30 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuIXi-0008Ho-Hc; Sun, 17 Jul 2005 19:27:30 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuIXg-0008Hg-F0 for ipsec@megatron.ietf.org; Sun, 17 Jul 2005 19:27:28 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04358 for ; Sun, 17 Jul 2005 19:27:25 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuJ0z-0006kI-0x for ipsec@ietf.org; Sun, 17 Jul 2005 19:57:46 -0400 Received: from [10.20.30.249] ([63.125.5.203]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j6HNRJ5c051929 for ; Sun, 17 Jul 2005 16:27:19 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Sun, 17 Jul 2005 16:27:21 -0700 To: IPsec WG From: Internet-Drafts@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.3 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [Ipsec] I-D ACTION:draft-eronen-ipsec-ikev2-clarifications-04.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 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IKEv2 Clarifications and Implementation Guidelines Author(s) : P. Hoffman, P. Eronen Filename : draft-eronen-ipsec-ikev2-clarifications-04.txt Pages : 45 Date : 2005-7-15 This document clarifies many areas of the IKEv2 specification. It does not to introduce any changes to the protocol, but rather provides descriptions that are less prone to ambiguous interpretations. The purpose of this document is to encourage the development of interoperable implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-eronen-ipsec-ikev2-clarifications-04.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-eronen-ipsec-ikev2-clarifications-04.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-eronen-ipsec-ikev2-clarifications-04.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. [The following attachment must be fetched by mail. Command-click the URL below and send the resulting message to get the attachment.] [The following attachment must be fetched by ftp. Command-click the URL below to ask your ftp client to fetch it.] _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 18 03:52:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuQQr-0004k5-3J; Mon, 18 Jul 2005 03:52:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuQQp-0004k0-HZ for ipsec@megatron.ietf.org; Mon, 18 Jul 2005 03:52:55 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18157 for ; Mon, 18 Jul 2005 03:52:54 -0400 (EDT) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DuQuC-0002e0-DV for ipsec@ietf.org; Mon, 18 Jul 2005 04:23:17 -0400 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.4/8.13.4/Debian-3) with ESMTP id j6I7qh1B014599 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 18 Jul 2005 10:52:43 +0300 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.4/8.13.4/Submit) id j6I7qh69014596; Mon, 18 Jul 2005 10:52:43 +0300 Date: Mon, 18 Jul 2005 10:52:43 +0300 Message-Id: <200507180752.j6I7qh69014596@burp.tkv.asdf.org> From: Markku Savela To: ipsec@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Subject: [Ipsec] Multicast SA and local/remote transport selector X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I've some conceptual difficulties how to deal with SA's for multicast traffic. Say, I want to specify a policy for specific port of multicast traffic, and would write a policy remote port = X, remote addr = somemulticast -> IPSEC-actions. As far as I understand, this would result an SA with similar traffic selector, specifying values for remote parameters. Now, if the host is also receiving the same multicast traffic, I would have to speficy another policy line with local port = X, local addr = somemulticast -> actions and would end up with another SA for the same group with different traffic selectors (local this time). How is the multicast key management/negotiation going to address this issue? In "old times", when my "traffic selectors" in SA were src/dst based, such multicast SA was not a problem, as it just had dst port = X, dst addr = somemulticast and it works fine for both outgoing and incoming traffic. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 18 09:08:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuVMW-0006GG-Eb; Mon, 18 Jul 2005 09:08:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuVMR-0006Dx-EI for ipsec@megatron.ietf.org; Mon, 18 Jul 2005 09:08:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA08933 for ; Mon, 18 Jul 2005 09:08:42 -0400 (EDT) Received: from smtp-out1.oct.nac.net ([209.123.233.211]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DuVpp-0007d2-7b for ipsec@ietf.org; Mon, 18 Jul 2005 09:39:08 -0400 Received: (qmail 84201 invoked from network); 18 Jul 2005 13:08:30 -0000 Received: from unknown (HELO mail1.oct.nac.net) (209.123.233.241) by smtp-out1.oct.nac.net with SMTP; 18 Jul 2005 13:08:30 -0000 Received: (qmail 11624 invoked from network); 18 Jul 2005 09:08:29 -0400 Received: from unknown (HELO nsx.garage) (gmgross@66.246.164.6) by mail1.oct.nac.net with SMTP; 18 Jul 2005 09:08:29 -0400 Received: (from gmg@localhost) by nsx.garage (8.11.2/8.11.2) id j6I9pqJ19362; Mon, 18 Jul 2005 05:51:52 -0400 Date: Mon, 18 Jul 2005 05:51:52 -0400 (EDT) From: George Gross To: Markku Savela Subject: Re: [Ipsec] Multicast SA and local/remote transport selector In-Reply-To: <200507180752.j6I7qh69014596@burp.tkv.asdf.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.7 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Markku, your question is very timely ;o) I'd suggestion you take a look at the recently published draft-ietf-msec-ipsec-extensions-00.txt. This draft is an MSEC working group item, and its intent is to address questions such as you mention below. The v00 version is abit rushed and immature, so I would anticipate lots of room for improvement based on review and comment. hth, George On Mon, 18 Jul 2005, Markku Savela wrote: > I've some conceptual difficulties how to deal with SA's for multicast > traffic. Say, I want to specify a policy for specific port of > multicast traffic, and would write a policy > > remote port = X, remote addr = somemulticast -> IPSEC-actions. > > As far as I understand, this would result an SA with similar traffic > selector, specifying values for remote parameters. > > Now, if the host is also receiving the same multicast traffic, I would > have to speficy another policy line with > > local port = X, local addr = somemulticast -> actions > > and would end up with another SA for the same group with different > traffic selectors (local this time). > > How is the multicast key management/negotiation going to address this > issue? > > In "old times", when my "traffic selectors" in SA were src/dst based, > such multicast SA was not a problem, as it just had > > dst port = X, dst addr = somemulticast > > and it works fine for both outgoing and incoming traffic. > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 18 09:58:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuW8s-0001Hv-UZ; Mon, 18 Jul 2005 09:58:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DuW8q-0001Hq-Af for ipsec@megatron.ietf.org; Mon, 18 Jul 2005 09:58:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA12039 for ; Mon, 18 Jul 2005 09:58:42 -0400 (EDT) Received: from usrwebshield.usr.com ([65.195.130.75]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DuWcG-0002OS-Kd for ipsec@ietf.org; Mon, 18 Jul 2005 10:29:09 -0400 Received: from (172.20.67.50) by usrwebshield.usr.com via smtp id 11ef_ce477100_f796_11d9_95f5_0030482a81b7; Mon, 18 Jul 2005 09:18:29 -0500 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Mon, 18 Jul 2005 08:59:14 -0500 Message-ID: <8927EC964E978243B2B27B49832C0CB2AC2784@usrs111.usr.com> Thread-Topic: Ipsec dynamic DNS and peer reset Thread-Index: AcWLmf505TAkuAxgRYezeGaj8FemZAABqtuQ From: "Batta, Anurag" To: X-NAIMIME-Disclaimer: 1 X-NAIMIME-Modified: 1 X-Spam-Score: 0.2 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] Ipsec dynamic DNS and peer reset X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org What should happen if Ipsec peers are dynamically assigned IP addresses and one of the peers go down and comes up with a different IP. In the configuration, DNS names are configured rather than ip address. Thanks. This e-mail may contain confidential or privileged information. If you t= hink you have received this e-mail in error, please advise the sender by = reply e-mail and then delete this e-mail immediately.=0D =0D Thank you. U. S. Robotics _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 18 16:20:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duc60-00049f-58; Mon, 18 Jul 2005 16:20:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Duc5y-00048O-1G for ipsec@megatron.ietf.org; Mon, 18 Jul 2005 16:20:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA19342 for ; Mon, 18 Jul 2005 16:20:07 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DucZN-0001aU-3Z for ipsec@ietf.org; Mon, 18 Jul 2005 16:50:36 -0400 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j6IKJq2o013779; Mon, 18 Jul 2005 16:19:52 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <8927EC964E978243B2B27B49832C0CB2AC2784@usrs111.usr.com> References: <8927EC964E978243B2B27B49832C0CB2AC2784@usrs111.usr.com> Date: Mon, 18 Jul 2005 16:07:18 -0400 To: "Batta, Anurag" From: Stephen Kent Subject: Re: [Ipsec] Ipsec dynamic DNS and peer reset 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: de4f315c9369b71d7dd5909b42224370 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 8:59 AM -0500 7/18/05, Batta, Anurag wrote: >What should happen if Ipsec peers are dynamically assigned IP addresses >and one of the peers go down and comes up with a different IP. In the >configuration, DNS names are configured rather than ip address. > >Thanks. If the IPsec implementation was part of the system that crashed, then the SA state would be lost anyway and that would require re-creation of previously extant SAs, e.g., to put new keys in place. If the SPD entry that authorized creation of the SA was name-based, not address based, as I think you suggest above, then traffic from the peer whose address changed will trigger creation of a new SA to replace the old one that was rendered unusable by the address change. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jul 20 08:53:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvE4j-00018P-Ks; Wed, 20 Jul 2005 08:53:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvE4g-00013Z-Sr for ipsec@megatron.ietf.org; Wed, 20 Jul 2005 08:53:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12188 for ; Wed, 20 Jul 2005 08:53:21 -0400 (EDT) Received: from iluvatar.zemris.fer.hr ([161.53.65.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvEYV-0008BE-Hj for ipsec@ietf.org; Wed, 20 Jul 2005 09:24:12 -0400 Received: from localhost (iluvatar [127.0.0.1]) by iluvatar.zemris.fer.hr (Postfix) with ESMTP id 6A9F713C00C; Wed, 20 Jul 2005 14:34:30 +0200 (CEST) Received: from iluvatar.zemris.fer.hr ([127.0.0.1]) by localhost (iluvatar.zemris.fer.hr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 30129-09; Wed, 20 Jul 2005 14:34:26 +0200 (CEST) Received: from Anardil.ZEMRIS.FER.HR (Anardil.ZEMRIS.FER.HR [161.53.65.229]) by iluvatar.zemris.fer.hr (Postfix) with ESMTP id EBAA013C00B; Wed, 20 Jul 2005 14:34:25 +0200 (CEST) From: Stjepan Gros To: ipsec@ietf.org, ipsec-tools-devel@lists.sourceforge.net Content-Type: text/plain Date: Wed, 20 Jul 2005 14:52:50 +0200 Message-Id: <1121863970.14710.13.camel@anardil.zemris.fer.hr> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at zemris.fer.hr X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: Subject: [Ipsec] IKEv2 implementation announce... X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi All, i would like to announce a project that has goal of developing open source implementation of IKEv2 protocol. We already have some alpha quality code (uncomplete). Snapshot of that code is released on sourceforge at the following url: http://sourceforge.net/projects/ikev2 Sourceforge is also a primary place for discussions and development. We welcome all the suggestions, critics, reviews, etc. Best regards, Stjepan Gros _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jul 20 10:00:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvF7M-0001tb-DD; Wed, 20 Jul 2005 10:00:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvF7L-0001tV-1x for ipsec@megatron.ietf.org; Wed, 20 Jul 2005 10:00:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA17013 for ; Wed, 20 Jul 2005 10:00:08 -0400 (EDT) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvFb9-00045R-KZ for ipsec@ietf.org; Wed, 20 Jul 2005 10:31:01 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id j6KDxnnP021726; Wed, 20 Jul 2005 16:59:49 +0300 (IDT) In-Reply-To: <1121863970.14710.13.camel@anardil.zemris.fer.hr> References: <1121863970.14710.13.camel@anardil.zemris.fer.hr> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <8fdd02670673df177eda5c162fc468fd@checkpoint.com> Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] IKEv2 implementation announce... Date: Wed, 20 Jul 2005 16:59:48 +0300 To: Stjepan Gros X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, ipsec-tools-devel@lists.sourceforge.net X-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 Cool! Isn't racoon2 from the KAME project also an open source project? On Jul 20, 2005, at 3:52 PM, Stjepan Gros wrote: > Hi All, > > i would like to announce a project that has goal of developing open > source implementation of IKEv2 protocol. We already have some alpha > quality code (uncomplete). Snapshot of that code is released on > sourceforge at the following url: > > http://sourceforge.net/projects/ikev2 > > Sourceforge is also a primary place for discussions and development. We > welcome all the suggestions, critics, reviews, etc. > > Best regards, > Stjepan Gros > > > _______________________________________________ > 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 Jul 20 10:30:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvFaN-0003pv-Hw; Wed, 20 Jul 2005 10:30:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvFaL-0003kc-FA for ipsec@megatron.ietf.org; Wed, 20 Jul 2005 10:30:09 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21333 for ; Wed, 20 Jul 2005 10:30:07 -0400 (EDT) Received: from iluvatar.zemris.fer.hr ([161.53.65.13]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvG4A-0006Oa-4V for ipsec@ietf.org; Wed, 20 Jul 2005 11:01:00 -0400 Received: from localhost (iluvatar [127.0.0.1]) by iluvatar.zemris.fer.hr (Postfix) with ESMTP id 299AC13C00C; Wed, 20 Jul 2005 16:11:19 +0200 (CEST) Received: from iluvatar.zemris.fer.hr ([127.0.0.1]) by localhost (iluvatar.zemris.fer.hr [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31968-01; Wed, 20 Jul 2005 16:11:17 +0200 (CEST) Received: from Anardil.ZEMRIS.FER.HR (Anardil.ZEMRIS.FER.HR [161.53.65.229]) by iluvatar.zemris.fer.hr (Postfix) with ESMTP id 9B98313C00B; Wed, 20 Jul 2005 16:11:17 +0200 (CEST) Subject: Re: [Ipsec] IKEv2 implementation announce... From: Stjepan Gros To: Yoav Nir In-Reply-To: <8fdd02670673df177eda5c162fc468fd@checkpoint.com> References: <1121863970.14710.13.camel@anardil.zemris.fer.hr> <8fdd02670673df177eda5c162fc468fd@checkpoint.com> Content-Type: text/plain Date: Wed, 20 Jul 2005 16:29:42 +0200 Message-Id: <1121869782.14710.19.camel@anardil.zemris.fer.hr> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at zemris.fer.hr X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Wed, 2005-07-20 at 16:59 +0300, Yoav Nir wrote: > Cool! > > Isn't racoon2 from the KAME project also an open source project? Yes, though I couldn't find source for IKEv2 daemon. They were not released it, at least that was so about month ago when I last checked. Gros > On Jul 20, 2005, at 3:52 PM, Stjepan Gros wrote: > > > Hi All, > > > > i would like to announce a project that has goal of developing open > > source implementation of IKEv2 protocol. We already have some alpha > > quality code (uncomplete). Snapshot of that code is released on > > sourceforge at the following url: > > > > http://sourceforge.net/projects/ikev2 > > > > Sourceforge is also a primary place for discussions and development. We > > welcome all the suggestions, critics, reviews, etc. > > > > Best regards, > > Stjepan Gros > > > > > > _______________________________________________ > > 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 Jul 20 10:36:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvFgb-0006kL-P6; Wed, 20 Jul 2005 10:36:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DvFga-0006kG-GW for ipsec@megatron.ietf.org; Wed, 20 Jul 2005 10:36:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA22023 for ; Wed, 20 Jul 2005 10:36:34 -0400 (EDT) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DvGAR-0006sG-2e for ipsec@ietf.org; Wed, 20 Jul 2005 11:07:27 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id j6KEaQnP006197; Wed, 20 Jul 2005 17:36:26 +0300 (IDT) In-Reply-To: <1121869782.14710.19.camel@anardil.zemris.fer.hr> References: <1121863970.14710.13.camel@anardil.zemris.fer.hr> <8fdd02670673df177eda5c162fc468fd@checkpoint.com> <1121869782.14710.19.camel@anardil.zemris.fer.hr> Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] IKEv2 implementation announce... Date: Wed, 20 Jul 2005 17:36:26 +0300 To: Stjepan Gros X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org They have released it on June 25th. See this link. http://www.freshports.org/security/racoon2/ I haven't got it to work yet, though. On Jul 20, 2005, at 5:29 PM, Stjepan Gros wrote: > On Wed, 2005-07-20 at 16:59 +0300, Yoav Nir wrote: >> Cool! >> >> Isn't racoon2 from the KAME project also an open source project? > > Yes, though I couldn't find source for IKEv2 daemon. They were not > released it, at least that was so about month ago when I last checked. > > Gros > >> On Jul 20, 2005, at 3:52 PM, Stjepan Gros wrote: >> >>> Hi All, >>> >>> i would like to announce a project that has goal of developing open >>> source implementation of IKEv2 protocol. We already have some alpha >>> quality code (uncomplete). Snapshot of that code is released on >>> sourceforge at the following url: >>> >>> http://sourceforge.net/projects/ikev2 >>> >>> Sourceforge is also a primary place for discussions and development. >>> We >>> welcome all the suggestions, critics, reviews, etc. >>> >>> Best regards, >>> Stjepan Gros >>> >>> >>> _______________________________________________ >>> 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 Jul 22 09:54:12 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvxye-0003oN-71; Fri, 22 Jul 2005 09:54:12 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dvxyc-0003oI-CI for ipsec@megatron.ietf.org; Fri, 22 Jul 2005 09:54:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15993 for ; Fri, 22 Jul 2005 09:54:07 -0400 (EDT) Received: from web25709.mail.ukl.yahoo.com ([217.12.10.181]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1DvySq-0006Q7-ND for ipsec@ietf.org; Fri, 22 Jul 2005 10:25:26 -0400 Received: (qmail 69727 invoked by uid 60001); 22 Jul 2005 13:53:59 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:Received:Date:From:Subject:To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ivgDE3sDl2xO2SjKcSbK0DKYa0m0CLG9q1GAcD6cZUo89oyjZa5GWImn29U3/S5cDIgEfGbQS3Z/kpeCg2GyOPatja0/+CGeKF5ujZbc4Si88nkC0HFcTcUc2TB1nG2K6eLgZVDElEv25Nf/57iWvmbztR1NskMFwHWDbvL5Wms= ; Message-ID: <20050722135359.69725.qmail@web25709.mail.ukl.yahoo.com> Received: from [128.40.42.4] by web25709.mail.ukl.yahoo.com via HTTP; Fri, 22 Jul 2005 14:53:59 BST Date: Fri, 22 Jul 2005 14:53:59 +0100 (BST) From: Takashi Sorimachi To: ipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.9 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a Content-Transfer-Encoding: 8bit Subject: [Ipsec] PFS in CHILD SA creation X-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, It was suggested in IKEv2 (draft-ietf-ipsec-ikev2-17.txt) that if a CHILD SA is created as part of the initial exchange, the nonces from the initial exchange should be used to compute keys for the CHILD SA (p.9). The key set for CHILD SA: KEYMAT = prf(SK_d, Ni | Nr) SK_d is derived from SKEYSEED (the root secret), whereas Ni and Nr are the nonces which have been used already in the initial exchange. Doesn't this arrangement lead to an imperfect forward secrecy, given that all the elements of KEYMAT were derived/used in the initial key exchange? Thanks. ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 25 04:18:49 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwyAj-00069B-AB; Mon, 25 Jul 2005 04:18:49 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwyAg-000693-Pg for ipsec@megatron.ietf.org; Mon, 25 Jul 2005 04:18:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26676 for ; Mon, 25 Jul 2005 04:18:45 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.196]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwyfU-0008QW-Il for ipsec@ietf.org; Mon, 25 Jul 2005 04:50:37 -0400 Received: by rproxy.gmail.com with SMTP id r35so326449rna for ; Mon, 25 Jul 2005 01:18:42 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:content-type:date:mime-version:x-mailer:content-transfer-encoding:message-id; b=MlUIobpY7rTIS8saWWj4w4zruYEZbQGSUjbFTYmxCv1OLOuCzScroYMIMZxl+c0uoTlgUXuXBbSGLS1lphdTbEZGST9Z4LgJRwq57hDw0mMMYmEfGxsjYuYOm83YwdrwH9DjjF/hmx1A3DWForPbFBa1mp7fE+d2CeFvgm32UeA= Received: by 10.38.86.44 with SMTP id j44mr1224560rnb; Mon, 25 Jul 2005 01:18:42 -0700 (PDT) Received: from isabel. ([84.121.24.204]) by mx.gmail.com with ESMTP id 59sm4500219rnb.2005.07.25.01.18.41; Mon, 25 Jul 2005 01:18:42 -0700 (PDT) From: Alejandro =?ISO-8859-1?Q?P=E9rez_M=E9ndez?= To: ipsec@ietf.org Content-Type: text/plain Date: Mon, 25 Jul 2005 10:18:40 +0200 Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit Message-ID: <42e4a062.1bacab29.5e4e.fffffef8@mx.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Subject: [Ipsec] 3DES mode X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, i'm confused about what 3DES mode must be used to encrypt SK payload data when 3DES is negociated in IKEv2 initial exchanges. Must be 3DES_CBC, 3DES_ECB...? Draft only specify 3DES. IMHO it could provoke interoperability issues. Thanks. Alejandro _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 25 04:40:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwyVn-0001TK-GZ; Mon, 25 Jul 2005 04:40:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DwyVl-0001TF-A4 for ipsec@megatron.ietf.org; Mon, 25 Jul 2005 04:40:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA27997 for ; Mon, 25 Jul 2005 04:40:31 -0400 (EDT) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dwz0X-0000k5-4I for ipsec@ietf.org; Mon, 25 Jul 2005 05:12:24 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] 3DES mode Date: Mon, 25 Jul 2005 01:41:03 -0700 Message-ID: Thread-Topic: [Ipsec] 3DES mode Thread-Index: AcWQ8fr8QBMmBdfoShG/V2jGacwZmAAAKUig From: "Vishwas Manral" To: =?iso-8859-1?Q?Alejandro_P=E9rez_M=E9ndez?= , X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Alejandro, I think it means 3DES_CBC as RFC2451 talks about CBC mode. In my view if we want to use 3DES_ECB, we will need a new transform ID = for transform type 1. Thanks, Vishwas -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf = Of Alejandro P=E9rez M=E9ndez Sent: Monday, July 25, 2005 1:49 PM To: ipsec@ietf.org Subject: [Ipsec] 3DES mode Hi, i'm confused about what 3DES mode must be used to encrypt SK payload data when 3DES is negociated in IKEv2 initial exchanges. Must be 3DES_CBC, 3DES_ECB...? Draft only specify 3DES. IMHO it could provoke interoperability issues. Thanks. Alejandro _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jul 25 04:54:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwyiz-0003k8-U4; Mon, 25 Jul 2005 04:54:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dwyiy-0003k3-0q for ipsec@megatron.ietf.org; Mon, 25 Jul 2005 04:54:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA28738 for ; Mon, 25 Jul 2005 04:54:10 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DwzDl-0001AK-Is for ipsec@ietf.org; Mon, 25 Jul 2005 05:26:03 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6P8m5js012146; Mon, 25 Jul 2005 11:48:19 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jul 2005 11:53:58 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 25 Jul 2005 11:53:57 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] 3DES mode Date: Mon, 25 Jul 2005 11:53:58 +0300 Message-ID: Thread-Topic: [Ipsec] 3DES mode Thread-Index: AcWQ8ioGCmbmQfkpR9654v8qiDHvawAA3GIg To: , X-OriginalArrivalTime: 25 Jul 2005 08:53:57.0593 (UTC) FILETIME=[64B5FC90:01C590F6] X-Spam-Score: 0.3 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org When the IKEv2 draft defines the transform number for ENCR_3DES, it also gives a reference to RFC2451 that defines the details.=20 (It's CBC mode.) Best regards, Pasi > -----Original Message----- > From: ext Alejandro P=E9rez M=E9ndez > Sent: Monday, July 25, 2005 11:19 AM > To: ipsec@ietf.org > Subject: [Ipsec] 3DES mode >=20 >=20 > Hi, >=20 > i'm confused about what 3DES mode must be used to encrypt SK payload > data when 3DES is negociated in IKEv2 initial exchanges. Must be > 3DES_CBC, 3DES_ECB...? Draft only specify 3DES. IMHO it could provoke > interoperability issues. >=20 > Thanks. >=20 > Alejandro _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jul 26 00:30:27 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxH5H-0004iU-BJ; Tue, 26 Jul 2005 00:30:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxH5G-0004gN-1O for ipsec@megatron.ietf.org; Tue, 26 Jul 2005 00:30:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21999 for ; Tue, 26 Jul 2005 00:30:23 -0400 (EDT) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxHaB-0004Wm-GE for ipsec@ietf.org; Tue, 26 Jul 2005 01:02:27 -0400 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j6Q4UGcn027614; Mon, 25 Jul 2005 21:30:17 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j6Q4UGFt015009; Tue, 26 Jul 2005 00:30:16 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.4+Sun/8.13.4) with ESMTP id j6Q4UFWE008340; Tue, 26 Jul 2005 00:30:15 -0400 (EDT) Subject: RE: [Ipsec] 3DES mode From: Bill Sommerfeld To: Vishwas Manral In-Reply-To: References: Content-Type: text/plain Message-Id: <1122352214.2863.1046.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.319 Date: Tue, 26 Jul 2005 00:30:15 -0400 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Mon, 2005-07-25 at 04:41, Vishwas Manral wrote: > In my view if we want to use 3DES_ECB, we will need a new transform ID > for transform type 1. but then, nobody in their right mind would want to use any ECB mode cipher directly. - Bill _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jul 27 08:13:09 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dxkmb-0002UF-Qg; Wed, 27 Jul 2005 08:13:09 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxkmZ-0002UA-76 for ipsec@megatron.ietf.org; Wed, 27 Jul 2005 08:13:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA21609 for ; Wed, 27 Jul 2005 08:13:05 -0400 (EDT) Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxlHh-0002dt-Ha for ipsec@ietf.org; Wed, 27 Jul 2005 08:45:25 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id j6RCCvrr028142 for ; Wed, 27 Jul 2005 21:12:57 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id j6RCCvWk022290 for ; Wed, 27 Jul 2005 21:12:57 +0900 (JST) Received: from ovp2.toshiba.co.jp [133.199.166.115] by tsb-wall.toshiba.co.jp with SMTP id XAA22289 ; Wed, 27 Jul 2005 21:12:56 +0900 Received: from mx.toshiba.co.jp (localhost [127.0.0.1]) by ovp2.toshiba.co.jp with ESMTP id j6RCCutP017803 for ; Wed, 27 Jul 2005 21:12:56 +0900 (JST) Received: by toshiba.co.jp id j6RCCut6018381; Wed, 27 Jul 2005 21:12:56 +0900 (JST) To: ipsec@ietf.org Date: Wed, 27 Jul 2005 21:12:56 +0900 From: Fukumoto Atsushi Message-Id: <200507271212.j6RCCut6018381@toshiba.co.jp> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Ipsec] IKEv2 rekeying question X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org In section "2.8 Rekeying", draft-ietf-ipsec-ikev2-17.txt says: If redundant SAs are created though such a collision, the SA created with the lowest of the four nonces used in the two exchanges SHOULD be closed by the endpoint that created it. Questions are: 1. What is the definition of comparison when determining the lowest of the four nonces? Is it to interpret the nonces as big-endian integers (in that case, shorter nonces will be lower, unless the longer nonces happen to have zeros at its head)? I think another possibility is to consider nonces as strings of octets and compare octet-by-octet from head to tail. 2. I didn't understand the phrase "by the endpoint that created it", does it mean the endpoint that initiated the exchange which had the lowest nonce? I understand "SHOULD be closed" means sending DELETE, as described in clarification draft 04 section 5.6. 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 Wed Jul 27 08:58:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxlUD-0006v4-Eo; Wed, 27 Jul 2005 08:58:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxlUA-0006uW-LI for ipsec@megatron.ietf.org; Wed, 27 Jul 2005 08:58:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA24666 for ; Wed, 27 Jul 2005 08:58:08 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DxlzP-00042b-Dx for ipsec@ietf.org; Wed, 27 Jul 2005 09:30:29 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j6RCvrpr028390 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 27 Jul 2005 15:57:53 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j6RCvq71028387; Wed, 27 Jul 2005 15:57:53 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17127.33999.830195.966224@fireball.kivinen.iki.fi> Date: Wed, 27 Jul 2005 15:57:51 +0300 From: Tero Kivinen To: Fukumoto Atsushi Subject: [Ipsec] IKEv2 rekeying question In-Reply-To: <200507271212.j6RCCut6018381@toshiba.co.jp> References: <200507271212.j6RCCut6018381@toshiba.co.jp> 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: 69a74e02bbee44ab4f8eafdbcedd94a1 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 Fukumoto Atsushi writes: > > In section "2.8 Rekeying", draft-ietf-ipsec-ikev2-17.txt says: > If redundant SAs are created though such a collision, the SA > created with the lowest of the four nonces used in the two exchanges > SHOULD be closed by the endpoint that created it. > > Questions are: > > 1. What is the definition of comparison when determining the lowest > of the four nonces? Is it to interpret the nonces as big-endian > integers (in that case, shorter nonces will be lower, unless the > longer nonces happen to have zeros at its head)? I think another > possibility is to consider nonces as strings of octets and compare > octet-by-octet from head to tail. I interpreted it as memcmp... > 2. I didn't understand the phrase "by the endpoint that created it", > does it mean the endpoint that initiated the exchange which had the > lowest nonce? I understand "SHOULD be closed" means sending DELETE, > as described in clarification draft 04 section 5.6. The endpoint who initiated the exchange which had the smallest nonce, should send delete notification to the SA. Of course all child SAs are moved to the winning IKE SA before the old one is deleted (this happens in both ends). There is also couple of different cases there, for example the case where you initiated rekey, got reply back and finished rekey, and only after that you receive the first packet of the other ends rekey (== simulateneous rekey). I.e in that case you already finished completely with the rekey, before you even see the first packet from the second exchange and notice that it was simultaneous rekey. And if this second one is the winning one, then you need to move the child SAs again to this new SA. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jul 27 09:00:52 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxlWm-0007cw-AL; Wed, 27 Jul 2005 09:00:52 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DxlWh-0007cU-42 for ipsec@megatron.ietf.org; Wed, 27 Jul 2005 09:00:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA24955 for ; Wed, 27 Jul 2005 09:00:45 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dxm1u-00049c-7k for ipsec@ietf.org; Wed, 27 Jul 2005 09:33:05 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6RD0Yxw011511 for ; Wed, 27 Jul 2005 16:00:41 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jul 2005 16:00:41 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 27 Jul 2005 16:00:41 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] IKEv2 rekeying question Date: Wed, 27 Jul 2005 16:00:40 +0300 Message-ID: Thread-Topic: [Ipsec] IKEv2 rekeying question Thread-Index: AcWSp4poyTFK55gIRZ20w0FWI3nZqQAAfEXw To: , X-OriginalArrivalTime: 27 Jul 2005 13:00:41.0231 (UTC) FILETIME=[313161F0:01C592AB] X-Spam-Score: 0.3 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Fukumoto Atsushi wrote: >=20 > In section "2.8 Rekeying", draft-ietf-ipsec-ikev2-17.txt says: > If redundant SAs are created though such a collision,=20 > the SA created with the lowest of the four nonces used=20 > in the two exchanges SHOULD be closed by the endpoint=20 > that created it. >=20 > Questions are: >=20 > 1. What is the definition of comparison when determining the lowest > of the four nonces? Is it to interpret the nonces as big-endian > integers (in that case, shorter nonces will be lower, unless the > longer nonces happen to have zeros at its head)? I think another > possibility is to consider nonces as strings of octets and compare > octet-by-octet from head to tail. I think the intent was octet-by-octet (lexicographical) comparison, sort of what "strcmp" does (but without special treatment for zero octet). (In other words: start by comparing the first octet; if they're equal, move to the next octet, and so on. If you reach the end of one nonce, that's the lower one.) > 2. I didn't understand the phrase "by the endpoint that created it", > does it mean the endpoint that initiated the exchange which had the > lowest nonce? I understand "SHOULD be closed" means sending DELETE, > as described in clarification draft 04 section 5.6. Yes, that's right. Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jul 28 04:21:03 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy3dX-0004A7-0w; Thu, 28 Jul 2005 04:21:03 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dy3dV-0004A2-Ib for ipsec@megatron.ietf.org; Thu, 28 Jul 2005 04:21:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05335 for ; Thu, 28 Jul 2005 04:20:59 -0400 (EDT) Received: from inet-tsb.toshiba.co.jp ([202.33.96.40]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Dy48o-000406-Kw for ipsec@ietf.org; Thu, 28 Jul 2005 04:53:30 -0400 Received: from tsb-wall.toshiba.co.jp ([133.199.160.134]) by inet-tsb.toshiba.co.jp with ESMTP id j6S8Knrr013060 for ; Thu, 28 Jul 2005 17:20:49 +0900 (JST) Received: (from root@localhost) by tsb-wall.toshiba.co.jp id j6S8KnCG010501 for ; Thu, 28 Jul 2005 17:20:49 +0900 (JST) Received: from ovp1.toshiba.co.jp [133.199.192.124] by tsb-wall.toshiba.co.jp with SMTP id TAA10494 ; Thu, 28 Jul 2005 17:20:49 +0900 Received: from mx2.toshiba.co.jp (localhost [127.0.0.1]) by ovp1.toshiba.co.jp with ESMTP id j6S8KmBk004937 for ; Thu, 28 Jul 2005 17:20:48 +0900 (JST) Received: by toshiba.co.jp id j6S8Kjsr007117; Thu, 28 Jul 2005 17:20:45 +0900 (JST) To: ipsec@ietf.org Date: Thu, 28 Jul 2005 17:20:45 +0900 From: Fukumoto Atsushi Message-Id: <200507280820.j6S8Kjsr007117@toshiba.co.jp> X-Spam-Score: 0.0 (/) X-Scan-Signature: f607d15ccc2bc4eaf3ade8ffa8af02a0 Subject: [Ipsec] REKEY_SA Notify clarification wanted X-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 says: in section 1.3: If this CREATE_CHILD_SA exchange is rekeying an existing SA other than the IKE_SA, the leading N payload of type REKEY_SA MUST identify the SA being rekeyed. If this CREATE_CHILD_SA exchange is not rekeying an existing SA, the N payload MUST be omitted. and in section 3.10.1: REKEY_SA 16393 This notification MUST be included in a CREATE_CHILD_SA exchange if the purpose of the exchange is to replace an existing ESP or AH SA. The SPI field identifies the SA being rekeyed. There is no data. These are the only mentions of REKEY_SA, and I found it hard to figure out what to do when rekeying IKE SA. The above descriptions strongly suggests (to me) that the REKEY_SA is not used in IKE SA rekeying. But apparently the intention is contrary, since the draft-eronen-ipsec-ikev2-clarification-04 appendix A.5 has this (I assume N(REKEY) means N(REKEY_SA)): A.5 CREATE_CHILD_SA exchange for rekeying the IKE_SA request --> N(REKEY), SA, Ni, [KEi] response <-- SA, Nr, [KEr] Meanwhile, section 5.2 of clarification draft 04 says: IKEv2 does not have any special support for reauthentication. Reauthentication is done by creating a new IKE_SA from scratch (using IKE_SA_INIT/IKE_AUTH exchanges, without any REKEY_SA notify payloads), creating new CHILD_SAs within the new IKE_SA (without REKEY_SA notify payloads), and finally deleting the old IKE_SA (which deletes the old CHILD_SAs as well). which seem to imply by not mentioning "without REKEY_SA" that I need REKEY_SA, although I wish it be more explicit. Also in section 7.7 of clarification draft 04: Since the main purpose of the Protocol ID field is to specify the type of the SPI, our interpretation is that the Protocol ID field should be non-zero only when the SPI field is non-empty. There are currently only two notifications where this is the case: INVALID_SELECTORS and REKEY_SA. This makes me wonder what the Protocol ID should be for REKEY_SA when rekeying IKE SA, if I need one. Is it ProtocolID==IKE_SA (value 1), in which case the SPI field must be non-empty? Or ProtocolID==0, since draft-17 says "For a notification concerning the IKE_SA, the SPI Size MUST be zero"? 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 Jul 28 11:51:10 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyAf8-0003hI-Go; Thu, 28 Jul 2005 11:51:10 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyAf5-0003hC-Fn for ipsec@megatron.ietf.org; Thu, 28 Jul 2005 11:51:07 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA06940 for ; Thu, 28 Jul 2005 11:51:04 -0400 (EDT) Received: from rproxy.gmail.com ([64.233.170.199]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyBAZ-00019P-3z for ipsec@ietf.org; Thu, 28 Jul 2005 12:23:40 -0400 Received: by rproxy.gmail.com with SMTP id r35so706099rna for ; Thu, 28 Jul 2005 08:51:03 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:subject:from:to:content-type:date:mime-version:x-mailer:content-transfer-encoding:message-id; b=tYleywNb0nhIAO2kBB1E4YkWu+yr/VVfJHM9jD+d1NKgb9KoUcl6ECg7BfD3bFeo4dfuryKaxcjCz0oZ2pnxnnQ3qmWBkon5kuxTBKThtDLirwhkR5ZPcR22sarsAuqoGB+YOgcgIJJ78r6MbtoOL/ctBdqp+CHr088D3C/L1R4= Received: by 10.38.98.13 with SMTP id v13mr783106rnb; Thu, 28 Jul 2005 08:51:03 -0700 (PDT) Received: from isabel. ([84.121.24.204]) by mx.gmail.com with ESMTP id 74sm573372rnb.2005.07.28.08.51.02; Thu, 28 Jul 2005 08:51:03 -0700 (PDT) From: Alejandro =?ISO-8859-1?Q?P=E9rez_M=E9ndez?= To: ipsec@ietf.org Content-Type: text/plain Date: Thu, 28 Jul 2005 17:51:00 +0200 Mime-Version: 1.0 X-Mailer: Evolution 2.2.3 Content-Transfer-Encoding: 7bit Message-ID: <42e8fee7.0c40b954.1079.2421@mx.gmail.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Subject: [Ipsec] Integrity key size X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi, I'm implementating IKEv2 protocol and I'm confused about the key size to be used in integrity protection when using AUTH_MD5_96 and AUTH_SHA1_96 algorithms. The section 2.13 in the IKEv2 draft says: << ... For integrity protection functions based on HMAC, the fixed key size is the size of the output of the underlying hash function. ... >> So, whats the SK_ai (and SK_ar) key correct size that must be used, 128 bits for MD5 and 192 for SHA-1 or 96 bits for both? Note I'm referring to the key size, not the digest size that is clearly 96 bits. Another thing: Linux IPsec stack has SHA1 and MD5 integrity algorithms, but they use all bytes, not only the first 96 bits as SHA1_96 and MD5_96 do. What is the Transform id that must be included in the PAYLOAD_SA on the CREATE_CHILD_SA exchange to negociate them? Thanks. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jul 28 12:04:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyAsT-0006He-UG; Thu, 28 Jul 2005 12:04:57 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyAsS-0006HY-8K for ipsec@megatron.ietf.org; Thu, 28 Jul 2005 12:04:56 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA08512 for ; Thu, 28 Jul 2005 12:04:53 -0400 (EDT) Received: from ottawa-hs-209-217-122-41.s-ip.magma.ca ([209.217.122.41] helo=mail.EllipticSemi.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyBNv-0001nY-CI for ipsec@ietf.org; Thu, 28 Jul 2005 12:37:29 -0400 Message-ID: <42E90219.5090905@ellipticsemi.com> Date: Thu, 28 Jul 2005 12:04:41 -0400 From: Michael Bowler User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: =?ISO-8859-1?Q?Alejandro_P=E9rez_M=E9ndez?= , ipsec@ietf.org Subject: Re: [Ipsec] Integrity key size References: <42e8fee7.0c40b954.1079.2421@mx.gmail.com> In-Reply-To: <42e8fee7.0c40b954.1079.2421@mx.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ietf.org id MAA08512 Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Alejandro P=E9rez M=E9ndez wrote: > Hi, >=20 > I'm implementating IKEv2 protocol and I'm confused about the key size t= o > be used in integrity protection when using AUTH_MD5_96 and AUTH_SHA1_96 > algorithms. > The section 2.13 in the IKEv2 draft says:=20 >=20 > << ... For integrity protection functions based on HMAC, the > fixed key size is the size of the output of the underlying hash > function. ... >> >=20 > So, whats the SK_ai (and SK_ar) key correct size that must be used, 128 > bits for MD5 and 192 for SHA-1 or 96 bits for both? Note I'm referring > to the key size, not the digest size that is clearly 96 bits. Based on the output size of underlying hash function, the key sizes=20 would be: MD5 =3D 128 bits SHA-1 =3D 160 bits Cheers, Michael --=20 Michael Bowler mbowler@ellipticsemi.com IC Design Engineer (613) 254-5456x107 Elliptic Semiconductor www.ellipticsemi.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Jul 29 04:08:26 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyPus-0004m6-7V; Fri, 29 Jul 2005 04:08:26 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DyPuq-0004m1-HS for ipsec@megatron.ietf.org; Fri, 29 Jul 2005 04:08:24 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA19575 for ; Fri, 29 Jul 2005 04:08:22 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DyQQS-00005X-B9 for ipsec@ietf.org; Fri, 29 Jul 2005 04:41:05 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j6T87dHY029205; Fri, 29 Jul 2005 11:08:17 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jul 2005 11:08:15 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 29 Jul 2005 11:08:15 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Integrity key size Date: Fri, 29 Jul 2005 11:08:15 +0300 Message-ID: Thread-Topic: [Ipsec] Integrity key size Thread-Index: AcWTjVvj/UxJMOEJQIe+v1nVIlmNNAAhl1aw To: , X-OriginalArrivalTime: 29 Jul 2005 08:08:15.0256 (UTC) FILETIME=[ABCD9180:01C59414] X-Spam-Score: 0.3 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Alejandro P=E9rez M=E9ndez wrote: > > Another thing: Linux IPsec stack has SHA1 and MD5 integrity=20 > algorithms, but they use all bytes, not only the first 96 bits=20 > as SHA1_96 and MD5_96 do. What is the Transform id that must be=20 > included in the PAYLOAD_SA on the CREATE_CHILD_SA exchange to=20 > negociate them? As far as I know, Linux IPsec stack does not support HMAC_SHA1_160=20 or HMAC_MD5_128, only the *_96 versions. (Supporting them would=20 be easy, but there's no real security advantage over the *_96 versions, only more per-packet overhead.) But if it does, there's currently no standard way to negotiate them=20 using IKEv2, because they don't have assigned transform IDs. Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Jul 31 11:58:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzGDG-0000Bq-4q; Sun, 31 Jul 2005 11:58:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzGDD-0000Bc-L7 for ipsec@megatron.ietf.org; Sun, 31 Jul 2005 11:58:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03803 for ; Sun, 31 Jul 2005 11:58:48 -0400 (EDT) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzGjJ-0001P8-1Q for ipsec@ietf.org; Sun, 31 Jul 2005 12:32:02 -0400 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j6VFwaYe026839 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Sun, 31 Jul 2005 18:58:36 +0300 (EEST) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j6VFwWI4026836; Sun, 31 Jul 2005 18:58:32 +0300 (EEST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17132.62760.55380.687054@fireball.kivinen.iki.fi> Date: Sun, 31 Jul 2005 18:58:32 +0300 From: Tero Kivinen To: Fukumoto Atsushi Subject: [Ipsec] REKEY_SA Notify clarification wanted In-Reply-To: <200507280820.j6S8Kjsr007117@toshiba.co.jp> References: <200507280820.j6S8Kjsr007117@toshiba.co.jp> 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: 8b30eb7682a596edff707698f4a80f7d 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 Fukumoto Atsushi writes: > draft-ietf-ipsec-ikev2-17.txt says: > in section 1.3: > If this > CREATE_CHILD_SA exchange is rekeying an existing SA other than the > IKE_SA, the leading N payload of type REKEY_SA MUST identify the SA > being rekeyed. If this CREATE_CHILD_SA exchange is not rekeying an > existing SA, the N payload MUST be omitted. > > and in section 3.10.1: > REKEY_SA 16393 > > This notification MUST be included in a CREATE_CHILD_SA > exchange if the purpose of the exchange is to replace an > existing ESP or AH SA. The SPI field identifies the SA being > rekeyed. There is no data. > > These are the only mentions of REKEY_SA, and I found it hard to figure > out what to do when rekeying IKE SA. The above descriptions strongly > suggests (to me) that the REKEY_SA is not used in IKE SA rekeying. When you are rekeying IKE SA you do not include N(REKEY_SA) at all. It is only included when you are rekeying ESP or AH SA (as the section 3.10.1 and 1.3 say). > But apparently the intention is contrary, since the > draft-eronen-ipsec-ikev2-clarification-04 appendix A.5 has this (I > assume N(REKEY) means N(REKEY_SA)): > > A.5 CREATE_CHILD_SA exchange for rekeying the IKE_SA > > request --> N(REKEY), > SA, Ni, [KEi] > > response <-- SA, Nr, [KEr] I think the clarification draft then has an error. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Jul 31 12:21:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzGZL-0005LZ-4J; Sun, 31 Jul 2005 12:21:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DzGZJ-0005L4-Fz for ipsec@megatron.ietf.org; Sun, 31 Jul 2005 12:21:41 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05386 for ; Sun, 31 Jul 2005 12:21:38 -0400 (EDT) Received: from [217.219.18.2] (helo=cc2.iut.ac.ir) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1DzH5O-0002c8-Bh for ipsec@ietf.org; Sun, 31 Jul 2005 12:54:52 -0400 Received: from ec.iut.ac.ir (localhost.localdomain [127.0.0.1]) by cc2.iut.ac.ir (Postfix) with ESMTP id AC1056817C for ; Sun, 31 Jul 2005 20:14:17 +0430 (IRDT) From: "mahdavi" To: ipsec@ietf.org Date: Sun, 31 Jul 2005 19:14:17 +0330 Message-Id: <20050731153910.M98618@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-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Ipsec] ipsec sample packets X-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. I am searching for ipsec sample packets before and after tunneling in various forms. I reached to http://ipsec-wit.antd.nist.gov In some email of yours I found that there I can get what I want. after stepping throgh the forms I get no Sample Packets. How can I get sample packets there? I cant undrestand what it means with directory ? With best of regards. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec