From ipsec-bounces@ietf.org Fri Dec 02 01:50:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei4kC-0007Ks-8U; Fri, 02 Dec 2005 01:50:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei4kA-0007JA-IT for ipsec@megatron.ietf.org; Fri, 02 Dec 2005 01:50:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14800 for ; Fri, 2 Dec 2005 01:49:18 -0500 (EST) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=brahma.intotoind.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei54l-0002AI-99 for ipsec@ietf.org; Fri, 02 Dec 2005 02:11:25 -0500 Received: from Somesh.intoto.com (3mc201.intotoind.com [172.16.3.201]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id jB26njfO017590 for ; Fri, 2 Dec 2005 12:19:45 +0530 Message-Id: <6.1.2.0.0.20051202122807.025e6bf8@172.16.1.10> X-Sender: srparate@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 02 Dec 2005 12:29:11 +0530 To: ipsec@ietf.org From: Someshwar Parate Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Ipsec] IPSec VPN client on Linux X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Dear ALL, Can anybody provide me some information regarding any IPSec VPN client available on Linux. regards... -Somesh _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Dec 02 01:51:53 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei4lt-0008QQ-54; Fri, 02 Dec 2005 01:51:53 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ei4lr-0008Q8-9o for ipsec@megatron.ietf.org; Fri, 02 Dec 2005 01:51:51 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA14944 for ; Fri, 2 Dec 2005 01:51:03 -0500 (EST) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=brahma.intotoind.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ei56T-0002F2-7a for ipsec@ietf.org; Fri, 02 Dec 2005 02:13:10 -0500 Received: from Somesh.intoto.com (3mc201.intotoind.com [172.16.3.201]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id jB26piT1017961 for ; Fri, 2 Dec 2005 12:21:45 +0530 Message-Id: <6.1.2.0.0.20051202123036.025f1448@172.16.1.10> X-Sender: srparate@172.16.1.10 X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Fri, 02 Dec 2005 12:31:35 +0530 To: ipsec@ietf.org From: Someshwar Parate Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: d17f825e43c9aed4fd65b7edddddec89 Subject: [Ipsec] IPSec VPN Client on Linux X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Dear ALL, Can anybody provide me some information regarding any IPSec VPN client available on Linux. regards... -Somesh email: srparate@intoto.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Dec 02 12:49:55 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiF2h-0001Oj-6j; Fri, 02 Dec 2005 12:49:55 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiF2Z-0001I5-Cu for ipsec@megatron.ietf.org; Fri, 02 Dec 2005 12:49:50 -0500 Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA23776 for ; Fri, 2 Dec 2005 12:48:50 -0500 (EST) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1EiEwl-0003SX-In for ipsec@lists.ietf.org; Fri, 02 Dec 2005 18:43:47 +0100 Received: from desk.marajade.sandelman.ca ([205.150.200.247]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 02 Dec 2005 18:43:47 +0100 Received: from mcr by desk.marajade.sandelman.ca with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 02 Dec 2005 18:43:47 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: ipsec@ietf.org From: Michael Richardson Date: Fri, 02 Dec 2005 12:36:51 -0500 Lines: 52 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: desk.marajade.sandelman.ca User-Agent: Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, linux) Cancel-Lock: sha1:X68+NG1fZ6yp4Bzp46EYbu4UiQo= Subject: [Ipsec] Re: New draft on hash use in IKE and IPsec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Paul" == Paul Hoffman writes: Paul> I would greatly appreciate careful review of my assumptions both of Paul> where we use hash functions in our protocols and how they are used. I read it. Section 2. a) IKEv2 uses hashes for authentication of the payloads. It is HMAC, so not a problem, but we should say so. b) I think that I agree that the hash used in NAT-D is not susceptible. I'm not sure why. Reasons why it might not matter: i) it's under the protection of the IKE SA, so it can't be modified by someone in the middle. ii) assuming that someone could find another set of IPs/ports which hashed to the same value... what could they do? At most they can turn NAT-T on or off my modifying the hash. That could lead to a failure to negotiate properly (won't move to port 4500, or moves incorrectly), but see (i). iii) the hash is not being used to provide integrity check of a larger object, but rather to obsecure the object. Maybe someone can undo the hash to get the original values back. (The hash is bigger than the IPv4+port, but probably not bigger than the IPv6+port) c) you say that an attacker could create two public keys with the same hash value. You say that this doesn't matter because the attacker would have to have both private keys. I don't understand this statement. - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) iQEVAwUBQ5CGNoCLcPvd0N1lAQIsGgf8D/Oa9lqxbQdXXadmN5ztry9S0Y59FFMe mlam0n0xAINvVZyLAey4ilFGJ5XXh9IHlt4zYAjySdOpVXYGAnKo2DHPGvT1rk2w FC6DR/RRqY7rvlcFFaSnJ0nL0J8mCuFNYq02wYRxbCLu1VjHqiBpp5U7NgU31VXr swjIMRh8OK9dcLL1rV/8vflAg51S2W2jpKQqU3u31+CJ0jC4G8ulQa6zBHT6PHL0 Q4uYLH5st0GSf4LtjpG51oJRQ965NZIp3dW/OR663mIQt5aToDY81/ruITaJZhT5 DN50/JRzEARvfbsse0joNLtuqA1h9gH93LM5KUYbuSIXR4pupj0Kaw== =Axuy -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Dec 02 13:37:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiFmK-0000YX-Mj; Fri, 02 Dec 2005 13:37:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EiFmI-0000YP-H2 for ipsec@megatron.ietf.org; Fri, 02 Dec 2005 13:37:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA29118 for ; Fri, 2 Dec 2005 13:36:14 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EiG70-0001Z0-Ui for ipsec@ietf.org; Fri, 02 Dec 2005 13:58:28 -0500 Received: from [10.20.30.249] (dsl2-63-249-109-231.cruzio.com [63.249.109.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB2IarcS039572; Fri, 2 Dec 2005 10:36:54 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Fri, 2 Dec 2005 10:36:51 -0800 To: Michael Richardson , ipsec@ietf.org From: Paul Hoffman Subject: [Ipsec] Re: New draft on hash use in IKE and IPsec Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 12:36 PM -0500 12/2/05, Michael Richardson wrote: >Section 2. >a) IKEv2 uses hashes for authentication of the payloads. > It is HMAC, so not a problem, but we should say so. Got it. >b) I think that I agree that the hash used in NAT-D is not > susceptible. I'm not sure why. Reasons why it might not matter: > > i) it's under the protection of the IKE SA, so it can't be modified > by someone in the middle. That is it. >c) you say that an attacker could create two public keys with the same > hash value. You say that this doesn't matter because the attacker would > have to have both private keys. > I don't understand this statement. Is the following better? "This is not considered to be a useful attack in IKEv1 or IKEv2: the relying party views the attacker as the same entity because the identity is the same in both certificates." --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Dec 04 21:37:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ej6EW-0002yz-GO; Sun, 04 Dec 2005 21:37:40 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ej6EU-0002yu-Aa for ipsec@megatron.ietf.org; Sun, 04 Dec 2005 21:37:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA15495 for ; Sun, 4 Dec 2005 21:36:49 -0500 (EST) Received: from bay113-dav13.bay113.hotmail.com ([65.54.168.85] helo=hotmail.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ej6Zd-0005HG-TT for ipsec@ietf.org; Sun, 04 Dec 2005 21:59:33 -0500 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 4 Dec 2005 18:37:24 -0800 Message-ID: Received: from 132.205.19.164 by BAY113-DAV13.phx.gbl with DAV; Mon, 05 Dec 2005 02:37:24 +0000 X-Originating-IP: [132.205.19.164] X-Originating-Email: [isalekul@hotmail.com] X-Sender: isalekul@hotmail.com From: "Salekul Islam" To: Date: Sun, 4 Dec 2005 21:37:27 -0500 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-OriginalArrivalTime: 05 Dec 2005 02:37:24.0504 (UTC) FILETIME=[D31EF180:01C5F944] X-Spam-Score: 2.8 (++) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Cc: abuza_m@encs.concordia.ca Subject: [Ipsec] Ordering of Security Association in Transport Adjacency X-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="===============1013522185==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1013522185== Content-Type: multipart/alternative; boundary="----=_NextPart_000_0011_01C5F91A.EC29DE80" This is a multi-part message in MIME format. ------=_NextPart_000_0011_01C5F91A.EC29DE80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I have a simple question. I am sorry if it had been answered already. I = could not find it in the mailing list archive. The IPsec architecture has recommend two transport-mode SAs like this: [IP1][AH][ESP][upper] My question is why it has not recommended the other order also like = this: [IP1][ESP][AH][upper] Is there any cryptographical benefit or anything else? Thank you, Salekul ------=_NextPart_000_0011_01C5F91A.EC29DE80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi,
 
I have a simple question. I am sorry if it had been = answered=20 already. I could not find it in the mailing list archive.
 
The IPsec architecture has recommend two transport-mode SAs = like=20 this:
 
    [IP1][AH][ESP][upper]
My question is why it has not recommended the other order also like = this:
 
    [IP1][ESP][AH][upper]
 
Is there any cryptographical benefit or = anything=20 else?
 
Thank you,
 
Salekul

------=_NextPart_000_0011_01C5F91A.EC29DE80-- --===============1013522185== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1013522185==-- From ipsec-bounces@ietf.org Mon Dec 05 06:36:56 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjEeO-0002Bt-PN; Mon, 05 Dec 2005 06:36:56 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjEeN-0002Bo-1n for ipsec@megatron.ietf.org; Mon, 05 Dec 2005 06:36:55 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04286 for ; Mon, 5 Dec 2005 06:36:04 -0500 (EST) Received: from xproxy.gmail.com ([66.249.82.195]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjEzd-0005H6-Pp for ipsec@ietf.org; Mon, 05 Dec 2005 06:58:55 -0500 Received: by xproxy.gmail.com with SMTP id s9so501778wxc for ; Mon, 05 Dec 2005 03:36:48 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=saDY3X5Es1qz0lmkrTHjLYirE6DiVUZqzcIIJcnSiTpxhqg2ofcHs+ftcIWTbSUEqSvf4cjyz8lt3IO/MTPxYWdK8M1y9YurAgNluYxlkBYNjoEQmxQlEHBbd3TStgP/d+zPg/eBrWg/XmY0DOWd23QO8XXUqzhqpjHQ9RY4o2I= Received: by 10.70.91.9 with SMTP id o9mr7393628wxb; Mon, 05 Dec 2005 03:36:47 -0800 (PST) Received: by 10.70.91.15 with HTTP; Mon, 5 Dec 2005 03:36:47 -0800 (PST) Message-ID: Date: Mon, 5 Dec 2005 12:36:47 +0100 From: Jan Hutter To: ipsec@ietf.org MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Subject: [Ipsec] IKEv2 Notify INVALID_SYNTAX in IKE_SA_INIT exchange X-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="===============0044629068==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0044629068== Content-Type: multipart/alternative; boundary="----=_Part_4006_5060849.1133782607874" ------=_Part_4006_5060849.1133782607874 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello, Do I have to reply a IKE_SA_INIT request with a Notify payload of type INVALID_SYNTAX in the following situations: - No configuration for a specific peer could be found - The SA payload does not contain an IKE proposal Thank you for any hints. Jan Hutter Student at University of applied sciences, Rapperswil, Switzerland ------=_Part_4006_5060849.1133782607874 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hello,

Do I have to reply a IKE_SA_INIT request with a Notify payload of type INVA= LID_SYNTAX in the following situations:
- No configuration for a specific peer could be found
- The SA payload does not contain an IKE proposal

Thank you for any hints.

Jan Hutter

Student at University of applied sciences, Rapperswil, Switzerland
------=_Part_4006_5060849.1133782607874-- --===============0044629068== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0044629068==-- From ipsec-bounces@ietf.org Mon Dec 05 06:48:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjEpv-0004mm-Al; Mon, 05 Dec 2005 06:48:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjEpt-0004md-VI for ipsec@megatron.ietf.org; Mon, 05 Dec 2005 06:48:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA05245 for ; Mon, 5 Dec 2005 06:47:59 -0500 (EST) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjFBA-0005eQ-Jo for ipsec@ietf.org; Mon, 05 Dec 2005 07:10:50 -0500 Received: from YnirNew (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id jB5BmHAF010294; Mon, 5 Dec 2005 13:48:17 +0200 (IST) Message-Id: <200512051148.jB5BmHAF010294@michael.checkpoint.com> From: "Yoav Nir" To: "'Jan Hutter'" , Subject: RE: [Ipsec] IKEv2 Notify INVALID_SYNTAX in IKE_SA_INIT exchange Date: Mon, 5 Dec 2005 13:48:17 +0200 Organization: Check Point MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Thread-Index: AcX5kJddZrhh7Ig1SJCDZyDco+Eu0wAANcnQ In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org For the first case, I would definitely send a NO_PROPOSAL_CHOSEN. For the second case, I also think NO_PROPOSAL_CHOSEN is best, although I can see it fitting the "value was out of range" description of INVALID_SYNTAX ________________________________ From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Jan Hutter Sent: Monday, December 05, 2005 1:37 PM To: ipsec@ietf.org Subject: [Ipsec] IKEv2 Notify INVALID_SYNTAX in IKE_SA_INIT exchange Hello, Do I have to reply a IKE_SA_INIT request with a Notify payload of type INVALID_SYNTAX in the following situations: - No configuration for a specific peer could be found - The SA payload does not contain an IKE proposal Thank you for any hints. Jan Hutter Student at University of applied sciences, Rapperswil, Switzerland _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 05 08:13:27 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjG9n-0003et-Pq; Mon, 05 Dec 2005 08:13:27 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjG9j-0003YZ-P5 for ipsec@megatron.ietf.org; Mon, 05 Dec 2005 08:13:25 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16184 for ; Mon, 5 Dec 2005 08:12:32 -0500 (EST) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjGV1-0000fb-0n for ipsec@ietf.org; Mon, 05 Dec 2005 08:35:24 -0500 Received: from fireball.kivinen.iki.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jB5DD8Ic012345 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 5 Dec 2005 15:13:08 +0200 (EET) Received: (from kivinen@localhost) by fireball.kivinen.iki.fi (8.13.4/8.12.11) id jB5DD7OY019372; Mon, 5 Dec 2005 15:13:07 +0200 (EET) X-Authentication-Warning: fireball.kivinen.iki.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17300.15587.667154.724088@fireball.kivinen.iki.fi> Date: Mon, 5 Dec 2005 15:13:07 +0200 From: Tero Kivinen To: Michael Richardson Subject: [Ipsec] Re: New draft on hash use in IKE and IPsec In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 3 min X-Total-Time: 3 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 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 Michael Richardson writes: > b) I think that I agree that the hash used in NAT-D is not > susceptible. I'm not sure why. Reasons why it might not matter: > > i) it's under the protection of the IKE SA, so it can't be modified > by someone in the middle. In IKEv2 they are protected, in the IKEv1 they are not protected. > iii) the hash is not being used to provide integrity check of a larger > object, but rather to obsecure the object. Maybe someone can > undo the hash to get the original values back. (The hash is bigger > than the IPv4+port, but probably not bigger than the IPv6+port) Yes, this is the reason why hashing is used in NAT-D. i.e. those payloads are sent in clear, and some people were very concerned that we reveal internal IP-addresses to the listeners outside the NAT, thus we obscure them by hashing them. This does not offer very much protection, but as random SPIs are included at least the listener needs to do calculation for each connection separately, i.e. precalculation is not possible. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 05 11:47:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjJVB-0003AB-H4; Mon, 05 Dec 2005 11:47:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjJV9-0003A6-LN for ipsec@megatron.ietf.org; Mon, 05 Dec 2005 11:47:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11699 for ; Mon, 5 Dec 2005 11:46:53 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjJqT-0000AX-80 for ipsec@ietf.org; Mon, 05 Dec 2005 12:09:46 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id jB5GhcIG020255; Mon, 5 Dec 2005 11:43:41 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 5 Dec 2005 11:09:43 -0500 To: "Salekul Islam" From: Stephen Kent Subject: Re: [Ipsec] Ordering of Security Association in Transport Adjacency X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.8 (/) X-Scan-Signature: 6cca30437e2d04f45110f2ff8dc1b1d5 Cc: ipsec@ietf.org, abuza_m@encs.concordia.ca X-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="===============1284457441==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============1284457441== Content-Type: multipart/alternative; boundary="============_-1078321476==_ma============" --============_-1078321476==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" At 9:37 PM -0500 12/4/05, Salekul Islam wrote: >Hi, > >I have a simple question. I am sorry if it had been answered >already. I could not find it in the mailing list archive. > >The IPsec architecture has recommend two transport-mode SAs like this: > > [IP1][AH][ESP][upper] > >My question is why it has not recommended the other order also like this: > > [IP1][ESP][AH][upper] > >Is there any cryptographical benefit or anything else? > >Thank you, > >Salekul The only motivation for using both AH and ESP in transport mode is to receive integrity protection for the IP header, as provided by AH. That dictates the order in the first example above. The other example, in which AH is applied on the inside, is not useful, since we have ESP options that offer integrity and confidentiality, which are more efficient that putting AH inside of ESP. Steve --============_-1078321476==_ma============ Content-Type: text/html; charset="us-ascii" Re: [Ipsec] Ordering of Security Association in Transport
At 9:37 PM -0500 12/4/05, Salekul Islam wrote:
Hi,
 
I have a simple question. I am sorry if it had been answered already. I could not find it in the mailing list archive.
 
The IPsec architecture has recommend two transport-mode SAs like this:
 
    [IP1][AH][ESP][upper]
My question is why it has not recommended the other order also like this:
 
    [IP1][ESP][AH][upper]
 
Is there any cryptographical benefit or anything else?
 
Thank you,
 
Salekul

The only motivation for using both AH and ESP in transport mode is to receive integrity protection for the IP header, as provided by AH. That dictates the order in the first example above. The other example, in which AH is applied on the inside, is not useful, since we have ESP options that offer integrity and confidentiality, which are more efficient that putting AH inside of ESP.

Steve
--============_-1078321476==_ma============-- --===============1284457441== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============1284457441==-- From ipsec-bounces@ietf.org Mon Dec 05 12:06:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjJnA-0007OH-Oz; Mon, 05 Dec 2005 12:06:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjJn9-0007O2-Qm for ipsec@megatron.ietf.org; Mon, 05 Dec 2005 12:06:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA13939 for ; Mon, 5 Dec 2005 12:05:29 -0500 (EST) Received: from burp.tkv.asdf.org ([212.16.99.49] ident=root) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjK8T-0000rC-0A for ipsec@ietf.org; Mon, 05 Dec 2005 12:28:22 -0500 Received: from burp.tkv.asdf.org (msa@localhost [127.0.0.1]) by burp.tkv.asdf.org (8.13.4/8.13.4/Debian-3) with ESMTP id jB5H5sg2024551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 5 Dec 2005 19:05:55 +0200 Received: (from msa@localhost) by burp.tkv.asdf.org (8.13.4/8.13.4/Submit) id jB5H5sih024548; Mon, 5 Dec 2005 19:05:54 +0200 Date: Mon, 5 Dec 2005 19:05:54 +0200 Message-Id: <200512051705.jB5H5sih024548@burp.tkv.asdf.org> From: Markku Savela To: ipsec@ietf.org In-reply-to: (message from Stephen Kent on Mon, 5 Dec 2005 11:09:43 -0500) Subject: Re: [Ipsec] Ordering of Security Association in Transport Adjacency References: X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 > >The IPsec architecture has recommend two transport-mode SAs like this: > > > > [IP1][AH][ESP][upper] > > > >My question is why it has not recommended the other order also like this: > > > > [IP1][ESP][AH][upper] > > > >Is there any cryptographical benefit or anything else? > > > The other > example, in which AH is applied on the inside, is not > useful, since we have ESP options that offer integrity and > confidentiality, which are more efficient that putting AH inside of > ESP. I can think one use for the latter order: you want to check the integrity of the IP header, but don't want to show this fact to outside snooper/hacker. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 05 17:56:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjPG9-0006CP-41; Mon, 05 Dec 2005 17:56:37 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjPG7-00069H-01 for ipsec@megatron.ietf.org; Mon, 05 Dec 2005 17:56:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26268 for ; Mon, 5 Dec 2005 17:55:44 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjPbP-0005so-Jl for ipsec@ietf.org; Mon, 05 Dec 2005 18:18:40 -0500 Received: from [10.20.30.249] (dsl2-63-249-109-231.cruzio.com [63.249.109.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB5MuL77020461 for ; Mon, 5 Dec 2005 14:56:23 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 5 Dec 2005 14:39:12 -0800 To: IPsec WG From: Hugo Krawczyk Content-Type: text/plain; charset="iso-8859-1" ; format="flowed" Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by above.proper.com id jB5MuL77020461 X-Spam-Score: 0.0 (/) X-Scan-Signature: 6d95a152022472c7d6cdf886a0424dc6 Content-Transfer-Encoding: quoted-printable Subject: [Ipsec] Re: [saag] Structure of documents discussing protocols and hashes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org David McGrew asked me to comment on the appended message re hash functions in IKE. My view is that there is no need to RUSH into upgrading SHA-1 in IKEv1 or v2. The only place where the recent attacks have a direct relevance is in public key certificates. Other uses of hashes in IKE (which include PRF, MAC, ephemeral signatures, and the randomness extraction functionality referred to by David's mail) would have some benefit from a hash function upgrade but nothing truly urgent. None of these uses are based on collision resistance in some essential way. Of course, new attacks, in particular on the pseudo-random properties of secretly-keyed HMAC, could be found in the future (or maybe even in the present), but such attacks to be of real significance will not be merely collision attacks. On the other hand it is imperative that a transition to stronger hash functions be planned now and executed asap. First, we do not know how fas= t attacks will improve and reach the point of being relevant even for uses such as in IKE. Second, such a transition is needed across all cryptographic applications and certainly across ietf standards. Last, there are no performance issues with the hash functions used in IKE. These operations are all quite insiginificant in comparison to publi= c key (signatures and Diffie-Hellman) operations, so a slower hash function should not be a consideration against upgrading (this may be different in the case of ipsec that uses HMAC to MAC millions of packets). As for certificates, where collision attacks may be of real significance, this is not IKE-specific. In that front, planning a transition is even more significant (and I would not count on the lack of explicit practical attacks on real-world certificates). Hugo On Fri, 2 Dec 2005, David McGrew wrote: > Hi Michael, > > On Dec 2, 2005, at 7:35 AM, Michael Richardson wrote: > > > -----BEGIN PGP SIGNED MESSAGE----- > > Hash: SHA1 > > > >>>>>> "David" =3D=3D David McGrew writes: > >>>>>> > > David> I think that it's worth suggesting that implementors > > move to > > David> a SHA-256 based PRF for IKE. > > > > I don't think you understand the attacks very well if you suggest > > that. > > The PRF is about sifting bits. The inputs to it are fixed in length > > (for a given situation) consists of pieces from both parties, which > > are > > both public (nonces and cookies), as well as private (result of DH). > > The output of it is never made public. There is nothing for an > > attacker to get onto. > > As far as I understand things, unless someone figures out a way to > > break MD5 such that knowing one input to the function means that you > > know the entire output, the use of hashes for PRFs is not imperiled. > > Sure, and HMAC-SHA1 is believed to be secure regardless of the > collision results against SHA1, and it is HMAC that's used in the PRF. > > My comments were in part motivated by the desire to use a Diffie- > Hellman method that's provably secure.I believe that that collision > resistance of the IKE KDF hash is needed for such a proof.The > analysis of the key derivation used in IKE that I have in mind is in > Dodis, Gennaro, H=C2stad, Krawczyk, and Rabin, "Randomness Extraction > and Key Derivation Using the CBC, Cascade and HMAC Modes", Advances > in Cryptology =F1 CRYPTO 2004, online at http://theory.lcs.mit.edu/ > ~yevgen/ps/hmac.ps.The IKE implications are mentioned in the 2nd to > last par. of Section 1.2, and the HMAC results are in the subsection > "The Extraction Properties of HMAC".I'll check with Hugo to verify > my interpretation here. > > The point that I wanted to make is that "it is best to migrate > towards crypto methods that have less unproven assumptions", not > "there is a lurking flaw and we all need to implement something new > right away".I agree with your gist, that as far as we know, there > are no security problems with using IKE relying on an HMAC-SHA1 PRF. > > > > > The reason that I say this is because getting the right inputs and > > outputs to the PRF is often very difficult. An error hereis usually > > made consistently, so an implementation will interoperate with itsel= f, > > and it is often hard to get to details of the input/output of the PR= F > > out of many implementations (in debug mode), so it is very hard to > > figure out what is occuring wrong. > > > > i.e. this is among the hardest piece to test. > > Yes, and unfortunately KDFs in general seem to have been designed > without algorithm agility in mind. > > David > > > > _______________________________________________ saag mailing list saag@mit.edu http://jis.mit.edu/mailman/listinfo/saag _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 05 17:56:38 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjPGA-0006E3-6I; Mon, 05 Dec 2005 17:56:38 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjPG7-0006AF-J5 for ipsec@megatron.ietf.org; Mon, 05 Dec 2005 17:56:35 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA26266 for ; Mon, 5 Dec 2005 17:55:44 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjPbS-0005t0-QU for ipsec@ietf.org; Mon, 05 Dec 2005 18:18:40 -0500 Received: from [10.20.30.249] (dsl2-63-249-109-231.cruzio.com [63.249.109.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB5MuL75020461; Mon, 5 Dec 2005 14:56:23 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Mon, 5 Dec 2005 14:53:59 -0800 To: Hugo Krawczyk From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 69a74e02bbee44ab4f8eafdbcedd94a1 Cc: saag@mit.edu, IPsec WG Subject: [Ipsec] Re: [saag] Structure of documents discussing protocols and hashes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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:52 PM +0200 12/5/05, Hugo Krawczyk wrote: >My view is that there is no need to RUSH into upgrading SHA-1 in >IKEv1 or v2. The only place where the recent attacks have a direct >relevance is in public key certificates. Other uses of hashes in IKE >(which include PRF, MAC, ephemeral signatures, and the randomness >extraction functionality referred to by David's mail) would have some >benefit from a hash function upgrade but nothing truly urgent. None of >these uses are based on collision resistance in some essential way. >Of course, new attacks, in particular on the pseudo-random properties of >secretly-keyed HMAC, could be found in the future (or maybe even in the >present), but such attacks to be of real significance will not be merely >collision attacks. The series of "hash evaluation" documents should give as specific numbers as possible. Here, you say "there is no need to RUSH" and "nothing truly urgent". Do we know of any collision-reduction attacks now that would cause any issues with IKE or IPsec? If not, why is there any need to amble, much less rush, towards new hash functions? Given that our preferred encryption algorithms are 112 and 128 bits strong, exactly where should we worry about using MD5 or SHA1 in IPsec (other than in the PKIX part)? Of course, if someone uses AES-192 or AES-256, they probably want to use SHA-256, but that's not relevant here. >First, we do not know how fast >attacks will improve and reach the point of being relevant even for uses >such as in IKE. Let's assume that the collision-resistance attacks get very good very quickly, such as reducing the collision-resistance of SHA-1 to 40 bits, but the preimage resistance is unaffected. Would our recommended hash functions change, and why? --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 05 18:19:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjPcd-0005MT-Th; Mon, 05 Dec 2005 18:19:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjPcc-0005LK-MJ for ipsec@megatron.ietf.org; Mon, 05 Dec 2005 18:19:50 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA29630 for ; Mon, 5 Dec 2005 18:19:00 -0500 (EST) Received: from machshav.com ([147.28.0.16]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjPxz-0006zY-Pk for ipsec@ietf.org; Mon, 05 Dec 2005 18:41:57 -0500 Received: by machshav.com (Postfix, from userid 512) id ABB89FB28A; Mon, 5 Dec 2005 18:19:43 -0500 (EST) Received: from berkshire.machshav.com (localhost [127.0.0.1]) by machshav.com (Postfix) with ESMTP id 25466FB27F; Mon, 5 Dec 2005 18:19:42 -0500 (EST) Received: from cs.columbia.edu (localhost [127.0.0.1]) by berkshire.machshav.com (Postfix) with ESMTP id DBAB03C015D; Mon, 5 Dec 2005 18:19:34 -0500 (EST) X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 From: "Steven M. Bellovin" To: Paul Hoffman In-Reply-To: (Your message of "Mon, 05 Dec 2005 14:53:59 PST.") Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 05 Dec 2005 18:19:34 -0500 Message-Id: <20051205231934.DBAB03C015D@berkshire.machshav.com> X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Cc: IPsec WG , saag@mit.edu, Hugo Krawczyk Subject: [Ipsec] Re: [saag] Structure of documents discussing protocols and hashes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org In message , Paul Hoffman writes: > >Here, you say "there is no need to RUSH" and "nothing truly urgent". >Do we know of any collision-reduction attacks now that would cause >any issues with IKE or IPsec? If not, why is there any need to amble, >much less rush, towards new hash functions? > Per mine and ekr's paper, the problem is that we *can't* switch, even if a serious problem developed. What's really necessary now is to add the extra signaling, so that we can switch hash functions if and when that becomes necessary. --Steven M. Bellovin, http://www.cs.columbia.edu/~smb _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 05 19:07:03 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjQMJ-0002DY-Nq; Mon, 05 Dec 2005 19:07:03 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjQMH-0002BA-7F for ipsec@megatron.ietf.org; Mon, 05 Dec 2005 19:07:01 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04001 for ; Mon, 5 Dec 2005 19:06:10 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EjQhe-0008Rv-Gn for ipsec@ietf.org; Mon, 05 Dec 2005 19:29:07 -0500 Received: from [10.20.30.249] (dsl2-63-249-109-231.cruzio.com [63.249.109.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB605iZJ027786; Mon, 5 Dec 2005 16:05:45 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <20051205231934.DBAB03C015D@berkshire.machshav.com> References: <20051205231934.DBAB03C015D@berkshire.machshav.com> Date: Mon, 5 Dec 2005 16:05:43 -0800 To: "Steven M. Bellovin" From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Cc: IPsec WG , saag@mit.edu, Hugo Krawczyk Subject: [Ipsec] Re: [saag] Structure of documents discussing protocols and hashes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 6:19 PM -0500 12/5/05, Steven M. Bellovin wrote: >In message , Paul Hoffman writes: > >> >>Here, you say "there is no need to RUSH" and "nothing truly urgent". >>Do we know of any collision-reduction attacks now that would cause >>any issues with IKE or IPsec? If not, why is there any need to amble, >>much less rush, towards new hash functions? >> > >Per mine and ekr's paper, the problem is that we *can't* switch, even >if a serious problem developed. What's really necessary now is to add >the extra signaling, so that we can switch hash functions if and when >that becomes necessary. That is important, but orthogonal to my question for Hugo. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Dec 07 06:41:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ejxfb-0002iD-G9; Wed, 07 Dec 2005 06:41:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EjxfZ-0002hj-L5 for ipsec@megatron.ietf.org; Wed, 07 Dec 2005 06:41:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA22693 for ; Wed, 7 Dec 2005 06:40:18 -0500 (EST) Received: from 63-197-255-154.ded.pacbell.net ([63.197.255.154] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ejy1D-0004Ke-HU for ipsec@ietf.org; Wed, 07 Dec 2005 07:03:34 -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 Date: Wed, 7 Dec 2005 03:45:33 -0800 Message-ID: Thread-Topic: draft-ietf-ipsec-esp-v3-10.txt Thread-Index: AcX7I7sj5sDiqZwESNmb3c/FMYziKg== From: "Vishwas Manral" To: "IPsec" X-Spam-Score: 0.0 (/) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: quoted-printable Cc: Pekka Savola Subject: [Ipsec] draft-ietf-ipsec-esp-v3-10.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Steve, (CC'ing Pekka for IPv6 inputs)=20 Sorry for getting this late. I noticed in section 3.3.4 it is stated that: - NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire implementations, it will be necessary to examine all the extension headers to determine if there is a fragmentation header and hence that the packet needs reassembling prior to IPsec processing. However I do not think having a fragment header itself means the packet is a fragment. Only if the offset field or the more fragment field is set to non-zero, only then is a packet a fragment.=20 The fragment header is also used to signal to an IPv4-to-IPv6 translator that the packet can be fragmented, DF bit setting in the outer IPv4 header (SIIT - RFC2765). I think the same text is there for AH draft draft-ietf-ipsec-rfc2402bis-11.txt too. We could change the text to=20 NOTE: For IPv6 -- For bump-in-the-stack and bump-in-the-wire implementations, it will be necessary to examine all the extension headers to determine if there is a fragmentation header, and either the More flag or the Fragment Offset is non-zero. If so that packet needs reassembling prior to IPsec processing. We can bounce the text off the IPv6 list too if we desire. Thanks, Vishwas _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Dec 07 16:40:37 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Ek71h-0006PV-1c; Wed, 07 Dec 2005 16: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 1Ek71e-0006PF-Ql for ipsec@megatron.ietf.org; Wed, 07 Dec 2005 16:40:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04083 for ; Wed, 7 Dec 2005 16:39:42 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ek7NP-0001WT-PQ for ipsec@ietf.org; Wed, 07 Dec 2005 17:03:05 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id jB7LeFIC008323; Wed, 7 Dec 2005 16:40:15 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Wed, 7 Dec 2005 16:40:07 -0500 To: "Vishwas Manral" From: Stephen Kent Subject: Re: [Ipsec] draft-ietf-ipsec-esp-v3-10.txt Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 08e48e05374109708c00c6208b534009 Cc: IPsec , Pekka Savola X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Vishwas, Sorry, but it's too late to consider any more changes to this text. All of the authors have responded to the RFC Editor, and made final edits for the IPsec RFCs. They should be published in a few days. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Dec 08 14:03:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkR2z-0003u1-EO; Thu, 08 Dec 2005 14:03:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkR2s-0003sX-82 for ipsec@megatron.ietf.org; Thu, 08 Dec 2005 14:03:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25205 for ; Thu, 8 Dec 2005 14:02:07 -0500 (EST) Received: from mailgw2.technion.ac.il ([132.68.238.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkR2j-0004UD-36 for ipsec@ietf.org; Thu, 08 Dec 2005 14:03:02 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgw2.technion.ac.il (Postfix) with ESMTP id 5BBD2390286 for ; Thu, 8 Dec 2005 21:02:48 +0200 (IST) Received: from mailgw2.technion.ac.il ([127.0.0.1]) by localhost (mailgw2.technion.ac.il [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 23799-01-91 for ; Thu, 8 Dec 2005 21:02:48 +0200 (IST) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by mailgw2.technion.ac.il (Postfix) with ESMTP id 1BA74390278 for ; Thu, 8 Dec 2005 21:02:48 +0200 (IST) Received: from ee.technion.ac.il (localhost [127.0.0.1]) by ee.technion.ac.il (8.12.10+Sun/8.12.2) with ESMTP id jB8J4wdr008841; Thu, 8 Dec 2005 21:04:59 +0200 (IST) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.12.10+Sun/8.12.2/Submit) with ESMTP id jB8J4vcq008838; Thu, 8 Dec 2005 21:04:58 +0200 (IST) Date: Thu, 8 Dec 2005 21:04:57 +0200 (IST) From: Hugo Krawczyk To: Paul Hoffman In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: AAAAAQAAAAQ= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new at technion.ac.il X-Spam-Score: 0.0 (/) X-Scan-Signature: c3a18ef96977fc9bcc21a621cbf1174b Cc: saag@mit.edu, IPsec WG Subject: [Ipsec] Re: [saag] Structure of documents discussing protocols and hashes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org See below On Mon, 5 Dec 2005, Paul Hoffman wrote: > At 9:52 PM +0200 12/5/05, Hugo Krawczyk wrote: > >My view is that there is no need to RUSH into upgrading SHA-1 in > >IKEv1 or v2. The only place where the recent attacks have a direct > >relevance is in public key certificates. Other uses of hashes in IKE > >(which include PRF, MAC, ephemeral signatures, and the randomness > >extraction functionality referred to by David's mail) would have some > >benefit from a hash function upgrade but nothing truly urgent. None of > >these uses are based on collision resistance in some essential way. > >Of course, new attacks, in particular on the pseudo-random properties of > >secretly-keyed HMAC, could be found in the future (or maybe even in the > >present), but such attacks to be of real significance will not be merely > >collision attacks. > > The series of "hash evaluation" documents should give as specific > numbers as possible. > > Here, you say "there is no need to RUSH" and "nothing truly urgent". > Do we know of any collision-reduction attacks now that would cause > any issues with IKE or IPsec? If not, why is there any need to amble, > much less rush, towards new hash functions? Even if the functions we use today are not yet broken in a practical sense, what is broken is our confidence on these functions, and we have to act on this "broken confidence". The way to do it is NOT by trying to measure (quantify) every day what is the latest best attack, but rather we should take advantage of the fact that most applications are currently NOT broken and prepare for a calm (but firm!) transition to new functions. In this sense I am not suggesting anything different than Belovin-Rescorla. As Steve has recently put it: > Per mine and ekr's paper, the problem is that we *can't* switch, even > if a serious problem developed. What's really necessary now is to add > the extra signaling, so that we can switch hash functions if and when > that becomes necessary. The counter-part of this switching problem is (paraphrasing the above): "even when we'll be ready to switch we won't know to WHAT to switch". That is, do not expect that we will be in a situation where our confidence will be fully (or even significantly) recovered. But that is not necessarily a bad thing. Thinking of specific cryptographic functions as resistant to attacks for many years to come is an illusion. We must always be ready for cryptanalytical developments as we've seen with MD5/SHA or even more serious ones (i.e., ones that develop more rapidly into practical attacks). What can we do about this state of affairs? Preparing our applications and implementations for switchable functions, building our protocols on the basis of functionality rather than on specific algorithms (for example, define the protocol in terms of mac or prf instead of HMAC, and certainly not in terms of specific functions such as SHA2) and BUILD YOUR SECURITY/CRYPTO DESIGNS ON THE MINIMAL POSSIBLE ASSUMPTIONS ON THE UNDERLYING FUNCTIONS. HMAC's design is a good example of applying the latter principle and the reason HMAC has resisted all the recent attacks. Should we apply this principle again? Sure. Randomized hashing is the name of the (new) game when it comes to collision resistant hashing and signatures. Hugo > > Given that our preferred encryption algorithms are 112 and 128 bits > strong, exactly where should we worryabout using MD5 or SHA1 in > IPsec (other than in the PKIX part)? Of course, if someone uses > AES-192 or AES-256, they probably want to use SHA-256, but that's not > relevant here. > > >First, we do not know how fast > >attacks will improve and reach the point of being relevant even for uses > >such as in IKE. > > Let's assume that the collision-resistance attacks get very good very > quickly, such as reducing the collision-resistance of SHA-1 to 40 > bits, but the preimage resistance is unaffected. Would our > recommended hash functions change, and why? > > --Paul Hoffman, Director > --VPN Consortium > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Dec 08 15:47:40 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkSfz-0006GB-Up; Thu, 08 Dec 2005 15:47:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkSfu-0006Cb-EY for ipsec@megatron.ietf.org; Thu, 08 Dec 2005 15:47:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09019 for ; Thu, 8 Dec 2005 15:46:29 -0500 (EST) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkSfi-0000cq-Co for ipsec@ietf.org; Thu, 08 Dec 2005 15:47:25 -0500 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id jB8KkfIC002283; Thu, 8 Dec 2005 15:46:42 -0500 (EST) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 8 Dec 2005 15:10:52 -0500 To: Hugo Krawczyk From: Stephen Kent Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Virus-Scanned: ClamAV version 0.83, clamav-milter version 0.83 on 128.33.1.41 X-Virus-Status: Clean X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Cc: IPsec WG , Paul Hoffman Subject: [Ipsec] Re: [saag] Structure of documents discussing protocols and hashes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hugo, I think it would be good to explore randomized hashing in the near term (said the non-cryptographer). At a minimum it might be good to develop RH-based integrity options for our various protocols, and see what the performance and engineering implications are. Would you envision using an hash algorithm like SHA-256 with randomization as a pre-processing step? That might be an especially attractive approach for an interim hash function solution, given that NIST is likely to suggest a near term transition to SHA-256. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Dec 08 16:48:20 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkTci-0007He-DX; Thu, 08 Dec 2005 16:48:20 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkTcg-0007FN-Es for ipsec@megatron.ietf.org; Thu, 08 Dec 2005 16:48:18 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23176 for ; Thu, 8 Dec 2005 16:47:15 -0500 (EST) Received: from cod.sandelman.ca ([192.139.46.139] helo=lists.sandelman.ca) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkTca-0005mv-3K for ipsec@ietf.org; Thu, 08 Dec 2005 16:48:12 -0500 Received: from sandelman.ottawa.on.ca (desk.marajade.sandelman.ca [205.150.200.247]) by lists.sandelman.ca (8.11.6p3/8.11.6) with ESMTP id jB8LlV218934 (using TLSv1/SSLv3 with cipher EDH-RSA-DES-CBC3-SHA (168 bits) verified OK); Thu, 8 Dec 2005 16:47:37 -0500 (EST) Received: from sandelman.ottawa.on.ca (unknown [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 5817D3AD9C; Thu, 8 Dec 2005 16:47:01 -0500 (EST) To: Hugo Krawczyk In-Reply-To: Message from Hugo Krawczyk of "Thu, 08 Dec 2005 21:04:57 +0200." References: X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 17) Date: Thu, 08 Dec 2005 16:47:01 -0500 Message-ID: <15586.1134078421@sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: 0.0 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb Cc: IPsec WG , saag@mit.edu, Paul Hoffman Subject: [Ipsec] Re: [saag] Structure of documents discussing protocols and hashes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >>>>> "Hugo" == Hugo Krawczyk writes: Hugo> different than Belovin-Rescorla. As Steve has recently put Hugo> it: smb> Per mine and ekr's paper, the problem is that we *can't* switch, smb> even if a serious problem developed. What's really necessary now smb> is to add the extra signaling, so that we can switch hash smb> functions if and when that becomes necessary. Hugo> The counter-part of this switching problem is (paraphrasing Hugo> the above): "even when we'll be ready to switch we won't know Hugo> to WHAT to switch". That is, do not expect that we will be in Hugo> a situation where our confidence will be fully (or even My feeling is: pick something. SHA-256 is fine as a test case for testing the ability to switch. It might not be the right answer in 2010. I also continue to question if PRF uses are really affected. - -- ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Xelerance Corporation, Ottawa, ON |net architect[ ] mcr@xelerance.com http://www.sandelman.ottawa.on.ca/mcr/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Finger me for keys iQEVAwUBQ5ip04CLcPvd0N1lAQIC+Af+IZGmTCc82MFzYh+qtv4oc94rTnb26d8I I9SF+RdGdVqr7oUPr59X4rfakY2LEHMZTH+vSkmwL6REVGhGpkvqPrNfIvAcaoZq STCxWv7bhnHbuuOO9wRJ8LPWVe35FrjnHKmvkaW4Y/zWGas5OFoxJYt35ufqt8ln Xz/IM5WT/vc9bS0ihWPwPKLPMqQCdK6H1wNnp5AtyZc0/GhGJ1LLWo/gCcBMo15Y M5RkR5W/FPiAwpSNzfsmOAD6BVFhZqhye5oq0ina309umVecOv1cJ08G8Jtn2rct /dHfXWSAsktVNAi1kaAAWOFOXX91iOxL4239Nxf0z9sDWhAMa94ikA== =+LOT -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Dec 08 18:03:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkUnh-0006To-TG; Thu, 08 Dec 2005 18:03:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkUne-0006SO-Rx for ipsec@megatron.ietf.org; Thu, 08 Dec 2005 18:03:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA03355 for ; Thu, 8 Dec 2005 18:02:38 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkUnX-0000ni-VI for ipsec@ietf.org; Thu, 08 Dec 2005 18:03:37 -0500 Received: from [10.20.30.249] (dsl2-63-249-109-231.cruzio.com [63.249.109.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id jB8N3Obd072851; Thu, 8 Dec 2005 15:03:24 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 8 Dec 2005 15:02:19 -0800 To: IPsec WG , saag@mit.edu From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Cc: Subject: [Ipsec] Re: [saag] Structure of documents discussing protocols and hashes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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:02 PM -0500 12/8/05, Sam Hartman wrote: >We'd like to have quantified results to guide our thinking. We don't >have such results; we have educated intuition about the strengths of >functions we are using. We have both. We now have quantified results that tell us that the two popular hash functions have much-weaker-than-expected collision-resistance. We have another related quantified result: the initial attacks on these functions were improved on in less than a year. We have educated intuition that these attacks will probably get better. >I think it would be irresponsible to ignore >this intuition just as I think it irresponsible to panic. Fully agree. But I don't see how the intuition affects the structure of of documents discussing protocols and hashes. - Our desire for agility in choosing all cryptographic functions to use is based on solid quantified understanding that sometimes a devastating attack is found. The reasons we need agility today are exactly the same as they were three years ago, before the current attacks were found; no intuition there. - We have quantified results that our earlier intuition about particular hash functions was wrong. We know for a fact that we should not to re-use the same intuition: we know we should look for things that don't match what we did before. Where did you want the intuition to come in here? --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Dec 08 18:29:32 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkVCe-00071Z-KZ; Thu, 08 Dec 2005 18:29:32 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EkVCY-00070m-LS for ipsec@megatron.ietf.org; Thu, 08 Dec 2005 18:29:30 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA05747 for ; Thu, 8 Dec 2005 18:28:18 -0500 (EST) Received: from mailgw2.technion.ac.il ([132.68.238.33]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EkVCO-0001ch-S0 for ipsec@ietf.org; Thu, 08 Dec 2005 18:29:17 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgw2.technion.ac.il (Postfix) with ESMTP id 9D111390296 for ; Fri, 9 Dec 2005 01:28:57 +0200 (IST) Received: from mailgw2.technion.ac.il ([127.0.0.1]) by localhost (mailgw2.technion.ac.il [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 24518-02-72 for ; Fri, 9 Dec 2005 01:28:57 +0200 (IST) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by mailgw2.technion.ac.il (Postfix) with ESMTP id 6FE71390246 for ; Fri, 9 Dec 2005 01:28:57 +0200 (IST) Received: from ee.technion.ac.il (localhost [127.0.0.1]) by ee.technion.ac.il (8.12.10+Sun/8.12.2) with ESMTP id jB8NV6dr003158; Fri, 9 Dec 2005 01:31:06 +0200 (IST) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.12.10+Sun/8.12.2/Submit) with ESMTP id jB8NV0Jr003134; Fri, 9 Dec 2005 01:31:05 +0200 (IST) Date: Fri, 9 Dec 2005 01:31:00 +0200 (IST) From: Hugo Krawczyk To: Stephen Kent In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Brightmail-Tracker: AAAAAQAAAAQ= X-Whitelist: TRUE X-Virus-Scanned: by amavisd-new at technion.ac.il X-Spam-Score: 0.0 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: IPsec WG , saag@mit.edu, Paul Hoffman Subject: [Ipsec] Re: [saag] Structure of documents discussing protocols and hashes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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, 8 Dec 2005, Stephen Kent wrote: > Hugo, > > I think it would be good to explore randomized hashing in the near > term (said the non-cryptographer).At a minimum it might be good to > develop RH-based integrity options for our various protocols, and see > what the performance and engineering implications are.Would you > envision using an hash algorithm like SHA-256 with randomization as a > pre-processing step? Exactly! And not only with SHA-256, but with any other existing or future hash function. I envision randomized hashing as a way to FREE digital signatures from their dependency on collision resistance (much like HMAC did for MAC functions) > That might be an especially attractive approach > for an interim hash function solution, given that NIST is likely to > suggest a near term transition to SHA-256. > As said, I do not see this just as an interim approach, but rather as a durable SAFETY NET for one of our most precious cryptographic tools: digital signatures. Now, while this approach does not require to change hash functions or to build dedicated hash functions, it does require a change of data encoding in digital signatures. This is not a trivial change but one we can afford (and well worth the insurance it buys us). Moreover, if we are going to clean up our protocols for better robustness to future attacks then we may well (personally, I'd say WE MUST) take the opporunity to upgrade the security of digital signatures (especially in applications with third-party verifiability such as certificates). This approach is explained in the now-expired draft draft-irtf-cfrg-rhash-00.txt which I re-posted now as http://www.ee.technion.ac.il/~hugo/draft-irtf-cfrg-rhash-00.txt Since its publication we have obtained very encouraging theoretical results backing the specific design outlined in the above draft. An academic paper with these results will be posted (I'll try to do it tomorrow) in http://www.ee.technion.ac.il/~hugo/rhash.pdf Comments are welcome. Hugo > Steve > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 12 11:53:33 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Elqvd-00021u-QP; Mon, 12 Dec 2005 11:53:33 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Elqvc-000211-1s for ipsec@megatron.ietf.org; Mon, 12 Dec 2005 11:53:32 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA16650 for ; Mon, 12 Dec 2005 11:52:26 -0500 (EST) Received: from web30013.mail.mud.yahoo.com ([68.142.201.216]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1ElqwH-00036r-JB for ipsec@ietf.org; Mon, 12 Dec 2005 11:54:15 -0500 Received: (qmail 8701 invoked by uid 60001); 12 Dec 2005 16:53:12 -0000 Message-ID: <20051212165312.8699.qmail@web30013.mail.mud.yahoo.com> Date: Mon, 12 Dec 2005 08:53:12 -0800 (PST) From: "=?utf-8?q?Buồn=20qu=C3=A1?=" To: ipsec@ietf.org MIME-Version: 1.0 X-Spam-Score: 4.2 (++++) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Ipsec] How can i add new encryption algorithm into IPSec X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "=?utf-8?q?Buồn=20qu=C3=A1?=" List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0648156857==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0648156857== Content-Type: multipart/alternative; boundary="0-172218105-1134406392=:8050" --0-172218105-1134406392=:8050 Content-Type: text/plain; charset=us-ascii Hi folks ! somebody help me, i have trouble with IPSec. I have designed VPN over IPSec, and it has gone. Now i want to use other Encryption algorithm which it not in IPSec, but i don't way to add it, somebody please help me. Thanks --0-172218105-1134406392=:8050 Content-Type: text/html; charset=us-ascii
Hi folks !
 
    somebody help me, i have trouble with IPSec. I have designed VPN over IPSec, and it has gone. Now i want to use other Encryption algorithm which it not in IPSec, but i don't way to add it, somebody please help me.
 
Thanks
--0-172218105-1134406392=:8050-- --===============0648156857== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0648156857==-- From ipsec-bounces@ietf.org Tue Dec 13 04:44:18 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Em6hm-0007Od-4F; Tue, 13 Dec 2005 04:44:18 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Em6hk-0007OW-ER for ipsec@megatron.ietf.org; Tue, 13 Dec 2005 04:44:16 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA26943 for ; Tue, 13 Dec 2005 04:43:09 -0500 (EST) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=brahma.intotoind.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Em6iX-0000Kz-0E for ipsec@ietf.org; Tue, 13 Dec 2005 04:45:07 -0500 Received: from personal-1d8666.intotoinc.com (1mc136.intotoind.com [172.16.1.136]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id jBD9hpUk017090 for ; Tue, 13 Dec 2005 15:13:52 +0530 Message-Id: <6.2.1.2.0.20051213142755.02ce14c0@172.16.1.10> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Tue, 13 Dec 2005 14:59:46 +0530 To: ipsec@ietf.org From: Jyothi In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Subject: [Ipsec] empty CertReq payload 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 Hi, In IKEv1, if the peer receives the empty CERTREQ payload data, it can respond with its self certificate issued by any CA. Is the same concept valid in IKEv2 also?? Thanks Jyothi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Dec 14 14:34:35 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmcOZ-0000AD-Go; Wed, 14 Dec 2005 14:34:35 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmcOX-00009g-92 for ipsec@megatron.ietf.org; Wed, 14 Dec 2005 14:34:33 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14608 for ; Wed, 14 Dec 2005 14:33:34 -0500 (EST) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.43) id 1EmcPm-0005PF-5O for ipsec@ietf.org; Wed, 14 Dec 2005 14:35:51 -0500 Received: (qmail 9250 invoked by uid 0); 14 Dec 2005 19:34:23 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (141.156.162.215) by woodstock.binhost.com with SMTP; 14 Dec 2005 19:34:23 -0000 Message-Id: <7.0.0.10.2.20051214143152.05d9dd28@vigilsec.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.0.10 (Beta) Date: Wed, 14 Dec 2005 14:34:25 -0500 To: ipsec@ietf.org From: Russ Housley Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Spam-Score: 0.2 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Ipsec] Moving RFC 1829 (ESP DES-CBC transform) to Historic X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org draft-ietf-newtrk-decruft-experiment-02 describes the results of an experiment. Many Proposed Standards are identified that ought to be moved to Historic. The document says: One additional document, RFC 1829, the ESP DES-CBC transform, was suggested for Historic status, but in this case, the group consensus is that the community would benefit from a separate document describing the security implications of using this algorithm. Is anyone willing to write the proposed document? Russ _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Dec 14 15:57:08 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmdgS-0003iG-EK; Wed, 14 Dec 2005 15:57:08 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EmdgQ-0003es-N5 for ipsec@megatron.ietf.org; Wed, 14 Dec 2005 15:57:06 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23375 for ; Wed, 14 Dec 2005 15:55:45 -0500 (EST) Received: from pop-siberian.atl.sa.earthlink.net ([207.69.195.71]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmdhG-0008Dg-8t for ipsec@ietf.org; Wed, 14 Dec 2005 15:58:02 -0500 Received: from elwamui-ovcar.atl.sa.earthlink.net ([209.86.224.44]) by pop-siberian.atl.sa.earthlink.net with esmtp (Exim 3.36 #10) id 1EmdfX-00049G-00; Wed, 14 Dec 2005 15:56:11 -0500 Message-ID: <8374384.1134593770916.JavaMail.root@elwamui-ovcar.atl.sa.earthlink.net> Date: Wed, 14 Dec 2005 15:56:10 -0500 (EST) From: "Scott G. Kelly" To: Russ Housley , ipsec@ietf.org Subject: Re: [Ipsec] Moving RFC 1829 (ESP DES-CBC transform) to Historic Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: EarthLink Zoo Mail 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: e5ba305d0e64821bf3d8bc5d3bb07228 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: "Scott G. Kelly" List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Russ, I'd be willing to contribute to this effort. Scott -----Original Message----- From: Russ Housley Sent: Dec 14, 2005 2:34 PM To: ipsec@ietf.org Subject: [Ipsec] Moving RFC 1829 (ESP DES-CBC transform) to Historic draft-ietf-newtrk-decruft-experiment-02 describes the results of an experiment. Many Proposed Standards are identified that ought to be moved to Historic. The document says: One additional document, RFC 1829, the ESP DES-CBC transform, was suggested for Historic status, but in this case, the group consensus is that the community would benefit from a separate document describing the security implications of using this algorithm. Is anyone willing to write the proposed document? Russ _______________________________________________ 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 Dec 15 11:21:17 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emvr3-0004Pa-0y; Thu, 15 Dec 2005 11:21:17 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Emvr1-0004PG-Dv for ipsec@megatron.ietf.org; Thu, 15 Dec 2005 11:21:15 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA28795 for ; Thu, 15 Dec 2005 11:20:06 -0500 (EST) Received: from pix-telematicos.um.es ([155.54.212.254] helo=mail.um.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EmvsA-0008Ae-3e for ipsec@ietf.org; Thu, 15 Dec 2005 11:22:34 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 34DCC23C9FB for ; Thu, 15 Dec 2005 17:20:29 +0100 (CET) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 26299-01-35 for ; Thu, 15 Dec 2005 17:20:29 +0100 (CET) Received: from mistral.dif.um.es (mistral.dif.um.es [155.54.1.60]) by mail.um.es (Postfix) with ESMTP id 14CE023C9F4 for ; Thu, 15 Dec 2005 17:20:29 +0100 (CET) Received: from diffie (unknown [155.54.210.175]) by mistral.dif.um.es (Postfix) with ESMTP id 741581054023; Thu, 15 Dec 2005 17:15:10 +0100 (CET) From: Alejandro Perez Mendez To: ipsec@ietf.org Content-Type: text/plain Date: Thu, 15 Dec 2005 17:20:31 +0100 Message-Id: <1134663631.25793.6.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 0.0 (/) X-Scan-Signature: 30ac594df0e66ffa5a93eb4c48bcb014 Content-Transfer-Encoding: 7bit Cc: OpenIKEv2 Administrators Subject: [Ipsec] IKEv2: invalid SPI in DELETE payload X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 What is the preferred behaviour when a DELETE payload containig an unknown IPSEC SPI is received in IKEv2? Should be to send an empty DELETE payload response? Thanks. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Dec 15 22:44:01 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En6Vl-00032f-NT; Thu, 15 Dec 2005 22:44:01 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1En6Vk-00032L-1Z for ipsec@megatron.ietf.org; Thu, 15 Dec 2005 22:44:00 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA27615 for ; Thu, 15 Dec 2005 22:42:59 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1En6XE-0004nh-5C for ipsec@ietf.org; Thu, 15 Dec 2005 22:45:35 -0500 Received: from [10.20.30.249] (dsl2-63-249-109-231.cruzio.com [63.249.109.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBG3hnVB055680 for ; Thu, 15 Dec 2005 19:43:50 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 15 Dec 2005 19:43:41 -0800 To: IPsec WG From: The IESG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: de4f315c9369b71d7dd5909b42224370 Subject: [Ipsec] Last Call: 'The AES-CMAC-96 Algorithm and its use with IPsec' to Proposed Standard X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org The IESG has received a request from an individual submitter to consider the following document: - 'The AES-CMAC-96 Algorithm and its use with IPsec ' as a Proposed Standard This document makes a normative reference to draft-songlee-aes-cmac-03.txt, which is being considered for publication as an Informational RFC. While this normative reference could probably be avoided, easy access to the CMAC algorithm description is desirable. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-01-12. The file can be obtained via http://www.ietf.org/internet-drafts/draft-songlee-aes-cmac-96-03.txt _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Dec 16 05:14:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnCbz-0002o2-3V; Fri, 16 Dec 2005 05:14:51 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnCbw-0002nL-Ri for ipsec@megatron.ietf.org; Fri, 16 Dec 2005 05:14:49 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26877 for ; Fri, 16 Dec 2005 05:13:48 -0500 (EST) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnCdW-0007yb-1X for ipsec@ietf.org; Fri, 16 Dec 2005 05:16:27 -0500 Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jBGADZsQ018810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Dec 2005 12:13:35 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id jBGADYW5011053; Fri, 16 Dec 2005 12:13:34 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17314.37710.80744.878445@fireball.acr.fi> Date: Fri, 16 Dec 2005 12:13:34 +0200 From: Tero Kivinen To: Alejandro Perez Mendez Subject: [Ipsec] IKEv2: invalid SPI in DELETE payload In-Reply-To: <1134663631.25793.6.camel@localhost.localdomain> References: <1134663631.25793.6.camel@localhost.localdomain> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 10 min X-Total-Time: 10 min X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com, OpenIKEv2 Administrators X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Alejandro Perez Mendez writes: > Hi > What is the preferred behaviour when a DELETE payload containig an > unknown IPSEC SPI is received in IKEv2? This should not really happen in normal case, as IKEv2 keeps both ends in sync, but it can happen in case the other end creates IPsec child SA, and your response to that gets delayed, and before the other end receives that packet, you decide to delete the newly created IPsec SA (from your point of view it is ready, but for the other end it is still half-created, and he does not know what SPI you are going to use). > Should be to send an empty DELETE payload response? Hmmm... I think you need to send error notify as a response. If you simply ignore the notify then in the case I describe above both ends end up in different state (i.e. other end thinks it has SA and other end does not have that SA). What error notify to use is another question then. Most logical would be INVALID_SPI,but that is supposed to be used only when you receive ESP or AH packets with invalid SPI. The problem with other notifies like INVALID_SYNTAX is that the other end might consider that as fatal error, and delete the IKE SA because of it. I think we need a clarification text saying we can use INVALID_SPI in that case too. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Dec 16 06:45:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnE1K-0007sM-MO; Fri, 16 Dec 2005 06:45:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnE1G-0007nH-Cx; Fri, 16 Dec 2005 06:45:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA07042; Fri, 16 Dec 2005 06:44:03 -0500 (EST) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnE2q-00034r-It; Fri, 16 Dec 2005 06:46:42 -0500 Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jBGBio69004038 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Dec 2005 13:44:50 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id jBGBin1c005091; Fri, 16 Dec 2005 13:44:49 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17314.43185.63560.327253@fireball.acr.fi> Date: Fri, 16 Dec 2005 13:44:49 +0200 From: Tero Kivinen To: songlee@ee.washington.edu, jicheol.lee@samsung.com, radha@ee.washington.edu Subject: [Ipsec] Last Call: 'The AES-CMAC-96 Algorithm and its use with IPsec' to Proposed Standard In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 9 min X-Total-Time: 8 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 93238566e09e6e262849b4f805833007 Content-Transfer-Encoding: 7bit Cc: IPsec WG , iesg@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org The IESG writes: > - 'The AES-CMAC-96 Algorithm and its use with IPsec ' > as a Proposed Standard The IANA considerations section of this draft uses AES-CMAC-PRF-128 (probably cut & paste from PRF document), when it should use AUTH_AES_CMAC_96 (or similar). To fix this change: 8. IANA Consideration IANA should allocate a value for IKEv2 Transform Type 3 (Integrity Algorithm) to the AES-CMAC-PRF-128 algorithm when this document is published. to 8. IANA Consideration IANA should allocate a value for IKEv2 Transform Type 3 (Integrity Algorithm) to the AUTH_AES_CMAC_96 algorithm when this document is published. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Dec 16 08:16:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnFS2-0002Cv-HN; Fri, 16 Dec 2005 08:16:46 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnFS0-0002Cj-Cb for ipsec@megatron.ietf.org; Fri, 16 Dec 2005 08:16:44 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16618 for ; Fri, 16 Dec 2005 08:15:44 -0500 (EST) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnFTb-0006Op-AG for ipsec@ietf.org; Fri, 16 Dec 2005 08:18:24 -0500 Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jBGDGXWc003563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Dec 2005 15:16:34 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id jBGDGT0W005547; Fri, 16 Dec 2005 15:16:29 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17314.48685.551696.192990@fireball.acr.fi> Date: Fri, 16 Dec 2005 15:16:29 +0200 From: Tero Kivinen To: ipsec@ietf.org, songlee@u.washington.edu, jicheol.lee@samsung.com, radha@ee.washington.edu, housley@vigilsec.com X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 11 min X-Total-Time: 12 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 9466e0365fc95844abaf7c3f15a05c7d Content-Transfer-Encoding: 7bit Cc: Subject: [Ipsec] Comments to draft-songlee-aes-cmac-prf-128-01.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 The draft uses truncation to truncate the key if it is longer than 128 bits. This is not very well suited for the IKEv2 use. The PRF is used in IKEv2 with key (Ni | Nr), where the length of Ni and Nr is between 16 and 256 octects. This means that the keying material when calculating SKEYSEED of the IKE_SA (2.14) is always only Ni and the responder nonce does not affect to the value of the SKEYSEED at all. It would be better to use similar method than draft-hoffman-rfc3664bis-05.txt does, i.e: ---------------------------------------------------------------------- o If the key is 129 bits or longer, shorten it to exactly 128 bits by performing the steps in AES-XCBC-PRF-128 (that is, the algorithm described in this document). In that re-application of this algorithm, the key is 128 zero bits; the message is the too- long current key. ---------------------------------------------------------------------- Also the IANA consideration section needs to have a bit more text. I.e. something like: 6. IANA Consideration IANA should allocate a value for IKEv2 Transform Type 2 (Pseudo-random Function (PRF)) to the PRF_AES128_CMAC algorithm when this document is published. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Dec 16 15:51:44 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnMYK-0003Tb-Ph; Fri, 16 Dec 2005 15:51:44 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EnMYJ-0003TW-0G for ipsec@megatron.ietf.org; Fri, 16 Dec 2005 15:51:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12805 for ; Fri, 16 Dec 2005 15:50:42 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EnMZv-0006ab-Ci for ipsec@ietf.org; Fri, 16 Dec 2005 15:53:26 -0500 Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBGKpWg5082418 for ; Fri, 16 Dec 2005 12:51:33 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Fri, 16 Dec 2005 12:51:32 -0800 To: IPsec WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Subject: [Ipsec] Re: [saag] Structure of documents discussing protocols and hashes X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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. Thank you for all the response on the -00 draft. I have significantly revised it, and the -01 is available from . In this draft, Section 5 is all new, and it would be grand if folks could read it carefully. In it, I try to glean the basics from Eric and Steve's paper and come to conclusions about what should be done. I may have missed important parts (for that matter, so might they), and others might have different conclusions from what I got. Please let the lists know what you think. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Dec 19 02:20:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoFKB-0002mk-L9; Mon, 19 Dec 2005 02:20:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoFK9-0002mF-A5 for ipsec@megatron.ietf.org; Mon, 19 Dec 2005 02:20:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA28280 for ; Mon, 19 Dec 2005 02:19:41 -0500 (EST) Received: from 63-197-255-154.ded.pacbell.net ([63.197.255.154] helo=sinett.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoFMI-0000GB-HG for ipsec@ietf.org; Mon, 19 Dec 2005 02:22:59 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5.6944.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Sun, 18 Dec 2005 23:20:26 -0800 Message-ID: Thread-Topic: ESP Vs AH integrity Thread-Index: AcYEbWU5lFmZmoe5QlmfSRTaXjNSRw== From: "Vishwas Manral" To: "IPsec" X-Spam-Score: 0.1 (/) X-Scan-Signature: 3971661e40967acfc35f708dd5f33760 Subject: [Ipsec] ESP Vs AH integrity X-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="===============0465331251==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============0465331251== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C6046C.AEF95208" This is a multi-part message in MIME format. ------_=_NextPart_001_01C6046C.AEF95208 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Hi, =20 Various IPsec drafts state that: - The primary difference between the integrity provided by ESP and AH is the extent of the coverage. Specifically, ESP does not protect any IP header fields unless those fields are encapsulated by ESP. =20 I think one more difference between ESP integrity-only service and AH is that, in case of AH the packet after the AH can be further looked into by any middle-box while the ESP integrity only may not be. The ESP header does not have to say integrity only service in the packet itself. =20 Is my understanding correct? =20 Thanks, Vishwas =20 ------_=_NextPart_001_01C6046C.AEF95208 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable 
Hi,
 
Various =
IPsec drafts state that: -
   The primary difference between =
the integrity
   provided by ESP and AH is the =
extent of the coverage.  =
Specifically,
   ESP does not protect any IP =
header fields unless those fields are

      encapsulated by = ESP.

 

I think one more difference between ESP integrity-only service = and AH is that, in case of AH the packet after the AH can be further looked = into by any middle-box while the ESP integrity only may not be. The ESP header does = not have to say integrity only service in the packet = itself.

 

Is my understanding correct?

 

Thanks,

Vishwas

 

------_=_NextPart_001_01C6046C.AEF95208-- --===============0465331251== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0465331251==-- From ipsec-bounces@ietf.org Mon Dec 19 10:37:51 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoN5C-0000u5-Uf; Mon, 19 Dec 2005 10: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 1EoN5A-0000tt-SV for ipsec@megatron.ietf.org; Mon, 19 Dec 2005 10:37:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01496 for ; Mon, 19 Dec 2005 10:36:46 -0500 (EST) Received: from pix-telematicos.um.es ([155.54.212.254] helo=mail.um.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoN7H-0001Ra-CY for ipsec@ietf.org; Mon, 19 Dec 2005 10:40:07 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 7DFE91FAFE9 for ; Mon, 19 Dec 2005 09:26:35 +0100 (CET) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 20677-01-63 for ; Mon, 19 Dec 2005 09:26:35 +0100 (CET) Received: from mistral.dif.um.es (mistral.dif.um.es [155.54.1.60]) by mail.um.es (Postfix) with ESMTP id 4B1D91FAFE7 for ; Mon, 19 Dec 2005 09:26:30 +0100 (CET) Received: from diffie (unknown [155.54.210.175]) by mistral.dif.um.es (Postfix) with ESMTP id 6F81C1054023 for ; Mon, 19 Dec 2005 09:20:28 +0100 (CET) From: Alejandro Perez Mendez To: ipsec@ietf.org Content-Type: multipart/mixed; boundary="=-YpDcr6tryQsZURu82i4J" Date: Mon, 19 Dec 2005 09:26:30 +0100 Message-Id: <1134980790.30296.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es X-Spam-Score: 0.0 (/) X-Scan-Signature: 539f8b288ab42db633e5c7cf1c34fca1 Subject: [Ipsec] Problem with exchanges collisions X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --=-YpDcr6tryQsZURu82i4J Content-Type: text/plain Content-Transfer-Encoding: 7bit Hi, we have some problems when exchanges happen simultaeously. In order to understand a possible case we attach an image. It's a posible case in which extrange things may happen, a REKEY_IKE_SA exchange and a REKEY_CHILD_SA exchange at the same time. In this case peers lose the status sync. We know it is unusual to attach images but it is very difficult to explain in a textual format. Best regards! -- Alejandro Perez Mendez Pedro J. Fernandez Ruiz University of Murcia --=-YpDcr6tryQsZURu82i4J Content-Description: Content-Type: image/png Content-Disposition: attachment; filename=diagram.png Content-Transfer-Encoding: base64 iVBORw0KGgoAAAANSUhEUgAAA34AAAJmCAIAAACMucUBAAAACXBIWXMAAA7HAAAOxgEhiR43AAAA B3RJTUUH1QwTCBkrMNQzrAAAIABJREFUeNrs3Xt8E1Xi//+T9E4ppbVU5CqKXRBYLq2y2FrFclMQ 7FJZ+SkC6sIXQZdFFKQoW29QrLcCCt1dFFA+3O9Q7tBydaUVgQoCi9KLAlJoS+mNNvP7Y9bZbJKm aZqkmcnr+fDhg6TJZObkzDnvOWdmopMkSQBuQ6fTUScBgBYVWqWnCAAAAED0BAAAANETAAAAIHoC AACA6AkAAACiJwAAAED0BAAAANETAAAAIHoCAACA6AkAAACiJwAAAED0BAAAANETAAAAIHoCAACA 6AkAAACiJwAAAED0BAAAANETAAAAIHqivtKyhM4qiggAQFcCh/CmCDyzgRgf9T+twKJjkpXXmzcZ kiRRjADgycy7BroSED1R685vvYGoszWRF0KrAQD0I3QlIHrC2uFmfRsLKy0IrQYAeA5lxswh/Qhd CdETHJ7SagAA6EpA9ETDGgtntBS0GgBA6HRGV0I/QvSEWskzI4uOSSZXFNW559NqAACU3Ck37y7r SuhHiJ7QwkFq5LFxdb4lKyrNIYettBoAoLHc6cquRO5HBNNo2sV9PbVGvrPaomOSsydH6mw1AABq 70oaqx+hKyF6QjWNhTzJbuU1lQUlWVFp13f+29npk1YDANRIp9O5T1fC16E9TLh7Vu4UQpQcyvNq 5ld8ND9kwN1ObTIEp34CgApzpy2DnS7rSuhHiJ5w38ZC2HZyd/GhvJaju19ZmSMkIZx8PEmrAQDa y52u7Eo49VN7mHDXTmNhS3thqKwuPXk5/MkuUkV1+YVrLlg3SWLGBAA0lTtd3JUsOibRlRA9ocrG QghRmvVLk05h+iY+TSPvKDmS74LVS8vifB0AoCtpaFdC+iR6QpWKD+c1691aCBEU1arkaD4FAgBI y1JBV1LflYTb4lxPDzpOFUIUH8qtzCspmPcvIYTe18tQWa33c0Ud4KRPAHBbtlyiSlcCoifqrTK3 uKa06t4VCfIp4Rde212afalZnzau+XSaDABwQ/UdwmjcrgRET6ipvSg+nBfcp21Ax1D5YbM+bUqO 5NFeAADU0pUwiqEBnOvpSe3Fodxm0W2Vh83+0KbYtad7cr0RALgVO36yqNG7Eqgdo54e1F7cM+8x 44fBMe2CY9pRkgAAFXUlDHyqHaOeqqTeC/0Y+AQAN9GIv9IOoidUpr5XIwIAoBmMYhA9AQCAmnCb TDQWzvVUHzumSLKi0tztaJXTdACgEdkxe0ZXAqInbN0/KQQAAF0J3AET7jCV/vns8VGcQwMAmuWC 2Xa6EhA9NcLZFyRKkpS9Z40Ljp45QxwAGouzr1WlK4EVTLjjv6oqyrb+4+3cM9kUBQCArgRETzhL RdmN5LEPXMk7V11VSWkAAOhK4CRMuEMIISSD4frlPB9f/4CmwcxfAADoSuAkjHpCCCECmgZ/vL9I /vebwztdvvgDZQIAoCuBwzHqCQAAAKInAABwNH66HURPeCJuigEAANETAABoAYf3cE9cZgQAgAYT pyQxuQR3xKgnGsf4KJ0kcbIRADgsccqk39T2ykXHJH7iEkRPAADgxMSpGBdJsaExMeEOd2xJGRAF AOvtpPwPWksQPYGGMj4/iVYVAEicIHoCTk+ftLMAQEsIoidABgUAEidgb8WmQquuJdLGr1DUdoV7 nSd60hYDIHHavqjaWloNdCXjIrk2QJUY9VQZ+TxItTcZDbmzEuOgAEicdCWCa1KJnoDrU7hJe00M BUDiBIiegIsyKI04ABIn4Oa4pbwqk5aqf4jCqb9jpNxUWbnNMhUGgFslzvreAd5J1P6bRvwkHtET cLuATgYFQOKsDb9phMbChLtac5VmLnV3QVkpTb/JMwDg7MRJs+MMDHkSPQEVtBdkUAAkTpNWkVEM uB4T7mqlxjM+3WR+h7l4AE5KnO42q65JDHmqHaOecGm77FbtBeOgABzSsqm3AWHgE0RP0GSQQQGQ OGEZQ54awIQ7aC/+J4MyFw/AeuLU2Ky6ik7f4qp8bWDUU/VNhioGPlV3nMo4KACTxKnhpkAtXQm/ nKkNjHoCdbTIjIMCnpw4uXLITTDkqRmMenK06vTGQhvHqfxkPOBRidPT9nG6Erhu/+KL1FJD6W6t hh2NhboaF6bjARKnm29RfVtgN0yf8qmoNLOawYS7dg5Y3fBUcZflSJ0Rb2/vXr16ZWZmmv9JNmTI EOVP+/fvl/9tMBji4+PvuOOOixcvWnnX7NmzQ0NDi4uLlWKXP8hkOl6n0x08eNDuTzFWWVk5ZcqU li1benl5tWvXLjExsaqqyvgFiYmJOp3u66+/dmzhCCFycnIGDx4cGBjYpEmTxx577NSpU+xo6pKT kzNkyJDAwMCAgICBAweeOHGizipRZ60wqW/nz5/XWfLFF1/YWMPrXFVl9zF/RtnRzF9mvi3BwcFP P/30pUuXrLxMr9e3bdt2xowZ9drL7C5PN9zF3LAfkS8VIHdqCRPumrLomDQ+yi2OWV1/kJqSktK9 e3chRFVVVVpa2rBhw/Ly8po2bSqE+Nvf/talSxfllS1btjR/+4wZM3bu3JmZmdm+fXv5GYvvevnl l1NTU+fNmzdz5kz5+aSkpGHDhm3YsMFk1MQiGz/F2Ouvv75ixYpZs2bdeeedx48ff++994qKihYs WKC8YP369f7+/ps3b+7du7cDC+fChQsxMTF33nnnBx98oNPpFi5cGB0dnZ2dfffdd7OjqcLp06cf eOCBjh07pqSk+Pn5ffnllzExMdnZ2R07drReJaxXS5P61rJly9WrV8t/evLJJ5U3RkVF2VjD61xV h7QMkiTl5+fPnTv3oYceys7ODgwMNN5b//rXv65YseKNN96wey+zozzddheTZ96Fe0yjcSslTeJL 1Zq0LNHo6bMhjYV9A6U6nW7fvn0PP/yw/PDXX38NDw/PyMiIjY01+ZPFd33xxRfPP//8hg0bHn/8 cYsLNPbpp5/OnDnzxx9/DA4OPnDgwEMPPXTixImuXbuaLNn4oR2forjtttv+/ve///GPf5QffvHF F5MnTy4qKpIf/vDDD126dJk6deq2bduUgSKHFM6f/vSnH3744ciRIwEBAUKI8vLyPn36RERErFq1 ir1MFQYPHnzlypUDBw74+/sLIWpqamJjY7t27bpo0SIrVcJ6tbRe38zfaEsNr9eqmixTp9MdOHAg Jiamtg8yeb6wsLBz586//vqrkrEcspfZV56u2cXsnnpSe1cCd8aEu9aMi/zPjEljTZq4Q2MhN+U2 OnDgwLhx4z755BMlEVr3wgsvhISEzJs3TwiRlJQ0atQok9ypLFaZJOrbt69Op6vXpyhKS0vl/lg2 ZMiQ+fPnKw83bNjw4IMPjhgx4uTJkz/++KOjCufmzZvr169/4403lBcHBATMnDlzw4YNpaWl7GXu r7i4ePv27YmJiUrl8fLy+vDDDx966KGG7C921DfHrmoDQ1hYWNivv/563333mUzgOnYv08YupnQl jdWPkDs1jAl3bZIkqVGOWd2hsSgrK0tOTm7RokVk5H9uxZGRkXH16lXlBTExMcqs37///e9p06b1 6NFj0qRJJsup7V2+vr5vv/32pEmTevbsmZmZefbs2TpX6R//+Me0adMKCwtfeumll156ybiIrKyb bNiwYWPGjBkzZswjjzwSExMTFhb2zDPPKH9dv359QkJCjx49wsLCNm/e/PLLLzukcE6dOnXr1q0H H3zQ+L2xsbG3bt3KycmxMrMPN/H9998bDIbo6GjjJ3v37m3+3ZlXCSvVsr71zZYaXueqmiyhvvr2 7au0ikKI5cuXjx8/3uQ1DtzLbCzPixcvqmIXa5TL3gmdmscXrPUv2FWthqNO7rR7wt3kmcWLF48d O9bin9LT0wcNGiT/qUmTJhEREcePHzef1KvtXUIIg8HQs2fPc+fOvfDCC6mpqRbXR54HtPgpVs4H Nf4UZXTkgw8+2Lhx47fffuvl5TVkyJCFCxfefvvtQoiCgoI2bdqcPn26U6dOI0eO/PXXX3fv3u2Q wtm5c+fAgQOrq6u9vLyUP9XU1Hh7e+/YsWPAgAHsWW5ux44dgwYNMvkGbakSVmpFnfXN4uR4nTW8 vqsqfjuDRVidcFfeaPL8li1bhg4dajAYHLiX2VGeer3eNbuYQ671dOWpn+ROT8CEu8a5YPJdmRlp 3PYiJSVl165du3bt2rp1a0JCwoQJEwoKCpS+RzJi3PP9/ve/P3To0ODBgydNmnTr1i2T7q22d+n1 +hkzZpSXlycmJtqybiafYn5vaoufIgsMDHzzzTezsrIKCws///zzEydOvPDCC/KfNm7c2KxZs5Mn T65Zs6ZJkyYZGRnKpfcNLJxmzZoJIZRz3WTXr18XQoSGhrJbuT/5AheTqdvS0lJlvthKlaitVthe 32zcj2xcVZMl1BmSjO8Ab/6CoqKikJAQh+9l9S1Pde1iyh1UnNeVjItkkt2DMOHuEenT+MjbUUeu ShvkJi1FZGSkMrZx3333rVmzJicnp3Xr1tbf9c477zRp0uSjjz7q0qXLvHnzpkyZYuPHySMi8v/r ZOVTTMZBTQozPz9/8uTJK1eu9PLyCgkJeeaZZ1q0aPHEE0/If92wYUNJScmIESOU12/fvv1Pf/pT wwunS5cuPj4+mZmZ8fHxQogbN24IITIyMgICAiye2Ap307lzZ51O98033/Tr1095MjU1ddu2bfLd iOzYX2yvb45dVRvJE+t1Nkf/+te/5EvRHbuXecIu5oyuROlHxnPbTk/CqKcHBVDjI1f7jl+N3+vO PysXFhYmhDCZU7NInu265557pkyZMmvWrJ9//tkZ61Pnp9T2c52BgYHr1q07cuSI8WiQfF+Y69ev 79u3b8eOHcp7BwwYsGnTJocUTlBQ0NChQ999992KigohxJIlS/r37//WW2+NHDnS+GoMuK3Q0NBH HnkkOTm5pqZGfqakpCQtLW3w4MH2VQm765tjV9Xcgw8+KO8v8sii9RdfunRp2bJlJsHR4XuZtncx 867EvsRp0o+QOz0Ko56emEGVf9t4/OpuA5x1Mjm5yuQc/5CQkLi4OJO3JCYmLl269NVXX/3qq69s f1d91fkpu3fvlj9F2YRnnnkmISEhMTExIiLi3Llz77zzzqhRo4QQW7duDQoKUi6hEEIMHTp05syZ t27d8vHxaXjhzJ49Oyoq6sEHHxw/fryfn9+pU6du3ry5ZMkS9iC1eP/99x944IH+/fuPGjWqurp6 /vz5er3+xRdfrLNKWKwVv/zyi331zZb9yPZVlRmvhnKup/EH+fr6Dh06VP53VlZWdXW1fF/POXPm tG7desyYMcZLCwkJefrppx24l9lSnnFxcWrfxcx/W7jOcVDVdSVw+hEMPJn7VBL7Pk6YnU3VrFmz 9PR0i5sWGRlp8V3Lli2zMnaivEu2b98+K6sq/vfmSnZ/islr2rZtO3PmzMrKSkmShg8fPnbsWONX 5ubmCiH27t3rkMKRJOn48eP9+/f38/MLCAiIj49/6aWXWrVqdfnyZfYXtTh69GhsbKyvr29QUNDI kSPz8/PrrBK11Qpb6puw4bxM8xpu+6oqCzF+Rt7RTD7ltttuM1+BoKCgp5566ueffzb/9LKyspde eiksLEz+NaP67mV2lKfLdjFXNuDkDdiIU3rhdgOW1Mk6R1Maq4i2bdv26KOPWv/FJkBj1V7Vuxgt Ktxxp6ZSguhJZwxQyWlRAdfgXE9AfczPsqJ3AYkTANETABkUIHECIHoCZFCAxAmA6AmADAoSJwCi JwAyKEDiBED0BEAGBYkTANETABkUJE5KAwDREyCDEg5A4gRA9ARABgWJEwDRE4DnZFAyBEicAIie AFyUQUkVIHECIHoCaIQYSs4ANQEA0RMAGRQkTgBETwBkUJA4AYDoCYAMChInAKInADIoSJwAiJ4A QAYlcQIA0RMAGRQkTgBETwAgg5I4AYDoCYAMSuIEAKInADIoSJwAiJ4A4PQMSjwicQIgegKAizIo gYnECYDoCQCNEEOJUCROAERPACCDkjgBgOgJgAxK4gQAoicAkEFJnABA9ARABiVxAgDREwA8PoOS OAEQPQGADEriBACiJwCoOYOSOAEQPQGADEriBACiJwCoOYOSOAEQPQHAszKo65MfiRMAiJ4APDSD uiwLkjgBgOgJAM6djidxAgDREwCcm0FJnABA9AQA52ZQEicAED0BwLkZlMQJAERPAHBuBiVxAkBD 6CkCALAjg1IsAGAHRj0BoFa1ZU0yKAAQPQHAuYlTwTgoABA9AcC5iZMMCgBETwBwdeK0JYMSQwGA 6AkAjkycVjKoYCgUAIieAEicLouDTMcDANETAInT1cigAED0BEDiJIMCANETALSVOMmgAED0BEDi JIMCANETALSeOMmgAIieAEDiJIMCANETALSeOMmgADyBniIAoJbEKZN+4znbrmyyUgjUB8AhrUpK Sor5YW19VVRUyO8tLS01PlAcMWJEv379ioqKdP9r+vTpJku4fPny0KFDAwICmjZtmpCQcPnyZfn5 Cxcu6HS6lStXWvzc5OTkgwcPmj+/d+/e+fPnmz/fvHlzi8up7fna1Pf1RE8AJE4yKAAhhPj4448r KyudseRPPvnk66+/XrFihbe3txDipJHJkyebvHjChAnh4eHZ2dkHDhyoqqoaM2aM/Hx6enpISMiO HTss5t0tW7ZER0dfvny5X79+vr6+kZGRp0+fFkI8/PDDq1atunXrlslbzD/XPvJyWrdubWerzvQN 3C1nUCchmGKuf0FRVqBFtaN8HnvsseHDhz/33HMNKa6KioqAgABJkkpLS4OCgiRJOnz48KBBg/bt 2xcZGak8aWUJ/v7+hYWFgYGBQojCwsJWrVrJgXjw4MGxsbHz5s3Ly8szOdRcvnx5Tk7Ou+++O2rU qNtvv3369OkLFizYvXv3gQMHhBBTp06Njo6Oj4+3Zf2bN29eVFRU3622712CUU8A7tYTMMZZL5IR hkKB+nr99dfff/99g8Fg/OSSJUtatmzZvHnzhQsXCiH69u27a9cuIUR0dPTs2bOFEElJSampqbUt 89dffx0xYkRqampkZKSNqxEYGJiRkSG3eKGhocXFxUKI8vLyI0eOTJw4sby8PCcnx+QtGzdu7Nu3 rxBi//79U6dODQsLe+21144ePSr/dcCAAWvWrDEPi0KINm3ajB8/PiAgwHhSftKkScbPmJSA/K6k pKQhQ4bIy4mLiysuLu7Spcs333zTs2dPHx+fiIiIPXv21LvZAhodddJjv3daJMoTtKiNUj4xMTHr 169XHp49e7Z169ZZWVknT55s165dbm7ujBkzkpOTq6urw8PDExISJEkaPHjwsWPHlOWUl5fL771x 44YQol+/fkKIo0ePyn+VnzSecC8vLzdZk3nz5un1+vbt248bNy49Pd1gMEiSlJ6eHhcXJ0lSfHx8 SkqKyVs6dOiQn58vSdKBAwfk1584caJNmzbyXwsKCu666y6TtwQHB0uSpNfrP/vss/3797ds2VIp h48++ujYsWN33HGHxRKQJMnPz2/06NHZ2dnKcuT/9+zZc9u2bSUlJevXr+/UqZMtxc6oJwDGODU7 FMo4KGDLwGdycrLS/qxfv3706NG9evXq2rVrQkLCnj17oqOjs7Ozz549269fvzNnzkiSdObMme7d u9e2wPLy8ldeeeW1114zbtO6GTl//rzJWyZNmvTTTz8lJiZevXp16NChs2bNEkKkp6f3799fHnbd uXOnyVsKCgpatGghhIiJidHpdCdOnBg+fLj8RiFEixYtCgoKLK6el5fXCy+8EBsbK2di+ZkJEybI 5wZYLAEhhMFgWLhwYc+ePU2WVlVVdfHixfLy8mHDhu3evZtRT3CMDsbkQJnTosJa+RgMhu7du2dk ZMgPX375ZX9//+DffPDBB9euXYuIiPjyyy9TU1NjYmK+++47eTCytlHPX3755fr16yEhIZs2bVKe tL4m69atU/59+PDh0NBQSZI6duyo7Ln+/v5lZWUmKy8PdhoMhpSUlDZt2shjt7Kamhrjo3rjUU/5 /8b/aNasmfEz5iVg/GKT5Rw/fnz48OGhoaG9evXavXs3o54AGOME46BAHU3T9OnTk5OT5YfBwcEz ZswoKioqKirKysoaOXJkSEiIn59fRkZGVFTUfffdl5aWFhMTY2WB8lmSM2bMmDZtWnV1tS3rMHbs 2KtXryrjo2VlZefOnSsuLj5x4oQ8R9++ffvMzEzjtwQFBcmRd8GCBZs3b/7222+feOIJ5a83b94M Dg62vQSMH5qXgJX3/vjjj6tXr75y5UpSUpJ8tVadiJ4ASJxkUMCjJSQknD17Vv73oEGDli5dev78 +XPnzg0ePFi+xWafPn3Wrl3bvXv3++67b9myZdHR0XUuc+LEiTdu3Pj888/lh6eMmE+Fx8fHP/vs s999992ZM2cmT57cv3//9PT0QYMGdevWrWvXrl27dh04cKDJLZYiIiIuXrwoSdLcuXM/+uijioqK /Pz8/Px8+a95eXkRERH2lYbFEjBXU1NjMBiSkpJWrVpVXl5eXV1t6/0+GW8H00Nghpdvim+KFtXD yyctLU15OGfOnObNmzdv3lyea5YkacmSJd26dZMk6fz583q9vqSkxMqEu/L84sWLW7ZseenSJZPo 9fzzz5usSVFR0YgRIwICApo0aRIfH3/p0qWBAwcuX75cecGWLVvuvfde47dMmzZt8eLFP//8s8Vc t3Tp0mnTptk44W7+D/MSMJ9w79at2/3333/o0KFOnTrp9fquXbseOXLElmLnjl9wuxEy6qTav0Gl +aM0+O5Aiwon+f7779944421a9da/OvIkSOnT59u5VqohquoqKisrLR9Wl/BhDsAx/RwzKqrHXPx gIrIg6DXr183/1NJScmNGzecmjuFEPKlSPb0F/QQ4BgdDfm+lNRCafD9ghYVrnT8+PGamhrzG9cf P368uro6KirKTasllRI0lCCRgG+cFhVwDW+KAAD5A9Yp3zg/GQ+A6AmAxAlXZ1AqBgD7cJkRgFoT J1cOwXoM5bIkwFEyMzN79erl7e39u9/9bsOGDfKTpaWlxnuW8rCiokL+h8kLlGdkYWFhqamp5p91 +fLloUOHBgQENG3aNCEhQblz54ULF3Q63cqVKy2uYXJy8sGDBy2+cu/evfPnzyd6AiBxggwKqMAP P/zw6KOPDhky5OjRo6+88sro0aO//fbbhiwwLy8vNzd36dKlb7311tatW03+OmHChPDw8Ozs7AMH DlRVVY0ZM0Z+Pj09PSQkxOTe9bKKiootW7Yo99I3eeXDDz+8atWqW7du2dTL0K/A3XIPdbKxSl6J EZQGqE60qHClP//5z15eXgsXLpQfJiUlXb58+dNPPy0tLQ0KClK+ROVhRUVFQECAJEkmLzB+jfzw s88+W79+/c6dO40/zt/fv7CwMDAwUAhRWFjYqlWryspKIcTgwYNjY2PnzZuXl5dncgy5fPnynJyc d999V35o/sqpU6dGR0fHx8fXubGMegKe3jMxxgmHYxwUqJc9e/Y888wzysOpU6fOmjXLIUseMGDA 4cOHTdr2wMDAjIwM+cnQ0NDi4mIhRHl5+ZEjRyZOnFheXp6Tk2OynI0bN/bt21f+t8VXDhgwYM2a NbasEtETIHGSOEEGBRpTbm5ux44djaPh7bffbt5iBwUF1XfJbdu2vXnzZmlpqfGTSUlJjz/+eIcO HcaPH79jxw4/Pz8hREZGRq9evZo2bfrQQw+Zz7l/8803nTt3lv9t8ZVdu3Y9evQo0RMAiRNkUMDd 6fV6vb7WSHbyN19//bUdu54QwsvLy/jJSZMm/fTTT4mJiVevXh06dKg8wpqent6/f38hRN++fU0m 6IUQBQUFLVq0kP9t8ZUtWrQoKCiwqSei74G7ZSPqpDNK1bgNAqiWtKhwKx06dFi5cuX9998vPzx8 +PCmTZvmzJnT8HM9z58/37t378LCQuOPW79+vXJS5pEjR4YMGVJYWHjPPfecP39eftLf3//atWsB AQHGdclgMMi7rcVXGgwGb29vg8FQd87m+wY03Oswxgm3xTgooOjbt++qVauUh0uXLm3SpIlDlpye nh4bG2vy5NixY69evSr/u1u3bmVlZefOnSsuLj5x4oQ8vNq+ffvMzEzjtwQFBZWXlwshanvlzZs3 bfxJd24pD2gwcSpdO6UBVWRQqi483CuvvHL//feHh4fHxcXt3bt3xYoVp06dsv3tyot9fHxat24t hMjPz5ckKScnJykpyfw+nfHx8c8+++zs2bP9/PxSUlL69++fnp4+aNCgbt26yS8YOHDgjh07Bg4c qLwlIiLi4sWLnTt3ru2VeXl5ERERtqwto56AdhInY5xQewZlHBSeqUuXLuvWrVu6dGnv3r1XrFiR np7epk0b29/e7TdKWGzbtm27du1GjRo1a9asuLg4k9d//PHHQUFBffr0iYyMvHbt2t///vdt27Y9 +uijygsGDBhgcqVRv3795KuIantlVlaWcgl8Hb0V/RPSssT4KJ0tYxKuyU/UyfqWmOu/JsDF1Zsa 7v4tqlt1JR7bhzrP999//8Ybb6xdu7a2F4wcOXL69Ondu3evc1FMuJM4hRBi0TGJ1p/ECbgbfjJe XYcHNnYl2vgGPa0PvffeeyVJun79ekhIiPlfS0pKbty4YUvuFIx6kjjr+3blvU6qOYx6kjgB9gL3 b1GVb6Eh/Ygav0Tbo3aj9KFOdfz48ZqamsjISIt/qq6ujoqKInrCYXuLy/Yfoid9LcB+4bYtakMS p6qjmMduuDMw4e4prbOj9hbz/Covn6afnhVwMS6Npythw4mecMfGwuE7jMX9hwBK4gTIoITOhncl 7vPdeeyGEz1hJ/mcTmfvM56885A4ATKoJ7RLLutH5K7ETfoRj91woifc+ljNw3ceEidABiV3Oqkf adyvzHjDrd+brbvDAAAgAElEQVQ4yWTN1b7hRE/Yw3iws+E7jB1LIH2SOAEyqJa6EtdrxGk0ixse eWxcnW/MikpT9YYTPeGwfabhO4wdS/CcQzcSJ0AG1Woz1Vi506QrcfFvmtS54ZUFJaeGrbjrvbiQ AXc7dcM1XEWJnppi/SC1ITuMoezWt7Gf/6fSBPu3T3yw+SMdOHQjcQJkUO01Vo0eOhslfdq44SWH 8rya+RUfzXde9NR8H0r09KCD1IbvMN22PS0MUnHmxdzkQ837dhB1zcbLv8Xsyc06fRtABiV3Njx9 OvvbsX3Diw/ltRzd/crKHCEJoXN6FdVkH6qn9dFMY1HnbiPvMCVH84W91dg3PNC3ZdOw+M63CssM t2rqfH1a1n/2HA/8RmTSb6ilgDtnUJnOCLnTrdKnU7sS2zfcUFldevJy+JNdpIrq8gvXnL3hWu1D iZ6e0lg4bIcxSEUHLgbe20Lv62XjnqMcs5I4AagigxrHULoSd+C8EFavDS/N+qVJpzB9E5+mkXeU HMlX9YY3IibcPYXJDhNwd6gdC1EuJ7oruR9FatxyKf0WpQFoJoayg7tb+mz0hrr4cF6z3q2FEEFR rYoP5N7+zO/df8OJnmi0wzWH7DA9M8dKBunXdad/XvBNSNxdtr9Rk3dcokMCyKCe1pU0+nfR8K7E +Hus74YXH8qtzCspmPcvIYTe18tQWa3381bLhhM94WoO2WH0TXyEEOEjuhSkfi1V1ehsm3PXWPok cQJkUC01AmrJncLR43/y92j77Usrc4trSqvuXZEgX1104bXdpdmXmvVpo7oNJ3rCFe2FY3cY6ZZB p9cJb72nlTaJE4BgLr5ROWMUQ/nxFOtdavHhvOA+bQM6/ud0tWZ92pQcyXNN9BTamjwkenoER+0w VVduCkm6uu5MYI+WOn29z3pW45QBXQsADWdQFQ15uoD1DFp8KPe2IRHKw2Z/aJOf+nUbSo3o6Tnq 1V44aoc5+dhXQgj/dsF3ze1vxzqraMqAxAnAozJo40Y9u5top66YSSd7z7zHjB8Gx7QLjmnnyuLS zMAn0dMjNHyH0TfxseUXNdW+59BtAPCcDNroQ552f/r4qHr3I/VKq4wEEz3hdu2F9sqTxAnAYzOo 6jhpFMP9O1ZtDHwSPUHipEsA4HEZVHt3i9Rw4tQYoqcqA5Oq95NGP2gjcQIgg9p+UyGtdiW2b77y cyr0oURPuGKHcatdzjxB2r77kTgBuGcGtaMpox1rYHpz0otB9GTvsmeHSf989oYFM+T3uu0uZ/sJ 4yROAG6eQe1oqdx/3Mu4K3HbxO9AVRVl6Z/P/lf6V9cu5TYLaxnV/0+Pj/+bf5Mg6jnRU/WcPdsu SVL2njUuyMR2t5s2thokTgBqjKG2t10NGf7URldix72inbThNdW3Ppk08Pzxg0IIH7+AoisFu7/6 8Fx2xqv/POjj6+8OG+5W9OzwMD5o27BgRu6ZbHdO3taf0f1G+g1fKwB1ZVCZ0prVqw30qK7Efa6U 2r/60/PHD0b0emjOtrz5h8reXHGi1d1dL57O2rdinrY33D6MekIIISrKbiSPfeBK3rnqqkoV5U7z P5E1AWgmg9rYvrnPAJgquhJnOLz5c51ON/atpSHhbYQQrTt2e/7tL9/+/3r8a/vyAc++SmU2wagn hBBCMhiuX87z8fUPaBrshsfQ5of+5s0uY5wAtJpBlXFQ+xpJuhKnqqm+VXD+ZJuIHqEt//tbLW0i uje7reUvP52mAptj1BNCCBHQNPjj/UXyv98c3unyxR/cKnfaODYAANrOoNbbw0Yf/nTnrsR5bpZc kwyG29vdY/K8j6+foaaGekv0hMrYctysjd+0BQDaQzVqGnzbnG15vv5NjJ8svvrLtUu54e0iKB+i JzTVyAIALDaeVgIov2PkWHovb/kUT4VkMKz+cIokSZFxCZSPhRKjCNAo5PsrkTsBwMVH72r/HaOG lIkLNvxmybXPpsZ/s3NFWOu7+o+aSlU0x6gn3LF1YMIIAEzUt2HkGN71fji2b/Gbo4quFLS6u+uk j7c0CWpOmRA9oY7mlZslAYDdR+/mbSmc3nMZDFv+nrT1H29LkhQ7/P8lTE7xCwikWIieUN/BPRkU AOqbOK2/ctExyTPn3OUs7qQNX/XhX/euSG0e3nr0m4vv/cMAKiTRE25nfJRNs+pkUABwSOJUjIsU 4yk4h/ouc9PeFantO0e+lJoeFNKCAiF6QiNHq2RQAKAldENb0pICmgZP/GgzuZPoCTIoAJA44USF P/+UeyY7etjzPn4BZTeKTP7KlUZET5BBAYDECYe5eCZLCHFo4z8Pbfyn+V898z5WRE+QQQGAxAmn uH45n0KoX8WmQquuJdLGIVRtlxk55KaetNcASJxWWlTNdyUe24eqAr9mpDKSJI2P0rHP1FlKMt1v qDkA3D9xypQWzHmfJd9fyQO7EvpQoifg9KROBgVA4jQxLpKCR6PhXE94SgZVWnmTZwCgURInbRE8 E6OeqkxRqp4vaNyZAsZBATRu4nT9GKdFap9zt7sroQ8legJkUAAkTldjzh1ET3jQ0SoZFACJE3Zr 4MifevtQDQx5Ej3VSr1Hq+6825BBAXhU4tTG5d4e1YdqA5cZqZWckPiZBCeVrdJ/mDwDAFYSJy2G CzhkCEONfag2hjyJnmC3IYMC8NzEySgGiJ6gySCDAiBxwjIHDmGoqw/VzJAn0RPsNmRQAB6dOBnF gItxmZHqmwxVnCSupcM1peS5JgnwqMSp4WvV1XLFt8O7EvpQoidABgVA4nQ1VVzx7bGXpWtvw5lw 10L0cee5knGRQm61PeGLUPoqk2cAqC5xetpe7LFdCX0o0RP27zlCCDfceTwkd5JBARIn6dNJxkfp xjvzS3Hn9KnJPpQJd+00GW54so72TvGs75fCXDygisTJbw4prZZ79iPO/lLc86RPrfahOsZjtCQt S4yPcotDN3kftqN2aXuUlHFQgP3RxdtoXzss3GMazcXZy602XMM1k1FPTRkX6RYXKrrmIFWlIwqM gwKNnsYY46yzpXKfrsRjN1zLR0TsdRo+mm+UQ7cGNhaedm4o46AA+5pTt7qBDXJj9SON+0157Ia7 BqOeHLOq+yBVA98U46CAUzMEY5wNaaAaqx9p3G/KYzfcRXsl+6Hmm13XHLo56ljNA6+INy8Bpe2j AgPsR43eorpyGs2txi88dsOdjZsraf+Y1dk7j4dMELjyK6PvBEic7tYoeWBX4rEb7mxMuHtEqyHP HTh8+kBephonCHJycoYMGRIYGBgQEDBw4MATJ04o/ZbC29u7V69emZmZxr2aiSFDhhgvNjExUafT ff3110KI8+fP6yz54osvbFmU8sWdOnVKeY3Jqu7fv9+k01We0el0Bw8etPgy820JDg5++umnL126 ZP6yysrKKVOmtGzZ0svLq127domJiVVVVbVtsvVPsb086/xQNDCc2VfJjeuSwWCIj4+/4447Ll68 WNtbZs+eHRoaWlxcrCz8wIEDOp3uyJEj5qtkXl2NP6LOXUZ5sqKi4q9//evtt99usfJYr67WC8fK CnhIjXVSVyIv0J27EvpQh2PUk8NWjztKO3369AMPPNCxY8eUlBQ/P78vv/wyJiYmOzu7Y8eOQoiU lJTu3bsLIaqqqtLS0oYNG5aXl9e0aVP5vX/729+6dOmiLKply5bGS16/fr2/v//mzZt79+7dsmXL 1atXy88/+eSTyhujoqJsWZTxqvbq1euFF17w8/N7/vnnd+7c6aiSl7dUkqT8/Py5c+c+9NBD2dnZ gYGBxq95/fXXV6xYMWvWrDvvvPP48ePvvfdeUVHRggULLG6ylU+pV3nW+aFwyFdvXyWXzZgxY+fO nZmZme3bt6/tLS+//HJqauq8efNmzpwpP5+UlDRs2LA+ffrYspImH2HxU8zHOKdMmWKl8tRZXa0X Tm0l41E11oFdibr6EfpQx8d5eBTzarDomGTlP1dWGxfUycceeywqKqq8vFx+WF1d/cADD4wbN07+ 9H379imvvHLlihAiIyNDWTfjv5o4c+aMl5fXtGnTunXrZr5RJm+0vqg6V9XiF2G8THmEycoHmTx/ 9erVFi1azJkzx+RloaGha9euVR5+/vnnwcHBtmyyxU+xsTytfygavovZV8mVP33++ed6vX7Tpk11 vmXBggUhISFFRUWSJGVmZup0upMnT1pcskl1NfkI8+pdW0NkpfLUWV2tF46VzXTnGuvs5tr2fsS8 K6EP9ViMenruCKjJNFO9Xq9excXF27dvX7t2rb+/v/yMl5fXhx9++O9//9v8xQEBAbYvecOGDQ8+ +OCIESOSk5N//PHHDh06OG9VFy1apNPp9u3b56gz22677bZnn3127dq106ZNM36+tLRU+XQhxJAh Q7y9ve3eZBvL0/qHwrHqVcnljDhu3LhPPvnk8ccfr/PFL7zwwgcffCAPfCYlJY0aNapr1652f0Tf vn3rrO1WKo8deyg1tl5dSZ036NBMV+LJfahD0KDDs3aM77//3mAwREdHGz/Zu3dv8wm4srKy5OTk Fi1aREZGKk9mZGRcvXpVeRgTE6NMuq1fvz4hIaFHjx5hYWGbN29++eWXra+JlUXZuKoZGRnKnL7c 8PXt29fur7JXr16LFi0yeXLYsGFjxowZM2bMI488EhMTExYW9swzzyh/rdcm216e1j8UDlTfSv7v f/972rRpPXr0mDRpki2V2dfX9+233540aVLPnj0zMzPPnj1b5yqZf4TSqSvz3WvWrLG4y1ivsfXd Q80Lp7bNpMYSsAiX9S4vwK0mMpy6/O3btwshqqurbZxGWbx4sZW/pqeny3/Kz88XQpw+fVqSpKee eiouLq7OCffaFmX3qsqfYjx0ZPuEuyRJmzdvNr73oay0tDQpKalXr17yVRdPPPHEpUuXbNnkhpSn lQ+FM+YKbazkQogmTZr06NHDpPJYr8w1NTW///3vAwICXnrpJSurpFRX5SNMOilbdhkrlceW6mq9 cKysgDvXWHp5uGMrRBHAo6KnfCGtfPKZ4saNGxcuXJA/PSUlZdeuXbt27dq6dWtCQoKfn19+fr4t 57Q1a9Zs1apVq1evfu6557y9vY0/Qth1rmedq2plmSZ51JbouWzZstDQ0NpW5tq1a8uWLbvrrruG DBliyyYrn2Jfedb2oXDILmbflyKE+MMf/nDz5s3Bgwd36dKlqqrKxu9xxYoVQggracw4eiqMP0Ky +fTo2iqPLdXVeuHYsgJuWGOJniB6Ao3cUBYWFup0ul27dhk/+e6770ZHR0u1XGSwY8eOOju//v37 m4yIrFixooHRs16rKtV+mZHFKQ7zt7/00kvyfL0iLy9v+PDhxsOu27dv9/f3t2WTLX6KLeVp/UPh kF3MvkouhNi9e7ckSWfPnvXx8fnggw9srMzyYLz1VVJY/AgbdxkrlceW6mq9cGpbATevsURPuCHu 6wnPEhoa+sgjjyQnJ9fU1MjPlJSUpKWlDR482PzFYWFhQgiDwWB9mdevX9+3b5/SeUuSNGDAgE2b NrlyVa1Q+ksrv9V56dKlZcuW/elPfzJ+MjAwcN26dcZ3YSwtLZXvvmTfJttSnlY+FM5gYyWXeXl5 CSHuueeeKVOmzJo16+eff27gpysVUjlSashH1FZ57N5DqbGAM3CZETzO+++//8ADD/Tv33/UqFHV 1dXz58/X6/UvvviixX7R5BmT6wxCQkLi4uK2bt0aFBSkXH4rhBg6dOjMmTNv3brl4+NT22pYXJTd q2qF8kGrV6/29fUdOnSock2SPKSan58/Z86c1q1bjxkzxviNISEhTz/9dEJCQmJiYkRExLlz5955 551Ro0YJIezbZBvLs7YPhTPY+KWYvCYxMXHp0qWvvvrqV199ZeNbLH6oZHSvROsfYcun1FZj7auu 5itmcQWs7CYALGPgFx414S47evRobGysr69vUFDQyJEjrZzo1qxZM+PLLExERkZKkjR8+PCxY8ca vys3N1cIsXfvXisT7hYX1ZBVFXVNuAshbrvtNosr8NRTT/3888/mn15WVvbSSy+FhYXp9fq2bdvO nDmzsrLSlk1uSHnW9qFwxoS7jV+K+RuXLVsm/vfKttoqszLhXlu/I2q5Kk75CNt3GYuVx8bqar1w rKyAO9dYenm4IQ/6uXqoZQyGOtmIQ18UPqhdtKiAUzHhDuC/mYCUABInAKInADIoSJwAiJ4AyKAA 9QQA0RMAGRQkTgBETwBkUJA4ARA9AYAMChInAKInADIoSJwAiJ4AQAYlcQIA0RMAGRQkTgBETwBk UJA4ARA9AYAMSuIEAKInADIoSJwAiJ4AQAYlcQIA0RMAGRSUMACiJwCQQUmcAIieAEAGJXECANET ABkUJE4ARE8AIIOSOAGA6AmADEriBACiJwCQQUmcAIieAEAGJXECANETADwtg5I4ARA9AYAMSuIE AKInAKg5g5I4ARA9AYAMSuIEAKInAKg5g5I4ARA9AYAMSuIEAKInAKg5g5I4AYDoCQDOzaAkTgAg egKAczMoiRMAiJ4A4NwMSuIEAKInADg3g5I4AYDoCQDOzaAkTgCwg54iAICGZFCKBQBsx6gnANSt tqxJBgUAoicAODdxKhgHBQCiJwA4N3GSQQGA6AkArk6cZFAAIHoCgKsTJxkUAIieAODqxEkGBQAr XHdzJZ1Ol5KSYt7o11dFRYX83tLSUuN2fMSIEf369SsqKtL9r+nTp5ss4fLly0OHDg0ICGjatGlC QsLly5fl5y9cuKDT6VauXGnxc5OTkw8ePGj+/N69e+fPn2/+fPPmzS0up7bna1Pf1wOosy2SSb9x 2Ucrn6isA18HAKKnE3388ceVlZXOWPInn3zy9ddfr1ixwtvbWwhx0sjkyZNNXjxhwoTw8PDs7OwD Bw5UVVWNGTNGfj49PT0kJGTHjh0W8+6WLVuio6MvX77cr18/X1/fyMjI06dPCyEefvjhVatW3bp1 y+Qt5p9rH3k5rVu3prICKk2cZFAA+G9r7LL2V6fTPfbYY8OHD3/uuefkh/Z9dEVFRUBAgCRJpaWl QUFBkiQdPnx40KBB+/bti4yMVJ60sgR/f//CwsLAwEAhRGFhYatWreRAPHjw4NjY2Hnz5uXl5Zn0 BMuXL8/JyXn33XdHjRp1++23T58+fcGCBbt37z5w4IAQYurUqdHR0fHx8basf/PmzYuKiuq71fa9 S6X5gLlIOLZGKWmP9YQH1n9qFNyNS0c9X3/99ffff99gMBg/uWTJkpYtWzZv3nzhwoVCiL59++7a tUsIER0dPXv2bCFEUlJSampqbcv89ddfR4wYkZqaGhkZaeNqBAYGZmRkyHtjaGhocXGxEKK8vPzI kSMTJ04sLy/PyckxecvGjRv79u0rhNi/f//UqVPDwsJee+21o0ePyn8dMGDAmjVrzMOiEKJNmzbj x48PCAgwnpSfNGmS8TMmJSC/KykpaciQIfJy4uLiiouLu3Tp8s033/Ts2dPHxyciImLPnj1UX8BK j+s+Y5y2YBwUgKeQXEX+rJiYmPXr1ysPz54927p166ysrJMnT7Zr1y43N3fGjBnJycnV1dXh4eEJ CQmSJA0ePPjYsWPKcsrLy+X33rhxQwjRr18/IcTRo0flv8pPGk+4l5eXm6zJvHnz9Hp9+/btx40b l56ebjAYJElKT0+Pi4uTJCk+Pj4lJcXkLR06dMjPz5ck6cCBA/LrT5w40aZNG/mvBQUFd911l8lb goODJUnS6/WfffbZ/v37W7ZsqZTDRx99dOzYsTvuuMNiCUiS5OfnN3r06OzsbGU58v979uy5bdu2 kpKS9evXd+rUSdIiV9ZJaLL+uLhlY1tAiwrUi6t/w/31119PTk5WWtX169ePHj26V69eXbt2TUhI 2LNnT3R0dHZ29tmzZ/v163fmzBlJks6cOdO9e/faFlheXv7KK6+89tprxi11NyPnz583ecukSZN+ +umnxMTEq1evDh06dNasWUKI9PT0/v37y8OuO3fuNHlLQUFBixYthBAxMTE6ne7EiRPDhw+X3yiE aNGiRUFBgcXV8/LyeuGFF2JjY+VMLD8zYcIE+dwAiyUghDAYDAsXLuzZs6fJ0qqqqi5evFheXj5s 2LDdu3dz4ASodIyTcVAAjHq66NjLYDB07949IyNDfvjyyy/7+/sH/+aDDz64du1aRETEl19+mZqa GhMT891338mDkbWNev7yyy/Xr18PCQnZtGmT8qT1NVm3bp3y78OHD4eGhkqS1LFjR6VM/P39y8rK TFZeHuw0GAwpKSlt2rSRx25lNTU1xn2e8ain/H/jfzRr1sz4GfMSMH6xyXKOHz8+fPjw0NDQXr16 7d69m2N0MKLjUeOCjIOCFhWMetozODF9+vTk5GT5YXBw8IwZM4qKioqKirKyskaOHBkSEuLn55eR kREVFXXfffelpaXFxMRYWaB8luSMGTOmTZtWXV1tyzqMHTv26tWryvhoWVnZuXPniouLT5w4Ic/R t2/fPjMz0/gtQUFBcuRdsGDB5s2bv/322yeeeEL5682bN4ODg20vAeOH5iVg5b0//vjj6tWrr1y5 kpSUJF+tBTDGKXnMVRSMgwLQAL3rPzIhIeHs2bPyvwcNGrR06dLz58+fO3du8ODB8i02+/Tps3bt 2u7du993333Lli2Ljo6uc5kTJ068cePG559/Lj88ZcR8Kjw+Pv7ZZ5/97rvvzpw5M3ny5P79+6en pw8aNKhbt25du3bt2rXrwIEDTW6xFBERcfHiRUmS5s6d+9FHH1VUVOTn5+fn58t/zcvLi4iIsK80 LJaAuZqaGoPBkJSUtGrVqvLy8urqau73CRIns1VkUAAqbsJcOeyflpamPJwzZ07z5s2bN28uzzVL krRkyZJu3bpJknT+/Hm9Xl9SUmJlwl15fvHixS1btrx06ZLJBj7//PMma1JUVDRixIiAgIAmTZrE x8dfunRp4MCBy5cvV16wZcuWe++91/gt06ZNW7x48c8//2yx9JYuXTpt2jQbJ9zN/2FeAuYT7t26 dbv//vsPHTrUqVMnvV7ftWvXI0eOMD0EZplBKYEWFerCHb9s8v3337/xxhtr1661+NeRI0dOnz7d yrVQDVdRUVFZWWn7tL6qR7aokxDc55JyAy0qNEpPEdhCHgS9fv26+Z9KSkpu3Ljh1NwphJAvReKL gCf0lMyqO2Qii7l4AG7aztOy2+j48eM1NTXmN64/fvx4dXV1VFQURcQxOhryvSvJidKgbEGLCqIn QEMJUhGlDVpUoKG8KQIAZCBPoJQ25Q+A6AmAxAkyKADtU/dlRpmZmb169fL29v7d7363YcMG+cnS 0lLjM+uVhxUVFfI/TF6gPCMLCwtLTU01/6zLly8PHTo0ICCgadOmCQkJyg04L1y4oNPpVq5caeM6 JycnHzx40Mb3mqzYunXrhBB79+6dP38+dRcqSpxcOeS2GZRrkgAQPW31ww8/PProo0OGDDl69Ogr r7wyevTob7/9tiELzMvLy83NXbp06VtvvbV161aTv06YMCE8PDw7O/vAgQNVVVVjxoyRn09PTw8J CTG5BX1tKioqtmzZotwk38b35uXlXbx4MSkpaeLEiZIkPfzww6tWrbp16xbVFyROkEEBqKx3UG9/ 8Oc//9nLy2vhwoXyw6SkpMuXL3/66aelpaVBQUHKdikPKyoqAgICJEkyeYHxa+SHn3322fr163fu 3Gn8cf7+/oWFhYGBgUKIwsLCVq1aVVZWCiEGDx4cGxs7b968vLy8Otvr5cuX5+TkvPvuu/LDOt9r vGJVVVV+fn7l5eX+/v5Tp06Njo6Oj4/XZF4ho6j9G1TSDKXB9whaVMCEikc99+zZ88wzzygPp06d OmvWLIcsecCAAYcPHzbZXQMDAzMyMuQnQ0NDi4uLhRDl5eVHjhyZOHFieXl5Tk6O/MpvvvmmZ8+e Pj4+ERERe/bsMV7Ixo0b+/btK//b4ntrYzAYNm/efN999/n7+8truGbNGqov3KqHY4xTSxgHBUD0 NJWbm9uxY0fjaHj77bebd4RBQUH1XXLbtm1v3rxZWlpq/GRSUtLjjz/eoUOH8ePH79ixw8/PTwiR kZHRq1evpk2bPvTQQ8q8+fjx4997771r167NnTt30qRJxgv55ptvOnfuLP/b4ntr69S9vLwSEhJe e+01+ZmuXbsePXqU6gsSJ8igAIierlp1vV6vr3X9T/7m66+/tqOpFUJ4eXkZPzlp0qSffvopMTHx 6tWrQ4cOlUdY09PT+/fvL4To27evMkFfVVV18eLF8vLyYcOG7d6923ghBQUFLVq0kP9t8b0W3bhx o6ioKDk5OTExUX6mRYsWBQUFVF+QOEEGBaCyHkS9fUaHDh1Wrlx5//33yw8PHz68adOmOXPmNPxc z/Pnz/fu3buwsND449avX6+cW3nkyJEhQ4YUFhbec88958+fl5/09/e/du1aQEDAd9999/bbb+/b t+/OO++cO3duXFyccYdtMBjkJtvie0220XjFysrKAgMDKyoq/Pz8DAaDt7e3wWDQZKYhx7jzt2N8 eAbqA/WBFhWoLxWPevbt23fVqlXKw6VLlzZp0sQhS05PT4+NjTV5cuzYsVevXpX/3a1bt7KysnPn zhUXF584cUIeXm3fvn1mZqYQ4scff1y9evWVK1eSkpKee+4544UEBQWVl5cLIWp7rxVVVVVeXl7e 3t5CiJs3b/KT7nBl78UYJ8wxDgrADiq+pfwrr7xy//33h4eHx8XF7d27d8WKFadOnbL97cqLfXx8 WrduLYTIz8+XJCknJycpKcn8Xpvx8fHPPvvs7Nmz/fz8UlJS+vfvn56ePmjQoG7duskvGDhw4I4d OwYOHJiUlFRZWTl48ODq6urmzZsbLyQiIuLixYudO3e2+N4+ffosXrx48uTJJh8tr1haWlp0dLR8 GkBeXlR7dSwAACAASURBVF5ERATVF85OnErCoDRgPYNSZwDU+7BVjbZv396lSxcvL69evXrJ16RL knTjxg3j7VIeysONyjOK9u3bGz8j31Le/LOKiopGjBgREBDQpEmT+Pj4S5cuDRw4cPny5coLtmzZ cu+990qSdOjQoU6dOun1+q5dux45csR4IdOmTVu8eLEkSRbf++OPP5p8I8YrFhERceLECfn5pUuX Tps2TdIitddJbXwFGmgcQC0CLSrcE2eBuNT333//xhtvrF27trYXTJ06NSUlpc7ljBw5cvr06d27 d9fkSBt1kjFOUK9Aiwqt0lMEriQPi16/ft3iX69evRoWFlbnQkpKSm7cuKHJ3IlG6Zk4jxPOw/mg AEz7HXoaFzt+/HhNTU1kZGRDllBdXR0VFcUxOhpSzkoyoDRA3dNwaVPOIHoCNJT0+gC1kRYVHsqb IrCvrdRwc0l/wHcKuADXxQNET9SaMhWLjklWXqC6dtP6Nlr8K30DiRMggwIgejq+tzZOmRaZv0At 7aaN22jxr/QNJE6ADAqA6OmwDrvOxGlLVpMX5W6Npu2pWr3bSAXmSwEZFADRU/uh02I+c59w5vAN dMNtJHHyLYAMCoDo6XGh0w3DmU6nc9IGEkBJnAAZFADRs/FDp5uEM0/YRhInQAalWAA1dWQeuNO6 LJCZGBfpunDWuNvYkA3kLnQkToC9w4GFQ7GA6Nn4+6EcyMZH2fp7blYCnB0LaXg4s30bG0UDN5CG kj4VYH9RY/RMy6qjT9Tq9+KxG243b0/bCY0zWeSxcXW+JSsqzfoL6ruQtCwh/5yxk+pi4+ZOeQMX HZOYfKcHBVyMufjGba9EXVNtGvtejBOnjRtOnfS46NnomcwF6dN9tnHRMckF47skTgBk0MZtr2zv dCz+Xomqf4rFxm23+GM0nlwnvT1nJ7FeRSoLSk4NW3HXe3EhA+62Y/mGslvfxn7+nzIN9m+f+GDz RzpYT5/y0GBtlc+OUUP3yZ3OTtgkTgBkULUkTm1EMYdsuMX87YF10iOiZ1pW3a8pOZTn1cyv+Gi+ fdFT1m3b08IgFWdezE0+1LxvB6Gzv3I7PFu7bcnTgtMXAmRQtTRZDu9o3P9nSjx2w4meDTI+qu5Y Vnwor+Xo7ldW5ghJCDvjn/ANDxRChMV3zp17yHCrRu/rVWfNkwcF7U6c7pw7TbaRhpueDyCDEjqt RzG36i88dsOJng6oOnXWG0NldenJy3fNjru85LvyC9cC7g61//MMUtGBi4H3tqgzd4rfLpDXcO4k fZI4ATKo5vtQTfYXHrvhRE8XVZ3SrF+adArTN/FpGnlHyZF8u6OnciX7Xcn96kycatw32KlInAAZ 1DNzp0PuSGh7fyHc8lcAbSwE+0rAc24O4+0h+4x1xYfzmvVuLYQIimpVfCD39md+b98n9swcKxmk X9ed/nnBNyFxdzU8cdoyIOrAIOvUFOtR6ZM+DCCDqpp85yCTTsEhdyS0vTNqlC7D4obXqxAaUgIe Mvnu6b/h/p/oeSi3Mq+kYN6/hBB6Xy9DZbXez56S0TfxEUKEj+hSkPq1VFWj+985d+OqbGNetF75 1DLk6VEjBPRYABlUG01Zbf1Lfe/ooqIBi3qd3NnAG+PUueEarnjeGt5zbK09ucU1pVX3rkiQry66 8Nru0uxLzfq0sb/ZumXQ6XXCW1/nkY1w6JilKhp0TR7MkTgBMqin9Z4Nv6OLu6XP+o7mOOTGONZD glaHPxn1FMWH84L7tA3o+J/zO5v1aVNyJM++6Fl15aaQpKvrzgT2aKnT1/uMkHrFUDUOeWrsXksk ToAM6pm5U9T/ji4NTJ/OLnM7ulSH3BinzoqnyfSp9/CdRwhRfCi3WXRb5WGzP7QpPppv3+eefOyr k4OXX9/173avRdt9lKPtHNPwO0m5Q+2SSb+hYwY8J4PKlHbAY7tOIep3R5cGpk+n9h125E75xjjh T3aRKqrLL1xz0oopv8yisf2IUU9xz7zHjB8Gx7QLjmlX7wjfxMeW86/re4TtwP3ETah34JMxTgDm rbRmWob6dis23tHF4SHMTX6A2lE3xmnEDW9EeloQt6LMLMB9mmPGOAFYyaAaHge1omfm2B77x7R+ uffPC75xzSe61ciF8Y1xSuydKVXjhjuEBkc9NX/dt9o3UBV3WWKME0B9M6h6Ww87uhXrd3RxXiE7 tvuwuz911I1xGmvDiZ6NxiG3H3PIQlSXzDQc60mcADwqgzZkOMOWO7o4kJuM/zn8xjhq2XCipwMS npssBCROAGRQdbHjji6O6rsdNTpj/5Cn426M0ygb3ui0dq6n8yajqyrKNn72RuLQuybc7z3tsTar P3qlouyGljZQkf75bA+52yjncQJwTQZ12/NB7e5TGnhHF1Vz4I1xPBNXuNukpvrWJ5MGnj9+UAjh 4xdQdKVg91cfnsvOePWfB318/TXWRGbvWaOiw1b7mlrtjUAAUEUDq4FWyLF3dGmsHqQh4zgOuTGO 6rpOR1Yh2gJb7F/96fnjByN6PTRnW978Q2VvrjjR6u6uF09n7VsxT0ubWVVRtmHBjNwz2Zr8Ehnj BOA+GdQdxkH5NWYQPRvKeefhHt78uU6nG/vW0pDwNkKI1h27Pf/2l0KIf21fro2iqyi7kfSnbn99 JHT7F3PUFSVJnAA8KoN61C2catPAGxGqN3Nr4w6MmppwHx/llMpUU32r4PzJNhE9Qlv+d0S9TUT3 Zre1/OWn086rW64MSZLBcP1yno+vv4+vf8XNErXc+ciW15A1Aagig9ar7Wp4H6G9u0WC6KkdN0uu SQbD7e3uMXnex9fPUFOjjW0MaBr88f4i+d9vDu90+eIPKs2dJE4AHpJBG/jL5nYM1jj8ZoINYfcY TQOHPBu9EDRwxifRs25Ng2+bsy3P17+J8ZPFV3+5dik3vF0E5dO4oVPeA0mcADwhg5o3gy5LIZwV SiE4CpcZ2VBGXt4h4W0Cm/33F1olg2H1h1MkSYqMS6B8GnLc1sDcadzych4nAK1mUOV80NraQDc8 /89z7tMnc5M7MKoCo571drPk2pK/jf0uc1NY67v6j5pKgThbnU0qiROAh2TQOg/CbW9XnTqA55r7 9Nnx85JO2nAX34FR7b+ryahn/fxwbN9bT/3+u8xNre7uOmXh3iZBzSmTxs2dNr4GADTfHrrJ8KfL 7tPnPldKufgOjGq/RIzoafNBhsGwedGsjybEFV0piB3+/6Z/cfS2O9pTLE5tZMmUAOCMI3YnUeN9 +hxC83dgdCwm3G216sO/7l2R2jy89eg3F9/7hwEUSAONj7I2WUDoBIAGpk/XT8iq6z59juL6OzAS PT3Cd5mb9q5Ibd858qXU9KCQFhSI09svTt8EALU1jCq6T58DecIdGImejWBLWlJA0+CJH20mdwIA AAV3YPTo6LnomOSMHzQq/Pmn3DPZ0cOe9/ELKLtRZPJXZ1xpZH0yGgAAu/E7Ro4l34HR+BnuwOhB 0XNcpBjvhMVePJMlhDi08Z+HNv7TYt6lGgEA1MJJPzrt/lzz0+3cgdGzoqeTXL+cTyEAAADrfji2 b/Gbo4quFLS6u+ukj7dwB0aPiJ7OmHOPG/mXuJF/cZMNlG8k69TjtrfWnmHHAACgHr2zwbDl70lb //G2JEmxw/9fwuQUv4BAisUird3Xc1wk36kKcDIrADQWeYzGE9Oh5MQNX/XhX7f8/a3gFq3+Mn/H 069/Ru70oOgJAACsYIzG4ZQ7MM786lvu/E30VB9GBAEAUBHuwFgvGrzMyAVnQ7KBZGsAAERj3IGR 6AliGQAAHoo7MNYXE+6q5NRzpZ2Kc4wAAFrCHRjrS5ujniqdkvaEIU+djmFdANA+z7lPn1vdgVEV GPVUcbxW3cAnQ54A4A60cX8lO8Zr1Dtn2MANJ3qSzDRYk2zBkCcAMBAAD8eoJ/EaAACA6OlJycwT hjy5eB8A3Ifa59zt7lPUPmqjgc5U46OeqqhhDalGatmFyJ0A4FaYcwfR00PTZ8MzmfunT3InAMB9 uhX1Dnxqoz/1iHM93XZawVF1yJ33InInALgnLhgA0dNZPGFawT1bECZ0AACO5ZARDTXGbs0M5XjK D2m6203mx0U6/k5DnrCNAAANdxzwBHqP2sHc5BDHeZnMfbZxfJSO3AkAcHjn4qieRV0Dn1o6e82z 7uvpDvXM2WOBjb6N4yL/s4eQOwGAntGx/Ytn0tiGe3vgPqbT6YQQrp9fkEPneCGcnckafRsJnQCg up7R/afdNX+imss2vHHpPXMfkw/yXHmcp0xAu6b2KNvoyoJlkh0A4CQMeWqGt8dWYjkhuWB0UM5/ jRLIXDb82YjbCABwVH/htuN/Tr1GwjM3vBExRiWcF0DdJ5A5L4A6fBsZNwWAxmpR3TOEuaAzdc8N 1+o5bN7smcIJI6DuNgro8A2U9wfBSCcAaKs3dLcQ5poru91z7FOrYzGMMFn4puV/2FEFlXMr3blU lQ20YxuNTx510jYy6gkAjduiNtaFqo2VO91zw4V2B3cY9bRw6GMe0cyzmsUreFRRS4xX0nwblQ1U xjVVt4EAgAZ2E2lZYnxUI48Cuv5Olh674a4+IiJM2HFIpOEQZhw3G2UbGfUEADdpURtrDrrRx/w8 dsNdg1HPeh8SsYEAAA/p8lwfwtxhzM9jN5zoCQAAGj+ECVedAek+8ctjN5zoCQAAGjmECedfguOG c80eu+FETwAAoM0c5v53hnFeAPXYX2MhegIAAFfnMHUFL8cGUA//CUCiJwAAsDOHKeoMZCY3JVRj 8LK44XVuu/ndGD38il6iJwAAsDOHKSzeDFuTect8Q6xvO7eOIXoCAACnBzK2HRbpKQIAAAAQPQEA AED0BAAAAIieAAAAIHoCAACA6AkAAAAQPQEAAED0BAAAAIieAAAAIHoCAACA6AkAAAAQPQEAAED0 BAAAAIieAAAAIHoCAACA6AkAAAAQPQEAAED0BAAAAIieAAAAIHoCAACA6AkAAAAQPQEAAKAZOkmS KAUAAAC4AKOeAAAAIHoCAACA6AkAAAAQPQEAAED0BAAAANGTIgAAAADREwAAAERPAAAAgOgJAAAA oicAAACIngAAAADREwAAAERPAAAAgOgJAAAAoicAAACIngAAAADREwAAAERPAAAAgOgJAAAAoicA AAA8mzdF4HA6nY5CAABHkSSJQgCInqChBAAO5gHUDxPuAAAAIHoCAACA6AkAAAAQPQEAAED0BAAA ANGTIgAAAADRE/ZLyxI6qygiAADgetzXUyPM0+SiY1K9Xs+9SAEAANETNoVO60HTnPnr5eUQQAEA ANETDgud1sMoARQAABA94cTQSQAFAABET9SaO50ROgmgAADA2bjCXU3k69adnTuNA+iiYxKXwwMA AEdh1FM1nDfJXmcA1el0jH0CAICGY9RTBZTBTtfnTuP0yRcBAAAaiFFPd9dYg521pU+GPwEAANFT s7mz0UOncfqUV4n0CQAA7MOEO7mzfiSJyXcAAED0JHe6RFoW6RMAABA9yZ2kTwAAQPSE9qRlUQYA AIDoqX5uPuSpYOATAAAQPeEiDHwCAACip7qpZchTxq3mAQAA0RMAAABET1ilriFPGQOfAACA6AkA AACiJ2qhxiFPGQOfAACA6AkAAACiJ8yod8hTxsAnAAAgenqoG9euvBwbND5K96/ty03+dLPk2l8e Ch4fpTvzrz0UFAAAIHqioYJCwweMelUIsXnRrJrqW8Z/2rFkbsXNki59Bna6P46CAgAARE+P44zZ 9v5PTwkKDb+Sd/7IliXKkyWFl/auSBVCxE+a7fCtYM4dAAAQPT2UX5OmQ154Uwix5e9vVVdVyk9u W/zercry3o8+3fZ3Pd0wf7dp00b+d1hYmMUUO23aNJ1OFxwcfObMGeM3WrF9+/baPnHLli0DBgwI DQ3V6/WhoaEDBw5cs2aNJFk+BnjxxRflNaztBfbp16+flbxu/a8N2S7zggoMDHziiScuXLhQ25dS pytXrgQFBel0uuXLTU/zuHbtWnBwsE6n27OH0zwAgOgJjYqJ/3NY67uuX87LXLdICHHtUu6BdYu8 vH2GTnhbjZuzZs2auXPn6nS6//u//+vUqVMDl/bOO+88/vjju3btun79uiRJ169f37lz55NPPjl2 7FiDwWDyYkmStmzZIoQoKCg4deqU87ZxzJgxc+fOddl2GSsrK9u4cWN0dPSVK1fs++jw8PBXX31V CDFr1qxbt/7nNI+5c+eWlJQMHDgwLo7TPACA6AmN8vbxfWLiu0KI9MXvVZbf3PL3t6pvVT385Ith rTqoblu+//77sWPHCiFmz5792GOPmfw1ODj4dC1iYmLMl5aVlfXGG2/4+vq+/fbbOTk5v/7667ff fjt16lS9Xr9kyZJ//vOfJq8/depUXl6er6+vECI9Pd2B2/XHP/7xL3/5i/JwyZIlO3futHtp9dqu kJCQ67+5evVqRkZG586dL126lJycbPcKTJkyJTw8/Pz580uW/Pc0j0uXLqWmpsrfHXslAIDoqWVR /Ua0/V3PkmuXV30w+cjmL/ybBD36XKLqtqKkpOSPf/xjaWnpU0899dprr1kI2d7enWrRtGlT89en paUJIebNmzdz5sx77703LCysR48e77///meffSaEWLRokcnrt27dKoR48cUXhRBWZvDt8OKLL378 8ceOWlq9tkuv1zf/zW233RYbGytnU3l81z5NmzZ98803hRBvvfVWZeV/TvN47733ysvLn3766Z49 e7JLAgCInlqm0+uHv5wshDi44R8GQ83A0a8FhbRQ1yZI/3979x4WVbX4f3ztmQFBBEZgULmomfr9 gp1AmckAzfulzPPzaKc0M8XrCZ7Qh8cL5C1F8dKvzCx69NHCTvrtedTSk/4wLygczcvIQEZefiSm jkokDoaAATPz+2P/mkMDM6KAgL1ff8GevTdrLdj7+bDWXmtbrVOmTLl48WLv3r23bNnSKDOZsrOz hRDjx4+32z516lQvL69z587Zbd+7d68kSYmJiV5eXseOHSstLW2ZbfWg9bKj0+kkSbp8+XJDyjBj xoxu3bpdu3ZNTrpXr17duHGji4tLcnIy1yMAgOj5+AvpO6xH7/5CiLae6iET5rS68q9evfqrr77S aDS7d+9u27Zto5zT1iFnR6VSJScn23Ws3r59+8SJE1qttkOHDgMGDKiqqnI+VyYmJkaSpCNHjsjf WiwWefJNTk6ObZ/g4OCnn35a1JhItHnzZvmLw4cPS5L04Ycf2nY2m82LFy/WaDSurq79+/eveZ6G 1MvhHUHRoHuCq6vrypUrhRApKSllZWXLly+vrKyMjY194oknuBgBAETPx1/F3Ts3L58XQpSXlhRd y2/Sn9Xo6ysdPHhw0aJFKpVq165dnTt3bqzT9ujRQwixZs2a2jNv4uPj33777Zpb9u/fb7FYRo4c KYQYPHiwuN+Ye1RUlBDCFhDz8/Pv3r0rhDAYDPKWwsJCo9EYHR1d8ygfH5+wsDAhhIeHR1hYmJ+f n+2jpKSkFStWlJSUWCyWY8eODRkyxNFMoAeqV216vd5qtXbr1q2Bzfvyyy/37t37559/njNnTlpa mqen58KFC7kSAQBEzz+Fbz5be7fkloe3rxDiqw+TWlHJr1y5MmHCBIvFotPp6pwtZFNdXX2hLjdv 3qxz/5kzZwohUlJSevbsGR8fv3fvXidj6PKzjyNGjBBCyBO009PTnSyxJEdPW9C0ZVDbljNnzggh 7KLn2LFjc3NzhRDPPvtsbm5uzUHz9evXb9mypby8vLS0dNKkSSaT6ZNPPml4vWoym83Z2dmzZs0S QowaNaqh9xSFQp6rtHnzZrPZPH/+fI1Gw5UIACB6Pv5Kiq4f2rZOoVAmfHzY08f/hxPfXNBntJbC jx07tri4WAhx4sQJ5/PK79y5E1KXpKS6o/bIkSNTU1M9PDwuXbq0YcOG0aNH+/j4DBgwIDU1tbKy 0i7U7t+/39vbu2/fvkKIXr16aTSaq1evnj9/3lFhQkJC1Gq1LXHm5OT4+Pj06dPHefR0IiEhYerU qS4uLu7u7vIkHvkMDamXEKK4uNi2qKdKpdJqtd9//71Go5k7d26dJ8/JyQl3TI6tNsOGDevfv78Q Qq1Wz5kzhysRAED0/FP418alVb9V9BszPahn2PNTkoQQX21IbNxF0WuapZUa8eQGgyEyMlIOW3Pn zq2urm7Eor7xxhtGo3Hbtm2TJ08OCAiorq7OysqKi4sbNGhQeXm5bbeTJ0+aTKahQ4eqVCohhEKh GDRokHA65q5QKCIjIy9cuFBWVibXIiIiQqfTfffdd3IVzpw506lTp65du9azqBMmTLB9LR9VUlLS wHrVJknSwIEDMzMzO3ToUOcOZWVl3zl26dIlu38G5HReUlKSn5/PlQgAIHo+/m5cyvv2609dXN1G TV8shHhu3Cy1JuCnc3rD4Z2tovxBQUFffvnlggULAgICzp8/L68cVCdfX19rXdLS0pycX61Wv/rq q2lpaUajMTc3NyEhoU2bNt9++23NRd3l0fbQ0FDbIL78PKXzXtjo6GiLxXL27Fmr1ZqTk6PVanU6 XUVFxcWLF61Wq16vj46Orv9DsfJPlMkJ2Ln61Ev8cV1Pk8lUXl5+5MiRkJAQR6ft16+f1bFDhw7V 3Hnt2rW3bt3y9fUVQjjqewYAED3xWPlyQ6LVYhk8Pl7tHyiEcGnj/sK0RUKI3akLzdVVLb/8e/bs 6dixY9u2beV1eZYuXeqkt++BVFdX1+xDlSQpLCzs3Xfflfsyv/jiC9tH8oqeycnJtkF8efp2VlaW 3KlZJ9tMI6PRWFxcLPd6CiEMBoPRaCwqKqr/aLsQws3NrdHrJf64rqdara7/T7mv69evr1u3TqlU Hj582N/f/5tvvsnIyOB6BAAQPR9n/zf76PfH9rm38x4xZYFtY/T/mubbqUvR1fzje7a0/Cr06dNH /mLy5Mm9evW6detWSkpKo5zZ3d09IiKi9vaBAwcGBQXZxo6vXLni6LWZlZWVtuWTanvmmWeUSqXB YJCf+NRqtaGhoe7u7gaD4UEf9JQTZOPWq6ktXbq0oqJi+vTpYWFhcpdnYmITPuYBACB6oplZLZZd 6+cLIYa/Ps/Dy8e2XeXiOmrGEiHE15uW/VZR1lqqo1Qq5cHi9evXFxQUNPyEfn5+BQUFda6CaTab XVxc5K/lLs8333zTbnBZTsBOxtw9PDzCw8MNBoPBYPD19e3cubNKpZJnGun1end39/Dw8KZoqHrW 6+HUc5pRXl7ep59+6ubmtnjxYiHErFmzAgIC9Hr9zp07uTABAETPx1P2oR0/ndN7+vgPGT/b7qPI Ua/7B3f/tbjw8P+834pq9Pzzzw8cOLCysnLBggUNP1tUVNTdu3ffe+89u+1ZWVk3b96UF3u3Rc8X X3zRbjd5oSXnSyxFR0fn5eWdOnVKq9XK3ZY6nS4nJ+f06dN9+/ZtYApsYL0eTj2nGSUmJloslvj4 +MDAQCGEu7v7okWLhBALFy6sqqri2gQAED0fQ9rhr2w8Y/3fB35u09b+DeYKpSr5q/yNZ6wvtKqX uUuS9M477wghdu7ceezYMbtPHa3reeHCBZPJVPts8vpBb731VlxcnMFgKC4uLigoSE1NHTNmjPh9 dczy8vKMjAwPD48BAwbYHR4eHq7RaC5fvuxk7nZUVFRVVdXBgwdtI+A6na60tDQzM9P5aLuTR0jv qz71emj1mWZ09OjRffv2eXt71/wPYdq0aV26dMnPz5ffEQ8AIHqimVmt1llaqbXXonFXVqojT2u1 8jJDCQkJdm/rcbSuZ0hIyLZt22qfKjIycvXq1UKI1NTUiIgIPz+/J598Mi4uzmQyvfbaa1OmTBFC ZGRk3Lt3b/jw4W3atLG/ZhSK4cOHC6dj7vJMI7PZrNVqbdFTTslOomdgYODJkyf79evn/IVJjtSn Xk3HYrHI7+qcN2+ej89/HvNwdXWVV8hatmxZQ4I1AIDoCTxSK1eudHFx0ev127dvb+CpFixYkJ6e PmzYMG9vbyGEt7f34MGDt2/f/tlnn8kvMXc02i6T36vpJHoGBwcHBwcLIWy9nt27d1er1ZIkRUZG OjoqISFBCHH8+HGj0dhE9Wo6O3bs0Ov1/v7+s2fbP+bx+uuvd+/evbCw8P333+fPGAD+5CRmnjZ+ m0oP3KqSJG0807p/EU3d6/kncePGjaqqqqCgIKVSSWsAD3dHBUD05Eb5mKdPcicAoieA+mDAHQAA AETPP5nWO9mILk8AAED0BAAAANETDrTGjk+6PAEAANETAAAARE841bo6PunyBAAARE88CjMjaAMA AED0bOVaS8cni+0BAACiJx4FujwBAADR8zHRwjs+Z0bQ5QkAAIiepE9yJwAAIHrisUmf5E4AAPDQ VDRBC0+fkiQJITaeaf60J+dgcicAAHho9Hq2gvS58Uzzd3/KS3iSOwEAQEMweNoEbdo0Q9LN2P3J 0vEAHrM7KoDmQq9nq9Fc3Z/kTgAA0Gj/T5IqWt3/6JIkPZq+Tx7uBPDY31EBPGJMM2p9HsHcI0In AAAgeuI/6VM0zdOfhE4AAED0RNMGUHmheEInAABoUjxD0wRt2hxPJsnBsSbnYbT2dCX+EgBwRwXQ 1Oj1fEzUvjXXDqMETQAAQPTEIwqjAAAAzYt1PQEAAED0BAAAANETAAAAIHoCAACA6AkAAACiJ00A AAAAoicAAACIngAAAADREwAAAERPAAAAED0BAAAAoicAAACIngAAAADREwAAAERPAAAAED0BAAAA oicAAACIngAAAADREwAAAERPAAAAED0BAACAR0BFE7QukiQ13cmtVistDAAAiJ74j4gzM5vitNna TbQtAABoUgy4AwAAgOgJAAAAoicAAABA9AQAAADREwAAAERPmgAAAABET/zpnDt3LiYmJjAwUKlU daXPsAAADrVJREFU+vj4/PWvfz169GjNHfz8/JysbCpJkp+fX81vg4KC6nms7ZCalEplz549V69e XVlZed/C7927d/jw4T4+PgqFwsfHZ8SIETt37nSyVGpsbKxcwkZcTnXo0KFO6uj80wbWS6rFw8Nj zJgxBQUFdrvV/KU4V1RU5OnpKUnS9u3b7T66ffu2t7e3JEmHDx/mwgEAoifwwLZu3RoeHp6Wlnbj xg2LxWIymb7++utBgwYlJyc3V5EsFkt+fn5SUtKoUaN+++03J3uuWLFi9OjRBw8eNJlMVqvVZDId OHDg73//e0xMjMViqb2/1Wrdu3evEOL69et5eXlNV4UpU6asXbv2oQ9/0HrVVF5evmfPnujo6KKi oof76f7+/vPmzRNCLF26tKqqquZHa9eu/fXXX0eMGDFkyBCuHQAgegIP5siRI1OnTq2qqnruued2 7tx59uzZQ4cOzZgxQ5KkJUuW7Nq165GVpH379qbf3bhxIy0trX379ocOHVq2bJmjQ7KzsxcvXuzq 6pqcnPzDDz/88ssvOTk5c+fOVSgUW7du3bJlS+1D8vLyrl275urqKoRIT09vrMKPHTt29uzZdoH+ wIEDD3e2B61Xzaa7detWZmZmSEhIYWHhmjVrHrpGCQkJ/v7+P/7449atW20bCwsLP/jgAyHEqlWr uHYAgOiJZlN+8Va2blP+m/+n5saKAlO2btPlhRkttthmszk2NtZisUyZMuXIkSPjxo37y1/+MmTI kE2bNm3evFkIkZiYeN8+tka7JBQK9e86deo0efLkffv2SZK0bt26W7du1XnIpk2bhBAbNmxYtGhR aGion59feHj4O++88/HHHwshNm7cWPuQffv2CSFiY2OFEPv372+swsfGxr7//vuNdbYHrVfNpvP1 9X3uuefkeCr37z6cdu3aLVmyRAixfPlyW8dzSkpKRUXFxIkTe/fuzVUPAERPNJu2/+Xn+3yPX08Y Sw03bRtvfKSXVIqAOF2LLfbBgwcvXLgQGBj40UcfKRR/+JuMiYkJCwv78ccfz54921zFi4yMHDNm zL1793bu3FnnDtnZ2UKI8ePH222fOnWql5fXuXPnah+yd+9eSZISExO9vLyOHTtWWlraAn8vD1Ev OzqdTpKky5cvN6QYM2bM6Nat27Vr1+Swe/Xq1Y0bN7q4uDTjkxgAAKIn/r+AWJ3kqrz+4WlhFUKI su+LSjJ/8n/lqTYBni22zHv27JETRtu2be0+kiRp3rx5EydOrKioaMYSjhs3TgjhaEaLo8dAVSpV cnLy/Pnz7bbfvn37xIkTWq22Q4cOAwYMqKqqcjJXJiYmRpKkI0eOyN9aLBZ55k1OTo5tn+Dg4Kef flr8cSLR5s2b5a8PHz4sSdKHH34obzebzYsXL9ZoNK6urv379695ngbWy+FdRtGg+4yrq+vKlSuF ECkpKWVlZcuXL6+srIyNjX3iiSe43gGA6Ilm5tqxXYfxT5Wd/fnOv68Iq7j+0Wmlp2vHqS16XPL0 6dNCiOHDh9f56cSJEz///PPIyMhmLKFWqxVCOJoP1KNHDyHEmjVraj8VEB8f//bbb9tt3L9/v8Vi GTlypBBi8ODBwumYe1RUlBDCFhDz8/Pv3r0rhDAYDPKWwsJCo9EYHR1td6CPj09YWJgQwsPDIyws zDb3PykpacWKFSUlJRaL5dixY0OGDHE0DehB61WbXq+3Wq3dunVrYPu//PLLvXv3/vnnn+fMmZOW lubp6blw4UIudgAgeqJF6BjTW+XV5nqq/teTxtIzNzpN66PyatOSCywPyIaEhNRz/wsONF0Jg4OD hRDXr1+v89OZM2cKIVJSUnr27BkfH793717nA+jys48jRowQQsgTtNPT0x0tsSRHT1vQtGVQ25Yz Z84IIWpHz7Fjx+bm5gohnn322dzcXNu4+fr167ds2VJeXl5aWjpp0iSTyfTJJ580Sr1qMpvN2dnZ s2bNEkKMGjWqofcphUKeq7R582az2Tx//nyNRsOVDgCtkYomePwoPV07Te9z7b0TBW8dcu3UTvNy rxZe4Dt37iiVSm9v73ruX/+Q2ljatm2rVCrl7sbaRo4cmZqaOm/evEuXLm3YsGHDhg0qlSoqKuqV V16ZPn26PI3dprq6ev/+/d7e3n379hVC9OrVS6PRXL169fz586GhoXVWVq1W2xJnTk6Oj49P165d 7xs9HUlISJg6daoQwsXFZcmSJf/85z/lMzSwXkKI4uLi2uuGajSauXPn1j55Tk5OTEyMo0L27dvX bhrTsGHD+vfv/+9//1utVs+ZM4fLHABaKXo9H0+al0JdO7Yzl1YGzNIqXJUtvLRWq1VehLwll1AI oVQ6bMk33njDaDRu27Zt8uTJAQEB1dXVWVlZcXFxgwYNKi8vr7nnyZMnTSbT0KFDVSqVEEKhUAwa NEg4HnNXKBSRkZEXLlwoKysTQhgMhoiICJ1O991331VXV8vRs1OnTl27dq1nXSZMmGD7Wj6qpKSk 4fWqTZKkgQMHZmZmdujQofanZWVl3zl26dKl2v+fnD9/Xi5tfn4+1zgAED3RglTdrqi+XSGEqCgw tfzSenl5VVdX3zfK1AyCdWq6EpaXl5vNZrVa7WQftVr96quvpqWlGY3G3NzchISENm3afPvtt3Yr usuj7aGhobbnBORHKp2s7hkdHW2xWM6ePWu1WnNycrRarU6nq6iouHjxotVq1ev10dHR9Q/u8o+T yfHXuXrWS/xxXU+TyVReXn7kyBFHXdT9+vWzOnbo0CG7/deuXXvr1i1fX18hRFJSEtc4ABA90YJc /+i0VQjPZwKLvsirvHm3hZe2S5cuQghHXVlff/11v379ar9K8VH66aefxO99hLVVV1fLHZAySZLC wsLeffdduSPziy++qLmzvKJncnJyyO/k6dtZWVlyv2ZttplGRqOxuLhY7vUUQhgMBqPRWFRUVP/R diGEm5tbPfd8oHqJP67rqVar6/+D7v/3fP36unXrlErl4cOH/f39v/nmm4yMDC5zACB6okUoP/fL 7fQf/V/p1Tmxn6i23PhY38ILHBERIYSwrR9kZ/fu3cePH6/5cvZH79SpU0KI8PDwOj91d3eXq2Bn 4MCBQUFBNceOr1y54miafGVlpaMWeOaZZ5RKpcFgkJ/41Gq1oaGh7u7uBoPhQR/0lBNkPfesf72a 2tKlSysqKqZPnx4WFiZ3eSYmJjZpPzcAgOiJ+rGKa++fVLZz7RjT262zt+9f/6s4Pb/84q2WXOQX X3xRCLFp06aafWyyO3fu7Nq1y83N7YHSVaPbsWOHcLz8k5+fX0FBQZ2rYJrNZhcXF9u3cpfnm2++ aTe+nJKSIhyPuXt4eISHhxsMBoPB4Ovr27lzZ5VK1adPH4PBoNfr3d3dHWXiBqp/vR5CTk5OuGPy 1HhZXl7ep59+6ubmtnjxYiHErFmzAgIC9Hq9oxX+AQBETzw6JZk/3TXc7DglXF5QqdOMPpKL8voH p1t49AwKCjp//vySJUtqdmVZLJbY2Ng7d+689NJLHh4ezVW8o0eP7t+/v3379o4WCYqKirp79+57 771ntz0rK+vmzZvyYu81o6cctWuSF1pyssRSdHR0Xl7eqVOntFqt3G2p0+lycnJOnz7dt2/fBqZA R+pfr4dQ/2lG8mtU4+PjAwMDhRDu7u6LFi0SQixcuLCqqopLHgCInmg21iqL8YNTLpq2/uOfkre4 dmjn/1Lor6eMv540tthiu7q6ym8eX7Vq1dixY9PT03/44Yf09PTnn39++/btnp6ey5cvb6yfVeeC oDU79iwWS8nvioqKPv/887/97W9yAKr9siWZvHjQW2+9FRcXZzAYiouLCwoKUlNTx4wZI35fHVMI UV5enpGR4eHhMWDAALszhIeHazSay5cvO3rgNSoqqqqq6uDBg7YRcJ1OV1pampmZed/+YEePkN5X Pev1cOo5zejo0aP79u3z9vZesGCB7dhp06Z16dIlPz9ffkc8AIDoiebxy5fnfrt6J2CmVuH2n5nL HWN6K9q6GD84ZbW03Gfjxo0bJw867969+4UXXnjqqadeeOGFAwcOeHp67tmzpxFfmRhSl5ovGTeZ TO1/16FDh0mTJpWUlIwcOTIhIcHROSMjI1evXi2ESE1NjYiI8PPze/LJJ+Pi4kwm02uvvTZlyhR5 t4yMjHv37g0fPrxNG/sV/hUKhTya72jMXZ5pZDab5fcqydFTCFFdXe08egYGBp48ebJfv35OXpjU wHo1HYvFIr+uc968eT4+PjX/V1myZIkQYtmyZQ8drAEARE80lP8rT0Wcmen3t/+uuVHV3q13Vkzo 9nGSQmrJhU9KSsrMzBw9erRarZYkKSgo6B//+Mf3338vL3vZLCRJ6tGjx6pVq/71r385X4dowYIF 6enpw4YNkxfG9/b2Hjx48Pbt2z/77DPbG8wdjbbL5PdqOoqewcHB8huVbL2e3bt3lxvK+StG5cR8 /Phxo/Fhur3rU6+ms2PHDr1e7+/vP3v2bLuPXn/99e7duxcWFsr95QCA1kJilmhT5JWma1VJkiLO zGyKM2drN/HH8Fi6ceNGVVVVUFCQkyXxgT/nHRXAo8eLNIHHXEBAAI0AAGghGHAHAAAA0RMAAABE TwAAAIDoCQAAAKInAAAAiJ40AQAAAIieAAAAIHoCAAAARE8AAAC0WLygrAnatIlfpNl0JeePAcCf 6o4K4NHjRZqtDLdgAADQejHgDgAAAKInAAAAiJ4AAAAA0RMAAABETwAAABA9aQIAAAAQPQEAAED0 BAAAAIieAAAAIHoCAACA6AkAAAAQPQEAAED0BAAAAIieAAAAIHoCAACA6AkAAAAQPQEAAED0BAAA AIieAAAAIHoCAACA6AkAAAAQPQEAAED0BAAAAIieAAAAIHoCAACA6AkAAAAQPQEAAED0BAAAAIie AAAAIHoCAACA6AkAAAAQPQEAAED0BAAAAIieAAAAIHoCAACA6AkAAAA0NRVN0BQkSaIRAAAA7DOS 1WqlFQAAAPAI/D8SymH1tkzFQwAAAABJRU5ErkJggs== --=-YpDcr6tryQsZURu82i4J Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --=-YpDcr6tryQsZURu82i4J-- From ipsec-bounces@ietf.org Mon Dec 19 15:48:11 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoRvX-00013h-Mr; Mon, 19 Dec 2005 15:48:11 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoRvV-00013a-OY for ipsec@megatron.ietf.org; Mon, 19 Dec 2005 15:48:09 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA10804 for ; Mon, 19 Dec 2005 15:47:05 -0500 (EST) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoRxl-0004TZ-I2 for ipsec@ietf.org; Mon, 19 Dec 2005 15:50:31 -0500 Received: from helpdeskabroad (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id jBJKktAF021534; Mon, 19 Dec 2005 22:46:56 +0200 (IST) From: "Yoav Nir" To: "'Alejandro Perez Mendez'" , Subject: RE: [Ipsec] Problem with exchanges collisions Date: Mon, 19 Dec 2005 15:45:53 -0500 Message-ID: <002c01c604dd$351c79e0$cc151fac@ad.checkpoint.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <1134980790.30296.1.camel@localhost.localdomain> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1213 Importance: Normal X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Interesting. IMO this won't create a lasting problem, because the rekey_ike_sa exchange is usually followed by a delete exchange for the IKE SA. After this delete exchange, the implementation on the right will lose the "B" SA, while the left one will retain it. Since it is the implementation on the right that wanted this SA, it's safe to assume that it will create a new one soon. Even if it doesn't, the worst that could happen is that the left side will continue to use the "B" SA and get an INVALID_SPI message. OTOH the left implementation can fix this. All it needs to do is to refrain from accepting any child_sa exchanges on the IKE SA after it has initiated the rekey. It can send the NO_MORE_SAS notification, and thus fail the creation of B. When the right-hand side retries this, there will be a new IKE SA and everything should work. -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Alejandro Perez Mendez Sent: Monday, December 19, 2005 3:27 AM To: ipsec@ietf.org Subject: [Ipsec] Problem with exchanges collisions Hi, we have some problems when exchanges happen simultaeously. In order to understand a possible case we attach an image. It's a posible case in which extrange things may happen, a REKEY_IKE_SA exchange and a REKEY_CHILD_SA exchange at the same time. In this case peers lose the status sync. We know it is unusual to attach images but it is very difficult to explain in a textual format. Best regards! -- Alejandro Perez Mendez Pedro J. Fernandez Ruiz University of Murcia _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 20 04:10:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EodVl-00043R-Jo; Tue, 20 Dec 2005 04:10:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EodVh-00042f-LD for ipsec@megatron.ietf.org; Tue, 20 Dec 2005 04:10:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA00606 for ; Tue, 20 Dec 2005 04:09:13 -0500 (EST) Received: from pix-telematicos.um.es ([155.54.212.254] helo=mail.um.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EodY2-00043P-FF for ipsec@ietf.org; Tue, 20 Dec 2005 04:12:46 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 70FEF23CD15; Tue, 20 Dec 2005 10:09:38 +0100 (CET) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 28657-01-8; Tue, 20 Dec 2005 10:09:38 +0100 (CET) Received: from mistral.dif.um.es (mistral.dif.um.es [155.54.1.60]) by mail.um.es (Postfix) with ESMTP id 0006223CCE9; Tue, 20 Dec 2005 10:09:20 +0100 (CET) Received: from diffie (unknown [155.54.210.175]) by mistral.dif.um.es (Postfix) with ESMTP id 14A31105405A; Tue, 20 Dec 2005 10:03:01 +0100 (CET) Subject: Re: [Ipsec] IKEv2: invalid SPI in DELETE payload From: Alejandro Perez Mendez To: Tero Kivinen In-Reply-To: <17314.37710.80744.878445@fireball.acr.fi> References: <1134663631.25793.6.camel@localhost.localdomain> <17314.37710.80744.878445@fireball.acr.fi> Content-Type: text/plain; charset=utf-8 Date: Tue, 20 Dec 2005 10:09:15 +0100 Message-Id: <1135069755.26309.18.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 3002fc2e661cd7f114cb6bae92fe88f1 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com, OpenIKEv2 Administrators X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org El vie, 16-12-2005 a las 12:13 +0200, Tero Kivinen escribi=C3=B3: > Alejandro Perez Mendez writes: > > Hi > > What is the preferred behaviour when a DELETE payload containig an > > unknown IPSEC SPI is received in IKEv2? >=20 > This should not really happen in normal case, as IKEv2 keeps both ends > in sync, but it can happen in case the other end creates IPsec child > SA, and your response to that gets delayed, and before the other end > receives that packet, you decide to delete the newly created IPsec SA > (from your point of view it is ready, but for the other end it is > still half-created, and he does not know what SPI you are going to > use).=20 >=20 > > Should be to send an empty DELETE payload response? >=20 > Hmmm... I think you need to send error notify as a response. If you > simply ignore the notify then in the case I describe above both ends > end up in different state (i.e. other end thinks it has SA and other > end does not have that SA). >=20 > What error notify to use is another question then. Most logical would > be INVALID_SPI,but that is supposed to be used only when you receive > ESP or AH packets with invalid SPI. The problem with other notifies > like INVALID_SYNTAX is that the other end might consider that as fatal > error, and delete the IKE SA because of it. >=20 > I think we need a clarification text saying we can use INVALID_SPI in > that case too.=20 IMHO, if an INVALID_SPI is sent, it should has the SPI field filled, because it is needed to know what SPI has been rejected. But draft appears to doesn't allow this. The draft says: << o Protocol ID (1 octet) - If this notification concerns an existing SA, this field indicates the type of that SA. For IKE_SA notifications, this field MUST be one (1). For notifications concerning IPsec SAs this field MUST contain either (2) to indicate AH or (3) to indicate ESP. For notifications which do not relate to an existing SA, this field MUST be sent as zero and MUST be ignored on receipt. All other values for this field are reserved to IANA for future assignment. =20 o SPI Size (1 octet) - Length in octets of the SPI as defined by the IPsec protocol ID or zero if no SPI is applicable. For a notification concerning the IKE_SA, the SPI Size MUST be zero. >> =20 Since INVALID_SPI is sent becasue SPI is unknown, it doesn't concern any existing SA and PROTOCOL_ID MUST be 0. If PROTOCOL_ID=3D0, then SPI_SIZE MUST be 0 and SPI=3DNULL. I'm still thinking that if the PAYLOAD_DEL in the response doesn't contain the paired SPI implies peer doesn't delete that. IMHO no error notify is needed here. If Host A has some CHILD_SAs with the following SPIs: A1-A2 B1-B2 C1-C2 D1-D2 but Host B has only the following ones: A2-A1 B2-B1 C2-C1 Then, if Host A wants delete all its CHILD_SAs =20 Host A Host B ------ ------- DELETE A1,B1,C1,D1 ----------------> <------------------- DELETE A2,B2,C2 but Host B only deletes A, B and C. Host A should now, delete D1-D2 unilaterally. Regards _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 20 07:36:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eogji-0001Ta-Rv; Tue, 20 Dec 2005 07:36:58 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eogjh-0001TV-9O for ipsec@megatron.ietf.org; Tue, 20 Dec 2005 07:36:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA20505 for ; Tue, 20 Dec 2005 07:35:54 -0500 (EST) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eogm3-0001vJ-VA for ipsec@ietf.org; Tue, 20 Dec 2005 07:39:24 -0500 Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jBKCZSIB029094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Dec 2005 14:35:28 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id jBKCZPU2017664; Tue, 20 Dec 2005 14:35:25 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17319.64140.977622.683966@fireball.acr.fi> Date: Tue, 20 Dec 2005 14:35:24 +0200 From: Tero Kivinen To: "Yoav Nir" Subject: RE: [Ipsec] Problem with exchanges collisions In-Reply-To: <002c01c604dd$351c79e0$cc151fac@ad.checkpoint.com> References: <1134980790.30296.1.camel@localhost.localdomain> <002c01c604dd$351c79e0$cc151fac@ad.checkpoint.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 7 min X-Total-Time: 43 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Yoav Nir writes: > Interesting. IMO this won't create a lasting problem, because the > rekey_ike_sa exchange is usually followed by a delete exchange for the > IKE SA. The problem is that if the peers go out of sync, then we really should tear down the IKE SA and start over. The IKEv2 is supposed to make sure the end nodes keeps on sync. > After this delete exchange, the implementation on the right will lose > the "B" SA, while the left one will retain it. Since it is the > implementation on the right that wanted this SA, it's safe to assume > that it will create a new one soon. Even if it doesn't, the worst that > could happen is that the left side will continue to use the "B" SA and > get an INVALID_SPI message. > > OTOH the left implementation can fix this. All it needs to do is to > refrain from accepting any child_sa exchanges on the IKE SA after it has > initiated the rekey. It can send the NO_MORE_SAS notification, and thus > fail the creation of B. When the right-hand side retries this, there > will be a new IKE SA and everything should work. I agree on that. When you start IKE SA rekey you need to mark the IKE SA so that no new create childs will be allowed on it during or after the IKE SA rekey (it is completely possible that the first create child packet from the other end is lost, and we do get IKE SA rekey finished before we even see that first packet). I agree that NO_ADDITIONAL_SAS is perfect for this case, as it means "responder is unwilling to accept any more CHILD_SAs on this IKE_SA". The responder just needs to remember that it can retry recreating the SA which failed with that error notify using another IKE SAs (i.e the new one in this case). -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 20 07:46:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eogsf-0003v4-Nw; Tue, 20 Dec 2005 07:46:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eogsd-0003uC-Va for ipsec@megatron.ietf.org; Tue, 20 Dec 2005 07:46:12 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21500 for ; Tue, 20 Dec 2005 07:45:08 -0500 (EST) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eogv3-0002Dw-EH for ipsec@ietf.org; Tue, 20 Dec 2005 07:48:42 -0500 Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jBKCigFr018482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Dec 2005 14:44:42 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id jBKCigGk016373; Tue, 20 Dec 2005 14:44:42 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17319.64698.435490.928689@fireball.acr.fi> Date: Tue, 20 Dec 2005 14:44:42 +0200 From: Tero Kivinen To: Alejandro Perez Mendez Subject: Re: [Ipsec] IKEv2: invalid SPI in DELETE payload In-Reply-To: <1135069755.26309.18.camel@localhost.localdomain> References: <1134663631.25793.6.camel@localhost.localdomain> <17314.37710.80744.878445@fireball.acr.fi> <1135069755.26309.18.camel@localhost.localdomain> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 8 min X-Total-Time: 8 min X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Pasi.Eronen@nokia.com, OpenIKEv2 Administrators X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Alejandro Perez Mendez writes: > IMHO, if an INVALID_SPI is sent, it should has the SPI field filled, > because it is needed to know what SPI has been rejected. But draft > appears to doesn't allow this. The draft says that the SPI is sent inside the notification data field. > I'm still thinking that if the PAYLOAD_DEL in the response doesn't > contain the paired SPI implies peer doesn't delete that. IMHO no error > notify is needed here. That does not work as the returned delete payload can be empty in case of simultaneous deletes: Initiator Responder ========= ========= SPI 1234<- SPI ->456 Sends delete SPI 1234 --> <-- Sends delete SPI 456 Receives delete 456 Receives delete 1234 from other end, notices from other end, notices that there is already that there is already delete 1234 sent out delete 456 sent out so so sends empty return sends empty return ACK ACK back --> <-- back. Receives empty ACK Receives empty ACK after that SPI par 1234 <-> 456 is deleted. If the respoder has not yet seen the DELETE SPI 1234 then he does not know whether initiator replied to his DELETE SPI 456 with empty ACK because of invalid SPI error, or because initiator has already initiated delete. In case if delete was already issued, then he will delete the other part of SPI (1234) when receiving it, but he should delete SPI 456 already now. If the SPI was unknown he needs to keep 456 and try again later (i.e. it might be that initiator has not yet created the SPI 456 in his end). > If Host A has some CHILD_SAs with the following SPIs: > A1-A2 > B1-B2 > C1-C2 > D1-D2 > but Host B has only the following ones: > A2-A1 > B2-B1 > C2-C1 How did we end up in this state? In IKEv2 we should not ever end up in this state, and if either end detects this it should restart the IKE SA from the beginning to fix up the situation, i.e. create new IKE SA, create required IPsec SAs, and delete old IKE SA (and all IPsec SAs). -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 20 07:56:19 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eoh2R-0006Ds-HK; Tue, 20 Dec 2005 07:56:19 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eoh2P-0006Di-Kw for ipsec@megatron.ietf.org; Tue, 20 Dec 2005 07:56:17 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA22282 for ; Tue, 20 Dec 2005 07:55:14 -0500 (EST) Received: from pix-telematicos.um.es ([155.54.212.254] helo=mail.um.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eoh4m-0002WT-Jl for ipsec@ietf.org; Tue, 20 Dec 2005 07:58:48 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 4DB5823C012; Tue, 20 Dec 2005 13:55:40 +0100 (CET) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon2 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 12325-01-29; Tue, 20 Dec 2005 13:55:40 +0100 (CET) Received: from mistral.dif.um.es (mistral.dif.um.es [155.54.1.60]) by mail.um.es (Postfix) with ESMTP id 247D123C370; Tue, 20 Dec 2005 13:55:30 +0100 (CET) Received: from diffie (unknown [155.54.210.175]) by mistral.dif.um.es (Postfix) with ESMTP id 9C48F105405A; Tue, 20 Dec 2005 13:49:14 +0100 (CET) Subject: Re: [Ipsec] IKEv2: invalid SPI in DELETE payload From: Alejandro Perez Mendez To: Tero Kivinen In-Reply-To: <17319.64698.435490.928689@fireball.acr.fi> References: <1134663631.25793.6.camel@localhost.localdomain> <17314.37710.80744.878445@fireball.acr.fi> <1135069755.26309.18.camel@localhost.localdomain> <17319.64698.435490.928689@fireball.acr.fi> Content-Type: text/plain; charset=utf-8 Date: Tue, 20 Dec 2005 13:55:30 +0100 Message-Id: <1135083330.25174.3.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: 1ac7cc0a4cd376402b85bc1961a86ac2 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, OpenIKEv2 Administrators X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org El mar, 20-12-2005 a las 14:44 +0200, Tero Kivinen escribi=C3=B3: > Alejandro Perez Mendez writes: > > IMHO, if an INVALID_SPI is sent, it should has the SPI field filled, > > because it is needed to know what SPI has been rejected. But draft > > appears to doesn't allow this. >=20 > The draft says that the SPI is sent inside the notification data > field. But this is only true when notification concern to an existing SA (in this case concern to an inexisting SA and it is not applicable), it isn't? _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 20 08:33:15 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EohcB-00077T-Nf; Tue, 20 Dec 2005 08:33:15 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eohc9-00077J-6h for ipsec@megatron.ietf.org; Tue, 20 Dec 2005 08:33:13 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA26395 for ; Tue, 20 Dec 2005 08:32:09 -0500 (EST) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoheY-0003w7-JI for ipsec@ietf.org; Tue, 20 Dec 2005 08:35:44 -0500 Received: from helpdeskabroad (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id jBKDVmAF002319; Tue, 20 Dec 2005 15:31:54 +0200 (IST) From: "Yoav Nir" To: "'Tero Kivinen'" Subject: RE: [Ipsec] Problem with exchanges collisions Date: Tue, 20 Dec 2005 08:30:44 -0500 Message-ID: <000a01c60569$99e38e90$06151fac@ad.checkpoint.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.2627 In-Reply-To: <17319.64140.977622.683966@fireball.acr.fi> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1213 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 And yet the IKEv2 protocol has INVALID_SPI and INITIAL-CONTACT that allows end nodes to re-sync if something went wrong. I don't think receiving an INVALID_SPI is a good enough reason to tear down the IKE SA. I think Left should send a NO-MORE-SAS, but if it doesn't, Right should not tear down the IKE SA, but rather respond with an INVALID SPI should Left ever try to use the missed SA -----Original Message----- From: Tero Kivinen [mailto:kivinen@iki.fi] Yoav Nir writes: > Interesting. IMO this won't create a lasting problem, because the > rekey_ike_sa exchange is usually followed by a delete exchange for the > IKE SA. The problem is that if the peers go out of sync, then we really should tear down the IKE SA and start over. The IKEv2 is supposed to make sure the end nodes keeps on sync. _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 20 09:17:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoiIb-000085-I8; Tue, 20 Dec 2005 09:17:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoiIa-00007M-2G for ipsec@megatron.ietf.org; Tue, 20 Dec 2005 09:17:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA01976 for ; Tue, 20 Dec 2005 09:16:00 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoiKz-0005Qu-OG for ipsec@ietf.org; Tue, 20 Dec 2005 09:19:35 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBKEF6GP025493; Tue, 20 Dec 2005 16:15:09 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Dec 2005 16:15:57 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Dec 2005 16:15:57 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 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: invalid SPI in DELETE payload Date: Tue, 20 Dec 2005 16:15:56 +0200 Message-ID: In-Reply-To: <1135083330.25174.3.camel@localhost.localdomain> Thread-Topic: [Ipsec] IKEv2: invalid SPI in DELETE payload Thread-Index: AcYFZ01sRpX737ihRLOQ5P0ldtT5fQACEszw To: X-OriginalArrivalTime: 20 Dec 2005 14:15:57.0236 (UTC) FILETIME=[E5408F40:01C6056F] X-Spam-Score: 0.3 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, openikev2-admin@dif.um.es X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Alejandro Perez Mendez wrote: > > The draft says that the SPI is sent inside the notification data > > field. >=20 > But this is only true when notification concern to an existing SA (in > this case concern to an inexisting SA and it is not applicable), it > isn't? If the notification concerns an existing SA, the SPI is sent=20 in the "SPI" field of the Notify payload. In this case, it's sent=20 in the "Notification Data" field of the Notify payload: INVALID_SPI 11 MAY be sent in an IKE INFORMATIONAL Exchange when a node receives an ESP or AH packet with an invalid SPI. The Notification Data contains the SPI of the invalid packet. [...] Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 20 09:19:47 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoiLD-0000yu-5T; Tue, 20 Dec 2005 09:19:47 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoiLB-0000yY-SO for ipsec@megatron.ietf.org; Tue, 20 Dec 2005 09:19:45 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA02478 for ; Tue, 20 Dec 2005 09:18:41 -0500 (EST) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoiNb-0005X0-5R for ipsec@ietf.org; Tue, 20 Dec 2005 09:22:16 -0500 Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jBKEISJv016826 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Dec 2005 16:18:28 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id jBKEIRCq024942; Tue, 20 Dec 2005 16:18:27 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Message-ID: <17320.4787.887108.547515@fireball.acr.fi> Date: Tue, 20 Dec 2005 16:18:27 +0200 From: Tero Kivinen To: Alejandro Perez Mendez Subject: Re: [Ipsec] IKEv2: invalid SPI in DELETE payload In-Reply-To: <1135083330.25174.3.camel@localhost.localdomain> References: <1134663631.25793.6.camel@localhost.localdomain> <17314.37710.80744.878445@fireball.acr.fi> <1135069755.26309.18.camel@localhost.localdomain> <17319.64698.435490.928689@fireball.acr.fi> <1135083330.25174.3.camel@localhost.localdomain> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 1 min X-Total-Time: 0 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, OpenIKEv2 Administrators X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Alejandro Perez Mendez writes: > El mar, 20-12-2005 a las 14:44 +0200, Tero Kivinen escribi=F3: > > Alejandro Perez Mendez writes: > > > IMHO, if an INVALID=5FSPI is sent, it should has the SPI field fi= lled, > > > because it is needed to know what SPI has been rejected. But draf= t > > > appears to doesn't allow this. > >=20 > > The draft says that the SPI is sent inside the notification data > > field. >=20 > But this is only true when notification concern to an existing SA (in= > this case concern to an inexisting SA and it is not applicable), it > isn't=3F In case of the existing SA then the SPI is in the SPI field of the notify payload. In case of unknown SPI it is in notification data (i.e. in different field).=20 --=20 kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 20 09:31:39 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoiWh-0004Bd-7P; Tue, 20 Dec 2005 09:31:39 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoiWf-0004Ak-Uh for ipsec@megatron.ietf.org; Tue, 20 Dec 2005 09:31:38 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA04132 for ; Tue, 20 Dec 2005 09:30:34 -0500 (EST) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EoiZ6-0005yB-Hi for ipsec@ietf.org; Tue, 20 Dec 2005 09:34:09 -0500 Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jBKEUYYP029460 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Dec 2005 16:30:34 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id jBKEUXnQ028187; Tue, 20 Dec 2005 16:30:33 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17320.5513.632218.390872@fireball.acr.fi> Date: Tue, 20 Dec 2005 16:30:33 +0200 From: Tero Kivinen To: "Yoav Nir" Subject: RE: [Ipsec] Problem with exchanges collisions In-Reply-To: <000a01c60569$99e38e90$06151fac@ad.checkpoint.com> References: <17319.64140.977622.683966@fireball.acr.fi> <000a01c60569$99e38e90$06151fac@ad.checkpoint.com> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 11 min X-Total-Time: 11 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 538aad3a3c4f01d8b6a6477ca4248793 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Yoav Nir writes: > And yet the IKEv2 protocol has INVALID_SPI and INITIAL-CONTACT that > allows end nodes to re-sync if something went wrong. I don't think > receiving an INVALID_SPI is a good enough reason to tear down the IKE > SA. If the INVALID_SPI is received as a separate informational exchange indicating that the other end received ESP or AH packet with SPI it does not know, then of course you do not tear down the IKE SA. It is completely possible that attacker is sending ESP and AH packets with invalid SPIs. The receipient of the INVALID_SPI notify from the other end should at most trigger DPD. In case the received INVALID_SPI had protection of IKE SA, then there is no need to even do that. On the other hand if you get INVALID_SPI error message as a response IPsec SA rekey or delete notification you have sent out, that means that there is something wrong with the state of the IPsec SAs in two peers. This is expected in some cases (like if window size is > 1 and the other end has not yet processed some of those messages, or in cases where there is exchanges going in both directions and the other is using SPI created by the exchange not finished yet), but if the problem does not disappear in few minutes, then it indicates that the state of the two ends is out of sync (i.e. you send DELETE SPI 1234, and got INVALID_SPI error back, you retry that after 3 minutes, and still get DELETE SPI 1234 back, then you know there is something permanently out of sync in the peers, and you should restart the IKE SA from the beginning). If you do not do that you create black hole which will cause traffic to be silently dropped. > I think Left should send a NO-MORE-SAS, but if it doesn't, Right should > not tear down the IKE SA, but rather respond with an INVALID SPI should > Left ever try to use the missed SA I think it is better to say that left MUST send NO_ADDITIONAL_SAS. I.e. forbid creating new SAs on the IKE SA which is already in the progress of being rekeyed. Yes, the right will also send INVALID SPI to the left end if it receives packet with the SPI it does not know. When left receives INVALID SPI with the SPI value it knows should be valid, then it will suspect that the two ends are out of sync, and it will restart the IKE SA. The problem with state getting messed up means that we do have black hole which will drop packets sent to it. We do want to recover from that, which means we do want to restart the IKE SA to make sure we clear out all black holes. We cannot recover from black holes by sending deletes and so on, as we do not know how the state is messed up, thus we need to start from the beginning. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 20 10:01:06 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoizC-0004lN-Kk; Tue, 20 Dec 2005 10:01:06 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EoizA-0004kz-Su for ipsec@megatron.ietf.org; Tue, 20 Dec 2005 10:01:05 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA08289 for ; Tue, 20 Dec 2005 10:00:00 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from host50.foretec.com ([65.246.255.50] helo=mx2.foretec.com) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Eoj1a-00075N-UH for ipsec@ietf.org; Tue, 20 Dec 2005 10:03:36 -0500 Received: from mgw-ext04.nokia.com ([131.228.20.96]) by mx2.foretec.com with esmtp (Exim 4.24) id 1Eoiz8-0005C9-0D for ipsec@ietf.org; Tue, 20 Dec 2005 10:01:02 -0500 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBKEx0cw011054; Tue, 20 Dec 2005 16:59:01 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Dec 2005 16:59:55 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Dec 2005 16:59:55 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 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: invalid SPI in DELETE payload Date: Tue, 20 Dec 2005 16:59:55 +0200 Message-ID: In-Reply-To: <17314.37710.80744.878445@fireball.acr.fi> Thread-Topic: [Ipsec] IKEv2: invalid SPI in DELETE payload Thread-Index: AcYCKari4ZJ7bnE6R6m4mQY7afOA/QDR8qlQ To: , X-OriginalArrivalTime: 20 Dec 2005 14:59:55.0796 (UTC) FILETIME=[09F4DD40:01C60576] X-Spam-Score: 0.3 (/) X-Scan-Signature: c1c65599517f9ac32519d043c37c5336 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, openikev2-admin@dif.um.es X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Tero Kivinen wrote: > Alejandro Perez Mendez writes: > > Hi > > What is the preferred behaviour when a DELETE payload containig > > an unknown IPSEC SPI is received in IKEv2? >=20 > This should not really happen in normal case, as IKEv2 keeps both > ends in sync, but it can happen in case the other end creates > IPsec child SA, and your response to that gets delayed, and before > the other end receives that packet, you decide to delete the newly > created IPsec SA (from your point of view it is ready, but for the > other end it is still half-created, and he does not know what SPI > you are going to use). One solution to this would be to prohibit the responder from deleting SAs that are not fully created yet. But perhaps this is not very nice either, since then we need some way to know for sure when the SA is really ready. > > Should be to send an empty DELETE payload response? >=20 > Hmmm... I think you need to send error notify as a response. If > you simply ignore the notify then in the case I describe above > both ends end up in different state (i.e. other end thinks it has > SA and other end does not have that SA). I agree, we won't want to end up in different states. > What error notify to use is another question then. Most logical > would be INVALID_SPI,but that is supposed to be used only when you > receive ESP or AH packets with invalid SPI. The problem with other > notifies like INVALID_SYNTAX is that the other end might consider > that as fatal error, and delete the IKE SA because of it. >=20 > I think we need a clarification text saying we can use INVALID_SPI > in that case too. Hmm... what would be the expected behavior of a host receiving this notification? Presumably, it had a reason for requesting deletion in the first place, and it might have already removed most of the local state associated with the inbound half of the SA pair. Now it gets a notification saying "the state isn't synchronized". Should it just try sending the same Delete payload again (in a new=20 Informational request) or what? Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 20 10:10:50 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eoj8c-0006X6-Fs; Tue, 20 Dec 2005 10:10:50 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eoj8a-0006WZ-QT for ipsec@megatron.ietf.org; Tue, 20 Dec 2005 10:10:48 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA09561 for ; Tue, 20 Dec 2005 10:09:44 -0500 (EST) Received: from pix-telematicos.um.es ([155.54.212.254] helo=mail.um.es) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EojB0-0007Qe-4J for ipsec@ietf.org; Tue, 20 Dec 2005 10:13:20 -0500 Received: from localhost (localhost [127.0.0.1]) by mail.um.es (Postfix) with ESMTP id 732B11FAA9B; Tue, 20 Dec 2005 16:09:28 +0100 (CET) Received: from mail.um.es ([127.0.0.1]) by localhost (xenon1 [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 16105-01-23; Tue, 20 Dec 2005 16:09:28 +0100 (CET) Received: from mistral.dif.um.es (mistral.dif.um.es [155.54.1.60]) by mail.um.es (Postfix) with ESMTP id 4A7AF1FAA6A; Tue, 20 Dec 2005 16:09:18 +0100 (CET) Received: from diffie (unknown [155.54.210.175]) by mistral.dif.um.es (Postfix) with ESMTP id ADC9B105405A; Tue, 20 Dec 2005 16:03:01 +0100 (CET) Subject: Re: [Ipsec] IKEv2: invalid SPI in DELETE payload From: Alejandro Perez Mendez To: Tero Kivinen In-Reply-To: <17320.4787.887108.547515@fireball.acr.fi> References: <1134663631.25793.6.camel@localhost.localdomain> <17314.37710.80744.878445@fireball.acr.fi> <1135069755.26309.18.camel@localhost.localdomain> <17319.64698.435490.928689@fireball.acr.fi> <1135083330.25174.3.camel@localhost.localdomain> <17320.4787.887108.547515@fireball.acr.fi> Content-Type: text/plain; charset=utf-8 Date: Tue, 20 Dec 2005 16:09:18 +0100 Message-Id: <1135091358.28187.1.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at telemat.um.es Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, OpenIKEv2 Administrators X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org El mar, 20-12-2005 a las 16:18 +0200, Tero Kivinen escribi=C3=B3: > Alejandro Perez Mendez writes: > > El mar, 20-12-2005 a las 14:44 +0200, Tero Kivinen escribi=C3=B3: > > > Alejandro Perez Mendez writes: > > > > IMHO, if an INVALID_SPI is sent, it should has the SPI field fill= ed, > > > > because it is needed to know what SPI has been rejected. But draf= t > > > > appears to doesn't allow this. > > >=20 > > > The draft says that the SPI is sent inside the notification data > > > field. > >=20 > > But this is only true when notification concern to an existing SA (in > > this case concern to an inexisting SA and it is not applicable), it > > isn't? >=20 > In case of the existing SA then the SPI is in the SPI field of the > notify payload. In case of unknown SPI it is in notification data > (i.e. in different field). It's true. I read too quickly this section :) Thanks for your response Regards _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 20 10:55:36 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eojpw-0000zX-8m; Tue, 20 Dec 2005 10:55:36 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eojpr-0000yi-LL; Tue, 20 Dec 2005 10:55:34 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA15590; Tue, 20 Dec 2005 10:54:27 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EojsI-0000dI-7g; Tue, 20 Dec 2005 10:58:03 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBKFnLPX028707; Tue, 20 Dec 2005 17:49:22 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Dec 2005 17:53:11 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 20 Dec 2005 17:53:11 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 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] Last Call: 'The AES-CMAC-96 Algorithm and its use withIPsec' to Proposed Standard Date: Tue, 20 Dec 2005 17:53:06 +0200 Message-ID: In-Reply-To: <17314.43185.63560.327253@fireball.acr.fi> Thread-Topic: [Ipsec] Last Call: 'The AES-CMAC-96 Algorithm and its use withIPsec' to Proposed Standard Thread-Index: AcYCNoIAaPH3wbNZSbGNDujN1kxoxADQSNcA To: , , X-OriginalArrivalTime: 20 Dec 2005 15:53:11.0159 (UTC) FILETIME=[7A8A9070:01C6057D] X-Spam-Score: 0.4 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, iesg@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 If you want to negotiate the use of AES-CMAC-96 with IKEv1, you also need numbers for AH Transform Identifier and ESP Authentication Algorithm. Other comments: Overall comment: I'm not quite sure what's the value of having two different specifications (800-38B and draft-songlee-aes-cmac) for the same algorithm, especially since they don't contain the same text, use different notations for describing the algorithm, etc. I'd suggest just having a reference to the NIST spec, and save effort for everyone... Section 1: "CMAC [NIST-CMAC] is a keyed hash function": IMHO not=20 exactly the best terminology (the rest of the document uses=20 Message Authentication Code, which is better) Section 4: "The result of truncation should be taken in most significant bits first order." Ok, this is a lowercase "should" instead of a SHOULD, but something like "is" would be more precise. References: [XCBC] and [OMAC1] are never cited in the text (and they're probably not normative). Probably [AH] should be normative. Best regards, Pasi > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org]=20 > On Behalf Of ext Tero Kivinen > Sent: 16 December, 2005 13:45 > To: songlee@ee.washington.edu; jicheol.lee@samsung.com;=20 > radha@ee.washington.edu > Cc: IPsec WG; iesg@ietf.org > Subject: [Ipsec] Last Call: 'The AES-CMAC-96 Algorithm and=20 > its use withIPsec' to Proposed Standard >=20 > The IESG writes: > > - 'The AES-CMAC-96 Algorithm and its use with IPsec ' > > as a Proposed Standard >=20 > The IANA considerations section of this draft uses AES-CMAC-PRF-128 > (probably cut & paste from PRF document), when it should use > AUTH_AES_CMAC_96 (or similar). To fix this change: >=20 > 8. IANA Consideration > =20 > IANA should allocate a value for IKEv2 Transform Type 3 (Integrity=20 > Algorithm) to the AES-CMAC-PRF-128 algorithm when this document is > published. >=20 >=20 > to >=20 > 8. IANA Consideration > =20 > IANA should allocate a value for IKEv2 Transform Type 3 (Integrity > Algorithm) to the AUTH_AES_CMAC_96 algorithm when this document is > published. > --=20 > kivinen@safenet-inc.com >=20 > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec >=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Dec 20 11:58:43 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eokp1-0000cA-DH; Tue, 20 Dec 2005 11:58:43 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eokoz-0000ae-Vu for ipsec@megatron.ietf.org; Tue, 20 Dec 2005 11:58:42 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA29868 for ; Tue, 20 Dec 2005 11:57:38 -0500 (EST) Received: from bass.opus1.com ([192.245.12.9]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EokrO-0004rj-VW for ipsec@ietf.org; Tue, 20 Dec 2005 12:01:14 -0500 Received: from Opus1.COM by Opus1.COM (PMDF V6.2-X27 #9830) id <01LWS4XZLASGA9SQ9X@Opus1.COM> for ipsec@ietf.org; Tue, 20 Dec 2005 09:58:25 -0700 (MST) Date: Tue, 20 Dec 2005 09:57:18 -0700 (MST) From: Joel M Snyder To: ipsec@ietf.org Message-id: <01LWS52WULR2A9SQ9X@Opus1.COM> Organization: Opus One - +1 520 324 0494 MIME-version: 1.0 Content-type: TEXT/PLAIN; CHARSET=us-ascii Fruit-of-the-day: Shinnini Comments: Telecommunications and Information Technology Services X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 Subject: [Ipsec] SSL VPN testing results (slightly off-topic) X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is slightly off-topic for IPsec readers (but not exactly, since there is a great deal of overlap in the provisioning & integration issues), so I apologize in advance if anyone doesn't want to know about SSL VPNs. A very very large review / test I just completed has finally been published by Network World: http://www.networkworld.com/reviews/2005/121905-ssl-test-intro.html jms -- Joel M Snyder, 1404 East Lind Road, Tucson, AZ, 85719 Phone: +1 520 324 0494 (voice) +1 520 324 0495 (FAX) jms@Opus1.COM http://www.opus1.com/jms Opus One _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Dec 21 03:57:21 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eozmj-0006ux-NN; Wed, 21 Dec 2005 03:57:21 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Eozmg-0006uY-Od; Wed, 21 Dec 2005 03:57:19 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA11729; Wed, 21 Dec 2005 03:56:12 -0500 (EST) From: Pasi.Eronen@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EozpE-0003QW-An; Wed, 21 Dec 2005 03:59:57 -0500 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id jBL8rCu2000458; Wed, 21 Dec 2005 10:53:14 +0200 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Dec 2005 10:57:03 +0200 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 21 Dec 2005 10:57:03 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5.7233.31 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] Last Call: 'The AES-CMAC-96 Algorithm and its use withIPsec' to Proposed Standard Date: Wed, 21 Dec 2005 10:57:02 +0200 Message-ID: In-Reply-To: Thread-Topic: [Ipsec] Last Call: 'The AES-CMAC-96 Algorithm and its use withIPsec' to Proposed Standard Thread-Index: AcYFne+jVsBakzymSrSMH3oTKezGNwAbc6tA To: X-OriginalArrivalTime: 21 Dec 2005 08:57:03.0624 (UTC) FILETIME=[8324D080:01C6060C] X-Spam-Score: 0.4 (/) X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22 Content-Transfer-Encoding: quoted-printable Cc: jicheol.lee@samsung.com, ipsec@ietf.org, iwata@mx.ibaraki.ac.jp, iesg@ietf.org, radha@ee.washington.edu X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Jun Hyuk Song wrote: > > Overall comment: I'm not quite sure what's the value of having > > two different specifications (800-38B and draft-songlee-aes-cmac) > > for the same algorithm, especially since they don't contain the > > same text, use different notations for describing the algorithm, > > etc. I'd suggest just having a reference to the NIST spec, and > > save effort for everyone... >=20 > You are comment to darft-songlee-aes-cmac right? >=20 > The purpose of this document is as we stated in abstract; "to make > the AES-CMAC algorithm conveniently available to the Internet > Community" Unlike NIST-80038B, draft-songlee-aes-cmac specifically > describes for CMAC over AES-128 with test code and test vector. I was just puzzled why you think that the NIST specs are not "conveniently available" (I think they are nowadays -- perhaps the situation was different earlier) and why extra work by yourself,=20 your co-authors, the IESG, the RFC editor, etc. is needed. Besides, the test vectors are the same as in 800-38B, and I'm not quite convinced that the test code is useful (most of it is standard AES code, and it's not even clear under which terms the code is licensed.) Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Dec 21 04:10:16 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EozzE-000561-Dr; Wed, 21 Dec 2005 04:10:16 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EozzB-00051p-VX for ipsec@megatron.ietf.org; Wed, 21 Dec 2005 04:10:14 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12840 for ; Wed, 21 Dec 2005 04:09:09 -0500 (EST) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Ep01l-0003wa-JL for ipsec@ietf.org; Wed, 21 Dec 2005 04:12:55 -0500 Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jBL998i5012692 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 21 Dec 2005 11:09:08 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id jBL996kT002657; Wed, 21 Dec 2005 11:09:06 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17321.7090.645389.376171@fireball.acr.fi> Date: Wed, 21 Dec 2005 11:09:06 +0200 From: Tero Kivinen To: Pasi.Eronen@nokia.com Subject: RE: [Ipsec] IKEv2: invalid SPI in DELETE payload In-Reply-To: References: <17314.37710.80744.878445@fireball.acr.fi> X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 16 min X-Total-Time: 22 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 14582b0692e7f70ce7111d04db3781c8 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, openikev2-admin@dif.um.es X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Pasi.Eronen@nokia.com writes: > One solution to this would be to prohibit the responder from > deleting SAs that are not fully created yet. But perhaps this is not > very nice either, since then we need some way to know for sure when > the SA is really ready. The problem is that if responder's policy changes then he might want to delete SA even when there has not been any traffic over that SA (which would indicate that the other end managed to create the SA). The case is like this: Initiator Responder ========= ========= Starts create child HDR(MessageID=22, Initiator), SK{SA(SPI=1234), Ni, TSi, TSr} --> Replies to the create child, and installs SA X <-- HDR(MessageID=22, Reply), SK{SA(SPI=456), Nr, TSi, TSr} Packet is lost or delayed Responder gets policy change which makes created SA against policy, so responder starts to delete SA <-- HDR(MessageID=44), SK{D(SPI=456)} Delete reaches initiator, but initiator does not know anything about SPI 456 as he has not yet seen the reply to the create child exchange from responder. He should send error notify back HDR(MessageID=44, Initiator, Reply), SK{N(INVALID_SPI(data=456))} --> Responder knows that delete didn't get through, so he keeps SPI 456 still but does not use it (he stopped using it when he originally created delete notifiation). Initiator restransmits create child as he has not received reply to it HDR(MessageID=22, Initiator), SK{SA(SPI=1234), Ni, TSi, TSr} --> Responder retranmits his packet. <-- HDR(MessageID=22, Reply), SK{SA(SPI=456), Nr, TSi, TSr} Initiator installs SA. Responder can later retry deleting the SPI 456. <-- HDR(MessageID=45), SK{D(SPI=456)} Now initiator knows the SPI thus it deletes the SA and replies to packet HDR(MessageID=45, Initiator, Reply), SK{D(SPI=1234)} --> After that SA has been deleted in both ends and peers are again in sync. > > I think we need a clarification text saying we can use INVALID_SPI > > in that case too. > > Hmm... what would be the expected behavior of a host receiving this > notification? Presumably, it had a reason for requesting deletion > in the first place, and it might have already removed most of the > local state associated with the inbound half of the SA pair. Now it > gets a notification saying "the state isn't synchronized". Should > it just try sending the same Delete payload again (in a new > Informational request) or what? It should keep the SA in half closed state (i.e. he will not use it, but will still accept incoming data to the SA). Later he should retry delete (say after few minutes) and if the problem persists it should then start corrective actions (i.e. restart IKE SA, but it might want to set up new IKE SA and replacement IPsec SAs before it deletes the old IKE SA). -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Dec 21 19:50:58 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpEfZ-0001qY-VM; Wed, 21 Dec 2005 19:50:57 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpEfY-0001qM-O2 for ipsec@megatron.ietf.org; Wed, 21 Dec 2005 19:50:56 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA04991 for ; Wed, 21 Dec 2005 19:49:52 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpEiG-0005cV-D0 for ipsec@ietf.org; Wed, 21 Dec 2005 19:53:45 -0500 Received: from [10.20.30.249] (dsl2-63-249-109-231.cruzio.com [63.249.109.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBM0okxw030071 for ; Wed, 21 Dec 2005 16:50:47 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Wed, 21 Dec 2005 16:50:40 -0800 To: IPsec WG From: The IESG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 68c8cc8a64a9d0402e43b8eee9fc4199 Subject: [Ipsec] Last Call: 'Repeated Authentication in IKEv2' to Informational RFC X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org The IESG has received a request from an individual submitter to consider the following document: - 'Repeated Authentication in IKEv2 ' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2006-01-18. The file can be obtained via http://www.ietf.org/internet-drafts/draft-nir-ikev2-auth-lt-04.txt _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Dec 23 20:25:00 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epy9c-0008CU-9t; Fri, 23 Dec 2005 20:25:00 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Epy9Z-00089E-TV for ipsec@megatron.ietf.org; Fri, 23 Dec 2005 20:24:57 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08585 for ; Fri, 23 Dec 2005 20:23:50 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpyCi-00029P-8p for ipsec@ietf.org; Fri, 23 Dec 2005 20:28:12 -0500 Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBO1OoFA059296 for ; Fri, 23 Dec 2005 17:24:51 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <200512230044.jBN0iRw02562@boreas.isi.edu> <200512230036.jBN0aOw28722@boreas.isi.edu> <200512230043.jBN0hIw01865@boreas.isi.edu> <200512230037.jBN0bew29123@boreas.isi.edu> <200512230045.jBN0jYw02952@boreas.isi.edu> <200512230040.jBN0eDw00454@boreas.isi.edu> <200512230039.jBN0d3w29930@boreas.isi.edu> <200512230041.jBN0faw01118@boreas.isi.edu> <200512230035.jBN0ZCw28428@boreas.isi.edu> References: <200512230044.jBN0iRw02562@boreas.isi.edu> <200512230036.jBN0aOw28722@boreas.isi.edu> <200512230043.jBN0hIw01865@boreas.isi.edu> <200512230037.jBN0bew29123@boreas.isi.edu> <200512230045.jBN0jYw02952@boreas.isi.edu> <200512230040.jBN0eDw00454@boreas.isi.edu> <200512230039.jBN0d3w29930@boreas.isi.edu> <200512230041.jBN0faw01118@boreas.isi.edu> <200512230035.jBN0ZCw28428@boreas.isi.edu> Date: Fri, 23 Dec 2005 17:24:29 -0800 To: ipsec@ietf.org From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Subject: [Ipsec] We finally have RFCs! X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 RFCs issued yesterday, but for some reason the RFC Editor's mail to this mailing list is not getting through. Below are the important bits from the announcements. To everyone who helped us finish IKEv2: thank you! --Paul Hoffman, Director --VPN Consortium > RFC 4301 > > Title: Security Architecture for the Internet Protocol > Author(s): S. Kent, K. Seo > Status: Standards Track > Date: December 2005 > Mailbox: kent@bbn.com, kseo@bbn.com > Pages: 101 > Characters: 262123 > Obsoletes: 2401 > > I-D Tag: draft-ietf-ipsec-rfc2401bis-06.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc4301.txt > > > RFC 4302 > > Title: IP Authentication Header > Author(s): S. Kent > Status: Standards Track > Date: December 2005 > Mailbox: kent@bbn.com > Pages: 34 > Characters: 82328 > Obsoletes: 2402 > > I-D Tag: draft-ietf-ipsec-rfc2402bis-10.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc4302.txt > > > RFC 4303 > > Title: IP Encapsulating Security Payload (ESP) > Author(s): S. Kent > Status: Standards Track > Date: December 2005 > Mailbox: kent@bbn.com > Pages: 44 > Characters: 114315 > Obsoletes: 2406 > > I-D Tag: draft-ietf-ipsec-esp-v3-11.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc4303.txt > > RFC 4304 > > Title: Extended Sequence Number (ESN) Addendum to > IPsec Domain of Interpretation (DOI) > for Internet Security Association > and Key Management Protocol (ISAKMP) > Author(s): S. Kent > Status: Standards Track > Date: December 2005 > Mailbox: kent@bbn.com > Pages: 5 > Characters: 9243 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-ipsec-esn-addendum-03.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc4304.txt > > RFC 4305 > > Title: Cryptographic Algorithm Implementation > Requirements for Encapsulating Security Payload > (ESP) and Authentication Header (AH) > Author(s): D. Eastlake 3rd > Status: Standards Track > Date: December 2005 > Mailbox: Donald.Eastlake@Motorola.com > Pages: 9 > Characters: 17991 > Obsoletes: 2404, 2406 > > I-D Tag: draft-ietf-ipsec-esp-ah-algorithms-02.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc4305.txt > > > RFC 4306 > > Title: Internet Key Exchange (IKEv2) Protocol > Author(s): C. Kaufman, Ed. > Status: Standards Track > Date: December 2005 > Mailbox: charliek@microsoft.com > Pages: 99 > Characters: 250941 > Obsoletes: 2407, 2408, 2409 > > I-D Tag: draft-ietf-ipsec-ikev2-17.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc4306.txt > > RFC 4307 > > Title: Cryptographic Algorithms for Use in the > Internet Key Exchange Version 2 (IKEv2) > Author(s): J. Schiller > Status: Standards Track > Date: December 2005 > Mailbox: jis@mit.edu > Pages: 6 > Characters: 12985 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-ipsec-ikev2-algorithms-05.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc4307.txt > > RFC 4308 > > Title: Cryptographic Suites for IPsec > Author(s): P. Hoffman > Status: Standards Track > Date: December 2005 > Mailbox: paul.hoffman@vpnc.org > Pages: 7 > Characters: 13127 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-ipsec-ui-suites-06.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc4308.txt > > RFC 4309 > > Title: Using Advanced Encryption Standard (AES) CCM Mode > with IPsec Encapsulating Security Payload (ESP) > Author(s): R. Housley > Status: Standards Track > Date: December 2005 > Mailbox: housley@vigilsec.com > Pages: 13 > Characters: 28998 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-ipsec-ciph-aes-ccm-05.txt > > URL: ftp://ftp.rfc-editor.org/in-notes/rfc4309.txt --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Dec 23 21:45:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpzPl-0006XL-3m; Fri, 23 Dec 2005 21:45:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EpzPj-0006Wx-H2 for ipsec@megatron.ietf.org; Fri, 23 Dec 2005 21:45:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA16486 for ; Fri, 23 Dec 2005 21:44:36 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EpzSs-0004eM-Gj for ipsec@ietf.org; Fri, 23 Dec 2005 21:48:59 -0500 Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBO2jaMx066178 for ; Fri, 23 Dec 2005 18:45:37 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Fri, 23 Dec 2005 18:45:32 -0800 To: IPsec WG From: Bernard Aboba Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 10ba05e7e8a9aa6adb025f426bef3a30 Subject: [Ipsec] Review of draft-nir-ikev2-auth-lt-04.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org In general, this specification appears to be ok, but there are places where the language could be cleaned up. Section 1 "However, in the remote access scenario it is usually up to a human user to supply the authentication credentials, and often EAP is used for authentication, which makes it unreasonable or impossible for the remote access gateway to initiate the exchange." This statement is misleading. In EAP, re-authentication (like authentication) is initiated by the authenticator sending an EAP-Request. So it is not correct to imply that EAP "makes it unreasonable or impossible for the remote access gateway to initiate the exchange". In IKEv2, the desire to do EAP authentication is indicated by the initiator leaving out the AUTH payload from message 3. The responder then can send an EAP payload in message 4. However, no mechanism is specified to enable a responder to initiate an EAP re-authentication. As noted in draft-eronen-ipsec-ikev2-clarifications, Section 5.2: " While creation of a new IKE_SA can be initiated by either party (initiator or responder in the original IKE_SA), the use of EAP authentication and/or configuration payloads means in practice that reauthentication has to be initiated by the same party as the original IKE_SA. IKEv2 does not currently allow the responder to request reauthentication in this case; however, there is ongoing work to add this functionality [ReAuth]." Given that this is not an EAP issue, but rather an IKEv2 issue, it might be helpful for the document to explain why it has chosen not to "allow the responder to request reauthentication" as implied in the above passage, opting for the lifetime approach instead. Is this because it is not clear exactly how a responder-initiated EAP re-authentication would proceed (e.g. no state machine for IKEv2/EAP interactions)? Section 2 "The Responder MUST send this information to the Initiator in an AUTH_LIFETIME notification either in the last message of an IKE_AUTH exchange, or in a separate Informational exchange, which can be sent at any time." In AAA, the Session-Time attribute is typically used to control EAP re-authentication. Since this attribute is sent along with EAP keying material, it is not known until EAP authentication has completed (e.g. at the time the EAP-Success message is sent). This means that during an initial authentication, AUTH_LIFETIME cannot be communicated at any time; this can only occur during re-authentication, because the Session-Time attribute has presumably been cached on the remote access gateway. This needs to be clarified. Section 4 "IKEv2 implementations that do not support the AUTH_LIFETIME notification will ignore it and will not repeat the authentication. In that case the original Responder will send a Delete notification for the IKE SA in an Informational exchange. Such implementations may be configured manually to repeat the authentication periodically." I'd suggest that this paragraph needs to be stronger. If the maximum re-authentication time expires (e.g. Session-Timeout attribute) and the Initiator has not initiated re-authentication, then the Responder SHOULD send a Delete notification. 5. Security Considerations "The AUTH_LIFETIME notification sent by the Responder does not override any security policy on the Initiator. In particular, the Initiator may have a different policy regarding re-authentication, requiring more frequent re-authentication. Such an Initiator can repeat the authentication earlier then is required by the notification." This paragraph suggests that an Initiator complying with this specification can ignore the AUTH_LIFETIME notification entirely. That seems odd. Shouldn't an Initiator compliant with this specification be required to initiatie re-authentication no later than specified in the AUTH_LIFETIME notification? _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Sun Dec 25 04:16:45 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EqRzh-0007YN-Ii; Sun, 25 Dec 2005 04:16:45 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EqRzf-0007YF-0j for ipsec@megatron.ietf.org; Sun, 25 Dec 2005 04:16:43 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20477 for ; Sun, 25 Dec 2005 04:15:34 -0500 (EST) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EqS31-0004ZA-Gg for ipsec@ietf.org; Sun, 25 Dec 2005 04:20:14 -0500 Received: from YnirNew (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id jBP9GKAF011164; Sun, 25 Dec 2005 11:16:20 +0200 (IST) Message-Id: <200512250916.jBP9GKAF011164@michael.checkpoint.com> From: "Yoav Nir" To: "'Bernard Aboba'" , "'IPsec WG'" Subject: RE: [Ipsec] Review of draft-nir-ikev2-auth-lt-04.txt Date: Sun, 25 Dec 2005 11:16:20 +0200 Organization: Check Point MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Thread-Index: AcYINH8UveOtIedIQsq2KXpjGzZODQA+ah3w In-Reply-To: X-Spam-Score: 0.0 (/) X-Scan-Signature: 932cba6e0228cc603da43d861a7e09d8 Content-Transfer-Encoding: 7bit Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Re: Section 1. The motivation for the lifetime approach is because of the human interaction that's involved. Protocols implementation are written with machines in mind and have timeouts consistent with machine speed and Internet round-trip time. People who must type in passwords or copy them from hardware tokens are much slower, and that's why it is best to have the client application decide how long before the lifetime expires it needs to start the authentication process (get credentials and start an Initial exchange). A good client may pop up the credential request 5 minutes before expiration (maybe the user went to make coffee). A good client running on Windows may increase this to 8 minutes if the accessibility options are set. This is why it's unreasonable for the server to initiate. With the state machines that are currently defined, it is not possible for the gateway to initiate an exchange where the client authenticates with EAP. I did not want to add a new exchange type. Does this look better? "However, in the remote access scenario it is usually up to a human User to supply the authentication credentials, which may take a long time, and often EAP is used. This makes it unreasonable for the remote Access gateway to initiate the IKEv2 AUTH exchange where these "redentials are passed." Re: Section 2 If you look at the top of page 32 of RFC 4306, the EAP success message is sent in message 4 of IKE_AUTH, while the notification is sent in the last message, message 6. There is no problem then to send a lifetime with the appropriate value. Re: Section 4 I can see a SHOULD there, but I can also see an implementation just preventing new child SAs when the time expires (by using the NO-MORE-SAS notification) and sending the DELETE only some 5 minutes. It may be worth a SHOULD. Re: Section 5 All I'm saying is that a compliant implementation may do the re-authentication earlier than is required by the notification. -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Bernard Aboba Sent: Saturday, December 24, 2005 4:46 AM To: IPsec WG Subject: [Ipsec] Review of draft-nir-ikev2-auth-lt-04.txt In general, this specification appears to be ok, but there are places where the language could be cleaned up. Section 1 "However, in the remote access scenario it is usually up to a human user to supply the authentication credentials, and often EAP is used for authentication, which makes it unreasonable or impossible for the remote access gateway to initiate the exchange." This statement is misleading. In EAP, re-authentication (like authentication) is initiated by the authenticator sending an EAP-Request. So it is not correct to imply that EAP "makes it unreasonable or impossible for the remote access gateway to initiate the exchange". In IKEv2, the desire to do EAP authentication is indicated by the initiator leaving out the AUTH payload from message 3. The responder then can send an EAP payload in message 4. However, no mechanism is specified to enable a responder to initiate an EAP re-authentication. As noted in draft-eronen-ipsec-ikev2-clarifications, Section 5.2: " While creation of a new IKE_SA can be initiated by either party (initiator or responder in the original IKE_SA), the use of EAP authentication and/or configuration payloads means in practice that reauthentication has to be initiated by the same party as the original IKE_SA. IKEv2 does not currently allow the responder to request reauthentication in this case; however, there is ongoing work to add this functionality [ReAuth]." Given that this is not an EAP issue, but rather an IKEv2 issue, it might be helpful for the document to explain why it has chosen not to "allow the responder to request reauthentication" as implied in the above passage, opting for the lifetime approach instead. Is this because it is not clear exactly how a responder-initiated EAP re-authentication would proceed (e.g. no state machine for IKEv2/EAP interactions)? Section 2 "The Responder MUST send this information to the Initiator in an AUTH_LIFETIME notification either in the last message of an IKE_AUTH exchange, or in a separate Informational exchange, which can be sent at any time." In AAA, the Session-Time attribute is typically used to control EAP re-authentication. Since this attribute is sent along with EAP keying material, it is not known until EAP authentication has completed (e.g. at the time the EAP-Success message is sent). This means that during an initial authentication, AUTH_LIFETIME cannot be communicated at any time; this can only occur during re-authentication, because the Session-Time attribute has presumably been cached on the remote access gateway. This needs to be clarified. Section 4 "IKEv2 implementations that do not support the AUTH_LIFETIME notification will ignore it and will not repeat the authentication. In that case the original Responder will send a Delete notification for the IKE SA in an Informational exchange. Such implementations may be configured manually to repeat the authentication periodically." I'd suggest that this paragraph needs to be stronger. If the maximum re-authentication time expires (e.g. Session-Timeout attribute) and the Initiator has not initiated re-authentication, then the Responder SHOULD send a Delete notification. 5. Security Considerations "The AUTH_LIFETIME notification sent by the Responder does not override any security policy on the Initiator. In particular, the Initiator may have a different policy regarding re-authentication, requiring more frequent re-authentication. Such an Initiator can repeat the authentication earlier then is required by the notification." This paragraph suggests that an Initiator complying with this specification can ignore the AUTH_LIFETIME notification entirely. That seems odd. Shouldn't an Initiator compliant with this specification be required to initiatie re-authentication no later than specified in the AUTH_LIFETIME notification? _______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf _______________________________________________ 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 Dec 27 06:57:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErDS5-0008Il-QI; Tue, 27 Dec 2005 06:57:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1ErDS3-0008H2-2V for ipsec@megatron.ietf.org; Tue, 27 Dec 2005 06:57:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA04222 for ; Tue, 27 Dec 2005 06:56:00 -0500 (EST) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1ErDVs-0008W9-0M for ipsec@ietf.org; Tue, 27 Dec 2005 07:01:08 -0500 Received: from YnirNew (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id jBRBufAF028619; Tue, 27 Dec 2005 13:56:41 +0200 (IST) Message-Id: <200512271156.jBRBufAF028619@michael.checkpoint.com> From: "Yoav Nir" To: "'Bernard Aboba'" Subject: RE: [Ipsec] Review of draft-nir-ikev2-auth-lt-04.txt Date: Tue, 27 Dec 2005 13:56:41 +0200 Organization: Check Point MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.6353 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506 Thread-Index: AcYJY7PT12aC1CE2R7mGWjBHK5W60gBdO2wg In-Reply-To: X-Spam-Score: 1.3 (+) X-Scan-Signature: bc6181926481d86059e678c9f7cb8b34 Content-Transfer-Encoding: 7bit Cc: 'IPsec WG' X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org My comments inline (beginning with [ynir]) -----Original Message----- From: Bernard Aboba [mailto:aboba@internaut.com] Sent: Sunday, December 25, 2005 4:59 PM To: Yoav Nir Cc: 'IPsec WG' Subject: RE: [Ipsec] Review of draft-nir-ikev2-auth-lt-04.txt > A good client may pop up the credential request 5 minutes before > expiration (maybe the user went to make coffee). A good client running > on Windows may increase this to 8 minutes if the accessibility options > are set. This is why it's unreasonable for the server to initiate. I assume you're talking about initiating the re-authentication exchange prior to expiration of the lifetime, correct? That's ok, but attempting to anticipate the EAP method exchange before it occurs is difficult: a. The EAP server, while typically utilizing the same EAP method for re-authentication, is under no obligation to do so, and in fact commonly used EAP methods support "fast re-authentication", in which different credentials are used. So "popping up a credential request" may not be necessary, depending on the method chosen. b. Unless the EAP method doesn't support freshness, the peer cannot pre-compute the re-authentication respose. The core issue here is the EAP retransmission timer, but that is under the control of the authenticator, not the peer. From RFC 3579, Section 2.3: It may be necessary to adjust retransmission strategies and authentication timeouts in certain cases. For example, when a token card is used additional time may be required to allow the user to find the card and enter the token. Since the NAS will typically not have knowledge of the required parameters, these need to be provided by the RADIUS server. This can be accomplished by inclusion of Session-Timeout attribute within the Access-Challenge packet. If Session-Timeout is present in an Access-Challenge packet that also contains an EAP-Message, the value of the Session-Timeout is used to set the EAP retransmission timer for that EAP Request, and that Request alone. Once the EAP-Request has been sent, the NAS sets the retransmission timer, and if it expires without having received an EAP-Response corresponding to the Request, then the EAP-Request is retransmitted. [ynir] Agree. For several IKEv2 authentication methods, like some EAP methods, or RSA signatures or pre-shared secrets it is possible for the user to enter the credentials before the exchange starts. Even when using EAP methods that don't allow this, it is still better that the client software be able to make sure the user is available to do her part of the process, by doing some UI interaction such as displaying a count-down, popping up an alert (and beginning the exchange when the user clicks OK), or beeping. > With the state machines that are currently defined, it is not possible for > the gateway to initiate an exchange where the client authenticates with EAP. > I did not want to add a new exchange type. One implication is that a new DH exchange occurs on each re-authentication. Is that desired? [ynir] It's not. It would be better to be able to just start an AUTH exchange under the existing IKE SA with no DH and without disturbing the IPsec SAs. When I suggested this in early 2004, people objected because that would mean a new exchange type or at least a new state machine for a relatively minor feature. If it could be done pretty well with the addition of a simple notification and a 3-page draft (that was before all the IPR boilerplate took it to 4 pages), I shouldn't invent a new variation on the AUTH exchange. > Does this look better? > "However, in the remote access scenario it is usually up to a human > User to supply the authentication credentials, which may take a long > time, and often EAP is used. This makes it unreasonable for the remote > Access gateway to initiate the IKEv2 AUTH exchange where these > "redentials are passed." It seems that the issue is really the state machine, not the retransmission timer, right? [ynir] It is. But given that we're not doing a new type of exchange, it still remains up to the client (or supplicant) to initiate the IKEv2 exchange for the gateway (or authenticator) to be able to initiate the EAP negotiation. And we've got two sets of retransmission timers and timeouts: those of EAP and those of IKEv2. > Re: Section 2 > If you look at the top of page 32 of RFC 4306, the EAP success message is > sent in message 4 of IKE_AUTH, while the notification is sent in the last > message, message 6. There is no problem then to send a lifetime with the > appropriate value. Right. But the AUTH_LIFETIME can't be sent before the Success message is received from the AAA server. > > Re: Section 4 > I can see a SHOULD there, but I can also see an implementation just > preventing new child SAs when the time expires (by using the NO-MORE-SAS > notification) and sending the DELETE only some 5 minutes. It may be worth a > SHOULD. > > Re: Section 5 > All I'm saying is that a compliant implementation may do the > re-authentication earlier than is required by the notification. That's fine. But if it attempts to do it later, what should the server do? [ynir] A re-authentication is just an ordinary Initial+AUTH exchange. It should be accepted as usual. If it contains an INITIAL-CONTACT, it also erases the old IKE SA (if that still exists) > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of > Bernard Aboba > Sent: Saturday, December 24, 2005 4:46 AM > To: IPsec WG > Subject: [Ipsec] Review of draft-nir-ikev2-auth-lt-04.txt > > In general, this specification appears to be ok, but there are > places where the language could be cleaned up. > > Section 1 > > "However, in the remote access scenario it is usually up to a human > user to supply the authentication credentials, and often EAP is used > for authentication, which makes it unreasonable or impossible for the > remote access gateway to initiate the exchange." > > This statement is misleading. > > In EAP, re-authentication (like authentication) is initiated by the > authenticator sending an EAP-Request. So it is not correct to imply > that EAP "makes it unreasonable or impossible for the remote > access gateway to initiate the exchange". > > In IKEv2, the desire to do EAP authentication is indicated > by the initiator leaving out the AUTH payload from message 3. > The responder then can send an EAP payload in message 4. > However, no mechanism is specified to enable a responder > to initiate an EAP re-authentication. > > As noted in draft-eronen-ipsec-ikev2-clarifications, Section 5.2: > > " While creation of a new IKE_SA can be initiated by either party > (initiator or responder in the original IKE_SA), the use of EAP > authentication and/or configuration payloads means in practice that > reauthentication has to be initiated by the same party as the > original IKE_SA. IKEv2 does not currently allow the responder to > request reauthentication in this case; however, there is ongoing work > to add this functionality [ReAuth]." > > Given that this is not an EAP issue, but rather an IKEv2 issue, it > might be helpful for the document to explain why it has chosen > not to "allow the responder to request reauthentication" as implied > in the above passage, opting for the lifetime approach instead. Is > this because it is not clear exactly how a responder-initiated EAP > re-authentication would proceed (e.g. no state machine for > IKEv2/EAP interactions)? > > Section 2 > > "The Responder MUST send this information to the Initiator in an > AUTH_LIFETIME notification either in the last message of an IKE_AUTH > exchange, or in a separate Informational exchange, which can be sent > at any time." > > In AAA, the Session-Time attribute is typically used to control > EAP re-authentication. Since this attribute is sent along with > EAP keying material, it is not known until EAP authentication > has completed (e.g. at the time the EAP-Success message is > sent). This means that during an initial authentication, > AUTH_LIFETIME cannot be communicated at any time; this can > only occur during re-authentication, because the Session-Time > attribute has presumably been cached on the remote access > gateway. This needs to be clarified. > > Section 4 > > "IKEv2 implementations that do not support the AUTH_LIFETIME > notification will ignore it and will not repeat the authentication. In > that case the original Responder will send a Delete notification for > the IKE SA in an Informational exchange. Such implementations may > be configured manually to repeat the authentication periodically." > > I'd suggest that this paragraph needs to be stronger. If the > maximum re-authentication time expires (e.g. Session-Timeout attribute) > and the Initiator has not initiated re-authentication, then the > Responder SHOULD send a Delete notification. > > 5. Security Considerations > > "The AUTH_LIFETIME notification sent by the Responder does not override > any security policy on the Initiator. In particular, the Initiator may > have a different policy regarding re-authentication, requiring more > frequent re-authentication. Such an Initiator can repeat the > authentication earlier then is required by the notification." > > This paragraph suggests that an Initiator complying with this > specification can ignore the AUTH_LIFETIME notification entirely. That > seems odd. Shouldn't an Initiator compliant with this specification be > required to initiatie re-authentication no later than specified in the > AUTH_LIFETIME notification? > > _______________________________________________ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf > > _______________________________________________ > 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 Dec 29 16:42:22 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es5XS-00020S-HJ; Thu, 29 Dec 2005 16:42:22 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es5XR-0001zr-1J for ipsec@megatron.ietf.org; Thu, 29 Dec 2005 16:42:21 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21519 for ; Thu, 29 Dec 2005 16:41:10 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Es5bk-0005ll-Sq for ipsec@ietf.org; Thu, 29 Dec 2005 16:46:49 -0500 Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBTLgCTe099442 for ; Thu, 29 Dec 2005 13:42:13 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 29 Dec 2005 13:34:46 -0800 To: IPsec WG From: Internet-Drafts@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.3 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 Subject: [Ipsec] I-D ACTION:draft-hoffman-ikev2-1-00.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Internet Key Exchange Protocol: IKEv2.1 Author(s) : P. Hoffman Filename : draft-hoffman-ikev2-1-00.txt Pages : 120 Date : 2005-12-29 This document describes version 2.1 of the Internet Key Exchange (IKE) protocol. IKEv2.1 is heavily based on IKEv2 from RFC 4306 (edited by Charlie Kaufman), and includes all of the clarifications from the "IKEv2 Clarifications" document (edited by Pasi Eronen and Paul Hoffman). IKEv2.1 makes additional changes to those two documents in places where IKEv2 was unclear and the clarifications document did not commit to a particular protocol interpretation. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoffman-ikev2-1-00.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-hoffman-ikev2-1-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-hoffman-ikev2-1-00.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. [The following attachment must be fetched by mail. Command-click the URL below and send the resulting message to get the attachment.] [The following attachment must be fetched by ftp. Command-click the URL below to ask your ftp client to fetch it.] _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/i-d-announce _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Dec 29 16:42:23 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es5XT-00021p-P1; Thu, 29 Dec 2005 16:42:23 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es5XS-00020M-1F for ipsec@megatron.ietf.org; Thu, 29 Dec 2005 16:42:22 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21522 for ; Thu, 29 Dec 2005 16:41:11 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Es5bk-0005ln-Su for ipsec@ietf.org; Thu, 29 Dec 2005 16:46:50 -0500 Received: from [10.20.30.249] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBTLgCTg099442 for ; Thu, 29 Dec 2005 13:42:14 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 29 Dec 2005 13:41:59 -0800 To: IPsec WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7655788c23eb79e336f5f8ba8bce7906 Subject: [Ipsec] First draft of IKEv2.1 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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. Some VPNC members have complained about having to jump back and forth between the IKEv2 Clarifications document with the IKEv2 RFC. At the same time, they also have said that they don't like the SHOULDs in IKEv2 that have nothing to do with interoperability. To that end, I have created a new document, for IKEv2.1. The first draft is at . Its main purpose is to fix the above two problems, but it can also be a springboard for needed core features that are not clarifications. The version number is 2.1 because some of the normative requirements (SHOULD and MUST) have changed. So far, there are no bits-on-the-wire changes, although it is believable that some will be introduced (such as new notifications) before the document is done. Of course, I am open to comments and suggestions on improving the document. Given that we are starting to see IKEv2 implementations in the market, it would be good to close this document within a few months so that new implementers can go straight to version 2.1. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Dec 29 18:19:05 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es733-00065G-RY; Thu, 29 Dec 2005 18:19:05 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es732-000658-1M for ipsec@megatron.ietf.org; Thu, 29 Dec 2005 18:19:04 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA00495 for ; Thu, 29 Dec 2005 18:17:52 -0500 (EST) Received: from mail3.exchange.microsoft.com ([131.107.76.156]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Es77H-0000Iy-K4 for ipsec@ietf.org; Thu, 29 Dec 2005 18:23:33 -0500 Received: from df-gwy-05.exchange.corp.microsoft.com ([157.54.63.146]) by mail3.exchange.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Dec 2005 15:18:48 -0800 Received: from df-hub-02.exchange.corp.microsoft.com (157.54.70.52) by df-gwy-05.exchange.corp.microsoft.com (157.54.63.146) with Microsoft SMTP Server id 8.0.462.17; Thu, 29 Dec 2005 23:18:47 +0000 Received: from df-hub-01.exchange.corp.microsoft.com ([157.54.69.171]) by df-hub-02.exchange.corp.microsoft.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Dec 2005 15:18:47 -0800 Received: from df-bhd-02.exchange.corp.microsoft.com ([157.54.4.151]) by df-hub-01.exchange.corp.microsoft.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.1830); Thu, 29 Dec 2005 15:18:46 -0800 From: Charlie Kaufman To: Paul Hoffman Date: Thu, 29 Dec 2005 15:18:42 -0800 Subject: RE: [Ipsec] First draft of IKEv2.1 Thread-Topic: [Ipsec] First draft of IKEv2.1 Thread-Index: AcYMwQo8lMLMfeN7ScC1RjTyEfv6GQACQf6g Message-ID: In-Reply-To: Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalReceiveConnectorType: FromLocal X-GlobalRulesExecuted: True X-InternalOrExternalRulesExecuted: True X-OriginalArrivalTime: 29 Dec 2005 23:18:46.0982 (UTC) FILETIME=[380D2660:01C60CCE] x-microsoft-aal: 31 x-microsoft-cal: 13 x-microsoft-multilevel-authmechanism: Custom X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Content-Transfer-Encoding: quoted-printable Cc: "ipsec@ietf.org" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I haven't read this carefully yet, but I have a couple of related concerns: If this document is limited to clarifications and truly minor revisions, th= en it should not change the version number from 2.0 to 2.1. The semantics o= f such a change are defined in the v2.0 document. Changing to 2.1 implies t= hat the recipient should do something differently when seeing the 2.1 than = when seeing the 2.0. If there is such a change, it should be carefully docu= mented (e.g. if there were some new notification types that should only be = sent to someone who agreed to speak version 2.1). A related concern is that if there are going to be changes that are likely = to affect interoperability, I would not expect we could sneak this through = without re-forming a working group to review it. Some of your SHOULD vs. MU= ST changes were hard fought at the time (and I believe in some cases I want= ed to make some of the changes you propose and was told not to by the worki= ng group). It would be good to have a new base document for the next round of substant= ive changes to IKE and for that document to include the explanation of mino= r version number negotiation, but I wouldn't expect such a document to move= forward any time soon. It would also be good to have a document that merge= s the original IKEv2 document with your clarifications - possibly as annota= tions, or possibly as integrated text. But we are still early in deployment= , and I would expect that document would be updated frequently over the nex= t few years. --Charlie -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of P= aul Hoffman Sent: Thursday, December 29, 2005 1:42 PM To: IPsec WG Subject: [Ipsec] First draft of IKEv2.1 Greetings again. Some VPNC members have complained about having to jump bac= k and forth between the IKEv2 Clarifications document with the IKEv2 RFC. A= t the same time, they also have said that they don't like the SHOULDs in IK= Ev2 that have nothing to do with interoperability. To that end, I have created a new document, for IKEv2.1. The first draft is= at .=20 Its main purpose is to fix the above two problems, but it can also be a spr= ingboard for needed core features that are not clarifications.=20 The version number is 2.1 because some of the normative requirements (SHOUL= D and MUST) have changed. So far, there are no bits-on-the-wire changes, al= though it is believable that some will be introduced (such as new notificat= ions) before the document is done. Of course, I am open to comments and suggestions on improving the document.= Given that we are starting to see IKEv2 implementations in the market, it = would be good to close this document within a few months so that new implem= enters can go straight to version 2.1. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec g/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Dec 29 20:05:12 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es8hk-0004UD-FT; Thu, 29 Dec 2005 20:05:12 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Es8hi-0004Tk-9Z for ipsec@megatron.ietf.org; Thu, 29 Dec 2005 20:05:10 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA09992 for ; Thu, 29 Dec 2005 20:03:58 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1Es8m3-0003UF-W3 for ipsec@ietf.org; Thu, 29 Dec 2005 20:09:40 -0500 Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBU153FB018482 for ; Thu, 29 Dec 2005 17:05:04 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 29 Dec 2005 16:58:30 -0800 To: "ipsec@ietf.org" From: Paul Hoffman Subject: RE: [Ipsec] First draft of IKEv2.1 Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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:18 PM -0800 12/29/05, Charlie Kaufman wrote: >If this document is limited to clarifications and truly minor revisions, It is not. There are many places where the 2.0 spec was unclear, leaving implementers with multiple ways to attempt to do something; the version 2.1 spec says exactly how to do them, often with MUST-level language. > then it should not change the version number from 2.0 to 2.1. The >semantics of such a change are defined in the v2.0 document. Correct. It says: The minor version number indicates new capabilities, and MUST be ignored by a node with a smaller minor version number, but used for informational purposes by the node with the larger minor version number. Adding new MUST-level methods is a new capability. >Changing to 2.1 implies that the recipient should do something >differently when seeing the 2.1 than when seeing the 2.0. If there >is such a change, it should be carefully documented (e.g. if there >were some new notification types that should only be sent to someone >who agreed to speak version 2.1). All of the changes are fairly clearly labelled in the document. The labelling makes it a bit harder to read, and thus may change in a later draft, but right now it is fairly easy to find every non-trivial change by searching for "{{". >A related concern is that if there are going to be changes that are >likely to affect interoperability, I would not expect we could sneak >this through without re-forming a working group to review it. Some >of your SHOULD vs. MUST changes were hard fought at the time (and I >believe in some cases I wanted to make some of the changes you >propose and was told not to by the working group). It is up to the ADs if they want to re-form the WG. Many other protocols have continued to develop after their WGs shut down, while some have had the WG started up. Given that this mailing list is still alive and active, and given that there are many active developers and a fair amount of interoperability testing going on, there may not be much need to form a WG. >It would be good to have a new base document for the next round of >substantive changes to IKE and for that document to include the >explanation of minor version number negotiation, but I wouldn't >expect such a document to move forward any time soon. It would also >be good to have a document that merges the original IKEv2 document >with your clarifications - possibly as annotations, or possibly as >integrated text. But we are still early in deployment, and I would >expect that document would be updated frequently over the next few >years. The IKEv2 implementers have shaken out the unclear parts fairly well so far. For example, after the first IKEv2 bakeoff, there was a slew of additions to the clarifications document; after the second bakeoff, there were almost none. We have gotten almost no new input to the clarifications document in the past few months. It does not benefit the users to have a version hanging in limbo for years if the version is fairly complete. On the other hand, if my opening version 2.1 brings out a lot more additions and changes to the core IKEv2 protocol, we should work on them until it is complete. But those may not be likely, given the past six months of relative quiet. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Dec 30 03:23:02 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsFXS-0001qt-Ln; Fri, 30 Dec 2005 03:23:02 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsFXP-0001pC-Od for ipsec@megatron.ietf.org; Fri, 30 Dec 2005 03:22:59 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA17707 for ; Fri, 30 Dec 2005 03:21:47 -0500 (EST) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsFbn-000052-Vn for ipsec@ietf.org; Fri, 30 Dec 2005 03:27:33 -0500 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id E3FFF898BA; Fri, 30 Dec 2005 10:22:32 +0200 (EET) Message-ID: <43B4EDFF.6080905@kolumbus.fi> Date: Fri, 30 Dec 2005 10:21:19 +0200 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Paul Hoffman Subject: Re: [Ipsec] First draft of IKEv2.1 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: 7baded97d9887f7a0c7e8a33c2e3ea1b Content-Transfer-Encoding: 7bit Cc: IPsec WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Paul Hoffman wrote: > Greetings again. Some VPNC members have complained about having to > jump back and forth between the IKEv2 Clarifications document with the > IKEv2 RFC. At the same time, they also have said that they don't like > the SHOULDs in IKEv2 that have nothing to do with interoperability. > > To that end, I have created a new document, for IKEv2.1. The first > draft is at > . Great! That was fast. > Of course, I am open to comments and suggestions on improving the > document. Given that we are starting to see IKEv2 implementations in > the market, it would be good to close this document within a few > months so that new implementers can go straight to version 2.1. I agree. > Its main purpose is to fix the above two problems, but it can also be > a springboard for needed core features that are not clarifications. I am very much in favor of speedy publication of an RFC that combines clarifications and the base spec. And I agree that the time for that is now. But I am a bit more sceptical about new features. Also, I'm not quite sure what you meant with "don't like the SHOULDs in IKEv2" part, and wonder if this is perhaps more of a "change" than a clarification. But I guess I have to read the document to find out exactly what was changed. I do realize that to fix some underspecified things you have to add new SHOULD/MUST language, and this is fine - I still consider it a clarification. But did you want to go beyond this? Anyway, I think it might be an idea to just do the clarifications and let new features be in other extension RFCs; new features tend to take longer to develop, and from what I can see you already have quite a bit of material just because of the clarifications. --Jari _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Dec 30 05:21:49 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsHOP-0001sp-Gs; Fri, 30 Dec 2005 05:21:49 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsHON-0001oe-G6 for ipsec@megatron.ietf.org; Fri, 30 Dec 2005 05:21:47 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA28438 for ; Fri, 30 Dec 2005 05:20:36 -0500 (EST) Received: from fireball.acr.fi ([83.145.195.1] helo=mail.kivinen.iki.fi) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsHSo-0003oT-0j for ipsec@ietf.org; Fri, 30 Dec 2005 05:26:22 -0500 Received: from fireball.acr.fi (localhost [IPv6:::1]) by mail.kivinen.iki.fi (8.13.4/8.12.10) with ESMTP id jBUALfQs006454 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 30 Dec 2005 12:21:41 +0200 (EET) Received: (from kivinen@localhost) by fireball.acr.fi (8.13.4/8.12.11) id jBUALeQm011851; Fri, 30 Dec 2005 12:21:40 +0200 (EET) X-Authentication-Warning: fireball.acr.fi: kivinen set sender to kivinen@iki.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17333.2612.897494.636076@fireball.acr.fi> Date: Fri, 30 Dec 2005 12:21:40 +0200 From: Tero Kivinen To: Paul Hoffman Subject: RE: [Ipsec] First draft of IKEv2.1 In-Reply-To: References: X-Mailer: VM 7.17 under Emacs 21.4.1 X-Edit-Time: 18 min X-Total-Time: 19 min X-Spam-Score: 0.0 (/) X-Scan-Signature: 825e642946eda55cd9bc654a36dab8c2 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 Paul Hoffman writes: > At 3:18 PM -0800 12/29/05, Charlie Kaufman wrote: > >If this document is limited to clarifications and truly minor revisions, > > It is not. There are many places where the 2.0 spec was unclear, > leaving implementers with multiple ways to attempt to do something; > the version 2.1 spec says exactly how to do them, often with > MUST-level language. If the 2.0 spec was written so that no interoperable versions can be written using that text, then adding MUST or SHOULDs to make it able to write interoperable versions isn't really a change, but clarification. I think the question is: Do the v2.1 implementation do something differently when he notices other end is v2.0 or not? If the answer is no, v2.1 does not need to do anything differently when other end is v2.0 or whether it is v2.1 version then I do not think we need to update the version number. > > then it should not change the version number from 2.0 to 2.1. The > >semantics of such a change are defined in the v2.0 document. > > Correct. It says: > > The minor > version number indicates new capabilities, and MUST be ignored by a > node with a smaller minor version number, but used for informational > purposes by the node with the larger minor version number. So in what places the v2.1 version needs to act differently when the other end is v2.0 version? > Adding new MUST-level methods is a new capability. Adding MUST level to the sending part but still allowing other options when receiving (i.e. say you MUST send xxx, but MUST also accept yyy when receiving). > >Changing to 2.1 implies that the recipient should do something > >differently when seeing the 2.1 than when seeing the 2.0. If there > >is such a change, it should be carefully documented (e.g. if there > >were some new notification types that should only be sent to someone > >who agreed to speak version 2.1). Actually new notification types do NOT need version number change. There is already text in the document saying that unknown notification types are ignored, and we normally use them as one way notifications, and things are agreed only when we see the other end sending such notification back (for example when both ends have sent and received USE_TRANSPRORT_MODE). Just adding new notification type does not normally require updating version number. > All of the changes are fairly clearly labelled in the document. The > labelling makes it a bit harder to read, and thus may change in a > later draft, but right now it is fairly easy to find every > non-trivial change by searching for "{{". Good, need to check that document soon. > Given that this mailing list is still alive and active, and given > that there are many active developers and a fair amount of > interoperability testing going on, there may not be much need to form > a WG. I think the question is do we want to do separate interoperability tests for v2.1? Or do we simply assume that we do IKEv2 interoperability tests, and that can be done with both v2.0 and v2.1 implementations. I myself would like to see only v2.0 versions out there, and this document only as a clarification explaining and modifying only things that were non-interoperable with base RFC4306 spec. If there is no need for the other end to know whether the other end support v2.1 or v2.0, then I would leave that thing out. Leaving the version number to 2.0 would also make it clear that no new features are allowed, and no bits on the wire can be changed. Also we cannot allow something that was forbidden and working by RFC4306. On the other hand if something was so there was no way to make interoperable version based on the RFC4306, then it really does not matter if we change that, as we cannot break interoperable versions. > The IKEv2 implementers have shaken out the unclear parts fairly well > so far. For example, after the first IKEv2 bakeoff, there was a slew > of additions to the clarifications document; after the second > bakeoff, there were almost none. We have gotten almost no new input > to the clarifications document in the past few months. One reason for that is that we are through the basic tests, but there are still cases which will cause changes when we start testing more complicated things. Things like the thread here in the list few weeks ago about the delete payloads to unknown SPIs and what error message to send back and so on. > It does not benefit the users to have a version hanging in limbo for > years if the version is fairly complete. On the other hand, if my > opening version 2.1 brings out a lot more additions and changes to > the core IKEv2 protocol, we should work on them until it is complete. > But those may not be likely, given the past six months of relative > quiet. I still think we should keep the version number 2.0 if we can do that, i.e. is there something now in the document that did work with base RFC4306 spec in interoperable way, but which is done differently on your draft? I do not care about cases which you could not make interoperable versions based on RFC4306. -- kivinen@safenet-inc.com _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Fri Dec 30 11:33:13 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsNBp-0003Rb-9Q; Fri, 30 Dec 2005 11:33:13 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsNBn-0003RK-EB for ipsec@megatron.ietf.org; Fri, 30 Dec 2005 11:33:11 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10702 for ; Fri, 30 Dec 2005 11:32:00 -0500 (EST) Received: from wproxy.gmail.com ([64.233.184.207]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsNGG-0000GM-KG for ipsec@ietf.org; Fri, 30 Dec 2005 11:37:49 -0500 Received: by wproxy.gmail.com with SMTP id i20so1815447wra for ; Fri, 30 Dec 2005 08:33:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:mime-version:content-type; b=WUNnCAuJ/IO8DsXuXw1pEXKf1dTHhYm5ElTJisgutLKBrM5ze4cM2V5KrzBkyKxKz7UG9kLGaj5SxR+EYXp5TH1CN6fH/pTSdljoWBaOkmznTHCBiFVsTVqLsaD+CWhCECJ+rfpaS7pM9eEf3B8rmr8Da54IcRIiVanKVO6DFjw= Received: by 10.65.200.7 with SMTP id c7mr4257685qbq; Fri, 30 Dec 2005 08:33:07 -0800 (PST) Received: by 10.64.220.6 with HTTP; Fri, 30 Dec 2005 08:33:07 -0800 (PST) Message-ID: Date: Sat, 31 Dec 2005 00:33:07 +0800 From: Wade To: ipsec@ietf.org, ipsec-tools-devel@lists.sourceforge.net MIME-Version: 1.0 X-Spam-Score: 0.1 (/) X-Scan-Signature: 3e15cc4fdc61d7bce84032741d11c8e5 Cc: Subject: [Ipsec] is there any idea on ipsec HA? X-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="===============0121382394==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0121382394== Content-Type: multipart/alternative; boundary="----=_Part_745_8438714.1135960387221" ------=_Part_745_8438714.1135960387221 Content-Type: text/plain; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable hello, The Ipsec high availability is one of requirement of people. Usually w= e use two security gateways, one acting as a master and another acting as a standby SG. I got a question on the packet sequence number, should the master SG send every packet to standby SG? The sequence number is used by anti-reply, if we don't bakeup it, when the master SG is halt for some reason the remot= e peer won't accept the packet which received from the backup SG because the packet SN won't pass the anti-reply checking mechanism. But to backup every packet is impossible, it's take too much throughput.. If we don't want to disable the anti-replay, is there any advice to solve this problem? Thanks Huide ------=_Part_745_8438714.1135960387221 Content-Type: text/html; charset=ISO-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable
hello,
 
     The Ipsec high availability is one of re= quirement of people. Usually we use two security gateways, one acting = as a master and another acting as a standby SG. 
     I got a question on the packet sequence numbe= r,  should the master SG send every packet to standby SG? The seq= uence number is used by anti-reply, if we don't bakeup it, when the master = SG is halt for some reason the remote peer won't accept the packet which re= ceived from the backup SG because the packet SN won't pass the anti-re= ply checking mechanism. But to backup every packet is impossible, it's take= too much throughput..
 
     If we don't want to disable the anti-replay,&= nbsp; is there any advice to solve this problem?
 
 
Thanks
 
Huide
------=_Part_745_8438714.1135960387221-- --===============0121382394== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec --===============0121382394==-- From ipsec-bounces@ietf.org Fri Dec 30 12:50:04 2005 Received: from localhost.cnri.reston.va.us ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsOOC-00007F-Px; Fri, 30 Dec 2005 12:50:04 -0500 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1EsOOA-00006J-Rl for ipsec@megatron.ietf.org; Fri, 30 Dec 2005 12:50:02 -0500 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19857 for ; Fri, 30 Dec 2005 12:48:50 -0500 (EST) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1EsOSe-00039J-7m for ipsec@ietf.org; Fri, 30 Dec 2005 12:54:41 -0500 Received: from [10.20.30.249] (dsl2-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id jBUHnoW7070309 for ; Fri, 30 Dec 2005 09:49:53 -0800 (PST) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <17333.2612.897494.636076@fireball.acr.fi> References: <17333.2612.897494.636076@fireball.acr.fi> Date: Fri, 30 Dec 2005 09:49:49 -0800 To: "ipsec@ietf.org" From: Paul Hoffman Subject: RE: [Ipsec] First draft of IKEv2.1 Content-Type: text/plain; charset="us-ascii" ; format="flowed" 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 At 12:21 PM +0200 12/30/05, Tero Kivinen wrote: >Paul Hoffman writes: >> At 3:18 PM -0800 12/29/05, Charlie Kaufman wrote: >> >If this document is limited to clarifications and truly minor revisions, >> >> It is not. There are many places where the 2.0 spec was unclear, >> leaving implementers with multiple ways to attempt to do something; >> the version 2.1 spec says exactly how to do them, often with >> MUST-level language. > >If the 2.0 spec was written so that no interoperable versions can be >written using that text, then adding MUST or SHOULDs to make it able >to write interoperable versions isn't really a change, but >clarification. Do other implementers agree with this assessment? If so, it would be fine to keep the 2.0 numbering. Before answering, *please* read the actual document (ahem) and look at each change. If we don't change the minor version number, some implementations will be going by RFC 4306 SHOULD/MUST rules (which were confusing in many cases), and other implementations will be going by the new SHOULD/MUST rules, and there will be no indication which is which. If there is a MUST in the new document where there was a SHOULD in the old document, there is essentially no point to making the MUST to increase interoperability. If what people want is just the clarifications rolled in with no actual increased interoperability, that's fine and easy to do, but that is not what I heard from many implementers. Maybe seeing all the changes in one place will help that decision. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec