From ipsec-bounces@ietf.org Thu Jun 02 00:26:43 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdhI3-0002aK-QF; Thu, 02 Jun 2005 00:26:43 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdhI1-0002Yp-Vz for ipsec@megatron.ietf.org; Thu, 02 Jun 2005 00:26:42 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA09121 for ; Thu, 2 Jun 2005 00:26:38 -0400 (EDT) Received: from ip-66-80-10-146.dsl.sca.megapath.net ([66.80.10.146] helo=guri.intoto.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Ddhbz-0002wu-AL for ipsec@ietf.org; Thu, 02 Jun 2005 00:47:19 -0400 Received: from brahma.intotoind.com ([172.16.1.10]) by guri.intoto.com (SMSSMTP 4.0.0.59) with SMTP id M2005060121254828174 ; Wed, 01 Jun 2005 21:25:49 -0700 Received: from suresh.intoto.com (1mc31.intotoind.com [172.16.1.31]) by brahma.intotoind.com (8.12.11/8.12.8) with ESMTP id j524QXjU023614; Thu, 2 Jun 2005 09:56:34 +0530 Message-Id: <6.2.1.2.0.20050602093601.01df7db8@172.16.1.10> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Thu, 02 Jun 2005 09:56:34 +0530 To: ipsec@ietf.org From: Suram Chandra Sekhar Mime-Version: 1.0 X-Scanned-By: MIMEDefang 2.41 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7da5a831c477fb6ef97f379a05fb683c Cc: paul.hoffman@vpnc.org Subject: [Ipsec] Doubt regarding Encoding method for RSA signatures X-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="===============0693570402==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0693570402== Content-Type: multipart/alternative; boundary="=====================_5024905==.ALT" --=====================_5024905==.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, I have a question on Encoding method for RSA signature as specified in the ikev2-clarification-document. In Section 2.2, Note that unlike IKEv1, IKEv2 uses the PKCS#1 v1.5 [PKCS1v20] signature encoding method (see next section for details), which includes the algorithm identifier for the hash algorithm. Here it is said that IKEv2 uses the PKCS#1 v1.5. The next section Section 2.3 specifies as follows... The current version of PKCS#1 (v2.1) [PKCS1v21] defines two different encoding methods (ways of "padding the hash") for signatures. However, IKEv2 points to the older PKCS#1 v2.0 [PKCS1v20]. That version has only one encoding method for signatures (EMSA-PKCS1-v1_5), and thus there is no ambiguity. In this section it is said that IKEv2 points to the older PKCS#1 v2.0. Is this a typo or both the versions are same?? The next question is PKCS#1v2.0 (rfc 2437) is obsoleted by PKCS#1v2.1 (rfc 3447). The problem is that, for the encoding method EMSA-PKCS1-v1_5 looks different in both the versions. Section 9.2.1 of PKCS#1 v2.0 (rfc 2437) specifies the padding to form the encoded message as follows... 5. Concatenate PS, the DER encoding T, and other padding to form the encoded message EM as: EM = 01 || PS || 00 || T Section 9.2 of PKCS#1v2.1 (rfc 3447) specifies the padding to form the encoded message as follows.. 5. Concatenate PS, the DER encoding T, and other padding to form the encoded message EM as EM = 0x00 || 0x01 || PS || 0x00 || T. In version 2.1 of PKCS#1, the encoding starts with 00 01 where as in version 2.0 of PKCS#1, the encoding starts with 01. I want to know the following things.. 1. Why is it decided to go with an obsoleted rfc. 2. I see there is ambiguity with padding between v2.0 and v2.1 of PKCS#1. Can this be clarified further. I feel it can refer to the new version PKCS#1 v2.1 (rfc 3447) with the encoding method as only EMSA_PKCS1_V1_5. Also as specified in the clarification document, hash function can be recommended to be SHA1. Please clarify on this. Regards Suram --=====================_5024905==.ALT Content-Type: text/html; charset="us-ascii" Hi,
I have a question on Encoding method for RSA signature as specified in the ikev2-clarification-document.

In Section 2.2,
   Note that unlike IKEv1, IKEv2 uses the PKCS#1 v1.5 [PKCS1v20]
   signature encoding method (see next section for details), which
   includes the algorithm identifier for the hash algorithm.

Here it is said that IKEv2 uses the PKCS#1 v1.5.

The next section
Section 2.3 specifies as follows...

   The current version of PKCS#1 (v2.1) [PKCS1v21] defines two different
   encoding methods (ways of "padding the hash") for signatures.
   However, IKEv2 points to the older PKCS#1 v2.0 [PKCS1v20].  That
   version has only one encoding method for signatures
   (EMSA-PKCS1-v1_5), and thus there is no ambiguity.

In this section it is said that IKEv2 points to the older PKCS#1 v2.0.

Is this a typo or both the versions are same??

The next question is PKCS#1v2.0 (rfc 2437) is obsoleted by PKCS#1v2.1 (rfc 3447).

The problem is that, for the encoding method EMSA-PKCS1-v1_5 looks different in both the versions.

Section 9.2.1 of PKCS#1 v2.0 (rfc 2437) specifies the padding to form the encoded message as follows...

  5. Concatenate PS, the DER encoding
T, and other padding to form the
     encoded message EM as: EM = 01 || PS || 00 || T
Section 9.2 of PKCS#1v2.1 (rfc 3447) specifies the padding to form the encoded message as follows..

   5. Concatenate PS, the DER
encoding T, and other padding to form the
      encoded message EM as

         EM = 0x00 || 0x01 || PS
|| 0x00 || T.
In version 2.1 of PKCS#1, the encoding starts with 00 01 where as in version 2.0 of PKCS#1,
the encoding starts with 01.

I want to know the following things..

1. Why is it decided to go with an obsoleted rfc.
2. I see there is ambiguity with padding between v2.0 and v2.1 of PKCS#1.  Can this be clarified further.

I feel it can refer to the new version PKCS#1 v2.1 (rfc 3447) with the encoding method as only EMSA_PKCS1_V1_5.
Also as specified in the clarification document, hash function can be recommended to be SHA1.

Please clarify on this.

Regards
Suram

--=====================_5024905==.ALT-- --===============0693570402== 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 --===============0693570402==-- From ipsec-bounces@ietf.org Thu Jun 02 09:30:45 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdpmX-00049o-Dt; Thu, 02 Jun 2005 09:30:45 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdpmV-00049f-0c for ipsec@megatron.ietf.org; Thu, 02 Jun 2005 09:30:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA13545 for ; Thu, 2 Jun 2005 09:30:41 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ddq6W-0005E1-4C for ipsec@ietf.org; Thu, 02 Jun 2005 09:51:25 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j52DUYM6014204; Thu, 2 Jun 2005 16:30:39 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Jun 2005 16:30:39 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Jun 2005 16:30:38 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] Doubt regarding Encoding method for RSA signatures Date: Thu, 2 Jun 2005 16:30:38 +0300 Message-ID: Thread-Topic: [Ipsec] Doubt regarding Encoding method for RSA signatures Thread-Index: AcVnK58Q33OT1/2fSzqpCp+VYWaAqQAS34zw To: , X-OriginalArrivalTime: 02 Jun 2005 13:30:38.0376 (UTC) FILETIME=[43A7B280:01C56777] X-Spam-Score: 0.3 (/) X-Scan-Signature: 32b73d73e8047ed17386f9799119ce43 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Suram Chandra Sekhar wrote: > > Hi, > I have a question on Encoding method for RSA signature as specified > in the ikev2-clarification-document. >=20 > In Section 2.2, > Note that unlike IKEv1, IKEv2 uses the PKCS#1 v1.5 [PKCS1v20] > signature encoding method (see next section for details), which > includes the algorithm identifier for the hash algorithm. > > Here it is said that IKEv2 uses the PKCS#1 v1.5. >=20 > The next section > Section 2.3 specifies as follows... >=20 > The current version of PKCS#1 (v2.1) [PKCS1v21] defines two different > encoding methods (ways of "padding the hash") for signatures. > However, IKEv2 points to the older PKCS#1 v2.0 [PKCS1v20]. That > version has only one encoding method for signatures > (EMSA-PKCS1-v1_5), and thus there is no ambiguity. > > In this section it is said that IKEv2 points to the older PKCS#1 v2.0. >=20 > Is this a typo or both the versions are same?? IKEv2 uses the "PKCS#1 v1.5" encoding method and signature generation/verification operations; the definition for these can be found in several different documents, including the original PKCS#1 v1.5 (also RFC 2313), v2.0 (also RFC 2437)=20 and v2.1 (also RFC 3447). The "v1.5" signature generation/verification operations defined in all those documents are compatible (but written slightly differently). > The next question is PKCS#1v2.0 (rfc 2437) is obsoleted by=20 > PKCS#1v2.1 (rfc 3447). >=20 > The problem is that, for the encoding method EMSA-PKCS1-v1_5=20 > looks different in both the versions. >=20 > Section 9.2.1 of PKCS#1 v2.0 (rfc 2437) specifies the padding to > form the encoded message as follows... > > 5. Concatenate PS, the DER encoding, and other padding to > form the encoded message EM as:=20 > EM =3D 01 || PS || 00 || T >=20 > Section 9.2 of PKCS#1v2.1 (rfc 3447) specifies the padding to form > the encoded message as follows.. > > 5. Concatenate PS, the DER encoding T, and other padding to=20 > form the encoded message EM as =20 > EM =3D 0x00 || 0x01 || PS || 0x00 || T. > > In version 2.1 of PKCS#1, the encoding starts with 00 01 where as=20 > in version 2.0 of PKCS#1, the encoding starts with 01. Adding zeroes in front of the message does not matter for RSA operations, because they treat the message as a non-negative integer. So if one implementation implements RSA signature generation/verification according to v2.1 and another=20 implementor uses v2.0, they're still compatible. > I want to know the following things.. >=20 > 1. Why is it decided to go with an obsoleted rfc. No reason (or more likely, the reference was put there before RFC 3447 was published, and nobody updated it). The RFC editor might fix the reference to point to the latest version. > 2. I see there is ambiguity with padding between v2.0 and v2.1=20 > of PKCS#1. Can this be clarified further. We'll try to rephrase the text slightly when doing clarifications=20 version -04. > I feel it can refer to the new version PKCS#1 v2.1 (rfc 3447) with > the encoding method as only EMSA_PKCS1_V1_5. Also as specified in > the clarification document, hash function can be recommended to be > SHA1. >=20 > Please clarify on this. > > Regards > Suram Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jun 02 17:47:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdxXE-0005mB-Cw; Thu, 02 Jun 2005 17:47:28 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdxXC-0005m6-RT for ipsec@megatron.ietf.org; Thu, 02 Jun 2005 17:47:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA03644 for ; Thu, 2 Jun 2005 17:47:24 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DdxrJ-0002H4-DB for ipsec@ietf.org; Thu, 02 Jun 2005 18:08:13 -0400 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 j52LlO9D033586 for ; Thu, 2 Jun 2005 14:47:24 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 2 Jun 2005 14:47:19 -0700 To: ipsec@ietf.org From: Internet-Drafts@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.3 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Subject: [Ipsec] I-D ACTION:draft-eronen-ipsec-ikev2-clarifications-03.txt X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : IKEv2 Clarifications and Implementation Guidelines Author(s) : P. Hoffman, P. Eronen Filename : draft-eronen-ipsec-ikev2-clarifications-03.txt Pages : 43 Date : 2005-6-2 This document clarifies many areas of the IKEv2 specification. It does not to introduce any changes to the protocol, but rather provides descriptions that are less prone to ambiguous interpretations. The purpose of this document is to encourage the development of interoperable implementations. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-eronen-ipsec-ikev2-clarifications-03.txt To remove yourself from the I-D Announcement list, send a message to i-d-announce-request@ietf.org with the word unsubscribe in the body of the message. You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce to change your subscription settings. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-eronen-ipsec-ikev2-clarifications-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-eronen-ipsec-ikev2-clarifications-03.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 Jun 02 17:56:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdxgE-0001w8-3S; Thu, 02 Jun 2005 17:56:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DdxgC-0001w3-OO for ipsec@megatron.ietf.org; Thu, 02 Jun 2005 17:56:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04163 for ; Thu, 2 Jun 2005 17:56:42 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Ddy0J-0002Tf-E9 for ipsec@ietf.org; Thu, 02 Jun 2005 18:17:31 -0400 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 j52LugkV034297 for ; Thu, 2 Jun 2005 14:56:43 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 2 Jun 2005 14:56:40 -0700 To: IPsec WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 7a6398bf8aaeabc7a7bb696b6b0a2aad Subject: [Ipsec] IKEv2 Clarifications and Implementation Guidelines, draft -03 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Greetings again. Pasi and I have revised many parts of the clarifications document based on feedback we have received from the mailing list and offline. We also added an informational appendix listing all the exchanges. All IKEv2 implementers should review the document and let us know if they find anything that needs changing. We would certainly like to hear feedback on the new appendix. We will start feeding open issues to the mailing list in the near future, but we're happy to hear comments in the meantime. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 08 12:07:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg35Z-0002mi-88; Wed, 08 Jun 2005 12:07:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dg35X-0002mX-4W for ipsec@megatron.ietf.org; Wed, 08 Jun 2005 12:07:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA12444 for ; Wed, 8 Jun 2005 12:07:28 -0400 (EDT) Received: from woodstock.binhost.com ([144.202.243.4]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dg3Qo-00085b-2C for ipsec@ietf.org; Wed, 08 Jun 2005 12:29:31 -0400 Received: (qmail 29697 invoked by uid 0); 8 Jun 2005 15:55:21 -0000 Received: from unknown (HELO Russ-Laptop.vigilsec.com) (138.88.14.207) by woodstock.binhost.com with SMTP; 8 Jun 2005 15:55:21 -0000 Message-Id: <6.2.1.2.2.20050608115200.05cf80d0@mail.binhost.com> X-Mailer: QUALCOMM Windows Eudora Version 6.2.1.2 Date: Wed, 08 Jun 2005 11:55:18 -0400 To: ipsec@ietf.org From: Russ Housley Mime-Version: 1.0 X-Spam-Score: 1.1 (+) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab Subject: [Ipsec] CMAC Documents X-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="===============0482337220==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0482337220== Content-Type: text/html; charset="us-ascii" Dear IPsec Mail List:

I am going to shepherd these documents.  As a first step, I would appreciate your review and comment.

Thanks,
  Russ


Hi Russ Housley,

We have I-Ds which are AES-CMAC usage on IPsec, but it has no workgroup since IPsec workgroup completed last April.

Can you possibly shepherd it for standard track publication?

http://www.ietf.org/internet-drafts/draft-songlee-aes-cmac-96-02.txt
http://www.ietf.org/internet-drafts/draft-songlee-aes-cmac-prf-128-00.txt

Thanks,
Jun Hyuk Song
--===============0482337220== 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 --===============0482337220==-- From ipsec-bounces@ietf.org Thu Jun 09 10:01:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgNbB-0006QA-Sn; Thu, 09 Jun 2005 10:01:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DgNb9-0006Q5-FZ for ipsec@megatron.ietf.org; Thu, 09 Jun 2005 10:01:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02504 for ; Thu, 9 Jun 2005 10:01:29 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext03.nokia.com ([131.228.20.95]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DgNwb-0004cf-K3 for ipsec@ietf.org; Thu, 09 Jun 2005 10:23:43 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext03.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j59Dx1ow025030; Thu, 9 Jun 2005 16:59:01 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Jun 2005 17:01:05 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 9 Jun 2005 17:01:05 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] CMAC Documents Date: Thu, 9 Jun 2005 17:01:04 +0300 Message-ID: Thread-Topic: [Ipsec] CMAC Documents Thread-Index: AcVsRQGhqfMrSzSVQEGpB9senNl67gAtmPag To: , X-OriginalArrivalTime: 09 Jun 2005 14:01:05.0547 (UTC) FILETIME=[ADA01DB0:01C56CFB] X-Spam-Score: 0.3 (/) X-Scan-Signature: 0ddefe323dd869ab027dbfff7eff0465 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org A comment about draft-songlee-aes-cmac-prf-128-00:=20 Some features of IKEv2 work, well, poorly with PRFs that require a fixed size key (see draft-eronen-ipsec-ikev2- clarifications-03, Sections 2.8, 2.9, and 3.5 for details). Currently we have only one such PRF (AES-XCBC-PRF-128), but=20 there's work ongoing (draft-hoffman-rfc3664bis-02) to remove=20 the fixed key size restriction from XCBC-MAC (by specifying=20 how to get a 128-bit key from a shorter or longer key). I think it would be useful to include such processing in CMAC-PRF as well (so from IKEv2 point of view, it would accept a key of arbitrary length). Best regards, Pasi (BTW, the draft also needs an IANA considerations section.) > -----Original Message----- > From: Russ Housley > Sent: Wednesday, June 08, 2005 6:55 PM > To: ipsec@ietf.org > Subject: [Ipsec] CMAC Documents >=20 > Dear IPsec Mail List: >=20 > I am going to shepherd these documents. As a first step, I=20 > would appreciate your review and comment. >=20 > Thanks, > Russ >=20 >=20 > > Hi Russ Housley, >=20 > We have I-Ds which are AES-CMAC usage on IPsec, but it has no > workgroup since IPsec workgroup completed last April. > > Can you possibly shepherd it for standard track publication? > > http://www.ietf.org/internet-drafts/draft-songlee-aes-cmac-96-02.txt=20 > = http://www.ietf.org/internet-drafts/draft-songlee-aes-cmac-prf-128-00.txt= =20 >=20 > Thanks, > Jun Hyuk Song=20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 14 15:26:15 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiH39-0008Hz-JB; Tue, 14 Jun 2005 15:26:15 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiH37-0008Ho-Ug for ipsec@megatron.ietf.org; Tue, 14 Jun 2005 15:26:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA22742 for ; Tue, 14 Jun 2005 15:26:12 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiHPd-00017Q-Jz for ipsec@ietf.org; Tue, 14 Jun 2005 15:49:31 -0400 Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5EJQ5qt056490 for ; Tue, 14 Jun 2005 12:26:05 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 14 Jun 2005 12:26:00 -0700 To: IPsec WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 Subject: [Ipsec] Changing PRFs when rekeying the IKE_SA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Greetings again. The IKEv2 clarifications document has the following section: 3.5 Changing PRFs when rekeying the IKE_SA When rekeying the IKE_SA, Section 2.18 says that "SKEYSEED for the new IKE_SA is computed using SK_d from the existing IKE_SA as follows: SKEYSEED = prf(SK_d (old), [g^ir (new)] | Ni | Nr)" If the old and new IKE_SA selected a different PRF, it is not clear which PRF should be used. We need to pick one or the other. I propose that we pick the *new* prf, because the two sides have agreed to use it for the new SA. Does anyone have any objections? --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 14 15:34:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiHAu-0001Gx-4s; Tue, 14 Jun 2005 15:34:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiHAs-0001Gr-Id for ipsec@megatron.ietf.org; Tue, 14 Jun 2005 15:34:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA23502 for ; Tue, 14 Jun 2005 15:34:13 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiHXP-0001sr-G5 for ipsec@ietf.org; Tue, 14 Jun 2005 15:57:32 -0400 Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5EJY6xC057157 for ; Tue, 14 Jun 2005 12:34:07 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Tue, 14 Jun 2005 12:34:02 -0700 To: IPsec WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 082a9cbf4d599f360ac7f815372a6a15 Subject: [Ipsec] Traffic selectors violating own policy X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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. The IKEv2 clarifications document has the following section: ----- 4.6 Traffic selectors violating own policy Section 2.9 describes traffic selector negotiation in great detail. One aspect of this negotiation that may need some clarification is that when creating a new SA, the initiator should not propose traffic selectors that violate its own policy. If this rule is not followed, valid traffic may be dropped. This is best illustrated by an example. Suppose that host A has a policy whose effect is that traffic to 192.0.1.66 is sent via host B encrypted using AES, and traffic to all other hosts in 192.0.1.0/24 is also sent via B, but must use 3DES. Suppose also that host B accepts any combination of AES and 3DES. If host A now proposes an SA that uses 3DES, and includes TSr containing (192.0.1.0-192.0.1.0.255), this will be accepted by host B. Now, host B can also use this SA to send traffic from 192.0.1.66, but those packets will be dropped by A since it requires the use of AES for those traffic. Even if host A creates a new SA only for 192.0.1.66 that uses AES, host B may freely continue to use the first SA for the traffic. In this situation, when proposing the SA, host A should have followed its own policy, and included a TSr containing ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead. In general, if (1) the initiator makes a proposal "for traffic X (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator does not actually accept traffic X' with SA, and (3) the initiator would be willing to accept traffic X' with some SA' (!=SAi), valid traffic can be unnecessarily dropped since the responder can apply either SA or SA' to traffic X'. (References: "Question about "narrowing" ..." thread, Feb 2005. "IKEv2 needs a "policy usage mode"..." thread, Feb 2005. "IKEv2 Traffic Selectors?" thread, Feb 2005. "IKEv2 traffic selector negotiation examples", 2004-08-08.) ----- This was a thorny issue when we discussed it earlier this year, but it needs to be resolved. I see three options: a) Say that the situation is unfortunate but a reality b) Add a SHOULD-level prohibition on SAs with traffic selectors that violate their own policy c) Add a MUST-level prohibition on SAs with traffic selectors that violate their own policy First question: are there more options? Second question: do people have a preference between these two options? The second and third seem cleaner but probably will add large overhead for what is clearly a corner case. The first seems unclean but possibly sufficient. Suggestions? --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 14 15:42:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiHIu-0003Bs-R7; Tue, 14 Jun 2005 15:42:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiHIu-0003Bn-1X for ipsec@megatron.ietf.org; Tue, 14 Jun 2005 15:42:32 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24172 for ; Tue, 14 Jun 2005 15:42:30 -0400 (EDT) Received: from brmea-mail-4.sun.com ([192.18.98.36]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiHfP-0002az-0l for ipsec@ietf.org; Tue, 14 Jun 2005 16:05:50 -0400 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by brmea-mail-4.sun.com (8.12.10/8.12.9) with ESMTP id j5EJgOqg011500; Tue, 14 Jun 2005 13:42:24 -0600 (MDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j5EJgOFt018984; Tue, 14 Jun 2005 15:42:24 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j5EJgNXY004840; Tue, 14 Jun 2005 15:42:23 -0400 (EDT) Subject: Re: [Ipsec] Changing PRFs when rekeying the IKE_SA From: Bill Sommerfeld To: Paul Hoffman In-Reply-To: References: Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1118778142.3523.65.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Tue, 14 Jun 2005 15:42:23 -0400 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 798b2e660f1819ae38035ac1d8d5e3ab 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 On Tue, 2005-06-14 at 15:26, Paul Hoffman wrote: > We need to pick one or the other. I propose that we pick the *new* > prf, because the two sides have agreed to use it for the new SA. Does > anyone have any objections? so, cryptographer-types have, in my presence, expressed fairly strong objection to using the same key bits with multiple algorithms on the theory that it constitutes bad practice and might lead to hard-to-analyze weaknesses. in the absence of a clarification that would lead me to assume that I'd should use the old prf/prf+ with the old SK_d to generate the new SKEYSEED. - Bill _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 14 15:46:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiHN4-0003Yk-45; Tue, 14 Jun 2005 15:46:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiHN2-0003Yf-He for ipsec@megatron.ietf.org; Tue, 14 Jun 2005 15:46:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA24515 for ; Tue, 14 Jun 2005 15:46:46 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiHjY-00031C-Ko for ipsec@ietf.org; Tue, 14 Jun 2005 16:10:06 -0400 Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5EJkeDe058145; Tue, 14 Jun 2005 12:46:40 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: In-Reply-To: <1118778142.3523.65.camel@thunk> References: <1118778142.3523.65.camel@thunk> Date: Tue, 14 Jun 2005 12:46:36 -0700 To: Bill Sommerfeld From: Paul Hoffman Subject: Re: [Ipsec] Changing PRFs when rekeying the IKE_SA Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 Cc: IPsec WG X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org At 3:42 PM -0400 6/14/05, Bill Sommerfeld wrote: >On Tue, 2005-06-14 at 15:26, Paul Hoffman wrote: > >> We need to pick one or the other. I propose that we pick the *new* >> prf, because the two sides have agreed to use it for the new SA. Does >> anyone have any objections? > >so, cryptographer-types have, in my presence, expressed fairly strong >objection to using the same key bits with multiple algorithms on the >theory that it constitutes bad practice and might lead to >hard-to-analyze weaknesses. > >in the absence of a clarification that would lead me to assume that I'd >should use the old prf/prf+ with the old SK_d to generate the new >SKEYSEED. That logic works for me as well. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 14 16:42:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiIFK-0007mf-6r; Tue, 14 Jun 2005 16:42:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiIFH-0007mR-Ku for ipsec@megatron.ietf.org; Tue, 14 Jun 2005 16:42:51 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04455 for ; Tue, 14 Jun 2005 16:42:49 -0400 (EDT) Received: from services.cse.ucsc.edu ([128.114.48.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiIbm-0000RU-Vv for ipsec@ietf.org; Tue, 14 Jun 2005 17:06:10 -0400 Received: from ghuang-lnx.netscreen.com (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id j5EKgbml018354 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 14 Jun 2005 13:42:44 -0700 (PDT) Subject: Re: [Ipsec] Changing PRFs when rekeying the IKE_SA From: Geoffrey Huang To: Paul Hoffman In-Reply-To: References: <1118778142.3523.65.camel@thunk> Content-Type: text/plain Date: Tue, 14 Jun 2005 13:40:57 -0700 Message-Id: <1118781657.5382.8.camel@ghuang-lnx.juniper.net> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit X-Spam-Score: 2.9 (++) X-Scan-Signature: bb8f917bb6b8da28fc948aeffb74aa17 Content-Transfer-Encoding: 7bit Cc: IPsec WG , Bill Sommerfeld X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I think it should be the old prf as well; not necessarily because of what Bill mentioned, but because the rekey operation happens under the auspices of the old IKE SA. To this end, since the child exchange really happens under the old IKE SA, I believe it should use the old PRF. -g On Tue, 2005-06-14 at 12:46 -0700, Paul Hoffman wrote: > At 3:42 PM -0400 6/14/05, Bill Sommerfeld wrote: > >On Tue, 2005-06-14 at 15:26, Paul Hoffman wrote: > > > >> We need to pick one or the other. I propose that we pick the *new* > >> prf, because the two sides have agreed to use it for the new SA. Does > >> anyone have any objections? > > > >so, cryptographer-types have, in my presence, expressed fairly strong > >objection to using the same key bits with multiple algorithms on the > >theory that it constitutes bad practice and might lead to > >hard-to-analyze weaknesses. > > > >in the absence of a clarification that would lead me to assume that I'd > >should use the old prf/prf+ with the old SK_d to generate the new > >SKEYSEED. > > That logic works for me as well. > > --Paul Hoffman, Director > --VPN Consortium > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 14 16:48:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiIKW-0000M8-9i; Tue, 14 Jun 2005 16:48:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiIKU-0000Kq-LI for ipsec@megatron.ietf.org; Tue, 14 Jun 2005 16:48:14 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04813 for ; Tue, 14 Jun 2005 16:48:12 -0400 (EDT) Received: from services.cse.ucsc.edu ([128.114.48.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiIh2-0000px-VL for ipsec@ietf.org; Tue, 14 Jun 2005 17:11:33 -0400 Received: from ghuang-lnx.netscreen.com (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id j5EKmCtG020046 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Tue, 14 Jun 2005 13:48:13 -0700 (PDT) Subject: Re: [Ipsec] Traffic selectors violating own policy From: Geoffrey Huang To: Paul Hoffman In-Reply-To: References: Content-Type: text/plain Date: Tue, 14 Jun 2005 13:48:12 -0700 Message-Id: <1118782092.5382.13.camel@ghuang-lnx.juniper.net> Mime-Version: 1.0 X-Mailer: Evolution 2.0.4 (2.0.4-4) Content-Transfer-Encoding: 7bit X-Spam-Score: 2.9 (++) X-Scan-Signature: 31247fb3be228bb596db9127becad0bc 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 Hi Paul, I don't see there are any other options; at least not without complicating matters greatly. W.r.t. your second question, I want to point out that (b) also implies (a). If you don't make it a MUST, then it's still a "best-effort" attempt to avoid the situation. That being said, I believe that such an occurrence is a misconfiguration on A's part. I don't believe that the protocol needs to go out of its way to avoid a fairly obscure case. I vote for (a), but I would accept (b). -g On Tue, 2005-06-14 at 12:34 -0700, Paul Hoffman wrote: > Greetings again. The IKEv2 clarifications document has the following section: > > ----- > 4.6 Traffic selectors violating own policy > > Section 2.9 describes traffic selector negotiation in great detail. > One aspect of this negotiation that may need some clarification is > that when creating a new SA, the initiator should not propose traffic > selectors that violate its own policy. If this rule is not followed, > valid traffic may be dropped. > > This is best illustrated by an example. Suppose that host A has a > policy whose effect is that traffic to 192.0.1.66 is sent via host B > encrypted using AES, and traffic to all other hosts in 192.0.1.0/24 > is also sent via B, but must use 3DES. Suppose also that host B > accepts any combination of AES and 3DES. > > If host A now proposes an SA that uses 3DES, and includes TSr > containing (192.0.1.0-192.0.1.0.255), this will be accepted by host > B. Now, host B can also use this SA to send traffic from 192.0.1.66, > but those packets will be dropped by A since it requires the use of > AES for those traffic. Even if host A creates a new SA only for > 192.0.1.66 that uses AES, host B may freely continue to use the first > SA for the traffic. In this situation, when proposing the SA, host A > should have followed its own policy, and included a TSr containing > ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead. > > In general, if (1) the initiator makes a proposal "for traffic X > (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator > does not actually accept traffic X' with SA, and (3) the initiator > would be willing to accept traffic X' with some SA' (!=SAi), valid > traffic can be unnecessarily dropped since the responder can apply > either SA or SA' to traffic X'. > > (References: "Question about "narrowing" ..." thread, Feb 2005. > "IKEv2 needs a "policy usage mode"..." thread, Feb 2005. "IKEv2 > Traffic Selectors?" thread, Feb 2005. "IKEv2 traffic selector > negotiation examples", 2004-08-08.) > ----- > > This was a thorny issue when we discussed it earlier this year, but > it needs to be resolved. I see three options: > > a) Say that the situation is unfortunate but a reality > > b) Add a SHOULD-level prohibition on SAs with traffic selectors that > violate their own policy > > c) Add a MUST-level prohibition on SAs with traffic selectors that > violate their own policy > > First question: are there more options? > > Second question: do people have a preference between these two > options? The second and third seem cleaner but probably will add > large overhead for what is clearly a corner case. The first seems > unclean but possibly sufficient. > > Suggestions? > > --Paul Hoffman, Director > --VPN Consortium > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 14 16:49:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiILR-00011O-An; Tue, 14 Jun 2005 16:49:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiILN-00011C-FU for ipsec@megatron.ietf.org; Tue, 14 Jun 2005 16:49:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04941 for ; Tue, 14 Jun 2005 16:49:05 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiIhp-0000rt-MW for ipsec@ietf.org; Tue, 14 Jun 2005 17:12:26 -0400 Received: from centralmail1brm.Central.Sun.COM ([129.147.62.1]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j5EKn1Kg013431 for ; Tue, 14 Jun 2005 13:49:01 -0700 (PDT) Received: from binky.Central.Sun.COM (binky.Central.Sun.COM [129.153.128.104]) by centralmail1brm.Central.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL, v2.2) with ESMTP id j5EKn03X001526 for ; Tue, 14 Jun 2005 14:49:00 -0600 (MDT) Received: from binky.Central.Sun.COM (localhost [127.0.0.1]) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3) with ESMTP id j5EKmxsF017091; Tue, 14 Jun 2005 15:48:59 -0500 (CDT) Received: (from nw141292@localhost) by binky.Central.Sun.COM (8.13.3+Sun/8.13.3/Submit) id j5EKmwOh017090; Tue, 14 Jun 2005 15:48:58 -0500 (CDT) Date: Tue, 14 Jun 2005 15:48:58 -0500 From: Nicolas Williams To: Paul Hoffman Subject: Re: [Ipsec] Traffic selectors violating own policy Message-ID: <20050614204858.GE16670@binky.Central.Sun.COM> Mail-Followup-To: Paul Hoffman , IPsec WG References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.7i X-Spam-Score: 0.0 (/) X-Scan-Signature: 9ed51c9d1356100bce94f1ae4ec616a9 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 On Tue, Jun 14, 2005 at 12:34:02PM -0700, Paul Hoffman wrote: > This was a thorny issue when we discussed it earlier this year, but > it needs to be resolved. I see three options: > > a) Say that the situation is unfortunate but a reality > > b) Add a SHOULD-level prohibition on SAs with traffic selectors that > violate their own policy > > c) Add a MUST-level prohibition on SAs with traffic selectors that > violate their own policy > > First question: are there more options? d) Forbid policy which leads to this problem -- kick the can to administrators and have them break up aggregate policies into non-conflicting entries. No, I don't like (d) :) e) When an incoming packet is protected with an SA which violates policy then drop the packet, negotiate a new SA with narrower TSs corresponding to the dropped packet and let the transport and/or application re-transmit the dropped packet. (e) is not great, but tolerable, I think. I think it should be possible to programmatically ensure that SAs with TSs that conflict with local policy are never negotiated, so (c) it should be. > Second question: do people have a preference between these two > options? The second and third seem cleaner but probably will add > large overhead for what is clearly a corner case. The first seems > unclean but possibly sufficient. They amount to much the same thing -- an implementation that incorrectly negotiates SAs with TSs that conflict with local policy will run into this problem and the only difference between (b) and (c) then will be the degree of non-compliance with the RFC. Nico -- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 14 23:23:04 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiOUa-0005D8-A8; Tue, 14 Jun 2005 23:23:04 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiOUX-00059C-5a for ipsec@megatron.ietf.org; Tue, 14 Jun 2005 23:23:01 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00585 for ; Tue, 14 Jun 2005 23:22:58 -0400 (EDT) Received: from mailgw4.technion.ac.il ([132.68.238.37]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiOr8-0007QC-9h for ipsec@ietf.org; Tue, 14 Jun 2005 23:46:23 -0400 Received: from localhost (localhost.localdomain [127.0.0.1]) by mailgw4.technion.ac.il (Postfix) with ESMTP id C3488F7959 for ; Wed, 15 Jun 2005 06:12:09 +0300 (IDT) Received: from mailgw4.technion.ac.il ([127.0.0.1]) by localhost (mailgw4.technion.ac.il [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 05721-01-81 for ; Wed, 15 Jun 2005 06:12:09 +0300 (IDT) Received: from ee.technion.ac.il (ee.technion.ac.il [132.68.48.5]) by mailgw4.technion.ac.il (Postfix) with ESMTP id A4711F78C3 for ; Wed, 15 Jun 2005 06:12:09 +0300 (IDT) 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 j5F3No4A008736; Wed, 15 Jun 2005 06:23:50 +0300 (IDT) Received: from localhost (hugo@localhost) by ee.technion.ac.il (8.12.10+Sun/8.12.2/Submit) with ESMTP id j5F3Ni74008709; Wed, 15 Jun 2005 06:23:45 +0300 (IDT) Date: Wed, 15 Jun 2005 06:23:44 +0300 (IDT) From: Hugo Krawczyk To: Geoffrey Huang Subject: Re: [Ipsec] Changing PRFs when rekeying the IKE_SA In-Reply-To: <1118781657.5382.8.camel@ghuang-lnx.juniper.net> 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: 0ddefe323dd869ab027dbfff7eff0465 Cc: IPsec WG , Bill Sommerfeld , Paul Hoffman X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Both Bill and Geoffrey are correct. It is the key from the existing session that spawns and authenticates the new (re-keyed) session, so both SK_d and prf must taken from the existing "old" session. Hugo On Tue, 14 Jun 2005, Geoffrey Huang wrote: > I think it should be the old prf as well; not necessarily because of > what Bill mentioned, but because the rekey operation happens under the > auspices of the old IKE SA.To this end, since the child exchange > really happens under the old IKE SA, I believe it should use the old > PRF. > > -g > > On Tue, 2005-06-14 at 12:46 -0700, Paul Hoffman wrote: > > At 3:42 PM -0400 6/14/05, Bill Sommerfeld wrote: > > >On Tue, 2005-06-14 at 15:26, Paul Hoffman wrote: > > > > > >>We need to pick one or the other. I propose that we pick the *new* > > >>prf, because the two sides have agreed to use it for the new SA. Does > > >>anyone have any objections? > > > > > >so, cryptographer-types have, in my presence, expressed fairly strong > > >objection to using the same key bitswith multiple algorithms on the > > >theory that it constitutes bad practice and might lead to > > >hard-to-analyze weaknesses. > > > > > >in the absence of a clarification that would lead me to assume that I'd > > >should use the old prf/prf+ with the old SK_d to generate the new > > >SKEYSEED. > > > > That logic works for me as well. > > > > --Paul Hoffman, Director > > --VPN Consortium > > > > _______________________________________________ > > Ipsec mailing list > > Ipsec@ietf.org > > https://www1.ietf.org/mailman/listinfo/ipsec > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 15 04:02:57 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiSrO-0008G8-J7; Wed, 15 Jun 2005 04:02:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiSrK-0008G2-4h for ipsec@megatron.ietf.org; Wed, 15 Jun 2005 04:02:50 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA20752 for ; Wed, 15 Jun 2005 04:02:48 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DiTDw-00066n-BR for ipsec@ietf.org; Wed, 15 Jun 2005 04:26:14 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 49E4B89832; Wed, 15 Jun 2005 11:02:38 +0300 (EEST) Message-ID: <42AFE0A4.9050906@kolumbus.fi> Date: Wed, 15 Jun 2005 11:02:44 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@ietf.org, Pasi Eronen Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 7bit Cc: Subject: [Ipsec] ikev2 and internal_ipvn_address X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org I'm trying to understand how IKEv2 is expected to process internal address requests, if the client is interested in getting both v4 and v6 addresses. The basic question is if you can ask for both types of addresses, and if so, if you can do that in a single request or in different ones, and what happens if only one address type is available. The scenario I'm looking at is a v4 & v6 capable client, but without knowledge of what kind of support exists in the security gateway or the network behind it. Section 2.19: CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute (either IPv4 or IPv6) but MAY contain any number of additional attributes the initiator wants returned in the response. Can an "additional attribute" be another "INTERNAL_ADDRESS" attribute, of other type? (And what if its of the same type?) Tentative conclusion from this text is that only one INTERNAL_IPvN_ADDRESS attribute may appear, but that conflicts with 3.15.1 (further below). Section 3.10.1: INTERNAL_ADDRESS_FAILURE 36 Indicates an error assigning an internal address (i.e., INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS) during the processing of a Configuration Payload by a responder. If this error is generated within an IKE_AUTH exchange no CHILD_SA will be created. What if you requested both address types, but got just one? Will this error code be used or not? Section 3.15.1: Multiple internal addresses MAY be requested by requesting multiple internal address attributes. The responder MAY only send up to the number of addresses requested. The Is this referring to requests within the same message or as multiple messages? If in the same, then its in conflict with my tentative conclusion from Section 2.19. --Jari _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 15 13:46:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DibyS-0000JE-Rs; Wed, 15 Jun 2005 13:46:48 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DibyQ-0000J9-II for ipsec@megatron.ietf.org; Wed, 15 Jun 2005 13:46:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08575 for ; Wed, 15 Jun 2005 13:46:43 -0400 (EDT) Received: from smtp811.mail.sc5.yahoo.com ([66.163.170.81]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DicL4-0007Q5-Cz for ipsec@ietf.org; Wed, 15 Jun 2005 14:10:14 -0400 Received: (qmail 27375 invoked from network); 15 Jun 2005 17:46:37 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.57.145 with login) by smtp811.mail.sc5.yahoo.com with SMTP; 15 Jun 2005 17:46:37 -0000 Message-ID: <008001c571d2$2ddb8840$7401a8c0@adithya> From: "Mohan Parthasarathy" To: "Jari Arkko" , , "Pasi Eronen" References: <42AFE0A4.9050906@kolumbus.fi> Subject: Re: [Ipsec] ikev2 and internal_ipvn_address Date: Wed, 15 Jun 2005 10:46:36 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: b4a0a5f5992e2a4954405484e7717d8c 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 Jari, See the latest thread on"Configuration Payload usage", it looks like both IPv4 and IPv6 address can be requested within a single Configuration request message. -mohan ----- Original Message ----- From: "Jari Arkko" To: ; "Pasi Eronen" Sent: Wednesday, June 15, 2005 1:02 AM Subject: [Ipsec] ikev2 and internal_ipvn_address > I'm trying to understand how IKEv2 is expected to process > internal address requests, if the client is interested in > getting both v4 and v6 addresses. The basic question > is if you can ask for both types of addresses, and if so, > if you can do that in a single request or in different ones, > and what happens if only one address type is available. > The scenario I'm looking at is a v4 & v6 capable client, > but without knowledge of what kind of support exists > in the security gateway or the network behind it. > > Section 2.19: > > CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute > (either IPv4 or IPv6) but MAY contain any number of additional > attributes the initiator wants returned in the response. > > Can an "additional attribute" be another "INTERNAL_ADDRESS" attribute, > of other type? (And what if its of the same type?) Tentative conclusion > from this text is that only one INTERNAL_IPvN_ADDRESS attribute > may appear, but that conflicts with 3.15.1 (further below). > > Section 3.10.1: > > INTERNAL_ADDRESS_FAILURE 36 > > Indicates an error assigning an internal address (i.e., > INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS) during the > processing of a Configuration Payload by a responder. If > this error is generated within an IKE_AUTH exchange no > CHILD_SA will be created. > > What if you requested both address types, but got just one? > Will this error code be used or not? > > Section 3.15.1: > > Multiple internal addresses MAY be requested by requesting > multiple internal address attributes. The responder MAY only > send up to the number of addresses requested. The > > Is this referring to requests within the same message or as multiple > messages? If in the same, then its in conflict with my tentative > conclusion from Section 2.19. > > --Jari > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 15 13:54:13 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dic5c-0001RK-W5; Wed, 15 Jun 2005 13:54:13 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dic5b-0001Ox-6J for ipsec@megatron.ietf.org; Wed, 15 Jun 2005 13:54:11 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09245 for ; Wed, 15 Jun 2005 13:54:10 -0400 (EDT) Received: from smtp805.mail.sc5.yahoo.com ([66.163.168.184]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DicSI-0007w3-Ox for ipsec@ietf.org; Wed, 15 Jun 2005 14:17:41 -0400 Received: (qmail 13009 invoked from network); 15 Jun 2005 17:54:04 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.57.145 with login) by smtp805.mail.sc5.yahoo.com with SMTP; 15 Jun 2005 17:54:04 -0000 Message-ID: <009d01c571d3$382f4fb0$7401a8c0@adithya> From: "Mohan Parthasarathy" To: "IPsec WG" , "Paul Hoffman" References: Subject: Re: [Ipsec] Traffic selectors violating own policy Date: Wed, 15 Jun 2005 10:54:04 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: d0bdc596f8dd1c226c458f0b4df27a88 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 > ----- > 4.6 Traffic selectors violating own policy > > Section 2.9 describes traffic selector negotiation in great detail. > One aspect of this negotiation that may need some clarification is > that when creating a new SA, the initiator should not propose traffic > selectors that violate its own policy. If this rule is not followed, > valid traffic may be dropped. > > This is best illustrated by an example. Suppose that host A has a > policy whose effect is that traffic to 192.0.1.66 is sent via host B > encrypted using AES, and traffic to all other hosts in 192.0.1.0/24 > is also sent via B, but must use 3DES. Suppose also that host B > accepts any combination of AES and 3DES. > > If host A now proposes an SA that uses 3DES, and includes TSr > containing (192.0.1.0-192.0.1.0.255), this will be accepted by host > B. Now, host B can also use this SA to send traffic from 192.0.1.66, > but those packets will be dropped by A since it requires the use of > AES for those traffic. Even if host A creates a new SA only for > 192.0.1.66 that uses AES, host B may freely continue to use the first > SA for the traffic. In this situation, when proposing the SA, host A > should have followed its own policy, and included a TSr containing > ((192.0.1.0-192.0.1.65),(192.0.1.67-192.0.1.255)) instead. > > In general, if (1) the initiator makes a proposal "for traffic X > (TSi/TSr), do SA", and (2) for some subset X' of X, the initiator > does not actually accept traffic X' with SA, and (3) the initiator > would be willing to accept traffic X' with some SA' (!=SAi), valid > traffic can be unnecessarily dropped since the responder can apply > either SA or SA' to traffic X'. > > (References: "Question about "narrowing" ..." thread, Feb 2005. > "IKEv2 needs a "policy usage mode"..." thread, Feb 2005. "IKEv2 > Traffic Selectors?" thread, Feb 2005. "IKEv2 traffic selector > negotiation examples", 2004-08-08.) > ----- > > This was a thorny issue when we discussed it earlier this year, but > it needs to be resolved. I see three options: > > a) Say that the situation is unfortunate but a reality > > b) Add a SHOULD-level prohibition on SAs with traffic selectors that > violate their own policy > > c) Add a MUST-level prohibition on SAs with traffic selectors that > violate their own policy > As IKEv2 allows different policy configurations to exist on the two ends, the only option is "c" for things to work. So, i really don't know why we have so many options :-) -mohan > First question: are there more options? > > Second question: do people have a preference between these two > options? The second and third seem cleaner but probably will add > large overhead for what is clearly a corner case. The first seems > unclean but possibly sufficient. > > Suggestions? > > --Paul Hoffman, Director > --VPN Consortium > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jun 16 03:55:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DipDH-0006YG-Nb; Thu, 16 Jun 2005 03:54:59 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DipDD-0006TM-UD for ipsec@megatron.ietf.org; Thu, 16 Jun 2005 03:54:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA23438 for ; Thu, 16 Jun 2005 03:54:50 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dipa3-0007w6-JJ for ipsec@ietf.org; Thu, 16 Jun 2005 04:18:33 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 1CE888988A; Thu, 16 Jun 2005 10:54:40 +0300 (EEST) Message-ID: <42B13046.7050709@kolumbus.fi> Date: Thu, 16 Jun 2005 10:54:46 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohan Parthasarathy Subject: Re: [Ipsec] ikev2 and internal_ipvn_address References: <42AFE0A4.9050906@kolumbus.fi> <008001c571d2$2ddb8840$7401a8c0@adithya> In-Reply-To: <008001c571d2$2ddb8840$7401a8c0@adithya> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f66b12316365a3fe519e75911daf28a8 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Pasi Eronen X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Thanks for the pointer! That was indeed a useful discussion from the point of view of the questions I had. It seems that there was some support for the idea that you can use multiple internal address requests at the same time. But I didn't see an answer to my question about what happens if there's a failure in allocating one of the requested addresses. And it would be really good to write all this down somewhere... Mohan Parthasarathy wrote: >Jari, > >See the latest thread on"Configuration Payload usage", it looks like both IPv4 and IPv6 >address can be requested within a single Configuration request message. > >-mohan > > >----- Original Message ----- >From: "Jari Arkko" >To: ; "Pasi Eronen" >Sent: Wednesday, June 15, 2005 1:02 AM >Subject: [Ipsec] ikev2 and internal_ipvn_address > > > > >>I'm trying to understand how IKEv2 is expected to process >>internal address requests, if the client is interested in >>getting both v4 and v6 addresses. The basic question >>is if you can ask for both types of addresses, and if so, >>if you can do that in a single request or in different ones, >>and what happens if only one address type is available. >>The scenario I'm looking at is a v4 & v6 capable client, >>but without knowledge of what kind of support exists >>in the security gateway or the network behind it. >> >>Section 2.19: >> >> CP(CFG_REQUEST) MUST contain at least an INTERNAL_ADDRESS attribute >> (either IPv4 or IPv6) but MAY contain any number of additional >> attributes the initiator wants returned in the response. >> >>Can an "additional attribute" be another "INTERNAL_ADDRESS" attribute, >>of other type? (And what if its of the same type?) Tentative conclusion >>from this text is that only one INTERNAL_IPvN_ADDRESS attribute >>may appear, but that conflicts with 3.15.1 (further below). >> >>Section 3.10.1: >> >> INTERNAL_ADDRESS_FAILURE 36 >> >> Indicates an error assigning an internal address (i.e., >> INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS) during the >> processing of a Configuration Payload by a responder. If >> this error is generated within an IKE_AUTH exchange no >> CHILD_SA will be created. >> >>What if you requested both address types, but got just one? >>Will this error code be used or not? >> >>Section 3.15.1: >> >> Multiple internal addresses MAY be requested by requesting >> multiple internal address attributes. The responder MAY only >> send up to the number of addresses requested. The >> >>Is this referring to requests within the same message or as multiple >>messages? If in the same, then its in conflict with my tentative >>conclusion from Section 2.19. >> >>--Jari >> >> >>_______________________________________________ >>Ipsec mailing list >>Ipsec@ietf.org >>https://www1.ietf.org/mailman/listinfo/ipsec >> >> > >_______________________________________________ >Ipsec mailing list >Ipsec@ietf.org >https://www1.ietf.org/mailman/listinfo/ipsec > > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jun 16 13:41:33 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiyMv-0001Ms-30; Thu, 16 Jun 2005 13:41:33 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DiyMt-0001Mn-2i for ipsec@megatron.ietf.org; Thu, 16 Jun 2005 13:41:31 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA17795 for ; Thu, 16 Jun 2005 13:41:26 -0400 (EDT) Received: from web80605.mail.yahoo.com ([66.218.79.94]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Diyjm-0008Th-Tf for ipsec@ietf.org; Thu, 16 Jun 2005 14:05:13 -0400 Received: (qmail 5141 invoked by uid 60001); 16 Jun 2005 17:41:16 -0000 Message-ID: <20050616174116.5139.qmail@web80605.mail.yahoo.com> Received: from [206.132.194.2] by web80605.mail.yahoo.com via HTTP; Thu, 16 Jun 2005 10:41:16 PDT Date: Thu, 16 Jun 2005 10:41:16 -0700 (PDT) From: Mohan Parthasarathy Subject: Re: [Ipsec] ikev2 and internal_ipvn_address To: Jari Arkko In-Reply-To: <42B13046.7050709@kolumbus.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 0770535483960d190d4a0d020e7060bd Content-Transfer-Encoding: 8bit Cc: ipsec@ietf.org, Pasi Eronen X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org In section 2.19, it says: All returned values will be implementation dependent. As can be seen in the above example, the IRAS MAY also send other attributes that were not included in CP(CFG_REQUEST) and MAY ignore the non- mandatory attributes that it does not support. >From this, no error is returned, just the attributes that are not supported are not returned. The client can still consider as an error if it does not see all the attributes it requested. Everyday you discover something new about Configuration payload :-) -mohan --- Jari Arkko wrote: > Thanks for the pointer! That was indeed a useful > discussion > from the point of view of the questions I had. It > seems that > there was some support for the idea that you can use > multiple > internal address requests at the same time. But I > didn't see > an answer to my question about what happens if > there's > a failure in allocating one of the requested > addresses. > > And it would be really good to write all this down > somewhere... > > Mohan Parthasarathy wrote: > > >Jari, > > > >See the latest thread on"Configuration Payload > usage", it looks like both IPv4 and IPv6 > >address can be requested within a single > Configuration request message. > > > >-mohan > > > > > >----- Original Message ----- > >From: "Jari Arkko" > >To: ; "Pasi Eronen" > > >Sent: Wednesday, June 15, 2005 1:02 AM > >Subject: [Ipsec] ikev2 and internal_ipvn_address > > > > > > > > > >>I'm trying to understand how IKEv2 is expected to > process > >>internal address requests, if the client is > interested in > >>getting both v4 and v6 addresses. The basic > question > >>is if you can ask for both types of addresses, and > if so, > >>if you can do that in a single request or in > different ones, > >>and what happens if only one address type is > available. > >>The scenario I'm looking at is a v4 & v6 capable > client, > >>but without knowledge of what kind of support > exists > >>in the security gateway or the network behind it. > >> > >>Section 2.19: > >> > >> CP(CFG_REQUEST) MUST contain at least an > INTERNAL_ADDRESS attribute > >> (either IPv4 or IPv6) but MAY contain any > number of additional > >> attributes the initiator wants returned in the > response. > >> > >>Can an "additional attribute" be another > "INTERNAL_ADDRESS" attribute, > >>of other type? (And what if its of the same type?) > Tentative conclusion > >>from this text is that only one > INTERNAL_IPvN_ADDRESS attribute > >>may appear, but that conflicts with 3.15.1 > (further below). > >> > >>Section 3.10.1: > >> > >> INTERNAL_ADDRESS_FAILURE > 36 > >> > >> Indicates an error assigning an > internal address (i.e., > >> INTERNAL_IP4_ADDRESS or > INTERNAL_IP6_ADDRESS) during the > >> processing of a Configuration Payload > by a responder. If > >> this error is generated within an > IKE_AUTH exchange no > >> CHILD_SA will be created. > >> > >>What if you requested both address types, but got > just one? > >>Will this error code be used or not? > >> > >>Section 3.15.1: > >> > >> Multiple internal addresses MAY be > requested by requesting > >> multiple internal address attributes. > The responder MAY only > >> send up to the number of addresses > requested. The > >> > >>Is this referring to requests within the same > message or as multiple > >>messages? If in the same, then its in conflict > with my tentative > >>conclusion from Section 2.19. > >> > >>--Jari > >> > >> > >>_______________________________________________ > >>Ipsec mailing list > >>Ipsec@ietf.org > >>https://www1.ietf.org/mailman/listinfo/ipsec > >> > >> > > > >_______________________________________________ > >Ipsec mailing list > >Ipsec@ietf.org > >https://www1.ietf.org/mailman/listinfo/ipsec > > > > > > > > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jun 16 15:30:19 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj04B-0001md-PM; Thu, 16 Jun 2005 15:30:19 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj04A-0001mF-5j for ipsec@megatron.ietf.org; Thu, 16 Jun 2005 15:30:18 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA29052 for ; Thu, 16 Jun 2005 15:30:12 -0400 (EDT) Received: from p130.piuha.net ([193.234.218.130]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj0R5-0006wi-1F for ipsec@ietf.org; Thu, 16 Jun 2005 15:54:01 -0400 Received: from [127.0.0.1] (p130.piuha.net [193.234.218.130]) by p130.piuha.net (Postfix) with ESMTP id 357EB8988A; Thu, 16 Jun 2005 22:30:03 +0300 (EEST) Message-ID: <42B1D342.4020706@kolumbus.fi> Date: Thu, 16 Jun 2005 22:30:10 +0300 From: Jari Arkko User-Agent: Mozilla Thunderbird 1.0 (X11/20041206) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Mohan Parthasarathy Subject: Re: [Ipsec] ikev2 and internal_ipvn_address References: <20050616174116.5139.qmail@web80605.mail.yahoo.com> In-Reply-To: <20050616174116.5139.qmail@web80605.mail.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: f4c2cf0bccc868e4cc88dace71fb3f44 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Pasi Eronen X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Mohan Parthasarathy wrote: >In section 2.19, it says: > >All returned values will be implementation dependent. >As can be seen > in the above example, the IRAS MAY also send other >attributes that > were not included in CP(CFG_REQUEST) and MAY ignore >the non- > mandatory attributes that it does not support. > >From this, no error is returned, just the attributes >that are not supported are not returned. The client >can still consider as an error if it does not see all >the attributes it requested. > >Everyday you discover something new about >Configuration payload :-) > This brings up a number of issues: 1) It seems that then the spec does not even say whether you can ignore an address assignment request or whether you should return internal address failure in the normal case. Section 2.19 talks about another error case, but not this: INTERNAL_ADDRESS_FAILURE 36 Indicates an error assigning an internal address (i.e., INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS) during the processing of a Configuration Payload by a responder. If this error is generated within an IKE_AUTH exchange no CHILD_SA will be created. Under what conditions do you actually send this? Is a "minimal IPv4 implementation (Section 4) required to recognize an INTERNAL_IP6_ADDRESS and respond with the above error code? Or only if you do support it but can't allocate an address? 2) My original question was a special case of the above. If you have multiple requests, what if one of them fails? 3) What does "mandatory" mean in the 2.19 text "can ignore non-mandatory attributes"? Section 3.15.1 does not define a mandatory/critical bit in the attribute format. Perhaps this means the list of attributes in Section 4 then? Or the text in 2.19 that seems to imply that one only needs to support INTERNAL_ADDRESS attribute? 4) How does DAD (Duplicate Address Detection) work in the IPv6 case? --Jari _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jun 16 16:30:23 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj10J-0007Wn-Er; Thu, 16 Jun 2005 16:30:23 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj10H-0007WY-8C for ipsec@megatron.ietf.org; Thu, 16 Jun 2005 16:30:21 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA12201 for ; Thu, 16 Jun 2005 16:30:15 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj1ND-0005Bd-W4 for ipsec@ietf.org; Thu, 16 Jun 2005 16:54:05 -0400 Received: from [172.20.100.163] (dommiel.bbn.com [192.1.122.15]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j5GKTr2o029577; Thu, 16 Jun 2005 16:30:03 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: References: Date: Thu, 16 Jun 2005 16:29:46 -0400 To: Paul Hoffman From: Stephen Kent Subject: Re: [Ipsec] Traffic selectors violating own policy 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: cf4fa59384e76e63313391b70cd0dd25 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, >Greetings again. The IKEv2 clarifications document has the following section: > >----- >4.6 Traffic selectors violating own policy > > Section 2.9 describes traffic selector negotiation in great detail. > One aspect of this negotiation that may need some clarification is > that when creating a new SA, the initiator should not propose traffic > selectors that violate its own policy. If this rule is not followed, > valid traffic may be dropped. I'd go for option (c), making the above statement into a MUST. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jun 16 17:33:14 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj1z8-0004ba-6h; Thu, 16 Jun 2005 17:33:14 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj1z5-0004bM-8i for ipsec@megatron.ietf.org; Thu, 16 Jun 2005 17:33:12 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17468 for ; Thu, 16 Jun 2005 17:33:05 -0400 (EDT) Received: from nwkea-mail-1.sun.com ([192.18.42.13]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dj2M0-0000kO-E6 for ipsec@ietf.org; Thu, 16 Jun 2005 17:56:55 -0400 Received: from eastmail1bur.East.Sun.COM ([129.148.9.49]) by nwkea-mail-1.sun.com (8.12.10/8.12.9) with ESMTP id j5GLX6Kg012412; Thu, 16 Jun 2005 14:33:06 -0700 (PDT) Received: from thunk.east.sun.com (thunk.East.Sun.COM [129.148.174.66]) by eastmail1bur.East.Sun.COM (8.12.10+Sun/8.12.10/ENSMAIL,v2.2) with ESMTP id j5GLX5Ft011773; Thu, 16 Jun 2005 17:33:05 -0400 (EDT) Received: from 127.0.0.1 (localhost [127.0.0.1]) by thunk.east.sun.com (8.13.3+Sun/8.13.3) with ESMTP id j5GLX5xG018837; Thu, 16 Jun 2005 17:33:05 -0400 (EDT) Subject: Re: [Ipsec] Traffic selectors violating own policy From: Bill Sommerfeld To: Paul Hoffman In-Reply-To: References: Content-Type: text/plain; charset=iso-8859-1 Message-Id: <1118957584.16789.119.camel@thunk> Mime-Version: 1.0 X-Mailer: Ximian Evolution 1.4.6.309 Date: Thu, 16 Jun 2005 17:33:05 -0400 Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 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 On Tue, 2005-06-14 at 15:34, Paul Hoffman wrote: > First question: are there more options? Silly question. There are always more options! > Second question: do people have a preference between these two > options? The second and third seem cleaner but probably will add > large overhead for what is clearly a corner case. The first seems > unclean but possibly sufficient. We can, and SHOULD do better than (a). Prefer (c) (maximises interoperability, minimises black holes). Can live with (b) if other implementors really need an escape clause. - Bill _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jun 16 20:15:48 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj4WR-0004sx-Us; Thu, 16 Jun 2005 20:15:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dj4WP-0004sr-Qj for ipsec@megatron.ietf.org; Thu, 16 Jun 2005 20:15:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA29268 for ; Thu, 16 Jun 2005 20:15:41 -0400 (EDT) Received: from smtp821.mail.sc5.yahoo.com ([66.163.171.7]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dj4tN-00018x-1n for ipsec@ietf.org; Thu, 16 Jun 2005 20:39:31 -0400 Received: (qmail 47484 invoked from network); 17 Jun 2005 00:15:35 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.58.176 with login) by smtp821.mail.sc5.yahoo.com with SMTP; 17 Jun 2005 00:15:34 -0000 Message-ID: <007901c572d1$ae6e4240$7401a8c0@adithya> From: "Mohan Parthasarathy" To: "Jari Arkko" References: <20050616174116.5139.qmail@web80605.mail.yahoo.com> <42B1D342.4020706@kolumbus.fi> Subject: Re: [Ipsec] ikev2 and internal_ipvn_address Date: Thu, 16 Jun 2005 17:15:34 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 5011df3e2a27abcc044eaa15befcaa87 Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org, Pasi Eronen X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Jari, There was another thread "Questions about internal address" where some of your questions were answered. We should include a new section in the clarification draft to address these questions. Comments inline... > > > >All returned values will be implementation dependent. > >As can be seen > > in the above example, the IRAS MAY also send other > >attributes that > > were not included in CP(CFG_REQUEST) and MAY ignore > >the non- > > mandatory attributes that it does not support. > > > >From this, no error is returned, just the attributes > >that are not supported are not returned. The client > >can still consider as an error if it does not see all > >the attributes it requested. > > > >Everyday you discover something new about > >Configuration payload :-) > > > This brings up a number of issues: > > 1) It seems that then the spec does not even say whether you > can ignore an address assignment request or whether > you should return internal address failure in the normal > case. Section 2.19 talks about another error case, but not > this: > > INTERNAL_ADDRESS_FAILURE 36 > > Indicates an error assigning an internal address (i.e., > INTERNAL_IP4_ADDRESS or INTERNAL_IP6_ADDRESS) during the > processing of a Configuration Payload by a responder. If > this error is generated within an IKE_AUTH exchange no > CHILD_SA will be created. > > Under what conditions do you actually send this? Is a > "minimal IPv4 implementation (Section 4) required to > recognize an INTERNAL_IP6_ADDRESS and respond with the > above error code? Or only if you do support it but can't > allocate an address? > If you read the thread that i mentioned above, it is not clear what was decided. Following are the options that i see. 1) Fail the request with INTERNAL_ADDRESS_FAILURE (this will fail the IPsec exchange also if it was done along with it) if you cannot complete the "whole" request. 2) Fail the request with INTERNAL_ADDRESS_FAILURE if you cannot process the mandatory attributes in the request. 3) Return whatever you have and leave the rest out. You still don't return error if you don't have anything to give. In some cases, you may want to at least get an IPv4 address. So, failing the request because you can't assign the IPv6 address seems harmful. On the other hand, just giving an IP address alone might not be useful. The client may have to know netmask or DNS to do some "useful" work. (2) assumes that we can agree on what mandatory attributes are. (3) seems like a good option because then the client can decide whether it is an error or proceed further depending on what it received from IRAS. > 2) My original question was a special case of the above. If > you have multiple requests, what if one of them fails? > See above.. > 3) What does "mandatory" mean in the 2.19 text "can > ignore non-mandatory attributes"? Section 3.15.1 > does not define a mandatory/critical bit in the > attribute format. Perhaps this means the list of > attributes in Section 4 then? Or the text in 2.19 > that seems to imply that one only needs to support > INTERNAL_ADDRESS attribute? > This is also not clear to me. The wording seems to be "CP(CFG_REQUEST MUST contain at least an INTERNAL_ADDRESS attribute". If i already have an address, i just need to know the DNS servers etc.. can i send a CFG_REQUEST without it ? I always assumed so. > 4) How does DAD (Duplicate Address Detection) work in the > IPv6 case? > This also seems to be left open. We have to assume that the IRAS does it. -mohan > > --Jari > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 20 20:03:16 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkWEW-0004NI-H6; Mon, 20 Jun 2005 20:03:16 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DkWET-0004LA-Qp for ipsec@megatron.ietf.org; Mon, 20 Jun 2005 20:03:13 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA23573 for ; Mon, 20 Jun 2005 20:03:11 -0400 (EDT) Received: from rs15.luxsci.com ([65.61.166.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DkWcG-0001UW-Ew for ipsec@ietf.org; Mon, 20 Jun 2005 20:27:49 -0400 Received: from rs15.luxsci.com (localhost [127.0.0.1]) by rs15.luxsci.com (8.12.11/8.12.11) with ESMTP id j5L02exe014972; Mon, 20 Jun 2005 19:02:40 -0500 Received: (from root@localhost) by rs15.luxsci.com (8.12.11/8.12.11/Submit) id j5L021qf014799; Tue, 21 Jun 2005 00:02:01 GMT Message-Id: <200506210002.j5L021qf014799@rs15.luxsci.com> Received: (from ietf-wd@v6security.com) by LuxSci SMTP Processor; Tue, 21 Jun 2005 00:02:01 +0000 From: "William Dixon" To: "'Paul Hoffman'" , "'IPsec WG'" Subject: RE: [Ipsec] Traffic selectors violating own policy Date: Mon, 20 Jun 2005 20:00:33 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-reply-to: X-Comment: LuxSci SMTP Processor Message ID - 1119312121-2301663.12880053 X-Spam-Score: 0.8 (/) X-Scan-Signature: 5ebbf074524e58e662bc8209a6235027 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 Based on implementation & deployment experience with IKEv1, I'd prefer another option. If you choose either B or C below, then you aren't providing sufficient guidance to enable interop. IKEv1 had this issue as well. Windows solved it by always proposing the most specific selector in policy. This is efficient aggregator of traffic. But my experience has shown this forces too much a-priori configuration coordination, so it makes the policy system quite cumbersome to use. I think Bill told me Solaris has the option of proposing the policy selector OR a 5-tuple generated from the traffic. Option D. An IKE initiator MUST not propose a more general selector when it has a more specific selector for that traffic. It SHOULD propose both the most specific selector it has configured in policy, as well as a selector constructed from the 5-tuple of the packet, unless the most specific policy selector is permit or block. An IKE responder SHOULD match the most specific selector, and SHOULD respond with the most general matching subset. Example: Host A Configuration: Require IPsec ESP for all traffic to 192.0.1.66 Require IPsec AH for all traffic to 192.0.1.0-192.0.1.255 Host B Configuration: Require IPsec AH for all traffic to/from 192.0.1.0-192.0.1.255 There exists the case, starting from a no SA state, that host B (with only subnet policy) initiates upper layer new connection from 192.0.1.66, and thus is the IKE initiator, proposing only what is in policy, it's subnet selector, which results in the inbound traffic from 192.0.1.66 being blocked for the reason Paul described. However, this selector could also require blocking traffic, in which case the traffic will of course be dropped. There are any number of perfectly valid policy configurations on Host A & B, such that what I propose is the best way to negotiate these. Such as: Block all TCP from 192.0.1.66 Block all UDP from 192.0.1.66 Require IPsec ESP transport mode for TCP src *, dst 445 from 192.0.1.66 (encrypt SMB file sharing traffic) Require IPsec AH transport mode for TCP src *, dst 3389 from 192.0.1.66 (authenticate Remote Desktop protocol, since it provides it's own encryption) Permit TCP src *, dst 443 from 192.0.1.66 The source address, 192.0.1.66 could be a subnet, Any or other wildcards as needed. Thus the most flexible option is to propose what is both in policy and in traffic. Clearly for IPsec gateways, requiring IKE to propose full 5-tuple options for every new 5 tuple would be a burdensome requirement, thus it's a SHOULD or we add more text to explain. We would expect gateways to have administratively coordinated policy, such that only the selectors in policy are proposed, and thus aggregate much traffic inside the same IPsec SA pair. However, there are scenarios where different organizations would like to configure their own gateways to allow certain types of IPsec protected traffic inbound, and would need the initiating gateway to propose the specific 5-tuple. Regarding: http://www.ietf.org/internet-drafts/draft-eronen-ipsec-ikev2-clarifications- 03.txt > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Paul Hoffman > Sent: Tuesday, June 14, 2005 3:34 PM > To: IPsec WG > Subject: [Ipsec] Traffic selectors violating own policy > > Greetings again. The IKEv2 clarifications document has the > following section: > > ----- > 4.6 Traffic selectors violating own policy > ----- > > This was a thorny issue when we discussed it earlier this year, but > it needs to be resolved. I see three options: > > a) Say that the situation is unfortunate but a reality > > b) Add a SHOULD-level prohibition on SAs with traffic selectors that > violate their own policy > > c) Add a MUST-level prohibition on SAs with traffic selectors that > violate their own policy > > First question: are there more options? > > Second question: do people have a preference between these two > options? The second and third seem cleaner but probably will add > large overhead for what is clearly a corner case. The first seems > unclean but possibly sufficient. > > Suggestions? > > --Paul Hoffman, Director > --VPN Consortium > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 21 14:17:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DknJj-0004tT-Jw; Tue, 21 Jun 2005 14:17:47 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DknJi-0004tO-54 for ipsec@megatron.ietf.org; Tue, 21 Jun 2005 14:17:46 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA14268 for ; Tue, 21 Jun 2005 14:17:44 -0400 (EDT) Received: from mx2.trusecure.com ([208.251.192.11]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dknhf-0004e2-1B for ipsec@ietf.org; Tue, 21 Jun 2005 14:42:32 -0400 Received: from VAMAIL01.corp.trusecure.net (vamail01.corp.cybertrust.net [172.19.1.52]) by mx2.trusecure.com (Postfix) with ESMTP id 29F72C9286 for ; Tue, 21 Jun 2005 14:17:18 -0400 (EDT) Received: from HRN-MSC-EXCH-01.mscore.trusecure.net (hrn-msc-exch-01.corp.cybertrust.net [172.19.1.49]) by VAMAIL01.corp.trusecure.net (8.12.10/maybe_its_not_even_really_Sendmail....) with ESMTP id j5LIHILa000713 for ; Tue, 21 Jun 2005 14:17:18 -0400 (EDT) Received: from hrn-msc-exch-02.mscore.trusecure.net ([172.19.1.56]) by HRN-MSC-EXCH-01.mscore.trusecure.net with Microsoft SMTPSVC(6.0.3790.211); Tue, 21 Jun 2005 14:17:18 -0400 Content-class: urn:content-classes:message MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Date: Tue, 21 Jun 2005 14:17:17 -0400 Message-ID: <04D8F83756A1A84BA156BBFF26FAE0F501B4E018@hrn-msc-exch-02.mscore.trusecure.net> Thread-Topic: IKEv2 Interop Workshop-II - Sept 19-23 Toronto Thread-Index: AcV2jXPut5u0H08lTQu/eYpkbZbbLw== From: "Zimmerman, Mark" To: X-OriginalArrivalTime: 21 Jun 2005 18:17:18.0481 (UTC) FILETIME=[7590B010:01C5768D] X-Spam-Score: 4.3 (++++) X-Scan-Signature: 36c793b20164cfe75332aa66ddb21196 Subject: [Ipsec] IKEv2 Interop Workshop-II - Sept 19-23 Toronto X-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="===============1881115865==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1881115865== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C5768D.755F4AC3" This is a multi-part message in MIME format. ------_=_NextPart_001_01C5768D.755F4AC3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable =20 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Greetings, Details for the next IKEv2 Interoperability Workshop have finally been firmed up for September (19th-23rd) in Toronto, Canada. Details for the agenda and registration information can be had at the following: https://www.icsalabs.com/icsa/docs/html/communities/ipsec/bakeoff/Regist ration_2.html More information, including registered vendors will be posted as it becomes available. Please contact me with questions or suggestions. Regards, -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQrhZrXYqhttf6ax6EQKkSQCg3G4vUALLggGfTgNKtZD+5R03d+8AoOuH OZTdFgrQec1nupBPUDX01Eh5 =3Drar/ -----END PGP SIGNATURE----- ------_=_NextPart_001_01C5768D.755F4AC3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable IKEv2 Interop Workshop-II - Sept 19-23 Toronto

 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Greetings,

Details for the next IKEv2 Interoperability Workshop = have finally been firmed up
for September (19th-23rd) in Toronto, Canada.

Details for the agenda and registration information = can be had at the following:

https://www.icsalabs.com/icsa/docs/html/communities= /ipsec/bakeoff/Registration_2.html

More information, including registered vendors will be = posted as it becomes available.

Please contact me with questions or = suggestions.

Regards,



-----BEGIN PGP SIGNATURE-----
Version: PGP 8.0.3

iQA/AwUBQrhZrXYqhttf6ax6EQKkSQCg3G4vUALLggGfTgNKtZD+5R03d+8AoOuH=
OZTdFgrQec1nupBPUDX01Eh5
=3Drar/
-----END PGP SIGNATURE-----

------_=_NextPart_001_01C5768D.755F4AC3-- --===============1881115865== 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 --===============1881115865==-- From ipsec-bounces@ietf.org Tue Jun 21 21:26:17 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dku0P-0003EC-Ua; Tue, 21 Jun 2005 21:26:17 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dku0O-0003E7-HX for ipsec@megatron.ietf.org; Tue, 21 Jun 2005 21:26:16 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA05187 for ; Tue, 21 Jun 2005 21:26:14 -0400 (EDT) Received: from web80602.mail.yahoo.com ([66.218.79.91]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DkuON-0005WT-0F for ipsec@ietf.org; Tue, 21 Jun 2005 21:51:06 -0400 Received: (qmail 77289 invoked by uid 60001); 22 Jun 2005 01:25:55 -0000 Message-ID: <20050622012555.77287.qmail@web80602.mail.yahoo.com> Received: from [192.100.104.17] by web80602.mail.yahoo.com via HTTP; Tue, 21 Jun 2005 18:25:55 PDT Date: Tue, 21 Jun 2005 18:25:55 -0700 (PDT) From: Mohan Parthasarathy To: ipsec@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 39bd8f8cbb76cae18b7e23f7cf6b2b9f Content-Transfer-Encoding: 8bit Subject: [Ipsec] IKEv2 MAC includes 4 octets of zero ? X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 section 3.1 of the IKEv2 draft, it states that: IKE messages use UDP ports 500 and/or 4500, with one IKE message per UDP datagram. Information from the beginning of the packet through the UDP header is largely ignored except that the IP addresses and UDP ports from the headers are reversed and used for return packets. When sent on UDP port 500, IKE messages begin immediately following the UDP header. When sent on UDP port 4500, IKE messages have prepended four octets of zero. These four octets of zero are not part of the IKE message and are not included in any of the length fields or checksums defined by IKE. In the clarification draft, InitiatorSignedOctets = RealMessage1 | NonceRData | MACedIDForI GenIKEHDR = [ four octets 0 if using port 4500 ] | RealIKEHDR Which is right ? Interestingly, both RFC 3947 and 3948 are slient about it. -mohan _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 22 08:45:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl4bF-0004md-8w; Wed, 22 Jun 2005 08:45:01 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dl4bD-0004mT-G1 for ipsec@megatron.ietf.org; Wed, 22 Jun 2005 08:44:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04393 for ; Wed, 22 Jun 2005 08:44:57 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dl4zK-0006Q7-7m for ipsec@ietf.org; Wed, 22 Jun 2005 09:09:55 -0400 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j5MCiplM021590; Wed, 22 Jun 2005 15:44:56 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Jun 2005 15:44:54 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Jun 2005 15:44:54 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] IKEv2 MAC includes 4 octets of zero ? Date: Wed, 22 Jun 2005 15:44:53 +0300 Message-ID: Thread-Topic: [Ipsec] IKEv2 MAC includes 4 octets of zero ? Thread-Index: AcV2ynVW8uYhl5MJRL+1xDk2FIUPPgAXL10g To: , X-OriginalArrivalTime: 22 Jun 2005 12:44:54.0422 (UTC) FILETIME=[30648B60:01C57728] X-Spam-Score: 0.3 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Mohan Parthasarathy wrote: >=20 > Hi, >=20 > In section 3.1 of the IKEv2 draft, it states that: >=20 > IKE messages use UDP ports 500 and/or 4500, with one IKE > message per UDP datagram. Information from the beginning of > the packet through the UDP header is largely ignored except > that the IP addresses and UDP ports from the headers are > reversed and used for return packets. When sent on UDP port > 500, IKE messages begin immediately following the UDP > header. When sent on UDP port 4500, IKE messages have > prepended four octets of zero. These four octets of zero are > not part of the IKE message and are not included in any of the > length fields or checksums defined by IKE. >=20 > In the clarification draft, >=20 > InitiatorSignedOctets =3D RealMessage1 | NonceRData | MACedIDForI > GenIKEHDR =3D [ four octets 0 if using port 4500 ] | RealIKEHDR >=20 > Which is right ? Interestingly, both RFC 3947 and 3948 > are slient about it. Both are right, if you check the text in clarifications draft carefully: InitiatorSignedOctets =3D RealMessage1 | NonceRData | MACedIDForI GenIKEHDR =3D [ four octets 0 if using port 4500 ] | RealIKEHDR RealIKEHDR =3D SPIi | SPIr | . . . | Length RealMessage1 =3D RealIKEHDR | RestOfMessage1 [...] The four zero octets are not part of RealMessage1, so they're not part of InitiatorSignedOctets either. Best regards, Pasi _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Thu Jun 23 16:58:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlYmU-0007f1-F5; Thu, 23 Jun 2005 16:58:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DlYmS-0007es-ER for ipsec@megatron.ietf.org; Thu, 23 Jun 2005 16:58:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01376 for ; Thu, 23 Jun 2005 16:58:34 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlZAp-00055C-Pp for ipsec@ietf.org; Thu, 23 Jun 2005 17:23:49 -0400 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 j5NKwRbq065577 for ; Thu, 23 Jun 2005 13:58:28 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Thu, 23 Jun 2005 13:57:05 -0700 To: IPsec WG From: Internet-Drafts@ietf.org Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.3 (/) X-Scan-Signature: c0bedb65cce30976f0bf60a0a39edea4 Subject: [Ipsec] I-D ACTION:draft-hoffman-rfc3664bis-03.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 : The AES-XCBC-PRF-128 Algorithm for the Internet Key Exchange Protocol (IKE) Author(s) : P. Hoffman Filename : draft-hoffman-rfc3664bis-03.txt Pages : 5 Date : 2005-6-23 Some implementations of IP Security (IPsec) may want to use a pseudo- random function derived from the Advanced Encryption Standard (AES). This document describes such an algorithm, called AES-XCBC-PRF-128. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-hoffman-rfc3664bis-03.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-rfc3664bis-03.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-rfc3664bis-03.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 Fri Jun 24 12:26:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlr0b-0002H5-6a; Fri, 24 Jun 2005 12:26:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dlr0Z-0002H0-7L for ipsec@megatron.ietf.org; Fri, 24 Jun 2005 12:26:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA22158 for ; Fri, 24 Jun 2005 12:26:18 -0400 (EDT) Received: from e31.co.us.ibm.com ([32.97.110.129]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DlrP4-00005Y-Sn for ipsec@ietf.org; Fri, 24 Jun 2005 12:51:44 -0400 Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e31.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j5OGQ1ai288462 for ; Fri, 24 Jun 2005 12:26:01 -0400 Received: from d03av04.boulder.ibm.com (d03av04.boulder.ibm.com [9.17.195.170]) by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j5OGQ1hE292942 for ; Fri, 24 Jun 2005 10:26:01 -0600 Received: from d03av04.boulder.ibm.com (loopback [127.0.0.1]) by d03av04.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j5OGQ1Nu005573 for ; Fri, 24 Jun 2005 10:26:01 -0600 Received: from d03nm120.boulder.ibm.com (d03nm120.boulder.ibm.com [9.17.195.146]) by d03av04.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j5OGQ1Q9005566 for ; Fri, 24 Jun 2005 10:26:01 -0600 From: Stephen Cuppett To: ipsec@ietf.org Message-ID: Date: Fri, 24 Jun 2005 10:25:59 -0600 X-MIMETrack: Serialize by Router on D03NM120/03/M/IBM(Release 6.5.4|March 27, 2005) at 06/24/2005 10:26:00 MIME-Version: 1.0 X-Spam-Score: 0.0 (/) X-Scan-Signature: 7d33c50f3756db14428398e2bdedd581 Subject: [Ipsec] Stephen Cuppett is out of the office. X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============0421873202==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org --===============0421873202== Content-type: multipart/alternative; Boundary="0__=08BBFAB9DFC9C3868f9e8a93df938690918c08BBFAB9DFC9C386" Content-Disposition: inline --0__=08BBFAB9DFC9C3868f9e8a93df938690918c08BBFAB9DFC9C386 Content-type: text/plain; charset=US-ASCII I will be out of the office starting 06/23/2005 and will not return until 07/18/2005. I will respond to your message when I return. --0__=08BBFAB9DFC9C3868f9e8a93df938690918c08BBFAB9DFC9C386 Content-type: text/html; charset=US-ASCII Content-Disposition: inline

I will be out of the office starting 06/23/2005 and will not return until 07/18/2005.

I will respond to your message when I return. --0__=08BBFAB9DFC9C3868f9e8a93df938690918c08BBFAB9DFC9C386-- --===============0421873202== 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 --===============0421873202==-- From ipsec-bounces@ietf.org Mon Jun 27 11:16:41 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmvLl-0008Hc-F6; Mon, 27 Jun 2005 11:16:41 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DmvLj-0008Dr-Oi for ipsec@megatron.ietf.org; Mon, 27 Jun 2005 11:16:39 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA01736 for ; Mon, 27 Jun 2005 11:16:37 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dmvkt-0007W5-G6 for ipsec@ietf.org; Mon, 27 Jun 2005 11:42:40 -0400 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j5RFGH2q029008; Mon, 27 Jun 2005 11:16:22 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <200506210002.j5L021qf014799@rs15.luxsci.com> References: <200506210002.j5L021qf014799@rs15.luxsci.com> Date: Mon, 27 Jun 2005 10:47:37 -0400 To: "William Dixon" From: Stephen Kent Subject: RE: [Ipsec] Traffic selectors violating own policy 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: b19722fc8d3865b147c75ae2495625f2 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 William, >Based on implementation & deployment experience with IKEv1, I'd prefer >another option. If you choose either B or C below, then you aren't providing >sufficient guidance to enable interop. > >IKEv1 had this issue as well. Windows solved it by always proposing the most >specific selector in policy. This is efficient aggregator of traffic. But my >experience has shown this forces too much a-priori configuration >coordination, so it makes the policy system quite cumbersome to use. I think >Bill told me Solaris has the option of proposing the policy selector OR a >5-tuple generated from the traffic. > >Option D. An IKE initiator MUST not propose a more general selector when it >has a more specific selector for that traffic. It SHOULD propose both the >most specific selector it has configured in policy, as well as a selector >constructed from the 5-tuple of the packet, unless the most specific policy >selector is permit or block. An IKE responder SHOULD match the most specific >selector, and SHOULD respond with the most general matching subset. 2401 and 2401bis specify how to select the SPD entry for an outbound packet. The fact that the SPD is ordered under user/admin control (or decorrelated in 2401bis) provides the basis for policy selection, before one gets to the stage of constructing proposals in IKE. I recall that MS used to have a non-compliant implementation for the Windows SPD, which imposed an arbitrary notion of specificity relative to the 5-tuple selector space, and thus imposed an ordering not controlled by the user/admin. Has this been fixed in more recent implementations? If not, does this non-complaint aspect of the MS IPsec implementation have any bearing on your proposal? Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 27 23:41:01 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn6y4-0002rx-Hp; Mon, 27 Jun 2005 23:41:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn6y2-0002oK-IX for ipsec@megatron.ietf.org; Mon, 27 Jun 2005 23:40:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00225 for ; Mon, 27 Jun 2005 23:40:55 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn7NH-0004b7-Gc for ipsec@ietf.org; Tue, 28 Jun 2005 00:07:05 -0400 Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5S3enmM036389 for ; Mon, 27 Jun 2005 20:40:50 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 27 Jun 2005 20:36:04 -0700 To: IPsec WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: ffa9dfbbe7cc58b3fa6b8ae3e57b0aa3 Subject: [Ipsec] SPI values for messages outside of an IKE_SA X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org The current draft of the clarifications document says: 6.9 SPI values for messages outside of an IKE_SA The IKEv2 specification does not say what SPI values should be used in the IKE header for the small number of notifications that are allowed to be sent outside of an IKE_SA. Note that such notifications are explicitly *not* Informational exchanges; Section 1.5 makes it clear that these are one-way messages that must not be responded to. There are two cases when such a one-way notification can be sent: INVALID_IKE_SPI and INVALID_SPI. In both cases, there are no IKE SPI values that would be meaningful to the recipient of such a notification. A strict interpretation of the specification would require the sender to invent garbage values for the SPI fields. However, we think this was not the intention, and using zero values is acceptable. Can we come to consensus on what to use? If you feel it doesn't matter, feel free to say that, but if you feel that a particular value is important, let's try to find it. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Mon Jun 27 23:41:02 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn6y6-0002sL-3P; Mon, 27 Jun 2005 23:41:02 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn6y2-0002pZ-Um for ipsec@megatron.ietf.org; Mon, 27 Jun 2005 23:40:58 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA00228 for ; Mon, 27 Jun 2005 23:40:55 -0400 (EDT) Received: from above.proper.com ([208.184.76.39]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn7NH-0004b9-It for ipsec@ietf.org; Tue, 28 Jun 2005 00:07:05 -0400 Received: from [10.20.30.249] (dsl2-63-249-92-231.cruzio.com [63.249.92.231]) (authenticated bits=0) by above.proper.com (8.12.11/8.12.9) with ESMTP id j5S3enmO036389 for ; Mon, 27 Jun 2005 20:40:52 -0700 (PDT) (envelope-from paul.hoffman@vpnc.org) Mime-Version: 1.0 Message-Id: Date: Mon, 27 Jun 2005 20:40:47 -0700 To: IPsec WG From: Paul Hoffman Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Spam-Score: 0.0 (/) X-Scan-Signature: 8b30eb7682a596edff707698f4a80f7d Subject: [Ipsec] INVALID_IKE_SPI X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 current version of the clarifications document says: 6.11 INVALID_IKE_SPI Section 3.10.1 says that the INVALID_IKE_SPI notification "indicates an IKE message was received with an unrecognized destination SPI. This usually indicates that the recipient has rebooted and forgotten the existence of an IKE_SA." The text does not say whether the SPI value should be included in the notification. However, it is clear that the notification will be useful to the recipient only if it can find the IKE_SA somehow, so the SPI should be included. This still leaves two questions open: which SPI(s) should be included, and how it (or they) should be sent. For the first question, the alternatives are the unrecognized destination SPI, the source SPI (which presumably would be more useful for the recipient), or both. For the second question, the SPI(s) could be placed in the SPI field(s) in the IKE header, the SPI field in the Notify payload, or the Notification Data field. In the case of another related notification, INVALID_SPI, the situation is clearer: there is only a single SPI, and the text explicitly says that the SPI is sent as Notification Data (since the notification is not about an existing SA, the SPI field in the Notify payload is not used; and obviously the value cannot be placed in the IKE header). Since the INVALID_IKE_SPI notification is sent outside of an IKE_SA, and it is not about an existing SA, it seems that using Notification Data would be the logical choice. However, this issue needs more discussion and we do not yet propose any solution in this document. Do people agree with the conclusion (puting the SPI in the Notification Data)? And which SPI shoul be included? --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 28 01:49:37 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn8yX-0002kf-0l; Tue, 28 Jun 2005 01:49:37 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dn8yV-0002kX-MR for ipsec@megatron.ietf.org; Tue, 28 Jun 2005 01:49:35 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA09663 for ; Tue, 28 Jun 2005 01:49:34 -0400 (EDT) Received: from rs15.luxsci.com ([65.61.166.71]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dn9Nm-0003fC-Jw for ipsec@ietf.org; Tue, 28 Jun 2005 02:15:43 -0400 Received: from rs15.luxsci.com (localhost [127.0.0.1]) by rs15.luxsci.com (8.12.11/8.12.11) with ESMTP id j5S5ms6t020274; Tue, 28 Jun 2005 00:48:54 -0500 Received: (from root@localhost) by rs15.luxsci.com (8.12.11/8.12.11/Submit) id j5S5m1ib019961; Tue, 28 Jun 2005 05:48:01 GMT Message-Id: <200506280548.j5S5m1ib019961@rs15.luxsci.com> Received: (from ietf-wd@v6security.com) by LuxSci SMTP Processor; Tue, 28 Jun 2005 05:48:01 +0000 From: "William Dixon" To: "'Stephen Kent'" Subject: RE: [Ipsec] Traffic selectors violating own policy Date: Tue, 28 Jun 2005 01:46:43 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit In-Reply-To: X-Comment: LuxSci SMTP Processor Message ID - 1119937681-4721585.67869533 X-Spam-Score: 0.8 (/) X-Scan-Signature: 8de5f93cb2b4e3bee75302e9eacc33db 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 Steve, sorry to confuse things, yes 2401 and 2401bis gives specific direction on ordering preference. I confused the discussion by talking about filter ordering in terms of specificity. This does not have bearing on what I'm proposing. What I'm suggesting for the IKEv2 clarifications draft is that both the selector matched in policy, and a dynamically built selector based on the full 5-tuple from the packet be proposed (as optional but recommended for transport mode). The reason is because my deployment experience shows that it is a much needed capability to enable host-to-host IPsec SA establishment when policies on either host are customized for that host, but not necessarily coordinated down to the port level between the two hosts. If you don't propose the full 5-tuple from the packet, there are many circumstances where two host IPsec policies would allow an IPsec SA specific to the 5-tuple to be established, but they would fail if IKE proposes only the selector from policy. You are right, Windows 2000, XP and 2003 does not allow administrator control over selector order. The selector ordering is automatically determined based on an algorithm for specificity (weight). The detailed documentation for selector ordering was made available recently here: http://www.microsoft.com/technet/community/columns/cableguy/cg0205.mspx The weight value itself is shown in the IPsec monitor GUI in XP and 2003, not in Windows 2000. Automatic ordering does not adhere to the requirement in RFC2401 & 2401bis for manual ordering. I have not seen interop problems myself in deployments that result from this difference. Certainly if anyone has, please let me know. However, it's clear how interop might be affected if two different platforms use exactly the same policy design, and the side with manual ordering doesn't also order the filters in the same order as the automatic algorithm in Windows. What I've seen is that the capabilities & supported options of host OS IPsec implementations are sufficiently different that a custom policy is required anyway, one that is tested interoperable with respect to selector negotiation. I don't know the plans for Longhorn for this specific issue. There are many changes for the IPsec implementation in Longhorn, so we'll have to see when the beta is released. > -----Original Message----- > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] > On Behalf Of Stephen Kent > Sent: Monday, June 27, 2005 10:48 AM > To: William Dixon > Cc: 'IPsec WG' > Subject: RE: [Ipsec] Traffic selectors violating own policy > > William, > > >Based on implementation & deployment experience with IKEv1, > I'd prefer > >another option. If you choose either B or C below, then you > aren't providing > >sufficient guidance to enable interop. > > > >IKEv1 had this issue as well. Windows solved it by always > proposing the most > >specific selector in policy. This is efficient aggregator of > traffic. But my > >experience has shown this forces too much a-priori configuration > >coordination, so it makes the policy system quite cumbersome > to use. I think > >Bill told me Solaris has the option of proposing the policy > selector OR a > >5-tuple generated from the traffic. > > > >Option D. An IKE initiator MUST not propose a more general > selector when it > >has a more specific selector for that traffic. It SHOULD > propose both the > >most specific selector it has configured in policy, as well > as a selector > >constructed from the 5-tuple of the packet, unless the most > specific policy > >selector is permit or block. An IKE responder SHOULD match > the most specific > >selector, and SHOULD respond with the most general matching subset. > > 2401 and 2401bis specify how to select the SPD entry for an outbound > packet. The fact that the SPD is ordered under user/admin control (or > decorrelated in 2401bis) provides the basis for policy selection, > before one gets to the stage of constructing proposals in IKE. > > I recall that MS used to have a non-compliant implementation for the > Windows SPD, which imposed an arbitrary notion of specificity > relative to the 5-tuple selector space, and thus imposed an ordering > not controlled by the user/admin. Has this been fixed in more recent > implementations? If not, does this non-complaint aspect of the MS > IPsec implementation have any bearing on your proposal? > > Steve > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec > > _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 28 04:41:47 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnBf8-0004AJ-VL; Tue, 28 Jun 2005 04:41:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnBf5-00046p-Ne for ipsec@megatron.ietf.org; Tue, 28 Jun 2005 04:41:43 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13166 for ; Tue, 28 Jun 2005 04:41:41 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext04.nokia.com ([131.228.20.96]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnC4P-0004R4-Ej for ipsec@ietf.org; Tue, 28 Jun 2005 05:07:53 -0400 Received: from esebh108.NOE.Nokia.com (esebh108.ntc.nokia.com [172.21.143.145]) by mgw-ext04.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j5S8b9dn021564; Tue, 28 Jun 2005 11:37:10 +0300 Received: from esebh104.NOE.Nokia.com ([172.21.143.34]) by esebh108.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Jun 2005 11:41:36 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Jun 2005 11:41:35 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] INVALID_IKE_SPI Date: Tue, 28 Jun 2005 11:41:30 +0300 Message-ID: Thread-Topic: [Ipsec] INVALID_IKE_SPI Thread-Index: AcV7lEt7kn/7KCKlR8KmenTd8+8/uQAJvbiQ To: , X-OriginalArrivalTime: 28 Jun 2005 08:41:35.0240 (UTC) FILETIME=[3114A880:01C57BBD] X-Spam-Score: 0.3 (/) X-Scan-Signature: e8a67952aa972b528dd04570d58ad8fe Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hmm... regardless of where the SPI (or SPIs) is sent, it looks=20 like the most useful piece of information for the the recipient=20 of the INVALID_IKE_SPI notification is its own SPI, not the SPI=20 of the party who sent the notification. The recipient of the notification could have a large number of=20 IKE_SAs with different peers, and some of those peers might have=20 picked identical SPIs; but the SPI chosen locally uniquely=20 identifies the IKE_SA in question. Best regards, Pasi > -----Original Message----- > From: Paul Hoffman > Sent: Tuesday, June 28, 2005 6:41 AM > To: IPsec WG > Subject: [Ipsec] INVALID_IKE_SPI >=20 >=20 > The current version of the clarifications document says: >=20 > 6.11 INVALID_IKE_SPI >=20 > Section 3.10.1 says that the INVALID_IKE_SPI notification=20 > "indicates an IKE message was received with an unrecognized=20 > destination SPI. This usually indicates that the recipient=20 > has rebooted and forgotten the existence of an IKE_SA." >=20 > The text does not say whether the SPI value should be=20 > included in the notification. However, it is clear that=20 > the notification will be useful to the recipient only if=20 > it can find the IKE_SA somehow, so > the SPI should be included. >=20 > This still leaves two questions open: which SPI(s) should be > included, and how it (or they) should be sent. For the first > question, the alternatives are the unrecognized=20 > destination SPI, the source SPI (which presumably would be=20 > more useful for the recipient), or both. For the second=20 > question, the SPI(s) could be placed in the SPI field(s)=20 > in the IKE header, the SPI field in the Notify payload, > or the Notification Data field. >=20 > In the case of another related notification, INVALID_SPI, the > situation is clearer: there is only a single SPI, and the text > explicitly says that the SPI is sent as Notification Data=20 > (since the notification is not about an existing SA, the=20 > SPI field in the Notify payload is not used; and obviously=20 > the value cannot be placed in the IKE header). >=20 > Since the INVALID_IKE_SPI notification is sent outside of=20 > an IKE_SA, and it is not about an existing SA, it seems that=20 > using Notification Data would be the logical choice. However,=20 > this issue needs more discussion and we do not yet propose=20 > any solution in this document. >=20 > Do people agree with the conclusion (puting the SPI in the=20 > Notification Data)? And which SPI shoul be included? >=20 > --Paul Hoffman, Director > --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 28 06:16:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnD8R-00059N-C3; Tue, 28 Jun 2005 06:16:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnD8P-00059I-23 for ipsec@megatron.ietf.org; Tue, 28 Jun 2005 06:16:05 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA19156 for ; Tue, 28 Jun 2005 06:16:02 -0400 (EDT) Received: from nav2.lgsoftindia.com ([203.200.13.13] helo=nav2.lgdomain.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DnDXg-0002vK-UA for ipsec@ietf.org; Tue, 28 Jun 2005 06:42:16 -0400 Received: from appolo.lgdomain.com ([192.168.1.21]) by nav2.lgdomain.com (SMSSMTP 4.1.2.20) with SMTP id M2005062815520115892 for ; Tue, 28 Jun 2005 15:52:01 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Tue, 28 Jun 2005 15:51:50 +0530 Message-ID: Thread-Topic: Configuration payload and traffic selectors Thread-Index: AcV7yzKnE6VEf0ozR7WZtg9qNcu22w== From: "Ravi Prasad" To: X-Spam-Score: 2.2 (++) X-Scan-Signature: 21bf7a2f1643ae0bf20c1e010766eb78 Subject: [Ipsec] Configuration payload and traffic selectors X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1890766756==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1890766756== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57BCB.390AE86E" This is a multi-part message in MIME format. ------_=_NextPart_001_01C57BCB.390AE86E Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 SGksDQoNCkFzc3VtZSB0aGUgc2NlbmFyaW8gd2hlcmUgYSByZW1vdGUgaG9zdCBjb25uZWN0 cyB0byBpbnRlcm5ldCB0aHJvdWdoIGhpcw0KY29ycG9yYXRlIGdhdGV3YXkuDQoNClRvIGRv IHRoaXMgYSBDUCBwYXlsb2FkIChDRkdfUkVRVUVTVCB3aXRoIElOVEVSTkFMX0FERFJFU1Mg YXR0cmlidXRlIG9mDQp0eXBlIElQdjQpIGlzIGluY2x1ZGVkIGFzIHBhcnQgb2YgQ1JFQVRF X0NISUxEX1NBIG1lc3NhZ2UuDQoNCiANCg0KVGhlIGRyYWZ0IHNheXMgdGhhdCANCg0KIlRo ZSBDUCBwYXlsb2FkIE1VU1QgYmUgaW5zZXJ0ZWQgYmVmb3JlIHRoZSBTQSBwYXlsb2FkLg0K IEluIHZhcmlhdGlvbnMgb2YgdGhlIHByb3RvY29sIHdoZXJlIHRoZXJlIGFyZSBtdWx0aXBs ZSBJS0VfQVVUSA0KZXhjaGFuZ2VzLCB0aGUgQ1AgcGF5bG9hZHMgDQogIE1VU1QgYmUgaW5z ZXJ0ZWQgaW4gdGhlIG1lc3NhZ2VzIGNvbnRhaW5pbmcgdGhlIFNBIHBheWxvYWRzLiINCiAN ClRoZXJlIGlzIG5vIGlzc3VlIGluIGJ1aWxkaW5nIFNBIHBheWxvYWQuIEkgaGF2ZSBkb3Vi dCBvbiBob3cgdG8gYnVpbGQNClRyYWZmaWMgc2VsZWN0b3JzIFRTaT8gDQpUaGUgZHJhZnQo ZHJhZnQtaWV0Zi1pcHNlYy1pa2V2Mi0xNy50eHQgc2VjIDIuOSkgc2F5cyB0aGF0DQoiVGhl IGZpcnN0IG9mIHRoZSB0d28gVFMgcGF5bG9hZHMgaXMga25vd24gYXMgVFNpIChUcmFmZmlj IFNlbGVjdG9yLQ0KaW5pdGlhdG9yKS4gIFRoZSBzZWNvbmQgaXMgDQogIGtub3duIGFzIFRT ciAoVHJhZmZpYyBTZWxlY3Rvci1yZXNwb25kZXIpLiBUU2kgc3BlY2lmaWVzIHRoZSBzb3Vy Y2UNCmFkZHJlc3Mgb2YgdHJhZmZpYyBmb3J3YXJkZWQgDQogIGZyb20gKG9yIHRoZSBkZXN0 aW5hdGlvbiBhZGRyZXNzIG9mIHRyYWZmaWMgZm9yd2FyZGVkIHRvKSB0aGUNCmluaXRpYXRv ciBvZiB0aGUgQ0hJTERfU0EgcGFpci4iDQogDQpJbiB0aGlzIGNhc2Ugd2hhdCB3aWxsIGJl IG15IFRTaT8NCklzIGl0IHRoZSBsb2NhbCBhZGRyZXNzIGluIHRoZSByZW1vdGUgbmV0d29y az8gT3IgaXMgaXQgd2lsZCBjYXJkDQphZGRyZXNzPw0KIA0KVGhhbmtzIGFuZCBSZWdhcmRz DQpSYXZpIHByYXNhZA0KIA0KDQogDQoNCiANCg0KIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjDQpUaGlzIEVt YWlsIE1lc3NhZ2UgaXMgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50KHMpIGFuZCBNYXkgY29udGFpbiBDT05GSURFTlRJQUwgYW5kIFBSSVZJTEVHRUQgaW5m b3JtYXRpb24uDQpMRyBTb2Z0IEluZGlhIHdpbGwgbm90IGJlIHJlc3BvbmlzaWJsZSBmb3Ig YW55IHZpcnVzZXMgb3IgZGVmZWN0cyBvcg0KYW55IGZvcndhcmRlZCBhdHRhY2hlbWVudHMg ZW1hbmF0aW5nIGVpdGhlciBmcm9tIHdpdGhpbg0KTEcgU29mdCBJbmRpYSBvciBvdXRzaWRl LiBBbnkgdW5hdXRob3Jpc2VkIHJldmlldyAsIHVzZSwgZGlzY2xvc3VyZSBvciBkaXN0cmli dXRpb24gaXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgaW50ZW50ZGVkDQpyZWNpcGll bnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYnkgcmVwbHkgZW1haWwgYW5kIGRlc3Ry b3kgYWxsDQpjb3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQojIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyM= ------_=_NextPart_001_01C57BCB.390AE86E Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNl IiB4bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxu czpzdDE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyIgeG1s bnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KDQo8aGVhZD4NCjxtZXRh IGh0dHAtZXF1aXY9Q29udGVudC1UeXBlIGNvbnRlbnQ9InRleHQvaHRtbDsgY2hhcnNldD11 cy1hc2NpaSI+DQo8bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29y ZCAxMSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8bzpTbWFydFRhZ1R5cGUgbmFtZXNwYWNldXJp PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiDQogbmFtZT0i cGxhY2UiIGRvd25sb2FkdXJsPSJodHRwOi8vd3d3LjVpYW50bGF2YWxhbXAuY29tLyIvPg0K PCEtLVtpZiAhbXNvXT4NCjxzdHlsZT4NCnN0MVw6KntiZWhhdmlvcjp1cmwoI2RlZmF1bHQj aWVvb3VpKSB9DQo8L3N0eWxlPg0KPCFbZW5kaWZdLS0+DQo8c3R5bGU+DQo8IS0tDQogLyog U3R5bGUgRGVmaW5pdGlvbnMgKi8NCiBwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYu TXNvTm9ybWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZv bnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21hbiI7fQ0KYTps aW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXtjb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlv bjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ e2NvbG9yOnB1cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnByZQ0KCXtt YXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0 Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7 bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseTpBcmlhbDsN Cgljb2xvcjp3aW5kb3d0ZXh0O30NCkBwYWdlIFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEu MGluOw0KCW1hcmdpbjoxLjBpbiAxLjI1aW4gMS4waW4gMS4yNWluO30NCmRpdi5TZWN0aW9u MQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT4NCg0KPC9oZWFkPg0KDQo8Ym9k eSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+DQoNCjxkaXYgY2xhc3M9U2Vj dGlvbjE+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz5IaSw8 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZv bnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpm b250LWZhbWlseTpBcmlhbCc+QXNzdW1lIHRoZSBzY2VuYXJpbyB3aGVyZSBhIHJlbW90ZSBo b3N0IGNvbm5lY3RzIHRvIGludGVybmV0DQp0aHJvdWdoIGhpcyBjb3Jwb3JhdGUgZ2F0ZXdh eS48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7 DQpmb250LWZhbWlseTpBcmlhbCc+VG8gZG8gdGhpcyBhIENQIHBheWxvYWQgKENGR19SRVFV RVNUIHdpdGggPC9zcGFuPjwvZm9udD5JTlRFUk5BTF9BRERSRVNTDQphdHRyaWJ1dGUgb2Yg dHlwZSBJUHY0KSBpcyBpbmNsdWRlZCBhcyBwYXJ0IG9mIENSRUFURV9DSElMRF9TQSBtZXNz YWdlLjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0z IGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBw dCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxl PSdmb250LXNpemU6DQoxMi4wcHQnPlRoZSBkcmFmdCBzYXlzIHRoYXQgPG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCg0KPHByZT48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBO ZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mIzgyMjA7VGhlIENQIHBheWxv YWQgTVVTVCBiZSBpbnNlcnRlZCBiZWZvcmUgdGhlIFNBIHBheWxvYWQuPG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiBJbiB2YXJpYXRpb25zIG9mIHRo ZSBwcm90b2NvbCB3aGVyZSB0aGVyZSBhcmUgbXVsdGlwbGUgSUtFX0FVVEggZXhjaGFuZ2Vz LCB0aGUgQ1AgcGF5bG9hZHMgPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+ PGZvbnQNCnNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQnPiZuYnNwOyZuYnNwO01VU1QgYmUgaW5zZXJ0ZWQgaW4gdGhlIG1lc3NhZ2Vz IGNvbnRhaW5pbmcgdGhlIFNBIHBheWxvYWRzLiYjODIyMTs8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3Bh biBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9m b250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPlRoZXJlIGlzIG5vIGlzc3VlIGluIGJ1aWxkaW5n IFNBIHBheWxvYWQuIEkgaGF2ZSBkb3VidCBvbiBob3cgdG8gYnVpbGQgVHJhZmZpYyBzZWxl Y3RvcnMgVFNpPyA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0K c2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dCc+VGhlIGRyYWZ0KGRyYWZ0LWlldGYtaXBzZWMtaWtldjItMTcudHh0IHNlYyAyLjkpIHNh eXMgdGhhdDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXpl PTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4m IzgyMjA7VGhlIGZpcnN0IG9mIHRoZSB0d28gVFMgcGF5bG9hZHMgaXMga25vd24gYXMgVFNp IChUcmFmZmljIFNlbGVjdG9yLSBpbml0aWF0b3IpLiZuYnNwOyBUaGUgc2Vjb25kIGlzIDxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgZmFjZT0i Q291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mbmJzcDsmbmJz cDtrbm93biBhcyBUU3IgKFRyYWZmaWMgU2VsZWN0b3ItcmVzcG9uZGVyKS4gVFNpIHNwZWNp ZmllcyB0aGUgc291cmNlIGFkZHJlc3Mgb2YgdHJhZmZpYyBmb3J3YXJkZWQgPG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBmYWNlPSJDb3VyaWVy IE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZuYnNwOyZuYnNwO2Zyb20g KG9yIHRoZSBkZXN0aW5hdGlvbiBhZGRyZXNzIG9mIHRyYWZmaWMgZm9yd2FyZGVkIHRvKSB0 aGUgaW5pdGlhdG9yIG9mIHRoZSBDSElMRF9TQSBwYWlyLiYjODIyMTs8bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3 Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPkluIHRoaXMgY2FzZSB3aGF0IHdpbGwg YmUgbXkgVFNpPzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpz aXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Jz5JcyBpdCB0aGUgbG9jYWwgYWRkcmVzcyBpbiB0aGUgcmVtb3RlIG5ldHdvcms/IE9yIGlz IGl0IHdpbGQgY2FyZCBhZGRyZXNzPzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48 cHJlPjxmb250DQpzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHBy ZT48Zm9udA0Kc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdCc+VGhhbmtzIGFuZCBSZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcHJlPjxwcmU+PHN0MTpwbGFjZQ0KdzpzdD0ib24iPjxmb250IHNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPlJhdmk8L3NwYW4+ PC9mb250Pjwvc3QxOnBsYWNlPiBwcmFzYWQ8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PGZvbnQN CnNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxmb250IHNpemU9MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6DQoxMi4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9u dD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPC9ib2R5Pg0K DQo8L2h0bWw+PHByZT4jIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMNClRoaXMgRW1haWwgTWVzc2FnZSBpcyBm b3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNpcGllbnQocykgYW5kIE1heSBj b250YWluIENPTkZJREVOVElBTCBhbmQgUFJJVklMRUdFRCBpbmZvcm1hdGlvbi4NCkxHIFNv ZnQgSW5kaWEgd2lsbCBub3QgYmUgcmVzcG9uaXNpYmxlIGZvciBhbnkgdmlydXNlcyBvciBk ZWZlY3RzIG9yDQphbnkgZm9yd2FyZGVkIGF0dGFjaGVtZW50cyBlbWFuYXRpbmcgZWl0aGVy IGZyb20gd2l0aGluDQpMRyBTb2Z0IEluZGlhIG9yIG91dHNpZGUuIEFueSB1bmF1dGhvcmlz ZWQgcmV2aWV3ICwgdXNlLCBkaXNjbG9zdXJlIG9yIGRpc3RyaWJ1dGlvbiBpcyBwcm9oaWJp dGVkLiBJZiB5b3UgYXJlIG5vdCBpbnRlbnRkZWQNCnJlY2lwaWVudCwgcGxlYXNlIGNvbnRh Y3QgdGhlIHNlbmRlciBieSByZXBseSBlbWFpbCBhbmQgZGVzdHJveSBhbGwNCmNvcGllcyBv ZiB0aGUgb3JpZ2luYWwgbWVzc2FnZS4NCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIzwvcHJlPg== ------_=_NextPart_001_01C57BCB.390AE86E-- --===============1890766756== 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 --===============1890766756==-- From ipsec-bounces@ietf.org Tue Jun 28 09:22:08 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnG2R-00075M-VJ; Tue, 28 Jun 2005 09:22:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnG2Q-00075E-0h for ipsec@megatron.ietf.org; Tue, 28 Jun 2005 09:22:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07033 for ; Tue, 28 Jun 2005 09:22:04 -0400 (EDT) Received: from aragorn.bbn.com ([128.33.0.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnGRl-00029D-Cv for ipsec@ietf.org; Tue, 28 Jun 2005 09:48:18 -0400 Received: from [128.89.89.106] (dhcp89-089-106.bbn.com [128.89.89.106]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id j5SDLm2o015568; Tue, 28 Jun 2005 09:21:48 -0400 (EDT) Mime-Version: 1.0 Message-Id: In-Reply-To: <200506280548.j5S5m1ib019961@rs15.luxsci.com> References: <200506280548.j5S5m1ib019961@rs15.luxsci.com> Date: Tue, 28 Jun 2005 08:15:00 -0400 To: "William Dixon" From: Stephen Kent Subject: RE: [Ipsec] Traffic selectors violating own policy 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: 538aad3a3c4f01d8b6a6477ca4248793 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 At 1:46 AM -0400 6/28/05, William Dixon wrote: >Steve, sorry to confuse things, yes 2401 and 2401bis gives specific >direction on ordering preference. I confused the discussion by talking about >filter ordering in terms of specificity. This does not have bearing on what >I'm proposing. OK. >What I'm suggesting for the IKEv2 clarifications draft is that both the >selector matched in policy, and a dynamically built selector based on the >full 5-tuple from the packet be proposed (as optional but recommended for >transport mode). The reason is because my deployment experience shows that >it is a much needed capability to enable host-to-host IPsec SA establishment >when policies on either host are customized for that host, but not >necessarily coordinated down to the port level between the two hosts. If you >don't propose the full 5-tuple from the packet, there are many circumstances >where two host IPsec policies would allow an IPsec SA specific to the >5-tuple to be established, but they would fail if IKE proposes only the >selector from policy. Sounds reasonable to me. Thanks for the clarification. >You are right, Windows 2000, XP and 2003 does not allow administrator >control over selector order. The selector ordering is automatically >determined based on an algorithm for specificity (weight). The detailed >documentation for selector ordering was made available recently here: >http://www.microsoft.com/technet/community/columns/cableguy/cg0205.mspx > >The weight value itself is shown in the IPsec monitor GUI in XP and 2003, >not in Windows 2000. Automatic ordering does not adhere to the requirement >in RFC2401 & 2401bis for manual ordering. I have not seen interop problems >myself in deployments that result from this difference. Certainly if anyone >has, please let me know. However, it's clear how interop might be affected >if two different platforms use exactly the same policy design, and the side >with manual ordering doesn't also order the filters in the same order as the >automatic algorithm in Windows. What I've seen is that the capabilities & >supported options of host OS IPsec implementations are sufficiently >different that a custom policy is required anyway, one that is tested >interoperable with respect to selector negotiation. I don't know the plans >for Longhorn for this specific issue. There are many changes for the IPsec >implementation in Longhorn, so we'll have to see when the beta is released. > It is not a matter of interoperability; explicit (manual) ordering is mandated for IPsec to enable a user/admin to express a specific access control policy in a precise fashion. The need o be able to order entries in an ACL where wild cards are allowed in names is a common one, dating back at least 30 years, e.g., Multics. This convention is almost universally employed in firewalls to manage rule sets, in router filters, etc. Not providing this facility makes it harder for a user/admin to ensure that a specific access control policy is properly represented in the SPD. Steve _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 28 09:50:35 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnGTz-0005wY-B1; Tue, 28 Jun 2005 09:50:35 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnGTx-0005vS-Ar for ipsec@megatron.ietf.org; Tue, 28 Jun 2005 09:50:33 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA09258 for ; Tue, 28 Jun 2005 09:50:31 -0400 (EDT) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnGtI-00052e-CD for ipsec@ietf.org; Tue, 28 Jun 2005 10:16:46 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id j5SDo8nP023854; Tue, 28 Jun 2005 16:50:09 +0300 (IDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=WINDOWS-1252; delsp=yes; format=flowed Message-Id: <9cb56baa3e2686b6f608493f372a94d9@checkpoint.com> Content-Transfer-Encoding: quoted-printable From: Yoav Nir Subject: Re: [Ipsec] Configuration payload and traffic selectors Date: Tue, 28 Jun 2005 16:50:07 +0300 To: "Ravi Prasad" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 244a2fd369eaf00ce6820a760a3de2e8 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 In section 2.19 (page 34 in draft -17) there is an example with a =20 universal TSi (=3D (0,0-65536,0.0.0.0-255.255.255.255) ) In its response, the responder narrows it down to the assigned IP =20 address (in the example, (0,0-65536,192.0.2.202-192.0.2.202) ) On Jun 28, 2005, at 1:21 PM, Ravi Prasad wrote: > > Hi, > Assume the scenario where a remote host connects to internet through =20= > his corporate gateway. > To do this a CP payload (CFG_REQUEST with INTERNAL_ADDRESS attribute =20= > of type IPv4) is included as part of CREATE_CHILD_SA message. > =A0 > The draft says that > =93The CP payload MUST be inserted before the SA payload. > In variations of the protocol where there are multiple IKE_AUTH =20 > exchanges, the CP payloads > =A0=A0MUST be inserted in the messages containing the SA payloads.=94 > =A0 > There is no issue in building SA payload. I have doubt on how to build = =20 > Traffic selectors TSi? > The draft(draft-ietf-ipsec-ikev2-17.txt sec 2.9) says that > =93The first of the two TS payloads is known as TSi (Traffic Selector- = =20 > initiator).=A0 The second is > =A0=A0known as TSr (Traffic Selector-responder). TSi specifies the = source =20 > address of traffic forwarded > =A0=A0from (or the destination address of traffic forwarded to) the =20= > initiator of the CHILD_SA pair.=94 > =A0 > In this case what will be my TSi? > Is it the local address in the remote network? Or is it wild card =20 > address? > =A0 > Thanks and Regards > Ravi prasad > =A0 > =A0 > =A0 > ##################################################################### > This Email Message is for the sole use of the intended recipient(s) =20= > and May contain CONFIDENTIAL and PRIVILEGED information. > LG Soft India will not be responisible for any viruses or defects or > any forwarded attachements emanating either from within > LG Soft India or outside. Any unauthorised review , use, disclosure or = =20 > distribution is prohibited. If you are not intentded > recipient, please contact the sender by reply email and destroy all > copies of the original message. > = #####################################################################__=20= > _____________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 28 10:11:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnGoY-0004E2-CD; Tue, 28 Jun 2005 10:11:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnGoV-0004DA-HX for ipsec@megatron.ietf.org; Tue, 28 Jun 2005 10:11:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA11982 for ; Tue, 28 Jun 2005 10:11:45 -0400 (EDT) Received: from nav2.lgsoftindia.com ([203.200.13.13] helo=nav2.lgdomain.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DnHDq-0007M4-MJ for ipsec@ietf.org; Tue, 28 Jun 2005 10:38:00 -0400 Received: from appolo.lgdomain.com ([192.168.1.21]) by nav2.lgdomain.com (SMSSMTP 4.1.2.20) with SMTP id M2005062819474916836 ; Tue, 28 Jun 2005 19:47:49 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: [Ipsec] Configuration payload and traffic selectors Date: Tue, 28 Jun 2005 19:47:48 +0530 Message-ID: Thread-Topic: [Ipsec] Configuration payload and traffic selectors Thread-Index: AcV7yzKnE6VEf0ozR7WZtg9qNcu22wAFG17gAAK8+5A= From: "Ravi Prasad" To: "Srinivas V. Chakravarty" , "Yoav Nir" X-Spam-Score: 2.2 (++) X-Scan-Signature: b38aee91eedbacb27d28d558bc16c035 Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1604815119==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1604815119== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57BEC.298D8DE6" This is a multi-part message in MIME format. ------_=_NextPart_001_01C57BEC.298D8DE6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 SGksDQoNCkp1c3QgY29ycmVjdCBtZSBpZiBJIGFtIHdyb25nLg0KDQpJIHRob3VnaHQgdGhh dCB0aGVyZSB3aWxsIGJlIHR3byBUU2kgYW5kIFRTcidzLiBPbmUgd2l0aCBDUCBwYXlsb2Fk IGFuZA0Kb25lIGZvciB0aGUgY2hpbGQgU0EuDQoNCkkgbWVhbiBzb21lIHRoaW5nIGxpa2Ug dGhpcw0KDQpJS0VfQVVUSCA9ICAge0hEUiwgU0sge0lEaSwgW0NFUlQsXSBbQ0VSVFJFUSxd ICBbSURyLF0gQVVUSCwgDQoNCiAgICAgICAgICAgICBDUChDRkdfUkVRVUVTVCksIFRTaSwg VFNyIC8qIFRoaXMgVFNpIGFuZCBUU3IgYXJlIGZvciB0aGUNCkNQIHBheWxvYWQgKi8NCg0K ICAgICAgICAgICAgIFNBaTIsIFRTaSwgVFNyfSAgLyogVGhpcyBUU2kgYW5kIFRTciBhcmUg Zm9yIHRoZSBDaGlsZCBTQQ0KcGF5bG9hZCAqLw0KDQogDQoNClUgbWVhbnMgdG8gc2F5IHRo YXQgICBJS0VfQVVUSCAgICBpcyBsaWtlIHRoaXMgICAgICAgICAgICAgICAgICAgDQoNCklL RV9BVVRIID0gICB7SERSLCBTSyB7SURpLCBbQ0VSVCxdIFtDRVJUUkVRLF0gIFtJRHIsXSBB VVRILCANCg0KICAgICAgICAgICAgIENQKENGR19SRVFVRVNUKSwgDQoNCiAgICAgICAgICAg ICBTQWkyLCBUU2ksIFRTcn0gIC8qIFRoaXMgVFNpIGFuZCBUU3IgYXJlIGZvciB0aGUgQ2hp bGQgU0ENCnBheWxvYWQgKi8NCg0KIA0KDQpUaGUgVFNpICBhbmQgVFNyIHJlZmVycmVkIENQ IHBheWxvYWQgYmVsb3cgDQoNCiAgICAgICAiICBGb3IgZXhhbXBsZSwgbWVzc2FnZSBmcm9t IGluaXRpYXRvciB0byByZXNwb25kZXI6DQoNCiAgICAgICAgICAgICAgICAgQ1AoQ0ZHX1JF UVVFU1QpPQ0KDQogICAgICAgICAgICAgICAgICAgICAgICBJTlRFUk5BTF9BRERSRVNTKDAu MC4wLjApDQoNCiAgICAgICAgICAgICAgICAgICAgICAgSU5URVJOQUxfTkVUTUFTSygwLjAu MC4wKQ0KDQogICAgICAgICAgICAgICAgICAgICAgSU5URVJOQUxfRE5TKDAuMC4wLjApDQoN CiAgICAgICAgICAgICAgVFNpID0gKDAsIDAtNjU1MzYsMC4wLjAuMC0yNTUuMjU1LjI1NS4y NTUpDQoNCiAgICAgICAgICAgICBUU3IgPSAoMCwgMC02NTUzNiwwLjAuMC4wLTI1NS4yNTUu MjU1LjI1NSkiDQoNCiANCg0KYXJlIHRvIGJlIHNlbnQgd2l0aCBTQSBwYXlsb2FkIGZvciBj aGlsZCBTQSBjcmVhdGlvbi4gVGhleSBhcmUgbm90IHBhcnQNCm9mIENQKENGR19SRVFVRVNU KS4gQ1AgKENGR19SRVFVRVNUKSBpcyBsaWtlIHRoaXMNCg0KQ1AoQ0ZHX1JFUVVFU1QpPQ0K DQogICAgICAgICAgICAgICAgICAgICAgICBJTlRFUk5BTF9BRERSRVNTKDAuMC4wLjApDQoN CiAgICAgICAgICAgICAgICAgICAgICAgSU5URVJOQUxfTkVUTUFTSygwLjAuMC4wKQ0KDQog ICAgICAgICAgICAgICAgICAgICAgSU5URVJOQUxfRE5TKDAuMC4wLjApDQoNCiANCg0KS2lu ZGx5IGVtYWlsIHdoZXRoZXIgbXkgdW5kZXJzdGFuZGluZyBpcyBjb3JyZWN0Lg0KDQogDQoN ClRoYW5rcyBhbmQgcmVnYXJkcw0KDQpSYXZpIFByYXNhZA0KDQogDQoNCiANCg0KIA0KDQog DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkZyb206IFNyaW5pdmFz IFYuIENoYWtyYXZhcnR5IA0KU2VudDogVHVlc2RheSwgSnVuZSAyOCwgMjAwNSA2OjI0IFBN DQpUbzogUmF2aSBQcmFzYWQNClN1YmplY3Q6IFJFOiBbSXBzZWNdIENvbmZpZ3VyYXRpb24g cGF5bG9hZCBhbmQgdHJhZmZpYyBzZWxlY3RvcnMNCg0KIA0KDQpIaSwNCg0KIA0KDQpQbGVh c2UgcmVmZXIgdG8gdGhlIHNlY3Rpb24gMi4xOSBpbiB0aGUgZHJhZnQtaWV0Zi1pcHNlYy1p a2V2Mi0xNy50eHQuDQoNCiANCg0KRm9yIGV4YW1wbGUsIG1lc3NhZ2UgZnJvbSBpbml0aWF0 b3IgdG8gcmVzcG9uZGVyOg0KDQogICAgICBDUChDRkdfUkVRVUVTVCk9DQoNCiAgICAgICAg SU5URVJOQUxfQUREUkVTUygwLjAuMC4wKQ0KDQogICAgICAgIElOVEVSTkFMX05FVE1BU0so MC4wLjAuMCkNCg0KICAgICAgICBJTlRFUk5BTF9ETlMoMC4wLjAuMCkNCg0KICAgICAgVFNp ID0gKDAsIDAtNjU1MzYsMC4wLjAuMC0yNTUuMjU1LjI1NS4yNTUpDQoNCiAgICAgIFRTciA9 ICgwLCAwLTY1NTM2LDAuMC4wLjAtMjU1LjI1NS4yNTUuMjU1KQ0KDQogDQoNClRoZSBpbml0 aWF0b3Igc3BlY2lmaWVzIHRoZSBwb3NzaWJsZSByYW5nZSBvZiBhZGRyZXNzZXMuIFRoZSBy ZXNwb25kZXINCndvdWxkIHNldCBhIHBhcnRpY3VsYXIgKCBvciBtYXkgYmUgcmFuZ2U/KSB0 byB0aGUgVHNpIHZhbHVlIGluIGl0cw0KcmVzcG9uc2UuIExvb2sgYXQgdGhlIHJlc3BvbnNl LA0KDQogDQoNCiAgICAgIENQKENGR19SRVBMWSk9DQoNCiAgICAgICAgSU5URVJOQUxfQURE UkVTUygxOTIuMC4yLjIwMikNCg0KICAgICAgICBJTlRFUk5BTF9ORVRNQVNLKDI1NS4yNTUu MjU1LjApDQoNCiAgICAgICAgSU5URVJOQUxfU1VCTkVUKDE5Mi4wLjIuMC8yNTUuMjU1LjI1 NS4wKQ0KDQogICAgICBUU2kgPSAoMCwgMC02NTUzNiwxOTIuMC4yLjIwMi0xOTIuMC4yLjIw MikNCg0KICAgICAgVFNyID0gKDAsIDAtNjU1MzYsMTkyLjAuMi4wLTE5Mi4wLjIuMjU1KQ0K DQogDQoNClJlZ2FyZHMsDQoNClNyaW5pdmFzIENoYWtyYXZhcnR5DQoNCiANCg0KIA0KDQog DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkZyb206IGlwc2VjLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzppcHNlYy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYNCk9mIFJhdmkgUHJhc2FkDQpTZW50OiBUdWVzZGF5LCBKdW5lIDI4LCAyMDA1IDM6NTIg UE0NClRvOiBpcHNlY0BpZXRmLm9yZw0KU3ViamVjdDogW0lwc2VjXSBDb25maWd1cmF0aW9u IHBheWxvYWQgYW5kIHRyYWZmaWMgc2VsZWN0b3JzDQoNCiANCg0KSGksDQoNCkFzc3VtZSB0 aGUgc2NlbmFyaW8gd2hlcmUgYSByZW1vdGUgaG9zdCBjb25uZWN0cyB0byBpbnRlcm5ldCB0 aHJvdWdoIGhpcw0KY29ycG9yYXRlIGdhdGV3YXkuDQoNClRvIGRvIHRoaXMgYSBDUCBwYXls b2FkIChDRkdfUkVRVUVTVCB3aXRoIElOVEVSTkFMX0FERFJFU1MgYXR0cmlidXRlIG9mDQp0 eXBlIElQdjQpIGlzIGluY2x1ZGVkIGFzIHBhcnQgb2YgQ1JFQVRFX0NISUxEX1NBIG1lc3Nh Z2UuDQoNCiANCg0KVGhlIGRyYWZ0IHNheXMgdGhhdCANCg0KIlRoZSBDUCBwYXlsb2FkIE1V U1QgYmUgaW5zZXJ0ZWQgYmVmb3JlIHRoZSBTQSBwYXlsb2FkLg0KIEluIHZhcmlhdGlvbnMg b2YgdGhlIHByb3RvY29sIHdoZXJlIHRoZXJlIGFyZSBtdWx0aXBsZSBJS0VfQVVUSA0KZXhj aGFuZ2VzLCB0aGUgQ1AgcGF5bG9hZHMgDQogIE1VU1QgYmUgaW5zZXJ0ZWQgaW4gdGhlIG1l c3NhZ2VzIGNvbnRhaW5pbmcgdGhlIFNBIHBheWxvYWRzLiINCiANClRoZXJlIGlzIG5vIGlz c3VlIGluIGJ1aWxkaW5nIFNBIHBheWxvYWQuIEkgaGF2ZSBkb3VidCBvbiBob3cgdG8gYnVp bGQNClRyYWZmaWMgc2VsZWN0b3JzIFRTaT8gDQpUaGUgZHJhZnQoZHJhZnQtaWV0Zi1pcHNl Yy1pa2V2Mi0xNy50eHQgc2VjIDIuOSkgc2F5cyB0aGF0DQoiVGhlIGZpcnN0IG9mIHRoZSB0 d28gVFMgcGF5bG9hZHMgaXMga25vd24gYXMgVFNpIChUcmFmZmljIFNlbGVjdG9yLQ0KaW5p dGlhdG9yKS4gIFRoZSBzZWNvbmQgaXMgDQogIGtub3duIGFzIFRTciAoVHJhZmZpYyBTZWxl Y3Rvci1yZXNwb25kZXIpLiBUU2kgc3BlY2lmaWVzIHRoZSBzb3VyY2UNCmFkZHJlc3Mgb2Yg dHJhZmZpYyBmb3J3YXJkZWQgDQogIGZyb20gKG9yIHRoZSBkZXN0aW5hdGlvbiBhZGRyZXNz IG9mIHRyYWZmaWMgZm9yd2FyZGVkIHRvKSB0aGUNCmluaXRpYXRvciBvZiB0aGUgQ0hJTERf U0EgcGFpci4iDQogDQpJbiB0aGlzIGNhc2Ugd2hhdCB3aWxsIGJlIG15IFRTaT8NCklzIGl0 IHRoZSBsb2NhbCBhZGRyZXNzIGluIHRoZSByZW1vdGUgbmV0d29yaz8gT3IgaXMgaXQgd2ls ZCBjYXJkDQphZGRyZXNzPw0KIA0KVGhhbmtzIGFuZCBSZWdhcmRzDQpSYXZpIHByYXNhZA0K IA0KDQogDQoNCiANCg0KIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjDQpUaGlzIEVtYWlsIE1lc3NhZ2UgaXMg Zm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50KHMpIGFuZA0KTWF5 IGNvbnRhaW4gQ09ORklERU5USUFMIGFuZCBQUklWSUxFR0VEIGluZm9ybWF0aW9uLg0KTEcg U29mdCBJbmRpYSB3aWxsIG5vdCBiZSByZXNwb25pc2libGUgZm9yIGFueSB2aXJ1c2VzIG9y IGRlZmVjdHMgb3INCmFueSBmb3J3YXJkZWQgYXR0YWNoZW1lbnRzIGVtYW5hdGluZyBlaXRo ZXIgZnJvbSB3aXRoaW4NCkxHIFNvZnQgSW5kaWEgb3Igb3V0c2lkZS4gQW55IHVuYXV0aG9y aXNlZCByZXZpZXcgLCB1c2UsIGRpc2Nsb3N1cmUgb3INCmRpc3RyaWJ1dGlvbiBpcyBwcm9o aWJpdGVkLiBJZiB5b3UgYXJlIG5vdCBpbnRlbnRkZWQNCnJlY2lwaWVudCwgcGxlYXNlIGNv bnRhY3QgdGhlIHNlbmRlciBieSByZXBseSBlbWFpbCBhbmQgZGVzdHJveSBhbGwNCmNvcGll cyBvZiB0aGUgb3JpZ2luYWwgbWVzc2FnZS4NCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjDQpUaGlzIEVtYWlsIE1lc3NhZ2UgaXMgZm9yIHRoZSBzb2xlIHVzZSBvZiB0aGUg aW50ZW5kZWQgcmVjaXBpZW50KHMpIGFuZCBNYXkgY29udGFpbiBDT05GSURFTlRJQUwgYW5k IFBSSVZJTEVHRUQgaW5mb3JtYXRpb24uDQpMRyBTb2Z0IEluZGlhIHdpbGwgbm90IGJlIHJl c3BvbmlzaWJsZSBmb3IgYW55IHZpcnVzZXMgb3IgZGVmZWN0cyBvcg0KYW55IGZvcndhcmRl ZCBhdHRhY2hlbWVudHMgZW1hbmF0aW5nIGVpdGhlciBmcm9tIHdpdGhpbg0KTEcgU29mdCBJ bmRpYSBvciBvdXRzaWRlLiBBbnkgdW5hdXRob3Jpc2VkIHJldmlldyAsIHVzZSwgZGlzY2xv c3VyZSBvciBkaXN0cmlidXRpb24gaXMgcHJvaGliaXRlZC4gSWYgeW91IGFyZSBub3QgaW50 ZW50ZGVkDQpyZWNpcGllbnQsIHBsZWFzZSBjb250YWN0IHRoZSBzZW5kZXIgYnkgcmVwbHkg ZW1haWwgYW5kIGRlc3Ryb3kgYWxsDQpjb3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2Uu DQojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyM= ------_=_NextPart_001_01C57BEC.298D8DE6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89 InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJu OnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6c3QxPSJ1cm46c2No ZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzbWFydHRhZ3MiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PUNv bnRlbnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXMtYXNjaWkiPg0KPG1l dGEgbmFtZT1HZW5lcmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTEgKGZpbHRlcmVk IG1lZGl1bSkiPg0KPCEtLVtpZiAhbXNvXT4NCjxzdHlsZT4NCnZcOioge2JlaGF2aW9yOnVy bCgjZGVmYXVsdCNWTUwpO30NCm9cOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30N CndcOioge2JlaGF2aW9yOnVybCgjZGVmYXVsdCNWTUwpO30NCi5zaGFwZSB7YmVoYXZpb3I6 dXJsKCNkZWZhdWx0I1ZNTCk7fQ0KPC9zdHlsZT4NCjwhW2VuZGlmXS0tPjxvOlNtYXJ0VGFn VHlwZQ0KIG5hbWVzcGFjZXVyaT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6 c21hcnR0YWdzIiBuYW1lPSJTdGF0ZSIvPg0KPG86U21hcnRUYWdUeXBlIG5hbWVzcGFjZXVy aT0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6c21hcnR0YWdzIg0KIG5hbWU9 IkNpdHkiIGRvd25sb2FkdXJsPSJodHRwOi8vd3d3LjVpYW1hcy1taWNyb3NvZnQtY29tOm9m ZmljZTpzbWFydHRhZ3MiLz4NCjxvOlNtYXJ0VGFnVHlwZSBuYW1lc3BhY2V1cmk9InVybjpz Y2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyINCiBuYW1lPSJwbGFjZSIg ZG93bmxvYWR1cmw9Imh0dHA6Ly93d3cuNWlhbnRsYXZhbGFtcC5jb20vIi8+DQo8IS0tW2lm ICFtc29dPg0KPHN0eWxlPg0Kc3QxXDoqe2JlaGF2aW9yOnVybCgjZGVmYXVsdCNpZW9vdWkp IH0NCjwvc3R5bGU+DQo8IVtlbmRpZl0tLT4NCjxzdHlsZT4NCjwhLS0NCiAvKiBGb250IERl ZmluaXRpb25zICovDQogQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFu b3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICov DQogcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46 MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZv bnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxp bmsNCgl7Y29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXtjb2xvcjpwdXJwbGU7DQoJdGV4 dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1zb1BsYWluVGV4dCwgbGkuTXNvUGxhaW5U ZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTou MDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3 Ijt9DQpwcmUNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9u dC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNwYW4uRW1h aWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OkFy aWFsOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0 eWxlLXR5cGU6cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6QXJpYWw7DQoJY29sb3I6bmF2eTt9 DQpzcGFuLkVtYWlsU3R5bGUyMA0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsN Cglmb250LWZhbWlseTpBcmlhbDsNCgljb2xvcjpuYXZ5O30NCkBwYWdlIFNlY3Rpb24xDQoJ e3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjI1aW4gMS4waW4gMS4yNWlu O30NCmRpdi5TZWN0aW9uMQ0KCXtwYWdlOlNlY3Rpb24xO30NCi0tPg0KPC9zdHlsZT4NCg0K PC9oZWFkPg0KDQo8Ym9keSBsYW5nPUVOLVVTIGxpbms9Ymx1ZSB2bGluaz1wdXJwbGU+DQoN CjxkaXYgY2xhc3M9U2VjdGlvbjE+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXpl PTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4w cHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+SGksPG86cD48L286cD48L3NwYW4+ PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1u YXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZh bWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz5KdXN0IGNvcnJlY3QgbWUgaWYgSSBhbSB3cm9uZy48 bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZv bnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl Og0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPkkgdGhvdWdodCB0aGF0 IHRoZXJlIHdpbGwgYmUgdHdvIFRTaSBhbmQNClRTciYjODIxNztzLiBPbmUgd2l0aCBDUCBw YXlsb2FkIGFuZCBvbmUgZm9yIHRoZSBjaGlsZCBTQS48bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkg ZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5 OkFyaWFsO2NvbG9yOm5hdnknPkkgbWVhbiBzb21lIHRoaW5nIGxpa2UgdGhpczxvOnA+PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48Zm9udCBz aXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz5JS0VfQVVUSCA9PC9zcGFuPjwv Zm9udD4mbmJzcDsmbmJzcDsNCns8c3QxOnBsYWNlIHc6c3Q9Im9uIj48c3QxOkNpdHkgdzpz dD0ib24iPkhEUjwvc3QxOkNpdHk+LCA8c3QxOlN0YXRlIHc6c3Q9Im9uIj5TSzwvc3QxOlN0 YXRlPjwvc3QxOnBsYWNlPg0Ke0lEaSwgW0NFUlQsXSBbQ0VSVFJFUSxdICZuYnNwO1tJRHIs XSBBVVRILCA8bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0Pjxmb250 IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEw LjBwdCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpDUChDRkdfUkVRVUVTVCksIFRTaSwgVFNyIC8q IFRoaXMgVFNpIGFuZCBUU3IgYXJlIGZvciB0aGUgQ1AgcGF5bG9hZCAqLzxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48Zm9udCBzaXpl PTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQn PiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOw0KU0FpMiwgVFNpLCBUU3J9Jm5ic3A7IC8qIFRoaXMgVFNp IGFuZCBUU3IgYXJlIGZvciB0aGUgQ2hpbGQgU0EgcGF5bG9hZCAqLzxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWluVGV4dD48Zm9udCBzaXplPTIg ZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQnPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb1BsYWlu VGV4dD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz5VIG1lYW5zIHRvIHNheSB0aGF0ICZuYnNwOyZu YnNwO0lLRV9BVVRIJm5ic3A7Jm5ic3A7Jm5ic3A7IGlzDQpsaWtlIHRoaXMmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsgPGZvbnQgY29sb3I9bmF2eT48c3Bhbg0Kc3R5bGU9J2Nv bG9yOm5hdnknPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0Pjxmb250 IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6 MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPklLRV9BVVRIID08L3NwYW4+ PC9mb250PiZuYnNwOyZuYnNwOw0KezxzdDE6cGxhY2UgdzpzdD0ib24iPjxzdDE6Q2l0eSB3 OnN0PSJvbiI+SERSPC9zdDE6Q2l0eT4sIDxzdDE6U3RhdGUgdzpzdD0ib24iPlNLPC9zdDE6 U3RhdGU+PC9zdDE6cGxhY2U+DQp7SURpLCBbQ0VSVCxdIFtDRVJUUkVRLF0gJm5ic3A7W0lE cixdIEFVVEgsIDxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29QbGFpblRleHQ+PGZv bnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0K MTAuMHB0Jz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCkNQKENGR19SRVFVRVNUKSwgPG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvUGxhaW5UZXh0Pjxmb250IHNp emU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBw dCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpTQWkyLCBUU2ksIFRTcn0mbmJzcDsgLyogVGhpcyBU U2kgYW5kIFRTciBhcmUgZm9yIHRoZSBDaGlsZCBTQSBwYXlsb2FkICovPG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBj b2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtm b250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5h dnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFt aWx5OkFyaWFsO2NvbG9yOm5hdnknPlRoZSBUU2kmbmJzcDsgYW5kIFRTciByZWZlcnJlZCBD UCBwYXlsb2FkDQpiZWxvdyA8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWw+PGk+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48 c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6 bmF2eTtmb250LXN0eWxlOml0YWxpYyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQomIzgyMjA7Jm5ic3A7IEZvciBleGFtcGxlLCBtZXNzYWdlIGZyb20gaW5pdGlh dG9yIHRvIHJlc3BvbmRlcjo8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9pPjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxpPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJp YWw+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2Nv bG9yOm5hdnk7Zm9udC1zdHlsZTppdGFsaWMnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOw0KJm5ic3A7Q1AoQ0ZHX1JFUVVFU1QpPTxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L2k+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGk+PGZvbnQgc2l6ZT0yIGNv bG9yPW5hdnkgZmFjZT1BcmlhbD48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eTtmb250LXN0eWxlOml0YWxpYyc+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7DQombmJzcDtJTlRFUk5BTF9BRERSRVNTKDAuMC4wLjApPG86cD48 L286cD48L3NwYW4+PC9mb250PjwvaT48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48aT48 Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuDQpzdHlsZT0nZm9udC1z aXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5O2ZvbnQtc3R5bGU6aXRh bGljJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0lOVEVSTkFMX05FVE1BU0soMC4wLjAu MCk8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9pPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxpPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4NCnN0eWxl PSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnk7Zm9udC1z dHlsZTppdGFsaWMnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw Ow0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7SU5URVJOQUxfRE5TKDAuMC4wLjAp PG86cD48L286cD48L3NwYW4+PC9mb250PjwvaT48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48aT48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuDQpzdHlsZT0n Zm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5O2ZvbnQtc3R5 bGU6aXRhbGljJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCiZuYnNwO1RTaSA9ICgwLCAwLTY1NTM2 LDAuMC4wLjAtMjU1LjI1NS4yNTUuMjU1KTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L2k+ PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGk+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkg ZmFjZT1BcmlhbD48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 QXJpYWw7Y29sb3I6bmF2eTtmb250LXN0eWxlOml0YWxpYyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDtUU3IgPSAoMCwNCjAtNjU1MzYsMC4wLjAuMC0yNTUuMjU1LjI1NS4yNTUpJiM4MjIxOzxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L2k+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBz aXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQox MC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+YXJlIHRvIGJlIHNlbnQgd2l0 aCBTQSBwYXlsb2FkIGZvciBjaGlsZA0KU0EgY3JlYXRpb24uIFRoZXkgYXJlIG5vdCBwYXJ0 IG9mIENQKENGR19SRVFVRVNUKS4gQ1AgKENGR19SRVFVRVNUKSBpcyBsaWtlDQp0aGlzPG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxl PSdtYXJnaW4tbGVmdDouNWluJz48aT48Zm9udCBzaXplPTIgY29sb3I9bmF2eQ0KZmFjZT1B cmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtj b2xvcjpuYXZ5Ow0KZm9udC1zdHlsZTppdGFsaWMnPkNQKENGR19SRVFVRVNUKT08bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9pPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxpPjxm b250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4NCnN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnk7Zm9udC1zdHlsZTppdGFs aWMnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KJm5ic3A7SU5URVJOQUxfQUREUkVTUygw LjAuMC4wKTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L2k+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PGk+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3Bhbg0K c3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eTtm b250LXN0eWxlOml0YWxpYyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtJTlRFUk5BTF9O RVRNQVNLKDAuMC4wLjApPG86cD48L286cD48L3NwYW4+PC9mb250PjwvaT48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48aT48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFs PjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xv cjpuYXZ5O2ZvbnQtc3R5bGU6aXRhbGljJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsNCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0lOVEVSTkFM X0ROUygwLjAuMC4wKTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L2k+PC9wPg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5h dnknPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+S2lu ZGx5IGVtYWlsIHdoZXRoZXIgbXkgdW5kZXJzdGFuZGluZyBpcw0KY29ycmVjdC48bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6 ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAu MHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29s b3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9u dC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+VGhhbmtzIGFuZCByZWdhcmRzPG86cD48L286 cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzdDE6cGxhY2Ug dzpzdD0ib24iPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4NCiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz5S YXZpPC9zcGFuPjwvZm9udD48L3N0MTpwbGFjZT48Zm9udA0Kc2l6ZT0yIGNvbG9yPW5hdnkg ZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpB cmlhbDsNCmNvbG9yOm5hdnknPiBQcmFzYWQ8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1B cmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFs O2NvbG9yOm5hdnknPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxz cGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6 bmF2eSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9u dC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxkaXY+DQoNCjxkaXYgY2xhc3M9TXNv Tm9ybWFsIGFsaWduPWNlbnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxmb250IHNp emU9Mw0KZmFjZT0iVGltZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEy LjBwdCc+DQoNCjxociBzaXplPTIgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlciB0YWJpbmRl eD0tMT4NCg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxi Pjxmb250IHNpemU9MiBmYWNlPVRhaG9tYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBw dDsNCmZvbnQtZmFtaWx5OlRhaG9tYTtmb250LXdlaWdodDpib2xkJz5Gcm9tOjwvc3Bhbj48 L2ZvbnQ+PC9iPjxmb250IHNpemU9Mg0KZmFjZT1UYWhvbWE+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6VGFob21hJz4gU3Jpbml2YXMgVi4NCkNoYWtyYXZh cnR5IDxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xkJz5TZW50Ojwvc3Bh bj48L2I+IFR1ZXNkYXksIEp1bmUgMjgsIDIwMDUgNjoyNA0KUE08YnI+DQo8Yj48c3BhbiBz dHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+VG86PC9zcGFuPjwvYj4gUmF2aSBQcmFzYWQ8YnI+ DQo8Yj48c3BhbiBzdHlsZT0nZm9udC13ZWlnaHQ6Ym9sZCc+U3ViamVjdDo8L3NwYW4+PC9i PiBSRTogW0lwc2VjXSBDb25maWd1cmF0aW9uDQpwYXlsb2FkIGFuZCB0cmFmZmljIHNlbGVj dG9yczwvc3Bhbj48L2ZvbnQ+PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21hbiI+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9m b250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBjb2xvcj1uYXZ5 IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtmb250LWZhbWls eTpBcmlhbDtjb2xvcjpuYXZ5Jz5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1Bcmlh bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2Nv bG9yOm5hdnknPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2 eSc+UGxlYXNlIHJlZmVyIHRvIHRoZSBzZWN0aW9uIDIuMTkgaW4gdGhlDQpkcmFmdC1pZXRm LWlwc2VjLWlrZXYyLTE3LnR4dC48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9y Om5hdnknPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48aT48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFu DQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5 O2ZvbnQtc3R5bGU6aXRhbGljJz5Gb3INCmV4YW1wbGUsIG1lc3NhZ2UgZnJvbSBpbml0aWF0 b3IgdG8gcmVzcG9uZGVyOjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L2k+PC9wPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PGk+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1Bcmlh bD48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29s b3I6bmF2eTtmb250LXN0eWxlOml0YWxpYyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7DQpDUChDRkdfUkVRVUVTVCk9PG86cD48L286cD48L3NwYW4+PC9mb250PjwvaT48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48aT48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNl PUFyaWFsPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlh bDtjb2xvcjpuYXZ5O2ZvbnQtc3R5bGU6aXRhbGljJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsNCklOVEVSTkFMX0FERFJFU1MoMC4wLjAuMCk8bzpwPjwv bzpwPjwvc3Bhbj48L2ZvbnQ+PC9pPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxpPjxm b250IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4NCnN0eWxlPSdmb250LXNp emU6MTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnk7Zm9udC1zdHlsZTppdGFs aWMnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KSU5URVJO QUxfTkVUTUFTSygwLjAuMC4wKTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L2k+PC9wPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGk+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1B cmlhbD48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7 Y29sb3I6bmF2eTtmb250LXN0eWxlOml0YWxpYyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpJTlRFUk5BTF9ETlMoMC4wLjAuMCk8bzpwPjwvbzpwPjwv c3Bhbj48L2ZvbnQ+PC9pPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxpPjxmb250IHNp emU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAu MHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnk7Zm9udC1zdHlsZTppdGFsaWMnPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KVFNpID0gKDAsIDAtNjU1MzYsMC4wLjAu MC0yNTUuMjU1LjI1NS4yNTUpPG86cD48L286cD48L3NwYW4+PC9mb250PjwvaT48L3A+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48aT48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFy aWFsPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtj b2xvcjpuYXZ5O2ZvbnQtc3R5bGU6aXRhbGljJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsNClRTciA9ICgwLCAwLTY1NTM2LDAuMC4wLjAtMjU1LjI1NS4yNTUuMjU1KTxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L2k+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZv bnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl Og0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXpl PTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMC4w cHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+VGhlIGluaXRpYXRvciBzcGVjaWZp ZXMgdGhlIHBvc3NpYmxlIHJhbmdlDQpvZiBhZGRyZXNzZXMuIFRoZSByZXNwb25kZXIgd291 bGQgc2V0IGEgcGFydGljdWxhciAoIG9yIG1heSBiZSByYW5nZT8pIHRvIHRoZQ0KVHNpIHZh bHVlIGluIGl0cyByZXNwb25zZS4gTG9vayBhdCB0aGUgcmVzcG9uc2UsPG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBj b2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEwLjBwdDtm b250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGk+PGZvbnQgc2l6ZT0yIGNvbG9y PW5hdnkgZmFjZT1BcmlhbD48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1m YW1pbHk6QXJpYWw7Y29sb3I6bmF2eTtmb250LXN0eWxlOml0YWxpYyc+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpDUChDRkdfUkVQTFkpPTxvOnA+PC9vOnA+PC9zcGFuPjwv Zm9udD48L2k+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGk+PGZvbnQgc2l6ZT0yIGNv bG9yPW5hdnkgZmFjZT1BcmlhbD48c3Bhbg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eTtmb250LXN0eWxlOml0YWxpYyc+Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7DQpJTlRFUk5BTF9BRERSRVNTKDE5 Mi4wLjIuMjAyKTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L2k+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PGk+PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3Bh bg0Kc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2 eTtmb250LXN0eWxlOml0YWxpYyc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7DQpJTlRFUk5BTF9ORVRNQVNLKDI1NS4yNTUuMjU1LjApPG86cD48L286cD48 L3NwYW4+PC9mb250PjwvaT48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48aT48Zm9udCBz aXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuDQpzdHlsZT0nZm9udC1zaXplOjEw LjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5O2ZvbnQtc3R5bGU6aXRhbGljJz4m bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNCklOVEVSTkFMX1NV Qk5FVCgxOTIuMC4yLjAvMjU1LjI1NS4yNTUuMCk8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9pPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxpPjxmb250IHNpemU9MiBjb2xvcj1u YXZ5IGZhY2U9QXJpYWw+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5OkFyaWFsO2NvbG9yOm5hdnk7Zm9udC1zdHlsZTppdGFsaWMnPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOw0KVFNpID0gKDAsIDAtNjU1MzYsMTkyLjAuMi4yMDItMTkyLjAu Mi4yMDIpPG86cD48L286cD48L3NwYW4+PC9mb250PjwvaT48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48aT48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuDQpz dHlsZT0nZm9udC1zaXplOjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5O2Zv bnQtc3R5bGU6aXRhbGljJz4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsNClRTciA9 ICgwLCAwLTY1NTM2LDE5Mi4wLjIuMC0xOTIuMC4yLjI1NSk8bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9pPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxpPjxmb250IHNpemU9MiBj b2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4NCnN0eWxlPSdmb250LXNpemU6MTAuMHB0O2Zv bnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnk7Zm9udC1zdHlsZTppdGFsaWMnPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L2k+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PGZvbnQgc2l6ZT0yIGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOg0KMTAuMHB0O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPlJlZ2FyZHMsPG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250 IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToN CjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz5TcmluaXZhcyBDaGFrcmF2 YXJ0eTxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48Zm9udCBzaXplPTIgY29sb3I9bmF2eSBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6DQoxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWw7Y29sb3I6bmF2eSc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250 IHNpemU9MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToN CjEwLjBwdDtmb250LWZhbWlseTpBcmlhbDtjb2xvcjpuYXZ5Jz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0y IGNvbG9yPW5hdnkgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOg0KMTAuMHB0 O2ZvbnQtZmFtaWx5OkFyaWFsO2NvbG9yOm5hdnknPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvZm9udD48L3A+DQoNCjxkaXY+DQoNCjxkaXYgY2xhc3M9TXNvTm9ybWFsIGFsaWduPWNl bnRlciBzdHlsZT0ndGV4dC1hbGlnbjpjZW50ZXInPjxmb250IHNpemU9Mw0KZmFjZT0iVGlt ZXMgTmV3IFJvbWFuIj48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdCc+DQoNCjxociBz aXplPTIgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlciB0YWJpbmRleD0tMT4NCg0KPC9zcGFu PjwvZm9udD48L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxmb250IHNpemU9MiBm YWNlPVRhaG9tYT48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5 OlRhaG9tYTtmb250LXdlaWdodDpib2xkJz5Gcm9tOjwvc3Bhbj48L2ZvbnQ+PC9iPjxmb250 IHNpemU9Mg0KZmFjZT1UYWhvbWE+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9u dC1mYW1pbHk6VGFob21hJz4NCmlwc2VjLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzppcHNl Yy1ib3VuY2VzQGlldGYub3JnXSA8Yj48c3Bhbg0Kc3R5bGU9J2ZvbnQtd2VpZ2h0OmJvbGQn Pk9uIEJlaGFsZiBPZiA8L3NwYW4+PC9iPlJhdmkgUHJhc2FkPGJyPg0KPGI+PHNwYW4gc3R5 bGU9J2ZvbnQtd2VpZ2h0OmJvbGQnPlNlbnQ6PC9zcGFuPjwvYj4gVHVlc2RheSwgSnVuZSAy OCwgMjAwNSAzOjUyDQpQTTxicj4NCjxiPjxzcGFuIHN0eWxlPSdmb250LXdlaWdodDpib2xk Jz5Ubzo8L3NwYW4+PC9iPiBpcHNlY0BpZXRmLm9yZzxicj4NCjxiPjxzcGFuIHN0eWxlPSdm b250LXdlaWdodDpib2xkJz5TdWJqZWN0Ojwvc3Bhbj48L2I+IFtJcHNlY10gQ29uZmlndXJh dGlvbg0KcGF5bG9hZCBhbmQgdHJhZmZpYyBzZWxlY3RvcnM8L3NwYW4+PC9mb250PjxvOnA+ PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9 MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4w cHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz5IaSw8bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+QXNz dW1lIHRoZSBzY2VuYXJpbyB3aGVyZSBhIHJlbW90ZSBob3N0IGNvbm5lY3RzIHRvIGludGVy bmV0DQp0aHJvdWdoIGhpcyBjb3Jwb3JhdGUgZ2F0ZXdheS48bzpwPjwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJp YWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+ VG8gZG8gdGhpcyBhIENQIHBheWxvYWQgKENGR19SRVFVRVNUIHdpdGggPC9zcGFuPjwvZm9u dD5JTlRFUk5BTF9BRERSRVNTDQphdHRyaWJ1dGUgb2YgdHlwZSBJUHY0KSBpcyBpbmNsdWRl ZCBhcyBwYXJ0IG9mIENSRUFURV9DSElMRF9TQSBtZXNzYWdlLjxvOnA+PC9vOnA+PC9wPg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0zIGZhY2U9IlRpbWVzIE5ldyBSb21h biI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToNCjEyLjBwdCc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MyBm YWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4wcHQn PlRoZSBkcmFmdCBzYXlzIHRoYXQgPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0K PHByZT48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0Jz4mIzgyMjA7VGhlIENQIHBheWxvYWQgTVVTVCBiZSBpbnNlcnRlZCBi ZWZvcmUgdGhlIFNBIHBheWxvYWQuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxw cmU+PGZvbnQNCnNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQt c2l6ZToxMC4wcHQnPiBJbiB2YXJpYXRpb25zIG9mIHRoZSBwcm90b2NvbCB3aGVyZSB0aGVy ZSBhcmUgbXVsdGlwbGUgSUtFX0FVVEggZXhjaGFuZ2VzLCB0aGUgQ1AgcGF5bG9hZHMgPG86 cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBmYWNlPSJD b3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZuYnNwOyZuYnNw O01VU1QgYmUgaW5zZXJ0ZWQgaW4gdGhlIG1lc3NhZ2VzIGNvbnRhaW5pbmcgdGhlIFNBIHBh eWxvYWRzLiYjODIyMTs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9u dA0Kc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQN CnNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQnPlRoZXJlIGlzIG5vIGlzc3VlIGluIGJ1aWxkaW5nIFNBIHBheWxvYWQuIEkgaGF2ZSBk b3VidCBvbiBob3cgdG8gYnVpbGQgVHJhZmZpYyBzZWxlY3RvcnMgVFNpPyA8bzpwPjwvbzpw Pjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGZhY2U9IkNvdXJpZXIg TmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+VGhlIGRyYWZ0KGRyYWZ0LWll dGYtaXBzZWMtaWtldjItMTcudHh0IHNlYyAyLjkpIHNheXMgdGhhdDxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgZmFjZT0iQ291cmllciBOZXci PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mIzgyMjA7VGhlIGZpcnN0IG9mIHRo ZSB0d28gVFMgcGF5bG9hZHMgaXMga25vd24gYXMgVFNpIChUcmFmZmljIFNlbGVjdG9yLSBp bml0aWF0b3IpLiZuYnNwOyBUaGUgc2Vjb25kIGlzIDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9u dD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mbmJzcDsmbmJzcDtrbm93biBhcyBUU3IgKFRyYWZm aWMgU2VsZWN0b3ItcmVzcG9uZGVyKS4gVFNpIHNwZWNpZmllcyB0aGUgc291cmNlIGFkZHJl c3Mgb2YgdHJhZmZpYyBmb3J3YXJkZWQgPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJl PjxwcmU+PGZvbnQNCnNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQnPiZuYnNwOyZuYnNwO2Zyb20gKG9yIHRoZSBkZXN0aW5hdGlvbiBh ZGRyZXNzIG9mIHRyYWZmaWMgZm9yd2FyZGVkIHRvKSB0aGUgaW5pdGlhdG9yIG9mIHRoZSBD SElMRF9TQSBwYWlyLiYjODIyMTs8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHBy ZT48Zm9udA0Kc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1z aXplOjEwLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+ PGZvbnQNCnNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQnPkluIHRoaXMgY2FzZSB3aGF0IHdpbGwgYmUgbXkgVFNpPzxvOnA+PC9vOnA+ PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgZmFjZT0iQ291cmllciBO ZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz5JcyBpdCB0aGUgbG9jYWwgYWRk cmVzcyBpbiB0aGUgcmVtb3RlIG5ldHdvcms/IE9yIGlzIGl0IHdpbGQgY2FyZCBhZGRyZXNz PzxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgZmFj ZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGZhY2U9 IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+VGhhbmtzIGFu ZCBSZWdhcmRzPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PHN0MTpwbGFj ZQ0KdzpzdD0ib24iPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPlJhdmk8L3NwYW4+PC9mb250Pjwvc3QxOnBsYWNlPiBw cmFzYWQ8bzpwPjwvbzpwPjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBmYWNlPSJDb3VyaWVy IE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvZm9udD48L3ByZT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9 MyBmYWNlPSJUaW1lcyBOZXcgUm9tYW4iPjxzcGFuIHN0eWxlPSdmb250LXNpemU6DQoxMi4w cHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48 L2ZvbnQ+PC9wPg0KDQo8L2Rpdj4NCg0KPC9ib2R5Pg0KDQo8L2h0bWw+DQo8cHJlPiMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIw0KVGhpcyBFbWFpbCBNZXNzYWdlIGlzIGZvciB0aGUgc29sZSB1c2Ugb2Yg dGhlIGludGVuZGVkIHJlY2lwaWVudChzKSBhbmQgTWF5IGNvbnRhaW4gQ09ORklERU5USUFM IGFuZCBQUklWSUxFR0VEIGluZm9ybWF0aW9uLg0KTEcgU29mdCBJbmRpYSB3aWxsIG5vdCBi ZSByZXNwb25pc2libGUgZm9yIGFueSB2aXJ1c2VzIG9yIGRlZmVjdHMgb3INCmFueSBmb3J3 YXJkZWQgYXR0YWNoZW1lbnRzIGVtYW5hdGluZyBlaXRoZXIgZnJvbSB3aXRoaW4NCkxHIFNv ZnQgSW5kaWEgb3Igb3V0c2lkZS4gQW55IHVuYXV0aG9yaXNlZCByZXZpZXcgLCB1c2UsIGRp c2Nsb3N1cmUgb3IgZGlzdHJpYnV0aW9uIGlzIHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90 IGludGVudGRlZA0KcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5IHJl cGx5IGVtYWlsIGFuZCBkZXN0cm95IGFsbA0KY29waWVzIG9mIHRoZSBvcmlnaW5hbCBtZXNz YWdlLg0KIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjPC9wcmU+PHByZT4jIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMNClRoaXMg RW1haWwgTWVzc2FnZSBpcyBmb3IgdGhlIHNvbGUgdXNlIG9mIHRoZSBpbnRlbmRlZCByZWNp cGllbnQocykgYW5kIE1heSBjb250YWluIENPTkZJREVOVElBTCBhbmQgUFJJVklMRUdFRCBp bmZvcm1hdGlvbi4NCkxHIFNvZnQgSW5kaWEgd2lsbCBub3QgYmUgcmVzcG9uaXNpYmxlIGZv ciBhbnkgdmlydXNlcyBvciBkZWZlY3RzIG9yDQphbnkgZm9yd2FyZGVkIGF0dGFjaGVtZW50 cyBlbWFuYXRpbmcgZWl0aGVyIGZyb20gd2l0aGluDQpMRyBTb2Z0IEluZGlhIG9yIG91dHNp ZGUuIEFueSB1bmF1dGhvcmlzZWQgcmV2aWV3ICwgdXNlLCBkaXNjbG9zdXJlIG9yIGRpc3Ry aWJ1dGlvbiBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgYXJlIG5vdCBpbnRlbnRkZWQNCnJlY2lw aWVudCwgcGxlYXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXBseSBlbWFpbCBhbmQgZGVz dHJveSBhbGwNCmNvcGllcyBvZiB0aGUgb3JpZ2luYWwgbWVzc2FnZS4NCiMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIzwvcHJlPg== ------_=_NextPart_001_01C57BEC.298D8DE6-- --===============1604815119== 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 --===============1604815119==-- From ipsec-bounces@ietf.org Tue Jun 28 10:13:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnGqI-0004jj-Rx; Tue, 28 Jun 2005 10:13:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnGqG-0004ja-2u for ipsec@megatron.ietf.org; Tue, 28 Jun 2005 10:13:36 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA12288 for ; Tue, 28 Jun 2005 10:13:34 -0400 (EDT) Received: from michael.checkpoint.com ([194.29.32.68]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnHFc-0007ew-0D for ipsec@ietf.org; Tue, 28 Jun 2005 10:39:49 -0400 Received: from [194.29.46.218] (localhost [127.0.0.1]) by michael.checkpoint.com (8.12.10+Sun/8.12.10) with ESMTP id j5SEDOnP003154; Tue, 28 Jun 2005 17:13:24 +0300 (IDT) In-Reply-To: References: Mime-Version: 1.0 (Apple Message framework v622) Content-Type: text/plain; charset=WINDOWS-1252; format=flowed Message-Id: Content-Transfer-Encoding: quoted-printable From: Yoav Nir Subject: Re: [Ipsec] Configuration payload and traffic selectors Date: Tue, 28 Jun 2005 17:13:23 +0300 To: "Ravi Prasad" X-Mailer: Apple Mail (2.622) X-Spam-Score: 0.0 (/) X-Scan-Signature: 7e439b86d3292ef5adf93b694a43a576 Content-Transfer-Encoding: quoted-printable Cc: ipsec@ietf.org, "Srinivas V. Chakravarty" X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: 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 could be wrong, but I think there's just one TSi payload, and one TSr=20= payload. On Jun 28, 2005, at 5:17 PM, Ravi Prasad wrote: > > Hi, > Just correct me if I am wrong. > I thought that there will be two TSi and TSr=92s. One with CP payload=20= > and one for the child SA. > I mean some thing like this > IKE_AUTH =3D=A0=A0 {HDR, SK {IDi, [CERT,] [CERTREQ,] =A0[IDr,] AUTH, > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 CP(CFG_REQUEST), TSi, TSr /* This = TSi and TSr are for the=20 > CP payload */ > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 SAi2, TSi, TSr}=A0 /* This TSi = and TSr are for the Child SA=20 > payload */ > =A0 > U means to say that =A0=A0IKE_AUTH=A0=A0=A0 is like this=A0=A0=A0=A0=A0 = =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 > IKE_AUTH =3D=A0=A0 {HDR, SK {IDi, [CERT,] [CERTREQ,] =A0[IDr,] AUTH, > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 CP(CFG_REQUEST), > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 SAi2, TSi, TSr}=A0 /* This TSi = and TSr are for the Child SA=20 > payload */ > =A0 > The TSi=A0 and TSr referred CP payload below > =A0=A0=A0=A0=A0=A0 =93=A0 For example, message from initiator to = responder: > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0CP(CFG_REQUEST)=3D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0INTERNAL_ADDRESS(0.0.0.0) > =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0INTER= NAL_NETMASK(0.0.0.0) > =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0INTERNAL= _DNS(0.0.0.0) > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0TSi =3D (0, = 0-65536,0.0.0.0-255.255.255.255) > =A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0TSr =3D (0, = 0-65536,0.0.0.0-255.255.255.255)=94 > =A0 > are to be sent with SA payload for child SA creation. They are not=20 > part of CP(CFG_REQUEST). CP (CFG_REQUEST) is like this > CP(CFG_REQUEST)=3D > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 = =A0INTERNAL_ADDRESS(0.0.0.0) > =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0INTER= NAL_NETMASK(0.0.0.0) > =A0=A0=A0=A0=A0=A0=A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0INTERNAL= _DNS(0.0.0.0) > =A0 > Kindly email whether my understanding is correct. > =A0 > Thanks and regards > Ravi Prasad > =A0 > =A0 > =A0 > =A0 > > From: Srinivas V. Chakravarty > Sent: Tuesday, June 28, 2005 6:24 PM > To: Ravi Prasad > Subject: RE: [Ipsec] Configuration payload and traffic selectors > =A0 > Hi, > =A0 > Please refer to the section 2.19 in the draft-ietf-ipsec-ikev2-17.txt. > =A0 > For example, message from initiator to responder: > =A0=A0=A0=A0=A0 CP(CFG_REQUEST)=3D > =A0=A0=A0=A0=A0=A0=A0 INTERNAL_ADDRESS(0.0.0.0) > =A0=A0=A0=A0=A0=A0=A0 INTERNAL_NETMASK(0.0.0.0) > =A0=A0=A0=A0=A0=A0=A0 INTERNAL_DNS(0.0.0.0) > =A0=A0=A0=A0=A0 TSi =3D (0, 0-65536,0.0.0.0-255.255.255.255) > =A0=A0=A0=A0=A0 TSr =3D (0, 0-65536,0.0.0.0-255.255.255.255) > =A0 > The initiator specifies the possible range of addresses. The responder=20= > would set a particular ( or may be range?) to the Tsi value in its=20 > response. Look at the response, > =A0 > =A0=A0=A0=A0=A0 CP(CFG_REPLY)=3D > =A0=A0=A0=A0=A0=A0=A0 INTERNAL_ADDRESS(192.0.2.202) > =A0=A0=A0=A0=A0=A0=A0 INTERNAL_NETMASK(255.255.255.0) > =A0=A0=A0=A0=A0=A0=A0 INTERNAL_SUBNET(192.0.2.0/255.255.255.0) > =A0=A0=A0=A0=A0 TSi =3D (0, 0-65536,192.0.2.202-192.0.2.202) > =A0=A0=A0=A0=A0 TSr =3D (0, 0-65536,192.0.2.0-192.0.2.255) > =A0 > Regards, > Srinivas Chakravarty > =A0 > =A0 > =A0 > > From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf=20= > Of Ravi Prasad > Sent: Tuesday, June 28, 2005 3:52 PM > To: ipsec@ietf.org > Subject: [Ipsec] Configuration payload and traffic selectors > =A0 > Hi, > Assume the scenario where a remote host connects to internet through=20= > his corporate gateway. > To do this a CP payload (CFG_REQUEST with INTERNAL_ADDRESS attribute=20= > of type IPv4) is included as part of CREATE_CHILD_SA message. > =A0 > The draft says that > =93The CP payload MUST be inserted before the SA payload. > In variations of the protocol where there are multiple IKE_AUTH=20 > exchanges, the CP payloads > =A0=A0MUST be inserted in the messages containing the SA payloads.=94 > =A0 > There is no issue in building SA payload. I have doubt on how to build=20= > Traffic selectors TSi? > The draft(draft-ietf-ipsec-ikev2-17.txt sec 2.9) says that > =93The first of the two TS payloads is known as TSi (Traffic Selector-=20= > initiator).=A0 The second is > =A0=A0known as TSr (Traffic Selector-responder). TSi specifies the = source=20 > address of traffic forwarded > =A0=A0from (or the destination address of traffic forwarded to) the=20 > initiator of the CHILD_SA pair.=94 > =A0 > In this case what will be my TSi? > Is it the local address in the remote network? Or is it wild card=20 > address? > =A0 > Thanks and Regards > Ravi prasad > =A0 > =A0 > =A0 > ##################################################################### > This Email Message is for the sole use of the intended recipient(s)=20 > and May contain CONFIDENTIAL and PRIVILEGED information. > LG Soft India will not be responisible for any viruses or defects or > any forwarded attachements emanating either from within > LG Soft India or outside. Any unauthorised review , use, disclosure or=20= > distribution is prohibited. If you are not intentded > recipient, please contact the sender by reply email and destroy all > copies of the original message. > ##################################################################### > ##################################################################### > This Email Message is for the sole use of the intended recipient(s)=20 > and May contain CONFIDENTIAL and PRIVILEGED information. > LG Soft India will not be responisible for any viruses or defects or > any forwarded attachements emanating either from within > LG Soft India or outside. Any unauthorised review , use, disclosure or=20= > distribution is prohibited. If you are not intentded > recipient, please contact the sender by reply email and destroy all > copies of the original message. > #####################################################################= _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 28 14:09:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnKWa-0001Th-9R; Tue, 28 Jun 2005 14:09:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnKWY-0001Tc-Gb for ipsec@megatron.ietf.org; Tue, 28 Jun 2005 14:09:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA06645 for ; Tue, 28 Jun 2005 14:09:26 -0400 (EDT) Received: from pike.sandelman.ca ([205.150.200.164]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnKvu-0004AH-3Z for ipsec@ietf.org; Tue, 28 Jun 2005 14:35:43 -0400 Received: from sandelman.ottawa.on.ca (unknown [IPv6:2002:c08b:2e21:2:20d:60ff:fe77:9739]) by pike.sandelman.ca (Postfix) with ESMTP id F1A7760B48; Tue, 28 Jun 2005 14:09:00 -0400 (EDT) Received: from marajade.sandelman.ottawa.on.ca (marajade [127.0.0.1]) by sandelman.ottawa.on.ca (Postfix) with ESMTP id 87074E9949; Tue, 28 Jun 2005 14:09:00 -0400 (EDT) To: Paul Hoffman Subject: Re: [Ipsec] SPI values for messages outside of an IKE_SA In-Reply-To: Message from Paul Hoffman of "Mon, 27 Jun 2005 20:36:04 PDT." References: X-Mailer: MH-E 7.82; nmh 1.1; XEmacs 21.4 (patch 17) Date: Tue, 28 Jun 2005 14:09:00 -0400 Message-ID: <8369.1119982140@marajade.sandelman.ottawa.on.ca> From: Michael Richardson X-Spam-Score: 0.0 (/) X-Scan-Signature: ea4ac80f790299f943f0a53be7e1a21a 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 -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Paul" == Paul Hoffman writes: Paul> A strict interpretation of the specification would require Paul> the sender to invent garbage values for the SPI fields. Paul> However, we think this was not the intention, and using zero Paul> values is acceptable. Paul> Can we come to consensus on what to use? If you feel it Paul> doesn't matter, feel free to say that, but if you feel that a Paul> particular value is important, let's try to find it. Set to zero, mandate not checking. - -- ] Michael Richardson Xelerance Corporation, Ottawa, ON | firewalls [ ] mcr @ xelerance.com Now doing IPsec training, see |net architect[ ] http://www.sandelman.ca/mcr/ www.xelerance.com/training/ |device driver[ ] I'm a dad: http://www.sandelman.ca/lrmr/ [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux) Comment: Finger me for keys iQCVAwUBQsGSO4qHRg3pndX9AQE51gP9Fah4B/syDeUFF7loTF/WvW/fFOxLN/gA ggYiDagwtNZ1Op5AOr725Zh2cLdb57woXfkNbs8YzoF0/3QdYaqmlpLGNBDhPB+6 cqVvRTp4lsLbcYnJmnZ292OFY15DPVfBpYT7CBT+lQCn3Af0qr64IMS6tQeOhJa/ /0KIfTLaMgU= =wZKU -----END PGP SIGNATURE----- _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 28 21:09:11 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnR4h-00039F-S3; Tue, 28 Jun 2005 21:09:11 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnR4g-00039A-JW for ipsec@megatron.ietf.org; Tue, 28 Jun 2005 21:09:10 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA18945 for ; Tue, 28 Jun 2005 21:09:08 -0400 (EDT) Received: from smtp106.sbc.mail.mud.yahoo.com ([68.142.198.205]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DnRU6-0003pj-VM for ipsec@ietf.org; Tue, 28 Jun 2005 21:35:29 -0400 Received: (qmail 51146 invoked from network); 29 Jun 2005 01:08:58 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.58.137 with login) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 29 Jun 2005 01:08:58 -0000 Message-ID: <006901c57c47$2071fa70$6e01a8c0@adithya> From: "Mohan Parthasarathy" To: "IPsec WG" , "Paul Hoffman" References: Subject: Re: [Ipsec] INVALID_IKE_SPI Date: Tue, 28 Jun 2005 18:08:54 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: 52f7a77164458f8c7b36b66787c853da 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 In section 2.21, If a node receives a message on UDP port 500 or 4500 outside the context of an IKE_SA known to it (and not a request to start one), it may be the result of a recent crash of the node. If the message is marked as a response, the node MAY audit the suspicious event but MUST NOT respond. If the message is marked as a request, the node MAY audit the suspicious event and MAY send a response. If a response is sent, the response MUST be sent to the IP address and port from whence it came with the same IKE SPIs and the Message ID copied. The response MUST NOT be cryptographically protected and MUST contain a Notify payload indicating INVALID_IKE_SPI. This says, that the IKE header has the SPIs just copied back. You also have to copy back the "Initiator" flag so that the receiver of the notification can locate the SA appropriately. -mohan > The current version of the clarifications document says: > > 6.11 INVALID_IKE_SPI > > Section 3.10.1 says that the INVALID_IKE_SPI notification "indicates > an IKE message was received with an unrecognized destination SPI. > This usually indicates that the recipient has rebooted and forgotten > the existence of an IKE_SA." > > The text does not say whether the SPI value should be included in the > notification. However, it is clear that the notification will be > useful to the recipient only if it can find the IKE_SA somehow, so > the SPI should be included. > > This still leaves two questions open: which SPI(s) should be > included, and how it (or they) should be sent. For the first > question, the alternatives are the unrecognized destination SPI, the > source SPI (which presumably would be more useful for the recipient), > or both. For the second question, the SPI(s) could be placed in the > SPI field(s) in the IKE header, the SPI field in the Notify payload, > or the Notification Data field. > > In the case of another related notification, INVALID_SPI, the > situation is clearer: there is only a single SPI, and the text > explicitly says that the SPI is sent as Notification Data (since the > notification is not about an existing SA, the SPI field in the Notify > payload is not used; and obviously the value cannot be placed in the > IKE header). > > Since the INVALID_IKE_SPI notification is sent outside of an IKE_SA, > and it is not about an existing SA, it seems that using Notification > Data would be the logical choice. However, this issue needs more > discussion and we do not yet propose any solution in this document. > > Do people agree with the conclusion (puting the SPI in the > Notification Data)? And which SPI shoul be included? > > --Paul Hoffman, Director > --VPN Consortium > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Tue Jun 28 21:19:58 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnRF8-0006MB-J3; Tue, 28 Jun 2005 21:19:58 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnRF7-0006M6-De for ipsec@megatron.ietf.org; Tue, 28 Jun 2005 21:19:57 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA19745 for ; Tue, 28 Jun 2005 21:19:55 -0400 (EDT) Received: from smtp106.sbc.mail.mud.yahoo.com ([68.142.198.205]) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1DnReZ-0004Rc-29 for ipsec@ietf.org; Tue, 28 Jun 2005 21:46:16 -0400 Received: (qmail 62949 invoked from network); 29 Jun 2005 01:19:47 -0000 Received: from unknown (HELO adithya) (mohanp@sbcglobal.net@64.172.58.137 with login) by smtp106.sbc.mail.mud.yahoo.com with SMTP; 29 Jun 2005 01:19:46 -0000 Message-ID: <007101c57c48$a2cdc110$6e01a8c0@adithya> From: "Mohan Parthasarathy" To: "IPsec WG" , "Paul Hoffman" References: Subject: Re: [Ipsec] SPI values for messages outside of an IKE_SA Date: Tue, 28 Jun 2005 18:19:45 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1437 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441 X-Spam-Score: 0.1 (/) X-Scan-Signature: e1e48a527f609d1be2bc8d8a70eb76cb 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 > The current draft of the clarifications document says: > > 6.9 SPI values for messages outside of an IKE_SA > > The IKEv2 specification does not say what SPI values should be used > in the IKE header for the small number of notifications that are > allowed to be sent outside of an IKE_SA. Note that such > notifications are explicitly *not* Informational exchanges; Section > 1.5 makes it clear that these are one-way messages that must not be > responded to. > > There are two cases when such a one-way notification can be sent: > INVALID_IKE_SPI and INVALID_SPI. In both cases, there are no IKE SPI > values that would be meaningful to the recipient of such a > notification. > Why is not meaningful to the recepient of such a notification ? At least for INVALID_IKE_SPI, return what you received. The other end sent it because it still has "state". To clean up the state, returning what you received might be useful. For INVALID_SPI, just use zeroes for the IKE SPI fields. -mohan > A strict interpretation of the specification would require the sender > to invent garbage values for the SPI fields. However, we think this > was not the intention, and using zero values is acceptable. > > Can we come to consensus on what to use? If you feel it doesn't > matter, feel free to say that, but if you feel that a particular > value is important, let's try to find it. > > --Paul Hoffman, Director > --VPN Consortium > > _______________________________________________ > Ipsec mailing list > Ipsec@ietf.org > https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 29 04:10:50 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnXek-0005W8-Kn; Wed, 29 Jun 2005 04:10:50 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnXei-0005TD-Jd for ipsec@megatron.ietf.org; Wed, 29 Jun 2005 04:10:48 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21006 for ; Wed, 29 Jun 2005 04:10:46 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext02.nokia.com ([131.228.20.94]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnY4D-0000xy-Hi for ipsec@ietf.org; Wed, 29 Jun 2005 04:37:11 -0400 Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-ext02.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j5T8AeYq001056; Wed, 29 Jun 2005 11:10:40 +0300 Received: from esebh101.NOE.Nokia.com ([172.21.138.177]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Jun 2005 11:10:40 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh101.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Jun 2005 11:10:40 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] INVALID_IKE_SPI Date: Wed, 29 Jun 2005 11:10:39 +0300 Message-ID: Thread-Topic: [Ipsec] INVALID_IKE_SPI Thread-Index: AcV8SId64Uj+/9EESQW0rXc4xuxRZwAOMhSQ To: , , X-OriginalArrivalTime: 29 Jun 2005 08:10:40.0381 (UTC) FILETIME=[09E962D0:01C57C82] X-Spam-Score: 0.3 (/) X-Scan-Signature: b19722fc8d3865b147c75ae2495625f2 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Oops, we somehow missed that text in Section 2.21; thanks=20 for pointing it out. We'll update the clarifications draft accordingly. Best regards, Pasi > -----Original Message----- > From: Mohan Parthasarathy > Sent: Wednesday, June 29, 2005 4:09 AM > To: IPsec WG; Paul Hoffman > Subject: Re: [Ipsec] INVALID_IKE_SPI >=20 >=20 > In section 2.21, > If a node receives a message on UDP port 500 or 4500 outside=20 > the context of an IKE_SA known to it (and not a request to=20 > start one), it may be the result of a recent crash of the node. =20 > If the message is marked as a response, the node MAY audit the=20 > suspicious event but MUST NOT respond. If the message is marked=20 > as a request, the node MAY audit the suspicious event and MAY=20 > send a response. If a response is sent, the response MUST be=20 > sent to the IP address and port from whence it came with the=20 > same IKE SPIs and the Message ID copied. The response MUST=20 > NOT be cryptographically protected and MUST contain a Notify=20 > payload indicating INVALID_IKE_SPI. >=20 > This says, that the IKE header has the SPIs just copied back. You=20 > also have to copy back the "Initiator" flag so that the receiver=20 > of the notification can locate the SA appropriately. >=20 > -mohan _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 29 10:27:46 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DndXW-0000ba-Jy; Wed, 29 Jun 2005 10:27:46 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DndXT-0000bV-V9 for ipsec@megatron.ietf.org; Wed, 29 Jun 2005 10:27:44 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA25353 for ; Wed, 29 Jun 2005 10:27:42 -0400 (EDT) Received: from nav2.lgsoftindia.com ([203.200.13.13] helo=nav2.lgdomain.com) by ietf-mx.ietf.org with smtp (Exim 4.33) id 1Dndwz-0008R0-7g for ipsec@ietf.org; Wed, 29 Jun 2005 10:54:09 -0400 Received: from appolo.lgdomain.com ([192.168.1.21]) by nav2.lgdomain.com (SMSSMTP 4.1.2.20) with SMTP id M2005062920033820461 for ; Wed, 29 Jun 2005 20:03:38 +0530 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Date: Wed, 29 Jun 2005 20:03:36 +0530 Message-ID: Thread-Index: AcV8t4ijjwcVMmQFRLicNZT2N0w+FA== From: "Ravi Prasad" To: X-Spam-Score: 2.2 (++) X-Scan-Signature: 8a85b14f27c9dcbe0719e27d46abc1f8 Subject: [Ipsec] (no subject) X-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="===============1073670211==" Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org This is a multi-part message in MIME format. --===============1073670211== Content-class: urn:content-classes:message Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C57CB7.89D289B2" This is a multi-part message in MIME format. ------_=_NextPart_001_01C57CB7.89D289B2 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: base64 SGksDQoNClRoZSBmb2xsb3dpbmcgbGluZXMgYXJlIGZyb20gdGhlIGRyYWZ0ICJkcmFmdC1p ZXRmLWlwc2VjLWlrZXYyLTE3LnR4dCINCg0KMy4xNS4xIENvbmZpZ3VyYXRpb24gQXR0cmli dXRlcw0KIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAg ICAyICAgICAgICAgICAgICAgICAgIDMNCiAgICAgICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAg MSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCiAgICAgICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rDQogICAgICAhUnwgICAgICAgICBBdHRyaWJ1dGUgVHlwZSAgICAgICEgICAgICAg ICAgICBMZW5ndGggICAgICAgICAgICAgfA0KICAgICAgKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSsNCiAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICB8DQogICAgICB+ICAgICAgICAgICAgICAgICAgICAgICAgICAgICBWYWx1ZSAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgfg0KICAgICAgfCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCiAgICAg ICstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rDQogDQogICAgICAgICAgICAgICBGaWd1cmUgMjM6ICBDb25maWd1cmF0 aW9uIEF0dHJpYnV0ZSBGb3JtYXQNCiANCiAgIG8gIFJlc2VydmVkICgxIGJpdCkgLSBUaGlz IGJpdCBNVVNUIGJlIHNldCB0byB6ZXJvIGFuZCBNVVNUIGJlDQogICAgICBpZ25vcmVkIG9u IHJlY2VpcHQuDQogDQogICBvICBBdHRyaWJ1dGUgVHlwZSAoNyBiaXRzKSAtIEEgdW5pcXVl IGlkZW50aWZpZXIgZm9yIGVhY2ggb2YgdGhlDQogICAgICBDb25maWd1cmF0aW9uIEF0dHJp YnV0ZSBUeXBlcy4NCiANCiAgIG8gIExlbmd0aCAoMiBvY3RldHMpIC0gTGVuZ3RoIGluIG9j dGV0cyBvZiBWYWx1ZS4NCiANCiAgIG8gIFZhbHVlICgwIG9yIG1vcmUgb2N0ZXRzKSAtIFRo ZSB2YXJpYWJsZSBsZW5ndGggdmFsdWUgb2YgdGhpcw0KICAgICAgQ29uZmlndXJhdGlvbiBB dHRyaWJ1dGUuDQoNCiANCg0KIA0KDQpUaGUgc2l6ZSBvZiAiYXR0cmlidXRlIHR5cGUiIGlu IHRoZSBwYWNrZXQgZm9ybWF0IGlzIHNob3duIGFzIDE1IGJpdHMNCmFuZCBpbiB0aGUgZXhw bGFuYXRpb24gaXQgaXMgZ2l2ZW4gYXMgNyBiaXRzLg0KDQpNeSBhc3N1bXB0aW9uIGlzIHRo YXQgaXQgaXMgMTUgYml0cyBhcyB3aGF0ZXZlciB0aGUgdmFsdWUgZm9sbG93cyBpcw0KcHJv cGVybHkgYWxpZ25lZCB3aXRoIHRoaXMgbGVuZ3RoLg0KDQogDQoNCktpbmRseSBjbGFyaWZ5 IHdoZXRoZXIgdGhpcyBhc3N1bXB0aW9uIGlzIHJpZ2h0Pw0KDQogDQoNClRoYW5rcyBhbmQg cmVnYXJkcw0KDQpSYXZpIFByYXNhZA0KDQogDQoNCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KVGhpcyBF bWFpbCBNZXNzYWdlIGlzIGZvciB0aGUgc29sZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lw aWVudChzKSBhbmQgTWF5IGNvbnRhaW4gQ09ORklERU5USUFMIGFuZCBQUklWSUxFR0VEIGlu Zm9ybWF0aW9uLg0KTEcgU29mdCBJbmRpYSB3aWxsIG5vdCBiZSByZXNwb25pc2libGUgZm9y IGFueSB2aXJ1c2VzIG9yIGRlZmVjdHMgb3INCmFueSBmb3J3YXJkZWQgYXR0YWNoZW1lbnRz IGVtYW5hdGluZyBlaXRoZXIgZnJvbSB3aXRoaW4NCkxHIFNvZnQgSW5kaWEgb3Igb3V0c2lk ZS4gQW55IHVuYXV0aG9yaXNlZCByZXZpZXcgLCB1c2UsIGRpc2Nsb3N1cmUgb3IgZGlzdHJp YnV0aW9uIGlzIHByb2hpYml0ZWQuIElmIHlvdSBhcmUgbm90IGludGVudGRlZA0KcmVjaXBp ZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2VuZGVyIGJ5IHJlcGx5IGVtYWlsIGFuZCBkZXN0 cm95IGFsbA0KY29waWVzIG9mIHRoZSBvcmlnaW5hbCBtZXNzYWdlLg0KIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMj ------_=_NextPart_001_01C57CB7.89D289B2 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNl IiB4bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxu czpzdDE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyIgeG1s bnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiPg0KDQo8aGVhZD4NCjxNRVRB IEhUVFAtRVFVSVY9IkNvbnRlbnQtVHlwZSIgQ09OVEVOVD0idGV4dC9odG1sOyBjaGFyc2V0 PXVzLWFzY2lpIj4NCjxtZXRhIG5hbWU9R2VuZXJhdG9yIGNvbnRlbnQ9Ik1pY3Jvc29mdCBX b3JkIDExIChmaWx0ZXJlZCBtZWRpdW0pIj4NCjxvOlNtYXJ0VGFnVHlwZSBuYW1lc3BhY2V1 cmk9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOnNtYXJ0dGFncyINCiBuYW1l PSJwbGFjZSIgZG93bmxvYWR1cmw9Imh0dHA6Ly93d3cuNWlhbnRsYXZhbGFtcC5jb20vIi8+ DQo8IS0tW2lmICFtc29dPg0KPHN0eWxlPg0Kc3QxXDoqe2JlaGF2aW9yOnVybCgjZGVmYXVs dCNpZW9vdWkpIH0NCjwvc3R5bGU+DQo8IVtlbmRpZl0tLT4NCjxzdHlsZT4NCjwhLS0NCiAv KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KIHAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRp di5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe2NvbG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0 aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQN Cgl7Y29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJ e21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4w cHQ7DQoJZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkVtYWlsU3R5bGUxNw0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQtZmFtaWx5OkFyaWFs Ow0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KQHBhZ2UgU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMjVpbiAxLjBpbiAxLjI1aW47fQ0KZGl2LlNlY3Rp b24xDQoJe3BhZ2U6U2VjdGlvbjE7fQ0KLS0+DQo8L3N0eWxlPg0KDQo8L2hlYWQ+DQoNCjxi b2R5IGxhbmc9RU4tVVMgbGluaz1ibHVlIHZsaW5rPXB1cnBsZT4NCg0KPGRpdiBjbGFzcz1T ZWN0aW9uMT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPkhp LDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsN CmZvbnQtZmFtaWx5OkFyaWFsJz5UaGUgZm9sbG93aW5nIGxpbmVzIGFyZSBmcm9tIHRoZSBk cmFmdCAmIzgyMjA7PC9zcGFuPjwvZm9udD5kcmFmdC1pZXRmLWlwc2VjLWlrZXYyLTE3LnR4 dCYjODIyMTs8Zm9udA0Kc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7Zm9udC1mYW1pbHk6QXJpYWwnPjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48 L3A+DQoNCjxwcmU+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdCc+My4xNS4xIENvbmZpZ3VyYXRpb24gQXR0cmlidXRlczxv OnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgZmFjZT0i Q291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGZhY2U9IkNv dXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgMiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAzPG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4 IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDE8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9w cmU+PHByZT48Zm9udA0Kc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0n Zm9udC1zaXplOjEwLjBwdCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9 MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAhUnwmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7QXR0cmlidXRlIFR5cGUmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgISZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBMZW5ndGgmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIg ZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSs8bzpwPjwvbzpwPjwvc3Bh bj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7IHwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsgfDxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIg ZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgfiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBWYWx1ZSZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDt+PG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBmYWNlPSJDb3Vy aWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyB8Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7IHw8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9u dA0Kc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEw LjBwdCc+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICstKy0rLSstKy0rLSstKy0r LSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rLSstKy0rPG86cD48 L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBmYWNlPSJDb3Vy aWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgZmFjZT0iQ291cmll ciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsgRmlndXJlIDIzOiZuYnNwOyBDb25maWd1cmF0aW9uIEF0dHJpYnV0 ZSBGb3JtYXQ8bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdCc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9 MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZu YnNwOyZuYnNwOyBvJm5ic3A7IFJlc2VydmVkICgxIGJpdCkgLSBUaGlzIGJpdCBNVVNUIGJl IHNldCB0byB6ZXJvIGFuZCBNVVNUIGJlPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJl PjxwcmU+PGZvbnQNCnNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMC4wcHQnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBpZ25vcmVk IG9uIHJlY2VpcHQuPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcHJlPjxwcmU+PGZvbnQN CnNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4w cHQnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpz aXplPTIgZmFjZT0iQ291cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 Jz4mbmJzcDsmbmJzcDsgbyZuYnNwOyBBdHRyaWJ1dGUgVHlwZSAoNyBiaXRzKSAtIEEgdW5p cXVlIGlkZW50aWZpZXIgZm9yIGVhY2ggb2YgdGhlPG86cD48L286cD48L3NwYW4+PC9mb250 PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBD b25maWd1cmF0aW9uIEF0dHJpYnV0ZSBUeXBlcy48bzpwPjwvbzpwPjwvc3Bhbj48L2ZvbnQ+ PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBzdHls ZT0nZm9udC1zaXplOjEwLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250Pjwv cHJlPjxwcmU+PGZvbnQNCnNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMC4wcHQnPiZuYnNwOyZuYnNwOyBvJm5ic3A7IExlbmd0aCAoMiBvY3Rl dHMpIC0gTGVuZ3RoIGluIG9jdGV0cyBvZiBWYWx1ZS48bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wcmU+PHByZT48Zm9udA0Kc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250 PjwvcHJlPjxwcmU+PGZvbnQNCnNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMC4wcHQnPiZuYnNwOyZuYnNwOyBvJm5ic3A7IFZhbHVlICgwIG9y IG1vcmUgb2N0ZXRzKSAtIFRoZSB2YXJpYWJsZSBsZW5ndGggdmFsdWUgb2YgdGhpczxvOnA+ PC9vOnA+PC9zcGFuPjwvZm9udD48L3ByZT48cHJlPjxmb250DQpzaXplPTIgZmFjZT0iQ291 cmllciBOZXciPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0Jz4mbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsgQ29uZmlndXJhdGlvbiBBdHRyaWJ1dGUuPG86cD48L286cD48 L3NwYW4+PC9mb250PjwvcHJlPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PGZvbnQgc2l6ZT0y IGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7DQpmb250LWZhbWls eTpBcmlhbCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFj ZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFy aWFsJz5UaGUgc2l6ZSBvZiAmIzgyMjA7YXR0cmlidXRlIHR5cGUmIzgyMjE7IGluIHRoZSBw YWNrZXQNCmZvcm1hdCBpcyBzaG93biBhcyAxNSBiaXRzIGFuZCBpbiB0aGUgZXhwbGFuYXRp b24gaXQgaXMgZ2l2ZW4gYXMgNyBiaXRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFjZT1BcmlhbD48c3BhbiBz dHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFyaWFsJz5NeSBhc3N1bXB0 aW9uIGlzIHRoYXQgaXQgaXMgMTUgYml0cyBhcyB3aGF0ZXZlciB0aGUgdmFsdWUNCmZvbGxv d3MgaXMgcHJvcGVybHkgYWxpZ25lZCB3aXRoIHRoaXMgbGVuZ3RoLjxvOnA+PC9vOnA+PC9z cGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBzaXplPTIgZmFj ZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OkFy aWFsJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L2ZvbnQ+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PGZvbnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6 ZToxMC4wcHQ7DQpmb250LWZhbWlseTpBcmlhbCc+S2luZGx5IGNsYXJpZnkgd2hldGhlciB0 aGlzIGFzc3VtcHRpb24gaXMgcmlnaHQ/PG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0 eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPjxvOnA+Jm5ic3A7 PC9vOnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Zm9udCBz aXplPTIgZmFjZT1BcmlhbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQt ZmFtaWx5OkFyaWFsJz5UaGFua3MgYW5kIHJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L2Zv bnQ+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHN0MTpwbGFjZSB3OnN0PSJvbiI+PGZv bnQgc2l6ZT0yIGZhY2U9QXJpYWw+PHNwYW4NCiBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDtm b250LWZhbWlseTpBcmlhbCc+UmF2aTwvc3Bhbj48L2ZvbnQ+PC9zdDE6cGxhY2U+PGZvbnQN CnNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQt ZmFtaWx5OkFyaWFsJz4gUHJhc2FkPG86cD48L286cD48L3NwYW4+PC9mb250PjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxmb250IHNpemU9MiBmYWNlPUFyaWFsPjxzcGFuIHN0eWxl PSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6QXJpYWwnPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvZm9udD48L3A+DQoNCjwvZGl2Pg0KDQo8L2JvZHk+DQoNCjwvaHRtbD48 cHJlPiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIw0KVGhpcyBFbWFpbCBNZXNzYWdlIGlzIGZvciB0aGUgc29s ZSB1c2Ugb2YgdGhlIGludGVuZGVkIHJlY2lwaWVudChzKSBhbmQgTWF5IGNvbnRhaW4gQ09O RklERU5USUFMIGFuZCBQUklWSUxFR0VEIGluZm9ybWF0aW9uLg0KTEcgU29mdCBJbmRpYSB3 aWxsIG5vdCBiZSByZXNwb25pc2libGUgZm9yIGFueSB2aXJ1c2VzIG9yIGRlZmVjdHMgb3IN CmFueSBmb3J3YXJkZWQgYXR0YWNoZW1lbnRzIGVtYW5hdGluZyBlaXRoZXIgZnJvbSB3aXRo aW4NCkxHIFNvZnQgSW5kaWEgb3Igb3V0c2lkZS4gQW55IHVuYXV0aG9yaXNlZCByZXZpZXcg LCB1c2UsIGRpc2Nsb3N1cmUgb3IgZGlzdHJpYnV0aW9uIGlzIHByb2hpYml0ZWQuIElmIHlv dSBhcmUgbm90IGludGVudGRlZA0KcmVjaXBpZW50LCBwbGVhc2UgY29udGFjdCB0aGUgc2Vu ZGVyIGJ5IHJlcGx5IGVtYWlsIGFuZCBkZXN0cm95IGFsbA0KY29waWVzIG9mIHRoZSBvcmln aW5hbCBtZXNzYWdlLg0KIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjPC9wcmU+ ------_=_NextPart_001_01C57CB7.89D289B2-- --===============1073670211== 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 --===============1073670211==-- From ipsec-bounces@ietf.org Wed Jun 29 11:40:25 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnefp-0003Vf-88; Wed, 29 Jun 2005 11:40:25 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnefn-0003VV-FL for ipsec@megatron.ietf.org; Wed, 29 Jun 2005 11:40:23 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03520 for ; Wed, 29 Jun 2005 11:40:21 -0400 (EDT) From: Pasi.Eronen@nokia.com Received: from mgw-ext01.nokia.com ([131.228.20.93]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dnf5M-0002fA-8R for ipsec@ietf.org; Wed, 29 Jun 2005 12:06:50 -0400 Received: from esebh107.NOE.Nokia.com (esebh107.ntc.nokia.com [172.21.143.143]) by mgw-ext01.nokia.com (Switch-3.1.7/Switch-3.1.7) with ESMTP id j5TFeFFe022959; Wed, 29 Jun 2005 18:40:17 +0300 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh107.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Jun 2005 18:40:14 +0300 Received: from esebe105.NOE.Nokia.com ([172.21.143.53]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Jun 2005 18:40:14 +0300 X-MimeOLE: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] (no subject) Date: Wed, 29 Jun 2005 18:40:13 +0300 Message-ID: Thread-Topic: [Ipsec] (no subject) Thread-Index: AcV8t4ijjwcVMmQFRLicNZT2N0w+FAACJpCQ To: , X-OriginalArrivalTime: 29 Jun 2005 15:40:14.0668 (UTC) FILETIME=[D7D6F0C0:01C57CC0] X-Spam-Score: 0.3 (/) X-Scan-Signature: 4d87d2aa806f79fed918a62e834505ca Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Yes, 15 bits is the correct value, see e.g. http://www.vpnc.org/ietf-ipsec/mail-archive/msg01779.html and draft-eronen-ipsec-ikev2-clarifications-03, Section 5.1. Best regards, Pasi > -----Original Message----- > From: Ravi Prasad > Sent: Wednesday, June 29, 2005 5:34 PM > To: ipsec@ietf.org > Subject: [Ipsec] (no subject) >=20 >=20 > Hi, > The following lines are from the draft "draft-ietf-ipsec-ikev2-17.txt" > 3.15.1 Configuration Attributes >=20 > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > !R| Attribute Type ! Length | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > | | > ~ Value ~ > | | > +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ > > Figure 23: Configuration Attribute Format > > o Reserved (1 bit) - This bit MUST be set to zero and MUST be > ignored on receipt. > > o Attribute Type (7 bits) - A unique identifier for each of the > Configuration Attribute Types. > > o Length (2 octets) - Length in octets of Value. > > o Value (0 or more octets) - The variable length value of this > Configuration Attribute. > > > The size of "attribute type" in the packet format is shown as 15 > bits and in the explanation it is given as 7 bits. My assumption is > that it is 15 bits as whatever the value follows is properly aligned > with this length. >=20 > Kindly clarify whether this assumption is right? > =20 > Thanks and regards > Ravi Prasad =20 _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 29 13:46:00 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DngdM-0006mc-Jo; Wed, 29 Jun 2005 13:46:00 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DngdK-0006lG-Uz for ipsec@megatron.ietf.org; Wed, 29 Jun 2005 13:45:59 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16838 for ; Wed, 29 Jun 2005 13:45:57 -0400 (EDT) Received: from services.cse.ucsc.edu ([128.114.48.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dnh2w-0000Ai-27 for ipsec@ietf.org; Wed, 29 Jun 2005 14:12:26 -0400 Received: from COM (001-816-089.area1.spcsdns.net [68.27.154.128]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id j5THjh5v011621 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 29 Jun 2005 10:45:50 -0700 (PDT) From: Geoffrey Huang Message-Id: <200506291745.j5THjh5v011621@services.cse.ucsc.edu> To: Paul Hoffman , IPsec WG Subject: Re: [Ipsec] SPI values for messages outside of an IKE_SA Date: Wed, 29 Jun 2005 10:45:00 -0700 Mime-Version: 1.0 X-Mailer: VersaMail(c) 1998-2004 3.0C, palmOne, Inc. X-Sender: geoff@soe.ucsc.edu X-Priority: 3 Importance: Normal Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 4adaf050708fb13be3316a9eee889caa Content-Transfer-Encoding: 8bit Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Hi Paul, I prefer to be liberal in what you expect. That being said, I think the value should simply be ignored by the recipient. -g -----Original Message----- From: Paul Hoffman Subj: [Ipsec] SPI values for messages outside of an IKE_SA Date: Mon Jun 27, 2005 8:36 pm Size: 1K To: IPsec WG The current draft of the clarifications document says: 6.9 SPI values for messages outside of an IKE_SA The IKEv2 specification does not say what SPI values should be used in the IKE header for the small number of notifications that are allowed to be sent outside of an IKE_SA. Note that such notifications are explicitly *not* Informational exchanges; Section 1.5 makes it clear that these are one-way messages that must not be responded to. There are two cases when such a one-way notification can be sent: INVALID_IKE_SPI and INVALID_SPI. In both cases, there are no IKE SPI values that would be meaningful to the recipient of such a notification. A strict interpretation of the specification would require the sender to invent garbage values for the SPI fields. However, we think this was not the intention, and using zero values is acceptable. Can we come to consensus on what to use? If you feel it doesn't matter, feel free to say that, but if you feel that a particular value is important, let's try to find it. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 29 14:05:38 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DngwM-0002rn-JF; Wed, 29 Jun 2005 14:05:38 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DngwL-0002rT-GQ for ipsec@megatron.ietf.org; Wed, 29 Jun 2005 14:05:37 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19182 for ; Wed, 29 Jun 2005 14:05:34 -0400 (EDT) Received: from mclean-vscan2.bah.com ([156.80.3.62]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnhLt-0000rI-W4 for ipsec@ietf.org; Wed, 29 Jun 2005 14:32:03 -0400 Received: from mclean-vscan2.bah.com (mclean-vscan2.bah.com [156.80.3.62]) by mclean-vscan2.bah.com (8.11.0/8.11.0) with SMTP id j5TI5BS00620; Wed, 29 Jun 2005 14:05:11 -0400 (EDT) Received: from mclnexbh02.resource.ds.bah.com ([156.80.7.152]) by mclean-vscan2.bah.com (SAVSMTP 3.1.6.45) with SMTP id M2005062914051121942 ; Wed, 29 Jun 2005 14:05:11 -0400 Received: from MCLNEXVS05.resource.ds.bah.com ([156.80.7.124]) by mclnexbh02.resource.ds.bah.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 29 Jun 2005 14:05:10 -0400 x-mimeole: Produced By Microsoft Exchange V6.5.7226.0 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [Ipsec] SPI values for messages outside of an IKE_SA Date: Wed, 29 Jun 2005 14:05:10 -0400 Message-ID: <787C235469504E49AC6D9F9ED13738402C43A2@MCLNEXVS05.resource.ds.bah.com> Thread-Topic: [Ipsec] SPI values for messages outside of an IKE_SA Thread-Index: AcV80weix+Eg2bXlT7ur+PP/5MQ4LAAAbuwA From: "Lowe Chris" To: "Geoffrey Huang" , "IPsec WG" X-OriginalArrivalTime: 29 Jun 2005 18:05:10.0991 (UTC) FILETIME=[174085F0:01C57CD5] X-Spam-Score: 0.0 (/) X-Scan-Signature: f60d0f7806b0c40781eee6b9cd0b2135 Content-Transfer-Encoding: quoted-printable Cc: X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org Geoffrey: You're right, and functionally it will be; but in the interest if good housekeeping, I would argue to pad the value with zeros. =20 Chris -----Original Message----- From: ipsec-bounces@ietf.org [mailto:ipsec-bounces@ietf.org] On Behalf Of Geoffrey Huang Sent: Wednesday, June 29, 2005 1:45 PM To: Paul Hoffman; IPsec WG Subject: Re: [Ipsec] SPI values for messages outside of an IKE_SA Hi Paul, I prefer to be liberal in what you expect. That being said, I think the value should simply be ignored by the recipient. -g -----Original Message----- From: Paul Hoffman Subj: [Ipsec] SPI values for messages outside of an IKE_SA Date: Mon Jun 27, 2005 8:36 pm Size: 1K To: IPsec WG The current draft of the clarifications document says: 6.9 SPI values for messages outside of an IKE_SA The IKEv2 specification does not say what SPI values should be used in the IKE header for the small number of notifications that are allowed to be sent outside of an IKE_SA. Note that such notifications are explicitly *not* Informational exchanges; Section 1.5 makes it clear that these are one-way messages that must not be responded to. There are two cases when such a one-way notification can be sent: INVALID_IKE_SPI and INVALID_SPI. In both cases, there are no IKE SPI values that would be meaningful to the recipient of such a notification. A strict interpretation of the specification would require the sender to invent garbage values for the SPI fields. However, we think this was not the intention, and using zero values is acceptable. Can we come to consensus on what to use? If you feel it doesn't matter, feel free to say that, but if you feel that a particular value is important, let's try to find it. --Paul Hoffman, Director --VPN Consortium _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 29 14:17:28 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnh7n-0006DS-Vs; Wed, 29 Jun 2005 14:17:27 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnh7m-0006DF-JI for ipsec@megatron.ietf.org; Wed, 29 Jun 2005 14:17:26 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20380 for ; Wed, 29 Jun 2005 14:17:25 -0400 (EDT) Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnhXL-0001KF-51 for ipsec@ietf.org; Wed, 29 Jun 2005 14:43:54 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id j5TIH7Zb027902 for ; Wed, 29 Jun 2005 14:17:07 -0400 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id j5TIGxNd027897; Wed, 29 Jun 2005 14:16:59 -0400 Received: from pkoning.equallogic.com ([172.16.1.163]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 29 Jun 2005 14:16:59 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17090.58777.836963.594130@gargle.gargle.HOWL> Date: Wed, 29 Jun 2005 14:16:57 -0400 From: Paul Koning To: lowe_chris@bah.com Subject: RE: [Ipsec] SPI values for messages outside of an IKE_SA References: <787C235469504E49AC6D9F9ED13738402C43A2@MCLNEXVS05.resource.ds.bah.com> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid X-OriginalArrivalTime: 29 Jun 2005 18:16:59.0390 (UTC) FILETIME=[BD7DA1E0:01C57CD6] X-Spam-Score: 0.0 (/) X-Scan-Signature: 08170828343bcf1325e4a0fb4584481c Content-Transfer-Encoding: 7bit Cc: ipsec@ietf.org X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org >>>>> "Lowe" == Lowe Chris writes: Lowe> Geoffrey: You're right, and functionally it will be; but in the Lowe> interest if good housekeeping, I would argue to pad the value Lowe> with zeros. Asking for zeroes in the padding rather than arbitrary bytes is fine, but DON'T require the receiver to check it. Instead, tell the receiver to ignore it. "Be strict in what you send, liberal in what you receive". Not checking is more efficient; it also makes future evolution easier. paul _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 29 14:30:32 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnhKS-0001cL-Di; Wed, 29 Jun 2005 14:30:32 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnhKQ-0001c4-Cf for ipsec@megatron.ietf.org; Wed, 29 Jun 2005 14:30:30 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21741 for ; Wed, 29 Jun 2005 14:30:29 -0400 (EDT) Received: from spsystems.net ([216.126.83.115]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dnhk1-0001l5-3P for ipsec@ietf.org; Wed, 29 Jun 2005 14:56:58 -0400 Received: from spsystems.net (henry@localhost [127.0.0.1]) by spsystems.net (8.12.10/8.12.10) with ESMTP id j5TIU5F1021297; Wed, 29 Jun 2005 14:30:05 -0400 (EDT) Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id j5TIU4et021296; Wed, 29 Jun 2005 14:30:04 -0400 (EDT) Date: Wed, 29 Jun 2005 14:30:04 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: RE: [Ipsec] SPI values for messages outside of an IKE_SA In-Reply-To: <17090.58777.836963.594130@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: cf4fa59384e76e63313391b70cd0dd25 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Wed, 29 Jun 2005, Paul Koning wrote: > Asking for zeroes in the padding rather than arbitrary bytes is fine, > but DON'T require the receiver to check it. Instead, tell the > receiver to ignore it. > > "Be strict in what you send, liberal in what you receive". Not > checking is more efficient; it also makes future evolution easier. On the contrary: it makes future evolution impossible, because it gives developers no incentive to fix broken software that sends random non-zero trash or attempts to misuse those bytes for transmission of private information. Henry Spencer henry@spsystems.net _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 29 14:54:07 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnhhH-0007hy-FF; Wed, 29 Jun 2005 14:54:07 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnhhG-0007ht-Ff for ipsec@megatron.ietf.org; Wed, 29 Jun 2005 14:54:06 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23913 for ; Wed, 29 Jun 2005 14:54:05 -0400 (EDT) Received: from sadr.equallogic.com ([66.155.203.134]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dni6r-0002Qk-Az for ipsec@ietf.org; Wed, 29 Jun 2005 15:20:34 -0400 Received: from sadr.equallogic.com (localhost.localdomain [127.0.0.1]) by sadr.equallogic.com (8.12.8/8.12.8) with ESMTP id j5TIruZZ030781 for ; Wed, 29 Jun 2005 14:53:56 -0400 Received: from M31.equallogic.com (M31.equallogic.com [172.16.1.31]) by sadr.equallogic.com (8.12.8/8.12.8) with SMTP id j5TIrtNd030776; Wed, 29 Jun 2005 14:53:55 -0400 Received: from pkoning.equallogic.com ([172.16.1.163]) by M31.equallogic.com with Microsoft SMTPSVC(6.0.3790.211); Wed, 29 Jun 2005 14:53:55 -0400 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17090.60994.674221.103885@gargle.gargle.HOWL> Date: Wed, 29 Jun 2005 14:53:54 -0400 From: Paul Koning To: henry@spsystems.net Subject: RE: [Ipsec] SPI values for messages outside of an IKE_SA References: <17090.58777.836963.594130@gargle.gargle.HOWL> X-Mailer: VM 7.17 under 21.4 (patch 14) "Reasonable Discussion" XEmacs Lucid X-OriginalArrivalTime: 29 Jun 2005 18:53:55.0876 (UTC) FILETIME=[E69E8E40:01C57CDB] X-Spam-Score: 0.0 (/) X-Scan-Signature: 79899194edc4f33a41f49410777972f8 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 >>>>> "Henry" == Henry Spencer writes: Henry> On Wed, 29 Jun 2005, Paul Koning wrote: >> Asking for zeroes in the padding rather than arbitrary bytes is >> fine, but DON'T require the receiver to check it. Instead, tell >> the receiver to ignore it. >> >> "Be strict in what you send, liberal in what you receive". Not >> checking is more efficient; it also makes future evolution easier. Henry> On the contrary: it makes future evolution impossible, because Henry> it gives developers no incentive to fix broken software that Henry> sends random non-zero trash or attempts to misuse those bytes Henry> for transmission of private information. Sure it does. The next version will break them and they will get NO sympathy. paul _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 29 14:54:54 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnhi2-0007x9-Eh; Wed, 29 Jun 2005 14:54:54 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1Dnhi0-0007wu-Vp for ipsec@megatron.ietf.org; Wed, 29 Jun 2005 14:54:53 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA24018 for ; Wed, 29 Jun 2005 14:54:51 -0400 (EDT) Received: from services.cse.ucsc.edu ([128.114.48.10]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1Dni7b-0002TB-Lr for ipsec@ietf.org; Wed, 29 Jun 2005 15:21:21 -0400 Received: from COM (001-816-089.area1.spcsdns.net [68.27.154.128]) (authenticated bits=0) by services.cse.ucsc.edu (8.13.1/8.13.1) with ESMTP id j5TIsd4V006245 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NO); Wed, 29 Jun 2005 11:54:46 -0700 (PDT) From: Geoffrey Huang Message-Id: <200506291854.j5TIsd4V006245@services.cse.ucsc.edu> To: Henry Spencer , IP Security List Subject: RE: [Ipsec] SPI values for messages outside of an IKE_SA Date: Wed, 29 Jun 2005 11:54:00 -0700 Mime-Version: 1.0 X-Mailer: VersaMail(c) 1998-2004 3.0C, palmOne, Inc. X-Sender: geoff@soe.ucsc.edu X-Priority: 3 Importance: Normal Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Spam-Score: 0.0 (/) X-Scan-Signature: 52e1467c2184c31006318542db5614d5 Content-Transfer-Encoding: 8bit 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 I disagree. It doesn't make future evolution impossible. In the future, if we ever decide to include meaningful data in the SPI field, the receiver merely needs to pay attention to this data. The errant sender (who hitherto sent junk) then needs to address its bug. There's no prevention of future functionality by being liberal in what you accept. On the other hand, being liberal encourages interoperability. -g -----Original Message----- From: Henry Spencer Subj: RE: [Ipsec] SPI values for messages outside of an IKE_SA Date: Wed Jun 29, 2005 11:30 am Size: 846 bytes To: IP Security List On Wed, 29 Jun 2005, Paul Koning wrote: > Asking for zeroes in the padding rather than arbitrary bytes is fine, > but DON'T require the receiver to check it. Instead, tell the > receiver to ignore it. > > "Be strict in what you send, liberal in what you receive". Not > checking is more efficient; it also makes future evolution easier. On the contrary: it makes future evolution impossible, because it gives developers no incentive to fix broken software that sends random non-zero trash or attempts to misuse those bytes for transmission of private information. Henry Spencer henry@spsystems.net _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec From ipsec-bounces@ietf.org Wed Jun 29 23:36:56 2005 Received: from localhost.localdomain ([127.0.0.1] helo=megatron.ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnprD-0003wB-SN; Wed, 29 Jun 2005 23:36:55 -0400 Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by megatron.ietf.org with esmtp (Exim 4.32) id 1DnprC-0003tr-2K for ipsec@megatron.ietf.org; Wed, 29 Jun 2005 23:36:54 -0400 Received: from ietf-mx.ietf.org (ietf-mx [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA02221 for ; Wed, 29 Jun 2005 23:36:49 -0400 (EDT) Received: from spsystems.net ([216.126.83.115]) by ietf-mx.ietf.org with esmtp (Exim 4.33) id 1DnqGp-0005h2-DL for ipsec@ietf.org; Thu, 30 Jun 2005 00:03:24 -0400 Received: from spsystems.net (henry@localhost [127.0.0.1]) by spsystems.net (8.12.10/8.12.10) with ESMTP id j5U3aNF1027013; Wed, 29 Jun 2005 23:36:23 -0400 (EDT) Received: (from henry@localhost) by spsystems.net (8.12.10/8.12.10/Submit) id j5U3aNNQ027012; Wed, 29 Jun 2005 23:36:23 -0400 (EDT) Date: Wed, 29 Jun 2005 23:36:23 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: RE: [Ipsec] SPI values for messages outside of an IKE_SA In-Reply-To: <17090.60994.674221.103885@gargle.gargle.HOWL> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Spam-Score: 0.0 (/) X-Scan-Signature: d6b246023072368de71562c0ab503126 X-BeenThere: ipsec@ietf.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: IP Security List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: ipsec-bounces@ietf.org Errors-To: ipsec-bounces@ietf.org On Wed, 29 Jun 2005, Paul Koning wrote: > Henry> On the contrary: it makes future evolution impossible, because > Henry> it gives developers no incentive to fix broken software that > Henry> sends random non-zero trash or attempts to misuse those bytes > Henry> for transmission of private information. > > Sure it does. The next version will break them and they will get NO > sympathy. There can't be a next version if the broken stuff is widely enough used that breaking it all is judged to be unacceptable. See HTML for an example of the nightmares that ensue when receiver implementers are encouraged to be so liberal that no useful feedback goes back to sender implementers. Henry Spencer henry@spsystems.net _______________________________________________ Ipsec mailing list Ipsec@ietf.org https://www1.ietf.org/mailman/listinfo/ipsec