From ipsec-bounces@ietf.org Tue Feb 1 00:38:51 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA26736 for ; Tue, 1 Feb 2005 00:38:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvqft-0006cw-KP; Tue, 01 Feb 2005 00:34:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvqRL-0002s2-2C for ipsec@megatron.ietf.org; Tue, 01 Feb 2005 00:19:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA24362 for ; Tue, 1 Feb 2005 00:19:00 -0500 (EST) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvqjQ-0005tP-DP for ipsec@ietf.org; Tue, 01 Feb 2005 00:37:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Comments: draft-ietf-ipsec-ikev2-17.txt Date: Mon, 31 Jan 2005 21:27:09 -0800 Message-ID: Thread-Topic: [Ipsec] Comments: draft-ietf-ipsec-ikev2-17.txt thread-index: AcUHoldCymOYL6QUQPCb4UOF1jBbZAAFaBWuABi+OTA= From: "Vishwas Manral" To: "Tero Kivinen" X-Spam-Score: 0.0 (/) X-Scan-Signature: a069a8e8835d39ce36e425c148267a7b Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Tero, I am adding the set of comments not yet addressed or not yet resolved. I = have updated the comments (based on feedback from you) and have also = added definitive text wherever possible: - 1. Section 2.13 - states "**they** algorithm by which keys are derived = from arbitrary values MUST be specified by the cryptographic transform. = " Typo. 2. Section 3.3.2 - Transform type Values Integrity Algorithm (INTEG) 3 (IKE, AH, optional in ESP) I think we can remove the "optional" in ESP part for Integrity = Algorithm. The ESP document states that: - " - confidentiality-only (MAY be supported) - integrity-only (MUST be supported) - confidentiality and integrity (MUST be supported)" Besides NONE should not be used as the integrity algorithm in Section = 3.3.2? It would also make things clearer if it was stated that when = confidentiality service is not used we should use=20 3. Section 3.3.3 change Protocol Mandatory Types Optional Types IKE ENCR, PRF, INTEG, D-H ESP ENCR INTEG, D-H, ESN AH INTEG D-H, ESN to Protocol Mandatory Types Optional Types IKE ENCR, PRF, INTEG, D-H ESP INTEG, ENCR D-H, ESN <<=3D=3D changed = here AH INTEG D-H, ESN 4. Section 1.2 states: - "All but the headers of all the messages that follow are encrypted and = integrity protected." to be changed to "For all messages that follow, the message following the header is = encrypted and the message including the header is integrity protected." 5. "In other words, if the responder stated its window size is N, then = when the initiator needs to make a request X, it MUST wait until it has = received responses to all requests up through request X-N." This = statement may not be true for X < N, if we are putting in values we = should specify the range properly. Otherwise it is good enough to remove = the part from the document itself. 6. In Section 2.13 we talk about (K, S) but never specify what K or S = mean. Tero, mentioned they are inputs. I am not sure if we can replace K = and S with Y, Z. If yes, we can leave it as it is else we need to = specify what they mean. 7. IKE document talks about ECN, but won't a similar case be there for = DSCP values. I think DSCP values should be copied from the Outer header = back to the inner header too. The text for DSCP is=20 "2.23 DSCP (DiffServ Code Point) When IPsec tunnels behave as originally specified in [RFC2401], DSCP usage is not appropriate for the outer IP headers because tunnel decapsulation processing can discard DSCP values. =20 IKEv2 simplifies this situation by requiring that DSCP values be=20 usable in the outer IP headers of all tunnel-mode IPsec SAs created by IKEv2. The decapsulating process needs to copy the DSCP value to the outer header as specified in [RFC2401bis]." 8. We may want to state (obvious) that IKE message on port 4500, MUST = have the first 4 bytes as zero on receipt and should always send the = bytes as 0. Though Tero pointed out a quote from the draft, it is clear = that it does not specify how to treat received values. I am ok, posting errata if the text cannot be added in the current = version of the document (document being in the RFC-Editor). Thanks, Vishwas ________________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf = Of Vishwas Manral Sent: Monday, January 31, 2005 10:55 PM To: Tero Kivinen Cc: ipsec@ietf.org Subject: RE: [Ipsec] Comments: draft-ietf-ipsec-ikev2-17.txt Hi Tero, =A0 Thanks a lot for the reply. My comments are prefixed with a "VM>" =A0 > "All but the headers of all the messages that follow are encrypted and = integrity protected." > > Do we also mean to say that the header is integrity protected but > not encrypted? We may want to clarify the text, and instead state > "For all messages that folllow, the header is encrypted and the > message including the header is integrity protected." Header is not encrypted, the data after header is encrypted, so your text is actually incorrect. It is true we could clarify that the header is also integrity protected.... VM> I guess I agree the text I gave confused it further. What I meant is = everything after the header is encrypted, and including the header is = integrity protected.=A0 Maybe the text you state is clearer. =A0 > 2. Section 3.3.2 - Transform type Values: - > > Encryption Algorithm (ENCR)=A0=A0=A0=A0 1=A0 (IKE and ESP) > Integrity Algorithm (INTEG)=A0=A0=A0=A0 3=A0 (IKE, AH, optional in = ESP) > > I think we can remove the "optional" in ESP part for Integrity > Algorithm. The optional part could be added instead to the > Encryption Algorithm part. No, we cannot remove that. Integrity is optional in ESP. Encryption is NOT optional in the ESP. If you do not want to use encryption in ESP, you need to negotiate cipher called ENCR_NULL. VM> I think we can remove the "INTEG part is optional" in ESP part of = it. If I see the Architecture document right, that is what is stated = very clearly. Am I=A0missing something there? This discrepancy seems to = be in a lot of drafts.=20 > 6.=A0 In Section 2.13 we talk about (K, S) but never specify what K or >=A0=A0=A0=A0 S mean. I think it is quite obvious that they are inputs to the function prf+... VM> Being a first time reader, I couldn't figure out what K and S stand = for(inputs to the function for sure, what do they mean). It was not = defined before or even in the same section(though everything else was). =A0 > 8.=A0 We may want to state(obvious) that IKE message on port 4500, >=A0=A0=A0=A0 MUST have the first 4 bytes as zero on receipt and should = always >=A0=A0=A0=A0 send the bytes as 0. I think the section 3.1 says that: ---------------------------------------------------------------------- =A0=A0 When sent on UDP port 4500, IKE messages have prepended four = octets =A0=A0 of zero. These four octets of zero are not part of the IKE = message =A0=A0 and are not included in any of the length fields or checksums =A0=A0 defined by IKE. VM> I do not agree, it anywhere states that a value of non-zero on input = is a wrong=A0 value. I think as a good protocol specification, we should = clearly specify the behavior even in cases where=A0an incorrect=A0value = is received(spcefying the=A0values to receive). I know things may seem = obvious to you but I guess to anyone implementing this, it may not. = Though I have not worked on IKE for long enough, I have figured this out = working and documenting other protocols. =A0 Thanks, Vishwas ________________________________________ From: Tero Kivinen [mailto:kivinen@iki.fi] Sent: Mon 1/31/2005 6:27 AM To: Vishwas Manral Cc: ipsec@ietf.org Subject: [Ipsec] Comments: draft-ietf-ipsec-ikev2-17.txt Vishwas Manral writes: > 2. Section 3.3.2 - Transform type Values: - > > Encryption Algorithm (ENCR)=A0=A0=A0=A0 1=A0 (IKE and ESP) > Integrity Algorithm (INTEG)=A0=A0=A0=A0 3=A0 (IKE, AH, optional in = ESP) > > I think we can remove the "optional" in ESP part for Integrity > Algorithm. The optional part could be added instead to the > Encryption Algorithm part. No, we cannot remove that. Integrity is optional in ESP. Encryption is NOT optional in the ESP. If you do not want to use encryption in ESP, you need to negotiate cipher called ENCR_NULL. > 4. Section 1.2 states: - > > "All but the headers of all the messages that follow are encrypted and = integrity protected." > > Do we also mean to say that the header is integrity protected but > not encrypted? We may want to clarify the text, and instead state > "For all messages that folllow, the header is encrypted and the > message including the header is integrity protected." Header is not encrypted, the data after header is encrypted, so your text is actually incorrect. It is true we could clarify that the header is also integrity protected.... > 6.=A0 In Section 2.13 we talk about (K, S) but never specify what K or >=A0=A0=A0=A0 S mean. I think it is quite obvious that they are inputs to the function prf+... > 8.=A0 We may want to state(obvious) that IKE message on port 4500, >=A0=A0=A0=A0 MUST have the first 4 bytes as zero on receipt and should = always >=A0=A0=A0=A0 send the bytes as 0. I think the section 3.1 says that: ---------------------------------------------------------------------- =A0=A0 When sent on UDP port 4500, IKE messages have prepended four = octets =A0=A0 of zero. These four octets of zero are not part of the IKE = message =A0=A0 and are not included in any of the length fields or checksums =A0=A0 defined by IKE. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 1 02:38:00 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22437 for ; Tue, 1 Feb 2005 02:38:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvsZJ-0004uv-IN; Tue, 01 Feb 2005 02:35:25 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvsY3-0002sE-OE for ipsec@megatron.ietf.org; Tue, 01 Feb 2005 02:34:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA22003 for ; Tue, 1 Feb 2005 02:34:06 -0500 (EST) Received: from mtagate3.uk.ibm.com ([195.212.29.136]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvsqA-0000hU-Cw for ipsec@ietf.org; Tue, 01 Feb 2005 02:52:50 -0500 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate3.uk.ibm.com (8.12.10/8.12.10) with ESMTP id j117XUvD170152 for ; Tue, 1 Feb 2005 07:33:30 GMT Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j117XUtd159246 for ; Tue, 1 Feb 2005 07:33:30 GMT Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j117XUfc025962 for ; Tue, 1 Feb 2005 07:33:30 GMT Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d06av02.portsmouth.uk.ibm.com (8.12.11/8.12.11) with ESMTP id j117XTxc025955; Tue, 1 Feb 2005 07:33:30 GMT Received: from zurich.ibm.com (sig-9-146-222-146.de.ibm.com [9.146.222.146]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id IAA92288; Tue, 1 Feb 2005 08:33:28 +0100 Message-ID: <41FF30C5.8050307@zurich.ibm.com> Date: Tue, 01 Feb 2005 08:33:25 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Vishwas Manral Subject: Re: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: ipsec@ietf.org List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit I am about to leave for 3 weeks so I have no time to check the text, but it has always been considered wrong on security grounds to copy bits from the outer (unprotected) header into the decapsulated (protected) header. That is very clear in the IPsec RFCs and I hope it remains clear in the new ones. Brian Vishwas Manral wrote: > Hi Steve/ Karen, > > I am resending an older mail, in case it got missed in transit. > > Although the security architecture talks about how the outer header is > generated from the inner header in tunnel mode while encapsulation, I > think the document completely misses the part of fields being copied > back into the inner header while decapsulation. > > I am CC'ing Brian Carpenter too, as he would probably have the best view > on this. > > Thanks, > Vishwas > ________________________________________ > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Vishwas Manral > Sent: Monday, January 31, 2005 9:37 AM > To: ipsec@ietf.org > Subject: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt > > Hi Steve, > > I think the security architecture does not specify copying of DSCP and > ECN values from the outer header to the inner header in the case of > decapsulation for tunnel mode for both IPv4 and IPv6. > > DSCP values will not be copied directly however, depending on the change > of domain. > > Thanks, > Vishwas > > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 1 03:47:00 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03476 for ; Tue, 1 Feb 2005 03:47:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cvteb-0000A9-GT; Tue, 01 Feb 2005 03:44:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvtZp-0007uW-3o for ipsec@megatron.ietf.org; Tue, 01 Feb 2005 03:40:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02932 for ; Tue, 1 Feb 2005 03:40:00 -0500 (EST) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cvtrv-0002FB-Lh for ipsec@ietf.org; Tue, 01 Feb 2005 03:58:44 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt Date: Tue, 1 Feb 2005 00:48:07 -0800 Message-ID: Thread-Topic: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt thread-index: AcUIMbw5kEbr9zfVSj6GAI2CBaYfDwACEXaw From: "Vishwas Manral" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 92df29fa99cf13e554b84c8374345c17 Content-Transfer-Encoding: quoted-printable Cc: brc@zurich.ibm.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Brian, I hope this gets through before you leave. There are two points I wanted to state: - 1. The only fields we copy from the outer to the inner header are the DSCP/ ECN fields. The idea is the DSCP field in the inner header may not be recognized in the domain and the best value would be the outer field itself. Besides dropping ECN field (not copying the outer header) could result in wrong treatment of packets. 2. If a router in the middle wanted to disrupt traffic by changing DSCP it could easily do so by dropping the packet itself. So not copying does not help at all. Do let me know if I am off track completely? Thanks, Vishwas -----Original Message----- From: Brian E Carpenter [mailto:brc@zurich.ibm.com]=20 Sent: Tuesday, February 01, 2005 1:03 PM To: Vishwas Manral Cc: ipsec@ietf.org Subject: Re: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt I am about to leave for 3 weeks so I have no time to check the text, but it has always been considered wrong on security grounds to copy bits from the outer (unprotected) header into the decapsulated (protected) header. That is very clear in the IPsec RFCs and I hope it remains clear in the new ones. Brian Vishwas Manral wrote: > Hi Steve/ Karen, >=20 > I am resending an older mail, in case it got missed in transit.=20 >=20 > Although the security architecture talks about how the outer header is > generated from the inner header in tunnel mode while encapsulation, I > think the document completely misses the part of fields being copied > back into the inner header while decapsulation. >=20 > I am CC'ing Brian Carpenter too, as he would probably have the best view > on this. >=20 > Thanks, > Vishwas > ________________________________________ > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf > Of Vishwas Manral > Sent: Monday, January 31, 2005 9:37 AM > To: ipsec@ietf.org > Subject: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt >=20 > Hi Steve, >=20 > I think the security architecture does not specify copying of DSCP and > ECN values from the outer header to the inner header in the case of > decapsulation for tunnel mode for both IPv4 and IPv6. >=20 > DSCP values will not be copied directly however, depending on the change > of domain. >=20 > Thanks, > Vishwas >=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 1 04:30:14 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06861 for ; Tue, 1 Feb 2005 04:30:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvuKi-0006zw-EJ; Tue, 01 Feb 2005 04:28:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvuIH-0006gQ-0w for ipsec@megatron.ietf.org; Tue, 01 Feb 2005 04:25:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06514 for ; Tue, 1 Feb 2005 04:25:55 -0500 (EST) Received: from mtagate3.de.ibm.com ([195.212.29.152]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvuaO-0003hw-5p for ipsec@ietf.org; Tue, 01 Feb 2005 04:44:40 -0500 Received: from d12nrmr1507.megacenter.de.ibm.com (d12nrmr1507.megacenter.de.ibm.com [9.149.167.1]) by mtagate3.de.ibm.com (8.12.10/8.12.10) with ESMTP id j119PNdt125896 for ; Tue, 1 Feb 2005 09:25:23 GMT Received: from d12av01.megacenter.de.ibm.com (d12av01.megacenter.de.ibm.com [9.149.165.212]) by d12nrmr1507.megacenter.de.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j119PNIW080368 for ; Tue, 1 Feb 2005 10:25:23 +0100 Received: from d12av01.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j119PN6E012236 for ; Tue, 1 Feb 2005 10:25:23 +0100 Received: from sihl.zurich.ibm.com (sihl.zurich.ibm.com [9.4.16.232]) by d12av01.megacenter.de.ibm.com (8.12.11/8.12.11) with ESMTP id j119PNGS012228; Tue, 1 Feb 2005 10:25:23 +0100 Received: from zurich.ibm.com (sig-9-146-222-146.de.ibm.com [9.146.222.146]) by sihl.zurich.ibm.com (AIX4.3/8.9.3p2/8.9.3) with ESMTP id KAA28726; Tue, 1 Feb 2005 10:25:21 +0100 Message-ID: <41FF4B02.9040509@zurich.ibm.com> Date: Tue, 01 Feb 2005 10:25:22 +0100 From: Brian E Carpenter Organization: IBM User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en, fr, de MIME-Version: 1.0 To: Vishwas Manral Subject: Re: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 6e922792024732fb1bb6f346e63517e4 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Vishwas Manral List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit The background for this is in RFC 2983 (and David Black might be interested in this topic). But I think you're correct; my only concern was to check that the decapsulator behavior is unchanged as far as the QOS fields are concerned. I believe the behavior required by RFC 2401, in the tables in section 5.1, remains correct: a decapsulator must not change the inner TOS/DSCP value because any change that has ocurred in the the outer header is potentially an exposure (to QOS-based DOS for example). The prohibition is even stronger for the IPv6 Flow Label which now is defined as immutable, so that is a very strong MUST NOT change. The tables in 5.1.2.1 and 5.1.2.2 of 2401bis are the same (except for ECN) so this is fine as-is. I really can't judge whether there are any attacks available due to ECN twiddling in the outer header. Brian Vishwas Manral wrote: > Hi Brian, > > I hope this gets through before you leave. There are two points I wanted > to state: - > > 1. The only fields we copy from the outer to the inner header are the > DSCP/ ECN fields. The idea is the DSCP field in the inner header may not > be recognized in the domain and the best value would be the outer field > itself. Besides dropping ECN field (not copying the outer header) could > result in wrong treatment of packets. > 2. If a router in the middle wanted to disrupt traffic by changing DSCP > it could easily do so by dropping the packet itself. So not copying does > not help at all. > > Do let me know if I am off track completely? > > Thanks, > Vishwas > > -----Original Message----- > From: Brian E Carpenter [mailto:brc@zurich.ibm.com] > Sent: Tuesday, February 01, 2005 1:03 PM > To: Vishwas Manral > Cc: ipsec@ietf.org > Subject: Re: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt > > I am about to leave for 3 weeks so I have no time to check the text, > but it has always been considered wrong on security grounds to > copy bits from the outer (unprotected) header into the decapsulated > (protected) header. That is very clear in the IPsec RFCs and I hope > it remains clear in the new ones. > > Brian > > Vishwas Manral wrote: > >>Hi Steve/ Karen, >> >>I am resending an older mail, in case it got missed in transit. >> >>Although the security architecture talks about how the outer header is >>generated from the inner header in tunnel mode while encapsulation, I >>think the document completely misses the part of fields being copied >>back into the inner header while decapsulation. >> >>I am CC'ing Brian Carpenter too, as he would probably have the best > > view > >>on this. >> >>Thanks, >>Vishwas >>________________________________________ >>From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >>Of Vishwas Manral >>Sent: Monday, January 31, 2005 9:37 AM >>To: ipsec@ietf.org >>Subject: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt >> >>Hi Steve, >> >>I think the security architecture does not specify copying of DSCP and >>ECN values from the outer header to the inner header in the case of >>decapsulation for tunnel mode for both IPv4 and IPv6. >> >>DSCP values will not be copied directly however, depending on the > > change > >>of domain. >> >>Thanks, >>Vishwas >> > > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 1 06:43:07 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA18605 for ; Tue, 1 Feb 2005 06:43:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvwKz-0007Ck-QT; Tue, 01 Feb 2005 06:36:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CvwI5-0006mj-FY for ipsec@megatron.ietf.org; Tue, 01 Feb 2005 06:33:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA17579 for ; Tue, 1 Feb 2005 06:33:51 -0500 (EST) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CvwaD-0006oj-Fo for ipsec@ietf.org; Tue, 01 Feb 2005 06:52:38 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt Date: Tue, 1 Feb 2005 03:41:59 -0800 Message-ID: Thread-Topic: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt thread-index: AcUIQV5zoFo722zuQ0WItW891LcKxQAC380g From: "Vishwas Manral" To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Steve/ Karen, After the discussion with Brian (and checking rfc2983), I think the following minor change can be added in section 5.1.2.1 and 5.1.2.2, for the Inner Header at decapsulator: - DSCP - constructed (9) 9. If the DSCP values changes a diffserv domain, the diffserv traffic conditioning SHOULD be done in order to ensure that traffic exiting the node is compatible with the egress node's diffserv domain. Regarding the ECN part, I think I understand. The values ECT (0) and ECT (1) can be there as is and CE is copied to make sure that in case of congestion it is signaled to the endpoint. However this can lead to an intermediate router changing the value maliciously to CE (but packets could as well have been dropped by the intermediate router). I hope my understanding is right here? Thanks, Vishwas -----Original Message----- From: Brian E Carpenter [mailto:brc@zurich.ibm.com]=20 Sent: Tuesday, February 01, 2005 2:55 PM To: Vishwas Manral Cc: ipsec@ietf.org Subject: Re: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt The background for this is in RFC 2983 (and David Black might be interested in this topic). But I think you're correct; my only concern was to check that the decapsulator behavior is unchanged as far as the QOS fields are concerned. I believe the behavior required by RFC 2401, in the tables in section 5.1, remains correct: a decapsulator must not change the inner TOS/DSCP value because any change that has ocurred in the the outer header is potentially an exposure (to QOS-based DOS for example). The prohibition is even stronger for the IPv6 Flow Label which now is defined as immutable, so that is a very strong MUST NOT change. The tables in 5.1.2.1 and 5.1.2.2 of 2401bis are the same (except for ECN) so this is fine as-is. I really can't judge whether there are any attacks available due to ECN twiddling in the outer header. Brian Vishwas Manral wrote: > Hi Brian, >=20 > I hope this gets through before you leave. There are two points I wanted > to state: - >=20 > 1. The only fields we copy from the outer to the inner header are the > DSCP/ ECN fields. The idea is the DSCP field in the inner header may not > be recognized in the domain and the best value would be the outer field > itself. Besides dropping ECN field (not copying the outer header) could > result in wrong treatment of packets. > 2. If a router in the middle wanted to disrupt traffic by changing DSCP > it could easily do so by dropping the packet itself. So not copying does > not help at all. >=20 > Do let me know if I am off track completely? >=20 > Thanks, > Vishwas >=20 > -----Original Message----- > From: Brian E Carpenter [mailto:brc@zurich.ibm.com]=20 > Sent: Tuesday, February 01, 2005 1:03 PM > To: Vishwas Manral > Cc: ipsec@ietf.org > Subject: Re: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt >=20 > I am about to leave for 3 weeks so I have no time to check the text, > but it has always been considered wrong on security grounds to > copy bits from the outer (unprotected) header into the decapsulated > (protected) header. That is very clear in the IPsec RFCs and I hope > it remains clear in the new ones. >=20 > Brian >=20 > Vishwas Manral wrote: >=20 >>Hi Steve/ Karen, >> >>I am resending an older mail, in case it got missed in transit.=20 >> >>Although the security architecture talks about how the outer header is >>generated from the inner header in tunnel mode while encapsulation, I >>think the document completely misses the part of fields being copied >>back into the inner header while decapsulation. >> >>I am CC'ing Brian Carpenter too, as he would probably have the best >=20 > view >=20 >>on this. >> >>Thanks, >>Vishwas >>________________________________________ >>From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf >>Of Vishwas Manral >>Sent: Monday, January 31, 2005 9:37 AM >>To: ipsec@ietf.org >>Subject: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt >> >>Hi Steve, >> >>I think the security architecture does not specify copying of DSCP and >>ECN values from the outer header to the inner header in the case of >>decapsulation for tunnel mode for both IPv4 and IPv6. >> >>DSCP values will not be copied directly however, depending on the >=20 > change >=20 >>of domain. >> >>Thanks, >>Vishwas >> >=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 1 11:22:51 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21831 for ; Tue, 1 Feb 2005 11:22:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw0jP-0000St-5q; Tue, 01 Feb 2005 11:18:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw0dd-0007VM-1X for ipsec@megatron.ietf.org; Tue, 01 Feb 2005 11:12:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20870 for ; Tue, 1 Feb 2005 11:12:23 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw0vn-0006EU-Bs for ipsec@ietf.org; Tue, 01 Feb 2005 11:31:12 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j11GBfjf029649; Tue, 1 Feb 2005 11:11:42 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 1 Feb 2005 11:11:26 -0500 To: "Vishwas Manral" From: Stephen Kent Subject: RE: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ipsec@ietf.org, brc@zurich.ibm.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 3:41 AM -0800 2/1/05, Vishwas Manral wrote: >Hi Steve/ Karen, > >After the discussion with Brian (and checking rfc2983), I think the >following minor change can be added in section 5.1.2.1 and 5.1.2.2, for >the Inner Header at decapsulator: - > >DSCP - constructed (9) > >9. If the DSCP values changes a diffserv domain, the diffserv traffic >conditioning SHOULD be done in order to ensure that traffic exiting the >node is compatible with the egress node's diffserv domain. So, what you are suggesting is that if the receiver is in a different diffserv domain, then it should change the DSCP value apropos the receiver's domain, right? How would this be done, in practice, e.g., would one require a table to map between the DSCP values for each domain? I'm tempted to say this should be done outside the IPsec context, by the receiver, so that this is not another IPsec configuration item, e.g., part of the SPD. We could insert a note to that effect if folks agree. >Regarding the ECN part, I think I understand. The values ECT (0) and ECT >(1) can be there as is and CE is copied to make sure that in case of >congestion it is signaled to the endpoint. However this can lead to an >intermediate router changing the value maliciously to CE (but packets >could as well have been dropped by the intermediate router). I hope my >understanding is right here? The ECN value is copied from the outer header to the inner header as described in the text, based on analysis David Black did a few years ago, and codified in RFC 2983. The notion is that a malicious router could do other evil things to packets comparable to what it can effect via changes to the ECN value, so it makes sense to copy the bit as directed, to support ECN functionality. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 1 12:20:47 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26244 for ; Tue, 1 Feb 2005 12:20:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw1T7-0004IE-A0; Tue, 01 Feb 2005 12:05:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw1Kt-0007mD-Oo for ipsec@megatron.ietf.org; Tue, 01 Feb 2005 11:57:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24398 for ; Tue, 1 Feb 2005 11:57:06 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw1d4-0007Gh-S0 for ipsec@ietf.org; Tue, 01 Feb 2005 12:15:56 -0500 Received: from [128.89.89.115] (dhcp89-089-115.bbn.com [128.89.89.115]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j11GuYjf002583; Tue, 1 Feb 2005 11:56:35 -0500 (EST) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: <20050124221258.GA6005@thunk.org> References: <20050124221258.GA6005@thunk.org> Date: Tue, 1 Feb 2005 12:00:22 -0500 To: "Theodore Ts'o" From: Karen Seo Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ipsec@ietf.org, Sam Hartman , Russ Housley Subject: [Ipsec] Re: Status update re: Issues remaining for draft-ietf-ipsec-rfc2401bis X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Ted, Sorry to take so long to reply... I have checked the boilerplate and it matches the text contained in recently approved RFCs, and conforms to RFCs 3667 and 3668. Sam Hartman's issue #1 is still under discussion. If this gets resolved this week, then we should be able to submit a draft next week. (Note: I'll be out of town the rest of this week without email access.) Karen >On Mon, Jan 24, 2005 at 01:40:23PM -0500, Karen Seo wrote: >> Russ, Ted, >> >> We have revised 2401bis to address the list of issues in the tracker >> with the exception of one issue that is still under discussion with >> Sam Hartman (plus possible boilerplate updates). Once that is >> resolved, the draft will be edited as necessary, nroffed, etc. and >> submitted to the IESG. > >Karen, Steve, > >This is great to hear! Many thanks to both of you for your hard work >in finishing the edits to 2401-bis. Both Barbara and I are looking >forward to what will hopefully be the last version of >draft-ietf-ipsec-rfc2401bis to be submitted to the I-D editor. >Assuming you can clear the last issue with Sam fairly quickly, do you >think you would be able to finish the boilerplate/nroff fixups within >the week? It would be really great for the IESG to be able to approve >this document and be able to close out this working group before the >Minneapolis meeting. > > - Ted _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 1 12:35:15 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA28302 for ; Tue, 1 Feb 2005 12:35:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw1oj-00037f-MB; Tue, 01 Feb 2005 12:27:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw1WT-0005Ba-GF for ipsec@megatron.ietf.org; Tue, 01 Feb 2005 12:09:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25299 for ; Tue, 1 Feb 2005 12:09:03 -0500 (EST) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw1of-0007VH-2Z for ipsec@ietf.org; Tue, 01 Feb 2005 12:27:53 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt Date: Tue, 1 Feb 2005 09:18:31 -0800 Message-ID: Thread-Topic: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt thread-index: AcUIejZ4vFB5TpjoSOetiwFMBL5AzQABrP1s From: "Vishwas Manral" To: "Stephen Kent" X-Spam-Score: 0.5 (/) X-Scan-Signature: 7268a2980febc47a9fa732aba2b737ba Cc: ipsec@ietf.org, brc@zurich.ibm.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0918768839==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0918768839== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50882.0D712CFE" This is a multi-part message in MIME format. ------_=_NextPart_001_01C50882.0D712CFE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Steve, =20 > So, what you are suggesting is that if the receiver is in a different > diffserv domain, then it should change the DSCP value apropos the > receiver's domain, right? How would this be done, in practice, e.g., > would one require a table to map between the DSCP values for each > domain? I'm tempted to say this should be done outside the IPsec > context, by the receiver, so that this is not another IPsec > configuration item, e.g., part of the SPD. We could insert a note > to that effect if folks agree. Yes that is what I am suggesting, as a DSCP value in one domain may not = make=20 sense in another domain at all (so leaving the text as is is not right I = think).=20 =20 There could be alternatives. If it was normal IP-in-IP tunnelling we = could as well=20 use the outer header DSCP and ECN values, which would be the best case. =20 However for IPSec from the hardware forwarding point of view it would be = best if the inner header already had the right value DSCP value, but that would = mean adding changes in the IKE draft.=20 =20 So I think the alternative you agree to is the best. Anyone else? =20 Thanks, Vishwas ________________________________ From: Stephen Kent [mailto:kent@bbn.com] Sent: Tue 2/1/2005 8:11 AM To: Vishwas Manral Cc: brc@zurich.ibm.com; ipsec@ietf.org Subject: RE: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt At 3:41 AM -0800 2/1/05, Vishwas Manral wrote: >Hi Steve/ Karen, > >After the discussion with Brian (and checking rfc2983), I think the >following minor change can be added in section 5.1.2.1 and 5.1.2.2, for >the Inner Header at decapsulator: - > >DSCP - constructed (9) > >9. If the DSCP values changes a diffserv domain, the diffserv traffic >conditioning SHOULD be done in order to ensure that traffic exiting the >node is compatible with the egress node's diffserv domain. So, what you are suggesting is that if the receiver is in a different diffserv domain, then it should change the DSCP value apropos the receiver's domain, right? How would this be done, in practice, e.g., would one require a table to map between the DSCP values for each domain? I'm tempted to say this should be done outside the IPsec context, by the receiver, so that this is not another IPsec configuration item, e.g., part of the SPD. We could insert a note to that effect if folks agree. >Regarding the ECN part, I think I understand. The values ECT (0) and = ECT >(1) can be there as is and CE is copied to make sure that in case of >congestion it is signaled to the endpoint. However this can lead to an >intermediate router changing the value maliciously to CE (but packets >could as well have been dropped by the intermediate router). I hope my >understanding is right here? The ECN value is copied from the outer header to the inner header as described in the text, based on analysis David Black did a few years ago, and codified in RFC 2983. The notion is that a malicious router could do other evil things to packets comparable to what it can effect via changes to the ECN value, so it makes sense to copy the bit as directed, to support ECN functionality. Steve ------_=_NextPart_001_01C50882.0D712CFE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= RE: [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt=0A= =0A= =0A=
=0A=
Hi = Steve,
=0A=
 
=0A=
> So, what you are suggesting is that = if the =0A= receiver is in a different
=0A=
> diffserv domain, then it should = change the DSCP =0A= value apropos the
=0A=
> receiver's domain, right? How would = this be done, =0A= in practice, e.g.,
=0A=
> would one require a table to map = between the DSCP =0A= values for each
=0A=
> domain? I'm tempted to say this = should be done =0A= outside the IPsec
=0A=
> context, by the receiver, so that = this is not =0A= another IPsec
=0A=
> configuration item, e.g., part of the = SPD.  =0A= We could  insert a note
=0A=
> to that effect if folks = agree.
=0A=
Yes that is what I am suggesting, as a = DSCP value in =0A= one domain may not make
=0A=
sense in another domain at all (so leaving = the text as =0A= is is not right I think).
=0A=
 
=0A=
There could be alternatives. If it =0A= was normal IP-in-IP tunnelling we could as well
=0A=
use the outer header DSCP and ECN =0A= values, which would be the best case.
=0A=
 
=0A=
However for IPSec from the hardware = forwarding point =0A= of view it would be best if the
=0A=
 inner header = already had the =0A= right value DSCP value, but that would mean adding changes
=0A=
in the IKE draft.
=0A=
 
=0A=
So I think the alternative you agree to is = the best. =0A= Anyone else?
=0A=
 
=0A=
Thanks,
=0A=
Vishwas
=0A=
=0A=
=0A=
=0A=
From: Stephen Kent =0A= [mailto:kent@bbn.com]
Sent: Tue 2/1/2005 8:11 AM
To: = Vishwas =0A= Manral
Cc: brc@zurich.ibm.com; = ipsec@ietf.org
Subject: RE: =0A= [Ipsec] draft-ietf-ipsec-rfc2401bis-05.txt

=0A=
=0A=

At 3:41 AM -0800 2/1/05, Vishwas Manral = wrote:
>Hi Steve/ =0A= Karen,
>
>After the discussion with Brian (and checking = rfc2983), I =0A= think the
>following minor change can be added in section 5.1.2.1 = and =0A= 5.1.2.2, for
>the Inner Header at decapsulator: = -
>
>DSCP - =0A= constructed (9)
>
>9. If the DSCP values changes a diffserv = domain, =0A= the diffserv traffic
>conditioning SHOULD be done in order to = ensure that =0A= traffic exiting the
>node is compatible with the egress node's = diffserv =0A= domain.

So, what you are suggesting is that if the receiver is in = a =0A= different
diffserv domain, then it should change the DSCP value = apropos =0A= the
receiver's domain, right? How would this be done, in practice, =0A= e.g.,
would one require a table to map between the DSCP values for =0A= each
domain? I'm tempted to say this should be done outside the =0A= IPsec
context, by the receiver, so that this is not another =0A= IPsec
configuration item, e.g., part of the SPD.  We could  = insert =0A= a note
to that effect if folks agree.

>Regarding the ECN = part, I =0A= think I understand. The values ECT (0) and ECT
>(1) can be there = as is and =0A= CE is copied to make sure that in case of
>congestion it is = signaled to =0A= the endpoint. However this can lead to an
>intermediate router = changing =0A= the value maliciously to CE (but packets
>could as well have been = dropped =0A= by the intermediate router). I hope my
>understanding is right =0A= here?

The ECN value is copied from the outer header to the inner = header =0A= as
described in the text, based on analysis David Black did a few =0A= years
ago, and codified in RFC 2983. The notion is that a malicious =0A= router
could do other evil things to packets comparable to what it =0A= can
effect via changes to the ECN value, so it makes sense to copy = the
bit =0A= as directed, to support ECN =0A= functionality.

Steve

=0A= =0A= =0A= ------_=_NextPart_001_01C50882.0D712CFE-- --===============0918768839== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0918768839==-- From ipsec-bounces@ietf.org Tue Feb 1 19:05:09 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19151 for ; Tue, 1 Feb 2005 19:05:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw7yp-0006tw-VG; Tue, 01 Feb 2005 19:02:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cw7wc-0006YT-8p for ipsec@megatron.ietf.org; Tue, 01 Feb 2005 19:00:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18359 for ; Tue, 1 Feb 2005 19:00:27 -0500 (EST) From: annelies.van_moffaert@alcatel.be Received: from smail.alcatel.fr ([62.23.212.165]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cw8Ep-000509-NP for ipsec@ietf.org; Tue, 01 Feb 2005 19:19:22 -0500 Received: from bemail04.netfr.alcatel.fr (bemail04.netfr.alcatel.fr [155.132.251.33]) by smail.alcatel.fr (ALCANET/NETFR) with ESMTP id j1200NVw027996 for ; Wed, 2 Feb 2005 01:00:23 +0100 To: ipsec@ietf.org Message-ID: Date: Wed, 2 Feb 2005 01:00:21 +0100 X-MIMETrack: Serialize by Router on BEMAIL04/BE/ALCATEL(Release 5.0.11 |July 24, 2002) at 02/02/2005 01:00:22 MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii X-Alcanet-MTA-scanned-and-authorized: yes X-Spam-Score: 0.3 (/) X-Scan-Signature: 8ac499381112328dd60aea5b1ff596ea Subject: [Ipsec] Annelies VAN MOFFAERT/BE/ALCATEL is out of the office. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I will be out of the office starting 28/01/2005 and will not return until 05/02/2005. I will respond to your message when I return. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Feb 4 04:33:53 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA06190 for ; Fri, 4 Feb 2005 04:33:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cwzji-00009G-VD; Fri, 04 Feb 2005 04:26:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CwzhF-0007U4-GH for ipsec@megatron.ietf.org; Fri, 04 Feb 2005 04:24:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA05551 for ; Fri, 4 Feb 2005 04:24:11 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cwzzz-0002pJ-Cp for ipsec@ietf.org; Fri, 04 Feb 2005 04:43:36 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j149O8xM020113 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 4 Feb 2005 11:24:08 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j149O5KY020110; Fri, 4 Feb 2005 11:24:05 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16899.16181.122350.103944@fireball.kivinen.iki.fi> Date: Fri, 4 Feb 2005 11:24:05 +0200 From: Tero Kivinen To: "Vishwas Manral" Subject: RE: [Ipsec] Comments: draft-ietf-ipsec-ikev2-17.txt In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 23 min X-Total-Time: 67 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Vishwas Manral writes: > 2. Section 3.3.2 - Transform type Values > > Integrity Algorithm (INTEG) 3 (IKE, AH, optional in ESP) > > I think we can remove the "optional" in ESP part for Integrity > Algorithm. The ESP document states that: - No we CANNOT remove the optional. > " > - confidentiality-only (MAY be supported) > - integrity-only (MUST be supported) > - confidentiality and integrity (MUST be supported)" If you support the confidentiality-only (which is MAY) you MUST be able to negotiate it in the IKE, which means that integrity algorithm in ESP must be something optional, so that you can leave it out. > Besides NONE should not be used as the integrity algorithm in > Section 3.3.2? It would also make things clearer if it was stated > that when confidentiality service is not used we should use True the NONE integrity algorithm makes it little bit unclear what you want to do when negotiating the ESP without integrity, you have two choices: 1) Do not include integrity algorithm at all (as MUST be done in case of combined algoritms as said in section 3.3, but this cannot be used if you have other INTEG algorithms in your proposal) 2) Include integrity algorith NONE (in which case you can omit it if that is the only algorithm, as said in 3.3.3). The reason we need NONE there is that if initiator wants to propose AES + SHA1 or AES without integrity. The ENCR proposal will have AES, and the INTEG proposal will have AUTH_SHA1 and NONE. > 3. Section 3.3.3 change > > Protocol Mandatory Types Optional Types > IKE ENCR, PRF, INTEG, D-H > ESP ENCR INTEG, D-H, ESN > AH INTEG D-H, ESN > to > Protocol Mandatory Types Optional Types > IKE ENCR, PRF, INTEG, D-H > ESP INTEG, ENCR D-H, ESN <<== changed here > AH INTEG D-H, ESN Once again, we cannot make that change. > 4. Section 1.2 states: - > > "All but the headers of all the messages that follow are encrypted > and integrity protected." > > to be changed to > > "For all messages that follow, the message following the header is > encrypted and the message including the header is integrity > protected." That change would be ok. > 5. "In other words, if the responder stated its window size is N, > then when the initiator needs to make a request X, it MUST wait > until it has received responses to all requests up through request > X-N." This statement may not be true for X < N, if we are putting in > values we should specify the range properly. Otherwise it is good > enough to remove the part from the document itself. I do not think we have any problem here, and we cannot remove that text. I think it is obvious that all negative message ids ar outside of window. > 6. In Section 2.13 we talk about (K, S) but never specify what K or > S mean. Tero, mentioned they are inputs. I am not sure if we can > replace K and S with Y, Z. If yes, we can leave it as it is else we > need to specify what they mean. Why would we want to replace them with Y or Z? They are just letters, and any letter is ok there. The reason they are selected as K and S, is that the K is the input for the key, and S is probably specifying the string or something. > 8. We may want to state (obvious) that IKE message on port 4500, > MUST have the first 4 bytes as zero on receipt and should always > send the bytes as 0. Though Tero pointed out a quote from the draft, > it is clear that it does not specify how to treat received values. The UDP encapsulation rfc says what to do with the other values, as all other values than zero are processed as SPIs, which means that in normal case they will never even came to the IKE, as the IPsec processing in the kernel already processes them. > I am ok, posting errata if the text cannot be added in the current > version of the document (document being in the RFC-Editor). I do not think there is anything else to fix than the typo, and perhaps adding the clarification to section 1.2 about the coverage of the integrity. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Feb 4 05:47:04 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11680 for ; Fri, 4 Feb 2005 05:47:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx0wQ-000408-Es; Fri, 04 Feb 2005 05:43:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx0sI-0002kj-BX for ipsec@megatron.ietf.org; Fri, 04 Feb 2005 05:39:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA11135 for ; Fri, 4 Feb 2005 05:39:39 -0500 (EST) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx1B2-0004wu-Me for ipsec@ietf.org; Fri, 04 Feb 2005 05:59:05 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Comments: draft-ietf-ipsec-ikev2-17.txt Date: Fri, 4 Feb 2005 02:47:52 -0800 Message-ID: Thread-Topic: [Ipsec] Comments: draft-ietf-ipsec-ikev2-17.txt thread-index: AcUKnLPkY1uDMWU/R3OWbQSjQqhuwwACOkfQ From: "Vishwas Manral" To: "Tero Kivinen" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68ba2b07ef271dba6ee42a93832cfa4c Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Tero, Thanks for the detailed reply. If you think it all ok we can leave it here.=20 However I am still confused about why we talk about ECN and not DSCP. Also I still believe we should specify behavior more clearly about receiving messages on 4500(if it is specified in another RFC, do we need to write anything about the send itself, isn't sending specified in the UDP encapsulation?). On why K, S are used yet nowhere specified what they mean (while everything else is explained). On why we give " In other words, if the responder stated its window size is N, then when the initiator needs to make a request X, it MUST wait until it has received responses to all requests up through request X-N.", when it is self explanatory anyway, and if we give it why we do not define the ranges of things we talk about. Thanks again, Vishwas -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi]=20 Sent: Friday, February 04, 2005 2:54 PM To: Vishwas Manral Cc: ipsec@ietf.org Subject: RE: [Ipsec] Comments: draft-ietf-ipsec-ikev2-17.txt Vishwas Manral writes: > 2. Section 3.3.2 - Transform type Values >=20 > Integrity Algorithm (INTEG) 3 (IKE, AH, optional in ESP) >=20 > I think we can remove the "optional" in ESP part for Integrity > Algorithm. The ESP document states that: -=20 No we CANNOT remove the optional.=20 > " > - confidentiality-only (MAY be supported) > - integrity-only (MUST be supported) > - confidentiality and integrity (MUST be supported)" If you support the confidentiality-only (which is MAY) you MUST be able to negotiate it in the IKE, which means that integrity algorithm in ESP must be something optional, so that you can leave it out.=20 > Besides NONE should not be used as the integrity algorithm in > Section 3.3.2? It would also make things clearer if it was stated > that when confidentiality service is not used we should use True the NONE integrity algorithm makes it little bit unclear what you want to do when negotiating the ESP without integrity, you have two choices: 1) Do not include integrity algorithm at all (as MUST be done in case of combined algoritms as said in section 3.3, but this cannot be used if you have other INTEG algorithms in your proposal) 2) Include integrity algorith NONE (in which case you can omit it if that is the only algorithm, as said in 3.3.3). The reason we need NONE there is that if initiator wants to propose AES + SHA1 or AES without integrity. The ENCR proposal will have AES, and the INTEG proposal will have AUTH_SHA1 and NONE.=20 > 3. Section 3.3.3 change >=20 > Protocol Mandatory Types Optional Types > IKE ENCR, PRF, INTEG, D-H > ESP ENCR INTEG, D-H, ESN > AH INTEG D-H, ESN > to > Protocol Mandatory Types Optional Types > IKE ENCR, PRF, INTEG, D-H > ESP INTEG, ENCR D-H, ESN <<=3D=3D changed = here > AH INTEG D-H, ESN Once again, we cannot make that change. > 4. Section 1.2 states: - >=20 > "All but the headers of all the messages that follow are encrypted > and integrity protected."=20 >=20 > to be changed to >=20 > "For all messages that follow, the message following the header is > encrypted and the message including the header is integrity > protected." That change would be ok. > 5. "In other words, if the responder stated its window size is N, > then when the initiator needs to make a request X, it MUST wait > until it has received responses to all requests up through request > X-N." This statement may not be true for X < N, if we are putting in > values we should specify the range properly. Otherwise it is good > enough to remove the part from the document itself. I do not think we have any problem here, and we cannot remove that text. I think it is obvious that all negative message ids ar outside of window. > 6. In Section 2.13 we talk about (K, S) but never specify what K or > S mean. Tero, mentioned they are inputs. I am not sure if we can > replace K and S with Y, Z. If yes, we can leave it as it is else we > need to specify what they mean. Why would we want to replace them with Y or Z? They are just letters, and any letter is ok there. The reason they are selected as K and S, is that the K is the input for the key, and S is probably specifying the string or something. > 8. We may want to state (obvious) that IKE message on port 4500, > MUST have the first 4 bytes as zero on receipt and should always > send the bytes as 0. Though Tero pointed out a quote from the draft, > it is clear that it does not specify how to treat received values. The UDP encapsulation rfc says what to do with the other values, as all other values than zero are processed as SPIs, which means that in normal case they will never even came to the IKE, as the IPsec processing in the kernel already processes them.=20 > I am ok, posting errata if the text cannot be added in the current > version of the document (document being in the RFC-Editor). I do not think there is anything else to fix than the typo, and perhaps adding the clarification to section 1.2 about the coverage of the integrity. --=20 kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Feb 4 10:44:07 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07974 for ; Fri, 4 Feb 2005 10:44:07 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx5Sg-0001TT-3p; Fri, 04 Feb 2005 10:33:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx5OD-00083Z-8B for ipsec@megatron.ietf.org; Fri, 04 Feb 2005 10:28:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06589 for ; Fri, 4 Feb 2005 10:28:54 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx5h0-0004LC-9C for ipsec@ietf.org; Fri, 04 Feb 2005 10:48:23 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j14FSqRX023174 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 4 Feb 2005 17:28:53 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j14FSpkv023171; Fri, 4 Feb 2005 17:28:51 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16899.38067.523713.118835@fireball.kivinen.iki.fi> Date: Fri, 4 Feb 2005 17:28:51 +0200 From: Tero Kivinen To: "Vishwas Manral" Subject: RE: [Ipsec] Comments: draft-ietf-ipsec-ikev2-17.txt In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 12 min X-Total-Time: 11 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Vishwas Manral writes: > However I am still confused about why we talk about ECN and not DSCP. DSCP values are copied during the encapsulation, and they are not changed during the decapsulation, thus there is no need to do anything special there. The ECN values are similarly copied during the encapsulation, but in the decapsulation they are reconstructed based on the both inner and outer ECN values. The processing of the ECN has changed from the rfc2401 to RFC2401bis, and the RFC3168 describing ECN had a negotiation method how to negotiate that the ECN bits are processed like in rfc2401bis. The text we have about ECN in the IKEv2 draft simply says, that all SAs negotiated using IKEv2 must construct the ECN bits, i.e the negotiation of that feature is no longer needed. > Also I still believe we should specify behavior more clearly about > receiving messages on 4500(if it is specified in another RFC, do we need > to write anything about the send itself, isn't sending specified in the > UDP encapsulation?). UDP encapsulation is described in the RFC 3948, and we already have reference to that in few places. I do not think we need to say anything more about the issue, than simply say that IKE packets are prepended with 4 bytes of zero. > On why K, S are used yet nowhere specified what they mean (while > everything else is explained). As I said they are inputs to the function of prf+. I do not think they need to be explicitly specified as such, as it is obvious from the context. > On why we give " In > other words, if the responder stated its window size is N, then when the > initiator needs to make a request X, it MUST wait until it has received > responses to all requests up through request X-N.", when it is self > explanatory anyway, and if we give it why we do not define the ranges of > things we talk about. That text explains how the windows work in general. If we remove it then the text will be hard to understand. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Feb 4 12:41:51 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18392 for ; Fri, 4 Feb 2005 12:41:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx7PZ-0008Vh-Fs; Fri, 04 Feb 2005 12:38:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cx7Nd-0007Vb-Fs for ipsec@megatron.ietf.org; Fri, 04 Feb 2005 12:36:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17816 for ; Fri, 4 Feb 2005 12:36:26 -0500 (EST) Received: from 63-197-255-158.ded.pacbell.net ([63.197.255.158] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cx7gR-0007Qe-8A for ipsec@ietf.org; Fri, 04 Feb 2005 12:55:56 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ipsec] Comments: draft-ietf-ipsec-ikev2-17.txt Date: Fri, 4 Feb 2005 09:45:55 -0800 Message-ID: Thread-Topic: [Ipsec] Comments: draft-ietf-ipsec-ikev2-17.txt thread-index: AcUKz6fWgJ5gRNxZTdCKF05jmrPFgAAEDNel From: "Vishwas Manral" To: "Tero Kivinen" X-Spam-Score: 0.0 (/) X-Scan-Signature: 4ec3642ae9025e273a4a263d640f3300 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0441962908==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0441962908== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C50AE1.60B64BEA" This is a multi-part message in MIME format. ------_=_NextPart_001_01C50AE1.60B64BEA Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Tero, =20 This is the last mail on the subject from me. I am sorry about going on = and on, as they seem like obvious. =20 I am sorry, as we have been having a private discussion(maybe that is = the reason for the misunderstanding) and after some thought this is what = we have come to some point with the DSCP and ECN, you may want to take a = look at it. I am just sending you abstracts from the last mail sent in = the discussion and most of the text is by David Black.=20 =20 I am sorry about the (K, S) part too. I guess I was not clear here. If K = and S mean something they should be explained. can we instead use x(Y, = Z), x is the function and Y and Z the inputs as very obvious. I think = we need to specify it. =20 I am not sure how saying "An IKE endpoint MUST NOT exceed the peer's = stated window size for transmitted IKE requests. " is not obvious(and hence the long = explanation) and why stating something else is. =20 As I said RFC3948, specifies the sending as well as the receiving, I am = not sure why something about sending is respecified in the IKE draft, = but not receiving. =20 Thanks, Vishwas =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D The informational reference to 2983 is important. I think this may be better handled by paralleling the text in 5.1.2 about the DS field and covert channels: o IPsec offers certain controls to a security administrator to manage covert channels (which would not normally be a concern for tunneling) and to ensure that the receiver examines the right portions of the received packet re: application of access controls. An IPsec implementation MAY be configurable with regard to how it processes the outer DS field for tunnel mode for transmitted packets. For outbound traffic, one configuration setting for the outer DS field will operate as described in the following sections on IPv4 and IPv6 header processing for IPsec tunnels. Another will allow the outer DS field to be mapped to a fixed value, which MAY be configured on a per SA basis. (The value might really be fixed for all traffic outbound from a device, but per SA granularity allows that as well.) This configuration option allows a local administrator to decide whether the covert channel provided by copying these bits outweighs the benefits of copying. I would also expect Steve to object to Vishwas's proposed SHOULD. = Here's an attempt on my part - take the current bullet: o IPsec describes how to handle ECN or DS. and replace it with: o IPsec describes how to handle ECN or DS and provides the ability to control propagation of changes in these fields from = unprotected to protected domains. ECN is controlled so that only legitimate ECN changes (indicating occurrence of congestion between the = tunnel endpoints) are propagated. By default, DS propagation is not permitted. When the traffic management benefits of DS = propagation outweigh the security concerns, an IPsec implementation MAY be configurable with regard to how it processes the outer DS field for tunnel mode for received packets. For inbound traffic, one configuration setting for the outer DS field will discard it and use the inner DS field as described in the following sections on IPv4 and IPv6 header processing for IPsec tunnels. Another will copy the outer DS field to overwrite the inner DS field; this discard vs. overwrite behavior MAY be configured on a per SA = basis. (The behavior might really be fixed for all traffic inbound to a device, but per SA granularity allows that as well.) This configuration option allows a local administrator to decide whether the information propagation concerns raised by copying these bits outweigh the benefits of copying. See [RFC 2983] for further information on = when each of these behaviors may be useful, and also for the possible need for diffserv traffic conditioning prior or subsequent to = IPsec processing (including tunnel decapsulation).=20 While this is more text than adding a (9) note, I think the longer explanation is better, as it explains the security issues rather than hoping that the reader will correctly infer them. Leaving the tables as they are avoids security surprises when someone skims the RFC and just implements the tables. Since my proposed = "implementation MAY be configurable" text above is qualified by "When the traffic management benefits of DS propagation outweigh the security concerns" I think that "MAY" could be a "SHOULD" but I'm not going to insist on this change. ________________________________ From: Tero Kivinen [mailto:kivinen@iki.fi] Sent: Fri 2/4/2005 7:28 AM To: Vishwas Manral Cc: ipsec@ietf.org Subject: RE: [Ipsec] Comments: draft-ietf-ipsec-ikev2-17.txt Vishwas Manral writes: > However I am still confused about why we talk about ECN and not DSCP. DSCP values are copied during the encapsulation, and they are not changed during the decapsulation, thus there is no need to do anything special there. The ECN values are similarly copied during the encapsulation, but in the decapsulation they are reconstructed based on the both inner and outer ECN values. The processing of the ECN has changed from the rfc2401 to RFC2401bis, and the RFC3168 describing ECN had a negotiation method how to negotiate that the ECN bits are processed like in rfc2401bis. The text we have about ECN in the IKEv2 draft simply says, that all SAs negotiated using IKEv2 must construct the ECN bits, i.e the negotiation of that feature is no longer needed. > Also I still believe we should specify behavior more clearly about > receiving messages on 4500(if it is specified in another RFC, do we = need > to write anything about the send itself, isn't sending specified in = the > UDP encapsulation?). UDP encapsulation is described in the RFC 3948, and we already have reference to that in few places. I do not think we need to say anything more about the issue, than simply say that IKE packets are prepended with 4 bytes of zero. > On why K, S are used yet nowhere specified what they mean (while > everything else is explained). As I said they are inputs to the function of prf+. I do not think they need to be explicitly specified as such, as it is obvious from the context. > On why we give " In > other words, if the responder stated its window size is N, then when = the > initiator needs to make a request X, it MUST wait until it has = received > responses to all requests up through request X-N.", when it is self > explanatory anyway, and if we give it why we do not define the ranges = of > things we talk about. That text explains how the windows work in general. If we remove it then the text will be hard to understand. -- kivinen@safenet-inc.com ------_=_NextPart_001_01C50AE1.60B64BEA Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =0A= =0A= =0A= =0A= =0A= =0A= RE: [Ipsec] Comments: draft-ietf-ipsec-ikev2-17.txt=0A= =0A= =0A=
=0A=
Hi = Tero,
=0A=
 
=0A=
This is the last mail on the = subject from =0A= me. I am sorry about going on and on, as they seem like = obvious.
=0A=
 
=0A=
I am sorry, as we have been = having a =0A= private discussion(maybe that is the reason for the = misunderstanding) and =0A= after some thought this is what we have come to some point with the DSCP = and =0A= ECN, you may want to take a look at it. I am just =0A= sending you abstracts from the last mail sent in the discussion and most = of the =0A= text is by David Black.
=0A=
 
=0A=
I am sorry about the (K, S) = part too. I =0A= guess I was not clear here. If K and S mean something they should be = explained. =0A= can we instead use x(Y, Z),  x is the function and Y and Z the = inputs as =0A= very obvious. I think we need to specify it.
=0A=
 
=0A=
I am not sure how saying = "An =0A= IKE endpoint MUST NOT exceed the peer's stated window size = for
transmitted =0A= IKE requests. " is not obvious(and hence the long explanation) and = why =0A= stating something else is.
=0A=
 
=0A=
As I said RFC3948, specifies = the sending as =0A= well as the receiving, I am not sure why something about sending is = respecified =0A= in the IKE draft, but not receiving.
=0A=
 
=0A=
Thanks,
=0A=
Vishwas
=0A=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D<= /FONT>
=0A=
The informational reference to 2983 is =0A= important.  I think this may be
better handled by paralleling = the text =0A= in 5.1.2 about the DS field and
covert = channels:

    o =0A= IPsec offers certain controls to a security administrator =0A= to
      manage covert channels (which would = not =0A= normally be a concern for
      tunneling) = and to =0A= ensure that the receiver examines the = right
      =0A= portions of the received packet re: application of =0A= access
      controls. An IPsec = implementation MAY =0A= be configurable with regard
      to how it =0A= processes the outer DS field for tunnel mode =0A= for
      transmitted packets. For outbound = traffic, =0A= one configuration
      setting for the = outer DS =0A= field will operate as described in the
      =0A= following sections on IPv4 and IPv6 header processing for =0A= IPsec
      tunnels. Another will allow the = outer DS =0A= field to be mapped to a
      fixed value, = which MAY =0A= be configured on a per SA basis. (The = value
      =0A= might really be fixed for all traffic outbound from a device, =0A= but
      per SA granularity allows that as = well.) =0A= This configuration option
      allows a = local =0A= administrator to decide whether the covert =0A= channel
      provided by copying these bits =0A= outweighs the benefits of copying.

I would also expect Steve to = object to =0A= Vishwas's proposed SHOULD.  Here's
an attempt on my part - take = the =0A= current bullet:

    o IPsec describes how to = handle ECN or =0A= DS.

and replace it with:

    o IPsec = describes how =0A= to handle ECN or DS and provides the =0A= ability
        to control = propagation of =0A= changes in these fields from =0A= unprotected
        to protected =0A= domains.  ECN is controlled so that only =0A= legitimate
        ECN changes = (indicating =0A= occurrence of congestion between the =0A= tunnel
        endpoints) are =0A= propagated.  By default, DS propagation is =0A= not
        permitted.  When = the =0A= traffic management benefits of DS =0A= propagation
        outweigh the = security =0A= concerns, an IPsec implementation MAY =0A= be
        configurable with = regard to how =0A= it processes the outer DS = field
        =0A= for tunnel mode for received packets.  For inbound traffic, =0A= one
        configuration setting = for the =0A= outer DS field will discard it = and
        =0A= use the inner DS field as described in the following sections =0A= on
        IPv4 and IPv6 header = processing =0A= for IPsec tunnels. Another = will
        =0A= copy the outer DS field to overwrite the inner DS field; =0A= this
      discard vs. overwrite behavior = MAY be =0A= configured on a per SA basis.
      (The = behavior =0A= might really be fixed for all traffic inbound to =0A= a
        device, but per SA = granularity =0A= allows that as well.) =0A= This
configuration
        = option =0A= allows a local administrator to decide whether =0A= the
information
        = propagation =0A= concerns raised by copying these bits outweigh =0A= the
        benefits of = copying.  See =0A= [RFC 2983] for further information on =0A= when
        each of these = behaviors may =0A= be useful, and also for the =0A= possible
        need for diffserv = traffic =0A= conditioning prior or subsequent to =0A= IPsec
        processing = (including tunnel =0A= decapsulation). 

While this is more text than adding a (9) = note, I =0A= think the longer
explanation is better, as it explains the security = issues =0A= rather than
hoping that the reader will correctly infer = them.   =0A= Leaving the
tables as they are avoids security surprises when someone =0A= skims
the RFC and just implements the tables.  Since my proposed =0A= "implementation
MAY be configurable" text above is qualified by "When = the =0A= traffic
management benefits of DS propagation outweigh the =0A= security
concerns" I think that "MAY" could be a "SHOULD" but I'm not =0A= going
to insist on this change.

=0A=
=0A= From: Tero Kivinen =0A= [mailto:kivinen@iki.fi]
Sent: Fri 2/4/2005 7:28 = AM
To: =0A= Vishwas Manral
Cc: ipsec@ietf.org
Subject: RE: = [Ipsec] =0A= Comments: draft-ietf-ipsec-ikev2-17.txt

=0A=
=0A=

Vishwas Manral writes:
> However I am still = confused about =0A= why we talk about ECN and not DSCP.

DSCP values are copied during = the =0A= encapsulation, and they are not
changed during the decapsulation, = thus there =0A= is no need to do anything
special there.

The ECN values are = similarly =0A= copied during the encapsulation, but in
the decapsulation they are =0A= reconstructed based on the both inner and
outer ECN = values.

The =0A= processing of the ECN has changed from the rfc2401 to RFC2401bis,
and = the =0A= RFC3168 describing ECN had a negotiation method how to
negotiate that = the ECN =0A= bits are processed like in rfc2401bis. The text
we have about ECN in = the =0A= IKEv2 draft simply says, that all SAs
negotiated using IKEv2 must = construct =0A= the ECN bits, i.e the
negotiation of that feature is no longer =0A= needed.

> Also I still believe we should specify behavior more = clearly =0A= about
> receiving messages on 4500(if it is specified in another = RFC, do =0A= we need
> to write anything about the send itself, isn't sending = specified =0A= in the
> UDP encapsulation?).

UDP encapsulation is = described in the =0A= RFC 3948, and we already have
reference to that in few places. I do = not think =0A= we need to say
anything more about the issue, than simply say that = IKE =0A= packets are
prepended with 4 bytes of zero.

> On why K, S = are used =0A= yet nowhere specified what they mean (while
> everything else is =0A= explained).

As I said they are inputs to the function of prf+. I = do not =0A= think they
need to be explicitly specified as such, as it is obvious = from =0A= the
context.

> On why we give " In
> other words, if = the =0A= responder stated its window size is N, then when the
> initiator = needs to =0A= make a request X, it MUST wait until it has received
> responses = to all =0A= requests up through request X-N.", when it is self
> explanatory = anyway, =0A= and if we give it why we do not define the ranges of
> things we = talk =0A= about.

That text explains how the windows work in general. If we = remove =0A= it
then the text will be hard to =0A= understand.
--
kivinen@safenet-inc.com

=0A= =0A= =0A= ------_=_NextPart_001_01C50AE1.60B64BEA-- --===============0441962908== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0441962908==-- From ipsec-bounces@ietf.org Sat Feb 5 01:43:59 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19691 for ; Sat, 5 Feb 2005 01:43:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxJcT-0000Zt-Oa; Sat, 05 Feb 2005 01:40:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxJaz-00005R-Cs for ipsec@megatron.ietf.org; Sat, 05 Feb 2005 01:39:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19181 for ; Sat, 5 Feb 2005 01:39:03 -0500 (EST) From: support@thedotcomoffice.com Received: from lynx.loosefoot.com ([207.195.54.249]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxJtt-0008EQ-Bl for ipsec@ietf.org; Sat, 05 Feb 2005 01:58:38 -0500 Received: by lynx.loosefoot.com (Postfix, from userid 48) id 4AE9D8C0EE; Sat, 5 Feb 2005 00:35:36 -0600 (CST) Received: from 210.7.84.51 (SquirrelMail authenticated user support@thedotcomoffice.com) by 207.195.54.249 with HTTP; Sat, 5 Feb 2005 00:35:36 -0600 (CST) Message-ID: <1156.210.7.84.51.1107585336.squirrel@207.195.54.249> Date: Sat, 5 Feb 2005 00:35:36 -0600 (CST) To: ipsec@ietf.org User-Agent: SquirrelMail/1.4.4-rc1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Spam-Score: 1.1 (+) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 8bit Subject: [Ipsec] Help on IPsec and ICS X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 8bit Hi all, Can anybody help me on using ipsec on a Windows 2k machine running "internet connection sharing". Following is the environment: 1. ICS running running Win2k 2. Client machines have Win98 3. Ports 137, 138 and 139, 53(DNS), 67 & 68 (for DHCP) are open on ICS 4. Connection requests from client are not displayed on ICS amchine through netstat command. 5. When ipsec enabled, clients cant access internet 6. I need to know which ports need to be opened so clients can access internet. Please help Thanks Ashok Khurana _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sat Feb 5 07:42:22 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27054 for ; Sat, 5 Feb 2005 07:42:21 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxPDj-0006xY-8f; Sat, 05 Feb 2005 07:39:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CxPDc-0006px-JN for ipsec@megatron.ietf.org; Sat, 05 Feb 2005 07:39:20 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA26869 for ; Sat, 5 Feb 2005 07:39:18 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CxPWZ-0006lP-DF for ipsec@ietf.org; Sat, 05 Feb 2005 07:58:57 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j15CdEJ18085 for ; Sat, 5 Feb 2005 14:39:14 +0200 (EET) X-Scanned: Sat, 5 Feb 2005 14:39:09 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j15Cd9QV009030 for ; Sat, 5 Feb 2005 14:39:09 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00uFdThU; Sat, 05 Feb 2005 14:39:07 EET Received: from esebh002.NOE.Nokia.com (esebh002.ntc.nokia.com [172.21.138.77]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j15Cd6x12673 for ; Sat, 5 Feb 2005 14:39:06 +0200 (EET) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 5 Feb 2005 14:39:05 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Sat, 5 Feb 2005 14:39:06 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Sat, 5 Feb 2005 14:39:05 +0200 Message-ID: Thread-Topic: New I-D: IKEv2 Clarifications and Implementation Guidelines Thread-Index: AcULf60xGSlkV+XiTvqc2JTtQldAsQ== To: X-OriginalArrivalTime: 05 Feb 2005 12:39:06.0155 (UTC) FILETIME=[AE3777B0:01C50B7F] X-Spam-Score: 0.3 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] New I-D: IKEv2 Clarifications and Implementation Guidelines X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi, A new internet-draft, "IKEv2 Clarifications and Implementation=20 Guidelines" is now available from: http://www.ietf.org/internet-drafts/draft-eronen-ipsec-ikev2-clarificatio= ns-00.txt Abstract This document clarifies some areas of the IKEv2 specification that may be difficult to understand to developers not intimately familiar with the specification and its history. The intent is not to introduce any changes to the protocol, but rather to provide descriptions less prone to ambiguous interpretations, and thus encourage the development of interoperable implementations. Readers are advised that this document is work-in-progress, and may contain incorrect interpretations. Comments are most welcome! (This -00 version certainly contains=20 errors that are due to my misunderstanding of some details..) Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Feb 7 03:08:12 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03667 for ; Mon, 7 Feb 2005 03:08:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cy3sy-00014m-0O; Mon, 07 Feb 2005 03:04:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cy3qu-0000sZ-Rk for ipsec@megatron.ietf.org; Mon, 07 Feb 2005 03:02:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA03241 for ; Mon, 7 Feb 2005 03:02:34 -0500 (EST) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cy4AD-0001Sr-8G for ipsec@ietf.org; Mon, 07 Feb 2005 03:22:33 -0500 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id j1781fk02470; Mon, 7 Feb 2005 10:01:41 +0200 (IST) Mime-Version: 1.0 (Apple Message framework v619) In-Reply-To: References: Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <80809712-78DE-11D9-AF15-000A95834BAA@checkpoint.com> Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] New I-D: IKEv2 Clarifications and Implementation Guidelines Date: Mon, 7 Feb 2005 10:01:41 +0200 To: Pasi.Eronen@nokia.com, " " X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Content-Transfer-Encoding: 7bit X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Some comments: 1. I think I can offer another reason for the existence of REKEY_SA. Although IPsec works on single packets, many implementations have a concept of a "connection" which is well-defined for TCP, and less so for UDP or ICMP. Such implementations associate each connection with an SA used to implement it. The REKEY_SA notification serves to tell these implementations that all the connections associated with one SA are moving to another SA, which is better than just deleting the SA and having them search the SAD for a suitable SA. 2. In section 2.9 you have: 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). It's too bad that IKEv2 requires you to create new child SAs for repeated authentication. It would be nice if the new IKE_SA could inherit the old child SAs just like the rekeyed IKE_SA can. I'm wondering whether I should include this ability in my draft. Barring that, I think it's an obvious idea for IKE peers, even in remote access to establish child SAs only as needed. It makes sense to do the reauthentication by just creating a new IKE_SA and then deleting the old IKE_SA. Unfortunately IKEv2 does not allow creating just an IKE_SA so there will be at least one child SA left, but all the other child SAs will be deleted. Since we assume that both peers can establish child SAs as needed, this is not a problem. I think there should be text that says that deleting an IKE_SA when a new IKE_SA exists should not be taken as an intent to disconnect existing connections. 3. Regarding section 3.3 (SUBNET) there can be another use of this specification. Suppose the server's reply is as follows: CP(CFG_REPLY) = INTERNAL_IP4_ADDRESS(192.0.1.234) INTERNAL_IP4_SUBNET(192.0.1.0/255.255.255.192) INTERNAL_IP4_SUBNET(192.0.2.0/255.255.255.0) TSi = (0, 0-65536, 0.0.0.0-255.255.255.255) TSr = (0, 0-65536, 0.0.0.0-255.255.255.255) This means that this SA can be used for any traffic, but only the two subnets are actually protected by the device. The client may send all its Internet traffic through the gateway or it may send only the things protected by the device. 4. Section 3.4. A subnet mask has a meaning in addition to being able to use layer 2. It also says which addresses will receive a broadcast. For example, if the client receives: CP(CFG_REPLY) = INTERNAL_IP4_ADDRESS(192.0.1.234) INTERNAL_IP4_NETMASK(255.255.255.0) This may indicate that if the client sends an encrypted packet to 192.0.1.255, the edge device will decrypt it, and then re-encrypt it will all existing tunnels with assigned IPs in the 192.0.1.x range, so that they all receive it. I don't know of any implementation that actually does this, and barring that it really does not make sense to have this attribute at all. 5. I'm missing some discussion of hash-and-URL. AFAIK this is something that hasn't been done in an RFC before. It should be noted that the infrastructure for storing Certs on servers is not yet in place, and is outside the scope of IKEv2. Should the cert be on the gateway? Should it be on the CA? On the CRL server? New type of server? There's also a work in progress to define push certificates. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Feb 7 10:40:08 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09822 for ; Mon, 7 Feb 2005 10:40:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyAwJ-0007wi-17; Mon, 07 Feb 2005 10:36:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyAsE-0006kr-MI for ipsec@megatron.ietf.org; Mon, 07 Feb 2005 10:32:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08507 for ; Mon, 7 Feb 2005 10:32:21 -0500 (EST) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyBBb-0002yr-1W for ipsec@ietf.org; Mon, 07 Feb 2005 10:52:28 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.2/8.13.2/Debian-1) with ESMTP id j17FWJwa024138 for ; Mon, 7 Feb 2005 17:32:19 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.2/8.13.2/Submit) id j17FWJxv024135; Mon, 7 Feb 2005 17:32:19 +0200 Date: Mon, 7 Feb 2005 17:32:19 +0200 Message-Id: <200502071532.j17FWJxv024135@burp.tkv.asdf.org> From: Markku Savela To: ipsec@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Subject: [Ipsec] Question about "narrowing" ... X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Is narrowing "well defined"? How to prevent "insane" narrowing or how to deal with it, if and when it happens? Consider a policy (assume "any" for things not specifically listed, and the packet specific "ts" included) remote 10.0.0.0/8 -> protect and packet remote=10.0.1.1 port=80 This will cause me to request for SA with SA1: remote 10.0.0.0 - 10.255.255.255 The other side can "narrow" it down to SA1: remote 10.0.1.0 - 10.0.1.255 Then, another packet remote=10.0.2.2 port=80 does not match the narrowed SA1, so I request again SA2: remote 10.0.0.0/8 this time the other end decides to narrow it with port range and returns SA2: remote 10.0.0.0 - 10.255.255.255 port= 1-100 Now I suddenly have two possible choices to use for the original packet, or other new packets like remote=10.0.1.2 port=90 Both SA1 and SA2 could be used for this. The questions arise... - should this be detected as error condition? - should I just pick either SA1 or SA2 randomly? - should there be some deterministic rule to pick between SA1 and SA2? Above are not trivial, because TS contains remote/local address, remote/local port and protocol. Insane narrowing can happen in "devious" ways and combinations, and finding some sensible algorithms is not obvious to me. One solution is of course: - scrap the narrowing concept. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Feb 7 17:42:01 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07934 for ; Mon, 7 Feb 2005 17:42:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyHWb-00044Y-Ao; Mon, 07 Feb 2005 17:38:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyHJA-0007SG-EM for ipsec@megatron.ietf.org; Mon, 07 Feb 2005 17:24:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06365 for ; Mon, 7 Feb 2005 17:24:37 -0500 (EST) Received: from ns.ca.certicom.com ([66.48.18.197] helo=mail.ca.certicom.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CyHcc-0001ln-8S for ipsec@ietf.org; Mon, 07 Feb 2005 17:44:47 -0500 Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id C89D710084 for ; Mon, 7 Feb 2005 17:23:57 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 29194-18 for ; Mon, 7 Feb 2005 17:23:46 -0500 (EST) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 1A4A51007D for ; Mon, 7 Feb 2005 17:23:46 -0500 (EST) To: ipsec@ietf.org X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Tom Stiemerling Date: Mon, 7 Feb 2005 17:14:42 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 02/07/2005 05:14:39 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: Eugene Chin Subject: [Ipsec] How to do authentication with EAP X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Can anybody provide clarification on this issue? Section 2.16 of IKEv2 draft 17 states: For EAP methods that create a shared key as a side effect of authentication, that shared key MUST be used by both the initiator and responder to generate AUTH payloads in messages 5 and 6 using the syntax for shared secrets specified in section 2.15. The shared key from EAP is the field from the EAP specification named MSK. The shared key generated during an IKE exchange MUST NOT be used for any other purpose. Should this not read messages 7 and 8 (as below)? Also how is the AUTH processing to be done? What are you meant to do with the MSK? EAP methods that do not establish a shared key SHOULD NOT be used, as they are subject to a number of man-in-the-middle attacks [EAPMITM] if these EAP methods are used in other protocols that do not use a server-authenticated tunnel. Please see the Security Considerations section for more details. If EAP methods that do not generate a shared key are used, the AUTH payloads in messages 7 and 8 MUST be generated using SK_pi and SK_pr respectively. This would appear to be the case if using EAP-CHAP (MD5 password). In this case how are SK_pi and SK_pr meant to be used in AUTH processing? The draft seems to be very vague about these points... Thanks, Tom _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Feb 7 20:48:07 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26595 for ; Mon, 7 Feb 2005 20:48:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyKRf-0005Mv-DE; Mon, 07 Feb 2005 20:45:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyKQf-0005CZ-Tw for ipsec@megatron.ietf.org; Mon, 07 Feb 2005 20:44:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA26451 for ; Mon, 7 Feb 2005 20:44:35 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyKkA-0006ps-9g for ipsec@ietf.org; Mon, 07 Feb 2005 21:04:47 -0500 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j181iPgx004655; Mon, 7 Feb 2005 17:44:25 -0800 (PST) Received: from thunk (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j181iOOp021955; Mon, 7 Feb 2005 20:44:25 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j181iOCo021383; Mon, 7 Feb 2005 20:44:24 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j181iOBZ021382; Mon, 7 Feb 2005 20:44:24 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: [Ipsec] Question about "narrowing" ... From: Bill Sommerfeld To: Markku Savela In-Reply-To: <200502071532.j17FWJxv024135@burp.tkv.asdf.org> References: <200502071532.j17FWJxv024135@burp.tkv.asdf.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1107827064.19442.196.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Mon, 07 Feb 2005 20:44:24 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit On Mon, 2005-02-07 at 10:32, Markku Savela wrote: > - should this be detected as error condition? No. > - should I just pick either SA1 or SA2 randomly? Yes. From your point of view, they're equivalent. >From the peer's point of view, they're equivalent. Treat it just like any other case of multiple SA's matching the packet. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 8 04:17:23 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA18030 for ; Tue, 8 Feb 2005 04:17:23 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyRRI-00054m-OX; Tue, 08 Feb 2005 04:13:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyRNW-0004Me-SG for ipsec@megatron.ietf.org; Tue, 08 Feb 2005 04:09:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA17606 for ; Tue, 8 Feb 2005 04:09:46 -0500 (EST) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyRh2-0007Aj-MW for ipsec@ietf.org; Tue, 08 Feb 2005 04:30:02 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.2/8.13.2/Debian-1) with ESMTP id j1899i1h006817 for ; Tue, 8 Feb 2005 11:09:44 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.2/8.13.2/Submit) id j1899ieU006814; Tue, 8 Feb 2005 11:09:44 +0200 Date: Tue, 8 Feb 2005 11:09:44 +0200 Message-Id: <200502080909.j1899ieU006814@burp.tkv.asdf.org> From: Markku Savela To: ipsec@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Subject: [Ipsec] 2401bis decorrelation X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org The 2401bis gives an decorrelation algorithm in appendix B. A policy (abrev. "p" = remote port, "a" = remote address) as follows: C1: p = 80 -> A1 C2: a= 10/8 -> A2 Should decorrelate into (as far as I can see) U1: p = 80, a = 10/8 -> A1 U2: p != 80, a = 10/8 -> A2 U3: p = 80, a != 10/8 -> A1 However, the algorithm starts with "put C1 into U", resulting U1: p = 80, a = ANY -> A1 Does the algorithm mean, that when forming the set T, they are removed from the set U? Otherwise, I cannot see it ending up with right result. Just as example, another policy, with selector order reversed C1: a= 10/8 -> A2 C2: p = 80 -> A1 should decorrelate into U1: p = 80, a = 10/8 -> A2 U2: p != 80, a = 10/8 -> A2 U3: p = 80, a != 10/8 -> A1 right? _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 8 05:20:22 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22547 for ; Tue, 8 Feb 2005 05:20:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CySOM-0006Uj-32; Tue, 08 Feb 2005 05:14:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CySN0-00016W-CL for ipsec@megatron.ietf.org; Tue, 08 Feb 2005 05:13:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA22159 for ; Tue, 8 Feb 2005 05:13:20 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CySgZ-00007o-3D for ipsec@ietf.org; Tue, 08 Feb 2005 05:33:36 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j18AD78V029791 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 8 Feb 2005 12:13:08 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j18AD7Pi029788; Tue, 8 Feb 2005 12:13:07 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16904.37043.173602.79888@fireball.kivinen.iki.fi> Date: Tue, 8 Feb 2005 12:13:07 +0200 From: Tero Kivinen To: Markku Savela Subject: [Ipsec] Question about "narrowing" ... In-Reply-To: <200502071532.j17FWJxv024135@burp.tkv.asdf.org> References: <200502071532.j17FWJxv024135@burp.tkv.asdf.org> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 14 min X-Total-Time: 37 min 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 Content-Transfer-Encoding: 7bit Markku Savela writes: > Is narrowing "well defined"? I think it is. > How to prevent "insane" narrowing or how to deal with it, if and > when it happens? They are not insane they are allowed by policy. > Now I suddenly have two possible choices to use for the original > packet, or other new packets like Yes, and the problem being? > Both SA1 and SA2 could be used for this. The questions arise... > > - should this be detected as error condition? No. It is completely valid to create overlapping SAs in the rfc2401bis architecture. They can be used do QoS and other things. > - should I just pick either SA1 or SA2 randomly? You can select one randomly, or you can use some more complicated method. > - should there be some deterministic rule to pick between SA1 and SA2? Probably, but other responder does not care which you use, so it is completely your internal matter what do you use to select SA. You can use QoS parameter, phase of moon, last bit of the crc of the packet or whatever. > Above are not trivial, because TS contains remote/local address, > remote/local port and protocol. Insane narrowing can happen in > "devious" ways and combinations, and finding some sensible algorithms > is not obvious to me. One solution is of course: > > - scrap the narrowing concept. I do not think that is an option. Anyways, I do not expect implementations to create such SAs unless they have some proper reason for that from their policy. Note, that in IKEv2 there is explicitly allowed to have multiple overlapping SAs, and create child sa is never a rekey unless specified as such by using notify. This means that there is never any reason to assume that some traffic should move to another SA based on the new IPsec SAs being created, only when there is a rekey. When you have overlapping SAs you must accept traffic from all of them, and you can use whatever method to select which one of them to use when sending. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 8 06:05:18 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27069 for ; Tue, 8 Feb 2005 06:05:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyT2k-00074q-Tf; Tue, 08 Feb 2005 05:56:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CySta-0005mB-DU for ipsec@megatron.ietf.org; Tue, 08 Feb 2005 05:47:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA24512 for ; Tue, 8 Feb 2005 05:47:00 -0500 (EST) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyTD9-0000ox-F1 for ipsec@ietf.org; Tue, 08 Feb 2005 06:07:17 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.2/8.13.2/Debian-1) with ESMTP id j18AkxnO007731; Tue, 8 Feb 2005 12:46:59 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.2/8.13.2/Submit) id j18Akx9d007728; Tue, 8 Feb 2005 12:46:59 +0200 Date: Tue, 8 Feb 2005 12:46:59 +0200 Message-Id: <200502081046.j18Akx9d007728@burp.tkv.asdf.org> From: Markku Savela To: kivinen@iki.fi In-reply-to: <16904.37043.173602.79888@fireball.kivinen.iki.fi> (message from Tero Kivinen on Tue, 8 Feb 2005 12:13:07 +0200) Subject: Re: [Ipsec] Question about "narrowing" ... References: <200502071532.j17FWJxv024135@burp.tkv.asdf.org> <16904.37043.173602.79888@fireball.kivinen.iki.fi> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > From: Tero Kivinen > No. It is completely valid to create overlapping SAs in the rfc2401bis > architecture. They can be used do QoS and other things. > > > - should I just pick either SA1 or SA2 randomly? > > You can select one randomly, or you can use some more complicated > method. Node A has policy: C1: remote 10/8 -> A1 Node B has policy C1: local port = 80 -> A1 C2: local 10/8 -> A1 (with the idea, that two SA's are used, one for port =80, and another for the rest). Now, if Node A can pick SA randomly (for example packet "remote=10.0.0.1, port=80" would match both narrowed selectors), then the whole point of narrowing has been lost. Why do it at all? [Rhetorical question] With my question, I only wanted to clarify, that it is the responsibily of the "narrower" to do the right thing. A offers: remote=10/8,port=any (packet: port=80,remote= 10.0.0.1) How is this narrowed down, so that B's policy is followed in A? Or is this impossible? _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 8 06:57:24 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01057 for ; Tue, 8 Feb 2005 06:57:24 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyTx7-0003G5-Mf; Tue, 08 Feb 2005 06:54:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyTve-0002yk-0O for ipsec@megatron.ietf.org; Tue, 08 Feb 2005 06:53:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA00854 for ; Tue, 8 Feb 2005 06:53:11 -0500 (EST) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyUFD-0002HW-Kw for ipsec@ietf.org; Tue, 08 Feb 2005 07:13:29 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.2/8.13.2/Debian-1) with ESMTP id j18BrAKu008605 for ; Tue, 8 Feb 2005 13:53:10 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.2/8.13.2/Submit) id j18BrACg008602; Tue, 8 Feb 2005 13:53:10 +0200 Date: Tue, 8 Feb 2005 13:53:10 +0200 Message-Id: <200502081153.j18BrACg008602@burp.tkv.asdf.org> From: Markku Savela To: ipsec@ietf.org In-reply-to: <200502080909.j1899ieU006814@burp.tkv.asdf.org> (message from Markku Savela on Tue, 8 Feb 2005 11:09:44 +0200) Subject: Re: [Ipsec] 2401bis decorrelation References: <200502080909.j1899ieU006814@burp.tkv.asdf.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Never mind, I was confused somehow (maybe still am, but...), I guess it works.. > The 2401bis gives an decorrelation algorithm in appendix B. > > A policy (abrev. "p" = remote port, "a" = remote address) as follows: > > C1: p = 80 -> A1 > C2: a= 10/8 -> A2 > > Should decorrelate into (as far as I can see) > > U1: p = 80, a = 10/8 -> A1 > U2: p != 80, a = 10/8 -> A2 > U3: p = 80, a != 10/8 -> A1 > > However, the algorithm starts with "put C1 into U", resulting > > U1: p = 80, a = ANY -> A1 The correct decorrelated is U1: p = 80, a = ANY -> A1 U2: p != 80, a = 10/8 -> A2 and for case C1: a= 10/8 -> A2 C2: p = 80 -> A1 it is U1: p = ANY, a = 10/8 -> A2 U2: p = 80, a != 10/8 -> A1 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 8 07:08:08 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01992 for ; Tue, 8 Feb 2005 07:08:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyU6u-00057J-8H; Tue, 08 Feb 2005 07:04:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyU5N-0004q1-9s for ipsec@megatron.ietf.org; Tue, 08 Feb 2005 07:03:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA01553 for ; Tue, 8 Feb 2005 07:03:14 -0500 (EST) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyUOx-0002VL-0X for ipsec@ietf.org; Tue, 08 Feb 2005 07:23:32 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.2/8.13.2/Debian-1) with ESMTP id j18C3EtI009335; Tue, 8 Feb 2005 14:03:14 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.2/8.13.2/Submit) id j18C3Ehh009332; Tue, 8 Feb 2005 14:03:14 +0200 Date: Tue, 8 Feb 2005 14:03:14 +0200 Message-Id: <200502081203.j18C3Ehh009332@burp.tkv.asdf.org> From: Markku Savela To: kivinen@iki.fi In-reply-to: <200502081046.j18Akx9d007728@burp.tkv.asdf.org> (message from Markku Savela on Tue, 8 Feb 2005 12:46:59 +0200) Subject: Re: [Ipsec] Question about "narrowing" ... References: <200502071532.j17FWJxv024135@burp.tkv.asdf.org> <16904.37043.173602.79888@fireball.kivinen.iki.fi> <200502081046.j18Akx9d007728@burp.tkv.asdf.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 Ok, I will answer my own question... sorry about confusion :-) > From: Markku Savela > Node A has policy: > C1: remote 10/8 -> A1 > > Node B has policy > C1: local port = 80 -> A1 > C2: local 10/8 -> A1 > .. > A offers: remote=10/8,port=any (packet: port=80,remote= 10.0.0.1) > > How is this narrowed down, so that B's policy is followed in A? Or is > this impossible? narrowed to "remote=10/8, port=80" and another A offers: remote=10/8,port=any (packet: port=100,remote= 10.0.0.1) then this is narrowed into remote=10/8, port != 80 => if you do narrowing, you have to use decorrelated policy in the narrowing process? _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 8 07:17:25 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02800 for ; Tue, 8 Feb 2005 07:17:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyUHf-000783-Ho; Tue, 08 Feb 2005 07:15:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyUEc-0006Zh-Lr for ipsec@megatron.ietf.org; Tue, 08 Feb 2005 07:12:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02520 for ; Tue, 8 Feb 2005 07:12:48 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyUYD-0002mE-FZ for ipsec@ietf.org; Tue, 08 Feb 2005 07:33:06 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j18CCjI0001572 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 8 Feb 2005 14:12:46 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j18CCjeV001569; Tue, 8 Feb 2005 14:12:45 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16904.44221.224483.181226@fireball.kivinen.iki.fi> Date: Tue, 8 Feb 2005 14:12:45 +0200 From: Tero Kivinen To: Tom Stiemerling Subject: [Ipsec] How to do authentication with EAP In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 5 min X-Total-Time: 11 min X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Eugene Chin X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Tom Stiemerling writes: > Can anybody provide clarification on this issue? > > Section 2.16 of IKEv2 draft 17 states: > > For EAP methods that create a shared key as a side effect of > authentication, that shared key MUST be used by both the initiator > and responder to generate AUTH payloads in messages 5 and 6 using the > syntax for shared secrets specified in section 2.15. The shared key > from EAP is the field from the EAP specification named MSK. The > shared key generated during an IKE exchange MUST NOT be used for any > other purpose. > > Should this not read messages 7 and 8 (as below)? Yes. > Also how is the AUTH processing to be done? What are you meant to do > with the MSK? You use it as specified in the 2.15, i.e. calculate AUTH but instead of the shared secret from the configuration you use MSK. > EAP methods that do not establish a shared key SHOULD NOT be used, as > they are subject to a number of man-in-the-middle attacks [EAPMITM] > if these EAP methods are used in other protocols that do not use a > server-authenticated tunnel. Please see the Security Considerations > section for more details. If EAP methods that do not generate a > shared key are used, the AUTH payloads in messages 7 and 8 MUST be > generated using SK_pi and SK_pr respectively. > > This would appear to be the case if using EAP-CHAP (MD5 password). So you should not use such metehod :-) > In this case how are SK_pi and SK_pr meant to be used in AUTH > processing? Instead of MSK use the SK_pi in the initiator end and SK_pr in the responder end in place of shared secret. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 8 07:33:51 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03973 for ; Tue, 8 Feb 2005 07:33:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyUS9-0001DY-0W; Tue, 08 Feb 2005 07:26:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyUN4-0008UD-GX for ipsec@megatron.ietf.org; Tue, 08 Feb 2005 07:21:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03165 for ; Tue, 8 Feb 2005 07:21:31 -0500 (EST) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyUgf-0002wd-AQ for ipsec@ietf.org; Tue, 08 Feb 2005 07:41:49 -0500 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id j18CKe405137; Tue, 8 Feb 2005 14:20:41 +0200 (IST) In-Reply-To: <200502081046.j18Akx9d007728@burp.tkv.asdf.org> References: <200502071532.j17FWJxv024135@burp.tkv.asdf.org> <16904.37043.173602.79888@fireball.kivinen.iki.fi> <200502081046.j18Akx9d007728@burp.tkv.asdf.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] Question about "narrowing" ... Date: Tue, 8 Feb 2005 14:20:38 +0200 To: Markku Savela X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 73734d43604d52d23b3eba644a169745 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com, Tero Kivinen X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit The traffic selector can be narrowed down to include only port 80. I fear that the case you describe below is one of a configuration mismatch. When Node A asks for 10.0.0.0/8, how can Node B know whether the matching SA is C1 or C2? It might pick one at random (say C1), and then, assuming that Node A wanted to send FTP, then it's now stuck with a useless SA. If A tries the same thing again, there's no reason to assume that B chooses differently this time. The only way out is for A to request 10.0.0.0(port=21). But now B answers with a narrow SA, and we are stuck with creating a different SA for each port. Now, let's suppose that node B originally did reply, but according to C2. Then it would answer with two traffic selectors: one for ports 0-79, the other for ports 81-65536. This is kind of kludgy, but it would allow A to know that it still has no SA for port 80. If it ever needs one, it can always negotiate another SA for port 80. I suggest that a good heuristic would be as follows: - Responders should reply with the broadest possible SA included in the request. - Initiators should be ready to initiate new Create_child_SA exchanges to get at the narrow SA that they actually want. Suppose our initiator is an endpoint, that its address is 192.0.1.17, and that the packet that triggered the SA creation is 192.0.1.17:3333-->10.0.0.1:80. Because all it has is its C1 rule, it will offer: 192.0.1.17(0-65536) <--> 10.0.0.0/24(0-65536) On node B this more closely matches C2, so node B responds like this: 192.0.1.17(0-65536) <--> 10.0.0.0/24(0-79,81-65536) Node A is missing an SA that actually matches its packet, so it creates a new exchange, this time with: 192.0.1.17(3333) <--> 10.0.0.1(80) Which will be accepted. Note that the need to do this heuristic is only if there is a policy mismatch. Perhaps the implementation guideline draft can include something like this heuristic. On Feb 8, 2005, at 12:46 PM, Markku Savela wrote: > >> From: Tero Kivinen > >> No. It is completely valid to create overlapping SAs in the rfc2401bis >> architecture. They can be used do QoS and other things. >> >>> - should I just pick either SA1 or SA2 randomly? >> >> You can select one randomly, or you can use some more complicated >> method. > > Node A has policy: > C1: remote 10/8 -> A1 > > Node B has policy > C1: local port = 80 -> A1 > C2: local 10/8 -> A1 > > (with the idea, that two SA's are used, one for port =80, and another > for the rest). > > Now, if Node A can pick SA randomly (for example packet > "remote=10.0.0.1, port=80" would match both narrowed selectors), then > the whole point of narrowing has been lost. Why do it at all? > [Rhetorical question] > > With my question, I only wanted to clarify, that it is the > responsibily of the "narrower" to do the right thing. > > A offers: remote=10/8,port=any (packet: port=80,remote= 10.0.0.1) > > How is this narrowed down, so that B's policy is followed in A? Or is > this impossible? > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 8 07:59:52 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05543 for ; Tue, 8 Feb 2005 07:59:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyUwN-00060z-Fl; Tue, 08 Feb 2005 07:58:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyUpC-0005G1-5o for ipsec@megatron.ietf.org; Tue, 08 Feb 2005 07:50:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05134 for ; Tue, 8 Feb 2005 07:50:37 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyV8n-0003dn-E7 for ipsec@ietf.org; Tue, 08 Feb 2005 08:10:53 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j18CoZkq002058 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 8 Feb 2005 14:50:35 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j18CoZk4002055; Tue, 8 Feb 2005 14:50:35 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16904.46490.990547.717595@fireball.kivinen.iki.fi> Date: Tue, 8 Feb 2005 14:50:34 +0200 From: Tero Kivinen To: Markku Savela Subject: Re: [Ipsec] Question about "narrowing" ... In-Reply-To: <200502081203.j18C3Ehh009332@burp.tkv.asdf.org> References: <200502071532.j17FWJxv024135@burp.tkv.asdf.org> <16904.37043.173602.79888@fireball.kivinen.iki.fi> <200502081046.j18Akx9d007728@burp.tkv.asdf.org> <200502081203.j18C3Ehh009332@burp.tkv.asdf.org> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 3 min X-Total-Time: 6 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Markku Savela writes: > => if you do narrowing, you have to use decorrelated policy > in the narrowing process? Yes. And also when you are proposing traffic selectors to the other end you should send decorrelated policy, as otherwise the responder can select something to the SA which are not allowed by your policy. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 8 08:04:19 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA05978 for ; Tue, 8 Feb 2005 08:04:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyUww-0006F2-0K; Tue, 08 Feb 2005 07:58:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyUrN-0005Ya-Jg for ipsec@megatron.ietf.org; Tue, 08 Feb 2005 07:52:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05225 for ; Tue, 8 Feb 2005 07:52:52 -0500 (EST) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyVAx-0003gW-Pz for ipsec@ietf.org; Tue, 08 Feb 2005 08:13:09 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.2/8.13.2/Debian-1) with ESMTP id j18Cqot0009458 for ; Tue, 8 Feb 2005 14:52:50 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.2/8.13.2/Submit) id j18Cqoj8009455; Tue, 8 Feb 2005 14:52:50 +0200 Date: Tue, 8 Feb 2005 14:52:50 +0200 Message-Id: <200502081252.j18Cqoj8009455@burp.tkv.asdf.org> From: Markku Savela To: ipsec@ietf.org In-reply-to: <200502081046.j18Akx9d007728@burp.tkv.asdf.org> (message from Markku Savela on Tue, 8 Feb 2005 12:46:59 +0200) Subject: Re: [Ipsec] Question about "narrowing" ... References: <200502071532.j17FWJxv024135@burp.tkv.asdf.org> <16904.37043.173602.79888@fireball.kivinen.iki.fi> <200502081046.j18Akx9d007728@burp.tkv.asdf.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org One more silly question... I wrote > Node A has policy: > C1: remote 10/8 -> A1 > > Node B has policy > C1: local port = 80 -> A1 > C2: local 10/8 -> A1 ...and it works fine if A is the initiator, and B is doing the narrowing using decorrelated policy. But, what about other way? Assume B is the initiator, and is *NOT* using decorrelated policy (decorrelation is not mandated by 2401bis). B offers: local ANY, local port=80 (packet: local=10.0.0.1, local port=80) A replies? local 10/8, local port=80 B offers: local 10/8, local port=ANY (packet: local=10.0.0.1, local port=100) A replies local 10/8, local port=ANY Now, as far as A is concerned, for a packet "remote=10.0.0.1, remote port=80", both SA's are valid, and it can use either one. But, B's policy will drop port=80 packets, if not sent with the port specific SA. There would be no problem, if both A and B had matching policies. The conclusion here: either policies must match exactly so that narrowing never occurs, or if policies are not quite matching as in above, BOTH sides must be using decorrelated policies and reflect this in already in their offers? Seems that IKEv2 would need to know whether other side is using decorrelated policies or not? Remember: decorrelation is not mandatory by 2401bis! _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 8 08:06:58 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06216 for ; Tue, 8 Feb 2005 08:06:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyUwz-0006GX-S9; Tue, 08 Feb 2005 07:58:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyUt9-0005hS-Ic for ipsec@megatron.ietf.org; Tue, 08 Feb 2005 07:54:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05318 for ; Tue, 8 Feb 2005 07:54:42 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyVCk-0003jD-Td for ipsec@ietf.org; Tue, 08 Feb 2005 08:14:59 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j18Csa8e002103 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Tue, 8 Feb 2005 14:54:36 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j18CsajM002100; Tue, 8 Feb 2005 14:54:36 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16904.46732.50421.177583@fireball.kivinen.iki.fi> Date: Tue, 8 Feb 2005 14:54:36 +0200 From: Tero Kivinen To: Yoav Nir Subject: Re: [Ipsec] Question about "narrowing" ... In-Reply-To: References: <200502071532.j17FWJxv024135@burp.tkv.asdf.org> <16904.37043.173602.79888@fireball.kivinen.iki.fi> <200502081046.j18Akx9d007728@burp.tkv.asdf.org> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 2 min X-Total-Time: 1 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Yoav Nir writes: > I suggest that a good heuristic would be as follows: > - Responders should reply with the broadest possible SA included in the > request. > - Initiators should be ready to initiate new Create_child_SA exchanges > to get at the narrow SA that they actually want. All these problems go away if you use the decorrelated traffic selectors (as pointed out by Markku) when you are proposing and use the same decorrelated traffic selectors when narrowing. That way the resulting SA will also be matching exactly one policy rule in both ends. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 8 08:16:05 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA07219 for ; Tue, 8 Feb 2005 08:16:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyVA7-0002Mh-1u; Tue, 08 Feb 2005 08:12:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyV5P-00085N-SW for ipsec@megatron.ietf.org; Tue, 08 Feb 2005 08:07:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA06241 for ; Tue, 8 Feb 2005 08:07:23 -0500 (EST) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyVP0-0003z2-7a for ipsec@ietf.org; Tue, 08 Feb 2005 08:27:39 -0500 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id j18D6oQ15736; Tue, 8 Feb 2005 15:06:50 +0200 (IST) In-Reply-To: <200502081203.j18C3Ehh009332@burp.tkv.asdf.org> References: <200502071532.j17FWJxv024135@burp.tkv.asdf.org> <16904.37043.173602.79888@fireball.kivinen.iki.fi> <200502081046.j18Akx9d007728@burp.tkv.asdf.org> <200502081203.j18C3Ehh009332@burp.tkv.asdf.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <48DB9088-79D2-11D9-88A7-000A95834BAA@checkpoint.com> Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] Question about "narrowing" ... Date: Tue, 8 Feb 2005 15:06:45 +0200 To: Markku Savela X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, kivinen@iki.fi X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit In both cases A offered the same thing (remote=10.0.0.0/8,port=any). How is B to know what to answer the first and second time? B doesn't get to see the packet. On Feb 8, 2005, at 2:03 PM, Markku Savela wrote: > Ok, I will answer my own question... sorry about confusion :-) > >> From: Markku Savela > >> Node A has policy: >> C1: remote 10/8 -> A1 >> >> Node B has policy >> C1: local port = 80 -> A1 >> C2: local 10/8 -> A1 >> .. >> A offers: remote=10/8,port=any (packet: port=80,remote= 10.0.0.1) >> >> How is this narrowed down, so that B's policy is followed in A? Or is >> this impossible? > > narrowed to "remote=10/8, port=80" > > and another > > A offers: remote=10/8,port=any (packet: port=100,remote= 10.0.0.1) > > then this is narrowed into > > remote=10/8, port != 80 > > => if you do narrowing, you have to use decorrelated policy > in the narrowing process? > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 8 09:54:06 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA14097 for ; Tue, 8 Feb 2005 09:54:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyWfl-0007IN-PK; Tue, 08 Feb 2005 09:49:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyWeD-00070H-FC for ipsec@megatron.ietf.org; Tue, 08 Feb 2005 09:47:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13780 for ; Tue, 8 Feb 2005 09:47:23 -0500 (EST) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyWxo-0006Cd-CU for ipsec@ietf.org; Tue, 08 Feb 2005 10:07:41 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.2/8.13.2/Debian-1) with ESMTP id j18ElGtE011171; Tue, 8 Feb 2005 16:47:16 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.2/8.13.2/Submit) id j18ElCDB011166; Tue, 8 Feb 2005 16:47:12 +0200 Date: Tue, 8 Feb 2005 16:47:12 +0200 Message-Id: <200502081447.j18ElCDB011166@burp.tkv.asdf.org> From: Markku Savela To: ynir@checkpoint.com In-reply-to: <48DB9088-79D2-11D9-88A7-000A95834BAA@checkpoint.com> (message from Yoav Nir on Tue, 8 Feb 2005 15:06:45 +0200) Subject: Re: [Ipsec] Question about "narrowing" ... References: <200502071532.j17FWJxv024135@burp.tkv.asdf.org> <16904.37043.173602.79888@fireball.kivinen.iki.fi> <200502081046.j18Akx9d007728@burp.tkv.asdf.org> <200502081203.j18C3Ehh009332@burp.tkv.asdf.org> <48DB9088-79D2-11D9-88A7-000A95834BAA@checkpoint.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > From: Yoav Nir > In both cases A offered the same thing (remote=10.0.0.0/8,port=any). > How is B to know what to answer the first and second time? B doesn't > get to see the packet. Yes, B does get to see the packet. Somewhere in IKEv2 there is a statement that the first entry in the selector list describes the packet information. It should be noted that this "packet information selector" is only for IKE use, it should not be actually included in the TS selectors of the resulting SA in SADB. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 8 11:17:22 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA21360 for ; Tue, 8 Feb 2005 11:17:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyY1D-00047I-Ig; Tue, 08 Feb 2005 11:15:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyXwe-00037R-5X for ipsec@megatron.ietf.org; Tue, 08 Feb 2005 11:10:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20919 for ; Tue, 8 Feb 2005 11:10:28 -0500 (EST) Received: from ns.ca.certicom.com ([66.48.18.197] helo=mail.ca.certicom.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CyYGE-000802-C9 for ipsec@ietf.org; Tue, 08 Feb 2005 11:30:48 -0500 Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id BE1BC1007D for ; Tue, 8 Feb 2005 11:09:52 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 31290-58 for ; Tue, 8 Feb 2005 11:09:38 -0500 (EST) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 93A8D10074 for ; Tue, 8 Feb 2005 11:09:38 -0500 (EST) In-Reply-To: <16904.44221.224483.181226@fireball.kivinen.iki.fi> Subject: Re: [Ipsec] How to do authentication with EAP To: ipsec@ietf.org X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Tom Stiemerling Date: Tue, 8 Feb 2005 11:00:35 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 02/08/2005 11:00:29 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 2409bba43e9c8d580670fda8b695204a X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Thanks for elaborating. Also, it seems to me that if you use EAP-CHAP (MD5 password) along with certificate based server authentication, then you are not subject to a man in the middle attack, since you know you are talking to the gateway before you do EAP. Cheers, Tom Tero Kivinen wrote on 02/08/2005 07:12:45 AM: > EAP methods that do not establish a shared key SHOULD NOT be used, as > they are subject to a number of man-in-the-middle attacks [EAPMITM] > if these EAP methods are used in other protocols that do not use a > server-authenticated tunnel. Please see the Security Considerations > section for more details. If EAP methods that do not generate a > shared key are used, the AUTH payloads in messages 7 and 8 MUST be > generated using SK_pi and SK_pr respectively. > > This would appear to be the case if using EAP-CHAP (MD5 password). > > So you should not use such metehod :-) > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 8 13:12:56 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA01007 for ; Tue, 8 Feb 2005 13:12:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyZmx-0001y2-F4; Tue, 08 Feb 2005 13:08:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyZit-0001Fm-MA for ipsec@megatron.ietf.org; Tue, 08 Feb 2005 13:04:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA00357 for ; Tue, 8 Feb 2005 13:04:25 -0500 (EST) Received: from nwkea-mail-2.sun.com ([192.18.42.14]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cya2W-0002Fl-PE for ipsec@ietf.org; Tue, 08 Feb 2005 13:24:46 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-2.sun.com (8.12.10/8.12.9) with ESMTP id j18I4Bgx009339; Tue, 8 Feb 2005 10:04:11 -0800 (PST) Received: from 129.148.19.3 (punchin-sommerfeld.East.Sun.COM [129.148.19.3]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j18I4AQp024295; Tue, 8 Feb 2005 13:04:11 -0500 (EST) Subject: Re: [Ipsec] Question about "narrowing" ... From: Bill Sommerfeld To: Tero Kivinen In-Reply-To: <16904.37043.173602.79888@fireball.kivinen.iki.fi> References: <200502071532.j17FWJxv024135@burp.tkv.asdf.org> <16904.37043.173602.79888@fireball.kivinen.iki.fi> Content-Type: text/plain Message-Id: <1107885807.45264.58.camel@unknown.hamachi.org> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Tue, 08 Feb 2005 13:03:27 -0500 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit On Tue, 2005-02-08 at 05:13, Tero Kivinen wrote: > Anyways, I do not expect implementations to create such SAs unless > they have some proper reason for that from their policy. There's another way to trigger the scenario Markku is worried about: The responder's policy may not be static -- it could have changed between the first and second SA creation. if the first SA remained consistent with the new policy there would be no reason for the responder to delete it. - Bill _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 8 15:36:59 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14834 for ; Tue, 8 Feb 2005 15:36:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CybxX-0007UC-CR; Tue, 08 Feb 2005 15:27:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CybvA-0005mn-TH for ipsec@megatron.ietf.org; Tue, 08 Feb 2005 15:25:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA13494 for ; Tue, 8 Feb 2005 15:25:15 -0500 (EST) Received: from ns.ca.certicom.com ([66.48.18.197] helo=mail.ca.certicom.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1CycEp-0005f0-0U for ipsec@ietf.org; Tue, 08 Feb 2005 15:45:36 -0500 Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 222BB10079 for ; Tue, 8 Feb 2005 15:24:44 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 32563-28 for ; Tue, 8 Feb 2005 15:24:33 -0500 (EST) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id D37F41003F for ; Tue, 8 Feb 2005 15:24:32 -0500 (EST) To: ipsec@ietf.org X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Tom Stiemerling Date: Tue, 8 Feb 2005 15:15:28 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 02/08/2005 03:15:23 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Ipsec] Double authentication of responder X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 you do EAP you delay sending the initiators AUTH until you have done EAP. Fine. The spec says you must also do PKI authentication of the responder. Fine. But then you also re-authenticate the responder in the last message of the exchange. So, my question is what purpose does this serve? You have already authenticated the server using PKI, so why do it again? Thanks, Tom _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Feb 9 02:42:53 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06830 for ; Wed, 9 Feb 2005 02:42:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CymS5-0005r0-86; Wed, 09 Feb 2005 02:39:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CymRN-0005aU-9x for ipsec@megatron.ietf.org; Wed, 09 Feb 2005 02:39:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA06670 for ; Wed, 9 Feb 2005 02:39:11 -0500 (EST) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyml6-000096-TZ for ipsec@ietf.org; Wed, 09 Feb 2005 02:59:38 -0500 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id j197cca22425; Wed, 9 Feb 2005 09:38:38 +0200 (IST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <9C0745AA-7A6D-11D9-AF52-000A95834BAA@checkpoint.com> Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] Double authentication of responder Date: Wed, 9 Feb 2005 09:38:37 +0200 To: Tom Stiemerling X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit The second time, the responder is proving that it has a trust relationship with the EAP server - that it is not doing some MITM attack with the EAP server. On Feb 8, 2005, at 10:15 PM, Tom Stiemerling wrote: > > > > > When you do EAP you delay sending the initiators AUTH until you have > done > EAP. Fine. > The spec says you must also do PKI authentication of the responder. > Fine. > But then you also re-authenticate the responder in the last message of > the > exchange. > So, my question is what purpose does this serve? You have already > authenticated > the server using PKI, so why do it again? > > Thanks, Tom > > > _______________________________________________ > 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 Feb 9 02:57:27 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07730 for ; Wed, 9 Feb 2005 02:57:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CymeB-0001gR-Py; Wed, 09 Feb 2005 02:52:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CymYj-0000DU-36 for ipsec@megatron.ietf.org; Wed, 09 Feb 2005 02:46:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA07079 for ; Wed, 9 Feb 2005 02:46:47 -0500 (EST) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CymsU-0000It-Ah for ipsec@ietf.org; Wed, 09 Feb 2005 03:07:14 -0500 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id j197kGY23735; Wed, 9 Feb 2005 09:46:16 +0200 (IST) In-Reply-To: <200502081447.j18ElCDB011166@burp.tkv.asdf.org> References: <200502071532.j17FWJxv024135@burp.tkv.asdf.org> <16904.37043.173602.79888@fireball.kivinen.iki.fi> <200502081046.j18Akx9d007728@burp.tkv.asdf.org> <200502081203.j18C3Ehh009332@burp.tkv.asdf.org> <48DB9088-79D2-11D9-88A7-000A95834BAA@checkpoint.com> <200502081447.j18ElCDB011166@burp.tkv.asdf.org> Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] Question about "narrowing" ... Date: Wed, 9 Feb 2005 09:46:15 +0200 To: Markku Savela X-Mailer: Apple Mail (2.619) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Can't believe I haven't noticed this before. It's right there on page 24. Thanks. On Feb 8, 2005, at 4:47 PM, Markku Savela wrote: > >> From: Yoav Nir > >> In both cases A offered the same thing (remote=10.0.0.0/8,port=any). >> How is B to know what to answer the first and second time? B doesn't >> get to see the packet. > > Yes, B does get to see the packet. Somewhere in IKEv2 there is a > statement that the first entry in the selector list describes the > packet information. > > It should be noted that this "packet information selector" is only for > IKE use, it should not be actually included in the TS selectors of the > resulting SA in SADB. > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Feb 9 06:46:08 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21634 for ; Wed, 9 Feb 2005 06:46:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyqFw-0006XL-IX; Wed, 09 Feb 2005 06:43:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyqFA-00069Q-2S for ipsec@megatron.ietf.org; Wed, 09 Feb 2005 06:42:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21550 for ; Wed, 9 Feb 2005 06:42:49 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyqYw-0004pC-8a for ipsec@ietf.org; Wed, 09 Feb 2005 07:03:19 -0500 Received: from kolumbus.fi (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 3004B89897; Wed, 9 Feb 2005 13:42:18 +0200 (EET) Message-ID: <4209F6CC.7040804@kolumbus.fi> Date: Wed, 09 Feb 2005 13:41:00 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Stiemerling Subject: Re: [Ipsec] How to do authentication with EAP References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit > Thanks for elaborating. Also, it seems to me that if you use EAP-CHAP (MD5 > password) along with > certificate based server authentication, then you are not subject to a man > in the middle attack, since > you know you are talking to the gateway before you do EAP. Yes, but does the gateway know its really talking to you? This depends on what you are doing. There are man-in-the-middle attacks that take the victim's authentication run from somewhere else and establish a tunnel where only the server is authenticated. Suddenly the attacker is "authenticated" to the gateway, yet the victim was doing something else. For instance, if you use the same CHAP password for dial-in and VPN authentication, someone who sees the PPP CHAP authentication run could use it to construct a successful IKEv2-EAP-CHAP authentication run. The victim sees a failed dial-in connection, and the attacker gets access to the VPN. This is one of the reasons why the use of weak methods such as EAP-CHAP is discouraged. --Jari _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Feb 9 09:41:26 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06248 for ; Wed, 9 Feb 2005 09:41:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cysvf-0008WE-RF; Wed, 09 Feb 2005 09:34:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cysk7-0004dj-U7 for ipsec@megatron.ietf.org; Wed, 09 Feb 2005 09:23:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04936 for ; Wed, 9 Feb 2005 09:22:58 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyt3w-0008Me-RG for ipsec@ietf.org; Wed, 09 Feb 2005 09:43:29 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j19EMjfU016243 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 9 Feb 2005 16:22:45 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j19EMiSN016240; Wed, 9 Feb 2005 16:22:44 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16906.7348.57052.203754@fireball.kivinen.iki.fi> Date: Wed, 9 Feb 2005 16:22:44 +0200 From: Tero Kivinen To: Markku Savela Subject: Re: [Ipsec] Question about "narrowing" ... In-Reply-To: <200502081447.j18ElCDB011166@burp.tkv.asdf.org> References: <200502071532.j17FWJxv024135@burp.tkv.asdf.org> <16904.37043.173602.79888@fireball.kivinen.iki.fi> <200502081046.j18Akx9d007728@burp.tkv.asdf.org> <200502081203.j18C3Ehh009332@burp.tkv.asdf.org> <48DB9088-79D2-11D9-88A7-000A95834BAA@checkpoint.com> <200502081447.j18ElCDB011166@burp.tkv.asdf.org> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 2 min X-Total-Time: 1 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, ynir@checkpoint.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Markku Savela writes: > It should be noted that this "packet information selector" is only for > IKE use, it should not be actually included in the TS selectors of the > resulting SA in SADB. It does not matter wheather it ends in the SADB or not, as normally the final TS selectors include that address inside one of the other selectors (and if they do not, then it MUST be included in the SADB selector). I would guess IKE implementations will optimize that kind of redundant items in the list away before giving it to the IPsec. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Feb 9 09:49:00 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06870 for ; Wed, 9 Feb 2005 09:49:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyt73-0002U1-3I; Wed, 09 Feb 2005 09:46:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyt0U-000139-2N for ipsec@megatron.ietf.org; Wed, 09 Feb 2005 09:39:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06143 for ; Wed, 9 Feb 2005 09:39:52 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CytKJ-0000IA-3j for ipsec@ietf.org; Wed, 09 Feb 2005 10:00:23 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j19EdpV7016498 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 9 Feb 2005 16:39:51 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j19EdnI5016495; Wed, 9 Feb 2005 16:39:50 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16906.8373.856318.880616@fireball.kivinen.iki.fi> Date: Wed, 9 Feb 2005 16:39:49 +0200 From: Tero Kivinen To: Bill Sommerfeld Subject: Re: [Ipsec] Question about "narrowing" ... In-Reply-To: <1107885807.45264.58.camel@unknown.hamachi.org> References: <200502071532.j17FWJxv024135@burp.tkv.asdf.org> <16904.37043.173602.79888@fireball.kivinen.iki.fi> <1107885807.45264.58.camel@unknown.hamachi.org> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 3 min X-Total-Time: 2 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Bill Sommerfeld writes: > On Tue, 2005-02-08 at 05:13, Tero Kivinen wrote: > > > Anyways, I do not expect implementations to create such SAs unless > > they have some proper reason for that from their policy. > > There's another way to trigger the scenario Markku is worried about: > > The responder's policy may not be static -- it could have changed between the > first and second SA creation. > > if the first SA remained consistent with the new policy there would be no > reason for the responder to delete it. Good think we already have the notify for that, i.e. if the other end sends data to the SA which is not allowed to be sent to that SA, then recipient of that data should send INVALID_SELECTORS notification to the initiator. The recipient of INVALID_SELECTORS can then remove the IPsec SA and recreate it, and now the other end will probably narrow it to match to the newly installed policy, fixing the situation. This still requires both ends to use decorrelated policy. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Feb 9 12:38:37 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA20553 for ; Wed, 9 Feb 2005 12:38:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyvfH-0004uf-ER; Wed, 09 Feb 2005 12:30:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyvcA-0003b4-FR for ipsec@megatron.ietf.org; Wed, 09 Feb 2005 12:26:58 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19035 for ; Wed, 9 Feb 2005 12:26:55 -0500 (EST) Received: from ns.ca.certicom.com ([66.48.18.197] helo=mail.ca.certicom.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Cyvvz-0003xA-To for ipsec@ietf.org; Wed, 09 Feb 2005 12:47:29 -0500 Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 7ECB71003F; Wed, 9 Feb 2005 12:26:21 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02961-75; Wed, 9 Feb 2005 12:26:07 -0500 (EST) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id A72C910084; Wed, 9 Feb 2005 12:26:07 -0500 (EST) In-Reply-To: <9C0745AA-7A6D-11D9-AF52-000A95834BAA@checkpoint.com> Subject: Re: [Ipsec] Double authentication of responder To: ynir@checkpoint.com X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Tom Stiemerling Date: Wed, 9 Feb 2005 12:05:47 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 02/09/2005 12:16:56 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d 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 OK. Here is a summary of my understanding of this: 1) If the EAP method does not generate an MSK, then you are not authenticating the EAP server, and the second AUTH from the gateway is redundant. 2) If the EAP method does generate an MSK, but does not authenticate the EAP server, then the second AUTH is necessary to authenticate the EAP server. 3) If the EAP method does generate an MSK and also authenticates the EAP server, then the second AUTH is redundant. Would you agree? Tom Yoav Nir wrote on 02/09/2005 02:38:37 AM: > The second time, the responder is proving that it has a trust > relationship with the EAP server - that it is not doing some MITM > attack with the EAP server. > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Feb 9 14:47:47 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA05739 for ; Wed, 9 Feb 2005 14:47:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyxWJ-0004jd-PE; Wed, 09 Feb 2005 14:29:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyxIt-0000Jp-1Z for ipsec@megatron.ietf.org; Wed, 09 Feb 2005 14:15:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29159 for ; Wed, 9 Feb 2005 14:15:09 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cyxcj-0006wt-Is for ipsec@ietf.org; Wed, 09 Feb 2005 14:35:42 -0500 Received: from [10.84.130.245] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j19JESjj029575; Wed, 9 Feb 2005 14:14:35 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <16904.46490.990547.717595@fireball.kivinen.iki.fi> References: <200502071532.j17FWJxv024135@burp.tkv.asdf.org> <16904.37043.173602.79888@fireball.kivinen.iki.fi> <200502081046.j18Akx9d007728@burp.tkv.asdf.org> <200502081203.j18C3Ehh009332@burp.tkv.asdf.org> <16904.46490.990547.717595@fireball.kivinen.iki.fi> Date: Wed, 9 Feb 2005 13:57:22 -0500 To: Tero Kivinen From: Stephen Kent Subject: Re: [Ipsec] Question about "narrowing" ... Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 2:50 PM +0200 2/8/05, Tero Kivinen wrote: >Markku Savela writes: >> => if you do narrowing, you have to use decorrelated policy >> in the narrowing process? > >Yes. And also when you are proposing traffic selectors to the other >end you should send decorrelated policy, as otherwise the responder >can select something to the SA which are not allowed by your policy. >-- Tero, I'm a bit concerned by this suggestion. 2401bis says one should send the original SPD entry, not a decorrelated one, to preserve the external perspective of the SPD and keep the decorrelation a purely local optimization. steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Feb 9 17:06:41 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03820 for ; Wed, 9 Feb 2005 17:06:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cyzqy-0007rS-HE; Wed, 09 Feb 2005 16:58:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CyzQT-0004yn-Nq for ipsec@megatron.ietf.org; Wed, 09 Feb 2005 16:31:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA25594 for ; Wed, 9 Feb 2005 16:31:07 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CyzkJ-0006WQ-Bl for ipsec@ietf.org; Wed, 09 Feb 2005 16:51:42 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j19LUKOJ028681; Wed, 9 Feb 2005 14:30:20 -0700 (MST) Received: from thunk (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j19LUKQp011606; Wed, 9 Feb 2005 16:30:20 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j19LUK3K007003; Wed, 9 Feb 2005 16:30:20 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j19LUJJN007002; Wed, 9 Feb 2005 16:30:19 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: [Ipsec] Question about "narrowing" ... From: Bill Sommerfeld To: Stephen Kent In-Reply-To: References: <200502071532.j17FWJxv024135@burp.tkv.asdf.org> <16904.37043.173602.79888@fireball.kivinen.iki.fi> <200502081046.j18Akx9d007728@burp.tkv.asdf.org> <200502081203.j18C3Ehh009332@burp.tkv.asdf.org> <16904.46490.990547.717595@fireball.kivinen.iki.fi> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1107984619.2838.343.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Wed, 09 Feb 2005 16:30:19 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Tero Kivinen X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit On Wed, 2005-02-09 at 13:57, Stephen Kent wrote: > I'm a bit concerned by this suggestion. > > 2401bis says one should send the original SPD entry, not a > decorrelated one, to preserve the external perspective of the SPD and > keep the decorrelation a purely local optimization. this seems wrong; if the initiator's original SPD entry has a hole punched in it by a previous rule and the responder is unaware of the hole, it may misroute traffic onto the wrong SA rather than creating the correct SA.. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Feb 10 03:19:38 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA05374 for ; Thu, 10 Feb 2005 03:19:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cz9MZ-0004zC-Re; Thu, 10 Feb 2005 03:07:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cz9IO-0002jE-5P for ipsec@megatron.ietf.org; Thu, 10 Feb 2005 03:03:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA04234 for ; Thu, 10 Feb 2005 03:03:26 -0500 (EST) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Cz9cJ-0004cb-3X for ipsec@ietf.org; Thu, 10 Feb 2005 03:24:06 -0500 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id j1A82pl15316; Thu, 10 Feb 2005 10:02:51 +0200 (IST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <2897FCAE-7B3A-11D9-AF52-000A95834BAA@checkpoint.com> Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] Double authentication of responder Date: Thu, 10 Feb 2005 10:02:50 +0200 To: Tom Stiemerling X-Mailer: Apple Mail (2.619) 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 Content-Transfer-Encoding: 7bit I agree with #1 and with #2. In #3 the AUTH message proves that the EAP server trusts the gateway enough to send the MSK. I'm at a loss to figure out why that's important. On Feb 9, 2005, at 7:05 PM, Tom Stiemerling wrote: > > > > > OK. Here is a summary of my understanding of this: > > 1) If the EAP method does not generate an MSK, then you are not > authenticating the > EAP server, and the second AUTH from the gateway is redundant. > > 2) If the EAP method does generate an MSK, but does not authenticate > the > EAP > server, then the second AUTH is necessary to authenticate the EAP > server. > > 3) If the EAP method does generate an MSK and also authenticates the > EAP > server, > then the second AUTH is redundant. > > Would you agree? > > Tom > > Yoav Nir wrote on 02/09/2005 02:38:37 AM: > >> The second time, the responder is proving that it has a trust >> relationship with the EAP server - that it is not doing some MITM >> attack with the EAP server. >> > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Feb 10 04:04:04 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08334 for ; Thu, 10 Feb 2005 04:04:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzA2H-0000VY-4M; Thu, 10 Feb 2005 03:50:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Cz9vt-0005Ej-1j for ipsec@megatron.ietf.org; Thu, 10 Feb 2005 03:44:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07355 for ; Thu, 10 Feb 2005 03:44:15 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzAFq-0005hs-Kz for ipsec@ietf.org; Thu, 10 Feb 2005 04:04:55 -0500 Received: from kolumbus.fi (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 1193F89883; Thu, 10 Feb 2005 10:43:39 +0200 (EET) Message-ID: <420B1E6D.1040901@kolumbus.fi> Date: Thu, 10 Feb 2005 10:42:21 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tom Stiemerling Subject: Re: [Ipsec] Double authentication of responder References: <2897FCAE-7B3A-11D9-AF52-000A95834BAA@checkpoint.com> In-Reply-To: <2897FCAE-7B3A-11D9-AF52-000A95834BAA@checkpoint.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Yoav Nir X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit > 1) If the EAP method does not generate an MSK, then > you are not authenticating the EAP server, and > the second AUTH from the gateway is rdundant. Just because you don't generate a key doesn't mean that you are not authenticating the server. (The reverse isn't true, see below.) > 2) If the EAP method does generate an MSK, but does not > authenticate the EAP server, then the second AUTH > is necessary to authenticate the EAP server. This case is illegal according to current RFCs. RFC 3748 says "EAP Methods deriving keys MUST provide for mutual authentication between the EAP peer and the EAP Server." --Jari _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Feb 10 04:54:42 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13275 for ; Thu, 10 Feb 2005 04:54:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzAum-0000gD-O1; Thu, 10 Feb 2005 04:47:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzAla-0000ZL-N6 for ipsec@megatron.ietf.org; Thu, 10 Feb 2005 04:37:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA10670 for ; Thu, 10 Feb 2005 04:37:40 -0500 (EST) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzB5Y-0006mV-La for ipsec@ietf.org; Thu, 10 Feb 2005 04:58:22 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.2/8.13.2/Debian-1) with ESMTP id j1A9bQeQ015110 for ; Thu, 10 Feb 2005 11:37:26 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.2/8.13.2/Submit) id j1A9bQAs015107; Thu, 10 Feb 2005 11:37:26 +0200 Date: Thu, 10 Feb 2005 11:37:26 +0200 Message-Id: <200502100937.j1A9bQAs015107@burp.tkv.asdf.org> From: Markku Savela To: ipsec@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: a7d6aff76b15f3f56fcb94490e1052e4 Subject: [Ipsec] IKEv2 Traffic Selectors? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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'm not myself involved in IKEv2 impelementations, which is why I may be misreading the IKEv2 draft. But, perhaps some expert can quickly answer to my concern: >From 2401bis I get the following picture for traffic selector: - list of "basic selectors" - a "basic selector" is a unit defining local and remote port range, local and remote address range and protocol range. The basic selector matches if *ALL* of the range conditions are met (AND rule), and the full selector matches if *ANY* of the basic ones matches (OR rule). >From my reading of IKE, it seems to split the traffic selector into two selector payloads: TSi and TSr. For example, the "per packet information" is supposed to be added to the front of the traffic selector. Assuming I'm the initiator for outgoing packet, seems to indicate that the packet information will be split into two TSi[1] = packet protocol, src address, src port TSr[1] = packet protocol, dst address, dst port This leads me to believe, that TSi and TSi *must* have exactly the same number of entries, and the entry on same "index" must correspond to one 2401 "basic selector"? How else could you express a selector like "localport=1234 and remoteport=80"? Thus, the matching rule for TS payloads in IKEv2 are for (i = all traffic selector in TS payload) if (TSi[i] and TSr[i] match the condition) selector match; The question of course is then: why two payloads in the first place? Both must have exactly same number of entries, and must be in synch. I would think single TS payload with combined initiator and responder values would be less error prone? _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Feb 10 05:20:05 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14807 for ; Thu, 10 Feb 2005 05:20:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzBG0-0003NW-QG; Thu, 10 Feb 2005 05:09:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzB8E-0004tD-R4 for ipsec@megatron.ietf.org; Thu, 10 Feb 2005 05:01:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13760 for ; Thu, 10 Feb 2005 05:01:04 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzBSD-0007Pg-FQ for ipsec@ietf.org; Thu, 10 Feb 2005 05:21:46 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j1AA0k1W027706 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 10 Feb 2005 12:00:52 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j1AA0jDP027703; Thu, 10 Feb 2005 12:00:46 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16907.12493.786724.720913@fireball.kivinen.iki.fi> Date: Thu, 10 Feb 2005 12:00:45 +0200 From: Tero Kivinen To: Stephen Kent Subject: Re: [Ipsec] Question about "narrowing" ... In-Reply-To: References: <200502071532.j17FWJxv024135@burp.tkv.asdf.org> <16904.37043.173602.79888@fireball.kivinen.iki.fi> <200502081046.j18Akx9d007728@burp.tkv.asdf.org> <200502081203.j18C3Ehh009332@burp.tkv.asdf.org> <16904.46490.990547.717595@fireball.kivinen.iki.fi> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 15 min X-Total-Time: 14 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 82c9bddb247d9ba4471160a9a865a5f3 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Stephen Kent writes: > >Yes. And also when you are proposing traffic selectors to the other > >end you should send decorrelated policy, as otherwise the responder > >can select something to the SA which are not allowed by your policy. > > I'm a bit concerned by this suggestion. > > 2401bis says one should send the original SPD entry, not a > decorrelated one, to preserve the external perspective of the SPD and > keep the decorrelation a purely local optimization. You need to send the policy out you are following. If you are following the decorrelated policy, you also need to communcate that to the other end, or otherwise the policies in both end must match exactly (in, which case the narrowing is not that useful). I.e. if host A policy is (for simplicy I am assuming the policy is only based by single IP-address selector): 1. 10.0.0.42 => ESP(AES) 2. 10.0.0.0-10.0.0.255 => AH(SHA1) The decorrelated policy will be: 1. 10.0.0.42 => ESP(AES) 2. 10.0.0.0-10.0.0.41, 10.0.0.43-10.0.0.255 => AH(SHA1) The responder host B is the SGW having policy which says that either ESP(AES) or AH(SHA1) is accepted from whatever places as dictated by the initiators policy (i.e. 1. 0.0.0.0-255.255.255.255 => either AH(SHA1) or ESP(AES)). Lets say the packet causing the trigger will have IP address 10.0.0.5. Now if you use original policy to negotiate the SA, the SA will have traffic selector 10.0.0.0-10.0.0.255 and uses AH(SHA1). Now if the host B wants to send packet having IP of 10.0.0.42, then the host A will reject that packet when it comes out from the tunnel as it should have had ESP(AES). The host A will send INVALID_SELECTORS notification, but the host B does not have any way to know how to fix the situation, as he does not have information about the policy of the other end. If the host A uses decorrelated policy then the SA created will have traffic selectors 10.0.0.0-10.0.0.41, 10.0.0.43-10.0.0.255 and uses AH(SHA1), and if host B tries to send packet with IP address of 10.0.0.42, he notices there is no SA for it. It starts creating the SA offering both ESP(AES) and AH(SHA1) as valid algorithms. The host A will select ESP(AES), and we will have second SA with traffic selectors 10.0.0.42 which uses ESP(AES). So if you want to use narrowing, and you are having the policies in both ends different, you should use the decorrelated policies if you want to to automatically detect and fix the mismatches in the policies. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Feb 10 05:46:58 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA17065 for ; Thu, 10 Feb 2005 05:46:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzBjk-0004im-QC; Thu, 10 Feb 2005 05:39:52 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzBin-0004To-EN for ipsec@megatron.ietf.org; Thu, 10 Feb 2005 05:38:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA16362 for ; Thu, 10 Feb 2005 05:38:51 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzC2m-0008FQ-Sf for ipsec@ietf.org; Thu, 10 Feb 2005 05:59:33 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j1AAcf4N028117 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 10 Feb 2005 12:38:42 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j1AAcfRE028114; Thu, 10 Feb 2005 12:38:41 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16907.14769.708584.854470@fireball.kivinen.iki.fi> Date: Thu, 10 Feb 2005 12:38:41 +0200 From: Tero Kivinen To: Markku Savela Subject: [Ipsec] IKEv2 Traffic Selectors? In-Reply-To: <200502100937.j1A9bQAs015107@burp.tkv.asdf.org> References: <200502100937.j1A9bQAs015107@burp.tkv.asdf.org> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 17 min X-Total-Time: 18 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Markku Savela writes: > This leads me to believe, that TSi and TSi *must* have exactly the > same number of entries, No such requirement. They can have different number of entries, and it is very common to have different number of entries. > and the entry on same "index" must correspond > to one 2401 "basic selector"? Nope. > How else could you express a selector like "localport=1234 and > remoteport=80"? All TSi payloads are ORed together and all TSr payloads or ORed together, to get the final local and remove selectors. Any item in the local selectors can be combined with any item in the remote selectors. > Thus, the matching rule for TS payloads in IKEv2 are > > for (i = all traffic selector in TS payload) > if (TSi[i] and TSr[i] match the condition) > selector match; Nope. It is: match = false; foreach i (TSi) if (TSi matches the condition) match = true; if (!match) return not_matched_failure match = false; foreach i (TSr) if (TSr matches the condition) match = true; if (!match) return not_matched_failure return matches. > The question of course is then: why two payloads in the first place? So thay you can express things like: TSi = 10.0.0.1, tcp, port 79 or TSi = 10.0.0.1, tcp, port 22 or TSi = 2001:670:83:f00:202:b3ff:fe1f:7884, any to TSr = 0.0.0.0-255.255.255.255, any or TSr = 0::0-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff, any which means that any IPv4 traffic having local tcp port 79 or 22 can be allowed from anywhere from the world, and also any IPv6 traffic to given local addres scan be allowed. There would also be insane combinations like having source IP of IPv4, and destination IP of IPv6, but there cannot be any packets matching those combinations so no problem there. The most common policy will most likely be the remote client policy, i.e, where the initiator proposes TSi = (0, 0-65536,0.0.0.0-255.255.255.255) TSr = (0, 0-65536,0.0.0.0-255.255.255.255) and responder replies with: TSi = (0, 0-65536,192.0.2.202-192.0.2.202) TSr = (0, 0-65536,192.0.2.0-192.0.2.255), (0, 0-65536,10.0.0.0-10.255.255.255) I.e. it allocates the IP address of 192.0.0.2.202 to the device, and says that other remove clients can also be accessed through it (192.0.2.0-192.0.2.255 range), and it also says that the 10.0.0.0/8 network can be acccessed through it, as this is the internal network used by the corporate. > Both must have exactly same number of entries, and must be in synch. I > would think single TS payload with combined initiator and responder > values would be less error prone? That would cause the comibnatory explosion of the rules, as then that kind of complicated rules would need to be expanded as separate payloads. This is same thing that was done to the algorithm proposals, i.e. we can take any algorithms from each set, no need to list that AES-SHA1, AES-MD5, 3DES-SHA1, 3DES-MD5, CAST-SHA1, CAST-MD5, etc, but simply say AES, 3DES, CAST for encryption and SHA1, MD5 for auth. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Feb 10 07:26:26 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23157 for ; Thu, 10 Feb 2005 07:26:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzDHr-0005Zp-2M; Thu, 10 Feb 2005 07:19:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzD5l-00079d-1U for ipsec@megatron.ietf.org; Thu, 10 Feb 2005 07:06:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21647 for ; Thu, 10 Feb 2005 07:06:35 -0500 (EST) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzDPg-0001Y3-Ll for ipsec@ietf.org; Thu, 10 Feb 2005 07:27:18 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.2/8.13.2/Debian-1) with ESMTP id j1AC6X3x017560; Thu, 10 Feb 2005 14:06:33 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.2/8.13.2/Submit) id j1AC6TkC017557; Thu, 10 Feb 2005 14:06:29 +0200 Date: Thu, 10 Feb 2005 14:06:29 +0200 Message-Id: <200502101206.j1AC6TkC017557@burp.tkv.asdf.org> From: Markku Savela To: kivinen@iki.fi In-reply-to: <16907.14769.708584.854470@fireball.kivinen.iki.fi> (message from Tero Kivinen on Thu, 10 Feb 2005 12:38:41 +0200) Subject: Re: [Ipsec] IKEv2 Traffic Selectors? References: <200502100937.j1A9bQAs015107@burp.tkv.asdf.org> <16907.14769.708584.854470@fireball.kivinen.iki.fi> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Tero Kivinen: > match = false; > foreach i (TSi) > if (TSi matches the condition) > match = true; > > if (!match) > return not_matched_failure > > match = false; > foreach i (TSr) > if (TSr matches the condition) > match = true; > > if (!match) > return not_matched_failure > return matches. Thanks for clarifying this. It has implications for me, because in my policy, I can express the following condition: (localport=1 and remoteport=1) or (localport=2 and remoteport=2) -> A1 IKEv2 cannot express this selector in negotiation. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Feb 10 08:00:56 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25968 for ; Thu, 10 Feb 2005 08:00:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzDpq-0003OP-Ua; Thu, 10 Feb 2005 07:54:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzDl8-0002dJ-WE for ipsec@megatron.ietf.org; Thu, 10 Feb 2005 07:49:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25026 for ; Thu, 10 Feb 2005 07:49:25 -0500 (EST) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzE59-0002bH-Jq for ipsec@ietf.org; Thu, 10 Feb 2005 08:10:08 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.2/8.13.2/Debian-1) with ESMTP id j1ACnOqw017735 for ; Thu, 10 Feb 2005 14:49:24 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.2/8.13.2/Submit) id j1ACnOtI017732; Thu, 10 Feb 2005 14:49:24 +0200 Date: Thu, 10 Feb 2005 14:49:24 +0200 Message-Id: <200502101249.j1ACnOtI017732@burp.tkv.asdf.org> From: Markku Savela To: ipsec@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Ipsec] IKEv2 needs a "policy usage mode"... X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I think it might be good if IKEv2 negotiated and operated in the following 3 modes as far as policy checking goes: A) Full policy checking, decorrelated policies on both ends. The only mode where narrowing is allowed. B) Full policy checking. No decorrelated policies in use, a proposed policy must exactly match (no narrowing). Basicly, both sides must have identical policies. C) No policy checking (in IKE). The proposed SA's with indicated traffic selectors are accepted as is. In this mode, a mismatch in policies results a "black hole" (which in my opinion is easily detected by other by dropped packets, and could be notified to the other end). The (C) is my preference. In this mode any complex policy I support, would not depend on IKE capabilities of negotiating it. :-) _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Feb 10 10:32:14 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09308 for ; Thu, 10 Feb 2005 10:32:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzG4s-0004zd-Kz; Thu, 10 Feb 2005 10:17:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzFza-00030Q-Qj for ipsec@megatron.ietf.org; Thu, 10 Feb 2005 10:12:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA07113 for ; Thu, 10 Feb 2005 10:12:28 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzGJb-00061O-O6 for ipsec@ietf.org; Thu, 10 Feb 2005 10:33:12 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j1AFBtjf011011; Thu, 10 Feb 2005 10:11:56 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <1107984619.2838.343.camel@thunk> References: <200502071532.j17FWJxv024135@burp.tkv.asdf.org> <16904.37043.173602.79888@fireball.kivinen.iki.fi> <200502081046.j18Akx9d007728@burp.tkv.asdf.org> <200502081203.j18C3Ehh009332@burp.tkv.asdf.org> <16904.46490.990547.717595@fireball.kivinen.iki.fi> <1107984619.2838.343.camel@thunk> Date: Thu, 10 Feb 2005 10:11:51 -0500 To: Bill Sommerfeld From: Stephen Kent Subject: Re: [Ipsec] Question about "narrowing" ... Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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 4:30 PM -0500 2/9/05, Bill Sommerfeld wrote: >On Wed, 2005-02-09 at 13:57, Stephen Kent wrote: > >> I'm a bit concerned by this suggestion. >> >> 2401bis says one should send the original SPD entry, not a >> decorrelated one, to preserve the external perspective of the SPD and >> keep the decorrelation a purely local optimization. > >this seems wrong; if the initiator's original SPD entry has a hole punched >in it by a previous rule and the responder is unaware of the hole, it may >misroute traffic onto the wrong SA rather than creating the correct SA.. > Bill, I may have lost track of where we are in discussion the IKE exchange. Let's ignore decorrelation, since it is optional. What is correct behavior for an initiator? I thought that IKE (v1 + v2) called for sending the SPD entry that matched the packet that triggered SA creation. IKE v2 added the feature of sending the packet headers as well, to help the responder determine if there is an overlap, when the initiator's SPD entry is a superset of an SPD entry at the responder. This allows the narrowing that I thought was the topic of this discussion. If this is the correct behavior for an initiator when decorrelation as not applied, then why change it when decorrelaton is applied? Decorrelation was not intended to change the external behavior of an IPsec implementation, but rather to allow an implementation to cache SPD data to achieve better performance. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Feb 10 11:31:47 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA14128 for ; Thu, 10 Feb 2005 11:31:47 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzH6C-0001UC-9d; Thu, 10 Feb 2005 11:23:24 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzH05-0000RG-9h for ipsec@megatron.ietf.org; Thu, 10 Feb 2005 11:17:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA13293 for ; Thu, 10 Feb 2005 11:17:03 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzHK7-0007Vr-07 for ipsec@ietf.org; Thu, 10 Feb 2005 11:37:48 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1AGGu819582; Thu, 10 Feb 2005 18:16:56 +0200 (EET) X-Scanned: Thu, 10 Feb 2005 18:27:35 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j1AGRZms013998; Thu, 10 Feb 2005 18:27:35 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00KoZzO0; Thu, 10 Feb 2005 18:27:22 EET Received: from esebh004.NOE.Nokia.com (esebh004.ntc.nokia.com [172.21.138.84]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1AGFNM23762; Thu, 10 Feb 2005 18:15:23 +0200 (EET) Received: from esebh005.NOE.Nokia.com ([172.21.138.86]) by esebh004.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 10 Feb 2005 18:13:45 +0200 Received: from esebe016.NOE.Nokia.com ([172.21.138.55]) by esebh005.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 10 Feb 2005 18:13:45 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe016.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Thu, 10 Feb 2005 18:13:44 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] IKEv2 needs a "policy usage mode"... Date: Thu, 10 Feb 2005 18:13:43 +0200 Message-ID: Thread-Topic: [Ipsec] IKEv2 needs a "policy usage mode"... Thread-Index: AcUPciY+x9xoXPfRR1GyuAYE3Mba/QAGA/Mg To: , X-OriginalArrivalTime: 10 Feb 2005 16:13:44.0407 (UTC) FILETIME=[7E518670:01C50F8B] X-Spam-Score: 0.3 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable In essence, mode A says that "a host must not propose=20 something that violates its own policy". (This, of course,=20 implies that the module sending the proposal must know=20 what the policy is.) Implementations that don't follow this are IMHO simply broken, and I don't think IKEv2 should do anything special for them. Best regards, Pasi > -----Original Message----- > From: ipsec-bounces@ietf.org=20 > [mailto:ipsec-bounces@ietf.org]On Behalf Of > ext Markku Savela > Sent: Thursday, February 10, 2005 2:49 PM > To: ipsec@ietf.org > Subject: [Ipsec] IKEv2 needs a "policy usage mode"... >=20 >=20 >=20 > I think it might be good if IKEv2 negotiated and operated in the > following 3 modes as far as policy checking goes: >=20 > A) Full policy checking, decorrelated policies on both ends. The only > mode where narrowing is allowed. >=20 > B) Full policy checking. No decorrelated policies in use, a proposed > policy must exactly match (no narrowing). Basicly, both sides must > have identical policies. >=20 > C) No policy checking (in IKE). The proposed SA's with indicated > traffic selectors are accepted as is. In this mode, a mismatch in > policies results a "black hole" (which in my opinion is easily > detected by other by dropped packets, and could be notified to the > other end). >=20 > The (C) is my preference. In this mode any complex policy I support, > would not depend on IKE capabilities of negotiating it. :-) >=20 >=20 > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec >=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Feb 10 12:35:52 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19335 for ; Thu, 10 Feb 2005 12:35:52 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzIBH-0008MP-RH; Thu, 10 Feb 2005 12:32:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzI8a-0006zo-LM for ipsec@megatron.ietf.org; Thu, 10 Feb 2005 12:29:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18739 for ; Thu, 10 Feb 2005 12:29:53 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzISc-0000iv-IQ for ipsec@ietf.org; Thu, 10 Feb 2005 12:50:39 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j1AHSxjj020543; Thu, 10 Feb 2005 12:29:21 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <16907.12493.786724.720913@fireball.kivinen.iki.fi> References: <200502071532.j17FWJxv024135@burp.tkv.asdf.org> <16904.37043.173602.79888@fireball.kivinen.iki.fi> <200502081046.j18Akx9d007728@burp.tkv.asdf.org> <200502081203.j18C3Ehh009332@burp.tkv.asdf.org> <16904.46490.990547.717595@fireball.kivinen.iki.fi> <16907.12493.786724.720913@fireball.kivinen.iki.fi> Date: Thu, 10 Feb 2005 10:48:04 -0500 To: Tero Kivinen From: Stephen Kent Subject: Re: [Ipsec] Question about "narrowing" ... Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 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 12:00 PM +0200 2/10/05, Tero Kivinen wrote: >Stephen Kent writes: >> >Yes. And also when you are proposing traffic selectors to the other >> >end you should send decorrelated policy, as otherwise the responder >> >can select something to the SA which are not allowed by your policy. >> >> I'm a bit concerned by this suggestion. >> >> 2401bis says one should send the original SPD entry, not a >> decorrelated one, to preserve the external perspective of the SPD and >> keep the decorrelation a purely local optimization. > >You need to send the policy out you are following. If you are >following the decorrelated policy, you also need to communcate that to >the other end, or otherwise the policies in both end must match >exactly (in, which case the narrowing is not that useful). First, decorrelation of the SPD does not change the policy expressed by the SPD. If you do not have an extant SA that matches an outbound packet, you search the decorrelated SPD to find a match. the matching decorrelated entry and all entries linked to it because they were derived from the same original entry, are used to create the SAD entry, which in turn forms the cache for outbound packet matching. This is what 2401bis says today in the section on decorrelation (page 23 of the 05 version, December 2004). The text should probably be clarified by noting that the SA management protocol may "narrow" the resulting SPD entry, i.e., cause the SAD to be populated with a subset of the linked entries, rather than all of them, reflecting a mutually agreed upon subset of original SPD entry that both peers have elected to employ. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Feb 10 12:41:04 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19950 for ; Thu, 10 Feb 2005 12:41:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzIBI-0008Mw-K0; Thu, 10 Feb 2005 12:32:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzI96-00079r-Oh for ipsec@megatron.ietf.org; Thu, 10 Feb 2005 12:30:28 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18785 for ; Thu, 10 Feb 2005 12:30:26 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzITA-0000jc-8q for ipsec@ietf.org; Thu, 10 Feb 2005 12:51:12 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j1AHSxjp020543; Thu, 10 Feb 2005 12:29:26 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <200502101249.j1ACnOtI017732@burp.tkv.asdf.org> References: <200502101249.j1ACnOtI017732@burp.tkv.asdf.org> Date: Thu, 10 Feb 2005 10:46:25 -0500 To: Markku Savela From: Stephen Kent Subject: Re: [Ipsec] IKEv2 needs a "policy usage mode"... Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 2:49 PM +0200 2/10/05, Markku Savela wrote: >I think it might be good if IKEv2 negotiated and operated in the >following 3 modes as far as policy checking goes: > >A) Full policy checking, decorrelated policies on both ends. The only >mode where narrowing is allowed. > >B) Full policy checking. No decorrelated policies in use, a proposed >policy must exactly match (no narrowing). Basicly, both sides must >have identical policies. > >C) No policy checking (in IKE). The proposed SA's with indicated >traffic selectors are accepted as is. In this mode, a mismatch in >policies results a "black hole" (which in my opinion is easily >detected by other by dropped packets, and could be notified to the >other end). > >The (C) is my preference. In this mode any complex policy I support, >would not depend on IKE capabilities of negotiating it. :-) > >______ As I just said in a previous message, the intent of decorrelation is NOT to charge then policy expressed in the SPD. I think IKEv2 included narrowing as a concept independent of use of decorrelation. Thus I have heartburn with this characterization of different modes of policy checking. I also think it is questionable to suggest (C) above, as it encourages expression of policies that IKE cannot negotiate. We worked hard in 2401bis to align what the SPD can express vs. what IKE can negotiate, to fix the mismatch from 2401. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Feb 10 13:18:14 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22894 for ; Thu, 10 Feb 2005 13:18:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzIrE-0004ZO-Qw; Thu, 10 Feb 2005 13:16:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzIlS-0002xS-Gn for ipsec@megatron.ietf.org; Thu, 10 Feb 2005 13:10:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22242 for ; Thu, 10 Feb 2005 13:10:01 -0500 (EST) Received: from spsystems.net ([216.126.83.115]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzJ5S-0001iT-Oi for ipsec@ietf.org; Thu, 10 Feb 2005 13:30:48 -0500 Received: from spsystems.net (henry@localhost [127.0.0.1]) by spsystems.net (8.12.10/8.12.10) with ESMTP id j1AI9GVO019149; Thu, 10 Feb 2005 13:09:16 -0500 (EST) Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id j1AI9GpS019148; Thu, 10 Feb 2005 13:09:16 -0500 (EST) Date: Thu, 10 Feb 2005 13:09:16 -0500 (EST) From: Henry Spencer To: IP Security List Subject: Re: [Ipsec] IKEv2 needs a "policy usage mode"... In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Thu, 10 Feb 2005, Stephen Kent wrote: > At 2:49 PM +0200 2/10/05, Markku Savela wrote: > >C) No policy checking (in IKE). The proposed SA's with indicated > >traffic selectors are accepted as is. In this mode, a mismatch in > >policies results a "black hole"... > > I also think it is questionable to suggest (C) above, as it > encourages expression of policies that IKE cannot negotiate. We > worked hard in 2401bis to align what the SPD can express vs. what IKE > can negotiate, to fix the mismatch from 2401. If memory serves, Markku has long taken the position that IKE ought to be purely a key-exchange protocol -- without the slightest hint of policy negotiation, because all policy negotiation ought to be done manually by prearrangement -- and resisted all attempts to convince him that this is based on an unrealistically narrow view of how IKE is used. What's surprising is not that he would suggest (C), but that his suggestion actually included (A) and (B). :-) Henry Spencer henry@spsystems.net _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Feb 10 13:39:56 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA24553 for ; Thu, 10 Feb 2005 13:39:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzJBZ-0002n8-8H; Thu, 10 Feb 2005 13:37:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzJ69-0000q0-D5 for ipsec@megatron.ietf.org; Thu, 10 Feb 2005 13:31:29 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23829 for ; Thu, 10 Feb 2005 13:31:26 -0500 (EST) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzJQA-0002Cs-83 for ipsec@ietf.org; Thu, 10 Feb 2005 13:52:13 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.2/8.13.2/Debian-1) with ESMTP id j1AIV86H022798; Thu, 10 Feb 2005 20:31:08 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.2/8.13.2/Submit) id j1AIV4Sw022793; Thu, 10 Feb 2005 20:31:04 +0200 Date: Thu, 10 Feb 2005 20:31:04 +0200 Message-Id: <200502101831.j1AIV4Sw022793@burp.tkv.asdf.org> From: Markku Savela To: kent@bbn.com In-reply-to: (message from Stephen Kent on Thu, 10 Feb 2005 10:46:25 -0500) Subject: Re: [Ipsec] IKEv2 needs a "policy usage mode"... References: <200502101249.j1ACnOtI017732@burp.tkv.asdf.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > From: Stephen Kent > > I also think it is questionable to suggest (C) above, as it > encourages expression of policies that IKE cannot negotiate. We > worked hard in 2401bis to align what the SPD can express vs. what IKE > can negotiate, to fix the mismatch from 2401. I will have to reread the 2401bis and try to find where it says that a policy like (remoteport=1 and localport=1) or (remoteport=2 and localport=2) is forbidden. Above is not negotiable in IKEv2. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Feb 10 14:49:08 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29120 for ; Thu, 10 Feb 2005 14:49:08 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzKED-0003Iw-9Y; Thu, 10 Feb 2005 14:43:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzKBD-0002g2-N4 for ipsec@megatron.ietf.org; Thu, 10 Feb 2005 14:40:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28471 for ; Thu, 10 Feb 2005 14:40:45 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzKVH-0003bW-T4 for ipsec@ietf.org; Thu, 10 Feb 2005 15:01:32 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j1AJe2xP028757; Thu, 10 Feb 2005 14:40:02 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <200502101831.j1AIV4Sw022793@burp.tkv.asdf.org> References: <200502101249.j1ACnOtI017732@burp.tkv.asdf.org> <200502101831.j1AIV4Sw022793@burp.tkv.asdf.org> Date: Thu, 10 Feb 2005 14:33:11 -0500 To: Markku Savela From: Stephen Kent Subject: Re: [Ipsec] IKEv2 needs a "policy usage mode"... X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.6 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1162701270==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1162701270== Content-Type: multipart/alternative; boundary="============_-1104058095==_ma============" --============_-1104058095==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 8:31 PM +0200 2/10/05, Markku Savela wrote: > > From: Stephen Kent >> >> I also think it is questionable to suggest (C) above, as it >> encourages expression of policies that IKE cannot negotiate. We >> worked hard in 2401bis to align what the SPD can express vs. what IKE >> can negotiate, to fix the mismatch from 2401. > >I will have to reread the 2401bis and try to find where it says that a >policy like > > (remoteport=1 and localport=1) or (remoteport=2 and localport=2) > >is forbidden. Above is not negotiable in IKEv2. 2401bis, like most IETF standards, emphasizes what one MUST or SHOULD do, and spends less time trying to enumerate all the things one MUST NOT or SHOULD NOT do. You can find the text that states that the SPD has been defined and structured to match what IKE v2 can negotiate. specifically, 4.4.1.2 says: This text describes the SPD in a fashion that maps directly into IKE payloads to ensure that the policy required by SPD entries can be negotiated through IKE. Steve --============_-1104058095==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Ipsec] IKEv2 needs a "policy usage mode"...
At 8:31 PM +0200 2/10/05, Markku Savela wrote:
> From: Stephen Kent <kent@bbn.com>
>
> I also think it is questionable to suggest (C) above, as it
> encourages expression of policies that IKE cannot negotiate. We
> worked hard in 2401bis to align what the SPD can express vs. what IKE
> can negotiate, to fix the mismatch from 2401.

I will have to reread the 2401bis and try to find where it says that a
policy like

  (remoteport=1 and localport=1) or (remoteport=2 and localport=2)
is forbidden. Above is not negotiable in IKEv2.

2401bis, like most IETF standards, emphasizes what one MUST or SHOULD do, and spends less time trying to enumerate all the things one MUST NOT or SHOULD NOT do.

You can find the text that states that the SPD has been defined and structured to match what IKE v2 can negotiate. specifically, 4.4.1.2 says:

This text describes the SPD in a fashion that maps directly into IKE
payloads to ensure that the policy required by SPD entries can be
negotiated through IKE.


Steve
--============_-1104058095==_ma============-- --===============1162701270== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1162701270==-- From ipsec-bounces@ietf.org Thu Feb 10 15:31:09 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04396 for ; Thu, 10 Feb 2005 15:31:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzKqq-0006En-OT; Thu, 10 Feb 2005 15:23:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzKo3-0003dE-Fy for ipsec@megatron.ietf.org; Thu, 10 Feb 2005 15:20:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03089 for ; Thu, 10 Feb 2005 15:20:53 -0500 (EST) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzL85-0004U8-Nj for ipsec@ietf.org; Thu, 10 Feb 2005 15:41:40 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.2/8.13.2/Debian-1) with ESMTP id j1AKKgBm025071; Thu, 10 Feb 2005 22:20:42 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.2/8.13.2/Submit) id j1AKKgvp025068; Thu, 10 Feb 2005 22:20:42 +0200 Date: Thu, 10 Feb 2005 22:20:42 +0200 Message-Id: <200502102020.j1AKKgvp025068@burp.tkv.asdf.org> From: Markku Savela To: kent@bbn.com In-reply-to: (message from Stephen Kent on Thu, 10 Feb 2005 14:33:11 -0500) Subject: Re: [Ipsec] IKEv2 needs a "policy usage mode"... References: <200502101249.j1ACnOtI017732@burp.tkv.asdf.org> <200502101831.j1AIV4Sw022793@burp.tkv.asdf.org> 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 > From: Stephen Kent > This text describes the SPD in a fashion that maps directly into IKE > payloads to ensure that the policy required by SPD entries can be > negotiated through IKE. Which is exactly the reason why so much dislike the IKE messing with policy. It locks IPSec capabilities to particular keymanager implementation that is the current fad. Anyway, I'm somewhat shocked to learn how the IKEv2 limis the policy. It really should cope with policy rules like: (remoteport=1 and localport=1) or (remoteport=2 and localport=2) _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Feb 10 17:54:49 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02320 for ; Thu, 10 Feb 2005 17:54:48 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzMwY-0002s2-BX; Thu, 10 Feb 2005 17:37:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzM3M-0008NI-3N for ipsec@megatron.ietf.org; Thu, 10 Feb 2005 16:40:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA16901 for ; Thu, 10 Feb 2005 16:40:45 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzMNO-0000Bb-W1 for ipsec@ietf.org; Thu, 10 Feb 2005 17:01:33 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j1ALdDVZ005922; Thu, 10 Feb 2005 16:39:13 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <200502102020.j1AKKgvp025068@burp.tkv.asdf.org> References: <200502101249.j1ACnOtI017732@burp.tkv.asdf.org> <200502101831.j1AIV4Sw022793@burp.tkv.asdf.org> <200502102020.j1AKKgvp025068@burp.tkv.asdf.org> Date: Thu, 10 Feb 2005 15:59:38 -0500 To: Markku Savela From: Stephen Kent Subject: Re: [Ipsec] IKEv2 needs a "policy usage mode"... Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 10:20 PM +0200 2/10/05, Markku Savela wrote: > > From: Stephen Kent > >> This text describes the SPD in a fashion that maps directly into IKE >> payloads to ensure that the policy required by SPD entries can be >> negotiated through IKE. > >Which is exactly the reason why so much dislike the IKE messing with >policy. It locks IPSec capabilities to particular keymanager >implementation that is the current fad. Not sure I understand your comment above. One goal for 2401bis was to make sure that we didn't mandate support for SPD features that IKE could not negotiate, since that would suggest manual configuration of SAD entries to support such policies. 2401 did not meet this goal, due to poor coordination, and we hoped to not make the same mistake again. > >Anyway, I'm somewhat shocked to learn how the IKEv2 limis the >policy. It really should cope with policy rules like: > > (remoteport=1 and localport=1) or (remoteport=2 and localport=2) Any complaints you have about what IKE v2 can or cannot negotiate should be directed to Charlie Kaufman, not me :-) Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Feb 10 18:12:37 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05464 for ; Thu, 10 Feb 2005 18:12:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzNIg-0008O8-2h; Thu, 10 Feb 2005 18:00:42 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzN9T-0004KG-AM for ipsec@megatron.ietf.org; Thu, 10 Feb 2005 17:51:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01804 for ; Thu, 10 Feb 2005 17:51:08 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzNTY-0005HX-H8 for ipsec@ietf.org; Thu, 10 Feb 2005 18:11:57 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j1AMobVZ009309 for ; Thu, 10 Feb 2005 17:50:38 -0500 (EST) Mime-Version: 1.0 Message-Id: Date: Thu, 10 Feb 2005 17:50:34 -0500 To: ipsec@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Subject: [Ipsec] another thought X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Karen pointed out that for the PFP feature of the SPD, one would expect to send the original (not the decorrelated) SPOD entry, but after populating the relevant fields from the packet triggering SA creation. SAD entry creation in the context of PFP is already described in 2401bis. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Feb 10 20:26:54 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15957 for ; Thu, 10 Feb 2005 20:26:54 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzPWw-0002kb-HV; Thu, 10 Feb 2005 20:23:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzPVl-0002GV-Al for ipsec@megatron.ietf.org; Thu, 10 Feb 2005 20:22:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA15553 for ; Thu, 10 Feb 2005 20:22:19 -0500 (EST) From: Black_David@emc.com Received: from mailhub.lss.emc.com ([168.159.2.31]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzPps-0000Qf-2a for ipsec@ietf.org; Thu, 10 Feb 2005 20:43:09 -0500 Received: from mxic2.corp.emc.com (mxic2.corp.emc.com [128.221.12.9]) by mailhub.lss.emc.com (Switch-3.1.6/Switch-3.1.6) with ESMTP id j1B1MF0B021505 for ; Thu, 10 Feb 2005 20:22:15 -0500 (EST) Received: by mxic2.corp.emc.com with Internet Mail Service (5.5.2653.19) id ; Thu, 10 Feb 2005 20:22:17 -0500 Message-ID: To: ipsec@ietf.org Date: Thu, 10 Feb 2005 20:22:16 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain X-PerlMx-Spam: Gauge=, SPAM=0%, Reasons='EMC_FROM_0 -0, __IMS_MSGID 0, __HAS_MSGID 0, __SANE_MSGID 0, NO_REAL_NAME 0, __TO_MALFORMED_2 0, __MIME_VERSION 0, __ANY_IMS_MUA 0, __IMS_MUA 0, __HAS_X_MAILER 0, __CT_TEXT_PLAIN 0, __CT 0, __C230066_P5 0, __MIME_TEXT_ONLY 0, EMC_BODY_1 -5' X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Ipsec] Please review: IKEv2 for FC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Some people may recall me mentioning work on Fibre Channel usage of IKEv2 - in essence, Fibre Channel needs a security association negotiation/setup protocol, and reusing IKEv2 is preferable to inventing a new one for many reasons. To be precise, a cut-down and adapted version of IKEv2 is to be used - e.g., things like NAT and EAP are not Fibre Channel concerns, at least not yet ;-). This work has now progressed to the point that there's a Internet-Draft on the additional IKEv2 values that need to be defined for Fibre Channel, draft-maino-fcsp-01.txt: http://www.ietf.org/internet-drafts/draft-maino-fcsp-01.txt One advantage of defining new values is that it makes it fairly easy to prevent IKEv2 proposals from getting confused between IP and FC - if a proposal is accidentally sent in the wrong context, it will be rejected as containing some things that the peer does not support. The only thing that this draft does is define the IKEv2 values needed to setup SAs over Fibre Channel - the actual details of how to carry IKEv2 traffic over Fibre Channel are being specified in T11 (the Fibre Channel standards body), ditto the details of the security protocols used. After review of this draft on this mailing list, the plan is to ask our AD (Russ) to take the revised draft as an individual submission to the IESG for Proposed Standard. Thanks in advance for comments, input, etc., --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Feb 11 03:26:50 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07591 for ; Fri, 11 Feb 2005 03:26:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzW5X-0007KR-OX; Fri, 11 Feb 2005 03:23:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzW0l-0006Ow-NY for ipsec@megatron.ietf.org; Fri, 11 Feb 2005 03:18:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07139 for ; Fri, 11 Feb 2005 03:18:46 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzWKv-0000MU-U1 for ipsec@ietf.org; Fri, 11 Feb 2005 03:39:39 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j1B8Ih4F011138 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 11 Feb 2005 10:18:43 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j1B8IgwV011135; Fri, 11 Feb 2005 10:18:42 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16908.27234.113009.337331@fireball.kivinen.iki.fi> Date: Fri, 11 Feb 2005 10:18:42 +0200 From: Tero Kivinen To: Pasi.Eronen@nokia.com Subject: RE: [Ipsec] IKEv2 needs a "policy usage mode"... In-Reply-To: References: 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: 9182cfff02fae4f1b6e9349e01d62f32 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com writes: > In essence, mode A says that "a host must not propose > something that violates its own policy". (This, of course, > implies that the module sending the proposal must know > what the policy is.) Yes. I.e. host must only give such traffic selectors that it will accept any traffic matching those selectors back from the negotiated SA. If some parts of the traffic selectors are not allowed because of the higher priority rule making hole to the lower priority rule, then they must not be proposed (== in effect use decorrelated policy, there is also another ways to do it). > Implementations that don't follow this are IMHO simply > broken, and I don't think IKEv2 should do anything > special for them. Agree. So I would say lets use A as a default and all others will simply then result in either black holes or INVALID_SELECTORS notifications in case there is policy mismatch > > A) Full policy checking, decorrelated policies on both ends. The only > > mode where narrowing is allowed. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Feb 11 03:38:22 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA08366 for ; Fri, 11 Feb 2005 03:38:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzWGs-0001yN-NU; Fri, 11 Feb 2005 03:35:26 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzWDd-00013i-Ew for ipsec@megatron.ietf.org; Fri, 11 Feb 2005 03:32:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA07985 for ; Fri, 11 Feb 2005 03:32:04 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzWXo-0000cw-HR for ipsec@ietf.org; Fri, 11 Feb 2005 03:52:57 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j1B8VqU3011366 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 11 Feb 2005 10:31:52 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j1B8VpKd011363; Fri, 11 Feb 2005 10:31:51 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16908.28023.38254.815993@fireball.kivinen.iki.fi> Date: Fri, 11 Feb 2005 10:31:51 +0200 From: Tero Kivinen To: Stephen Kent Subject: Re: [Ipsec] Question about "narrowing" ... In-Reply-To: References: <200502071532.j17FWJxv024135@burp.tkv.asdf.org> <16904.37043.173602.79888@fireball.kivinen.iki.fi> <200502081046.j18Akx9d007728@burp.tkv.asdf.org> <200502081203.j18C3Ehh009332@burp.tkv.asdf.org> <16904.46490.990547.717595@fireball.kivinen.iki.fi> <16907.12493.786724.720913@fireball.kivinen.iki.fi> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 7 min X-Total-Time: 10 min 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 Content-Transfer-Encoding: 7bit Stephen Kent writes: > If you do not have an extant SA that matches an outbound packet, you > search the decorrelated SPD to find a match. the matching > decorrelated entry and all entries linked to it because they were > derived from the same original entry, are used to create the SAD > entry, which in turn forms the cache for outbound packet matching. > This is what 2401bis says today in the section on decorrelation > (page 23 of the 05 version, December 2004). That is fine, and yes, in IKE you use the full list of all entries linked together, i.e. created by the same SPD entry. > The text should probably be clarified by noting that the SA > management protocol may "narrow" the resulting SPD entry, i.e., cause > the SAD to be populated with a subset of the linked entries, rather > than all of them, reflecting a mutually agreed upon subset of > original SPD entry that both peers have elected to employ. Yes. But the problem is not only in narrowing. It is in the mismatching policy. If I have policy which says all http traffic uses AES, and all (other) traffic uses 3DES, and I create SA for the all other traffic using the original SPD entry (all traffic uses 3DES), then the other end could be send us a traffic following that rule, including http traffic, which will then be rejected by the other end. So this problem is not in the narrowing, but simply in the case of mismatched policies. The reason it came out as a problem in the narrowing is that the narrowing is only useful or usable if you have mismatched policies, so both these are related to mismatched policies. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Feb 11 03:59:00 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09663 for ; Fri, 11 Feb 2005 03:59:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzWbe-00073b-OO; Fri, 11 Feb 2005 03:56:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzWZv-0006SV-QR for ipsec@megatron.ietf.org; Fri, 11 Feb 2005 03:55:07 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA09455 for ; Fri, 11 Feb 2005 03:55:06 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzWu7-0001Fi-6q for ipsec@ietf.org; Fri, 11 Feb 2005 04:15:59 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j1B8sw6v011525 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Fri, 11 Feb 2005 10:54:58 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j1B8swYV011522; Fri, 11 Feb 2005 10:54:58 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16908.29410.48994.989889@fireball.kivinen.iki.fi> Date: Fri, 11 Feb 2005 10:54:58 +0200 From: Tero Kivinen To: Markku Savela Subject: Re: [Ipsec] IKEv2 needs a "policy usage mode"... In-Reply-To: <200502101831.j1AIV4Sw022793@burp.tkv.asdf.org> References: <200502101249.j1ACnOtI017732@burp.tkv.asdf.org> <200502101831.j1AIV4Sw022793@burp.tkv.asdf.org> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 1 min X-Total-Time: 1 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, kent@bbn.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Markku Savela writes: > I will have to reread the 2401bis and try to find where it says that a > policy like > > (remoteport=1 and localport=1) or (remoteport=2 and localport=2) > > is forbidden. Above is not negotiable in IKEv2. It is negotiable in IKE, but not as with one SA in single create child sa exchange. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Feb 11 07:49:13 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23967 for ; Fri, 11 Feb 2005 07:49:13 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzaBW-00030f-Mq; Fri, 11 Feb 2005 07:46:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzaAz-0002li-5j for ipsec@megatron.ietf.org; Fri, 11 Feb 2005 07:45:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA23803 for ; Fri, 11 Feb 2005 07:45:35 -0500 (EST) Received: from mail-eur1.microsoft.com ([213.199.128.139]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzaVB-0005rO-E0 for ipsec@ietf.org; Fri, 11 Feb 2005 08:06:30 -0500 Received: from EUR-MSG-20.europe.corp.microsoft.com ([65.53.210.18]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Fri, 11 Feb 2005 12:45:03 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Question about "narrowing" ... Date: Fri, 11 Feb 2005 12:45:02 -0000 Message-ID: <892867B805D4DA42A1C48103BF4CFA5A01096D75@EUR-MSG-20.europe.corp.microsoft.com> Thread-Topic: [Ipsec] Question about "narrowing" ... thread-index: AcUN3rbXINaDYDXjQxqqoyxcgOl6xgCVnKDA From: "Michael Roe" To: X-OriginalArrivalTime: 11 Feb 2005 12:45:03.0435 (UTC) FILETIME=[81A691B0:01C51037] X-Spam-Score: 0.0 (/) X-Scan-Signature: 97adf591118a232206bdb5a27b217034 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable =20 Markku Savela writes:=20 > The conclusion here: either policies must match exactly so that > narrowing never occurs, or if policies are not quite matching as in > above, BOTH sides must be using decorrelated policies and reflect this > in already in their offers? >=20 > Seems that IKEv2 would need to know whether other side is using > decorrelated policies or not? >=20 > Remember: decorrelation is not mandatory by 2401bis! I'd noticed this, too. There seems to be a risk of negotiating an SA that doesn't work (some packets sent on it will be rejected by the receiver) unless: (a) The decorrelated SPD is sent in the traffic selectors or (b) The responder has some magic means (outside of IKEv2) of knowing the contents of the initiator's SPD. One way to do this would be to have a vendor-specific protocol that runs before IKEv2, does the actual negotiation, and creates an SPD that IKEv2 can use ... and if you're doing this, you don't need narrowing. Another way to do this is for the sysadmins of the two ends to have a telephone call and spend a couple of hours debugging their SPDs. I think the decorrelated SPD entry ought to be sent in the traffic selectors. Mike _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Feb 11 10:53:56 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09824 for ; Fri, 11 Feb 2005 10:53:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Czd3f-000273-T3; Fri, 11 Feb 2005 10:50:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Czcqe-0006Ex-HQ for ipsec@megatron.ietf.org; Fri, 11 Feb 2005 10:36:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08490 for ; Fri, 11 Feb 2005 10:36:46 -0500 (EST) From: Atul.Sharma@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzdAs-0001NH-Kc for ipsec@ietf.org; Fri, 11 Feb 2005 10:57:44 -0500 Received: from esdks001.ntc.nokia.com (esdks001.ntc.nokia.com [172.21.138.120]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1BFaic16638; Fri, 11 Feb 2005 17:36:44 +0200 (EET) X-Scanned: Fri, 11 Feb 2005 17:44:19 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks001.ntc.nokia.com (8.12.9/8.12.9) id j1BFiJdY032446; Fri, 11 Feb 2005 17:44:19 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks001.ntc.nokia.com 00BRiSQc; Fri, 11 Feb 2005 17:44:18 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1BFWNM29739; Fri, 11 Feb 2005 17:32:23 +0200 (EET) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 11 Feb 2005 09:30:24 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 11 Feb 2005 10:30:22 -0500 Message-ID: Thread-Topic: Asymmetric Security Thread-Index: AcUQTpnUEz8hOuQbS/i127voUDpGJA== To: , X-OriginalArrivalTime: 11 Feb 2005 15:30:24.0061 (UTC) FILETIME=[9ACDF6D0:01C5104E] X-Spam-Score: 0.3 (/) X-Scan-Signature: 5a9a1bd6c2d06a21d748b7d0070ddcb8 Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] Asymmetric Security X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi All, I wanted to start a discussion on Asymmetric Security. Asymmetry can show up in different ways in a secure transmission. For = example: * we can have asymmetry in the gateways involved in secure = transmission.=20 * we can have asymmetry in the tunnels between two possible multihomed=20 gateways * we can have asymmetry in the tunnel endpoints of the a tunnel (1) Asymmetry in Gateways:=20 Let us say there are three gateways A, B, C. In the forward direction = secure traffic=20 flows from Gateway A to Gateway B. In the reverse direction traffic = flows from=20 Gateway C to Gateway A. A Mobile IP End-to-End Security between a=20 correspondent node and a mobile node will be an example scenario here. IKE negotiations between A and B can setup a tunnel and IKE negotiations between C and A can set up the tunnels. Both the tunnels shall still = protect the same hosts/addresses. [Since IKE negotiations do not allow asymmetry we = will have to have two separate IKE negotiations] (2) Asymmetry in Tunnels: Let us say there are two multihomed Gateways. These gateways negotiate = TWO=20 tunnels, each with different tunnel endpoints (corresponding to = multihomed addresses). But both the tunnels still protecting the same hosts/addresses. This can = be a real life scenario to acheive redundancy/high availability (3) Asymmetry in Tunnel Endpoints Let us say there are two multihome Gateways. These gateways negotiate = ONE tunnel, but with different tunnel endpoints in forward and reverse direction. = Something recently discussed in MOBIKE mailing list. I wanted to ask folks if current efforts (standards, or to-be-standards) = solve all the=20 Asymmetry needs of Security? Does it make sense to start new efforts to = deal=20 Asymmetry in Security (ASEC )?=20 Should we have a BoF, when we can, to discuss the Asymmetric needs of = Security? Atul _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Feb 11 12:45:56 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19115 for ; Fri, 11 Feb 2005 12:45:56 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzemM-00038C-PT; Fri, 11 Feb 2005 12:40:30 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzefD-00015n-RU for ipsec@megatron.ietf.org; Fri, 11 Feb 2005 12:33:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA17866 for ; Fri, 11 Feb 2005 12:33:05 -0500 (EST) Received: from mail-eur.microsoft.com ([213.199.128.145]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1CzezS-0004Mg-TF for ipsec@ietf.org; Fri, 11 Feb 2005 12:54:04 -0500 Received: from EUR-MSG-20.europe.corp.microsoft.com ([65.53.210.18]) by mail-eur.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 11 Feb 2005 17:32:27 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] IKEv2 needs a "policy usage mode"... Date: Fri, 11 Feb 2005 17:32:29 -0000 Message-ID: <892867B805D4DA42A1C48103BF4CFA5A01096FD1@EUR-MSG-20.europe.corp.microsoft.com> Thread-Topic: [Ipsec] IKEv2 needs a "policy usage mode"... thread-index: AcUQGDxkjlGRcV9LSpup0+LL1ZbpKQAQgtfQ From: "Michael Roe" To: X-OriginalArrivalTime: 11 Feb 2005 17:32:27.0121 (UTC) FILETIME=[A7B03E10:01C5105F] X-Spam-Score: 0.0 (/) X-Scan-Signature: 25620135586de10c627e3628c432b04a Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable > Markku Savela writes: > > I will have to reread the 2401bis and try to find where it=20 > says that a > > policy like > >=20 > > (remoteport=3D1 and localport=3D1) or (remoteport=3D2 and = localport=3D2) > >=20 > > is forbidden. Above is not negotiable in IKEv2. Tero Kivinen replies: > It is negotiable in IKE, but not as with one SA in single create child > sa exchange. I agree with Markku that 2401bis allows SPD entries that IKEv2 is unable to represent in a single create child SA exchange. These entries can often arise as a result of decorrelating the SPD (which means that this issue is connected with the other thread, on whether the ordered or the decorrelated SPD entry is used to create the traffic selectors). As Tero says, you can always split the entry up into multiple=20 security associations. This leaks some information about the plaintext to the attacker, because the attacker can see which SA is used. In many cases, this may not matter. Here's an example, which I hope I've got right: local addr | local port | remote addr | remote port | action X TCP * * 25 APPLY(3DES) Y TCP * * 80 APPLY(3DES) X or Y TCP * * * APPLY(AES) The third entry decorrelates to: local addr | local port | remote addr | remote port | action X * * 1-24 } X * * 26-MAX } Y * * 1-79 } APPLY(AES) Y * * 81-MAX } This can't be represented in a single create-child-sa, but it can be represented in two: 1) Tsi =3D (TCP, X, ANY) Tsr =3D (TCP, ANY, 1-24),(TCP, ANY, 26-MAX) 2) Tsi =3D (TCP, Y, ANY) Tsr =3D (TCP, ANY, 1-79),(TCP, ANY, 81-MAX) The effect of this is that you get two security associations where you might have expected one, and an eavesdropper on the link can distinguish packets from X from packets from Y. Mike PS. As far as I can tell, this problem didn't occur with IKEv1 and IPsecv1 because RFC2401 says this: NOTE: The correct "matching" policy will not necessarily be the first inbound policy found. If the check in (4) fails, steps (3) and (4) are repeated until all policy entries have been checked or until the check succeeds. So in IKEv1, it was OK to negotiate an SA with=20 local addr =3D X or Y, action =3D APPLY(AES) and an incoming packet on this SA from port 25 to host X would be accepted, even though there was a higher precedence SPD entry that says this packet should be protected with 3DES. In the 2401bis, we don't have this note, and this packet will get dropped. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Feb 11 13:36:16 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23606 for ; Fri, 11 Feb 2005 13:36:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzfVt-0003LC-Tr; Fri, 11 Feb 2005 13:27:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1CzfRa-0001gO-88 for ipsec@megatron.ietf.org; Fri, 11 Feb 2005 13:23:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22760 for ; Fri, 11 Feb 2005 13:23:01 -0500 (EST) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Czfll-0005pD-FI for ipsec@ietf.org; Fri, 11 Feb 2005 13:44:01 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.2/8.13.2/Debian-1) with ESMTP id j1BIMugQ011240; Fri, 11 Feb 2005 20:22:56 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.2/8.13.2/Submit) id j1BIMu7k011237; Fri, 11 Feb 2005 20:22:56 +0200 Date: Fri, 11 Feb 2005 20:22:56 +0200 Message-Id: <200502111822.j1BIMu7k011237@burp.tkv.asdf.org> From: Markku Savela To: mroe@microsoft.com In-reply-to: <892867B805D4DA42A1C48103BF4CFA5A01096FD1@EUR-MSG-20.europe.corp.microsoft.com> (mroe@microsoft.com) Subject: Re: [Ipsec] IKEv2 needs a "policy usage mode"... References: <892867B805D4DA42A1C48103BF4CFA5A01096FD1@EUR-MSG-20.europe.corp.microsoft.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: 856eb5f76e7a34990d1d457d8e8e5b7f Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > From: "Michael Roe" > So in IKEv1, it was OK to negotiate an SA with > local addr = X or Y, action = APPLY(AES) > and an incoming packet on this SA from port 25 to host > X would be accepted, even though there was a higher precedence > SPD entry that says this packet should be protected with 3DES. Just to set record right, thats not quite true. Even with old IKEv1/2401, if policy said port 25 is to be protected with 3DES, such packet arriving viad AES SA would not be accepted. The old IPSec was not that broken! There might have been broken implementations! The NOTE you referred was supposed to tell the implementers not to fall into that trap. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Feb 14 07:34:38 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA25162 for ; Mon, 14 Feb 2005 07:34:38 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0fJi-00063j-1V; Mon, 14 Feb 2005 07:27:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0fI4-0005s0-F1 for ipsec@megatron.ietf.org; Mon, 14 Feb 2005 07:25:24 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA24527 for ; Mon, 14 Feb 2005 07:25:22 -0500 (EST) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0fct-0000BP-PY for ipsec@ietf.org; Mon, 14 Feb 2005 07:46:56 -0500 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.11.6+Sun/8.11.6) with ESMTP id j1ECOi202960; Mon, 14 Feb 2005 14:24:44 +0200 (IST) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v619.2) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit From: Yoav Nir Subject: Re: [Ipsec] Asymmetric Security Date: Mon, 14 Feb 2005 14:24:43 +0200 To: Atul.Sharma@nokia.com X-Mailer: Apple Mail (2.619.2) X-Spam-Score: 0.0 (/) X-Scan-Signature: b280b4db656c3ca28dd62e5e0b03daa8 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, mobike@machshav.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit I would add a fourth scenario, which is actually a variation. (4) Asymmetry in clustered gateways Let us say that there are several gateways (call them A1 and A2) that appear to be a single gateway (i.e, have one identifier, one certificate, one IP address) with some load-sharing clustering hardware or software. Any peer (call it C) must never see anything other than a single gateway (call it A). The problem is that due to performance constraints, the two gateways cannot synchronize their state after every packet, and because of the retransmission counter of ESP, they need to have two SAs, one for A1 and one for A2. In IKEv1 this was a problem, because IKE implementations were not required to support multiple redundant SAs (and to C, it looks like the two SAs are redundant). Such implementations always deleted one of the SAs. In IKEv2 C is required to support multiple redundant SAs. On Feb 11, 2005, at 5:30 PM, Atul.Sharma@nokia.com wrote: > Hi All, > > I wanted to start a discussion on Asymmetric Security. > > Asymmetry can show up in different ways in a secure transmission. For > example: > * we can have asymmetry in the gateways involved in secure > transmission. > * we can have asymmetry in the tunnels between two possible multihomed > gateways > * we can have asymmetry in the tunnel endpoints of the a tunnel > > > (1) Asymmetry in Gateways: > Let us say there are three gateways A, B, C. In the forward direction > secure traffic > flows from Gateway A to Gateway B. In the reverse direction traffic > flows from > Gateway C to Gateway A. A Mobile IP End-to-End Security between a > correspondent node and a mobile node will be an example scenario here. > IKE negotiations between A and B can setup a tunnel and IKE > negotiations > between C and A can set up the tunnels. Both the tunnels shall still > protect the > same hosts/addresses. [Since IKE negotiations do not allow asymmetry > we will > have to have two separate IKE negotiations] > > (2) Asymmetry in Tunnels: > Let us say there are two multihomed Gateways. These gateways negotiate > TWO > tunnels, each with different tunnel endpoints (corresponding to > multihomed addresses). > But both the tunnels still protecting the same hosts/addresses. This > can be a real > life scenario to acheive redundancy/high availability > > (3) Asymmetry in Tunnel Endpoints > Let us say there are two multihome Gateways. These gateways negotiate > ONE tunnel, > but with different tunnel endpoints in forward and reverse direction. > Something recently > discussed in MOBIKE mailing list. > > > I wanted to ask folks if current efforts (standards, or > to-be-standards) solve all the > Asymmetry needs of Security? Does it make sense to start new efforts > to deal > Asymmetry in Security (ASEC )? > > Should we have a BoF, when we can, to discuss the Asymmetric needs of > Security? > > > Atul > > > > _______________________________________________ > 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 Feb 14 09:29:45 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07479 for ; Mon, 14 Feb 2005 09:29:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0h5I-0000eD-17; Mon, 14 Feb 2005 09:20:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0h0G-0008T5-BX for ipsec@megatron.ietf.org; Mon, 14 Feb 2005 09:15:08 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA06256 for ; Mon, 14 Feb 2005 09:15:06 -0500 (EST) From: Atul.Sharma@nokia.com Received: from mgw-x2.nokia.com ([131.228.20.22]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0hL6-0003DN-VU for ipsec@ietf.org; Mon, 14 Feb 2005 09:36:41 -0500 Received: from esdks004.ntc.nokia.com (esdks004.ntc.nokia.com [172.21.138.159]) by mgw-x2.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1EEExI21557; Mon, 14 Feb 2005 16:14:59 +0200 (EET) X-Scanned: Mon, 14 Feb 2005 16:10:44 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks004.ntc.nokia.com (8.12.9/8.12.9) id j1EEAicM009093; Mon, 14 Feb 2005 16:10:44 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks004.ntc.nokia.com 00DzgTTF; Mon, 14 Feb 2005 16:10:42 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1EEAgJ26400; Mon, 14 Feb 2005 16:10:42 +0200 (EET) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 14 Feb 2005 08:10:41 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Asymmetric Security Date: Mon, 14 Feb 2005 09:10:39 -0500 Message-ID: Thread-Topic: [Ipsec] Asymmetric Security Thread-Index: AcUSkKcexLIMXeD8QkaY9xqDGvaHzwADEjsQ To: X-OriginalArrivalTime: 14 Feb 2005 14:10:41.0684 (UTC) FILETIME=[F7866540:01C5129E] X-Spam-Score: 0.3 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, mobike@machshav.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Thanks Yoav, for bringing another scenario needing Asymmetric support. More such scenarios we can bring the better. The question is whether IKEv2 and 2401bis are sufficient to handle the Asymmetric Security needs or do we need something extra? Things like:=20 Do we allow different tunnel endpoints in the two direction of a tunnel?=20 Do we allow IKE negotiations to be asymmetric? OR Anyhting needed to support the Asymmetric Scenarios brought up? Could members on the MOBIKE and IPsec lists comment on the Asymmetric support in current efforts? And need for a possible new Asymmetric=20 Security efforts? Do we need to seek input from other WG lists? Atul > -----Original Message----- > From: ext Yoav Nir [mailto:ynir@checkpoint.com] > Sent: Monday, February 14, 2005 7:25 AM > To: Sharma Atul (Nokia-ES/Boston) > Cc: mobike@machshav.com; ipsec@ietf.org > Subject: Re: [Ipsec] Asymmetric Security >=20 >=20 > I would add a fourth scenario, which is actually a variation. >=20 > (4) Asymmetry in clustered gateways > Let us say that there are several gateways (call them A1 and A2) that=20 > appear to be a single gateway (i.e, have one identifier, one=20 > certificate, one IP address) with some load-sharing=20 > clustering hardware=20 > or software. Any peer (call it C) must never see anything=20 > other than a=20 > single gateway (call it A). The problem is that due to performance=20 > constraints, the two gateways cannot synchronize their state after=20 > every packet, and because of the retransmission counter of ESP, they=20 > need to have two SAs, one for A1 and one for A2. In IKEv1 this was a=20 > problem, because IKE implementations were not required to support=20 > multiple redundant SAs (and to C, it looks like the two SAs are=20 > redundant). Such implementations always deleted one of the SAs. In=20 > IKEv2 C is required to support multiple redundant SAs. >=20 > On Feb 11, 2005, at 5:30 PM, Atul.Sharma@nokia.com wrote: >=20 > > Hi All, > > > > I wanted to start a discussion on Asymmetric Security. > > > > Asymmetry can show up in different ways in a secure=20 > transmission. For=20 > > example: > > * we can have asymmetry in the gateways involved in secure=20 > > transmission. > > * we can have asymmetry in the tunnels between two=20 > possible multihomed > > gateways > > * we can have asymmetry in the tunnel endpoints of the a tunnel > > > > > > (1) Asymmetry in Gateways: > > Let us say there are three gateways A, B, C. In the forward=20 > direction=20 > > secure traffic > > flows from Gateway A to Gateway B. In the reverse direction traffic=20 > > flows from > > Gateway C to Gateway A. A Mobile IP End-to-End Security between a > > correspondent node and a mobile node will be an example=20 > scenario here. > > IKE negotiations between A and B can setup a tunnel and IKE=20 > > negotiations > > between C and A can set up the tunnels. Both the tunnels=20 > shall still=20 > > protect the > > same hosts/addresses. [Since IKE negotiations do not allow=20 > asymmetry=20 > > we will > > have to have two separate IKE negotiations] > > > > (2) Asymmetry in Tunnels: > > Let us say there are two multihomed Gateways. These=20 > gateways negotiate=20 > > TWO > > tunnels, each with different tunnel endpoints (corresponding to=20 > > multihomed addresses). > > But both the tunnels still protecting the same=20 > hosts/addresses. This=20 > > can be a real > > life scenario to acheive redundancy/high availability > > > > (3) Asymmetry in Tunnel Endpoints > > Let us say there are two multihome Gateways. These gateways=20 > negotiate=20 > > ONE tunnel, > > but with different tunnel endpoints in forward and reverse=20 > direction.=20 > > Something recently > > discussed in MOBIKE mailing list. > > > > > > I wanted to ask folks if current efforts (standards, or=20 > > to-be-standards) solve all the > > Asymmetry needs of Security? Does it make sense to start=20 > new efforts=20 > > to deal > > Asymmetry in Security (ASEC )? > > > > Should we have a BoF, when we can, to discuss the=20 > Asymmetric needs of=20 > > Security? > > > > > > Atul > > > > > > > > _______________________________________________ > > Ipsec mailing list > > Ipsec@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipsec >=20 >=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 15 00:09:00 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27865 for ; Tue, 15 Feb 2005 00:08:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0uuj-0002du-Lv; Tue, 15 Feb 2005 00:06:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0uu3-0002ZG-NV for ipsec@megatron.ietf.org; Tue, 15 Feb 2005 00:05:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27482 for ; Tue, 15 Feb 2005 00:05:35 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0vF1-00022D-P3 for ipsec@ietf.org; Tue, 15 Feb 2005 00:27:20 -0500 Received: from [10.1.190.35] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j1F54pkJ019687; Tue, 15 Feb 2005 00:04:52 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 14 Feb 2005 23:54:40 -0500 To: Yoav Nir From: Stephen Kent Subject: [Mobike] Re: [Ipsec] Asymmetric Security Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Cc: ipsec@ietf.org, Atul.Sharma@nokia.com, mobike@machshav.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 2:24 PM +0200 2/14/05, Yoav Nir wrote: >I would add a fourth scenario, which is actually a variation. > >(4) Asymmetry in clustered gateways >Let us say that there are several gateways (call them A1 and A2) >that appear to be a single gateway (i.e, have one identifier, one >certificate, one IP address) with some load-sharing clustering >hardware or software. Any peer (call it C) must never see anything >other than a single gateway (call it A). The problem is that due to >performance constraints, the two gateways cannot synchronize their >state after every packet, and because of the retransmission counter >of ESP, they need to have two SAs, one for A1 and one for A2. In >IKEv1 this was a problem, because IKE implementations were not >required to support multiple redundant SAs (and to C, it looks like >the two SAs are redundant). Such implementations always deleted one >of the SAs. In IKEv2 C is required to support multiple redundant >SAs. As you noted, it is not generally feasible for two devices to appear to be one device, due to sequence number management constraints. Also, there is this small matter of synchronizing the keys generated for the SAs between the two devices, in a secure fashion. So, a solution today is to create distinct SAs to each device, and recognize that they represent parallel SGs and don't try to make them look like one SG. What would you want IPsec to do differently, and what implications have you discovered as a result of any proposed changes? Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 15 00:13:22 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28154 for ; Tue, 15 Feb 2005 00:13:22 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0uuk-0002e0-GK; Tue, 15 Feb 2005 00:06:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0uu3-0002ZH-Lm for ipsec@megatron.ietf.org; Tue, 15 Feb 2005 00:05:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27484 for ; Tue, 15 Feb 2005 00:05:36 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0vF1-00022E-QA for ipsec@ietf.org; Tue, 15 Feb 2005 00:27:20 -0500 Received: from [10.1.190.35] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j1F552kJ019699; Tue, 15 Feb 2005 00:05:03 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 15 Feb 2005 00:04:56 -0500 To: Atul.Sharma@nokia.com From: Stephen Kent Subject: Re: [Ipsec] Asymmetric Security Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Cc: ipsec@ietf.org, mobike@machshav.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 10:30 AM -0500 2/11/05, Atul.Sharma@nokia.com wrote: >Hi All, > >I wanted to start a discussion on Asymmetric Security. > >Asymmetry can show up in different ways in a secure transmission. For example: > * we can have asymmetry in the gateways involved in secure >transmission. > * we can have asymmetry in the tunnels between two possible multihomed > gateways > * we can have asymmetry in the tunnel endpoints of the a tunnel > > >(1) Asymmetry in Gateways: >Let us say there are three gateways A, B, C. In the forward >direction secure traffic >flows from Gateway A to Gateway B. In the reverse direction traffic flows from >Gateway C to Gateway A. A Mobile IP End-to-End Security between a >correspondent node and a mobile node will be an example scenario here. >IKE negotiations between A and B can setup a tunnel and IKE negotiations >between C and A can set up the tunnels. Both the tunnels shall still >protect the >same hosts/addresses. [Since IKE negotiations do not allow asymmetry we will >have to have two separate IKE negotiations] so, what's the problem? you have separate SAs because you have different endpoints. we decided long ago to create SAs in pairs. are you concerned that the state maintained for the unused SAs is a unacceptable burden? > >(2) Asymmetry in Tunnels: >Let us say there are two multihomed Gateways. These gateways negotiate TWO >tunnels, each with different tunnel endpoints (corresponding to >multihomed addresses). >But both the tunnels still protecting the same hosts/addresses. This >can be a real >life scenario to acheive redundancy/high availability again, what is the problem here? >(3) Asymmetry in Tunnel Endpoints >Let us say there are two multihome Gateways. These gateways >negotiate ONE tunnel, >but with different tunnel endpoints in forward and reverse >direction. Something recently >discussed in MOBIKE mailing list. as I noted in a separate response, this scenario needs a better description, given the use of terms above. >I wanted to ask folks if current efforts (standards, or >to-be-standards) solve all the >Asymmetry needs of Security? Does it make sense to start new efforts to deal >Asymmetry in Security (ASEC )? > >Should we have a BoF, when we can, to discuss the Asymmetric needs >of Security? I think you have a long way to go before you establish the need for a BoF. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 15 00:15:39 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA28364 for ; Tue, 15 Feb 2005 00:15:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0uul-0002e7-FO; Tue, 15 Feb 2005 00:06:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0uu3-0002ZI-W7 for ipsec@megatron.ietf.org; Tue, 15 Feb 2005 00:05:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA27490 for ; Tue, 15 Feb 2005 00:05:36 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0vF1-00022C-Mp for ipsec@ietf.org; Tue, 15 Feb 2005 00:27:20 -0500 Received: from [10.1.190.35] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j1F54pkL019687; Tue, 15 Feb 2005 00:04:54 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 14 Feb 2005 23:54:54 -0500 To: From: Stephen Kent Subject: [Mobike] RE: [Ipsec] Asymmetric Security Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: ipsec@ietf.org, mobike@machshav.com, ynir@checkpoint.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 9:10 AM -0500 2/14/05, wrote: >Thanks Yoav, for bringing another scenario needing Asymmetric support. >More such scenarios we can bring the better. > >The question is whether IKEv2 and 2401bis are sufficient to handle >the Asymmetric Security needs or do we need something extra? Things >like: > Do we allow different tunnel endpoints in the two direction of > a tunnel? this is not a well-formed question; a tunnel is composed of two SAs. what do you mean to ask here? > Do we allow IKE negotiations to be asymmetric? again, not well-formed. are you referring to anything other than S/D addresses? how about ports? Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 15 01:55:44 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA06315 for ; Tue, 15 Feb 2005 01:55:44 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0waV-0006ok-Tz; Tue, 15 Feb 2005 01:53:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D0wXP-0006Ri-Ow for ipsec@megatron.ietf.org; Tue, 15 Feb 2005 01:50:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05818 for ; Tue, 15 Feb 2005 01:50:22 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.193]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D0wsO-0004Ga-EX for ipsec@ietf.org; Tue, 15 Feb 2005 02:12:05 -0500 Received: by wproxy.gmail.com with SMTP id 71so876299wri for ; Mon, 14 Feb 2005 22:49:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:mime-version:content-type:content-transfer-encoding; b=NFW6Up6m4WgW1nnba/lQlJI5mfBcyiibOi8vuh7ZIJUOQxohAF2xuVFORMgyeLOPqmCzWWRLUVC3pPfdJMkN2zYQzW/duRy7TzB29sKK0qNNL4pGQKQqi7ufUGEF0cz5m5wifyJNN+EF/j8DzS7E0lRyVwgezbMaKL4d3wGwEKY= Received: by 10.54.16.79 with SMTP id 79mr60987wrp; Mon, 14 Feb 2005 22:49:51 -0800 (PST) Received: by 10.54.40.21 with HTTP; Mon, 14 Feb 2005 22:49:51 -0800 (PST) Message-ID: <41ae44840502142249461c01d@mail.gmail.com> Date: Tue, 15 Feb 2005 12:19:51 +0530 From: Kausty To: ipsec@ietf.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aefe408d50e9c7c47615841cb314bed Content-Transfer-Encoding: 7bit Subject: [Ipsec] microsoft IKEv2 IPR X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kausty List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit hi what is the significance of the ms ipr related to ikev2? i was not able to locate a clear definition of the ipr , what impact does it have on implementors of ikev2? thanks and regards kausty _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 15 09:19:50 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03764 for ; Tue, 15 Feb 2005 09:19:50 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D13T0-0007gN-TI; Tue, 15 Feb 2005 09:14:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D13Rk-0007Sq-8y for ipsec@megatron.ietf.org; Tue, 15 Feb 2005 09:13:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03242 for ; Tue, 15 Feb 2005 09:12:56 -0500 (EST) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D13mk-0005bZ-4G for ipsec@ietf.org; Tue, 15 Feb 2005 09:34:43 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.2/8.13.2/Debian-1) with ESMTP id j1FECpL5027895 for ; Tue, 15 Feb 2005 16:12:51 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.2/8.13.2/Submit) id j1FECl1i027890; Tue, 15 Feb 2005 16:12:47 +0200 Date: Tue, 15 Feb 2005 16:12:47 +0200 Message-Id: <200502151412.j1FECl1i027890@burp.tkv.asdf.org> From: Markku Savela To: ipsec@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: cf3becbbd6d1a45acbe2ffd4ab88bdc2 Subject: [Ipsec] Some comments on draft-ietf-ipsec-rfc2401bis-05.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 Few minor comments on this draft. ------- 4.1 Definition and Scope ... For an SA used to carry unicast traffic, the SPI (Security Parameters Index - see Appendix A and AH [Ken04b] and ESP [Ken04a] specifications) by itself suffices to specify an SA. ... ------- Shouldn't this be qualified as "For an inbound SA ...". For outbound, we naturally can have multiple SA's with same SPI, but different destinations? ------- 4.4.1.1 Selectors ... - Name: This is not a selector like the others above. It is not acquired from a packet. A name may be used as a symbolic identifier for an IPsec Local or Remote address. Named SPD entries are used in two ways: ... 4.4.1.2 Structure of an SPD entry .... o Name -- a list of IDs. This quasi-selector is optional. The forms that MUST be supported are described above in Section 4.4.1.1 under "Name". .... o One to N selector sets that correspond to the "condition" for applying a particular IPsec action. Each selector set contains: - Local Address - Remote Address - Next Layer Protocol - Local Port, or ICMP message type/code or Mobility Header type (depending on the next layer protocol) - Remote Port, or ICMP message type/code or Mobility Header type (depending on the next layer protocol) ------- If "name" is supposed to be used as an identifier of local or remote address, shouldn't that be somehow mentioned in the "N selector sets" description? I don't know how to interpret a plain selector with list of names, as there is no context whether a name is supposed to be remote or local address (when that interpretation is inteded). To me it would seem natural to allow a name where expilicit address is possible. In addition to above, a generic observation: the boolean expression combining the individual selector tests is not specified. ------- 4.4.2 Security Association Database (SAD) ... For each of the selectors defined in Section 4.4.1.1, the entry for an inbound SA in the SAD MUST be initially populated with the value or values negotiated at the time the SA was created. (See Section 4.4.1, paragraph on Handling Changes to the SPD while the System is Running for guidance on the effect of SPD changes on extant SAs.) For a receiver, these values are used to check that the header fields of an inbound packet (after IPsec processing) match the selector values negotiated for the SA. Thus, the SAD acts as a cache for checking the selectors of inbound traffic arriving on SAs. For the receiver, this is part of verifying that a packet arriving on an SA is consistent with the policy for the SA. .... ------- The last sentence is not true, unless the selectors in SA are decorrelated. This is explained later in "5. IP Traffic Processing". But, perhaps above should also be amended, so that a reader is not mislead here. ------- At the moment I don't have anything else. For me some concepts are more confusing than clarifying: - protected/unprotected side - obsession with interfaces They are perhaps natural for security gateway, but for a host with IPSEC inside the TCP/IP stack, those are not very helpful (at least the way I see the implementation). For a host, the model can be very simple: you just have incoming and outgoing packets, policy either matches or not, it does not matter what interfaces are involved. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 15 09:27:16 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04415 for ; Tue, 15 Feb 2005 09:27:16 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D13e1-0000ce-R9; Tue, 15 Feb 2005 09:25:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D13cH-0000Rz-Tl for ipsec@megatron.ietf.org; Tue, 15 Feb 2005 09:23:54 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04195 for ; Tue, 15 Feb 2005 09:23:52 -0500 (EST) From: Atul.Sharma@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D13xL-0005tU-FP for ipsec@ietf.org; Tue, 15 Feb 2005 09:45:39 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1FENbc12043; Tue, 15 Feb 2005 16:23:42 +0200 (EET) X-Scanned: Tue, 15 Feb 2005 16:19:02 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j1FEJ2Zi009593; Tue, 15 Feb 2005 16:19:02 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks002.ntc.nokia.com 00nmy3kt; Tue, 15 Feb 2005 16:14:46 EET Received: from daebh001.NOE.Nokia.com (daebh001.americas.nokia.com [10.241.35.121]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1FEDuM06006; Tue, 15 Feb 2005 16:13:57 +0200 (EET) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 15 Feb 2005 08:12:52 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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] Asymmetric Security Date: Tue, 15 Feb 2005 09:12:50 -0500 Message-ID: Thread-Topic: [Ipsec] Asymmetric Security Thread-Index: AcUTHB67SyBEKeXgSoemmvS91FiwtQASrNTg To: X-OriginalArrivalTime: 15 Feb 2005 14:12:52.0646 (UTC) FILETIME=[6FFF5C60:01C51368] X-Spam-Score: 0.3 (/) X-Scan-Signature: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, mobike@machshav.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Steve, Some comments/clarifications inline. Best, Atul > -----Original Message----- > From: ext Stephen Kent [mailto:kent@bbn.com] > Sent: Tuesday, February 15, 2005 12:05 AM > To: Sharma Atul (Nokia-ES/Boston) > Cc: ipsec@ietf.org; mobike@machshav.com > Subject: Re: [Ipsec] Asymmetric Security >=20 >=20 > At 10:30 AM -0500 2/11/05, Atul.Sharma@nokia.com wrote: > >Hi All, > > > >I wanted to start a discussion on Asymmetric Security. > > > >Asymmetry can show up in different ways in a secure=20 > transmission. For example: > > * we can have asymmetry in the gateways involved in secure=20 > >transmission. > > * we can have asymmetry in the tunnels between two=20 > possible multihomed > > gateways > > * we can have asymmetry in the tunnel endpoints of the a tunnel > > > > > >(1) Asymmetry in Gateways: > >Let us say there are three gateways A, B, C. In the forward=20 > >direction secure traffic > >flows from Gateway A to Gateway B. In the reverse direction=20 > traffic flows from > >Gateway C to Gateway A. A Mobile IP End-to-End Security between a > >correspondent node and a mobile node will be an example=20 > scenario here. > >IKE negotiations between A and B can setup a tunnel and IKE=20 > negotiations > >between C and A can set up the tunnels. Both the tunnels shall still=20 > >protect the > >same hosts/addresses. [Since IKE negotiations do not allow=20 > asymmetry we will > >have to have two separate IKE negotiations] >=20 > so, what's the problem? you have separate SAs because you have=20 > different endpoints. we decided long ago to create SAs in pairs. are=20 > you concerned that the state maintained for the unused SAs is a=20 > unacceptable burden? Only that there is no unused SAs or rather no unused SA pairs. There = will be two SA pairs negotiated each with different tunnel endpoints. In the first SA pair only the forward SA will be used, in the second SA pair = only the reverse SA will be used. Is something like this already allowed? One SA in each pair shall be unused, which need not even be maintained. A related question: Do we allow IKE negotiations to be asymmetric, i.e. = IKE message goes to an address, but the response comes back from a different address? > >(2) Asymmetry in Tunnels: > >Let us say there are two multihomed Gateways. These gateways=20 > negotiate TWO > >tunnels, each with different tunnel endpoints (corresponding to=20 > >multihomed addresses). > >But both the tunnels still protecting the same hosts/addresses. This=20 > >can be a real > >life scenario to acheive redundancy/high availability >=20 > again, what is the problem here? Allowing two tunnels protecting the same addresses/hosts, but with = differnt tunnel endpoints. Is this something allowed now? _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 15 09:35:41 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05203 for ; Tue, 15 Feb 2005 09:35:41 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D13l0-0001aa-OK; Tue, 15 Feb 2005 09:32:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D13jp-0001UC-7g for ipsec@megatron.ietf.org; Tue, 15 Feb 2005 09:31:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04903 for ; Tue, 15 Feb 2005 09:31:35 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D144m-00064O-9W for ipsec@ietf.org; Tue, 15 Feb 2005 09:53:21 -0500 Received: from kolumbus.fi (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 9025F89883 for ; Tue, 15 Feb 2005 16:31:01 +0200 (EET) Message-ID: <4212074E.7@kolumbus.fi> Date: Tue, 15 Feb 2005 16:29:34 +0200 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040316 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@ietf.org Subject: Re: [Mobike] Re: [Ipsec] Asymmetric Security References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: 7bit X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit I think asymmetric scenarios can be interesting in some cases. But I would recommend discussing the specific problems in the context that they came up. For instance, we are discussing in MOBIKE WG on whether the two peers must always use the same pair of addresses or if they can end up using different addresses due to failures or movements. The answer to this question has a lot to do with the complexity of the failure detection and address pair decision algorithms; this is quite specific to MOBIKE. I have seen Yoav's cluster scenario pop up several times, so it looks like a valid requirement. But exactly how that should be solved (separate gateways or not) and whether current specifications need some enhancement for this is something that the IPsec WG should discuss. (There's perhaps a meta-issue of how IPsec architecture and IKE maintenance will happen in the future, if the IPsec WG is shut down as predicted. But that's a general procedural issue, and not specific to asymmetry.) --Jari _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 15 09:44:40 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05900 for ; Tue, 15 Feb 2005 09:44:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D13tJ-0002s2-Ea; Tue, 15 Feb 2005 09:41:29 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D13rP-0002XB-U2 for ipsec@megatron.ietf.org; Tue, 15 Feb 2005 09:39:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA05558 for ; Tue, 15 Feb 2005 09:39:30 -0500 (EST) From: Atul.Sharma@nokia.com Received: from mgw-x4.nokia.com ([131.228.20.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D14CS-0006IJ-Kv for ipsec@ietf.org; Tue, 15 Feb 2005 10:01:18 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x4.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1FEdA902996; Tue, 15 Feb 2005 16:39:10 +0200 (EET) X-Scanned: Tue, 15 Feb 2005 16:37:30 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j1FEbUbB025065; Tue, 15 Feb 2005 16:37:30 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks003.ntc.nokia.com 00FN0Jvk; Tue, 15 Feb 2005 16:36:58 EET Received: from daebh002.NOE.Nokia.com (daebh002.americas.nokia.com [10.241.35.122]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1FEavJ28733; Tue, 15 Feb 2005 16:36:57 +0200 (EET) Received: from bsebe001.NOE.Nokia.com ([172.19.160.13]) by daebh002.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Tue, 15 Feb 2005 08:35:28 -0600 X-MimeOLE: Produced By Microsoft Exchange V6.0.6487.1 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: [Mobike] RE: [Ipsec] Asymmetric Security Date: Tue, 15 Feb 2005 09:35:27 -0500 Message-ID: Thread-Topic: [Mobike] RE: [Ipsec] Asymmetric Security Thread-Index: AcUTHEbI8or/25ciSnathlTUveKjjAAThXJg To: X-OriginalArrivalTime: 15 Feb 2005 14:35:28.0990 (UTC) FILETIME=[987107E0:01C5136B] X-Spam-Score: 0.3 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, ynir@checkpoint.com, mobike@machshav.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi Steve, Response inline. Atul > -----Original Message----- > From: mobike-bounces@machshav.com=20 > [mailto:mobike-bounces@machshav.com]On > Behalf Of ext Stephen Kent > Sent: Monday, February 14, 2005 11:55 PM > To: Sharma Atul (Nokia-ES/Boston) > Cc: ipsec@ietf.org; mobike@machshav.com; ynir@checkpoint.com > Subject: [Mobike] RE: [Ipsec] Asymmetric Security >=20 >=20 > At 9:10 AM -0500 2/14/05, wrote: > >Thanks Yoav, for bringing another scenario needing=20 > Asymmetric support. > >More such scenarios we can bring the better. > > > >The question is whether IKEv2 and 2401bis are sufficient to handle > >the Asymmetric Security needs or do we need something extra? Things > >like: > > Do we allow different tunnel endpoints in the two direction of > > a tunnel? >=20 > this is not a well-formed question; a tunnel is composed of two SAs.=20 > what do you mean to ask here? I will make it more explicit, with one example scenario: So let us say SA pair has the SAs: SA1, SA2. The gateways X and Y. For the sake of simplicity let us just have Y multihomed with addresses Y1 and Y2. So for SA1 tunnel endpoints are X and Y1, for SA2 tunnel endpoints are Y2 and X. Is something like this allowed now? > > Do we allow IKE negotiations to be asymmetric? >=20 > again, not well-formed. are you referring to anything other than S/D=20 > addresses? how about ports? In the above example, IKE in forward direction go X->Y1, but comeback=20 Y2->X.=20 Is that allowed? As far as I know, it is not allowed. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 15 14:17:53 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24001 for ; Tue, 15 Feb 2005 14:17:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D15VZ-0003wQ-8M; Tue, 15 Feb 2005 11:25:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1595-0007Sk-RX for ipsec@megatron.ietf.org; Tue, 15 Feb 2005 11:01:52 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23706 for ; Tue, 15 Feb 2005 11:01:49 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D15UA-0002WJ-Ck for ipsec@ietf.org; Tue, 15 Feb 2005 11:23:38 -0500 Received: from [10.1.190.35] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j1FG12kN009870; Tue, 15 Feb 2005 11:01:08 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 15 Feb 2005 10:51:10 -0500 To: From: Stephen Kent Subject: [Mobike] RE: [Ipsec] Asymmetric Security Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 00e94c813bef7832af255170dca19e36 Cc: ipsec@ietf.org, mobike@machshav.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Atul, > > > > >> >(1) Asymmetry in Gateways: >> >Let us say there are three gateways A, B, C. In the forward >> >direction secure traffic >> >flows from Gateway A to Gateway B. In the reverse direction >> traffic flows from >> >Gateway C to Gateway A. A Mobile IP End-to-End Security between a >> >correspondent node and a mobile node will be an example >> scenario here. >> >IKE negotiations between A and B can setup a tunnel and IKE >> negotiations >> >between C and A can set up the tunnels. Both the tunnels shall still >> >protect the >> >same hosts/addresses. [Since IKE negotiations do not allow >> asymmetry we will >> >have to have two separate IKE negotiations] >> >> so, what's the problem? you have separate SAs because you have >> different endpoints. we decided long ago to create SAs in pairs. are >> you concerned that the state maintained for the unused SAs is a >> unacceptable burden? > >Only that there is no unused SAs or rather no unused SA pairs. There will >be two SA pairs negotiated each with different tunnel endpoints. In the >first SA pair only the forward SA will be used, in the second SA pair only >the reverse SA will be used. Is something like this already allowed? It is allowed, and the only possible problem I might see is if DPD mechanisms were confused by the lack of traffic one one of the SAs in each peer. >One SA in each pair shall be unused, which need not even be maintained. true in principle, but unless an implementation suffers from maintaining this extraneous state, it's not a big deal. >A related question: Do we allow IKE negotiations to be asymmetric, i.e. IKE >message goes to an address, but the response comes back from a different >address? That's an IKE question, ask Charlie. > >> >(2) Asymmetry in Tunnels: >> >Let us say there are two multihomed Gateways. These gateways >> negotiate TWO >> >tunnels, each with different tunnel endpoints (corresponding to >> >multihomed addresses). >> >But both the tunnels still protecting the same hosts/addresses. This >> >can be a real >> >life scenario to acheive redundancy/high availability >> >> again, what is the problem here? > >Allowing two tunnels protecting the same addresses/hosts, but with differnt >tunnel endpoints. Is this something allowed now? I think the right question here is how one would cause these different tunnels to be created in the first place. 2401bis is not explicit about how one determines the address for an SG, given the address of a host behind the SG. We note that this is a problem for which we do not have general answers. The new text on the PAD does address this a bit, but it is not comprehensive. My guess is that this is usually manually con figured into an implementation. In your case the question is whether an implementation allows for multiple SG addresses, and whether it causes a tunnel to be created to each of them when an SPD entry triggers SA creation. Currently this is largely outside the scope of 2401bis, i.e., it is up to vendors. One could add a sentence to the PAD text to say that support for creation of more than one tunnel mode SA at a time is OK (i.e., a MAY) just to clarify the issue. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 15 14:19:12 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24245 for ; Tue, 15 Feb 2005 14:19:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D15Vc-00040A-5r; Tue, 15 Feb 2005 11:25:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D159E-0007al-Qn for ipsec@megatron.ietf.org; Tue, 15 Feb 2005 11:02:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23740 for ; Tue, 15 Feb 2005 11:01:58 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D15UJ-0002XR-47 for ipsec@ietf.org; Tue, 15 Feb 2005 11:23:47 -0500 Received: from [10.1.190.35] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j1FG12kP009870; Tue, 15 Feb 2005 11:01:20 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Tue, 15 Feb 2005 10:59:52 -0500 To: From: Stephen Kent Subject: RE: [Mobike] RE: [Ipsec] Asymmetric Security Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c Cc: ipsec@ietf.org, mobike@machshav.com, ynir@checkpoint.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 9:35 AM -0500 2/15/05, wrote: >Hi Steve, > >Response inline. > >Atul > > >> -----Original Message----- >> From: mobike-bounces@machshav.com >> [mailto:mobike-bounces@machshav.com]On >> Behalf Of ext Stephen Kent >> Sent: Monday, February 14, 2005 11:55 PM >> To: Sharma Atul (Nokia-ES/Boston) >> Cc: ipsec@ietf.org; mobike@machshav.com; ynir@checkpoint.com >> Subject: [Mobike] RE: [Ipsec] Asymmetric Security >> >> >> At 9:10 AM -0500 2/14/05, wrote: >> >Thanks Yoav, for bringing another scenario needing >> Asymmetric support. >> >More such scenarios we can bring the better. >> > >> >The question is whether IKEv2 and 2401bis are sufficient to handle >> >the Asymmetric Security needs or do we need something extra? Things >> >like: >> > Do we allow different tunnel endpoints in the two direction of >> > a tunnel? >> >> this is not a well-formed question; a tunnel is composed of two SAs. >> what do you mean to ask here? > >I will make it more explicit, with one example scenario: > So let us say SA pair has the SAs: SA1, SA2. The gateways X and Y. > For the sake of simplicity let us just have Y multihomed with addresses > Y1 and Y2. So for SA1 tunnel endpoints are X and Y1, for SA2 tunnel > endpoints are Y2 and X. > >Is something like this allowed now? I think my other message addressed this question, but frankly the text above is very unclear. try explaining it again. > >> > Do we allow IKE negotiations to be asymmetric? >> >> again, not well-formed. are you referring to anything other than S/D >> addresses? how about ports? > >In the above example, IKE in forward direction go X->Y1, but comeback >Y2->X. > >Is that allowed? As far as I know, it is not allowed. so, if I understand your question, it is whether a multi-homed SG can accept IKE packets on one interface and send them back via the other interface, labelled with the source address of the second interface. My guess is that IKE would not react well to this. Note that IKE SAs do not share all the features of ESP or AH SAs. In ESP or AH, we tolerate the situation in which the source address for an inbound packet either is irrelevant to processing (for the outer address in tunnel mode) or we can accommodate multiple valid source addresses (for transport mode or the inner address in tunnel mode, if configured in the SPD). Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 15 14:50:12 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00872 for ; Tue, 15 Feb 2005 14:50:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D18Es-0004O7-2N; Tue, 15 Feb 2005 14:20:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D15ah-0007Vj-Ph for ipsec@megatron.ietf.org; Tue, 15 Feb 2005 11:30:23 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA00892 for ; Tue, 15 Feb 2005 11:30:21 -0500 (EST) Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D15vj-0004nl-BT for ipsec@ietf.org; Tue, 15 Feb 2005 11:52:10 -0500 Received: from zcard303.ca.nortel.com (zcard303.ca.nortel.com [47.129.242.59]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id j1FGTfH25425 for ; Tue, 15 Feb 2005 11:29:41 -0500 (EST) Received: from nortelnetworks.com (wcary0w4.ca.nortel.com [47.129.148.152]) by zcard303.ca.nortel.com with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2653.13) id 1XL534TA; Tue, 15 Feb 2005 11:29:42 -0500 Message-ID: <42122375.5050705@nortelnetworks.com> Date: Tue, 15 Feb 2005 11:29:41 -0500 X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Marcus Leech User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Content-Transfer-Encoding: 7bit Subject: [Ipsec] Racoon2/IKEV2 status X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Sorry for the slightly-OT post, but it seems likely that the right folks would be on this list. I'm trying to determine the current status of racoon2 with ikev2--I'm working a project that could usefully use the code. I had heard that the IKEV2 portion of racoon2 was being held back due to IPR concerns having to do with NAT-T and DPD. Any news on that front? _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 15 14:59:18 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02632 for ; Tue, 15 Feb 2005 14:59:18 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D18Uz-0005Y6-9K; Tue, 15 Feb 2005 14:36:41 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D16XB-0001TS-E7 for ipsec@megatron.ietf.org; Tue, 15 Feb 2005 12:30:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19015 for ; Tue, 15 Feb 2005 12:30:46 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D16sE-0002CP-Cn for ipsec@ietf.org; Tue, 15 Feb 2005 12:52:37 -0500 Received: from [10.1.190.35] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j1FHTpkL016138; Tue, 15 Feb 2005 12:29:54 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <200502151412.j1FECl1i027890@burp.tkv.asdf.org> References: <200502151412.j1FECl1i027890@burp.tkv.asdf.org> Date: Tue, 15 Feb 2005 12:28:36 -0500 To: Markku Savela From: Stephen Kent Subject: Re: [Ipsec] Some comments on draft-ietf-ipsec-rfc2401bis-05.txt X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.1 (/) X-Scan-Signature: 2c12be3f3a8d57895fb9c003e1517c01 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0513330533==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0513330533== Content-Type: multipart/alternative; boundary="============_-1103633906==_ma============" --============_-1103633906==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 4:12 PM +0200 2/15/05, Markku Savela wrote: first, note that WG last call and IETF last call have been over for weeks. >Few minor comments on this draft. >------- > >4.1 Definition and Scope > ... > For an SA used to carry unicast traffic, the SPI (Security Parameters > Index - see Appendix A and AH [Ken04b] and ESP [Ken04a] > specifications) by itself suffices to specify an SA. > ... > >------- >Shouldn't this be qualified as "For an inbound SA ...". For outbound, >we naturally can have multiple SA's with same SPI, but different >destinations? yes, this text refers to inbound traffic processing, which is where the issue of how to define an SA based on an SPI applies. For outbound traffic processing, the SPI is not used to specify (select) and SA. >------- > >4.4.1.1 Selectors > ... > - Name: This is not a selector like the others above. It is not > acquired from a packet. A name may be used as a symbolic > identifier for an IPsec Local or Remote address. Named SPD > entries are used in two ways: > ... >4.4.1.2 Structure of an SPD entry > .... > o Name -- a list of IDs. This quasi-selector is optional. > The forms that MUST be supported are described above in > Section 4.4.1.1 under "Name". > .... > o One to N selector sets that correspond to the "condition" > for applying a particular IPsec action. Each selector set > contains: > - Local Address > - Remote Address > - Next Layer Protocol > - Local Port, or ICMP message type/code or Mobility > Header type (depending on the next layer protocol) > - Remote Port, or ICMP message type/code or Mobility > Header type (depending on the next layer protocol) > >------- >If "name" is supposed to be used as an identifier of local or remote >address, shouldn't that be somehow mentioned in the "N selector sets" >description? I don't know how to interpret a plain selector with list >of names, as there is no context whether a name is supposed to be >remote or local address (when that interpretation is inteded). To me >it would seem natural to allow a name where expilicit address is >possible. As the text in 4.4.1.1 notes, "name" is special. The name is refers to the SPD entry as a whole, and thus encompasses all the selector sets. Whether the name applies to the local or remote address is determined by whether the IPsec entity is acting as initiator or responder, as discussed in 4.4.1.1 >In addition to above, a generic observation: the boolean expression >combining the individual selector tests is not specified. The boolean applied to the selector sets is OR, i.e., if all of the headers of a packet match any of the specified selector sets, then the SPD entry is matched. >------- > > >4.4.2 Security Association Database (SAD) > > ... > For each of the selectors defined in Section 4.4.1.1, the entry for > an inbound SA in the SAD MUST be initially populated with the value > or values negotiated at the time the SA was created. (See Section > 4.4.1, paragraph on Handling Changes to the SPD while the System is > Running for guidance on the effect of SPD changes on extant SAs.) For > a receiver, these values are used to check that the header fields of > an inbound packet (after IPsec processing) match the selector values > negotiated for the SA. Thus, the SAD acts as a cache for checking the > selectors of inbound traffic arriving on SAs. For the receiver, this > is part of verifying that a packet arriving on an SA is consistent > with the policy for the SA. > .... > >------- >The last sentence is not true, unless the selectors in SA are >decorrelated. This is explained later in "5. IP Traffic >Processing". But, perhaps above should also be amended, so that a >reader is not mislead here. In 4.4.1, on page 23, the section on decorrelation states that "The processing model described in this document assumes the ability to decorrelate overlapping SPD entries to permit caching ..." So the discussion in 4.4.2 should be interpreted in the context of decorrelation, as indicated. >------- > >At the moment I don't have anything else. For me some concepts are >more confusing than clarifying: > > - protected/unprotected side > - obsession with interfaces > >They are perhaps natural for security gateway, but for a host with >IPSEC inside the TCP/IP stack, those are not very helpful (at least >the way I see the implementation). For a host, the model can be very >simple: you just have incoming and outgoing packets, policy either >matches or not, it does not matter what interfaces are involved. The host model is simple: if there is one interface in the host to the Internet, the barrier is implemented by IPsec in its location in the stack. the unprotected side is "below" the Ipsec barrier (the network side), while the side "above" IPsec (transport and application) is protected. In a host with multiple interfaces the same model may apply, or one might designate one of the interfaces to be protected, depending on the context. And, of course one can make use of the model with virtual interfaces that may be purely internal to a host. The point to keep in mind is that IPsec defines a packet filtering firewall that can apply cryptographic security for selected traffic flows. Like any firewall, there needs to be a barrier that traffic crosses and thus becomes subject to inspection/filtering. The unprotected vs. protected side aspect of the model is relevant because we treat traffic differently depending on its directionality with regard to the barrier. Steve --============_-1103633906==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Ipsec] Some comments on draft-ietf-ipsec-rfc2401bis-0
At 4:12 PM +0200 2/15/05, Markku Savela wrote:

first, note that WG last call and IETF last call have been over for weeks.
 
Few minor comments on this draft.
-------

4.1 Definition and Scope
   ...
   For an SA used to carry unicast traffic, the SPI (Security Parameters
   Index - see Appendix A and AH [Ken04b] and ESP [Ken04a]
   specifications) by itself suffices to specify an SA.
   ...

-------
Shouldn't this be qualified as "For an inbound SA ...". For outbound,
we naturally can have multiple SA's with same SPI, but different
destinations?

yes, this text refers to inbound traffic processing, which is where the issue of how to define an SA based on an SPI applies. For outbound traffic processing, the SPI is not used to specify (select) and SA.

-------

4.4.1.1  Selectors
      ...
      - Name:  This is not a selector like the others above.  It is not
        acquired from a packet. A name may be used as a symbolic
        identifier for an IPsec Local or Remote address. Named SPD
        entries are used in two ways:
      ...
4.4.1.2  Structure of an SPD entry
      ....
           o Name -- a list of IDs.  This quasi-selector is optional.
             The forms that MUST be supported are described above in
             Section 4.4.1.1 under "Name".
      ....
           o One to N selector sets that correspond to the "condition"
             for applying a particular IPsec action. Each selector set
             contains:
                - Local Address
                - Remote Address
                - Next Layer Protocol
                - Local Port, or ICMP message type/code or Mobility
                  Header type (depending on the next layer protocol)
                - Remote Port, or ICMP message type/code or Mobility
                  Header type (depending on the next layer protocol)

-------
If "name" is supposed to be used as an identifier of local or remote
address, shouldn't that be somehow mentioned in the "N selector sets"
description? I don't know how to interpret a plain selector with list
of names, as there is no context whether a name is supposed to be
remote or local address (when that interpretation is inteded). To me
it would seem natural to allow a name where expilicit address is
possible.

As the text in 4.4.1.1 notes, "name" is special. The name is refers to the SPD entry as a whole, and thus encompasses all the selector sets. Whether the name applies to the local or remote address is determined by whether the IPsec entity is acting as initiator or responder, as discussed in 4.4.1.1

In addition to above, a generic observation: the boolean expression
combining the individual selector tests is not specified.

The boolean applied to the selector sets is OR, i.e., if all of the headers of a packet match any of the specified selector sets, then the SPD entry is matched.

-------


4.4.2 Security Association Database (SAD)

   ...
   For each of the selectors defined in Section 4.4.1.1, the entry for
   an inbound SA in the SAD MUST be initially populated with the value
   or values negotiated at the time the SA was created. (See Section
   4.4.1, paragraph on  Handling Changes to the SPD while the System is
   Running for guidance on the effect of SPD changes on extant SAs.) For
   a receiver, these values are used to check that the header fields of
   an inbound packet (after IPsec processing) match the selector values
   negotiated for the SA. Thus, the SAD acts as a cache for checking the
   selectors of inbound traffic arriving on SAs.  For the receiver, this
   is part of verifying that a packet arriving on an SA is consistent
   with the policy for the SA.
   ....

-------
The last sentence is not true, unless the selectors in SA are
decorrelated. This is explained later in "5. IP Traffic
Processing". But, perhaps above should also be amended, so that a
reader is not mislead here.

In 4.4.1, on page 23, the section on decorrelation states that
        "The processing model described in this document assumes the ability to decorrelate overlapping SPD entries to permit caching ..."  So the discussion in 4.4.2 should be interpreted in the context of decorrelation, as indicated.


-------

At the moment I don't have anything else. For me some concepts are
more confusing than clarifying:

 - protected/unprotected side
 - obsession with interfaces

They are perhaps natural for security gateway, but for a host with
IPSEC inside the TCP/IP stack, those are not very helpful (at least
the way I see the implementation). For a host, the model can be very
simple: you just have incoming and outgoing packets, policy either
matches or not, it does not matter what interfaces are involved.

The host model is simple: if there is one interface in the host to the Internet, the barrier is implemented by IPsec in its location in the stack. the unprotected side is "below" the Ipsec barrier (the network side), while the side "above" IPsec (transport and application) is protected. In a host with multiple interfaces the same model may apply, or one might designate one of the interfaces to be protected, depending on the context. And, of course one can make use of the model with virtual interfaces that may be purely internal to a host.

The point to keep in mind is that IPsec defines a packet filtering firewall that can apply cryptographic security for selected traffic flows. Like any firewall, there needs to be a barrier that traffic crosses and thus becomes subject to inspection/filtering. The unprotected vs. protected side aspect of the model is relevant because we treat traffic differently depending on its directionality with regard to the barrier.

Steve
--============_-1103633906==_ma============-- --===============0513330533== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0513330533==-- From ipsec-bounces@ietf.org Tue Feb 15 15:03:04 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03253 for ; Tue, 15 Feb 2005 15:03:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D18Wx-000356-Di; Tue, 15 Feb 2005 14:38:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D16q6-00021d-DZ for ipsec@megatron.ietf.org; Tue, 15 Feb 2005 12:50:26 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25636 for ; Tue, 15 Feb 2005 12:50:19 -0500 (EST) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D17BA-0004LQ-EX for ipsec@ietf.org; Tue, 15 Feb 2005 13:12:09 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.2/8.13.2/Debian-1) with ESMTP id j1FHoBYD030640; Tue, 15 Feb 2005 19:50:11 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.2/8.13.2/Submit) id j1FHoB2K030637; Tue, 15 Feb 2005 19:50:11 +0200 Date: Tue, 15 Feb 2005 19:50:11 +0200 Message-Id: <200502151750.j1FHoB2K030637@burp.tkv.asdf.org> From: Markku Savela To: kent@bbn.com In-reply-to: (message from Stephen Kent on Tue, 15 Feb 2005 12:28:36 -0500) Subject: Re: [Ipsec] Some comments on draft-ietf-ipsec-rfc2401bis-05.txt References: <200502151412.j1FECl1i027890@burp.tkv.asdf.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7bac9cb154eb5790ae3b2913587a40de Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > From: Stephen Kent > > yes, this text refers to inbound traffic processing, which is where > the issue of how to define an SA based on an SPI applies. For > outbound traffic processing, the SPI is not used to specify (select) > and SA. Outbound SA's need to be searched and identified by something, when IKE updates the SA's. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 15 15:04:01 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03439 for ; Tue, 15 Feb 2005 15:04:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D18XB-0003jp-FA; Tue, 15 Feb 2005 14:38:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D16rh-0002tD-22 for ipsec@megatron.ietf.org; Tue, 15 Feb 2005 12:52:03 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA26207 for ; Tue, 15 Feb 2005 12:51:57 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D17Ck-0004Tb-Ul for ipsec@ietf.org; Tue, 15 Feb 2005 13:13:48 -0500 Received: from [10.1.190.35] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j1FHpQkJ017358; Tue, 15 Feb 2005 12:51:27 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <892867B805D4DA42A1C48103BF4CFA5A01096FD1@EUR-MSG-20.europe.corp.microsoft .com> References: <892867B805D4DA42A1C48103BF4CFA5A01096FD1@EUR-MSG-20.europe.corp.microsoft .com> Date: Tue, 15 Feb 2005 12:51:18 -0500 To: "Michael Roe" From: Stephen Kent Subject: RE: [Ipsec] IKEv2 needs a "policy usage mode"... Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 057ebe9b96adec30a7efb2aeda4c26a4 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 Folks, Let me try to characterize what I think are the options for IKE traffic selector negotiation, for v1 vs. v2 and 2401 vs. 2401bis. I'm concerned that we have differing views of this, and frankly, I'm confused. I have to admit that I am not an IKE expert, especially with regard to IKE v1, where there was a big mismatch with the SPD. Still, let me try to explore the situation, to see if we can get a clearer understanding of what should happen. Under 2401 and IKE v1: - (no decorrelation available) - initiator sends local SPD entry that matches outbound traffic, based on linear search of local SPD, as the proposal - initiator does not send packet headers that triggered SA establishment - responder matches received, remote SPD entry against local SPD, based on an exact match - if successful, a pair of SAs is established, in the SAD at each end - inbound traffic received via an SA is matched against the SPD, and to a check is made that the SPD entry matches the SAD in question. this (slow) procedure is employed to ensure that the traffic is consistent with the SPD at a responder, since the choice of the matching SPD entry based on the IKE exchange might have selected and entry that is not the first match for specific traffic. - outbound traffic from the responder, consistent with the SAD entry created by IKE, may match a different rule at the responder (because there is no caching) and thus trigger a new SA, rather than flowing over the extant SA, due to the imprecision of the procedure. Under 2401bis and IKE v2: - decorrelation is an option, though not mandated. let's start the analysis w/o assuming use of decorrelation - IKE v2 transports the headers of the packet that triggered the SA to the responder, as a aide in selecting the right SPD entry - at the responder, these headers can be matched against the local SPD (ordered search, since we assume no decorrelation here) to find the entry that the responder would use to create an SA based - given this new feature, the receiver should match the selected SPD entry against the proposal sent by the initiator, and "narrow" the response. the narrowed response should be the intersection of the local and remote SPD entries, thus ensuring that traffic sent in both directions will be accepted at each end. - under 2401bis, traffic checking at a receiver is based only on the SAD entry, with no reference to the SPD. this procedure ensures that such checking suffices, because of the way the responder's SPD entry was selected, and the way the responder narrowed the response. so, what happens differently if one tries to take advantage of decorrelation? - 2401bis says that one should send the original, correlated SPD entry in the IKE exchange. the reasoning is that one wants decorrelation to not create multiple SAs where one would have been created if correlation were not performed. thus the description above matches what 2401bis says happens re the IKE exchange, with the added detail that the SAD entries at each end will be decorrelated, if each end used a decorrelated SPD. this latter detail arises because 2401bis calls for pulling in all of the decorrelated entries resulting from the initial SPD entry when the SAD entry is created. 2401bis did not say anything about narrowing, but if the returned proposal is narrowed, then it could be compared to the decorrelated SPD entries first, to yield an SAD entry that is a subset of all the decorrelated ones based on the original SPD entry. - if the responder has a decorrelated SPD, the lookup based on the transmitted packet header can make use of the decorrelation. but 2401bis implies (?) responding with the original SPD entry. again, no mention of narrowing is present, but the procedure described above could be used to narrow the SAD entries created. - because the responder narrows its proposal, and because the packet headers are sent along with the proposal, there should be fewer opportunities for mismatches between the peers re acceptable traffic flowing over the SAs. the question we have been discussing is whether the originator should send just the decorrelated entry, vs. the original entry. - If a decorrelated entry is sent, the responder will generally see a much more restrictive IKE proposal. if the responder has decorrelated his SPD, a match against the packet headers may find a similarly narrow local SPD entry. the result may accomplish the narrowing called for in IKE v2. however, this behavior could cause more SAs to be created than for a correlated SPD, even when there were identical correlated entries at each end. this does not seem to be the right response. - one could send the full set of decorrelated entries, instead of the original entry. this would prevent unintended creation of additional SAs. also, a recipient who has a decorrelated SPD can match each entry at his end with the proposals from the responder. this might make the narrowing process easier as well, and still prevent creation of extra SAs. - if the responder does not have a decorrelated SPD, it can still do the ordered SPD lookup based on the packet headers and then match the resulting SPD entry against the set of decorrelated proposals the initiator sent. the resulting narrowed proposal should represent so, to avoid creation of extra SAs, we ought not send just a decorrelated entry as a proposal, but we could choose to send the set of linked, decorrelated entries to a peer to help in the narrowing process, especially if the peer has a decorrelated SPD. Does this discussions help? Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 15 15:05:35 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03777 for ; Tue, 15 Feb 2005 15:05:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D18YH-0006c8-SP; Tue, 15 Feb 2005 14:40:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D170A-0007G8-IO for ipsec@megatron.ietf.org; Tue, 15 Feb 2005 13:00:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29503 for ; Tue, 15 Feb 2005 13:00:43 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D17LG-0005Wn-85 for ipsec@ietf.org; Tue, 15 Feb 2005 13:22:34 -0500 Received: from [10.1.190.35] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j1FI06kJ017864; Tue, 15 Feb 2005 13:00:08 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <200502151750.j1FHoB2K030637@burp.tkv.asdf.org> References: <200502151412.j1FECl1i027890@burp.tkv.asdf.org> <200502151750.j1FHoB2K030637@burp.tkv.asdf.org> Date: Tue, 15 Feb 2005 12:59:58 -0500 To: Markku Savela From: Stephen Kent Subject: Re: [Ipsec] Some comments on draft-ietf-ipsec-rfc2401bis-05.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 7:50 PM +0200 2/15/05, Markku Savela wrote: > > From: Stephen Kent >> >> yes, this text refers to inbound traffic processing, which is where >> the issue of how to define an SA based on an SPI applies. For >> outbound traffic processing, the SPI is not used to specify (select) >> and SA. > >Outbound SA's need to be searched and identified by something, when >IKE updates the SA's. The question of how IKE tracks the SAs that it has created is not addressed by 2401bis (or by IKE?). However, this is an internal issue for each implementation that can be solved lots of ways, e.g., via purely local pointers. We might add a parenthetical clarification if folks believe it is confusing. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 15 15:06:55 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04054 for ; Tue, 15 Feb 2005 15:06:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D18Z5-0008M9-GF; Tue, 15 Feb 2005 14:40:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D176s-0002JE-Q6 for ipsec@megatron.ietf.org; Tue, 15 Feb 2005 13:07:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA02102 for ; Tue, 15 Feb 2005 13:07:39 -0500 (EST) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D17Rx-0006LE-8n for ipsec@ietf.org; Tue, 15 Feb 2005 13:29:30 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.2/8.13.2/Debian-1) with ESMTP id j1FI7Xde031407; Tue, 15 Feb 2005 20:07:33 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.2/8.13.2/Submit) id j1FI7Xej031404; Tue, 15 Feb 2005 20:07:33 +0200 Date: Tue, 15 Feb 2005 20:07:33 +0200 Message-Id: <200502151807.j1FI7Xej031404@burp.tkv.asdf.org> From: Markku Savela To: kent@bbn.com In-reply-to: (message from Stephen Kent on Tue, 15 Feb 2005 12:28:36 -0500) Subject: Re: [Ipsec] Some comments on draft-ietf-ipsec-rfc2401bis-05.txt References: <200502151412.j1FECl1i027890@burp.tkv.asdf.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > From: Stephen Kent > > o One to N selector sets that correspond to the "condition" > > for applying a particular IPsec action. Each selector set > > contains: > > - Local Address > > - Remote Address > > - Next Layer Protocol > > - Local Port, or ICMP message type/code or Mobility > > Header type (depending on the next layer protocol) > > - Remote Port, or ICMP message type/code or Mobility > > Header type (depending on the next layer protocol) > > > > The boolean applied to the selector sets is OR, i.e., if all of the > headers of a packet match any of the specified selector sets, then > the SPD entry is matched. Just to be sure, within a selector set, the test is A) Local Address OR Remote Address OR ... B) Local Address AND Remote Address AND ... I assume (B) is the correct one? _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 15 15:10:53 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA04919 for ; Tue, 15 Feb 2005 15:10:53 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D18dT-0005Wf-5w; Tue, 15 Feb 2005 14:45:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D17kN-00069t-8P for ipsec@megatron.ietf.org; Tue, 15 Feb 2005 13:48:31 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA15739 for ; Tue, 15 Feb 2005 13:48:29 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D185S-0002FX-T0 for ipsec@ietf.org; Tue, 15 Feb 2005 14:10:19 -0500 Received: from [10.1.190.35] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j1FIldkL020551; Tue, 15 Feb 2005 13:47:43 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <200502151807.j1FI7Xej031404@burp.tkv.asdf.org> References: <200502151412.j1FECl1i027890@burp.tkv.asdf.org> <200502151807.j1FI7Xej031404@burp.tkv.asdf.org> Date: Tue, 15 Feb 2005 13:38:17 -0500 To: Markku Savela From: Stephen Kent Subject: Re: [Ipsec] Some comments on draft-ietf-ipsec-rfc2401bis-05.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 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:07 PM +0200 2/15/05, Markku Savela wrote: > > From: Stephen Kent > >> > o One to N selector sets that correspond to the "condition" >> > for applying a particular IPsec action. Each selector set >> > contains: >> > - Local Address >> > - Remote Address >> > - Next Layer Protocol >> > - Local Port, or ICMP message type/code or Mobility >> > Header type (depending on the next layer protocol) >> > - Remote Port, or ICMP message type/code or Mobility >> > Header type (depending on the next layer protocol) >> > >> >> The boolean applied to the selector sets is OR, i.e., if all of the >> headers of a packet match any of the specified selector sets, then >> the SPD entry is matched. > >Just to be sure, within a selector set, the test is > > A) Local Address OR Remote Address OR ... > > B) Local Address AND Remote Address AND ... > >I assume (B) is the correct one? yes, B is the correct interpretation. ALL the parts of a selector set must match, so they are ANDs, but the selector sets themselves are ORs. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 15 16:19:58 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13858 for ; Tue, 15 Feb 2005 16:19:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1A4w-0007kC-9s; Tue, 15 Feb 2005 16:17:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D19qO-0003Fc-Vw for ipsec@megatron.ietf.org; Tue, 15 Feb 2005 16:02:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11882 for ; Tue, 15 Feb 2005 16:02:51 -0500 (EST) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1ABQ-0001Zd-JI for ipsec@ietf.org; Tue, 15 Feb 2005 16:24:42 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.2/8.13.2/Debian-1) with ESMTP id j1FL2ZVv003352; Tue, 15 Feb 2005 23:02:35 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.2/8.13.2/Submit) id j1FL2YUj003349; Tue, 15 Feb 2005 23:02:35 +0200 Date: Tue, 15 Feb 2005 23:02:35 +0200 Message-Id: <200502152102.j1FL2YUj003349@burp.tkv.asdf.org> From: Markku Savela To: kent@bbn.com In-reply-to: (message from Stephen Kent on Tue, 15 Feb 2005 12:51:18 -0500) Subject: Re: [Ipsec] IKEv2 needs a "policy usage mode"... References: <892867B805D4DA42A1C48103BF4CFA5A01096FD1@EUR-MSG-20.europe.corp.microsoft .com> X-Spam-Score: 0.0 (/) X-Scan-Signature: cab78e1e39c4b328567edb48482b6a69 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Let me tackle one point first... > From: Stephen Kent > Under 2401bis and IKE v2: > - decorrelation is an option, though not mandated. let's start > the analysis w/o assuming use of decorrelation > - IKE v2 transports the headers of the packet that triggered the SA > to the responder, as a aide in selecting the right SPD entry > - at the responder, these headers can be matched against the local > SPD (ordered search, since we assume no decorrelation here) to find > the entry that the responder would use to create an SA based > - given this new feature, the receiver should match the selected SPD > entry against the proposal sent by the initiator, and "narrow" the > response. the narrowed response should be the intersection of the > local and remote SPD entries, thus ensuring that traffic sent in both > directions will be accepted at each end. > - under 2401bis, traffic checking at a receiver is based only on the > SAD entry, with no reference to the SPD. this procedure ensures that > such checking suffices, because of the way the responder's SPD > entry was selected, and the way the responder narrowed the response. No, YOU STILL have to check the policy, even if packet matched the narrowed responce! Consider (there is even no narrowing required) Initiator policy: localport=25 -> A1 remoteport=80 -> A2 Responder policy: localport=80 -> A2 The packet from initiator: localport=1234 remoteport=80. This results an SA pair with only port=80 as selector (other port any). Now, he responder can validly send packet with (localport=80, remoteport=25) using A2. And if the initiator only checked he SA selector, it would pass. But this not correct, the port 25 on receiver is supposed to have some other security (A1)! _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Feb 15 22:59:25 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11896 for ; Tue, 15 Feb 2005 22:59:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1GIh-0005cg-UI; Tue, 15 Feb 2005 22:56:31 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1GI3-0005Jv-LI for ipsec@megatron.ietf.org; Tue, 15 Feb 2005 22:55:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA11344 for ; Tue, 15 Feb 2005 22:55:49 -0500 (EST) Received: from [207.145.48.18] (helo=smtp.intoto.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D1GdE-0004x8-6e for ipsec@ietf.org; Tue, 15 Feb 2005 23:17:44 -0500 Received: from angel.intoto.com ([66.80.10.146]) by smtp.intoto.com (SMSSMTP 4.0.0.59) with SMTP id M2005021519543226966 ; Tue, 15 Feb 2005 19:54:32 -0800 Received: from SriniSony (dhcp-109.intoto.com [10.1.5.109]) (authenticated bits=0) by angel.intoto.com (8.13.1/8.13.1) with ESMTP id j1G3srst008013; Tue, 15 Feb 2005 19:54:56 -0800 Message-Id: <200502160354.j1G3srst008013@angel.intoto.com> From: "Srinivasa Rao Addepalli" To: , Subject: RE: [Mobike] RE: [Ipsec] Asymmetric Security Date: Tue, 15 Feb 2005 19:54:52 -0800 Organization: Intoto Inc MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Thread-Index: AcUTHB67SyBEKeXgSoemmvS91FiwtQASrNTgAByVpgA= X-Spam-Score: 0.0 (/) X-Scan-Signature: fb6060cb60c0cea16e3f7219e40a0a81 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, mobike@machshav.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi Atul, > >(1) Asymmetry in Gateways: > >Let us say there are three gateways A, B, C. In the forward > >direction secure traffic > >flows from Gateway A to Gateway B. In the reverse direction > traffic flows from > >Gateway C to Gateway A. A Mobile IP End-to-End Security between a > >correspondent node and a mobile node will be an example > scenario here. > >IKE negotiations between A and B can setup a tunnel and IKE > negotiations > >between C and A can set up the tunnels. Both the tunnels shall still > >protect the > >same hosts/addresses. [Since IKE negotiations do not allow > asymmetry we will > >have to have two separate IKE negotiations] > > so, what's the problem? you have separate SAs because you have > different endpoints. we decided long ago to create SAs in pairs. are > you concerned that the state maintained for the unused SAs is a > unacceptable burden? Only that there is no unused SAs or rather no unused SA pairs. There will be two SA pairs negotiated each with different tunnel endpoints. In the first SA pair only the forward SA will be used, in the second SA pair only the reverse SA will be used. Is something like this already allowed? SRINI> This scenario happens even in cases where each peer having only one IP address. Think of a scenario, where both parties re-key IPsec (phase2) keys at the same time. So, IMO the scenario you described would work with existing implementations. One SA in each pair shall be unused, which need not even be maintained. A related question: Do we allow IKE negotiations to be asymmetric, i.e. IKE message goes to an address, but the response comes back from a different address? SRINI> In my view, this may not be problem with IKE implementations. But, we observed this problem, when there is symmetric firewall in between IKE peers. It is a good practice that IKE implementations send the reverse/response IKE packets with source IP address as the landed IP address of the received IKE packet. So, I consider the problem you indicated is more of implementation problem than the specification limitation. > >(2) Asymmetry in Tunnels: > >Let us say there are two multihomed Gateways. These gateways > negotiate TWO > >tunnels, each with different tunnel endpoints (corresponding to > >multihomed addresses). > >But both the tunnels still protecting the same hosts/addresses. This > >can be a real > >life scenario to acheive redundancy/high availability > > again, what is the problem here? Allowing two tunnels protecting the same addresses/hosts, but with differnt tunnel endpoints. Is this something allowed now? SRINI> Yes, specifications don't prohibit this behavior. It is already put to use, in implementations, to achieve load sharing of the data across multiple SAs to pass secured traffic through multiple WAN links. _______________________________________________ Mobike mailing list Mobike@machshav.com https://www.machshav.com/mailman/listinfo.cgi/mobike _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Feb 16 00:46:13 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22228 for ; Wed, 16 Feb 2005 00:46:12 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Hsi-0003XS-A4; Wed, 16 Feb 2005 00:37:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Hmu-000175-OK for ipsec@megatron.ietf.org; Wed, 16 Feb 2005 00:31:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20956 for ; Wed, 16 Feb 2005 00:31:45 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.193]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1I85-0007nU-H4 for ipsec@ietf.org; Wed, 16 Feb 2005 00:53:42 -0500 Received: by wproxy.gmail.com with SMTP id 71so39194wri for ; Tue, 15 Feb 2005 21:31:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=lZZ9glVHfJCZrUnOPHqOOQigjcWPS1My2RqHZ9/F5ZA7goJFjM3nYu8NSQaQ/kjicSOVTq+BfwxMd+nS+2IKGjaWLaDanm54Sf9zV8acpjN/OqS3tNlK81PQS1LT121ZTewgUF/196N4opf5N4o1TUvfCJcilI3PU/kXw3d2HhQ= Received: by 10.54.30.70 with SMTP id d70mr155653wrd; Tue, 15 Feb 2005 21:31:15 -0800 (PST) Received: by 10.54.40.21 with HTTP; Tue, 15 Feb 2005 21:31:15 -0800 (PST) Message-ID: <41ae448405021521316ab81db9@mail.gmail.com> Date: Wed, 16 Feb 2005 11:01:15 +0530 From: Kausty To: mleech@nortel.com, ipsec@ietf.org In-Reply-To: <20050216113615Z.sakane@kame.net> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: <41ae44840502140152793d1df6@mail.gmail.com> <20050216113615Z.sakane@kame.net> X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Content-Transfer-Encoding: 7bit Subject: [Ipsec] Fwd: racoon2 status X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kausty List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit ---------- Forwarded message ---------- From: Shoichi Sakane Date: Wed, 16 Feb 2005 11:36:15 +0900 Subject: Re: racoon2 status To: kkumbhalkar@gmail.com Cc: sakane@kame.net > hi, > which sections of IKEv2 protocol does microsoft hold its IPR for?. > or does it have an IPR over the entire IKEv2 protocol itself. > thanks not sure in microsoft's ipr because the statement didn't disclose any things, just it has IPR for IKEv2. in certicom's ipr, it claims to have ipr related to the DH exchange. will you help to solve the ipr issue ? > kausty > > On Wed, 05 Jan 2005 07:14:54 +0900, Shoichi Sakane wrote: > > currently we have a problem to publish our ikev2 code. that is > > the IPR issue disclosed at the ietf IPR directory. > > > > http://www.ietf.org/ietf/IPR/microsoft-ipr-draft-ietf-ipsec-ikev2.txt > > http://www.ietf.org/ietf/IPR/certicom-ipr-rfc3526-rfc2409-ikev2.txt > > > > we cannot publish our code before the issue will be solved. > > > > > hi > > > i was going through the your post on racoon mailing list saying that > > > racoon2 will be available by 25dec04 and even the kame road map doc > > > suggests so. > > > i was interested in porting and evaluating racoon2 on linux, but i > > > havent been able to locate the page for racoon2 . > > > has the alpha version been released, if so then where can i download > > > the source code from. > > > thanks and regards > > > kausty > > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Feb 16 00:46:51 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA22358 for ; Wed, 16 Feb 2005 00:46:51 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Hsk-0003Y0-EY; Wed, 16 Feb 2005 00:37:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Hoc-0001jo-Oq for ipsec@megatron.ietf.org; Wed, 16 Feb 2005 00:33:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA21050 for ; Wed, 16 Feb 2005 00:33:31 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.195]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1I9n-0007qn-Cs for ipsec@ietf.org; Wed, 16 Feb 2005 00:55:28 -0500 Received: by wproxy.gmail.com with SMTP id 71so39373wri for ; Tue, 15 Feb 2005 21:33:02 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=VtuElwOhM9es58d9s4A4U+GcOvbtB9g9bwzl6url8oNG1bEfRLIiVr8Mi1RPBGbt7GBfBlDzp0x9UzEGR4zbMFuhR4ZIjV2ClHGrAKNK7apE5tUEOZZAAw0Ui8DDN7GtGXvPmLNlZgsH0EW71WPNkrXYh4lCLAJmng7RSIYkWSU= Received: by 10.54.31.8 with SMTP id e8mr158740wre; Tue, 15 Feb 2005 21:33:02 -0800 (PST) Received: by 10.54.40.21 with HTTP; Tue, 15 Feb 2005 21:33:02 -0800 (PST) Message-ID: <41ae44840502152133485f5de6@mail.gmail.com> Date: Wed, 16 Feb 2005 11:03:02 +0530 From: Kausty To: mleech@nortel.com, ipsec@ietf.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Subject: [Ipsec] ikev2 status X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kausty List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit IKEv2 is stuck in the RFC editor's queue behind RFC2401bis (because it references it). That document has been imminent for some time; the WG chairs or ADs might have a better idea when it will be completed. No further changes to IKEv2 are contemplated. Frustratingly, I've been asked not to comment on the Microsoft IPR statement beyond what they have posted. --Charlie -----Original Message----- From: Kausty [mailto:kkumbhalkar@gmail.com] Sent: Monday, February 14, 2005 9:35 PM To: Charlie Kaufman Subject: Microsoft's statement about IPR claimed in draft-ietf-ipsec-ikev2-08.txt Hi, Regarding the Patent Disclosure and Licensing Declaration relating to IKEv2 draft, I wanted to know which particular sections of IKEv2 are part of microsoft's IPR and for which license would be required from microsoft. and yes by what time will ikev2 draft will get the RFC status. Thanks Kausty _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Feb 16 05:24:56 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21460 for ; Wed, 16 Feb 2005 05:24:55 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1MKe-0004I1-S1; Wed, 16 Feb 2005 05:22:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1MIp-0003k9-Qg for ipsec@megatron.ietf.org; Wed, 16 Feb 2005 05:21:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA21153 for ; Wed, 16 Feb 2005 05:21:01 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Me3-0007Jb-CF for ipsec@ietf.org; Wed, 16 Feb 2005 05:43:00 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j1GAKmpi021458 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 16 Feb 2005 12:20:48 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j1GAKk7g021455; Wed, 16 Feb 2005 12:20:46 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16915.7806.614453.965100@fireball.kivinen.iki.fi> Date: Wed, 16 Feb 2005 12:20:46 +0200 From: Tero Kivinen To: Stephen Kent Subject: RE: [Ipsec] IKEv2 needs a "policy usage mode"... In-Reply-To: References: <892867B805D4DA42A1C48103BF4CFA5A01096FD1@EUR-MSG-20.europe.corp.microsoft.com> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 46 min X-Total-Time: 90 min X-Spam-Score: 0.0 (/) X-Scan-Signature: a492040269d440726bfd84680622cee7 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Michael Roe X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Stephen Kent writes: > Under 2401 and IKE v1: > - (no decorrelation available) > - initiator sends local SPD entry that matches outbound traffic, > based on linear search of local SPD, as the proposal > - initiator does not send packet headers that triggered SA > establishment > - responder matches received, remote SPD entry against local SPD, > based on an exact match > - if successful, a pair of SAs is established, in the SAD at each end > - inbound traffic received via an SA is matched against the SPD, and > to a check is made that the SPD entry matches the SAD in question. > this (slow) procedure is employed to ensure that the traffic is > consistent with the SPD at a responder, since the choice of > the matching SPD entry based on the IKE exchange might have selected > and entry that is not the first match for specific traffic. > - outbound traffic from the responder, consistent with the SAD entry > created by IKE, may match a different rule at the responder (because > there is no caching) and thus trigger a new SA, rather than flowing > over the extant SA, due to the imprecision of the procedure. Yes, I think that is quite correct interpretation. The key points there is: 1) Everything works as long as the SPD in both end is exactly same. 2) If there is any changes in the SPD then either the negotiation will fail (no exact match found for entry from the recipients SPD for the initiators proposed SPD entry), or the traffic will disappear in the black hole (traffic coming out from SA is dropped as it does not match the local SPD). > Under 2401bis and IKE v2: > - decorrelation is an option, though not mandated. let's start > the analysis w/o assuming use of decorrelation > - IKE v2 transports the headers of the packet that triggered the SA > to the responder, as a aide in selecting the right SPD entry > - at the responder, these headers can be matched against the local > SPD (ordered search, since we assume no decorrelation here) to find > the entry that the responder would use to create an SA based > - given this new feature, the receiver should match the selected SPD > entry against the proposal sent by the initiator, and "narrow" the > response. the narrowed response should be the intersection of the > local and remote SPD entries, thus ensuring that traffic sent in both > directions will be accepted at each end. > - under 2401bis, traffic checking at a receiver is based only on the > SAD entry, with no reference to the SPD. this procedure ensures that > such checking suffices, because of the way the responder's SPD > entry was selected, and the way the responder narrowed the response. I do not think the last point is valid, regardless of narrowing, or at least if you do it that way you will allow traffic not matching SPD to pass through. Lets take example: Host A has SPD saying 10.0.0.0-10.0.0.255 as a selector (I assume we have only one selector and that is one IPv4 address, to simplify the example). The SPD says use AES for that Host B has SPD saying that for selector 10.0.0.42 use 3DES, and lower priority rule says that 10.0.0.0-10.0.0.255 can use either AES or 3DES. Now when A makes SA for host 10.0.0.1 it will create SA having seletors of 10.0.0.0-10.0.0.255 using AES, and B will accept that. Now if A tries to send packets to 10.0.0.42 using that SA if B only checks the SAD having 10.0.0.0-10.0.0.255 / AES it will accept the packets, even when there is higher priority rule saying that traffic must use 3DES. > so, what happens differently if one tries to take advantage of decorrelation? > > - 2401bis says that one should send the original, correlated SPD entry > in the IKE exchange. the reasoning is that one wants decorrelation > to not create multiple SAs where one would have been created if > correlation were not performed. I do not think that is valid to say it would create multiple SAs even when decorrelated versions are used (protocol holes are an exception). As the decorrelated SPD entry can still be (in most cases) be presented as one traffic selector set, meaning it will still be one SA. Exception to this is when we need to decorrelate protocols, i.e. when we have policy which says: 1) protocol:TCP use AES 2) protocol:any use 3DES The decorrelated SPD will be: 1) protocol:TCP(6) use AES 2) protocol:1-5,7-255 use 3DES and that second selector cannot really be expressed in the IKEV2 traffic selector (or it can, but it will expand to traffic selector having 254 items). The best way in those kind of policies in IKE is to expand it rule where we use SA per protocol (i.e. put the PFP on for protocol). I think it should send the decorrelated SPD entry if it is using decorrelated policies, as otherwise we end up problems if the policies do not match in both ends. > thus the description above matches > what 2401bis says happens re the IKE exchange, with the added > detail that the SAD entries at each end will be decorrelated, if > each end used a decorrelated SPD. this latter detail arises because > 2401bis calls for pulling in all of the decorrelated > entries resulting > from the initial SPD entry when the SAD entry is created. If the SPDs are not identical in both ends the SAD entry created by the above rules can be different in both ends. I.e. if we take my first example with 10.0.0.0-10.0.0.255 but the host B initiating. The B's second entry is decorrelated to 10.0.0.0-10.0.0.41, 10.0.0.43-10.0.0.255. When B initiates to the A for packet 10.0.0.1, and if it takes the original SPD entry it will send 10.0.0.0-10.0.0.255 / AES to the host A, they will end up problems. If B installs the decorreclated version to the SAD after the exchange, then A and B has different selectors for the SA, and if B installs the original SPD entry then that SAD entry will not follow his own policy. > 2401bis did > not say anything about narrowing, but if the returned proposal is > narrowed, then it could be compared to the decorrelated SPD entries > first, to yield an SAD entry that is a subset of all the decorrelated > ones based on the original SPD entry. But in that case the SAD entry in both ends will be different, as initiator will modify selectors after they have been negotiated with the other end. > - if the responder has a decorrelated SPD, the lookup based on the > transmitted packet header can make use of the decorrelation. but > 2401bis implies (?) responding with the original SPD entry. again, no > mention of narrowing is present, but the procedure described > above could be used to narrow the SAD entries created. I think we cannot use the original SPD entry when responding, if decorrelated policies are used. > - because the responder narrows its proposal, and because the packet > headers are sent along with the proposal, there should be fewer > opportunities for mismatches between the peers re acceptable traffic > flowing over the SAs. As long as either end modifies the SAD entries without telling the other end there will be mismatch in the final selectors for the SA. I.e. if original SPD entries are used and then they are modified when installing them to SAD then we end up problems if the SPDs in hosts are different. > the question we have been discussing is whether the originator should > send just the decorrelated entry, vs. the original entry. > - If a decorrelated entry is sent, the responder will generally see a > much more restrictive IKE proposal. if the responder has decorrelated > his SPD, a match against the packet headers may find a similarly > narrow local SPD entry. the result may accomplish the > narrowing called > for in IKE v2. however, this behavior could cause more SAs to be > created than for a correlated SPD, even when there were identical > correlated entries at each end. this does not seem to be the right > response. Why would it cause more SAs to be created? The decorrelated entry can be expressed as one traffic selector in the IKE, thus we can create one SA for it. And when the responder is calculating intersection based on his own decorrelated SPD and the other ends policy it should include all possible ranges which are allowed by both policies. If some ranges are left out they are left out because they are not allowed by the policy. > - one could send the full set of decorrelated entries, instead of the > original entry. this would prevent unintended creation of additional > SAs. also, a recipient who has a decorrelated SPD can match > each entry > at his end with the proposals from the responder. this might make the > narrowing process easier as well, and still prevent creation of > extra SAs. Oh, when you were talking about the decorrelated SPD entry you were only talking about one specific entry there? I was always assuming that decorrelated SPD entry, is actually set of entries generated from the original SPD, i.e. the "full set of decorrelated entries" you mention here. Now I understand your comments before. So read all the above text so that decorrelated SPD entry ==> "full set of decorrelated entries created from one original SPD entry". > - if the responder does not have a decorrelated SPD, it can still > do the ordered SPD lookup based on the packet headers and then match > the resulting SPD entry against the set of decorrelated proposals the > initiator sent. the resulting narrowed proposal should represent > > so, to avoid creation of extra SAs, we ought not send just a > decorrelated entry as a proposal, but we could choose to send the set > of linked, decorrelated entries to a peer to help in the narrowing > process, especially if the peer has a decorrelated SPD. Yes. And I think that is only way to really get things working when the policies are different. > Does this discussions help? Yes... -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Feb 16 05:54:27 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23639 for ; Wed, 16 Feb 2005 05:54:27 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1MjG-0002f8-6w; Wed, 16 Feb 2005 05:48:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Mhc-00024T-GA for ipsec@megatron.ietf.org; Wed, 16 Feb 2005 05:46:40 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA23223 for ; Wed, 16 Feb 2005 05:46:37 -0500 (EST) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1N2p-0007yd-SO for ipsec@ietf.org; Wed, 16 Feb 2005 06:08:37 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.2/8.13.2/Debian-1) with ESMTP id j1GAkb7X014075 for ; Wed, 16 Feb 2005 12:46:37 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.2/8.13.2/Submit) id j1GAkbGK014072; Wed, 16 Feb 2005 12:46:37 +0200 Date: Wed, 16 Feb 2005 12:46:37 +0200 Message-Id: <200502161046.j1GAkbGK014072@burp.tkv.asdf.org> From: Markku Savela To: ipsec@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 7aafa0432175920a4b3e118e16c5cb64 Subject: [Ipsec] IKE, traffic selectors and policy selector, policy checking X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org My definitions: policy selector = the selectors in Policy Data Base (= PS) traffic seletor = the selectors associated with SA (= TS) Claims: 1) IKE policy check (if done), is based on the packet information, not on TS 2) PS and TS are related, but not the same Expanded explanations: 1) IKE policy check (if done), is based on the packet information ------------------------------------------------------------------ - IKEv2 includes the complete information about the packet that triggers the negotiation. - this information can be used to check and choose one of the proposed security to use, or reject the proposal. TS is not needed at this stage. - if this is the only SA between the negotiators, TS can be totally ignored. This is why IKEv1 mostly worked, even with complex policy selector, while not supporting any TS. IKEv1 got into interoperability trouble only when it needed to maintain multiple SA's between end points. How to negotiate the routing of specific traffic to specific SA was always fuzzy (although, identities, protocol and ports could were included in the negotiation and used for the purpose). 2) PS and TS are related, but not the quite same ------------------------------------------------ The previous policy check step already guarantees that the proposed ipsec transforms and traffic is acceptable. The TS negotiation is just fine tuning the use of multiple SA's with equal security features. It is a request from initiator: Can you route traffic that matches this pattern to this SA? The narrowing is just responder replying: Yes, but I want finer division using this pattern. And, this is where decorrelation steps in. If policies are not exactly the same, the TS exchange must use decorrelated selectors. (This is totally independent whether implementation uses decorrelation in PS or as optimization for incoming SA policy matching). Also, I rejecting negotiation because of the fine tuning cannot be complied, is different from rejecting the negotiation based on the policy check in (1). _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Feb 16 06:46:26 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28115 for ; Wed, 16 Feb 2005 06:46:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1NVN-0005mx-1Z; Wed, 16 Feb 2005 06:38:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1NPv-0004Jp-79 for ipsec@megatron.ietf.org; Wed, 16 Feb 2005 06:32:27 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA26685 for ; Wed, 16 Feb 2005 06:32:24 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Nl8-0000bq-PI for ipsec@ietf.org; Wed, 16 Feb 2005 06:54:24 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j1GBW7dS022128 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 16 Feb 2005 13:32:07 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j1GBW62T022125; Wed, 16 Feb 2005 13:32:06 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16915.12085.981069.105303@fireball.kivinen.iki.fi> Date: Wed, 16 Feb 2005 13:32:05 +0200 From: Tero Kivinen To: Markku Savela Subject: Re: [Ipsec] Some comments on draft-ietf-ipsec-rfc2401bis-05.txt In-Reply-To: <200502151807.j1FI7Xej031404@burp.tkv.asdf.org> References: <200502151412.j1FECl1i027890@burp.tkv.asdf.org> <200502151807.j1FI7Xej031404@burp.tkv.asdf.org> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 14 min X-Total-Time: 70 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, kent@bbn.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Markku Savela writes: > > > From: Stephen Kent > > > > o One to N selector sets that correspond to the "condition" > > > for applying a particular IPsec action. Each selector set > > > contains: > > > - Local Address > > > - Remote Address > > > - Next Layer Protocol > > > - Local Port, or ICMP message type/code or Mobility > > > Header type (depending on the next layer protocol) > > > - Remote Port, or ICMP message type/code or Mobility > > > Header type (depending on the next layer protocol) > > > > > > > The boolean applied to the selector sets is OR, i.e., if all of the > > headers of a packet match any of the specified selector sets, then > > the SPD entry is matched. > > Just to be sure, within a selector set, the test is > > A) Local Address OR Remote Address OR ... > > B) Local Address AND Remote Address AND ... > > I assume (B) is the correct one? Not from IKEv2 point of view. IKEv2 traffic selectors are list of local selectors ORed together list of remote selectors ORed together where the local information from packet needs to match item on the "list of local selectors" and the remote information from packet needs to match item on the "list of remote selectors". I.e. any local address is OK, and any remote address is OK. Each item in local or remote selectors list is Address-range AND Next layer protocol AND Port-range I did explain this when we were talking about the ASN1 description of the SPD. See <16399.12161.370070.285455@fireball.acr.fi> http://www.vpnc.org/ietf-ipsec/mail-archive/msg00092.html. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Feb 16 06:55:09 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA28951 for ; Wed, 16 Feb 2005 06:55:09 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Ngl-0000Pq-HK; Wed, 16 Feb 2005 06:49:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1NZl-0006jv-EH for ipsec@megatron.ietf.org; Wed, 16 Feb 2005 06:42:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27849 for ; Wed, 16 Feb 2005 06:42:34 -0500 (EST) Received: from [83.145.195.1] (helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Nv0-0000zR-6R for ipsec@ietf.org; Wed, 16 Feb 2005 07:04:34 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.12.11/8.12.10) with ESMTP id j1GBgR6B022169 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 16 Feb 2005 13:42:28 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.12.11/8.12.6/Submit) id j1GBgRmN022166; Wed, 16 Feb 2005 13:42:27 +0200 (EET) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16915.12707.450170.691765@fireball.kivinen.iki.fi> Date: Wed, 16 Feb 2005 13:42:27 +0200 From: Tero Kivinen To: Stephen Kent Subject: Re: [Ipsec] Some comments on draft-ietf-ipsec-rfc2401bis-05.txt In-Reply-To: References: <200502151412.j1FECl1i027890@burp.tkv.asdf.org> <200502151807.j1FI7Xej031404@burp.tkv.asdf.org> X-Mailer: VM 7.17 under Emacs 21.3.1 X-Edit-Time: 8 min X-Total-Time: 10 min X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Stephen Kent writes: > At 8:07 PM +0200 2/15/05, Markku Savela wrote: > > > From: Stephen Kent > > > >> > o One to N selector sets that correspond to the "condition" > >> > for applying a particular IPsec action. Each selector set > >> > contains: > >> > - Local Address > >> > - Remote Address > >> > - Next Layer Protocol > >> > - Local Port, or ICMP message type/code or Mobility > >> > Header type (depending on the next layer protocol) > >> > - Remote Port, or ICMP message type/code or Mobility > >> > Header type (depending on the next layer protocol) > >> > > >> > >> The boolean applied to the selector sets is OR, i.e., if all of the > >> headers of a packet match any of the specified selector sets, then > >> the SPD entry is matched. > > > >Just to be sure, within a selector set, the test is > > > > A) Local Address OR Remote Address OR ... > > > > B) Local Address AND Remote Address AND ... > > > >I assume (B) is the correct one? > > yes, B is the correct interpretation. ALL the parts of a selector set > must match, so they are ANDs, but the selector sets themselves are > ORs. That does not match IKEv2. IKEv2 does always combine all local selectors (address, next layer protocol and port) to one single union of them, and same thing for the remote selectors, and you can mix and match them as you like. I.e you can have tarffic selectors local = TS(10.0.0.0-10.0.0.255),TS(192.0.2.1-192.0.2.255) remote = TS(10.0.5.0-10.0.5.255),TS(10.0.22.0-10.0.22.255) and that will mean that all following packets are allowed: 10.0.0.11 -> 10.0.5.1 192.0.2.1 -> 10.0.5.44 10.0.0.1 -> 10.0.22.5 192.0.2.11 -> 10.0.22.66 etc. I.e. local address can be any from the local address set, and remote address can be any from the remote address set. If you want to make policy which allows only from 10.0.0.0-10.0.0.255 <-> 10.0.5.0-10.0.0.5.255 and 192.0.2.1-192.0.2.255 <-> 10.0.22.0-10.0.22.255, then you need to make two rules for that, and create two SAs for that. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Feb 16 09:09:20 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11279 for ; Wed, 16 Feb 2005 09:09:20 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Pko-0000vB-Sl; Wed, 16 Feb 2005 09:02:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Pht-0000PW-JW for ipsec@megatron.ietf.org; Wed, 16 Feb 2005 08:59:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA10433 for ; Wed, 16 Feb 2005 08:59:07 -0500 (EST) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Q38-0004b1-I0 for ipsec@ietf.org; Wed, 16 Feb 2005 09:21:08 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.2/8.13.2/Debian-1) with ESMTP id j1GDx5oA016621 for ; Wed, 16 Feb 2005 15:59:05 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.2/8.13.2/Submit) id j1GDx5SK016618; Wed, 16 Feb 2005 15:59:05 +0200 Date: Wed, 16 Feb 2005 15:59:05 +0200 Message-Id: <200502161359.j1GDx5SK016618@burp.tkv.asdf.org> From: Markku Savela To: ipsec@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Subject: [Ipsec] Minor comment/question on draft-ietf-ipsec-esp-v3-09.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 Minor nit (or my misunderstanding of something), but in 2.3 Payload Data ... Note that the beginning of the next layer protocol header MUST be aligned relative to the beginning of the ESP header as follows. For IPv4, this alignment is a multiple of 4 bytes. For IPv6, the alignment is a multiple of 8 bytes. ... I'm puzzled about what the "next layer protocol header" means? With ESP, the packet really does not have any next layer header, that needs alignment. The paragraphah can be deleted? [Of course, after inbound ESP processing we have the header and it must be properly aligned, but that is a different matter.] _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Feb 16 09:56:05 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17059 for ; Wed, 16 Feb 2005 09:56:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1QQu-0001y0-Rb; Wed, 16 Feb 2005 09:45:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1QOj-0001ZW-3H for ipsec@megatron.ietf.org; Wed, 16 Feb 2005 09:43:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA15176 for ; Wed, 16 Feb 2005 09:43:19 -0500 (EST) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Qjt-0005qh-M8 for ipsec@ietf.org; Wed, 16 Feb 2005 10:05:21 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.2/8.13.2/Debian-1) with ESMTP id j1GEhGrb017448 for ; Wed, 16 Feb 2005 16:43:16 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.2/8.13.2/Submit) id j1GEhG0P017445; Wed, 16 Feb 2005 16:43:16 +0200 Date: Wed, 16 Feb 2005 16:43:16 +0200 Message-Id: <200502161443.j1GEhG0P017445@burp.tkv.asdf.org> From: Markku Savela To: ipsec@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 9182cfff02fae4f1b6e9349e01d62f32 Subject: [Ipsec] Minor comment on draft-ietf-ipsec-rfc2402bis-10.txt (AH) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org There is a strange sentence in: 3.3.3.1 Handling Mutable Fields ... ... If the IP (v4 or v6) implementation encounters an extension header that it does not recognize, it will discard the packet and send an ICMP message. IPsec will never see the packet. ... There is no such thing as "unrecognized extension header". There are only "recognized extension headers" and "transport protocol". Thus, if a stack receives a header that it does not recognize as an extension header, it must assume that it is a transport protocol. This protocol may have receiver or may not (in Unix receiver may be using the raw socket). If no receiver, it may result a protocol unreachable ICMP. However, IPsec will see such packets (and actually have a policy selector for it). Hence, the two sentences above could/should be deleted. Other that above editorial[?] issue(s), the text seem OK by me (same applies to the ESP draft, which I forgot to state in my previous comment). _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Feb 16 10:57:30 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02531 for ; Wed, 16 Feb 2005 10:57:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Qw8-0002Y1-CY; Wed, 16 Feb 2005 10:17:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1QhV-0006Hr-Cr for ipsec@megatron.ietf.org; Wed, 16 Feb 2005 10:02:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA18076 for ; Wed, 16 Feb 2005 10:02:47 -0500 (EST) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1R2l-0006al-0J for ipsec@ietf.org; Wed, 16 Feb 2005 10:24:48 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.2/8.13.2/Debian-1) with ESMTP id j1GF2kvw018235 for ; Wed, 16 Feb 2005 17:02:46 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.2/8.13.2/Submit) id j1GF2kIM018232; Wed, 16 Feb 2005 17:02:46 +0200 Date: Wed, 16 Feb 2005 17:02:46 +0200 Message-Id: <200502161502.j1GF2kIM018232@burp.tkv.asdf.org> From: Markku Savela To: ipsec@ietf.org In-reply-to: <200502161443.j1GEhG0P017445@burp.tkv.asdf.org> (message from Markku Savela on Wed, 16 Feb 2005 16:43:16 +0200) Subject: Re: [Ipsec] Minor comment on draft-ietf-ipsec-rfc2402bis-10.txt (AH) References: <200502161443.j1GEhG0P017445@burp.tkv.asdf.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org [Ok, I have to revice my comment a bit...] > There is no such thing as "unrecognized extension header". There are > only "recognized extension headers" and "transport protocol". Above is true, but in connection with AH, the draft sentences are sort of correct, perhaps the following was intended: Assume send is using extension header "EX" that receiver does not recognize, and builds an IP packet as follows: IP EX AH ... The receiver does not recognize EX as extension header, and treats it as some transport protocol. As the draft says, AH processing is never called. However, IPsec does get to see this packet as transport EX packet (of course, the two nodes really won't communicate correctly...) _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Feb 16 15:06:15 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14231 for ; Wed, 16 Feb 2005 15:06:15 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1UzZ-0008Rw-Hi; Wed, 16 Feb 2005 14:37:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1T7W-0000kB-Qj for ipsec@megatron.ietf.org; Wed, 16 Feb 2005 12:37:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA01794 for ; Wed, 16 Feb 2005 12:37:47 -0500 (EST) Received: from mail-eur1.microsoft.com ([213.199.128.139]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1TSn-00039y-T9 for ipsec@ietf.org; Wed, 16 Feb 2005 12:59:51 -0500 Received: from EUR-MSG-20.europe.corp.microsoft.com ([65.53.210.18]) by mail-eur1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Wed, 16 Feb 2005 17:37:14 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] IKEv2 needs a "policy usage mode"... Date: Wed, 16 Feb 2005 17:37:16 -0000 Message-ID: <892867B805D4DA42A1C48103BF4CFA5A01115575@EUR-MSG-20.europe.corp.microsoft.com> Thread-Topic: [Ipsec] IKEv2 needs a "policy usage mode"... thread-index: AcUTmXdO4dHEcbugQuqbU8XnxXMxggAsMmnw From: "Michael Roe" To: X-OriginalArrivalTime: 16 Feb 2005 17:37:14.0983 (UTC) FILETIME=[27553F70:01C5144E] X-Spam-Score: 0.0 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable =20 Steve Kent writes: > Under 2401bis and IKE v2: > - decorrelation is an option, though not mandated. let's start > the analysis w/o assuming use of decorrelation ... > - given this new feature, the receiver should match the=20 > selected SPD > entry against the proposal sent by the initiator, and "narrow" the > response. the narrowed response should be the intersection of the > local and remote SPD entries, thus ensuring that traffic sent in both > directions will be accepted at each end. The problem is that it doesn't ensure that traffic sent on the SA will be accepted by the other end. If the initiator sends one of its (ordered, correlated) SPD entries in its traffic selectors, and the responder intersects this with one of its (ordered, correlated) SPD entries and sends the result back in its traffic selectors, then: a) AH or ESP packets sent by the IKE initiator may be dropped on receipt, because the IKE responder has higher-precedence SPD entries that the initiator doesn't know about. b) AH or ESP packets sent by the IKE responder may be dropped on receipt, because the IKE initiator has higher-precedence SPD entries that the responder doesn't know about. > so, to avoid creation of extra SAs, we ought not send just a=20 > decorrelated entry as a proposal, but we could choose to send the set=20 > of linked, decorrelated entries to a peer to help in the narrowing=20 > process, especially if the peer has a decorrelated SPD. Yes, what I meant was that the traffic seelctors ought to represent the set of linked, decorrelated entries that correspond to a single entry in the (ordered, correlated) SPD. The second problem is that you can't always do this. Sometimes the set of linked, decorrelated entries can't be represented in a single CREATE_CHILD_SA. Even when it can be represented, we sometimes have the problem that it can't be represented efficiently. Policies often have a BYPASS entry for ICMP, because otherwise you can't bootstrap. So you will often have entries in the decorrelated SPD for "all protocols except ICMP". To represent this, you need 254 traffic selectors in TSI and TSR. (A possible implementation approach would be to split such an SA into an SA for TCP+UDP, plus a separate SA for each protocol. In the common case, only the SA for TCP+UDP would be used). Mike _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Feb 16 15:06:35 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA14323 for ; Wed, 16 Feb 2005 15:06:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1V1K-0002BX-Op; Wed, 16 Feb 2005 14:39:34 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1TLv-000106-8Q for ipsec@megatron.ietf.org; Wed, 16 Feb 2005 12:52:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA06345 for ; Wed, 16 Feb 2005 12:52:39 -0500 (EST) Received: from ns.ca.certicom.com ([66.48.18.197] helo=mail.ca.certicom.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D1ThC-0004di-3u for ipsec@ietf.org; Wed, 16 Feb 2005 13:14:43 -0500 Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 472681003F for ; Wed, 16 Feb 2005 12:52:09 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 04487-41 for ; Wed, 16 Feb 2005 12:51:58 -0500 (EST) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id CC1CC1006C for ; Wed, 16 Feb 2005 12:51:57 -0500 (EST) To: ipsec@ietf.org X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Tom Stiemerling Date: Wed, 16 Feb 2005 12:42:47 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 02/16/2005 12:42:35 PM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Ipsec] Rekeying IKE_SA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Couple of questions about creating child IKE_SA: When you create a child IKE SA, does the old IKE_SA get implicitly deleted, or do you have to send a Delete payload in an INFORMATIONAL exchange subsequently to the CREATE_CHILD_SA exchange to delete the old IKE_SA? Also, who sends the Delete payload first, the initiator of the CHILD_SA exchange? Thanks, Tom _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Feb 16 15:22:32 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA17688 for ; Wed, 16 Feb 2005 15:22:32 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1VJO-00047Z-P5; Wed, 16 Feb 2005 14:58:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1UFl-0003HZ-Np for ipsec@megatron.ietf.org; Wed, 16 Feb 2005 13:50:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22591 for ; Wed, 16 Feb 2005 13:50:20 -0500 (EST) Received: from [217.219.18.2] (helo=cc2.iut.ac.ir) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Uaz-0001ZC-TM for ipsec@ietf.org; Wed, 16 Feb 2005 14:12:23 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by cc2.iut.ac.ir (Postfix) with ESMTP id 53AB56817C for ; Wed, 16 Feb 2005 22:36:54 +0330 (IRST) Received: from cc2.iut.ac.ir ([127.0.0.1]) by localhost (cc2.iut.ac.ir [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 28009-01-20 for ; Wed, 16 Feb 2005 22:36:52 +0330 (IRST) Received: from ec.iut.ac.ir (localhost.localdomain [127.0.0.1]) by cc2.iut.ac.ir (Postfix) with ESMTP id DD9446817B for ; Wed, 16 Feb 2005 22:36:52 +0330 (IRST) From: "mahdavi" To: ipsec@ietf.org Date: Wed, 16 Feb 2005 22:36:52 +0330 Message-Id: <20050216185344.M14671@ec.iut.ac.ir> X-Mailer: Open WebMail 2.41 20041227 X-OriginatingIP: 193.251.135.125 (mahdavi@ec.iut.ac.ir) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 X-Virus-Scanned: amavisd-new at cc2.iut.ac.ir X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Ipsec] Multi port router and SPD. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi all. In a router can I use JUST ONE PAIR of SPDs (one for Inbound and another for Outbound) for all incomming (or outgoing) packets from DIFFERENT PORTS of router regardless of which port the packets are comming in ( or going out )? (Because of Implementation problems in hardware I want to use one policy for all ports of router. Does this affects security of IPsec? ) PS: I want to be complient with rfc2401 not rfc2401bis. Best of regards. mahdavi. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Feb 16 16:59:26 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01519 for ; Wed, 16 Feb 2005 16:59:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1XAB-0003zN-Ji; Wed, 16 Feb 2005 16:56:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1X2Q-0000Ur-W8 for ipsec@megatron.ietf.org; Wed, 16 Feb 2005 16:48:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA00517 for ; Wed, 16 Feb 2005 16:48:48 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1XNk-0003ug-G1 for ipsec@ietf.org; Wed, 16 Feb 2005 17:10:53 -0500 Received: from [10.1.190.35] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j1GLlckP027707; Wed, 16 Feb 2005 16:47:50 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <200502161359.j1GDx5SK016618@burp.tkv.asdf.org> References: <200502161359.j1GDx5SK016618@burp.tkv.asdf.org> Date: Wed, 16 Feb 2005 12:22:18 -0500 To: Markku Savela From: Stephen Kent Subject: Re: [Ipsec] Minor comment/question on draft-ietf-ipsec-esp-v3-09.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.7 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 3:59 PM +0200 2/16/05, Markku Savela wrote: >Minor nit (or my misunderstanding of something), but in > >2.3 Payload Data > ... > Note that the beginning of the next layer protocol header MUST be > aligned relative to the beginning of the ESP header as follows. For > IPv4, this alignment is a multiple of 4 bytes. For IPv6, the > alignment is a multiple of 8 bytes. > ... > > >I'm puzzled about what the "next layer protocol header" means? With >ESP, the packet really does not have any next layer header, that needs >alignment. > >The paragraphah can be deleted? > >[Of course, after inbound ESP processing we have the header and it >must be properly aligned, but that is a different matter.] > Inside the ESP payload, after the optional IV, is the "next layer protocol header." It is referred to as "rest of payload data" in Figure 2. Typically, for transport mode this will be TCP or UDP. For tunnel mode, it is IP. This text is part of a discussion reminding folks that the IV, if present, must preserve the 4 or 8 byte alignment requirements for the relevant IP version. We assume that the ESP payload, overall, started on an appropriate boundary, so the addition of the 8 bytes of SPI plus sequence number preserved this alignment. But the IV, if present, could break the alignment. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Feb 16 17:26:28 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04402 for ; Wed, 16 Feb 2005 17:26:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1XWk-0005Cr-Sx; Wed, 16 Feb 2005 17:20:10 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1XPX-0001qP-PG for ipsec@megatron.ietf.org; Wed, 16 Feb 2005 17:12:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03025 for ; Wed, 16 Feb 2005 17:12:40 -0500 (EST) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1Xkr-0004g7-7z for ipsec@ietf.org; Wed, 16 Feb 2005 17:34:46 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.2/8.13.2/Debian-1) with ESMTP id j1GMCXQS024848; Thu, 17 Feb 2005 00:12:33 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.2/8.13.2/Submit) id j1GMCXAQ024845; Thu, 17 Feb 2005 00:12:33 +0200 Date: Thu, 17 Feb 2005 00:12:33 +0200 Message-Id: <200502162212.j1GMCXAQ024845@burp.tkv.asdf.org> From: Markku Savela To: kent@bbn.com In-reply-to: (message from Stephen Kent on Wed, 16 Feb 2005 12:22:18 -0500) Subject: Re: [Ipsec] Minor comment/question on draft-ietf-ipsec-esp-v3-09.txt References: <200502161359.j1GDx5SK016618@burp.tkv.asdf.org> X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org > From: Stephen Kent > Inside the ESP payload, after the optional IV, is the "next layer > protocol header." It is referred to as "rest of payload data" in > Figure 2. Typically, for transport mode this will be TCP or UDP. For > tunnel mode, it is IP. This text is part of a discussion reminding > folks that the IV, if present, must preserve the 4 or 8 byte > alignment requirements for the relevant IP version. We assume that > the ESP payload, overall, started on an appropriate boundary, so the > addition of the 8 bytes of SPI plus sequence number preserved this > alignment. But the IV, if present, could break the alignment. I knew that, but I assumed the removal of the ESP headers from the packet required shifting of data within the packet anyway, so the aligment requirement seemed unnecessary. I suppose, it might make some optimizations in the shifting possible. However, this is a new requirement compared to RFC-2406? Can it be "MUST"? _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Feb 16 18:05:30 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA08126 for ; Wed, 16 Feb 2005 18:05:30 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1Y2I-00021J-EK; Wed, 16 Feb 2005 17:52:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1XyZ-0008I0-By for ipsec@megatron.ietf.org; Wed, 16 Feb 2005 17:48:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06348 for ; Wed, 16 Feb 2005 17:48:52 -0500 (EST) Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1YJt-0005iu-5H for ipsec@ietf.org; Wed, 16 Feb 2005 18:10:58 -0500 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id j1GMmM9S023803 for ; Wed, 16 Feb 2005 17:48:22 -0500 Received: from M30.equallogic.com (m30 [172.16.1.30]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id j1GMmKGa023798; Wed, 16 Feb 2005 17:48:20 -0500 Received: from pkoning.equallogic.com ([172.16.1.139]) by M30.equallogic.com with Microsoft SMTPSVC(5.0.2195.6713); Wed, 16 Feb 2005 17:48:19 -0500 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16915.52658.617227.384253@gargle.gargle.HOWL> Date: Wed, 16 Feb 2005 17:48:18 -0500 From: Paul Koning To: msa@burp.tkv.asdf.org Subject: Re: [Ipsec] Minor comment/question on draft-ietf-ipsec-esp-v3-09.txt References: <200502161359.j1GDx5SK016618@burp.tkv.asdf.org> <200502162212.j1GMCXAQ024845@burp.tkv.asdf.org> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid X-OriginalArrivalTime: 16 Feb 2005 22:48:19.0947 (UTC) FILETIME=[9C84BBB0:01C51479] X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, kent@bbn.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit >>>>> "Markku" == Markku Savela writes: >> From: Stephen Kent >> Inside the ESP payload, after the optional IV, is the "next layer >> protocol header." It is referred to as "rest of payload data" in >> Figure 2. Typically, for transport mode this will be TCP or >> UDP. For tunnel mode, it is IP. This text is part of a discussion >> reminding folks that the IV, if present, must preserve the 4 or 8 >> byte alignment requirements for the relevant IP version. We assume >> that the ESP payload, overall, started on an appropriate boundary, >> so the addition of the 8 bytes of SPI plus sequence number >> preserved this alignment. But the IV, if present, could break the >> alignment. Markku> I knew that, but I assumed the removal of the ESP headers Markku> from the packet required shifting of data within the packet Markku> anyway, so the aligment requirement seemed unnecessary. No... you don't shift the data, you change the start of data pointer. Then you reference header fields relative to that pointer. If the alignment requirement isn't satisfied, then you can end up in situations where the original alignment lets you do nice efficient aligned memory loads, but after adjusting the pointer past the ESP header you have to use unaligned load sequences. Either that, or you don't realize this and your box crashes on an unaligned load fault... :-( paul _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Feb 17 01:16:00 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA21195 for ; Thu, 17 Feb 2005 01:15:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1evD-0004T9-82; Thu, 17 Feb 2005 01:13:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1ep4-0002cl-93 for ipsec@megatron.ietf.org; Thu, 17 Feb 2005 01:07:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA19569 for ; Thu, 17 Feb 2005 01:07:33 -0500 (EST) Received: from sj-iport-3-in.cisco.com ([171.71.176.72] helo=sj-iport-3.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1fAS-0000NS-P2 for ipsec@ietf.org; Thu, 17 Feb 2005 01:29:41 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-3.cisco.com with ESMTP; 16 Feb 2005 23:20:16 +0000 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,92,1107734400"; d="scan'208"; a="226214038:sNHT20530368" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1H66wuC010562; Wed, 16 Feb 2005 22:06:58 -0800 (PST) Received: from ghuangw2k01 ([10.32.227.26]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with SMTP id BBT53856; Wed, 16 Feb 2005 22:06:59 -0800 (PST) Message-Id: <200502170606.BBT53856@mira-sjc5-b.cisco.com> From: "Geoffrey Huang" To: "'Tom Stiemerling'" , Subject: RE: [Ipsec] Rekeying IKE_SA Date: Wed, 16 Feb 2005 22:06:59 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 thread-index: AcUUYwgXbtolup7zSDiXVW07UVxXFgAU1HIA X-Spam-Score: 0.0 (/) X-Scan-Signature: 769a46790fb42fbb0b0cc700c82f7081 Content-Transfer-Encoding: 7bit X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit See section 2.8 of the draft: The Delete payload to delete itself MUST be the last request sent over an IKE_SA. This implies that you explicitly delete the old IKE SA. As far as who sends the delete payload "first" -- I believe the answer should be whoever has the shorter life time. So suppose you have two peers, A and B. Suppose the lifetime on A is configured for 30 minutes, whereas B's lifetime is configured for 60 minutes. A will initiate the rekey at 30 minutes (or probably a bit before that). Since A's lifetime expires first, I would imagine that A would send the delete first. I do not believe that the rekey of an IKE SA via the create-child exchange should be the impetus for the responder of the exchange to send out a delete message. (Was that clear?) -g > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Tom Stiemerling > Sent: Wednesday, February 16, 2005 9:43 AM > To: ipsec@ietf.org > Subject: [Ipsec] Rekeying IKE_SA > > > > > > Couple of questions about creating child IKE_SA: > > When you create a child IKE SA, does the old IKE_SA get > implicitly deleted, or do you have to send a Delete payload > in an INFORMATIONAL exchange subsequently to the > CREATE_CHILD_SA exchange to delete the old IKE_SA? Also, who > sends the Delete payload first, the initiator of the CHILD_SA > exchange? > > Thanks, Tom > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Feb 17 13:43:26 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA18343 for ; Thu, 17 Feb 2005 13:43:26 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1o1o-0001JY-MS; Thu, 17 Feb 2005 10:57:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1nHh-0001DH-2N for ipsec@megatron.ietf.org; Thu, 17 Feb 2005 10:09:41 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03547 for ; Thu, 17 Feb 2005 10:09:39 -0500 (EST) Received: from ns.ca.certicom.com ([66.48.18.197] helo=mail.ca.certicom.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D1nd9-0005t8-CR for ipsec@ietf.org; Thu, 17 Feb 2005 10:31:52 -0500 Received: from spamfilter.certicom.com (storm [127.0.0.1]) by mail.ca.certicom.com (Postfix) with ESMTP id 4A3D510088; Thu, 17 Feb 2005 10:09:08 -0500 (EST) Received: from mail.ca.certicom.com ([127.0.0.1]) by spamfilter.certicom.com (storm [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07487-09; Thu, 17 Feb 2005 10:08:55 -0500 (EST) Received: from certicom1.certicom.com (domino1.certicom.com [10.0.1.24]) by mail.ca.certicom.com (Postfix) with ESMTP id 9992410084; Thu, 17 Feb 2005 10:08:55 -0500 (EST) In-Reply-To: <200502170606.BBT53856@mira-sjc5-b.cisco.com> Subject: RE: [Ipsec] Rekeying IKE_SA To: "Geoffrey Huang" X-Mailer: Lotus Notes Release 6.5.1 January 21, 2004 Message-ID: From: Tom Stiemerling Date: Thu, 17 Feb 2005 09:59:44 -0500 X-MIMETrack: Serialize by Router on Certicom1/Certicom(Release 6.5.1|January 21, 2004) at 02/17/2005 09:59:30 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 Geoffrey. My question actually related only to creating a child IKE SA (equivalent to rekeying the IKE SA), and not deleting an IKE SA in general. The spec says that when you create a child IKE SA you move all the child IPSEC SAs to the new IKE SA, and delete the original IKE SA. So my question was whether this is done implicitly as part of the create child sa exchange, or done subsequently using an informational exchange. Thanks, Tom "Geoffrey Huang" wrote on 02/17/2005 01:06:59 AM: > See section 2.8 of the draft: > > The Delete payload to delete itself MUST be the last request > sent over an IKE_SA. > > This implies that you explicitly delete the old IKE SA. > > As far as who sends the delete payload "first" -- I believe the answer > should be whoever has the shorter life time. So suppose you have two peers, > A and B. Suppose the lifetime on A is configured for 30 minutes, whereas > B's lifetime is configured for 60 minutes. A will initiate the rekey at 30 > minutes (or probably a bit before that). Since A's lifetime expires first, > I would imagine that A would send the delete first. > > I do not believe that the rekey of an IKE SA via the create-child exchange > should be the impetus for the responder of the exchange to send out a delete > message. (Was that clear?) _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Feb 17 16:38:58 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08003 for ; Thu, 17 Feb 2005 16:38:58 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1r8r-0003KB-Lq; Thu, 17 Feb 2005 14:16:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1peL-0001SW-LA for ipsec@megatron.ietf.org; Thu, 17 Feb 2005 12:41:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA02859 for ; Thu, 17 Feb 2005 12:41:11 -0500 (EST) Received: from sj-iport-1-in.cisco.com ([171.71.176.70] helo=sj-iport-1.cisco.com) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1pzp-0006Zn-Fh for ipsec@ietf.org; Thu, 17 Feb 2005 13:03:26 -0500 Received: from sj-core-1.cisco.com (171.71.177.237) by sj-iport-1.cisco.com with ESMTP; 17 Feb 2005 09:51:30 -0800 X-BrightmailFiltered: true X-Brightmail-Tracker: AAAAAA== X-IronPort-AV: i="3.90,95,1107763200"; d="scan'208"; a="615391367:sNHT1858607472" Received: from mira-sjc5-b.cisco.com (IDENT:mirapoint@mira-sjc5-b.cisco.com [171.71.163.14]) by sj-core-1.cisco.com (8.12.10/8.12.6) with ESMTP id j1HHdTuE012345; Thu, 17 Feb 2005 09:39:33 -0800 (PST) Received: from ghuangw2k01 (dhcp-128-107-163-234.cisco.com [128.107.163.234]) by mira-sjc5-b.cisco.com (MOS 3.4.5-GR) with ESMTP id BBU16322; Thu, 17 Feb 2005 09:39:30 -0800 (PST) Message-Id: <200502171739.BBU16322@mira-sjc5-b.cisco.com> From: "Geoffrey Huang" To: "'Tom Stiemerling'" Subject: RE: [Ipsec] Rekeying IKE_SA Date: Thu, 17 Feb 2005 09:39:31 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 thread-index: AcUVAspqIXyrUiNoSUGzS5u+Be9OBQAFNJTA X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit My opinion is that it's done separately using an informational exchange. -g > -----Original Message----- > From: Tom Stiemerling [mailto:TStiemerling@certicom.com] > Sent: Thursday, February 17, 2005 7:00 AM > To: Geoffrey Huang > Cc: ipsec@ietf.org > Subject: RE: [Ipsec] Rekeying IKE_SA > > > > > > Thanks Geoffrey. My question actually related only to > creating a child IKE SA (equivalent to rekeying the IKE SA), > and not deleting an IKE SA in general. The spec says that > when you create a child IKE SA you move all the child IPSEC > SAs to the new IKE SA, and delete the original IKE SA. So my > question was whether this is done implicitly as part of the > create child sa exchange, or done subsequently using an > informational exchange. > > Thanks, Tom > > "Geoffrey Huang" wrote on 02/17/2005 01:06:59 AM: > > > See section 2.8 of the draft: > > > > The Delete payload to delete itself MUST be the last request > > sent over an IKE_SA. > > > > This implies that you explicitly delete the old IKE SA. > > > > As far as who sends the delete payload "first" -- I believe > the answer > > should be whoever has the shorter life time. So suppose > you have two > peers, > > A and B. Suppose the lifetime on A is configured for 30 minutes, > > whereas B's lifetime is configured for 60 minutes. A will initiate > > the rekey at > 30 > > minutes (or probably a bit before that). Since A's lifetime expires > first, > > I would imagine that A would send the delete first. > > > > I do not believe that the rekey of an IKE SA via the create-child > exchange > > should be the impetus for the responder of the exchange to > send out a > delete > > message. (Was that clear?) > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Feb 17 17:25:10 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16706 for ; Thu, 17 Feb 2005 17:25:10 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1ti7-0005YR-GP; Thu, 17 Feb 2005 17:01:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1sKV-0007cu-2o for ipsec@megatron.ietf.org; Thu, 17 Feb 2005 15:32:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02092 for ; Thu, 17 Feb 2005 15:32:52 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1sfy-0006kB-3n for ipsec@ietf.org; Thu, 17 Feb 2005 15:55:09 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j1HL2P814592 for ; Thu, 17 Feb 2005 13:02:25 -0800 X-mProtect: <200502172102> Nokia Silicon Valley Messaging Protection Received: from hannu.iprg.nokia.com (205.226.2.79, claiming to be "[205.226.2.79]") by darkstar.iprg.nokia.com smtpdNRheF8; Thu, 17 Feb 2005 13:02:21 PST Message-ID: <4214FF40.5010302@iprg.nokia.com> Date: Thu, 17 Feb 2005 12:32:00 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Content-Transfer-Encoding: 7bit Subject: [Ipsec] INTERNAL_IP6_SUBNET and multiple prefixes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit hi all, how does the initiator ask for information on multiple IPv6 prefixes by using the INTERNAL_IP6_SUBNET attribute? section 3.15.1 says o INTERNAL_IP6_SUBNET - The protected sub-networks that this edge-device protects. This attribute is made up of two fields; the first being a 16 octet IPv6 address the second being a one octet prefix-length as defined in [ADDRIPV6]. Multiple sub-networks MAY be requested. The responder MAY respond with zero or more sub-network attributes. the INTERNAL_IP6_SUBNET seems to have a fixed length of 21 (4 + 17 for value) octets. I guess the responder could send information about multiple IPv6 prefixes by including multiple INTERNAL_IP6_SUBNET attributes in the the CFG_REPLY payload. but how does the initiator indicate whether it wants information about one IPv6 prefix or all the IPv6 prefixes? or the does the responder by default send information about all the IPv6 prefixes? Vijay _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Feb 17 20:35:00 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08053 for ; Thu, 17 Feb 2005 20:35:00 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1wwe-0003V5-9o; Thu, 17 Feb 2005 20:28:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D1wm3-0006rc-5M for ipsec@megatron.ietf.org; Thu, 17 Feb 2005 20:17:39 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA06082 for ; Thu, 17 Feb 2005 20:17:38 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D1x7b-0007nA-7Q for ipsec@ietf.org; Thu, 17 Feb 2005 20:39:56 -0500 Received: from eastmail2bur.East.Sun.COM ([129.148.13.40]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j1I1HUhl000070; Thu, 17 Feb 2005 18:17:31 -0700 (MST) Received: from thunk (thunk.East.Sun.COM [129.148.174.66]) by eastmail2bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j1I1HUOp021133; Thu, 17 Feb 2005 20:17:30 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j1I1HUxG025447; Thu, 17 Feb 2005 20:17:30 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j1I1HT6b025446; Thu, 17 Feb 2005 20:17:29 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: [Ipsec] Multi port router and SPD. From: Bill Sommerfeld To: mahdavi In-Reply-To: <20050216185344.M14671@ec.iut.ac.ir> References: <20050216185344.M14671@ec.iut.ac.ir> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1108689448.25320.22.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Thu, 17 Feb 2005 20:17:29 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit On Wed, 2005-02-16 at 14:06, mahdavi wrote: > (Because of Implementation problems in hardware I want to use one policy for > all ports of router. Does this affects security of IPsec? ) This sort of policy makes sense in a host implementation where the trusted area is entirely inside the box and all external ports are equally untrusted. if your goal is to use IPsec to (for instance) secure management traffic to or from the router itself, this could be ok. If the goal is to protect traffic *through* the router you must exercise extreme caution. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Feb 18 06:49:32 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21816 for ; Fri, 18 Feb 2005 06:49:29 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D26Zc-000604-Oz; Fri, 18 Feb 2005 06:45:28 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D26Tt-0003xu-Vb for ipsec@megatron.ietf.org; Fri, 18 Feb 2005 06:39:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA21020 for ; Fri, 18 Feb 2005 06:39:31 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-x3.nokia.com ([131.228.20.26]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D26pY-0005cs-5Y for ipsec@ietf.org; Fri, 18 Feb 2005 07:01:56 -0500 Received: from esdks003.ntc.nokia.com (esdks003.ntc.nokia.com [172.21.138.158]) by mgw-x3.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1IBdVA19938 for ; Fri, 18 Feb 2005 13:39:31 +0200 (EET) X-Scanned: Fri, 18 Feb 2005 13:39:26 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks003.ntc.nokia.com (8.12.9/8.12.9) id j1IBdQck003430 for ; Fri, 18 Feb 2005 13:39:26 +0200 Received: from mgw-int1.ntc.nokia.com (172.21.143.96) by esdks003.ntc.nokia.com 0036Iuzc; Fri, 18 Feb 2005 13:39:25 EET Received: from esebh001.NOE.Nokia.com (esebh001.ntc.nokia.com [172.21.138.28]) by mgw-int1.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1IBdMM19168 for ; Fri, 18 Feb 2005 13:39:22 +0200 (EET) Received: from esebe018.NOE.Nokia.com ([172.21.138.57]) by esebh001.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 18 Feb 2005 13:39:18 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe018.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Fri, 18 Feb 2005 13:39:17 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] INTERNAL_IP6_SUBNET and multiple prefixes Date: Fri, 18 Feb 2005 13:39:17 +0200 Message-ID: Thread-Topic: [Ipsec] INTERNAL_IP6_SUBNET and multiple prefixes Thread-Index: AcUVP9bkEWOgJv3/R7qE8C1rhM20MQAbH3zA To: , X-OriginalArrivalTime: 18 Feb 2005 11:39:17.0255 (UTC) FILETIME=[7A6F8970:01C515AE] X-Spam-Score: 0.3 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable In draft-eronen-ipsec-ikev2-clarifications-00 my preliminary conclusion was that the INTERNAL_IP4/6_SUBNET attributes do=20 not make sense in CFG_REQUESTs.=20 If the responder wants to send one or more INTERNAL_IP4/6_SUBNET attributes, it should do so, regardless of whether the initiator=20 asked for them or not (the initiator will ignore them if it has=20 no use for them). This case is also shown in the example in=20 Section 2.19. (It looks like the sentence "Multiple sub-networks MAY be requested" was copied verbatim from the MODE-CFG draft from 1999, but no longer makes sense. Or at least that's my current interpretation -- other comments are certainly welcome.) Best regards, Pasi > -----Original Message----- > From: Vijay Devarapalli > Sent: Thursday, February 17, 2005 10:32 PM > To: ipsec@ietf.org > Subject: [Ipsec] INTERNAL_IP6_SUBNET and multiple prefixes >=20 >=20 > hi all, >=20 > how does the initiator ask for information on multiple IPv6=20 > prefixes by using the INTERNAL_IP6_SUBNET attribute? >=20 > section 3.15.1 says >=20 > o INTERNAL_IP6_SUBNET - The protected sub-networks that > this edge-device protects. This attribute is made up=20 > of two fields; the first being a 16 octet IPv6 address=20 > the second being a one octet prefix-length as defined=20 > in [ADDRIPV6]. Multiple sub-networks MAY be requested. =20 > The responder MAY respond with zero or more sub-network=20 > attributes. >=20 > the INTERNAL_IP6_SUBNET seems to have a fixed length of 21 (4 > + 17 for value) octets. I guess the responder could send > information about multiple IPv6 prefixes by including multiple > INTERNAL_IP6_SUBNET attributes in the the CFG_REPLY > payload. but how does the initiator indicate whether it wants > information about one IPv6 prefix or all the IPv6 prefixes? or > the does the responder by default send information about all > the IPv6 prefixes? >=20 > Vijay _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Feb 18 15:10:45 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA05763 for ; Fri, 18 Feb 2005 15:10:45 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2E7p-0005ng-Pw; Fri, 18 Feb 2005 14:49:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2Dtw-0000pc-5Z for ipsec@megatron.ietf.org; Fri, 18 Feb 2005 14:34:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA00292 for ; Fri, 18 Feb 2005 14:34:54 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2EFc-00077C-Qn for ipsec@ietf.org; Fri, 18 Feb 2005 14:57:22 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j1IK4Oc28837; Fri, 18 Feb 2005 12:04:24 -0800 X-mProtect: <200502182004> Nokia Silicon Valley Messaging Protection Received: from hannu.iprg.nokia.com (205.226.2.79, claiming to be "[205.226.2.79]") by darkstar.iprg.nokia.com smtpdruY22T; Fri, 18 Feb 2005 12:04:17 PST Message-ID: <42164327.8090701@iprg.nokia.com> Date: Fri, 18 Feb 2005 11:33:59 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pasi.Eronen@nokia.com, charliek@microsoft.com Subject: Re: [Ipsec] INTERNAL_IP6_SUBNET and multiple prefixes 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: bdc523f9a54890b8a30dd6fd53d5d024 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Pasi.Eronen@nokia.com wrote: > In draft-eronen-ipsec-ikev2-clarifications-00 my preliminary > conclusion was that the INTERNAL_IP4/6_SUBNET attributes do > not make sense in CFG_REQUESTs. hmm.. but what if the initiator does not want to know about the prefixes? IMO, the initiator should include the INTERNAL_IP6_SUBNET attribute in CFG_REQUEST and the responder should just send information on all prefixes. > If the responder wants to send one or more INTERNAL_IP4/6_SUBNET > attributes, it should do so, regardless of whether the initiator > asked for them or not (the initiator will ignore them if it has > no use for them). This case is also shown in the example in > Section 2.19. okay. > (It looks like the sentence "Multiple sub-networks MAY be > requested" was copied verbatim from the MODE-CFG draft from > 1999, but no longer makes sense. Or at least that's my > current interpretation -- other comments are certainly welcome.) should this be fixed during AUTH48 edits? we just need to remove "Multiple sub-networks MAY be requested." and say the responder always sends information on all prefixes? Charlie? Vijay > > Best regards, > Pasi > > >>-----Original Message----- >>From: Vijay Devarapalli >>Sent: Thursday, February 17, 2005 10:32 PM >>To: ipsec@ietf.org >>Subject: [Ipsec] INTERNAL_IP6_SUBNET and multiple prefixes >> >> >>hi all, >> >>how does the initiator ask for information on multiple IPv6 >>prefixes by using the INTERNAL_IP6_SUBNET attribute? >> >>section 3.15.1 says >> >> o INTERNAL_IP6_SUBNET - The protected sub-networks that >> this edge-device protects. This attribute is made up >> of two fields; the first being a 16 octet IPv6 address >> the second being a one octet prefix-length as defined >> in [ADDRIPV6]. Multiple sub-networks MAY be requested. >> The responder MAY respond with zero or more sub-network >> attributes. >> >>the INTERNAL_IP6_SUBNET seems to have a fixed length of 21 (4 >>+ 17 for value) octets. I guess the responder could send >>information about multiple IPv6 prefixes by including multiple >>INTERNAL_IP6_SUBNET attributes in the the CFG_REPLY >>payload. but how does the initiator indicate whether it wants >>information about one IPv6 prefix or all the IPv6 prefixes? or >>the does the responder by default send information about all >>the IPv6 prefixes? >> >>Vijay > > > > _______________________________________________ > 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 Feb 18 15:37:04 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10284 for ; Fri, 18 Feb 2005 15:37:04 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2EYZ-0000Pf-9Z; Fri, 18 Feb 2005 15:16:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2EXS-0007uJ-1z for ipsec@megatron.ietf.org; Fri, 18 Feb 2005 15:15:46 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA07009 for ; Fri, 18 Feb 2005 15:15:44 -0500 (EST) Received: from mail2.microsoft.com ([131.107.3.124]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2Et8-0000cV-Ix for ipsec@ietf.org; Fri, 18 Feb 2005 15:38:13 -0500 Received: from mailout1.microsoft.com ([157.54.1.117]) by mail2.microsoft.com with Microsoft SMTPSVC(6.0.3790.211); Fri, 18 Feb 2005 12:15:10 -0800 Received: from RED-MSG-51.redmond.corp.microsoft.com ([157.54.12.11]) by mailout1.microsoft.com with Microsoft SMTPSVC(6.0.3790.1289); Fri, 18 Feb 2005 12:15:10 -0800 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] INTERNAL_IP6_SUBNET and multiple prefixes Date: Fri, 18 Feb 2005 12:15:08 -0800 Message-ID: Thread-Topic: [Ipsec] INTERNAL_IP6_SUBNET and multiple prefixes Thread-Index: AcUV8OWzyxuVC8rsQ52os/iz0rpMLwAAiqXg From: "Charlie Kaufman" To: "Vijay Devarapalli" , X-OriginalArrivalTime: 18 Feb 2005 20:15:10.0126 (UTC) FILETIME=[8BC8D4E0:01C515F6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 67c1ea29f88502ef6a32ccec927970f0 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable The current language is (by my reading at least) self-inconsistent, which makes it a good candidate for fixing in AUTH48. The inconsistency is that the Attribute Type table lists INTERNAL_IP4/6_SUBNET as not multivalued while the text says that multiple values can be requested and returned. From the discussion below, I gather that the text is right and the table should say "YES". (This also affects the IANA registry). The syntax of the CFG_REQUEST with respect to multivalued attributes is not what I would have designed, but I believe it is unambiguous and I see no compelling reason the change it at this late date. For all but two of the multivalued attributes, the syntax allows the field to be requested multiple times in the request (which seems silly) and allows the responder to return all of the values of the requested attribute even if only one is requested. I can think of no reason why someone would repeat a request. This wording effectively requires that an implementation of a responder ignore such duplicate requests. The exception is for INTERNAL_IP4/6_ADDRESS, where the number of times the request is repeated indicates the number of addresses requested to be allocated. In any case, the syntactical clumsiness is not limited to INTERNAL_IP4/6_SUBNET, but also applies to INTERNAL_IP4/6_DNS/NBNS/DHCP, and if we were to change it in one place we should change it in all. But I'm not convinced a change is needed. Do you still think so? --Charlie -----Original Message----- From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com]=20 Sent: Friday, February 18, 2005 11:34 AM To: Pasi.Eronen@nokia.com; Charlie Kaufman Cc: ipsec@ietf.org Subject: Re: [Ipsec] INTERNAL_IP6_SUBNET and multiple prefixes Pasi.Eronen@nokia.com wrote: > In draft-eronen-ipsec-ikev2-clarifications-00 my preliminary > conclusion was that the INTERNAL_IP4/6_SUBNET attributes do=20 > not make sense in CFG_REQUESTs.=20 hmm.. but what if the initiator does not want to know about the prefixes? IMO, the initiator should include the INTERNAL_IP6_SUBNET attribute in CFG_REQUEST and the responder should just send information on all prefixes. > If the responder wants to send one or more INTERNAL_IP4/6_SUBNET > attributes, it should do so, regardless of whether the initiator=20 > asked for them or not (the initiator will ignore them if it has=20 > no use for them). This case is also shown in the example in=20 > Section 2.19. okay. > (It looks like the sentence "Multiple sub-networks MAY be > requested" was copied verbatim from the MODE-CFG draft from > 1999, but no longer makes sense. Or at least that's my > current interpretation -- other comments are certainly welcome.) should this be fixed during AUTH48 edits? we just need to remove "Multiple sub-networks MAY be requested." and say the responder always sends information on all prefixes? Charlie? Vijay >=20 > Best regards, > Pasi >=20 >=20 >>-----Original Message----- >>From: Vijay Devarapalli >>Sent: Thursday, February 17, 2005 10:32 PM >>To: ipsec@ietf.org >>Subject: [Ipsec] INTERNAL_IP6_SUBNET and multiple prefixes >> >> >>hi all, >> >>how does the initiator ask for information on multiple IPv6=20 >>prefixes by using the INTERNAL_IP6_SUBNET attribute? >> >>section 3.15.1 says >> >> o INTERNAL_IP6_SUBNET - The protected sub-networks that >> this edge-device protects. This attribute is made up=20 >> of two fields; the first being a 16 octet IPv6 address=20 >> the second being a one octet prefix-length as defined=20 >> in [ADDRIPV6]. Multiple sub-networks MAY be requested. =20 >> The responder MAY respond with zero or more sub-network=20 >> attributes. >> >>the INTERNAL_IP6_SUBNET seems to have a fixed length of 21 (4 >>+ 17 for value) octets. I guess the responder could send >>information about multiple IPv6 prefixes by including multiple >>INTERNAL_IP6_SUBNET attributes in the the CFG_REPLY >>payload. but how does the initiator indicate whether it wants >>information about one IPv6 prefix or all the IPv6 prefixes? or >>the does the responder by default send information about all >>the IPv6 prefixes? >> >>Vijay >=20 >=20 >=20 > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Feb 18 18:58:35 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA27257 for ; Fri, 18 Feb 2005 18:58:34 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2HKx-0003wY-C3; Fri, 18 Feb 2005 18:15:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2GQ7-0002FX-KY for ipsec@megatron.ietf.org; Fri, 18 Feb 2005 17:16:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA07645 for ; Fri, 18 Feb 2005 17:16:17 -0500 (EST) Received: from darkstar.iprg.nokia.com ([205.226.5.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D2Glr-00021j-Aw for ipsec@ietf.org; Fri, 18 Feb 2005 17:38:47 -0500 Received: (from root@localhost) by darkstar.iprg.nokia.com (8.11.0/8.11.0-DARKSTAR) id j1IMjlL14348; Fri, 18 Feb 2005 14:45:47 -0800 X-mProtect: <200502182245> Nokia Silicon Valley Messaging Protection Received: from hannu.iprg.nokia.com (205.226.2.79, claiming to be "[205.226.2.79]") by darkstar.iprg.nokia.com smtpdwU56xP; Fri, 18 Feb 2005 14:45:39 PST Message-ID: <421668FA.9060902@iprg.nokia.com> Date: Fri, 18 Feb 2005 14:15:22 -0800 From: Vijay Devarapalli User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charlie Kaufman Subject: Re: [Ipsec] INTERNAL_IP6_SUBNET and multiple prefixes References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 3d7f2f6612d734db849efa86ea692407 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Charlie Kaufman wrote: > The current language is (by my reading at least) self-inconsistent, > which makes it a good candidate for fixing in AUTH48. > > The inconsistency is that the Attribute Type table lists > INTERNAL_IP4/6_SUBNET as not multivalued while the text says that > multiple values can be requested and returned. From the discussion > below, I gather that the text is right and the table should say "YES". > (This also affects the IANA registry). > The syntax of the CFG_REQUEST with respect to multivalued attributes is > not what I would have designed, but I believe it is unambiguous and I > see no compelling reason the change it at this late date. For all but > two of the multivalued attributes, the syntax allows the field to be > requested multiple times in the request (which seems silly) and allows > the responder to return all of the values of the requested attribute > even if only one is requested. regarding INTERNAL_IP64/6_SUBNET, the problem comes when the initiator does not know for sure if the responder sent information about all subnets, or just one subnet or a subset of the subnets. I agree it does not make sense for the initiator to repeat an attribute in the CFG_REQUEST (with the exception of INTERNAL_IP4/6_ADDR). infact the initiator would not know how many times to repeat the attribute because it would not know how many subnets/DNS servers/DHCP servers are available. :) > I can think of no reason why someone > would repeat a request. This wording effectively requires that an > implementation of a responder ignore such duplicate requests. The > exception is for INTERNAL_IP4/6_ADDRESS, where the number of times the > request is repeated indicates the number of addresses requested to be > allocated. > In any case, the syntactical clumsiness is not limited to > INTERNAL_IP4/6_SUBNET, but also applies to INTERNAL_IP4/6_DNS/NBNS/DHCP, > and if we were to change it in one place we should change it in all. > > But I'm not convinced a change is needed. > > Do you still think so? well, if not this document, we need to document this somewhere. I am sure someone will come across this later and have the same question I had. we could just remove the text which says multiple sub-networks may be requested. and let the text about the responder replying with one or more attributes as it is. Vijay > > --Charlie > > -----Original Message----- > From: Vijay Devarapalli [mailto:vijayd@iprg.nokia.com] > Sent: Friday, February 18, 2005 11:34 AM > To: Pasi.Eronen@nokia.com; Charlie Kaufman > Cc: ipsec@ietf.org > Subject: Re: [Ipsec] INTERNAL_IP6_SUBNET and multiple prefixes > > Pasi.Eronen@nokia.com wrote: > >>In draft-eronen-ipsec-ikev2-clarifications-00 my preliminary >>conclusion was that the INTERNAL_IP4/6_SUBNET attributes do >>not make sense in CFG_REQUESTs. > > > hmm.. but what if the initiator does not want to know about > the prefixes? > > IMO, the initiator should include the INTERNAL_IP6_SUBNET > attribute in CFG_REQUEST and the responder should just send > information on all prefixes. > > >>If the responder wants to send one or more INTERNAL_IP4/6_SUBNET >>attributes, it should do so, regardless of whether the initiator >>asked for them or not (the initiator will ignore them if it has >>no use for them). This case is also shown in the example in >>Section 2.19. > > > okay. > > >>(It looks like the sentence "Multiple sub-networks MAY be >>requested" was copied verbatim from the MODE-CFG draft from >>1999, but no longer makes sense. Or at least that's my >>current interpretation -- other comments are certainly welcome.) > > > should this be fixed during AUTH48 edits? > > we just need to remove "Multiple sub-networks MAY be requested." > and say the responder always sends information on all prefixes? > > Charlie? > > Vijay > > > >>Best regards, >>Pasi >> >> >> >>>-----Original Message----- >>>From: Vijay Devarapalli >>>Sent: Thursday, February 17, 2005 10:32 PM >>>To: ipsec@ietf.org >>>Subject: [Ipsec] INTERNAL_IP6_SUBNET and multiple prefixes >>> >>> >>>hi all, >>> >>>how does the initiator ask for information on multiple IPv6 >>>prefixes by using the INTERNAL_IP6_SUBNET attribute? >>> >>>section 3.15.1 says >>> >>> o INTERNAL_IP6_SUBNET - The protected sub-networks that >>> this edge-device protects. This attribute is made up >>> of two fields; the first being a 16 octet IPv6 address >>> the second being a one octet prefix-length as defined >>> in [ADDRIPV6]. Multiple sub-networks MAY be requested. >>> The responder MAY respond with zero or more sub-network >>> attributes. >>> >>>the INTERNAL_IP6_SUBNET seems to have a fixed length of 21 (4 >>>+ 17 for value) octets. I guess the responder could send >>>information about multiple IPv6 prefixes by including multiple >>>INTERNAL_IP6_SUBNET attributes in the the CFG_REPLY >>>payload. but how does the initiator indicate whether it wants >>>information about one IPv6 prefix or all the IPv6 prefixes? or >>>the does the responder by default send information about all >>>the IPv6 prefixes? >>> >>>Vijay >> >> >> >>_______________________________________________ >>Ipsec mailing list >>Ipsec@ietf.org >>https://www1.ietf.org/mailman/listinfo/ipsec > > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Feb 18 19:43:17 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA01986 for ; Fri, 18 Feb 2005 19:43:17 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2ITP-0004SU-5V; Fri, 18 Feb 2005 19:27:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D2IHE-0004jh-Dk for ipsec@megatron.ietf.org; Fri, 18 Feb 2005 19:15:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA29772 for ; Fri, 18 Feb 2005 19:15:13 -0500 (EST) Received: from smtp819.mail.sc5.yahoo.com ([66.163.170.5]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D2Icz-0000Yu-BE for ipsec@ietf.org; Fri, 18 Feb 2005 19:37:46 -0500 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.163.215.163 with login) by smtp819.mail.sc5.yahoo.com with SMTP; 19 Feb 2005 00:15:13 -0000 Message-ID: <014f01c51618$134607f0$6701a8c0@adithya> From: "Mohan Parthasarathy" To: "Vijay Devarapalli" , References: <4214FF40.5010302@iprg.nokia.com> Subject: Re: [Ipsec] INTERNAL_IP6_SUBNET and multiple prefixes Date: Fri, 18 Feb 2005 16:14:58 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 x-mimeole: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Vijay, > hi all, > > how does the initiator ask for information on multiple IPv6 prefixes > by using the INTERNAL_IP6_SUBNET attribute? > > section 3.15.1 says > > o INTERNAL_IP6_SUBNET - The protected sub-networks that this > edge-device protects. This attribute is made up of two fields; > the first being a 16 octet IPv6 address the second being a one > octet prefix-length as defined in [ADDRIPV6]. Multiple > sub-networks MAY be requested. The responder MAY respond with > zero or more sub-network attributes. > > the INTERNAL_IP6_SUBNET seems to have a fixed length of 21 (4 + 17 for > value) octets. I guess the responder could send information about > multiple IPv6 prefixes by including multiple INTERNAL_IP6_SUBNET > attributes in the the CFG_REPLY payload. but how does the initiator Something related to INTERNAL_IP6_SUBNET was discussed before. It is not the only way to return the IPv6 prefixes. You can also use the traffic selector payloads to return the prefixes. This means that the SA you just established can be used access the prefixes sent back in the TSr (normal IKEv2 semantics). If you use INTERNAL_IP6_SUBNET, it tells the client that what subnets are behind the SG (usually needed by the client to implement split tunneling), but you need to establish separate SAs for accessing them. If at all we end up fixing something here, it might be worth clarifying this. -mohan > indicate whether it wants information about one IPv6 prefix or all the > IPv6 prefixes? or the does the responder by default send information > about all the IPv6 prefixes? > > Vijay > > _______________________________________________ > 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 Feb 23 00:33:05 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA12366 for ; Wed, 23 Feb 2005 00:33:05 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kXi-0003fS-K0; Tue, 22 Feb 2005 19:38:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kXg-0003f8-Rn for ipsec@megatron.ietf.org; Tue, 22 Feb 2005 19:38:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15650 for ; Tue, 22 Feb 2005 19:38:06 -0500 (EST) Received: from mailout.fastq.com ([204.62.193.66]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3kuA-0008KU-AN for ipsec@ietf.org; Tue, 22 Feb 2005 20:01:30 -0500 Received: from MMyersLapTop (dslstat-ppp-47.fastq.com [65.39.92.47]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id j1N0c7c03693; Tue, 22 Feb 2005 17:38:07 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" To: , Date: Tue, 22 Feb 2005 17:35:12 -0700 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: X-Spam-Score: 0.6 (/) X-Scan-Signature: 093efd19b5f651b2707595638f6c4003 Subject: [Ipsec] RE: OCSP in IKEv2, draft -02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1503587105==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1503587105== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0005_01C51904.DCAF0B70" This is a multi-part message in MIME format. ------=_NextPart_000_0005_01C51904.DCAF0B70 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable All, Apologies for the typo. The correct URL is http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-oscp-02.txt The document title should refer to OCSP, not OSCP. ^^ ^^ This will be corrected. Mike -----Original Message----- From: Michael Myers [mailto:mmyers@fastq.com] Sent: Tuesday, February 22, 2005 5:03 PM To: ietf-pkix@imc.org; ipsec@ietf.org Subject: OCSP in IKEv2, draft -02 Colleagues, Please consider the following contribution from Hannes Tschoefenig and = myself. http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-ocsp-02.txt We propose two IKEv2 CERT payload extensions which taken together enable = in-band use of OCSP in IKEv2. This -02 draft incorporates comments to = date. Mike ------=_NextPart_000_0005_01C51904.DCAF0B70 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
All,
 
Apologies=20 for the typo.  The correct URL is
 
http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-oscp-= 02.txt
 
The document=20 title should refer to OCSP, not OSCP.
          &nbs= p;           =20         =20     ^^        = ;^^
This will be=20 corrected.
 
Mike
 
-----Original Message-----
From: Michael Myers=20 [mailto:mmyers@fastq.com]
Sent: Tuesday, February 22, 2005 = 5:03=20 PM
To: ietf-pkix@imc.org; ipsec@ietf.org
Subject: = OCSP in=20 IKEv2, draft -02

Colleagues,
 
Please=20 consider the following contribution from Hannes Tschoefenig and=20 myself.
 
http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-ocsp-= 02.txt
 
We propose=20 two IKEv2 CERT payload extensions which taken together enable in-band = use of=20 OCSP in IKEv2.  This -02 draft incorporates comments to=20 date.
 
Mike
------=_NextPart_000_0005_01C51904.DCAF0B70-- --===============1503587105== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1503587105==-- From ipsec-bounces@ietf.org Wed Feb 23 20:42:28 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA18684 for ; Wed, 23 Feb 2005 20:42:28 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kmx-0006VW-Gr; Tue, 22 Feb 2005 19:54:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3VaT-0008CB-2x for ipsec@megatron.ietf.org; Tue, 22 Feb 2005 03:40:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA26745 for ; Tue, 22 Feb 2005 03:39:57 -0500 (EST) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3Vwk-0003nC-Uu for ipsec@ietf.org; Tue, 22 Feb 2005 04:03:11 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.3/8.13.3/Debian-6) with ESMTP id j1M8dvfh000329 for ; Tue, 22 Feb 2005 10:39:57 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.3/8.13.3/Submit) id j1M8dvU3000326; Tue, 22 Feb 2005 10:39:57 +0200 Date: Tue, 22 Feb 2005 10:39:57 +0200 Message-Id: <200502220839.j1M8dvU3000326@burp.tkv.asdf.org> From: Markku Savela To: ipsec@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Ipsec] More of ESN X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org One attack does occur to me... *IF* an attacker can create a packet with sequence number that is below the window and which passes the authentication check with the next higher sequence space, then attacker has practically shut down the connection (because all subsequent real packets will have "incorrect" high ESN part). Because high ESN is mostly 0, all that is needed is to be able to generate a single bit change that passes the authentication algorithm. I'm no expert on hashes and HMAC, so I have no idea how easy or difficult it would be. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Feb 23 20:44:01 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA19110 for ; Wed, 23 Feb 2005 20:44:01 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3lJ9-0001Yh-RB; Tue, 22 Feb 2005 20:27:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3lJ8-0001U9-7S for ipsec@megatron.ietf.org; Tue, 22 Feb 2005 20:27:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA11614 for ; Tue, 22 Feb 2005 19:05:33 -0500 (EST) Received: from mailout.fastq.com ([204.62.193.66]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3kOd-0007Lo-Ip for ipsec@ietf.org; Tue, 22 Feb 2005 19:28:57 -0500 Received: from MMyersLapTop (dslstat-ppp-47.fastq.com [65.39.92.47]) by mailout.fastq.com (8.11.6-2003091800/8.11.3.FastQ-MailOut) with SMTP id j1N05Sc01520; Tue, 22 Feb 2005 17:05:28 -0700 (MST) (envelope-from mmyers@fastq.com) From: "Michael Myers" To: , Date: Tue, 22 Feb 2005 17:02:32 -0700 Message-ID: MIME-Version: 1.0 X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <4216676F.30403@nist.gov> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal X-Spam-Score: 0.7 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [Ipsec] OCSP in IKEv2, draft -02 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0404837513==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0404837513== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C51900.4C5B3F70" This is a multi-part message in MIME format. ------=_NextPart_000_0013_01C51900.4C5B3F70 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Colleagues, Please consider the following contribution from Hannes Tschoefenig and = myself. http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-ocsp-02.txt We propose two IKEv2 CERT payload extensions which taken together enable = in-band use of OCSP in IKEv2. This -02 draft incorporates comments to = date. Mike ------=_NextPart_000_0013_01C51900.4C5B3F70 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable =EF=BB=BF
Colleagues,
 
Please=20 consider the following contribution from Hannes Tschoefenig and=20 myself.
 
http://www.ietf.org/internet-drafts/draft-myers-ipsec-ikev2-ocsp-= 02.txt
 
We propose two IKEv2 CERT payload extensions = which=20 taken together enable in-band use of OCSP in IKEv2.  This = -02 draft=20 incorporates comments to date.
 
Mike
------=_NextPart_000_0013_01C51900.4C5B3F70-- --===============0404837513== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0404837513==-- From ipsec-bounces@ietf.org Wed Feb 23 23:15:06 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA14327 for ; Wed, 23 Feb 2005 23:15:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3kmt-0006UP-Ro; Tue, 22 Feb 2005 19:53:59 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3VFz-0005iL-NR for ipsec@megatron.ietf.org; Tue, 22 Feb 2005 03:19:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA24687 for ; Tue, 22 Feb 2005 03:18:44 -0500 (EST) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3VcA-00035p-Vg for ipsec@ietf.org; Tue, 22 Feb 2005 03:41:58 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.3/8.13.3/Debian-6) with ESMTP id j1M8Ie5j032740 for ; Tue, 22 Feb 2005 10:18:40 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.3/8.13.3/Submit) id j1M8IdtO032737; Tue, 22 Feb 2005 10:18:39 +0200 Date: Tue, 22 Feb 2005 10:18:39 +0200 Message-Id: <200502220818.j1M8IdtO032737@burp.tkv.asdf.org> From: Markku Savela To: ipsec@ietf.org X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Ipsec] About extended sequence numbers X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Is my understanding correct in following: With old 32 bit sequence number logic, if you got and "old" packet below replay window, it was dropped without running the authentication algorithm. With new 64 bit sequence number logic, you don't know if the packet is old, until you have tried to authenticate it with the new higher "sequence subspace number". --- As far as I see, this is *not* new attack potential, as sequece numbers could always be adjusted so that algorithm must be run. It is just that a connection using ESN behaves a little bit differently from not using ESN. Just a curious observation, probably nothing to be concerned with? _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Feb 24 00:17:35 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA07153 for ; Thu, 24 Feb 2005 00:17:35 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3llm-0005s1-4m; Tue, 22 Feb 2005 20:56:54 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D3llj-0005py-6k for ipsec@megatron.ietf.org; Tue, 22 Feb 2005 20:56:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23976 for ; Tue, 22 Feb 2005 20:56:35 -0500 (EST) Received: from smtp.263xmail.com ([211.150.100.27]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D3m7z-0001tL-12 for Ipsec@ietf.org; Tue, 22 Feb 2005 21:19:59 -0500 Received: from windowsxpsp1 (e-smtp2 [127.0.0.1]) by smtp.263xmail.com (Postfix) with ESMTP id C2A74226E3 for ; Wed, 23 Feb 2005 09:55:51 +0800 (CST) (envelope-from eric.qu@360degreeweb.com.cn) Received: from windowsxpsp1 (unknown [221.216.117.235]) by antispam-2 (Coremail:263.net(263.net.20040702)) with SMTP id XtAFAKLiG0I8DHXr.2 for ; Wed, 23 Feb 2005 09:55:52 +0800 (CST) X-TEBIE-Originating-IP: [221.216.117.235] Message-ID: <001401c5194a$c30f95e0$6e01a8c0@windowsxpsp1> From: "eric.qu" To: Date: Wed, 23 Feb 2005 09:55:33 +0800 MIME-Version: 1.0 X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 X-Spam-Score: 2.2 (++) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Subject: [Ipsec] i have a question about manual key X-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="===============0322835994==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0322835994== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C5198D.D0B20D20" This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C5198D.D0B20D20 Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 aGkNCiAgaSBoYXZlIGEgcXVlc3Rpb24gYWJvdXQgbWFudWFsIGtleSANCiAgaSBoYXZlIHR3byBy b3V0ZSBieSBvd24gZGV2ZWxvcCwgaSBjYW4gZXN0YWJsaXNoIHRoZSB2cG4gdHVubmVsIGJ5IHVz ZSBtYW51YWwga2V5IC4gYW5kIHRlc3QgaWNtcCB0cmFmZmljIGZyb20gbGVmdCByb3V0ZSB0byBy aWdodCByb3V0ZSAsIGl0IGlzIG9rIC4NCiAgYW5kIHRoZW4gLCB0aGUgbGVmdCByb3V0ZSBjb250 aW51ZSBzZW5kIGVuY3J5cHQgaWNtcCB0cmFmZmljIHRvIHJpZ2h0LCBhbmQgY2hhbmdlIHRoZSBt YW51YWwga2V5IG9mIHJpZ2h0IHJvdXRlICxub3cgLCB0aGUgcmlnaHQgcm91dGUgZHJvcHBlZCBl bmNyeXB0IGljbXAgdHJhZmZpYyAsIGJlYWNhdXNlIHRoZSBtYW51YWwga2V5IG9mIGxlZnQgcm91 dGUgY2FuJ3QgYmUgbWF0Y2hlZC4gDQogIGFmdGVyIHNvbWUgcGFja2V0cyAsIGkgcmVjb3ZlciB0 aGUgY29ycmVjdCBtYXVuYWwga2V5IGluIHJpZ2h0IHJvdXRlICwgYnV0IHRoZSBsZWZ0IHJvdXRl IGNhbid0IHJlY2VpdmUgZW5jcnlwdCBpY21wIHJlcGx5IHRyYWZmaWMgZnJvbSByaWdodCByb3V0 ZSBzdWNjZXNzZnVsbHkgDQogIGkgZmluZCB0aGUgbGVmdCByb3V0ZSBzZW5kIGVzcCBwYWNrZXQg d2l0aCBsYXJnZSBzZXFudW1iZXIgLCBhbmQgcmlnaHQgcm91dGUgcmVwbHkgZXNwIHBhY2tlc3Qg d2l0aCBtaW4gc2VxbnVtYmVyICxiZWNhdXNlIHRoZSByaWdodCByb3V0ZSBtYWtlIGEgbmV3IGlw c2VjIHNhICwgdGh1cyB0aGUgbGVmdCByb3V0ZSByZWNlaXZlIHRoZSBlc3AgcGFrY2V0IHdpdGgg bWluLXNlcW51bWJlciBmcm9tIHJpZ2h0IHJvdXRlIA0KICBiZWNhdXNlIGl0IGlzIG1hbnVhbCBr ZXkgLCB0aGUgbGVmdCByb3V0ZSBjYW4ndCBrbm93IHRoYXQgdGhlIHJpZ2h0IHJvdXRlIGhhdmUg Y2hhbmdlZCBpcHNlYyBzYSAsIHRoZSBsZWZ0IGtlZXAgdGhlIGlwc2VjIHNhICwgYW5kIHRoZSBz ZXEgbnVtYmVyIHdpbmRvdyBpcyBzbyBsYXJnZSB0aGF0IGNhbid0IG1hdGNoIHRoZSBlc3Agc2Vx IG51bWJlciBvZiByaWdodCByb3V0ZSwgc28gbGVmdCByb3V0ZSB3aWxsIGRyb3BwZWQgdGhlIGVz cCBwYWNrdGVzIC4gDQogIHdobyBjYW4gdGVsbCBtZSBob3cgc29sdmUgdGhpcyBwcm9ibGVtID8N CiAgdGhhbmtzISENCg0KDQoNCg0KICBCZXN0IHJlZ2FyZHMNCg0KDQoNCkVyaWMNCg== ------=_NextPart_000_0011_01C5198D.D0B20D20 Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9uYWwv L0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PWdiMjMxMiI+DQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4w MC4yOTAwLjI2MDQiIG5hbWU9R0VORVJBVE9SPg0KPFNUWUxFPjwvU1RZTEU+DQo8L0hFQUQ+DQo8 Qk9EWSBiZ0NvbG9yPSNmZmZmZmY+DQo8RElWPjxGT05UIHNpemU9Mj5oaTxCUj4mbmJzcDsgaSBo YXZlIGEgcXVlc3Rpb24gYWJvdXQgbWFudWFsIGtleSA8QlI+Jm5ic3A7IGkgDQpoYXZlIHR3byBy b3V0ZSBieSBvd24gZGV2ZWxvcCwgaSBjYW4gZXN0YWJsaXNoIHRoZSB2cG4gdHVubmVsIGJ5IHVz ZSBtYW51YWwga2V5IA0KLiBhbmQgdGVzdCBpY21wIHRyYWZmaWMgZnJvbSBsZWZ0IHJvdXRlIHRv IHJpZ2h0IHJvdXRlICwgaXQgaXMgb2sgLjxCUj4mbmJzcDsgDQphbmQgdGhlbiAsIHRoZSBsZWZ0 IHJvdXRlIGNvbnRpbnVlIHNlbmQgZW5jcnlwdCBpY21wIHRyYWZmaWMgdG8gcmlnaHQsIGFuZCAN CmNoYW5nZSB0aGUgbWFudWFsIGtleSBvZiByaWdodCByb3V0ZSAsbm93ICwgdGhlIHJpZ2h0IHJv dXRlIGRyb3BwZWQgZW5jcnlwdCBpY21wIA0KdHJhZmZpYyAsIGJlYWNhdXNlIHRoZSBtYW51YWwg a2V5IG9mIGxlZnQgcm91dGUgY2FuJ3QgYmUgbWF0Y2hlZC4gPEJSPiZuYnNwOyANCmFmdGVyIHNv bWUgcGFja2V0cyAsIGkgcmVjb3ZlciB0aGUgY29ycmVjdCBtYXVuYWwga2V5IGluIHJpZ2h0IHJv dXRlICwgYnV0IHRoZSANCmxlZnQgcm91dGUgY2FuJ3QgcmVjZWl2ZSBlbmNyeXB0IGljbXAgcmVw bHkgdHJhZmZpYyBmcm9tIHJpZ2h0IHJvdXRlIA0Kc3VjY2Vzc2Z1bGx5IDxCUj4mbmJzcDsgaSBm aW5kIHRoZSBsZWZ0IHJvdXRlIHNlbmQgZXNwIHBhY2tldCB3aXRoIGxhcmdlIA0Kc2VxbnVtYmVy ICwgYW5kIHJpZ2h0IHJvdXRlIHJlcGx5IGVzcCBwYWNrZXN0IHdpdGggbWluIHNlcW51bWJlciAs YmVjYXVzZSB0aGUgDQpyaWdodCByb3V0ZSBtYWtlIGEgbmV3IGlwc2VjIHNhICwgdGh1cyB0aGUg bGVmdCByb3V0ZSByZWNlaXZlIHRoZSBlc3AgcGFrY2V0IA0Kd2l0aCBtaW4tc2VxbnVtYmVyIGZy b20gcmlnaHQgcm91dGUgPEJSPiZuYnNwOyBiZWNhdXNlIGl0IGlzIG1hbnVhbCBrZXkgLCB0aGUg DQpsZWZ0IHJvdXRlIGNhbid0IGtub3cgdGhhdCB0aGUgcmlnaHQgcm91dGUgaGF2ZSBjaGFuZ2Vk IGlwc2VjIHNhICwgdGhlIGxlZnQga2VlcCANCnRoZSBpcHNlYyBzYSAsIGFuZCB0aGUgc2VxIG51 bWJlciB3aW5kb3cgaXMgc28gbGFyZ2UgdGhhdCBjYW4ndCBtYXRjaCB0aGUgZXNwIA0Kc2VxIG51 bWJlciBvZiByaWdodCByb3V0ZSwgc28gbGVmdCByb3V0ZSB3aWxsIGRyb3BwZWQgdGhlIGVzcCBw YWNrdGVzIC4gDQo8QlI+Jm5ic3A7IHdobyBjYW4gdGVsbCBtZSBob3cgc29sdmUgdGhpcyBwcm9i bGVtID88QlI+Jm5ic3A7IA0KdGhhbmtzISE8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9E SVY+DQo8RElWPjxGT05UIHNpemU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNp emU9Mj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIHNpemU9Mj4mbmJzcDsgQmVzdCBy ZWdhcmRzPC9GT05UPjwvRElWPg0KPERJVj4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0y PjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJ Vj4NCjxESVY+PEZPTlQgc2l6ZT0yPkVyaWM8L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIHNpemU9 Mj48L0ZPTlQ+PEZPTlQgc2l6ZT0yPjwvRk9OVD4mbmJzcDs8L0RJVj48L0JPRFk+PC9IVE1MPg0K ------=_NextPart_000_0011_01C5198D.D0B20D20-- --===============0322835994== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0322835994==-- From ipsec-bounces@ietf.org Thu Feb 24 00:54:42 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA20867 for ; Thu, 24 Feb 2005 00:54:42 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D48LZ-0002xP-JV; Wed, 23 Feb 2005 21:03:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D48LX-0002wC-Ig for ipsec@megatron.ietf.org; Wed, 23 Feb 2005 21:03:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA25114 for ; Wed, 23 Feb 2005 21:03:17 -0500 (EST) Received: from brmea-mail-3.sun.com ([192.18.98.34]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D48iJ-0004pM-Oq for ipsec@ietf.org; Wed, 23 Feb 2005 21:26:54 -0500 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j1O23Bhl004447; Wed, 23 Feb 2005 19:03:11 -0700 (MST) Received: from thunk (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j1O23AQp014054; Wed, 23 Feb 2005 21:03:10 -0500 (EST) Received: from thunk.east.sun.com (localhost [127.0.0.1]) by thunk (8.13.3+Sun/8.13.3) with ESMTP id j1O23AeU028294; Wed, 23 Feb 2005 21:03:10 -0500 (EST) Received: (from sommerfeld@localhost) by thunk.east.sun.com (8.13.3+Sun/8.13.3/Submit) id j1O23AMd028293; Wed, 23 Feb 2005 21:03:10 -0500 (EST) X-Authentication-Warning: thunk.east.sun.com: sommerfeld set sender to sommerfeld@sun.com using -f Subject: Re: [Ipsec] More of ESN From: Bill Sommerfeld To: Markku Savela In-Reply-To: <200502220839.j1M8dvU3000326@burp.tkv.asdf.org> References: <200502220839.j1M8dvU3000326@burp.tkv.asdf.org> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit Message-Id: <1109210589.25366.227.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.325 Date: Wed, 23 Feb 2005 21:03:10 -0500 X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit On Tue, 2005-02-22 at 03:39, Markku Savela wrote: > *IF* an attacker can create a packet with sequence number that is > below the window and which passes the authentication check with the > next higher sequence space, then attacker has practically shut down > the connection (because all subsequent real packets will have > "incorrect" high ESN part). > > Because high ESN is mostly 0, all that is needed is to be able to > generate a single bit change that passes the authentication algorithm. if you have that sort of attack capability, you could most likely be able to tweak other bits within the packet payload, which if anything is a far more serious attack. the correct response to a real attack of that form would be to retire the auth algorithm... - Bill _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Feb 24 01:08:57 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA25602 for ; Thu, 24 Feb 2005 01:08:57 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D48hI-0003hM-2n; Wed, 23 Feb 2005 21:25:48 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D48hF-0003g8-HI for ipsec@megatron.ietf.org; Wed, 23 Feb 2005 21:25:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA04261 for ; Wed, 23 Feb 2005 21:25:43 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4943-0007Rf-RF for ipsec@ietf.org; Wed, 23 Feb 2005 21:49:20 -0500 Received: from [202.13.76.80] (ramblo.bbn.com [128.33.0.51]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j1O2PQkJ006483; Wed, 23 Feb 2005 21:25:27 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <200502220839.j1M8dvU3000326@burp.tkv.asdf.org> References: <200502220839.j1M8dvU3000326@burp.tkv.asdf.org> Date: Wed, 23 Feb 2005 21:20:54 -0500 To: Markku Savela From: Stephen Kent Subject: Re: [Ipsec] More of ESN Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 10:39 AM +0200 2/22/05, Markku Savela wrote: >One attack does occur to me... > >*IF* an attacker can create a packet with sequence number that is >below the window and which passes the authentication check with the >next higher sequence space, then attacker has practically shut down >the connection (because all subsequent real packets will have >"incorrect" high ESN part). > >Because high ESN is mostly 0, all that is needed is to be able to >generate a single bit change that passes the authentication algorithm. > >I'm no expert on hashes and HMAC, so I have no idea how easy or >difficult it would be. > HMAC should detect such changes very reliably. It is very sensitive to a one-bit change anywhere in the covered data. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Feb 24 01:33:37 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA04969 for ; Thu, 24 Feb 2005 01:33:37 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4CMF-00009X-SZ; Thu, 24 Feb 2005 01:20:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4CMC-00008N-Mo for ipsec@megatron.ietf.org; Thu, 24 Feb 2005 01:20:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA29394 for ; Thu, 24 Feb 2005 01:20:15 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.196]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Cj2-0007QC-00 for ipsec@ietf.org; Thu, 24 Feb 2005 01:43:53 -0500 Received: by wproxy.gmail.com with SMTP id 71so99637wri for ; Wed, 23 Feb 2005 22:20:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:references; b=G4NgU9soMha9C1Hk+uVV181osRa2jvA976T49gE6fqV7tPWjfOzXq9J5skzrQGet+x0j4LIDyPZrlTQeb+SBob7n6GlA8xRMzFyUKeN2Zecgtj5QZks5uJnB3rJ6fWuugKNYazUmyUK/0uY+Vm6iVlP8ro1UliLCt3zS8NNU4T8= Received: by 10.54.32.23 with SMTP id f23mr3062wrf; Wed, 23 Feb 2005 22:20:02 -0800 (PST) Received: by 10.54.40.21 with HTTP; Wed, 23 Feb 2005 22:20:02 -0800 (PST) Message-ID: <41ae448405022322204933e8c5@mail.gmail.com> Date: Thu, 24 Feb 2005 11:50:02 +0530 From: Kausty To: Awadhesh Paswan Subject: Re: [Ipsec] ipsec implementation in linux kernel 2.6 In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 50a516d93fd399dc60588708fd9a3002 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: Kausty List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit hi On Thu, 24 Feb 2005 11:13:45 +0530, Awadhesh Paswan wrote: > > Hi, > > I am going through the native implementation of IPsec with Linux kernel > 2.6. Can some body please send me any document or reference link for the > same? > for config look into http://www.ipsec-howto.org/ for overview of internals you could look into usagi docs. but its best to go through the code > > > > Regards > Awadhesh Kumar Paswan > Larsen &Toubro Infotech Limited > Communications & Embedded System > #2, Church Street, Bangalore-560001 > Tel : + 91-80-25323734/5/6, Ext-124 > > > > ========================================= > ( ) L&T Infotech General Business > ( ) L&T Infotech Internal Use > ( ) L&T Infotech Confidential > (+ ) L&T Infotech Proprietary > ========================================= > ______________________________________________________________________ > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Feb 24 01:42:06 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA07651 for ; Thu, 24 Feb 2005 01:42:06 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Bms-0005J6-Si; Thu, 24 Feb 2005 00:43:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4Bmq-0005Ik-Ba for ipsec@megatron.ietf.org; Thu, 24 Feb 2005 00:43:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA17167 for ; Thu, 24 Feb 2005 00:43:39 -0500 (EST) Received: from mail18.messagelabs.com ([202.153.127.245]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D4C9d-0003ij-US for ipsec@ietf.org; Thu, 24 Feb 2005 01:07:19 -0500 X-VirusChecked: Checked X-Env-Sender: Awadhesh.Paswan@lntinfotech.com X-Msg-Ref: server-13.tower-18.messagelabs.com!1109223807!10712773!2 X-StarScan-Version: 5.4.11; banners=lntinfotech.com,-,- X-Originating-IP: [203.101.96.4] Received: (qmail 4651 invoked from network); 24 Feb 2005 05:43:27 -0000 Received: from bangaloresmtp.lntinfotech.com (203.101.96.4) by server-13.tower-18.messagelabs.com with SMTP; 24 Feb 2005 05:43:27 -0000 Received: from Bangalore.lntinfotech.com ([172.29.5.3]) by bangaloresmtp.lntinfotech.com (Lotus Domino Release 5.0.12) with ESMTP id 2005022411140664:22985 ; Thu, 24 Feb 2005 11:14:06 +0530 To: ipsec@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5 September 26, 2003 Message-ID: From: "Awadhesh Paswan" Date: Thu, 24 Feb 2005 11:13:45 +0530 X-MIMETrack: Serialize by Router on BANGALORE/LNTINFOTECH(Release 5.0.12 |February 13, 2003) at 02/24/2005 11:13:51 AM, Serialize complete at 02/24/2005 11:13:51 AM, Itemize by SMTP Server on BANGALORESMTP/LNTINFOTECH(Release 5.0.12 |February 13, 2003) at 02/24/2005 11:14:07 AM, Serialize by Router on BANGALORESMTP/LNTINFOTECH(Release 5.0.12 |February 13, 2003) at 02/24/2005 11:14:08 AM, Serialize complete at 02/24/2005 11:14:08 AM X-Spam-Score: 0.0 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da Subject: [Ipsec] ipsec implementation in linux kernel 2.6 X-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="===============0451787860==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multipart message in MIME format. --===============0451787860== Content-Type: multipart/alternative; boundary="=_alternative 001F78B265256FB2_=" This is a multipart message in MIME format. --=_alternative 001F78B265256FB2_= Content-Type: text/plain; charset="US-ASCII" Hi, I am going through the native implementation of IPsec with Linux kernel 2.6. Can some body please send me any document or reference link for the same? Regards Awadhesh Kumar Paswan Larsen &Toubro Infotech Limited Communications & Embedded System #2, Church Street, Bangalore-560001 Tel : + 91-80-25323734/5/6, Ext-124 ========================================= ( ) L&T Infotech General Business ( ) L&T Infotech Internal Use ( ) L&T Infotech Confidential (+ ) L&T Infotech Proprietary ========================================= ______________________________________________________________________ --=_alternative 001F78B265256FB2_= Content-Type: text/html; charset="US-ASCII"
Hi,

     I am going through the native implementation of IPsec with Linux kernel 2.6. Can some body please send  me any document or reference link for the same?




Regards
Awadhesh Kumar Paswan
Larsen &Toubro Infotech Limited
Communications & Embedded System
#2, Church Street, Bangalore-560001
Tel : + 91-80-25323734/5/6, Ext-124



=========================================
( ) L&T Infotech General Business
( ) L&T Infotech Internal Use
( )  L&T Infotech Confidential
(+ )  L&T Infotech Proprietary
=========================================
______________________________________________________________________
--=_alternative 001F78B265256FB2_=-- --===============0451787860== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-Transfer-Encoding: 7bit _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0451787860==-- From ipsec-bounces@ietf.org Thu Feb 24 07:39:03 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11771 for ; Thu, 24 Feb 2005 07:39:03 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4IF4-0002dD-AI; Thu, 24 Feb 2005 07:37:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4IF2-0002bD-8H for ipsec@megatron.ietf.org; Thu, 24 Feb 2005 07:37:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11538 for ; Thu, 24 Feb 2005 07:37:14 -0500 (EST) Received: from mx2.grc.nasa.gov ([128.156.11.69]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D4Ibs-000440-CK for ipsec@ietf.org; Thu, 24 Feb 2005 08:00:55 -0500 Received: from lombok-fi.grc.nasa.gov (seraph1.grc.nasa.gov [128.156.10.10]) by mx2.grc.nasa.gov (Postfix) with ESMTP id C1BD1C3D5 for ; Thu, 24 Feb 2005 07:37:02 -0500 (EST) Received: from apataki.grc.nasa.gov (apataki.grc.nasa.gov [139.88.112.35]) by lombok-fi.grc.nasa.gov (NASA GRC TCPD 8.12.10/8.12.10) with ESMTP id j1OCb2Rs012468 for ; Thu, 24 Feb 2005 07:37:02 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j1OCb2NL002933 for ; Thu, 24 Feb 2005 07:37:02 -0500 (EST) Received: from apataki.grc.nasa.gov ([127.0.0.1])by localhost (apataki.grc.n asa.gov [127.0.0.1]) (amavisd-new, port 10024)with ESMTP id 27663-17 for ;Thu, 24 Feb 2005 07:37:01 -0500 (EST) Received: from webmail.grc.nasa.gov (ragnarok.grc.nasa.gov [128.156.253.19]) by apataki.grc.nasa.gov (NASA GRC TCPD 8.13.1/8.13.1) with ESMTP id j1OCb0I v002915for ; Thu, 24 Feb 2005 07:37:00 -0500 (EST) Received: by webmail.grc.nasa.gov (Postfix, from userid 501)id 1B6B333800F; Thu, 24 Feb 2005 07:37:00 -0500 (EST) Received: from grc.nasa.gov (oh-northolmstead1-16-134.clvhoh.adelphia.net [6 8.71.111.134])by webmail.grc.nasa.gov (Postfix) with ESMTP id 83E5C33800Dfo r ; Thu, 24 Feb 2005 07:36:59 -0500 (EST) Message-ID: <421DCA63.8030806@grc.nasa.gov> Date: Thu, 24 Feb 2005 07:36:51 -0500 From: ivancic User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-imss-version: 2.19 X-imss-result: Passed X-imss-approveListMatch: *@*.nasa.gov X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Subject: [Ipsec] Request for Comment on IPv6-based Global Air Space communicationnet work requirements X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit NASA has formulated a list of requirements to ensure global interoperability and deployment. NASA is seeking comments from various industries, academia and government agencies throughout the world regarding these salient requirements. Comments are being sought from those directly involved in aeronautics, as well as telecommunication, communication, computer and information assurance providers as we believe those outside the traditional aeronautics community have expertise and insight that is directly applicable to network centric operations. Application of commercial off the shelf technologies and techniques will, hopefully, enable network centric operation to be economically and technically realizable over the Global Airspace System. Note, there are some fundamental security requirements presented regarding IPSec and use of security mechanisms over a Global Network. Any input and constructive criticism by the Security community regarding these proposed requirements is welcome. A user friendly URL for this request can be found here: http://roland.grc.nasa.gov/~ivancic/RFI/rfi.html The official announcement is here: http://prod.nais.nasa.gov/cgi-bin/eps/synopsis.cgi?acqid=114192 Please feel free to forward this request to whomever you my feel would benefit -- ****************************** William D. Ivancic Phone 216-433-3494 Fax 216-433-8705 Lab 216-433-2620 Mobile 440-503-4892 Yahoo ID: ivancic http://roland.grc.nasa.gov/~ivancic _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Feb 25 09:16:19 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18497 for ; Fri, 25 Feb 2005 09:16:19 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4gDK-0007Xk-CM; Fri, 25 Feb 2005 09:13:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D4gDI-0007XX-US for ipsec@megatron.ietf.org; Fri, 25 Feb 2005 09:13:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18128 for ; Fri, 25 Feb 2005 09:13:03 -0500 (EST) Received: from [203.199.183.83] (helo=eit.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1D4gDO-0001Zt-9U for ipsec@ietf.org; Fri, 25 Feb 2005 09:13:14 -0500 Received: (qmail 28436 invoked from network); 25 Feb 2005 14:15:35 -0000 Received: from unknown (HELO embeddedinfotech.com) (192.168.1.91) by 192.168.1.16 with SMTP; 25 Feb 2005 14:15:35 -0000 Message-ID: <421F310B.8090403@embeddedinfotech.com> Date: Fri, 25 Feb 2005 19:37:07 +0530 From: jeet User-Agent: Mozilla Thunderbird 0.5 (Windows/20040207) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: 7bit Subject: [Ipsec] how to calculate authentication payload in case of digital signature in IKEv2. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: 7bit Hi All, Can anybody plz tell me, how to calculate authentication payload in case of digital signature in IKEv2.. I am calculating the signature with following procedure. 1. For the responder, the buffer to be signed is calculated as buffer = (complete message buffer | Ni | prf(SK_pr,IDr') ) where Ni is initiator Nonce. and IDr' is the responder's ID payload excluding the fixed header 2. Get the signed buffer by calling openssl function. RSA_private_encrypt(bufferLength, buffer, signed_output, privateKey, padding); where bufferLength is the length of the buffer to be signed. buffer is the buffer to be signed. signed_output is the buffer to get the signed data. privateKey is the RSA private key. padding used is RSA_PKCS1_PADDING. Routine RSA_private_encrypt() is giving error. Error string is as follows: eay_rsa_sign(): error:0406C06E:rsa routines:RSA_padding_add_PKCS1_type_1:data too large for key size Plz see if my procedure is wrong or I need to use some other openssl routine to calculate the sign. Thanks in advance. Jatinder _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Feb 28 07:52:14 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15326 for ; Mon, 28 Feb 2005 07:52:14 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5kKE-0006RA-KM; Mon, 28 Feb 2005 07:48:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5kKD-0006R5-9T for ipsec@megatron.ietf.org; Mon, 28 Feb 2005 07:48:37 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA15142 for ; Mon, 28 Feb 2005 07:48:36 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-x1.nokia.com ([131.228.20.21]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5kKw-00063Y-FV for ipsec@ietf.org; Mon, 28 Feb 2005 07:49:23 -0500 Received: from esdks002.ntc.nokia.com (esdks002.ntc.nokia.com [172.21.138.121]) by mgw-x1.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1SCmUZ27998; Mon, 28 Feb 2005 14:48:32 +0200 (EET) X-Scanned: Mon, 28 Feb 2005 14:47:56 +0200 Nokia Message Protector V1.3.34 2004121512 - RELEASE Received: (from root@localhost) by esdks002.ntc.nokia.com (8.12.9/8.12.9) id j1SCluU4021061; Mon, 28 Feb 2005 14:47:56 +0200 Received: from mgw-int2.ntc.nokia.com (172.21.143.97) by esdks002.ntc.nokia.com 00QMzF0s; Mon, 28 Feb 2005 14:47:56 EET Received: from esebh003.NOE.Nokia.com (esebh003.ntc.nokia.com [172.21.138.82]) by mgw-int2.ntc.nokia.com (Switch-2.2.8/Switch-2.2.8) with ESMTP id j1SCltU21797; Mon, 28 Feb 2005 14:47:55 +0200 (EET) Received: from esebe009.NOE.Nokia.com ([172.21.138.41]) by esebh003.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 28 Feb 2005 14:47:54 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebe009.NOE.Nokia.com with Microsoft SMTPSVC(5.0.2195.6881); Mon, 28 Feb 2005 14:47:54 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] how to calculate authentication payload in case of digital signature in IKEv2. Date: Mon, 28 Feb 2005 14:47:53 +0200 Message-ID: Thread-Topic: [Ipsec] how to calculate authentication payload in case of digital signature in IKEv2. thread-index: AcUbS+9oxspuGyeJSBSaqpcGB0EHaQCRdTqw To: , X-OriginalArrivalTime: 28 Feb 2005 12:47:54.0552 (UTC) FILETIME=[B8AAB380:01C51D93] X-Spam-Score: 0.3 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Content-Transfer-Encoding: quoted-printable X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Content-Transfer-Encoding: quoted-printable Hi, IKEv2 uses RSA signatures, not RSA encryption, so=20 use OpenSSL's RSA_sign() function instead.=20 See the documentation in openssl-*/doc/crypto/RSA_sign.pod for details (in particular, you have to calculate the SHA-1=20 of the buffer before calling RSA_sign). Best regards, Pasi > -----Original Message----- > From: jatinder@embeddedinfotech.com > Sent: Friday, February 25, 2005 4:07 PM > To: ipsec@ietf.org > Subject: [Ipsec] how to calculate authentication payload in case of > digital signature in IKEv2. >=20 >=20 > Hi All, >=20 > Can anybody plz tell me, how to calculate authentication > payload in case of digital signature in IKEv2.. I am > calculating the signature with following procedure. >=20 > 1. For the responder, the buffer to be signed is calculated as > buffer =3D (complete message buffer | Ni | prf(SK_pr,IDr') ) >=20 > where Ni is initiator Nonce. > and IDr' is the responder's ID payload excluding the fixed header >=20 > 2. Get the signed buffer by calling openssl function. >=20 > RSA_private_encrypt(bufferLength, buffer, > signed_output, privateKey, padding); >=20 > where bufferLength is the length of the buffer to be signed. > buffer is the buffer to be signed. > signed_output is the buffer to get the signed data. > privateKey is the RSA private key. > padding used is RSA_PKCS1_PADDING. >=20 > Routine RSA_private_encrypt() is giving error. > Error string is as follows: > eay_rsa_sign(): error:0406C06E:rsa=20 > routines:RSA_padding_add_PKCS1_type_1:data too large for key size >=20 > Plz see if my procedure is wrong or I need to use some other=20 > openssl routine to calculate the sign. >=20 > Thanks in advance. > Jatinder _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Feb 28 16:27:39 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09902 for ; Mon, 28 Feb 2005 16:27:39 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5sP1-0001rY-I4; Mon, 28 Feb 2005 16:26:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5sOy-0001qy-2s for ipsec@megatron.ietf.org; Mon, 28 Feb 2005 16:26:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA09671 for ; Mon, 28 Feb 2005 16:26:00 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5sPk-0001Ep-TU for ipsec@ietf.org; Mon, 28 Feb 2005 16:26:53 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j1SLPNkJ016911; Mon, 28 Feb 2005 16:25:23 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: <200502220818.j1M8IdtO032737@burp.tkv.asdf.org> References: <200502220818.j1M8IdtO032737@burp.tkv.asdf.org> Date: Mon, 28 Feb 2005 16:10:06 -0500 To: Markku Savela From: Stephen Kent Subject: Re: [Ipsec] About extended sequence numbers Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: 21c69d3cfc2dd19218717dbe1d974352 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 10:18 AM +0200 2/22/05, Markku Savela wrote: >Is my understanding correct in following: > >With old 32 bit sequence number logic, if you got and "old" packet >below replay window, it was dropped without running the authentication >algorithm. right. >With new 64 bit sequence number logic, you don't know if the packet is >old, until you have tried to authenticate it with the new higher >"sequence subspace number". well, you can do it in two phases. First, look to see if the sequence number looks "good" based on only the low order 32 bits. if so, then proceed to authentication. this is just the way non-ESN processing proceeds. The added complexity arises when the window spans two sequence number subspaces, i.e., two 2**32 bit chunks. The appendix in AH and ESP (it's the same text in both) provides a discussion on how to deal with this, which works easily so long as there is no ambiguity caused by a very extensive packet sequence loss. Specifically, if you miss 2**32 packets in a row on one SA, then we have no quick way to detect and recover, a problem we discussed 2 about years ago. > > --- > >As far as I see, this is *not* new attack potential, as sequece >numbers could always be adjusted so that algorithm must be run. > >It is just that a connection using ESN behaves a little bit >differently from not using ESN. Just a curious observation, probably >nothing to be concerned with? Here is the note I plan to add to AH (section 3.3.2) and ESP (section 3.3.3) Note: If a receiver chooses to not enable anti-replay for an SA, then the receiver SHOULD NOT negotiate ESN in an SA management protocol. Use of ESN creates a need for the receiver to manage the anti-replay window (in order to determine the correct value for the high order bits of the ESN, which are employed in the ICV computation), which is generally contrary to the notion of disabling anti-replay for an SA. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Feb 28 18:46:41 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22344 for ; Mon, 28 Feb 2005 18:46:40 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5uYZ-0006He-Sm; Mon, 28 Feb 2005 18:44:07 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5uYX-0006HZ-W1 for ipsec@megatron.ietf.org; Mon, 28 Feb 2005 18:44:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA22154 for ; Mon, 28 Feb 2005 18:44:03 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5uZL-000447-UK for ipsec@ietf.org; Mon, 28 Feb 2005 18:44:58 -0500 Received: from [128.89.89.75] (dhcp89-089-075.bbn.com [128.89.89.75]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j1SNhqkJ023273 for ; Mon, 28 Feb 2005 18:43:52 -0500 (EST) Mime-Version: 1.0 Message-Id: Date: Mon, 28 Feb 2005 18:43:47 -0500 To: ipsec@ietf.org From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Subject: [Ipsec] SPD & IKE v2 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Folks, Thanks to a simple but complete example by Tero (and an equally valid although not so complete example by Markku), I agree that my second set of processing descriptions, the first to deal with IKE v2, was wrong. Unless one uses a decorrelated SPD, one cannot perform the required checks on inbound traffic using just SAD data. Mike also noted this in a more general comment, w/o examples. Tero suggested that the proliferation of SAs that motivated 2401bis to call for sending the original, correlated SPD entry will arise only when there are two or more (correlated) SPD entries in which the protocol field is non-trivial and overlaps. I was thinking about the general case re this problem, but I believe Tero is correct here. So, my general comment was correct, but Tero's suggestion is that maybe, in practice, this will not be a big deal. Mike Roe suggested that a desire to bypass ICMP traffic might trigger a lot of decorrelated entries. I would expect that if one generally wants to protect traffic for a given S/D address range via one SA, then one may send the ICMP traffic over that SA as well. So, your actual decorrelation experience may vary ... My last suggestion was that one could choose to send the set of linked, decorrelated entries as IKE proposals, which I thought would ensure that we don't create more SAs than intended. Tero agrees that this is a reasonable strategy, Mike indicated that this is what he envisioned as well. However, Mike points out that it might entail a lot of proposals, and that IKE would be unable to represent all of them in creating an SA. I have revised the 2401bis text to better explain this issue, making it a local choice as to whether to send a correlated or decorrelated SPD entry in IKE v2, with some discussion of the motivations and concerns in both cases. This brings me to the issue Tero raised in this discussion. Tero, I think you suggested that there is a fundamental mismatch between what the SPD allows to be expressed and what IKE v2 can negotiate. Specifically, I think you indicated that the mismatch arises because IKE semantics call for a "mix and match" approach to viewing TSi/TSr payloads. I looked at section 2.9 in IKE v2 and I don't see where it suggests this. For example, the text describes how to pass triggering packet header data as the FIRST selector set data in TSi and TSr payloads, implying that the order of elements in these payloads is important, and that one is expected to view them as pairs, matching the corresponding S/D address and port fields. So, I have to admit that I am confused by your comment. If I send a series of pairs of TSi/TSr payloads, I would interpret this to represent pairs of S/D data, with a common protocol, so that each matched pair represents one selector set from an SPD entry, if the entry has more than one selector set in it. Can you cite the parts of IKEv2 that suggest the "mix and match" approach that you indicated? Such semantics make no sense in the access control context that the SPD represents. Also, I'd like to think that IKE should be trying to negotiate what the SPD specifies, to minimize the likelihood that SAs are established that later will not carry the intended traffic. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Feb 28 19:29:59 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25888 for ; Mon, 28 Feb 2005 19:29:59 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5vEx-0004tG-DI; Mon, 28 Feb 2005 19:27:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5vEv-0004tB-DI for ipsec@megatron.ietf.org; Mon, 28 Feb 2005 19:27:53 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25741 for ; Mon, 28 Feb 2005 19:27:50 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5vFk-0004wW-L9 for ipsec@ietf.org; Mon, 28 Feb 2005 19:28:46 -0500 Received: from [10.20.30.249] (dsl2-63-249-109-245.cruzio.com [63.249.109.245]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j210Rj4j020985; Mon, 28 Feb 2005 16:27:45 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 28 Feb 2005 16:25:57 -0800 To: IPsec WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Cc: "Theodore Y. Ts'o" , Russ Housley , Barbara Fraser Subject: [Ipsec] Technical change needed to IKEv2 before publication X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Greetings again. During the IKEv2 bakeoff last week, a technical mistake was found in the current IKEv2 Internet Draft. This is not something that simply needs to be clarified; it needs an actual fix to the document because, without it, interoperability is literally impossible. (FWIW, the bakeoff also led to about 25 clarifications that will be sent to the list soon. These are all clarifications to areas that one or more bakeoff participant felt was unclear. They are only clarifications, not technical changes.) After discussing this briefly with Russ Housley, our AD, we decided to poll the Working Group on how to fix the problem. If we can reach consensus soon (such as within a week from today), it may not delay the publication of the IKEv2 RFC. Russ will want to hear from the WG co-chairs as to our consensus. ------------------- Issue: If a receiver doesn't support ESN, they require the sender to send an ESN transform Some systems know that they don't support ESN, and therefore they require the other side to actively say they won't expect it. The only way for the other side to do so is for it to send a Transform Type 5 with a value of 0. However, there is no way for the responder to say that to the initiator, so interoperability is not possible. This is a technical error in the IKEv2 spec. There are three simple possible ways to change this: SUGGESTION A: The last sentence of 3.3.2 says: If Transform Type 5 is not included in a proposal, use of Extended Sequence Numbers is assumed. Replace this with: If Transform Type 5 is not included in a proposal, it is assumed that the sending party does not support Extended Sequence Numbers. SUGGESTION B: Create a new response notification that says "I can't do ESN, start again and include a 'no ESN' transform." SUGGESTION C: Change the places that says Transform Type 5 is optional to say it is mandatory. ------------------- The people I spoke with at the bakeoff agreed that suggestions A and C would both work and be easy to implement. Personally, I think suggestion C is better because having defaults tends to lead to interoperability issues down the line when new implementers don't read all the defaults. It's only a few extra bytes per proposal to always be explicit. Please respond on the list soon so that the WG co-chairs can advise the ADs of the WG consensus on this and prevent a delay in the document's publication. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Feb 28 21:39:25 2005 Received: from megatron.ietf.org (megatron.ietf.org [132.151.6.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05592 for ; Mon, 28 Feb 2005 21:39:25 -0500 (EST) Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5xFE-0005xM-6W; Mon, 28 Feb 2005 21:36:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1D5xFB-0005xD-Rv for ipsec@megatron.ietf.org; Mon, 28 Feb 2005 21:36:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05336 for ; Mon, 28 Feb 2005 21:36:15 -0500 (EST) From: kallol_biswas@agilent.com Received: from msgbas9x.lvld.agilent.com ([192.25.144.41]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1D5xG3-0007HO-5p for ipsec@ietf.org; Mon, 28 Feb 2005 21:37:11 -0500 Received: from relcos2.cos.agilent.com (relcos2.cos.agilent.com [130.29.152.237]) by msgbas9x.lvld.agilent.com (Postfix) with ESMTP id BFA2F1D71 for ; Mon, 28 Feb 2005 19:36:07 -0700 (MST) Received: from wlvdvs01.lvld.agilent.com (wlvdvs01.lvld.agilent.com [148.5.6.4]) by relcos2.cos.agilent.com (Postfix) with ESMTP id A20DC4AC for ; Mon, 28 Feb 2005 19:36:07 -0700 (MST) Received: from wcosbh22.cos.agilent.com ([130.29.152.178]) by wlvdvs01.lvld.agilent.com with InterScan Messaging Security Suite; Mon, 28 Feb 2005 19:36:06 -0700 Received: from wcosmb02.cos.agilent.com ([130.29.152.96]) by wcosbh22.cos.agilent.com with Microsoft SMTPSVC(5.0.2195.6713); Mon, 28 Feb 2005 19:36:05 -0700 X-MimeOLE: Produced By Microsoft Exchange V6.0.6603.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 28 Feb 2005 19:36:05 -0700 Message-ID: Thread-Topic: [Ipsec] SPD & IKE v2 Thread-Index: AcUd7/GH9giMoJBhRKCqi6WQzZJJMwAFjS2Q To: , X-OriginalArrivalTime: 01 Mar 2005 02:36:05.0992 (UTC) FILETIME=[6B12B680:01C51E07] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8abaac9e10c826e8252866cbe6766464 Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] Simple IPSec 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 Content-Transfer-Encoding: quoted-printable Folks, I have just read a tutorial on IPSec, and have a few questions. = Hope they are not too trivial. I have downloaded the following five steps from a site on the internet. "How IPSec Works" 1) "Interesting traffic" initiates the IPSec process. Traffic is deemed = interesting when the IPSec security policy configured in the IPSec peers = starts the IKE process. 2) IKE phase 1. IKE authenticates IPSec peers and negotiates IKE SAs = during this phase, setting up a secure channel for negotiating IPSec SAs = in phase 2. 3) IKE phase 2. IKE negotiates IPSec SA parameters and sets up matching = IPSec SAs in the peers. 4) Data transfer. Data is transferred between IPSec peers based on the = IPSec parameters and keys stored in the SA database. 5) IPSec tunnel termination. IPSec SAs terminate through deletion or by = timing out. The question is how often step 2 & 3 take place? My understanding is = that only once for the first frame and then a SA remains valid till it = times out or deleted, right? Do we have any performance figure of a system with IPSec enabled? = Specially with iSCSI. Kallol _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec