From lpatricky6a7eap@msn.com Sun Jun 1 00:59:22 2003 Received: from hotmail.com (bay3-dav56.bay3.hotmail.com [65.54.169.86]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h517xMAF097014 for ; Sun, 1 Jun 2003 00:59:22 -0700 (PDT) (envelope-from lpatricky6a7eap@msn.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Sun, 1 Jun 2003 00:59:17 -0700 Received: from 62.240.34.244 by bay3-dav56.bay3.hotmail.com with DAV; Sun, 01 Jun 2003 07:59:17 +0000 X-Originating-IP: [62.240.34.244] X-Originating-Email: [lpatricky6a7eap@msn.com] From: "Rupert Brass" Subject: HGH... a miracle? To: "Decoste Delvecchio" X-MSMail-Priority: Normal X-Accept-Language: en Importance: Normal X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2500.0000 X-Mailer: MSN Explorer 7.00.0021.1900 Content-Type: multipart/alternative; boundary="hC012iquKpGRJvUi2dJFN381l8gskb4QRHAfP42uN4Uk4rcHJXQW21xm11Mc" Content-Transfer-Encoding: 7bit Message-ID: X-OriginalArrivalTime: 01 Jun 2003 07:59:17.0394 (UTC) FILETIME=[B3499720:01C32813] Date: 1 Jun 2003 00:59:17 -0700 --hC012iquKpGRJvUi2dJFN381l8gskb4QRHAfP42uN4Uk4rcHJXQW21xm11Mc Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="US-ASCII"
Is Slow Metabolism Preventing You From Losing Weight?

Click here and finally get some results.

HGH has been specially formulated to increase the effectiveness of your body to break down energy that has been stored in your bodies fat cells.
In fact, it is so effective that you'll even lose weight while you rest.

Click here and see how HGH can help you achieve your weight loss goals.

Don't want any more adverts? visit here
--hC012iquKpGRJvUi2dJFN381l8gskb4QRHAfP42uN4Uk4rcHJXQW21xm11Mc-- From owner-ipsec@lists.tislabs.com Sun Jun 1 21:14:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h524EDAF085575; Sun, 1 Jun 2003 21:14:14 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA07921 Sun, 1 Jun 2003 23:30:51 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Sun, 1 Jun 2003 21:36:28 -0600 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: New algorithms and suites drafts Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi again. As Barbara said on Friday, we will have two documents for the algorithms: the MUST/SHOULD/MAY document and a UI document. The UI suite document is at . As Jeff said the other day, he turned in draft-ietf-ipsec-ikev2-algorithms-01.txt. A temporary version is available at ; it should be available from the IETF repository soon. In the -01 draft, Jeff included a UI suite (based on what he was asked on the mailing list earlier). He and I are sitting together at the moment, and he agreed that the UI suites should only be in the UI document. The -02 draft will not have his current section 5. Sorry for the mis-alignment. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Mon Jun 2 07:00:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h52E0KAF041753; Mon, 2 Jun 2003 07:00:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA10511 Mon, 2 Jun 2003 09:28:35 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <3ECA65EA.8000500@creeksidenet.com> To: "jpickering@creeksidenet.com" Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: Re: v7 nits MIME-Version: 1.0 X-Mailer: Lotus Notes Build V602_05062003 May 06, 2003 Message-ID: Date: Sat, 31 May 2003 19:50:29 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 05/31/2003 07:46:39 PM, Serialize complete at 05/31/2003 07:46:39 PM Content-Type: multipart/alternative; boundary="=_alternative 007215A085256D37_=" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multipart message in MIME format. --=_alternative 007215A085256D37_= Content-Type: text/plain; charset="US-ASCII" Good catch. I've tightened the wording. My expectation (which is what I tightened the wording to) was that this protocol type was effectively a modifier of the SPIs listed because a system could have ESP and AH SAs with the same SPIs at the same time. So I tightened the wording to say that this is only used if it concerns an existing SA. So in the example you give, where no SA exists, an implementation would send a zero and ignore the received value. Someone had already pointed out the ambiguity in the nat hash; I fixed it. --Charlie jpickering@creeksidenet.com wrote on 05/20/2003 01:29:14 PM: > > As long as we are still stuck in the bogs of identity usage, a > couple of points of v7 clarification would be also appreciated: > > Text on protocol for notifications states: > > For notifications > concerning IPsec SAs this field will contain either (2) > to indicate AH or (3) to indicate ESP. For notifications > for which no protocol ID is relevant, this field MUST be > sent as zero and MUST be ignored. > > What about "no prop chosen" for child props that include both > AH and ESP? What about "ipcomp supported" requests with > both AH and ESP props? I would claim that protocol ID is > not relevant, but the sentence above says I still need a "2" or "3". > Also, what SPI in these cases? > > For "nat detection source/dest ip" notifies, text says to hash SPIs, > address and port. Which spis are to be used and in which order? > > Jeff > > > > > > > --=_alternative 007215A085256D37_= Content-Type: text/html; charset="US-ASCII"
Good catch. I've tightened the wording. My expectation (which is what I tightened the wording to) was that this protocol type was effectively a modifier of the SPIs listed because a system could have ESP and AH SAs with the same SPIs at the same time. So I tightened the wording to say that this is only used if it concerns an existing SA. So in the example you give, where no SA exists, an implementation would send a zero and ignore the received value.

Someone had already pointed out the ambiguity in the nat hash; I fixed it.

        --Charlie

jpickering@creeksidenet.com wrote on 05/20/2003 01:29:14 PM:
>
> As long as we are still stuck in the bogs of identity usage, a
> couple of points of v7 clarification would be also appreciated:
>
> Text on protocol for notifications states:
>
>    For notifications
>      concerning IPsec SAs this field will contain either (2)
>      to indicate AH or (3) to indicate ESP. For notifications
>      for which no protocol ID is relevant, this field MUST be
>      sent as zero and MUST be ignored.
>
> What about "no prop chosen" for child props that include both
> AH and ESP? What about "ipcomp supported" requests with
> both AH and ESP props? I would claim that protocol ID is
> not relevant, but the sentence above says I still need a "2" or "3".
> Also, what SPI in these cases?
>
> For "nat detection source/dest ip" notifies, text says to hash SPIs,
> address and port. Which spis are to be used and in which order?
>
> Jeff
>
>
>
>
>
>
>
--=_alternative 007215A085256D37_=-- From owner-ipsec@lists.tislabs.com Mon Jun 2 07:01:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h52E1LAF041786; Mon, 2 Jun 2003 07:01:22 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA10510 Mon, 2 Jun 2003 09:28:29 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com In-Reply-To: <3ED36A6F.5010309@polito.it> To: derenale@polito.it Cc: ipsec@lists.tislabs.com, owner-ipsec@lists.tislabs.com Subject: Re: IKE_SA SPI with a changed address MIME-Version: 1.0 X-Mailer: Lotus Notes Build V602_05062003 May 06, 2003 Message-ID: Date: Sat, 31 May 2003 19:50:31 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 05/31/2003 07:46:39 PM, Serialize complete at 05/31/2003 07:46:39 PM Content-Type: multipart/alternative; boundary="=_alternative 007470A185256D37_=" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multipart message in MIME format. --=_alternative 007470A185256D37_= Content-Type: text/plain; charset="US-ASCII" derenale@polito.it wrote on 05/27/2003 09:38:55 AM: > what would happen in IKEv2 if the Initiator and Responder change their > IP adresses after have established an IKE_SA? The current spec is intentionally vague on this issue. The short answer is that most likely the IKE_SA would fail. There is certainly nothing in the spec that would require implementations to do anything that would ever allow this to work. There have been a number of proposals to enhance the protocol to make it possible for IPsec endpoints to change IP addresses and maintain an established SA (in support of both NATs and Mobile IP). All have problems, mostly because different scenarios require different approaches. I expect this will be an area of continued experimentation followed eventually by standardization. The current spec is vague to allow that experimentation. --Charlie --=_alternative 007470A185256D37_= Content-Type: text/html; charset="US-ASCII"
derenale@polito.it wrote on 05/27/2003 09:38:55 AM:
> what would happen in IKEv2 if the  Initiator and Responder change their
> IP adresses after have established an IKE_SA?
The current spec is intentionally vague on this issue. The short answer is that most likely the IKE_SA would fail. There is certainly nothing in the spec that would require implementations to do anything that would ever allow this to work. There have been a number of proposals to enhance the protocol to make it possible for IPsec endpoints to change IP addresses and maintain an established SA (in support of both NATs and Mobile IP). All have problems, mostly because different scenarios require different approaches.

I expect this will be an area of continued experimentation followed eventually by standardization. The current spec is vague to allow that experimentation.

        --Charlie --=_alternative 007470A185256D37_=-- From owner-ipsec@lists.tislabs.com Mon Jun 2 07:05:52 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h52E5nAF041996; Mon, 2 Jun 2003 07:05:51 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA10588 Mon, 2 Jun 2003 09:37:32 -0400 (EDT) Message-Id: <200306021129.HAA01757@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-aes-ctr-04.txt Date: Mon, 02 Jun 2003 07:29:32 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Using AES Counter Mode With IPsec ESP Author(s) : R. Housley Filename : draft-ietf-ipsec-ciph-aes-ctr-04.txt Pages : 19 Date : 2003-5-30 This document describes the use of AES Counter Mode, with an explicit initialization vector, as an IPsec Encapsulating Security Payload confidentiality mechanism. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-ctr-04.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ciph-aes-ctr-04.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-ctr-04.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-30152148.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-ctr-04.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-aes-ctr-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-30152148.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Jun 2 07:08:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h52E8PAF042082; Mon, 2 Jun 2003 07:08:25 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA10565 Mon, 2 Jun 2003 09:35:32 -0400 (EDT) Message-Id: <200306021129.HAA01741@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ciph-aes-ccm-03.txt Date: Mon, 02 Jun 2003 07:29:27 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Using AES CCM Mode With IPsec ESP Author(s) : R. Housley Filename : draft-ietf-ipsec-ciph-aes-ccm-03.txt Pages : 13 Date : 2003-5-30 This document describes the use of AES CCM Mode, with an explicit initialization vector, as an IPsec Encapsulating Security Payload (ESP) mechanism to provide confidentiality, data origin authentication, connectionless integrity. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ciph-aes-ccm-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ciph-aes-ccm-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-ietf-ipsec-ciph-aes-ccm-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. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-5-30152138.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ciph-aes-ccm-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ciph-aes-ccm-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-5-30152138.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Jun 3 03:53:17 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h53AokAF032794; Tue, 3 Jun 2003 03:53:17 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA18160 Tue, 3 Jun 2003 05:53:16 -0400 (EDT) Date: Tue, 3 Jun 2003 11:51:23 +0200 To: ipsec@lists.tislabs.com Subject: need for encrypting IKE QM exchange Message-ID: <20030603095123.GD29366@www.mobile-ip.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.28i From: jfl@mobile-ip.de (Floroiu John) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, There is a question I would like to ask regarding the need to encrypt the IKE Quick Mode exchange. I couldn't find throughout RFC2408 and RFC2409 a clear explanation to why SA, Nx, KE need to be encrypted (since the messages are authenticated anyway). SA, Nx and KE only indicate to a potential attacker the transforms that are being used and the SA's lifetime, which imo is harmless. Clearly IDci, IDcr must be encrypted, and the only answer I could figure out to the question above is that, since the protocol does not provide support for individual payloads to be encrypted, the whole message is encrypted instead. Looking at JFK I noticed however that "sa" and "sa'" are also transported (within message 3 and 4) in encryted form. The ultimate question is whether, assuming another protocol than IKE is used to negotiate SAs, SA, Nx and KE could be transported in plain text. Of course it is "better" to have them encrypted, but I cannot understand why would it be "worse" to have them in clear. Any comments would be gratly appreciated. John. From owner-ipsec@lists.tislabs.com Tue Jun 3 06:17:49 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h53DHnAF040562; Tue, 3 Jun 2003 06:17:49 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA19423 Tue, 3 Jun 2003 08:49:22 -0400 (EDT) X-Originating-IP: [64.114.95.129] X-Originating-Email: [askrywan@hotmail.com] From: "Andrew Krywaniuk" To: ipsec@lists.tislabs.com, paul.hoffman@vpnc.org Date: Mon, 02 Jun 2003 18:45:10 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 02 Jun 2003 22:45:11.0281 (UTC) FILETIME=[9FE2D610:01C32958] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Hi again. As Barbara said on Friday, we will have two documents for the >algorithms: the MUST/SHOULD/MAY document and a UI document. The UI suite >document is at >. A lot of people (I wasn't one of them) complained that IKEv1 was too hard to understand because you have to consult 3 different RFCs. One of the primary motivations of IKEv2 was to consolidate everything into one giant protocol description. But now for algorithms and ciphersuites, we seem to have no problem with creating extra documents at the last minute. I'm just wondering... was there a straw poll or a discussion where WG members expressed their preference for two documents? (I don't remember one.) If this is simply a matter of Paul and Jeff not stepping on each others' toes, couldn't there just be one document with 2 authors? Andrew -------------------------------------- The odd thing about fairness is when we strive so hard to be equitable that we forget to be correct. _________________________________________________________________ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 From owner-ipsec@lists.tislabs.com Tue Jun 3 06:21:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h53DLWAF040990; Tue, 3 Jun 2003 06:21:33 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA19372 Tue, 3 Jun 2003 08:38:24 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: IPsec bakeoff : Interoperability Tests at ETSI Sophia Antipolis FRANCE 21-25 July 2003 Date: Tue, 3 Jun 2003 14:43:42 +0200 Message-ID: <4091553999CBE4409CC2B562152B5A3302060B11@email10.etsihq.org> Thread-Topic: IPsec bakeoff : Interoperability Tests at ETSI Sophia Antipolis FRANCE 21-25 July 2003 Thread-Index: AcMpzcNbTKV+eLHqQciVDuGQNC+UCA== From: =?iso-8859-1?Q?Patrick_Ren=E9_Guillemin?= To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id IAA19369 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear All, This email is to remind you of the IPsec bakeoff organized by ETSI (Sophia Antipolis FRANCE 21-25 July 2003 = the week after IETF 57 in Vienna, Austria). Registration is open until July 6 at http://www.etsi.org/plugtests/02UpcomingEvents/IPsec/IPsec_home.htm click on "Registration login" For those who have are willing to attend, please register quickly so as to allow us to better prepare the event. Details: In addition to our new native IPv6 access, ETSI will provide (LAN and WLAN) with direct IPv4 access at 2x10 Mbps on the same network to tests: - IPsec over IPv6 and IPv4 - Manual IPsec - IKEv1 and IKEv2 - NAT-T - Remote access extensions - ... and more as you like As for other events, testing guidelines will be given but no tests are mandatory and participants select tests according to their wish. In addition to interoperability we could organize IPsec performance and scalability tests if enough participants are interested. During the week, we could book rooms to allow attendees to organize talks about subjects such as: - IPsec benchmarking methodology IETF draft - PPVPN - IPv6 v2 or IPv8 Feedback on generic problems encountered will be shared during the event. It is reminded that detailed information shared during the event is confidential and the event strictly reserved to technical people with products. Marketing and Sales representatives as well as observers are not allowed. A discussion list dedicated to the event has been set up. To subscribe to the PLUGTESTS-IPsec mailing list: send to listserv@list.etsi.org the following command: subscribe PLUGTESTS-IPsec (Firstname Lastname) in the body of the message. - For web archives see http://list.etsi.org/plugtests-ipsec.html Best Regards Patrick GUILLEMIN Plugtests - Technical Coordinator ETSI - European Telecommunications Standards Institute Tel: +33 4 92 94 4331 - Fax: +33 4 92 38 5231 http://www.etsi.org/plugtests From owner-ipsec@lists.tislabs.com Tue Jun 3 06:43:04 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h53DeXAF041824; Tue, 3 Jun 2003 06:43:03 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA19461 Tue, 3 Jun 2003 08:57:27 -0400 (EDT) Message-Id: <200306031147.HAA27449@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ikev2-algorithms-01.txt Date: Tue, 03 Jun 2003 07:47:27 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Cryptographic Algorithms for use in the Internet Key Exchange Version 2 Author(s) : J. Schiller Filename : draft-ietf-ipsec-ikev2-algorithms-01.txt Pages : 7 Date : 2003-6-2 The IPSec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE [RFC2409] and IKEv2 [IKEv2]) provide a mechanism to negotiate which algorithms should be used in any even association. However to ensure interoperability between disparate implementations it is necessary to specify a set of mandatory to implement algorithms to ensure at least one algorithm that all implementations will have available. This document defines the current set of mandatory to implement algorithms for use of IKEv2 as well as specifying algorithms that should be implemented because they made be promoted to mandatory at some future time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-algorithms-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ikev2-algorithms-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ikev2-algorithms-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-2145642.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ikev2-algorithms-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ikev2-algorithms-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-2145642.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Jun 3 06:45:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h53DgbAF041876; Tue, 3 Jun 2003 06:45:09 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA19470 Tue, 3 Jun 2003 08:58:28 -0400 (EDT) Message-Id: <200306031147.HAA27467@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ikev2-08.txt Date: Tue, 03 Jun 2003 07:47:32 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Internet Key Exchange (IKEv2) Protocol Author(s) : C. Kaufman Filename : draft-ietf-ipsec-ikev2-08.txt Pages : 97 Date : 2003-6-2 This document describes version 2 of the IKE (Internet Key Exchange) protocol. IKE is a component of IPsec used for performing mutual authentication and establishing and maintaining security associations. This version of IKE simplifies the design by removing options that were rarely used and simplifying the encoding. This version of the IKE specification combines the contents of what were previously separate documents, including ISAKMP (RFC 2408), IKE (RFC 2409), the Internet DOI (RFC 2407), NAT Traversal, Legacy authentication, and remote address acquisition. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-08.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ikev2-08.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ikev2-08.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-2145654.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ikev2-08.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ikev2-08.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-2145654.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Tue Jun 3 09:14:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h53GEnAF052912; Tue, 3 Jun 2003 09:14:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA20593 Tue, 3 Jun 2003 11:33:21 -0400 (EDT) From: Charlie_Kaufman@notesdev.ibm.com Subject: New IKEv2 draft -08 To: ipsec@lists.tislabs.com X-Mailer: Lotus Notes Build V601_12032002NP December 03, 2002 Message-ID: Date: Tue, 3 Jun 2003 11:14:14 -0400 X-MIMETrack: Serialize by Router on Ace/Iris(Build V602_05222003NP|May 22, 2003) at 06/03/2003 11:38:35 AM MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Just to let people know, I posted a revised IKEv2 draft incorporating the recent comments. There were no bits on the wire changes, but a substantial number of fixed typos and clarifications. I believe the intent is to go to last call with this one. It hasn't shown up on the I-D site yet, but Paul Hoffman has temporarily posted it on his site (as he announced Saturday): > Charlie has posted a new version of the main IKEv2 document. A > temporary version can be found at > > > --Paul Hoffman, Director > --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Jun 3 10:35:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h53HZ8AF055619; Tue, 3 Jun 2003 10:35:10 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA20967 Tue, 3 Jun 2003 12:44:28 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 3 Jun 2003 10:50:14 -0600 To: Charlie_Kaufman@notesdev.ibm.com, ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: New IKEv2 draft -08 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >Just to let people know, I posted a revised IKEv2 draft incorporating >the recent comments. There were no bits on the wire changes, but a >substantial number of fixed typos and clarifications. I believe the >intent is to go to last call with this one. It hasn't shown up on the >I-D site yet, but Paul Hoffman has temporarily posted it on his site >(as he announced Saturday): > > > Charlie has posted a new version of the main IKEv2 document. A > > temporary version can be found at > > The real draft appeared this morning (and the same is true for Jeff's algorithm requirements draft), so I nuked the temporary drafts. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Jun 3 11:03:49 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h53I1GAF057304; Tue, 3 Jun 2003 11:03:48 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA21193 Tue, 3 Jun 2003 13:30:23 -0400 (EDT) Message-Id: <4.3.2.7.2.20030603102719.050c84c8@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 03 Jun 2003 10:32:01 -0700 To: ipsec@lists.tislabs.com From: Barbara Fraser Subject: Working Group Last Call IKEv2 Cc: tytso@mit.edu, Barbara Fraser Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, This is a working group last call for comments on the IKEv2 draft, draft-ietf-ipsec-ikev2-08.txt, for progression to Proposed Standard: This last call will expire in three weeks on June 23, 2003. thanks, Barb and Ted From owner-ipsec@lists.tislabs.com Tue Jun 3 13:56:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h53KrpAF066246; Tue, 3 Jun 2003 13:56:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA22104 Tue, 3 Jun 2003 16:13:10 -0400 (EDT) Message-Id: <200306032018.h53KIxvj025073@thunk.east.sun.com> From: Bill Sommerfeld To: jfl@mobile-ip.de (Floroiu John) cc: ipsec@lists.tislabs.com Subject: Re: need for encrypting IKE QM exchange In-Reply-To: Your message of "Tue, 03 Jun 2003 11:51:23 +0200." <20030603095123.GD29366@www.mobile-ip.de> Reply-to: sommerfeld@east.sun.com Date: Tue, 03 Jun 2003 16:18:59 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > There is a question I would like to ask regarding the need to > encrypt the IKE Quick Mode exchange. I couldn't find throughout > RFC2408 and RFC2409 a clear explanation to why SA, Nx, KE need to be > encrypted (since the messages are authenticated anyway). > > SA, Nx and KE only indicate to a potential attacker the transforms that > are being used and the SA's lifetime, which imo is harmless. others may disagree. also, selector values are exchanged, which may indicate port number / protocol of the protected traffic, leaking information about the traffic being carried. - Bill From owner-ipsec@lists.tislabs.com Tue Jun 3 21:35:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h544XSAF080923; Tue, 3 Jun 2003 21:35:59 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA25111 Tue, 3 Jun 2003 23:57:43 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 3 Jun 2003 21:03:24 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Eliminating "SHOULD-" from draft-ietf-ipsec-algorithms Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings again. draft-ietf-ipsec-algorithms uses the standard definitions for MUST, SHOULD, and so on. It adds three new terms: SHOULD+ This term means the same as SHOULD. However it is likely that an algorithm marked as SHOULD+ will be promoted at some future time to be a MUST SHOULD- This terms means the same as SHOULD. However an algorithm marked as SHOULD- may be deprecated to a MAY in a future version of this document. MUST- This term means the same as MUST. However we expect at some point that this algorithm will no longer be a MUST in a future document. Although its status will be determined at a later time, it is reasonable to expect that if a future revision of a document alters the status of a MUST- algorithm, it will remain at least a SHOULD or a SHOULD-. The concept of SHOULD+ and MUST- is good, but SHOULD- is not useful and is confusing to implementers. In the current draft, there are only two items that are marked as SHOULD-: ENCR_DES_IV64 1 [RFC1827] SHOULD- ENCR_DES 2 [RFC2405] SHOULD- There is no good reason for DES to be a SHOULD or a SHOULD-. No one who cares about security would use it, and the only reason we see it in use in IPsec today is that it is still the MUST for IKEv1. Any use of DES should be a MAY. If IKEv2 lists DES as MAY instead of SHOULD-, that will hasten the demise of the use of DES in environments that should be using stronger keys. An additional benefit would be to make this RFC more understandable. (In less polite terms: let's finally dump DES from any level of requirement!) --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Jun 3 21:36:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h544XTAF080924; Tue, 3 Jun 2003 21:36:01 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA25112 Tue, 3 Jun 2003 23:57:44 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 3 Jun 2003 16:34:50 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96 from SHOULD to SHOULD+ Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings again. draft-ietf-ipsec-algorithms lists the following pseudo-random functions: 4.1.4. IKEv2 Transform Type 2 Algorithms Transfer Type 2 Algorithms are pseudo-random functions used to generate random values when needed. Name Number Defined In Status RESERVED 0 PRF_HMAC_MD5 1 [RFC2104] MAY PRF_HMAC_SHA1 2 [RFC2104] MUST PRF_HMAC_TIGER 3 [RFC2104] MAY PRF_AES128_CBC 4 [CIPH-AES] SHOULD It lists the following for integrity algorithms: 4.1.5. IKEv2 Transform Type 3 Algorithms Transfer Type 3 Algorithms are Integrity algorithms used to protect data against tampering. Name Number Defined In Status NONE 0 AUTH_HMAC_MD5_96 1 [RFC2403] MAY AUTH_HMAC_SHA1_96 2 [RFC2404] MUST AUTH_DES_MAC 3 MAY AUTH_KPDK_MD5 4 [RFC1826] MAY AUTH_AES_XCBC_96 5 SHOULD Some implementers have said that they would like to use PRF_AES128_CBC and AUTH_AES_XCBC_96 when they use AES for encryption in constrained hardware. Basically, why implement PRF_HMAC_SHA1 and AUTH_HMAC_SHA1_96 when PRF_AES128_CBC is good enough and it will clearly take less silicon. I followed this logic when I specified PRF_AES128_CBC and AUTH_AES_XCBC_96 in the VPN-2 UI suite. I propose that PRF_AES128_CBC be listed as SHOULD+ instead of SHOULD so that implementers know that they should be implementing it soon. Otherwise, I should change the VPN-2 UI suite to use PRF_HMAC_SHA1 and AUTH_HMAC_SHA1_96. Does anyone object to raising these two uses of AES to SHOULD+? --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Jun 3 22:09:23 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5459JAF081904; Tue, 3 Jun 2003 22:09:22 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA25392 Wed, 4 Jun 2003 00:41:40 -0400 (EDT) Date: Wed, 4 Jun 2003 00:47:16 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: Eliminating "SHOULD-" from draft-ietf-ipsec-algorithms In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 3 Jun 2003, Paul Hoffman / VPNC wrote: > (In less polite terms: let's finally dump DES from any level of requirement!) Agreed! About time. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Jun 4 02:21:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h549LHAF015589; Wed, 4 Jun 2003 02:21:17 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA27119 Wed, 4 Jun 2003 04:50:25 -0400 (EDT) Date: Wed, 4 Jun 2003 10:48:29 +0200 To: Bill Sommerfeld , ipsec@lists.tislabs.com Subject: Re: need for encrypting IKE QM exchange Message-ID: <20030604084829.GA3545@www.mobile-ip.de> References: <20030603095123.GD29366@www.mobile-ip.de> <200306032018.h53KIxvj025073@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200306032018.h53KIxvj025073@thunk.east.sun.com> User-Agent: Mutt/1.3.28i From: jfl@mobile-ip.de (Floroiu John) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > SA, Nx and KE only indicate to a potential attacker the transforms that > > are being used and the SA's lifetime, which imo is harmless. > > others may disagree. Thanks for the answer. I had this feeling indeed, but I wasn't sure about the reasons ;-) I actually overlooked the selectors, which provide indeed information about the traffic being exchanged through a security gateway. Regarding the other parameters, maybe the lifetime is the most sensitive. KE is essentially a public parameter, SPIs are seen afterwards in clear. As for the transforms, they are not many of them (so that one may try them in turn) and their strength, I believe, comes from the algorithm itself rather than from hiding its identity. > also, selector values are exchanged, which may indicate port number / > protocol of the protected traffic, leaking information about the > traffic being carried. John. From owner-ipsec@lists.tislabs.com Wed Jun 4 09:07:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h54G6fAF042142; Wed, 4 Jun 2003 09:07:21 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA29789 Wed, 4 Jun 2003 11:27:01 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16094.4355.911606.608931@pkoning.dev.equallogic.com> Date: Wed, 4 Jun 2003 11:32:19 -0400 From: Paul Koning To: paul.hoffman@vpnc.org Cc: ipsec@lists.tislabs.com Subject: Re: Eliminating "SHOULD-" from draft-ietf-ipsec-algorithms References: X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Paul" == Paul Hoffman > writes: Paul> ... Paul> There is no good reason for DES to be a SHOULD or a SHOULD-. No Paul> one who cares about security would use it, and the only reason Paul> we see it in use in IPsec today is that it is still the MUST Paul> for IKEv1. Any use of DES should be a MAY. I'd prefer SHOULD NOT for ENCR_DES. As for ENCR_DES_IV64, why is that mentioned at all? Has it ever been seen in the wild? I'd just drop that one entirely. paul From owner-ipsec@lists.tislabs.com Wed Jun 4 09:16:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h54GDwAF043124; Wed, 4 Jun 2003 09:16:28 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA29902 Wed, 4 Jun 2003 11:46:29 -0400 (EDT) Message-Id: <200306041551.h54Fpm812033@yogi> X-Mailer: exmh version 2.6.2 03/21/2003 with nmh-1.0.4 To: ipsec@lists.tislabs.com Subject: protocol encoding in proposal differs from IKEv1 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 04 Jun 2003 10:51:48 -0500 From: "Stephen C. Koehler" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I just noticed that the protocol encoding in IKEv2 is different from IKEv1. Is this correct?? >From IKEv2: o Protocol-Id (1 octet) - Specifies the protocol identifier for the current negotiation. Zero (0) indicates IKE, one (1) indicated ESP, and two (2) indicates AH. The IKEv2 DOI encodes ISAKMP as 1, AH as 2, and ESP as 3. >From an implementer's standpoint, I would like to point out (i.e., complain) that differences such as this make it very inconvenient to have IKEv1 and IKEv2 coexist in the same piece of code. My biggest complaint is that the the payload structures have changed from IKEv1 to IKEv2, but the payload type numbers have not. I think it would have been better to give a new number to any structure that changed. In the above case, the proposal structure is identical, but the encoding of one of the files has changed. -- Steve Koehler koehler@securecomputing.com From owner-ipsec@lists.tislabs.com Wed Jun 4 10:34:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h54HYdAF045606; Wed, 4 Jun 2003 10:34:39 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA00368 Wed, 4 Jun 2003 12:56:09 -0400 (EDT) Message-ID: <49B96FCC784BC54F9675A6B558C3464ED7C15F@mail.netoctave.com> From: David Blaker To: ipsec@lists.tislabs.com Subject: RE: Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96 from SHOULD to SHOULD+ Date: Wed, 4 Jun 2003 12:47:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C32AB9.0CEDE720" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C32AB9.0CEDE720 Content-Type: text/plain Although I have seen discussions of using AES for a PRF function on the IPSec mailing list, I am unaware of a formal definition that is documented in a draft. draft-ietf-ipsec-ciph-aes-cbs-05.txt makes no mention of a prf function, as far as I can tell. If PRF_AES128_CBC is to be either a SHOULD or a SHOULD+, then someone first needs to define it somewhere. Would one of the proposers of this algorithm please provide a draft? David Blaker, VP System Engineering CyberGuard Corporation -----Original Message----- From: Paul Hoffman / VPNC [mailto:paul.hoffman@vpnc.org] Sent: Tuesday, June 03, 2003 7:35 PM To: ipsec@lists.tislabs.com Subject: Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96 from SHOULD to SHOULD+ Greetings again. draft-ietf-ipsec-algorithms lists the following pseudo-random functions: 4.1.4. IKEv2 Transform Type 2 Algorithms Transfer Type 2 Algorithms are pseudo-random functions used to generate random values when needed. Name Number Defined In Status RESERVED 0 PRF_HMAC_MD5 1 [RFC2104] MAY PRF_HMAC_SHA1 2 [RFC2104] MUST PRF_HMAC_TIGER 3 [RFC2104] MAY PRF_AES128_CBC 4 [CIPH-AES] SHOULD It lists the following for integrity algorithms: 4.1.5. IKEv2 Transform Type 3 Algorithms Transfer Type 3 Algorithms are Integrity algorithms used to protect data against tampering. Name Number Defined In Status NONE 0 AUTH_HMAC_MD5_96 1 [RFC2403] MAY AUTH_HMAC_SHA1_96 2 [RFC2404] MUST AUTH_DES_MAC 3 MAY AUTH_KPDK_MD5 4 [RFC1826] MAY AUTH_AES_XCBC_96 5 SHOULD Some implementers have said that they would like to use PRF_AES128_CBC and AUTH_AES_XCBC_96 when they use AES for encryption in constrained hardware. Basically, why implement PRF_HMAC_SHA1 and AUTH_HMAC_SHA1_96 when PRF_AES128_CBC is good enough and it will clearly take less silicon. I followed this logic when I specified PRF_AES128_CBC and AUTH_AES_XCBC_96 in the VPN-2 UI suite. I propose that PRF_AES128_CBC be listed as SHOULD+ instead of SHOULD so that implementers know that they should be implementing it soon. Otherwise, I should change the VPN-2 UI suite to use PRF_HMAC_SHA1 and AUTH_HMAC_SHA1_96. Does anyone object to raising these two uses of AES to SHOULD+? --Paul Hoffman, Director --VPN Consortium ------_=_NextPart_001_01C32AB9.0CEDE720 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96 from SHOULD to = SHOULD+ Although I have seen discussions of using AES for a = PRF function on the IPSec mailing list, I am unaware of a formal = definition that is documented in a draft. = draft-ietf-ipsec-ciph-aes-cbs-05.txt makes no mention of a prf function, as far as I can tell. If = PRF_AES128_CBC is to be either a SHOULD or a SHOULD+, then someone = first needs to define it somewhere. Would one of the proposers of = this algorithm please provide a draft? David Blaker, VP System Engineering CyberGuard Corporation -----Original Message----- From: Paul Hoffman / VPNC [<3d.htm>mailto:paul.hoffman@vpnc.org]<= /FONT> Sent: Tuesday, June 03, 2003 7:35 PM To: ipsec@lists.tislabs.com Subject: Promoting PRF_AES128_CBC and = AUTH_AES_XCBC_96 from SHOULD to SHOULD+ Greetings again. draft-ietf-ipsec-algorithms lists = the following pseudo-random functions: 4.1.4. IKEv2 Transform Type 2 Algorithms Transfer Type 2 Algorithms are pseudo-random = functions used to generate random values when needed. = Name &n= bsp; Number Defined In Status = RESERVED &nbs= p; 0 = PRF_HMAC_MD5 = 1 = [RFC2104] MAY = PRF_HMAC_SHA1 = 2 = [RFC2104] MUST = PRF_HMAC_TIGER = 3 = [RFC2104] MAY = PRF_AES128_CBC = 4 [CIPH-AES] = SHOULD It lists the following for integrity = algorithms: 4.1.5. IKEv2 Transform Type 3 Algorithms Transfer Type 3 Algorithms are Integrity algorithms = used to protect data against tampering. = Name &n= bsp; Number = Defined In Status = NONE &n= bsp; 0 = AUTH_HMAC_MD5_96 = 1 = [RFC2403] MAY = AUTH_HMAC_SHA1_96 = 2 = [RFC2404] MUST = AUTH_DES_MAC = 3 = ; = ; MAY = AUTH_KPDK_MD5 = 4 = [RFC1826] MAY = AUTH_AES_XCBC_96 = 5 = ; = ; SHOULD Some implementers have said that they would like to = use PRF_AES128_CBC and AUTH_AES_XCBC_96 when they use = AES for encryption in constrained hardware. Basically, why implement = PRF_HMAC_SHA1 and AUTH_HMAC_SHA1_96 when PRF_AES128_CBC is good enough = and it will clearly take less silicon. I followed this logic = when I specified PRF_AES128_CBC and AUTH_AES_XCBC_96 in the VPN-2 UI = suite. I propose that PRF_AES128_CBC be listed as SHOULD+ = instead of SHOULD so that implementers know that they should be = implementing it soon. Otherwise, I should change the VPN-2 UI suite to use = PRF_HMAC_SHA1 and AUTH_HMAC_SHA1_96. Does anyone object to raising these two uses of AES = to SHOULD+? --Paul Hoffman, Director --VPN Consortium ------_=_NextPart_001_01C32AB9.0CEDE720-- From owner-ipsec@lists.tislabs.com Fri Jun 6 12:05:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h56J5IAF031053; Fri, 6 Jun 2003 12:05:19 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA15964 Fri, 6 Jun 2003 14:14:33 -0400 (EDT) Message-ID: <2A8DB02E3018D411901B009027FD3A3F03676096@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'ipsec@lists.tislabs.com'" Subject: Question regarding user identity confidentiality Date: Fri, 6 Jun 2003 15:20:36 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi all, i have read the ikev2 tuturial and ikev2 and i have a question about the user identity confidentiality: before secure legacy authentication was added to ikev2 i agreed with the selected user id confidentiality approach where the identity of the initiator is revealed first. at that time it is was difficult to assume a client-server architecture (i.e. which entity starts ike) and therefore which entity has to be protected. for remote access solutions using secure legacy authentication (by using eap) things are a little bit different. with eap you have the following message flow (taken from section 3.16 of [draft-ietf-ipsec-ikev2-08.txt]): Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi, [CERTREQ,] [IDr,] SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, EAP } HDR, SK {EAP, [AUTH] } --> The draft says "By including an IDi payload but not an AUTH payload, the initiator has declared an identity but has not proven it." (message 3) Section 3.16 additionally says: "Note that since IKE passes an indication of initiator identity in message 3 of the protocol, EAP based prompts for Identity SHOULD NOT be used." To me this seems that protection of the user identity against an active attack cannot be provided for eap methods (except if tunneled methods are used). this seems to have some disadvantages for remote access solutions where you have a client-server relationship. possible solutions are: a) ignore user id conf. b) suggest to use a tunneled method within ikev2/eap when user identity confidentiality is required. this clearly has a performance disadvantage since you create two tunnels (for server to client authentication) in addition to the eap method for client to server authentication. c) change the handling for secure legacy auth. and let the responder authenticate to the initiator first d) others? am i wrong with my observations? ciao hannes From owner-ipsec@lists.tislabs.com Fri Jun 6 12:56:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h56JuPAF032451; Fri, 6 Jun 2003 12:56:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA16178 Fri, 6 Jun 2003 15:22:13 -0400 (EDT) Message-Id: <4.3.2.7.2.20030606121942.04ed4dc0@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Jun 2003 12:27:08 -0700 To: Internet-Drafts@ietf.org From: Barbara Fraser Subject: Problem with draft-ietf-ipsec-ikev2-algorithms-02.txt Cc: jis@mit.edu, tytso@mit.edu, byfraser@cisco.com, ipsec@lists.tislabs.com, angelos@cs.columbia.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Re: draft-ietf-ipsec-ikev2-algorithms-02.txt Ted and I were looking for this draft and noticed that the link for the -02 document on the IPsec wg page is broken. When we checked the ftp site, there were no copies of this document at all, even the earlier -01 version. We believe Jeff submitted the -02 document on June 3. There has been no announcement of this draft which leads us to believe something happened in the middle of ID's handling of this document. Thanks for looking into this, Barb and Ted From owner-ipsec@lists.tislabs.com Fri Jun 6 13:13:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h56KDDAF032930; Fri, 6 Jun 2003 13:13:14 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA16341 Fri, 6 Jun 2003 15:46:15 -0400 (EDT) Date: Fri, 6 Jun 2003 15:52:03 -0400 From: "Theodore Ts'o" To: David Blaker Cc: ipsec@lists.tislabs.com Subject: Re: Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96 from SHOULD to SHOULD+ Message-ID: <20030606195203.GB4070@think> References: <49B96FCC784BC54F9675A6B558C3464ED7C15F@mail.netoctave.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49B96FCC784BC54F9675A6B558C3464ED7C15F@mail.netoctave.com> User-Agent: Mutt/1.5.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Jun 04, 2003 at 12:47:57PM -0400, David Blaker wrote: > Although I have seen discussions of using AES for a PRF function on > the IPSec mailing list, I am unaware of a formal definition that is > documented in a draft. draft-ietf-ipsec-ciph-aes-cbs-05.txt makes no > mention of a prf function, as far as I can tell. If PRF_AES128_CBC > is to be either a SHOULD or a SHOULD+, then someone first needs to > define it somewhere. Would one of the proposers of this algorithm please > provide a draft? Good catch. It appears that ikev2-algorithms-01 is in error: PRF_AES128_CBC is not defined in draft-ietf-ipsec-aes-cbc-05, and I don't see any drafts where it is defined. So we need to modify ikev2-algorithms to point at a (currently non-existent) I-D, and we need to find a volunteer to quickly gin up an I-D which defines PRF_AES128_CBC. Barbara and I believe that this shouldn't hold up the IETF last call for draft-ietf-ipsec-algorithms, since writing up this PRF AES I-D should be something that can be done quickly, however, with the dangling reference the algorithms document will stall when it hits the RFC editor, so we will need to plug this reference quickly. - Ted From drobertmjkyjpxoh7gdf0@msn.com Fri Jun 6 16:26:13 2003 Received: from hotmail.com (bay3-dav140.bay3.hotmail.com [65.54.169.170]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h56NQDAF039642 for ; Fri, 6 Jun 2003 16:26:13 -0700 (PDT) (envelope-from drobertmjkyjpxoh7gdf0@msn.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Fri, 6 Jun 2003 16:26:08 -0700 Received: from 212.170.242.64 by bay3-dav140.bay3.hotmail.com with DAV; Fri, 06 Jun 2003 23:26:08 +0000 X-Originating-IP: [212.170.242.64] X-Originating-Email: [drobertmjkyjpxoh7gdf0@msn.com] To: "Schrawder Vitiello" Subject: loving women want you From: "Graap Saglibene" X-Originating-Ip: [7.930.85.01] X-Priority: 3 (Normal) Content-Type: multipart/alternative; boundary="I2uTPp6aVeiXCsFwjI0cp8S0d45ykhwqEOmo31jmjKYkPyOh7Gef0naDbB5bGjFy4W" Content-Transfer-Encoding: 7bit Message-ID: X-OriginalArrivalTime: 06 Jun 2003 23:26:08.0786 (UTC) FILETIME=[02535720:01C32C83] Date: 6 Jun 2003 16:26:08 -0700 --I2uTPp6aVeiXCsFwjI0cp8S0d45ykhwqEOmo31jmjKYkPyOh7Gef0naDbB5bGjFy4W Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="ISO-8859-1"
Searching And Still Haven't Found A That Someone Special?
Don't spend another day alone, take your first step towards a better life.

Visit Us Here And Choose The Woman You'd Like Meet

You can browse through our database of pictures and bio's of beautiful Russian women
looking for a western man just like you!

Join Today For FREE And Start A Relationship That Will Last A Life Time

Visit Us Online Here

here To Be Taken Off
--I2uTPp6aVeiXCsFwjI0cp8S0d45ykhwqEOmo31jmjKYkPyOh7Gef0naDbB5bGjFy4W-- From owner-ipsec@lists.tislabs.com Fri Jun 6 17:05:50 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5705nAF040942; Fri, 6 Jun 2003 17:05:49 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA17341 Fri, 6 Jun 2003 19:34:37 -0400 (EDT) Date: Sat, 7 Jun 2003 02:40:27 +0300 (IDT) From: Hugo Krawczyk To: "Theodore Ts'o" cc: David Blaker , IPsec WG Subject: Re: Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96 from SHOULD to SHOULD+ In-Reply-To: <20030606195203.GB4070@think> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Good catch. It appears that ikev2-algorithms-01 is in error: > PRF_AES128_CBC is not defined in draft-ietf-ipsec-aes-cbc-05, and I > don't see any drafts where it is defined. So we need to modify > ikev2-algorithms to point at a (currently non-existent) I-D, and we > need to find a volunteer to quickly gin up an I-D which defines > PRF_AES128_CBC. that's easy: the right document to point out is draft-ietf-ipsec-ciph-aes-xcbc-mac-04.txt. The function defined there is exactly what the algorithms I-D calls PRF_AES128_CBC (maybe we should rename it to PRF_AES128_XCBC), except that draft-ietf-ipsec-ciph-aes-xcbc-mac-04.txt mandates the truncation to 96 bits which is not necessary (nor recommended) here. Thus one can define PRF_AES128_XCBC by referring to the above I-D and saying that no truncation takes place (all the 128 bits of output from AES128 are output by the prf). This means ignoring the text in draft-ietf-ipsec-ciph-aes-xcbc-mac-04.txt after sec 4.2. It would be nice if draft-ietf-ipsec-ciph-aes-xcbc-mac-04.txt is reorganized a bit such as first aes-xcbc-mac is defined with output equal to the block length (does this draft refer only to aes128?) Then a section about truncation is added where aes-xcbc-mac-96 is defined. A couple of test cases for aes-xcbc-mac could be added. In this way ikev2 could cleanly refer to aes-xcbc-mac as defined in draft-ietf-ipsec-ciph-aes-xcbc-mac-04.txt. Hugo From owner-ipsec@lists.tislabs.com Fri Jun 6 17:06:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h57066AF040956; Fri, 6 Jun 2003 17:06:06 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA17389 Fri, 6 Jun 2003 19:42:44 -0400 (EDT) Date: Sat, 7 Jun 2003 02:48:48 +0300 (IDT) From: Hugo Krawczyk To: Tschofenig Hannes cc: "'ipsec@lists.tislabs.com'" Subject: Re: Question regarding user identity confidentiality In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03676096@mchp905a.mch.sbs.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hannes, You are late to this party... This issue has been discussed in a couple of threads in this list (the last of which took place in March and carried the subject "Do ipsec vendors care about privacy?"). This represented my failed attempt to get the WG to decide on what seems as the obvious requirement to protect the user's id in the EAP exchange. Even the "provocative" subject of the thread (and the positive answer to that question given by several ipsec vendors) was insufficient to market the idea. If you read the thread you'll see some people claiming that doing so would add significant complexity to the protocol. I do not agree. I have the feeling that a silent majority would have supported this, but that's how silent majorities work, they remain silent... :) Hugo On Fri, 6 Jun 2003, Tschofenig Hannes wrote: > hi all, > > i have read the ikev2 tuturial and ikev2 and i have a question about the > user identity confidentiality: > > before secure legacy authentication was added to ikev2 i agreed with the > selected user id confidentiality approach where the identity of the > initiator is revealed first. at that time it is was difficult to assume a > client-server architecture (i.e. which entity starts ike) and therefore > which entity has to be protected. > > for remote access solutions using secure legacy authentication (by using > eap) things are a little bit different. > > with eap you have the following message flow (taken from section 3.16 of > [draft-ietf-ipsec-ikev2-08.txt]): > > Initiator Responder > ----------- ----------- > HDR, SAi1, KEi, Ni --> > > <-- HDR, SAr1, KEr, Nr, [CERTREQ] > > HDR, SK {IDi, [CERTREQ,] [IDr,] > SAi2, TSi, TSr} --> > > <-- HDR, SK {IDr, [CERT,] AUTH, > EAP } > > HDR, SK {EAP, [AUTH] } --> > > The draft says "By including an IDi payload but not an AUTH payload, the > initiator has declared an identity but has not proven it." (message 3) > > Section 3.16 additionally says: "Note that since IKE passes an indication of > initiator identity in message 3 of the protocol, EAP based prompts for > Identity SHOULD NOT be used." > > To me this seems that protection of the user identity against an active > attack cannot be provided for eap methods (except if tunneled methods are > used). this seems to have some disadvantages for remote access solutions > where you have a client-server relationship. > > possible solutions are: > > a) ignore user id conf. > b) suggest to use a tunneled method within ikev2/eap when user identity > confidentiality is required. this clearly has a performance disadvantage > since you create two tunnels (for server to client authentication) in > addition to the eap method for client to server authentication. > c) change the handling for secure legacy auth. and let the responder > authenticate to the initiator first > d) others? > > am i wrong with my observations? > > ciao > hannes > From owner-ipsec@lists.tislabs.com Fri Jun 6 17:17:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h570HbAF041189; Fri, 6 Jun 2003 17:17:39 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA17453 Fri, 6 Jun 2003 19:54:29 -0400 (EDT) Message-Id: <5.2.0.9.2.20030606195908.043c5358@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 06 Jun 2003 20:00:20 -0400 To: action@ietf.org From: Russ Housley Subject: Fwd: Problem with draft-ietf-ipsec-ikev2-algorithms-02.txt Cc: jis@mit.edu, tytso@mit.edu, byfraser@cisco.com, ipsec@lists.tislabs.com, angelos@cs.columbia.edu Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Please fix the link to draft-ietf-ipsec-ikev2-algorithms-02.txt on the IPsec WG web page and make sure the document is in the repository. Russ >Delivered-To: housley@mail.binhost.com >Delivered-To: alias-582@vigilsec.com >X-Sender: byfraser@mira-sjc5-4.cisco.com >X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 >Date: Fri, 06 Jun 2003 12:27:08 -0700 >To: Internet-Drafts@ietf.org >From: Barbara Fraser >Subject: Problem with draft-ietf-ipsec-ikev2-algorithms-02.txt >Cc: jis@mit.edu, tytso@mit.edu, byfraser@cisco.com, ipsec@lists.tislabs.com, > angelos@cs.columbia.edu >Sender: owner-ipsec@lists.tislabs.com > >Hi, > >Re: draft-ietf-ipsec-ikev2-algorithms-02.txt > >Ted and I were looking for this draft and noticed that the link for the >-02 document on the IPsec wg page is broken. When we checked the ftp >site, there were no copies of this document at all, even the earlier -01 >version. We believe Jeff submitted the -02 document on June 3. There >has been no announcement of this draft which leads us to believe something >happened in the middle of ID's handling of this document. > >Thanks for looking into this, >Barb and Ted > From owner-ipsec@lists.tislabs.com Sat Jun 7 01:53:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h578r2AF076837; Sat, 7 Jun 2003 01:53:06 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA19616 Sat, 7 Jun 2003 04:21:37 -0400 (EDT) Date: Sat, 7 Jun 2003 10:27:30 +0200 From: Markus Friedl To: ipsec@lists.tislabs.com Subject: IKEv2 and NAT/T Message-ID: <20030607082730.GA25456@faui02> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, Jun 03, 2003 at 11:14:14AM -0400, Charlie_Kaufman@notesdev.ibm.com wrote: > Just to let people know, I posted a revised IKEv2 draft incorporating > the recent comments. Hello, since IKEv2 includes support for NAT/T, I'd like to know how IKEv2 is affected by the IPR/patent claims that exist for several NAT traversal methods. Does anyone have pointers about the nature of these IPR claims and what exactily is affected by these claims. Encapsulating ESP in UDP seems very trivial, so I doubt that this is all the patents are about. Any help appreciated. thanks, -markus From owner-ipsec@lists.tislabs.com Sat Jun 7 18:00:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5810rAF038245; Sat, 7 Jun 2003 18:00:53 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA22740 Sat, 7 Jun 2003 20:25:37 -0400 (EDT) Message-Id: <4.3.2.7.2.20030606162749.04395f00@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Fri, 06 Jun 2003 18:30:50 -0700 To: John Shriver From: Barbara Fraser Subject: draft-ietf-ipsec-doi-tc-mib-07.txt and friends Cc: tytso@mit.edu, byfraser@cisco.com, angelos@cs.columbia.edu, Bert Wijnen , "Hilarie Orman, Purple Streak Development" , Luis Sanchez , "C. M. Heard" , Russ Housley , Paul Hoffman / VPNC , ipsec@lists.tislabs.com Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_39173268==_.ALT" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --=====================_39173268==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi John, Ted and I have been, once again, digging back into the status of 5 of the MIB documents and would like to see us once and for all get these documents put to bed. We've seen and read the thread concerning draft-ietf-ipsec-doi-tc-mib-07.txt. Everything seems to have come to a halt after Mike Heard posted his summary MIB doctor comments on April 28. This document is referenced in the an IPSP document so we need to somehow resolve the issues surrounding it, which is why there is such a wide distribution on this message. First question is, are you willing to continue to work on this document as the editor? Second, it seems there has been some difference of opinion between you and Mike. One comment made was that some of the difficulties arose from this document being looked at in isolation of the other related documents. This brings me to a question. Every time Ted and I have asked if anyone is implementing these MIBs, there has been total silence leading us to believe nobody is implementing them. Paul Hoffman has kindly resubmitted draft-ietf-ipsec-ike-monitor-mib-04.txt, draft-ietf-ipsec-isakmp-di-mon-mib-05.txt, and draft-ietf-ipsec-monitor-mib-06.txt for us in the new format, and if he, or someone else is willing to take them on, we could continue to progress all of them. If that's what folks want to do. On the other hand, we could also choose to progress only the document that Hilary's group needs and drop the other three due to lack of interest/implementation. It's also fair to remind folks that these are all IKEv1 MIB docs. All this boils down to the following: 1. Are you willing to continue to edit draft-ietf-ipsec-doi-tc-mib-07.txt? 2. We need to come to agreement on what changes are needed, that is we must address the MIB doctor comments. 3. Are we going to continue to support draft-ietf-ipsec-ike-monitor-mib-04.txt, draft-ietf-ipsec-isakmp-di-mon-mib-05.txt, and draft-ietf-ipsec-monitor-mib-06.txt? If so, who's willing to take on the document editor job? And, more importantly, how do we decide what changes are needed to them. I feel like we're living in Ground Day with these MIB docs. We keep living the same thing over and over. Let's please get to the end :-) thanks, Barb and Ted --=====================_39173268==_.ALT Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi John,

Ted and I have been, once again, digging back into the status of 5 of the MIB documents and would like to see us once and for all get these documents put to bed.  We've seen and read the thread concerning draft-ietf-ipsec-doi-tc-mib-07.txt. Everything seems to have come to a halt after Mike Heard posted his summary MIB doctor comments on April 28. This document is referenced in the an IPSP document so we need to somehow resolve the issues surrounding it,  which is why there is such a wide distribution on this message.  First question is, are you willing to continue to work on this document as the editor? Second, it seems there has been some difference of opinion between you and Mike. One comment made was that some of the difficulties arose from this document being looked at in isolation of the other related documents. This brings me to a question. Every time Ted and I have asked if anyone is implementing these MIBs, there has been total silence leading us to believe nobody is implementing them. Paul Hoffman has kindly resubmitted draft-ietf-ipsec-ike-monitor-mib-04.txt,  draft-ietf-ipsec-isakmp-di-mon-mib-05.txt, and draft-ietf-ipsec-monitor-mib-06.txt for us in the new format, and if he, or someone else is willing to take them on, we could continue to progress all of them.  If that's what folks want to do. On the other hand, we could also choose to progress only the document that Hilary's group needs and drop the other three due to lack of interest/implementation.  It's also fair to remind folks that these are all IKEv1 MIB docs.

All this boils down to the following:
1. Are you willing to continue to edit draft-ietf-ipsec-doi-tc-mib-07.txt?
2. We need to come to agreement on what changes are needed, that is we must address the MIB doctor comments.
3. Are we going to continue to support draft-ietf-ipsec-ike-monitor-mib-04.txt,  draft-ietf-ipsec-isakmp-di-mon-mib-05.txt, and draft-ietf-ipsec-monitor-mib-06.txt? If so, who's willing to take on the document editor job? And, more importantly, how do we decide what changes are needed to them.

I feel like we're living in Ground Day with these MIB docs. We keep living the same thing over and over. Let's please get to the end=20 :-)

thanks,
Barb and Ted --=====================_39173268==_.ALT-- From owner-ipsec@lists.tislabs.com Sat Jun 7 18:00:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5810uAF038255; Sat, 7 Jun 2003 18:00:59 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA22752 Sat, 7 Jun 2003 20:28:38 -0400 (EDT) Cc: David Blaker , ipsec@lists.tislabs.com Message-ID: <3EE10F4A.7000303@bell-labs.com> Date: Fri, 06 Jun 2003 18:01:46 -0400 From: Uri Blumenthal Organization: Lucent Tehcnologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en, zh-cn, ru, de, he MIME-Version: 1.0 To: "Theodore Ts'o" Original-CC: David Blaker , ipsec@lists.tislabs.com Subject: Re: Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96 from SHOULD to SHOULD+ References: <49B96FCC784BC54F9675A6B558C3464ED7C15F@mail.netoctave.com> <20030606195203.GB4070@think> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'd volunteer, since I've been working on the thing (on and off) for a while now. But as the discussion demonstrated, it's not as simple - if you want to use that PRF in IKEv2. Theodore Ts'o wrote: > On Wed, Jun 04, 2003 at 12:47:57PM -0400, David Blaker wrote: > >>Although I have seen discussions of using AES for a PRF function on >>the IPSec mailing list, I am unaware of a formal definition that is >>documented in a draft. draft-ietf-ipsec-ciph-aes-cbs-05.txt makes no >>mention of a prf function, as far as I can tell. If PRF_AES128_CBC >>is to be either a SHOULD or a SHOULD+, then someone first needs to >>define it somewhere. Would one of the proposers of this algorithm please >>provide a draft? > > > Good catch. It appears that ikev2-algorithms-01 is in error: > PRF_AES128_CBC is not defined in draft-ietf-ipsec-aes-cbc-05, and I > don't see any drafts where it is defined. So we need to modify > ikev2-algorithms to point at a (currently non-existent) I-D, and we > need to find a volunteer to quickly gin up an I-D which defines > PRF_AES128_CBC. > > Barbara and I believe that this shouldn't hold up the IETF last call > for draft-ietf-ipsec-algorithms, since writing up this PRF AES I-D > should be something that can be done quickly, however, with the > dangling reference the algorithms document will stall when it hits the > RFC editor, so we will need to plug this reference quickly. From owner-ipsec@lists.tislabs.com Sat Jun 7 18:04:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h58144AF038387; Sat, 7 Jun 2003 18:04:04 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA22753 Sat, 7 Jun 2003 20:28:44 -0400 (EDT) Date: Fri, 6 Jun 2003 22:42:44 +0200 From: Markus Friedl To: ipsec@lists.tislabs.com Subject: Re: New IKEv2 draft -08 Message-ID: <20030606204244.GA31195@folly> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, Jun 03, 2003 at 11:14:14AM -0400, Charlie_Kaufman@notesdev.ibm.com wrote: > Just to let people know, I posted a revised IKEv2 draft incorporating > the recent comments. Hello, since IKEv2 includes support for NAT/T, I'd like to know how IKEv2 is affected by the IPR/patent claims that exist for several NAT traversal methods. Does anyone have pointers about the nature of these IPR claims and what exactily is affected by these claims. Encapsulating ESP in UDP seems very trivial, so I doubt that this is all the patents are about. Any help appreciated. thanks, -markus From owner-ipsec@lists.tislabs.com Sun Jun 8 15:19:41 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h58MJeAF017353; Sun, 8 Jun 2003 15:19:40 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA25838 Sun, 8 Jun 2003 17:45:28 -0400 (EDT) Message-ID: <3EE3AD34.5090600@trpz.com> Date: Sun, 08 Jun 2003 14:40:04 -0700 From: Abraham Shacham User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Barbara Fraser , ipsec@lists.tislabs.com CC: tytso@mit.edu, ippcp Subject: IPComp editorial comments (Re: Working Group Last Call IKEv2) References: <4.3.2.7.2.20030603102719.050c84c8@mira-sjc5-4.cisco.com> In-Reply-To: <4.3.2.7.2.20030603102719.050c84c8@mira-sjc5-4.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Attached please find the IPComp editorial comments for IKEv2, including in RFC editor format. Regards, avram shacham@trpz.com shacham@shacham.net (*) Footnote to the bored reader of this repeated message: The I-D is in wg last call, so at the most a single repeat is due -- during ietf last call ;-< Barbara Fraser wrote: > Hi, > > This is a working group last call for comments on the IKEv2 draft, > draft-ietf-ipsec-ikev2-08.txt, for progression to Proposed Standard: > > This last call will expire in three weeks on June 23, 2003. > > thanks, > Barb and Ted > > > -------- Original Message -------- > Subject: IKEv2-05: IPComp (editorial) comments > Date: Mon, 03 Mar 2003 00:21:59 -0800 > From: Abraham Shacham > To: IP Security List > CC: ippcp > > > s/IPcomp/IPComp/ > s/RFC 2393/RFC 3173/ > > In page 54: > > The Transform IDs currently defined are: > Name Number Defined In > RESERVED 0 > IPCOMP_OUI 1 > IPCOMP_DEFLATE 2 (RFC2394) > IPCOMP_LZS 3 (RFC2395) > > Following RFC-3051, add: > > IPCOMP_LZJH 4 (RFC3051) > > > > Thanks, > avram > === the above comments in RFC editor format === page 2: Old: 2.22 IPcomp.................................................34 New: 2.22 IPComp.................................................34 page 4: Old: match fashion. IKE can also negotiate use of IPcomp [RFC2393] in connection with an ESP and/or AH SA. We call the IKE SA an "IKE_SA". New: match fashion. IKE can also negotiate use of IPComp [RFC3173] in connection with an ESP and/or AH SA. We call the IKE SA an "IKE_SA". page 11: Old: SAs are nested, as when data (and IP headers if in tunnel mode) are encapsulated first with IPcomp, then with ESP, and finally with AH between the same pair of endpoints, all of the SAs MUST be deleted New: SAs are nested, as when data (and IP headers if in tunnel mode) are encapsulated first with IPComp, then with ESP, and finally with AH between the same pair of endpoints, all of the SAs MUST be deleted page 34: Old: 2.22 IPcomp New: 2.22 IPComp Old: implementations of this specification MUST NOT accept an IPcomp algorithm that was not proposed, MUST NOT accept more than one, and New: implementations of this specification MUST NOT accept an IPComp algorithm that was not proposed, MUST NOT accept more than one, and Old: A side effect of separating the negotiation of IPcomp from cryptographic parameters is that it is not possible to propose New: A side effect of separating the negotiation of IPComp from cryptographic parameters is that it is not possible to propose pp 65, 66: Old: IPCOMP_SUPPORTED 24581 This notification may only be included in a message containing an SA payload negotiating a CHILD_SA and indicates a willingness by its sender to use IPcomp on this SA. The data associated with this notification includes a two octet IPcomp CPI followed by a one octet transform ID optionally followed by attributes whose length and format is defined by that transform ID. A message proposing an SA may contain multiple IPCOMP_SUPPORTED notifications to indicate multiple supported algorithms. A message accepting an SA may contain at most one. The transform IDs currently defined are: NAME NUMBER DEFINED IN ----------- ------ ----------- RESERVED 0 IPCOMP_OUI 1 IPCOMP_DEFLATE 2 RFC 2394 IPCOMP_LZS 3 RFC 2395 values 4-240 are reserved to IANA. Values 241-255 are for private use among mutually consenting parties. New: IPCOMP_SUPPORTED 24581 This notification may only be included in a message containing an SA payload negotiating a CHILD_SA and indicates a willingness by its sender to use IPComp on this SA. The data associated with this notification includes a two octet IPComp CPI followed by a one octet transform ID optionally followed by attributes whose length and format is defined by that transform ID. A message proposing an SA may contain multiple IPCOMP_SUPPORTED notifications to indicate multiple supported algorithms. A message accepting an SA may contain at most one. The transform IDs currently defined are: NAME NUMBER DEFINED IN ----------- ------ ----------- RESERVED 0 IPCOMP_OUI 1 IPCOMP_DEFLATE 2 RFC 2394 IPCOMP_LZS 3 RFC 2395 IPCOMP_LZJH 4 RFC 3051 values 5-240 are reserved to IANA. Values 241-255 are for private use among mutually consenting parties. page 83: Old: IPcomp Transform IDs New: IPComp Transform IDs page 85: Old: [IPCOMP] Shacham, A., Monsour, R., Pereira, R., and Thomas, M., "IP Payload Compression Protocol (IPComp)", RFC 2393, August 1998. New: [IPCOMP] Shacham, A., Monsour, R., Pereira, R., and Thomas, M., "IP Payload Compression Protocol (IPComp)", RFC 3173, September 2001. === eom === From owner-ipsec@lists.tislabs.com Mon Jun 9 07:10:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h59EADAF082359; Mon, 9 Jun 2003 07:10:14 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28372 Mon, 9 Jun 2003 09:32:46 -0400 (EDT) Message-Id: <200306091145.HAA28659@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ikev2-algorithms-02.txt Date: Mon, 09 Jun 2003 07:45:35 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Cryptographic Algorithms for use in the Internet Key Exchange Version 2 Author(s) : J. Schiller Filename : draft-ietf-ipsec-ikev2-algorithms-02.txt Pages : 6 Date : 2003-6-6 The IPSec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE [RFC2409] and IKEv2 [IKEv2]) provide a mechanism to negotiate which algorithms should be used in any even association. However to ensure interoperability between disparate implementations it is necessary to specify a set of mandatory to implement algorithms to ensure at least one algorithm that all implementations will have available. This document defines the current set of mandatory to implement algorithms for use of IKEv2 as well as specifying algorithms that should be implemented because they made be promoted to mandatory at some future time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-algorithms-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ikev2-algorithms-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ikev2-algorithms-02.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-6133209.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ikev2-algorithms-02.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ikev2-algorithms-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-6133209.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Jun 9 07:10:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h59EAJAF082381; Mon, 9 Jun 2003 07:10:19 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28378 Mon, 9 Jun 2003 09:38:50 -0400 (EDT) Message-ID: <3EE487F1.5F3D173B@ietf.org> Date: Mon, 09 Jun 2003 09:13:21 -0400 From: Natalia Syracuse X-Mailer: Mozilla 4.51 [en] (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Barbara Fraser CC: Internet-Drafts@ietf.org, jis@mit.edu, tytso@mit.edu, ipsec@lists.tislabs.com, angelos@cs.columbia.edu Subject: Re: Problem with draft-ietf-ipsec-ikev2-algorithms-02.txt References: <4.3.2.7.2.20030606121942.04ed4dc0@mira-sjc5-4.cisco.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk ftp://ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-algorithms-02.txt. It has been received on June 6th. It has been announced on June 9th. http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-algorithms-02.txt Natalia Syracuse Barbara Fraser wrote: > > Hi, > > Re: draft-ietf-ipsec-ikev2-algorithms-02.txt > > Ted and I were looking for this draft and noticed that the link for the -02 > document on the IPsec wg page is broken. When we checked the ftp site, > there were no copies of this document at all, even the earlier -01 > version. We believe Jeff submitted the -02 document on June 3. There has > been no announcement of this draft which leads us to believe something > happened in the middle of ID's handling of this document. > > Thanks for looking into this, > Barb and Ted From owner-ipsec@lists.tislabs.com Mon Jun 9 07:44:57 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h59EiuAF084634; Mon, 9 Jun 2003 07:44:57 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA28549 Mon, 9 Jun 2003 10:16:23 -0400 (EDT) From: "Yoav Nir" To: Subject: RE: I-D ACTION:draft-ietf-ipsec-ikev2-algorithms-02.txt Date: Mon, 9 Jun 2003 17:20:51 +0200 Message-ID: <000e01c32e9a$b6ffbb00$292e1dc2@YnirNew> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <200306091145.HAA28659@ietf.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, I still see no reference to AES with 192 or 256 bits. Either we have different names and numbers (such as "ENCR_AES_256_CBC") or else we use the keylength attribute of the transform payload. In that case, I think the encryption method name should be changed to "ENCR_AES_CBC". Having only "ENCR_AES_128_CBC" does not make sense. Yoav -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Internet-Drafts@ietf.org Sent: Monday, June 09, 2003 1:46 PM To: IETF-Announce: Cc: ipsec@lists.tislabs.com Subject: I-D ACTION:draft-ietf-ipsec-ikev2-algorithms-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Cryptographic Algorithms for use in the Internet Key Exchange Version 2 Author(s) : J. Schiller Filename : draft-ietf-ipsec-ikev2-algorithms-02.txt Pages : 6 Date : 2003-6-6 The IPSec series of protocols makes use of various cryptographic algorithms in order to provide security services. The Internet Key Exchange (IKE [RFC2409] and IKEv2 [IKEv2]) provide a mechanism to negotiate which algorithms should be used in any even association. However to ensure interoperability between disparate implementations it is necessary to specify a set of mandatory to implement algorithms to ensure at least one algorithm that all implementations will have available. This document defines the current set of mandatory to implement algorithms for use of IKEv2 as well as specifying algorithms that should be implemented because they made be promoted to mandatory at some future time. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ikev2-algorithms-02.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ikev2-algorithms-02.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ikev2-algorithms-02.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. From owner-ipsec@lists.tislabs.com Mon Jun 9 08:32:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h59FWCAF088914; Mon, 9 Jun 2003 08:32:13 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28741 Mon, 9 Jun 2003 11:00:41 -0400 (EDT) Message-Id: <200306091506.h59F65of003913@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Barbara Fraser cc: ipsec@lists.tislabs.com, tytso@mit.edu Subject: Re: Working Group Last Call IKEv2 In-reply-to: Your message of Tue, 03 Jun 2003 10:32:01 PDT. <4.3.2.7.2.20030603102719.050c84c8@mira-sjc5-4.cisco.com> Date: Mon, 09 Jun 2003 17:06:05 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: I have some concerns about the current draft (08), here are the minor concerns: - in section 2.1 (retransmission) we should stress the "messages" are IKE messages, i.e., for instance one can restransmit a request using a different address in the transport header. I propose a very simple improvement, change: For every pair of messages, the Initiator is responsible for to For every pair of IKE messages, the Initiator is responsible for so the reader can refer to section 3 where IKE messages are defined. - nowhere the rule for sending response (reverse the transport stuff) is fully explained. I propose to complete section 2.11 (agility): ... An implementation MUST accept incoming connection requests even if not received from UDP port 500 or 4500, and MUST respond to the address and port from which the request was received. becomes: ... An implementation MUST accept incoming requests even if not received from UDP port 500 or 4500, and MUST respond to the address and port from which the request was received, and from the address and port to which the request was received. note that I suppressed the word "connection" as this stands for every requests. - when CHILD_SAs rekeyed with a CREATE_CHILD_SA using PFS are usable? In IKEv1 these synchro issues are handled by the infamous commit bit and the third message of quick mode... IMHO the companion draft (draft-ietf-ipsec-ikev2-tutorial-xx.txt) should give some hints. BTW I'd like to get the opinion from other implementors because the simplest solution (wait for an initiator->responder packet) is not always available... This can be an occasion to explain what SA to use in rekeying, the new one or the old one until it expires? Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Mon Jun 9 09:06:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h59G6OAF090464; Mon, 9 Jun 2003 09:06:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA28993 Mon, 9 Jun 2003 11:35:40 -0400 (EDT) Message-Id: <200306091541.h59Ff3of003997@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Barbara Fraser cc: ipsec@lists.tislabs.com, tytso@mit.edu Subject: Re: Working Group Last Call IKEv2 In-reply-to: Your message of Tue, 03 Jun 2003 10:32:01 PDT. <4.3.2.7.2.20030603102719.050c84c8@mira-sjc5-4.cisco.com> Date: Mon, 09 Jun 2003 17:41:03 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: I have some concerns about the current draft (08), here are the major concerns: - the NAT traversal facility is clearly unfinished: what is the decision about this: postpone this to another draft, give up all missing stuff, something else? Two examples of missing stuff: * the encapsulation of ESP of UDP 4500 * the implicit peer address update mechanism - the peer addresses (the addresses IKE runs over, cf 2.11) are not protected, this makes IKEv2 usable to launch DoS attacks by modifying addresses in IP headers of some packets. Initial CHILD_SA establishment can be made safe if NAT detection (i.e., NAT_DETECTION_{SOURCE,DESTINATION}_IP) is mandatory for all implementations (I can't see any problem with this and the proposed modification to the draft is very simple: put the relevant statement some lines before or after its current position). If this is accepted, we have two ways to protect the addresses of peers which are not behind a NAT: * always use the peer address of the IKE_SA_INIT messages as the address of the endpoint in any derived SA (i.e., "lock" it, the idea is from Tero Kivinen). * introduce a new notification to specify the proper peer address(es). This idea (mine) gives a better support to SCTP and similar cases but needs more work/time. Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Mon Jun 9 09:26:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h59GQuAF090906; Mon, 9 Jun 2003 09:26:57 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29164 Mon, 9 Jun 2003 12:00:38 -0400 (EDT) Message-Id: <200306091606.h59G62of004050@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipsec@lists.tislabs.com Subject: issue with "per-interface SAD/SPD" Date: Mon, 09 Jun 2003 18:06:02 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The RFC 2401 mandates (section 4.4, page 13) separate inbound and outbound databases (SAD and SPD) for each IPsec-enabled interface. This doesn't work in a dynamic environment where for instance dynamic routing makes the arrival of a packet for an address of a node possible on more than one interface in a long term, or where the peer is a mobile node. The problem exists at least in SAD lookup for incoming traffic and for SPD matching in IKE... IMHO the simplest (so the best :-) solution is to introduce an interface selector: the "firewall" properties are kept but a SPD entry can be "shared" between some interfaces. How this will be handled in the revision of RFC 2401? Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Mon Jun 9 10:09:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h59H91AF091640; Mon, 9 Jun 2003 10:09:01 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA29347 Mon, 9 Jun 2003 12:39:48 -0400 (EDT) Message-ID: <3EE4BA34.5010308@isi.edu> Date: Mon, 09 Jun 2003 09:47:48 -0700 From: Joe Touch User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030529 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Francis Dupont CC: ipsec@lists.tislabs.com Subject: Re: issue with "per-interface SAD/SPD" References: <200306091606.h59G62of004050@givry.rennes.enst-bretagne.fr> In-Reply-To: <200306091606.h59G62of004050@givry.rennes.enst-bretagne.fr> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis Dupont wrote: > The RFC 2401 mandates (section 4.4, page 13) separate inbound and > outbound databases (SAD and SPD) for each IPsec-enabled interface. > This doesn't work in a dynamic environment where for instance dynamic > routing makes the arrival of a packet for an address of a node possible > on more than one interface in a long term, or where the peer is a mobile > node. > The problem exists at least in SAD lookup for incoming traffic and for > SPD matching in IKE... IMHO the simplest (so the best :-) solution is > to introduce an interface selector: the "firewall" properties are kept > but a SPD entry can be "shared" between some interfaces. > How this will be handled in the revision of RFC 2401? > > Regards > > Francis.Dupont@enst-bretagne.fr FYI, we addressed this sort of issue in draft-touch-ipsec-vpn-05.txt, which was submitted independently as an Informational in April. Introducing an interface selector is insufficient; the selector needs to indicate the next-hop IP address and interface, as both are required for IP forwarding. The details of this issue, and simpler alternatives are discussed in the draft. Joe From owner-ipsec@lists.tislabs.com Mon Jun 9 12:37:41 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h59JbeAF001741; Mon, 9 Jun 2003 12:37:40 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA29939 Mon, 9 Jun 2003 15:05:39 -0400 (EDT) Date: Mon, 9 Jun 2003 13:11:27 -0600 Message-Id: <200306091911.h59JBRS09976@localhost.localdomain> From: "The Purple Streak, Hilarie Orman" To: jshriver+ietf@sockeye.com Cc: byfraser@cisco.com, ipsec@lists.tislabs.com, paul.hoffman@vpnc.org, housley@vigilsec.com, heard@pobox.com, lsanchez@xapiens.com, bwijnen@lucent.com, angelos@cs.columbia.edu, tytso@mit.edu, wes@hardakers.net In-reply-to: Yourmessage <3EE490E7.8080101@sockeye.com> Subject: Re: draft-ietf-ipsec-doi-tc-mib-07.txt and friends Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Wes Hardaker has had implementations that use this, and he has made similar changes to his IPSP MIB document in order to appease the MIB powers. You and Wes should coordinate changes and resubmit ASAP. Hilarie > Date: Mon, 09 Jun 2003 09:51:35 -0400 > From: John Shriver > Organization: Sockeye Networks > > Hi John, > > > > Ted and I have been, once again, digging back into the status of 5 of > > the MIB documents and would like to see us once and for all get these > > documents put to bed. We've seen and read the thread concerning > > draft-ietf-ipsec-doi-tc-mib-07.txt. Everything seems to have come to a > > halt after Mike Heard posted his summary MIB doctor comments on April > > 28. This document is referenced in the an IPSP document so we need to > > somehow resolve the issues surrounding it, which is why there is such a > > wide distribution on this message. First question is, are you willing > > to continue to work on this document as the editor? > Absolutely. The problem is that we lack a consensus on what to do about > Mike Heard's comments. Honestly, nobody but Mike and I appear to give a > darn, at least on the IPsec mailing list! Even if I do decide to agree > with the change from enumerations to simple typedefs, is an agreement of > two people out of the entire IPsec list really a consensus? Maybe it > is, in the absence of any dissenting opinion! > Myself, I think the MIB is far more useful if we ignore Mike's comments. > But, realistically, it would _never_ get through last call, and it > would be futile to proceeed in that direction. > > Second, it seems > > there has been some difference of opinion between you and Mike. One > > comment made was that some of the difficulties arose from this document > > being looked at in isolation of the other related documents. This brings > > me to a question. Every time Ted and I have asked if anyone is > > implementing these MIBs, there has been total silence leading us to > > believe nobody is implementing them. > I suspect that nobody is implementing the related MIBs. I may remember > one vendor implementing the drafts, but I wouldn't be surprised if > they've been swept away by the dot-com meltdown of the last two years. > > Paul Hoffman has kindly resubmitted > > draft-ietf-ipsec-ike-monitor-mib-04.txt, > > draft-ietf-ipsec-isakmp-di-mon-mib-05.txt, and > > draft-ietf-ipsec-monitor-mib-06.txt for us in the new format, and if he, > > or someone else is willing to take them on, we could continue to > > progress all of them. > I think that IKEv2 is rendering much of the content of these MIBs as > obsolete. Plus the competiting IPsec Flow Monitoring MIB effort from > Cisco & Tivoli people, which has the advantadge of being implemented. > (You can't get through the standards track without implementations...) > Hopefully the folks authoring the Flow Monitoring MIB will continue to > pick up some of the good points from the earlier set of MIBs, I will > concede that later versions were improved. But I've seen little > standards effort there, they may have decided to abandon the standards > track, and just publish the MIBs under their trees? > > If that's what folks want to do. On the other > > hand, we could also choose to progress only the document that Hilary's > > group needs and drop the other three due to lack of > > interest/implementation. It's also fair to remind folks that these are > > all IKEv1 MIB docs. > > > > All this boils down to the following: > > 1. Are you willing to continue to edit draft-ietf-ipsec-doi-tc-mib-07.txt? > Yes. > > 2. We need to come to agreement on what changes are needed, that is we > > must address the MIB doctor comments. > Well, I can make the changes from enumerations to simple typedefs. The > real question is whether the IPSP folks are still interested in using > this MIB if it doesn't have the enumerations in it. To me, that was the > primary value of the MIB, and why I convinced Tim to let me do it. He > was just exporting the variables as INTEGERs, which I found unfriendly. > At least with any of the tools inheriting from the CMU ones, the > enumerations are much more useful. > So, IPSP folks (you are on the CC: list, right?), do you still want this > MIB without the enumerations? If so, I'll make Mike's changes, and ship > it out again. > > 3. Are we going to continue to support > > draft-ietf-ipsec-ike-monitor-mib-04.txt, > > draft-ietf-ipsec-isakmp-di-mon-mib-05.txt, and > > draft-ietf-ipsec-monitor-mib-06.txt? > I think we can let them die, unless someone someone is wanting them. > > If so, who's willing to take on the > > document editor job? And, more importantly, how do we decide what > > changes are needed to them. > > > > I feel like we're living in Groundhog Day with these MIB docs. We keep > > living the same thing over and over. Let's please get to the end :-) > Yeah, it would have been _easier_ if there had been some controversy, > rather than stunning silence all the way... > > > > thanks, > > Barb and Ted From owner-ipsec@lists.tislabs.com Mon Jun 9 15:39:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h59MdjAF007754; Mon, 9 Jun 2003 15:39:48 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA00402 Mon, 9 Jun 2003 18:10:55 -0400 (EDT) Date: Tue, 10 Jun 2003 01:16:47 +0300 (IDT) From: Hugo Krawczyk To: Uri Blumenthal cc: "Theodore Ts'o" , David Blaker , IPsec WG Subject: Re: Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96 from SHOULD to SHOULD+ In-Reply-To: <3EE10F4A.7000303@bell-labs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 6 Jun 2003, Uri Blumenthal wrote: > I'd volunteer, since I've been working on the thing (on and off) > for a while now. But as the discussion demonstrated, it's not as > simple - if you want to use that PRF in IKEv2. Uri, I see no need for further I-D's. As I said in a recent message all is needed is a pointer to the AES-XCBC-MAC draft for the definition of what ikev2 calls PRF_AES128_CBC. All other issues regarding the use of prf are taken care by the ikev2 draft itself. In particular, the draft completely specifies the use of prf's whether with variable length key (such as HMAC-SHA) or fixed length key (such as aes128-cbc). The only prf's that are defined as MUST NOT USE are those whose output is shorter than the key itself (such as 3DES). All other discussions regarding prf use in ikev2 were resolved and reflected in the ikev2 draft. Hugo > > > Theodore Ts'o wrote: > > On Wed, Jun 04, 2003 at 12:47:57PM -0400, David Blaker wrote: > > > >>Although I have seen discussions of using AES for a PRF function on > >>the IPSec mailing list, I am unaware of a formal definition that is > >>documented in a draft. draft-ietf-ipsec-ciph-aes-cbs-05.txt makes no > >>mention of a prf function, as far as I can tell. If PRF_AES128_CBC > >>is to be either a SHOULD or a SHOULD+, then someone first needs to > >>define it somewhere. Would one of the proposers of this algorithm please > >>provide a draft? > > > > > > Good catch. It appears that ikev2-algorithms-01 is in error: > > PRF_AES128_CBC is not defined in draft-ietf-ipsec-aes-cbc-05, and I > > don't see any drafts where it is defined. So we need to modify > > ikev2-algorithms to point at a (currently non-existent) I-D, and we > > need to find a volunteer to quickly gin up an I-D which defines > > PRF_AES128_CBC. > > > > Barbara and I believe that this shouldn't hold up the IETF last call > > for draft-ietf-ipsec-algorithms, since writing up this PRF AES I-D > > should be something that can be done quickly, however, with the > > dangling reference the algorithms document will stall when it hits the > > RFC editor, so we will need to plug this reference quickly. > From owner-ipsec@lists.tislabs.com Mon Jun 9 16:44:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h59NiKAF010431; Mon, 9 Jun 2003 16:44:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA00640 Mon, 9 Jun 2003 19:14:27 -0400 (EDT) Date: Tue, 10 Jun 2003 02:20:33 +0300 (IDT) From: Hugo Krawczyk To: Uri Blumenthal cc: IPsec WG Subject: Re: Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96 from SHOULD to SHOULD+ In-Reply-To: <3EE5100E.3020608@bell-labs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 9 Jun 2003, Uri Blumenthal wrote: > Hugo Krawczyk wrote: > >>I'd volunteer, since I've been working on the thing (on and off) > >>for a while now. But as the discussion demonstrated, it's not as > >>simple - if you want to use that PRF in IKEv2. > > > > I see no need for further I-D's. As I said in a recent message all is > > needed is a pointer to the AES-XCBC-MAC draft for the definition of what > > ikev2 calls PRF_AES128_CBC. All other issues regarding the use of prf are > > taken care by the ikev2 draft itself. > > Respectfully disagree. care to explain? > > > In particular, the draft completely > > specifies the use of prf's whether with variable length key (such as > > HMAC-SHA) or fixed length key (such as aes128-cbc). > > Except for how to construct a pure AES-based PRF. what do you mean by "pure AES-based PRF"? Isnt AES-XCBC a pure AES-based prf? Hugo From owner-ipsec@lists.tislabs.com Mon Jun 9 18:12:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5A1CoAF013552; Mon, 9 Jun 2003 18:12:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA00938 Mon, 9 Jun 2003 20:42:59 -0400 (EDT) Message-ID: <3EE52B65.803@airespace.com> Date: Mon, 09 Jun 2003 17:50:45 -0700 From: "Scott G. Kelly" Organization: Airespace User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 CC: ipsec@lists.tislabs.com Subject: Identity protection [Re: Working Group Last Call IKEv2] References: <4.3.2.7.2.20030603102719.050c84c8@mira-sjc5-4.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jun 2003 00:48:28.0888 (UTC) FILETIME=[02185580:01C32EEA] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I want to formally raise the issue of identity protection once again, now that we are in last call. This has been referred to by Hannes and Hugo in recent posts, and was discussed previously here. I don't think anyone will disagree that identity protection is useful in remote access scenarios for a number of reasons. In such cases, the identity of the SGW might often be obvious based on its use of a fixed IP address, but the identity of the initiator need not be. In weighing the usefulness of adding identity protection, we might consider how difficult it is to see the packets en route against what benefit an attacker might derive from knowledge of the identity, and also against the cost of securing this information. In many remote access scenarios, gaining access to packets containing identities is not a simple thing - the cost to the attacker is not insignificant. And the derived information does not provide a direct advantage - it is only one piece of the puzzle, and in general, significantly more work is required to take advantage of it. I think that for these reasons, some folks may feel that this protecting the intiator identity is not that important. Wireless network access is very much like remote access, and IPsec is sometimes used to secure such access. However, note that in a large number of wlan deployment scenarios, gaining access to the packets containing the identity is often straightforward, or even trivial. That is, the cost is significantly less than in the wired case. This changes the cost-benefit analysis considerably. For this reason, I think we should reconsider this. I think identity protection is a *very* important feature, and that IKEv2 should support it. Scott Barbara Fraser wrote: > Hi, > > This is a working group last call for comments on the IKEv2 draft, > draft-ietf-ipsec-ikev2-08.txt, for progression to Proposed Standard: > > This last call will expire in three weeks on June 23, 2003. > > thanks, > Barb and Ted > From owner-ipsec@lists.tislabs.com Mon Jun 9 21:13:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5A4D4AF018061; Mon, 9 Jun 2003 21:13:05 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA01424 Mon, 9 Jun 2003 23:43:37 -0400 (EDT) Mime-Version: 1.0 X-Sender: kseo@po2.bbn.com Message-Id: In-Reply-To: <200306091606.h59G62of004050@givry.rennes.enst-bretagne.fr> References: <200306091606.h59G62of004050@givry.rennes.enst-bretagne.fr> Date: Mon, 9 Jun 2003 23:49:39 -0400 To: Francis Dupont From: Karen Seo Subject: Re: issue with "per-interface SAD/SPD" Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Francis, I see your point but am not sure how Steve (Kent) would propose to address this. He's on vacation until 6/17. So I just wanted to let you know that we'll get back to you as soon as he returns (and has a chance to plow through his email backlog :-).) Karen >The RFC 2401 mandates (section 4.4, page 13) separate inbound and >outbound databases (SAD and SPD) for each IPsec-enabled interface. >This doesn't work in a dynamic environment where for instance dynamic >routing makes the arrival of a packet for an address of a node possible >on more than one interface in a long term, or where the peer is a mobile >node. >The problem exists at least in SAD lookup for incoming traffic and for >SPD matching in IKE... IMHO the simplest (so the best :-) solution is >to introduce an interface selector: the "firewall" properties are kept >but a SPD entry can be "shared" between some interfaces. >How this will be handled in the revision of RFC 2401? > >Regards > >Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Jun 10 10:22:11 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5AHMAAF085008; Tue, 10 Jun 2003 10:22:11 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03687 Tue, 10 Jun 2003 12:39:25 -0400 (EDT) Date: Tue, 10 Jun 2003 19:45:33 +0300 (IDT) From: Hugo Krawczyk To: Uri Blumenthal cc: IPsec WG Subject: Re: Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96 from SHOULD to SHOULD+ In-Reply-To: <3EE53648.3090608@bell-labs.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk OK. I see now what you mean. Your phrasing of the question via "pure AES-based prf" confused me. What you are actually asking is whether the uses of prf in IKE are "provably secure" on the sole assumption that the prf function is a pseudorandom function (or, to be more precise, a function randomly chosen from a family of pseudorandom functions) under the standard definition of such functions. There are two answers to this question: yes and no. More specifically: the function "prf" in IKE has several uses: (1) to derive SKEYSEED from the DH value g^ir (2) to derive further keys (Ka, Kd, Ke, for the IKE-SA and KEYMAT for the ipsec algorithms) from SKEYSEED (3) as an integrity algorithm for the IKE-SA (including the essential MAC on the signer's identity in the SIGMA design) and for the CHILD-SA. Uses (2) and (3) (and, in general, the use of prf+) are provably secure on the sole assumption that prf is a pseudorandom function. Use (1) is the one you are referrinfg to below, and the answr to it is NO. That is, if all you assume on prf is that it is a pseudorandom function then you cannot conclude that SKEYSEED is indistinguishable from random. Indeed, I can show a family of pseudorandom functions (especially constructed to serve as a counter-example) under which SKEYSEED is distinguishable from random. The reason for this, as you note, is the use of a prf with random but non-secret key. This is a heuristic use of prf that I introduced for use in IKEv1 and about which I wrote several times (during the last 6 years) to this list. The idea is to use the prf family with random-but-known keys as a universal hash (UH) family and then to apply the so-called "leftover hash lemma". The right (in the sense of provability) design would have been to use an explicit UH function for this. However, I did not think that the introduction of a completely new transform to IKE would have been warmly welcome (to say the least). Moreover, this is one of the places where I personally believe that the engineering considerations outweigh the pure analytic considerations. Basically, I believe that any reasonable prf family will have enough statistical strength as to serve as a good replacement for UH for the sake of "extracting the computational randomness" from a DH key. I can only wish this to be the "weakest link" in all the cryptography of ike. Note, btw, that while we need SKEYSEED to be indistinguishable from random, ,the "distinguishing game" here is far more restricted for the attacker than in classic uses of prf's: in particular, the attacker never gets to see the output SKEYSEED of the prf but (at most) the output of prf(SKEYSEED,...). If you want a more academic analytical point of view, then one can phrase an explicit assumption on the prf family that will ensure the security of its use in (1). This, with the DDH assumption on the DH group used in IKE, will give you the required analytical assurance. While these assumptions on prf do not hold for all pseudorandom families, I expect them to occur in specific families such as AES (as long, of course, as no new serious cryptanalytical weaknesses on AES are discovered). I will not add more here about the technicalities involving these assumptions since this would get far more technical andacademic than this list deserves. Moreover, the full analytical details are still "work in progress" that will hopefully be published in the not-too-far future. One last thing on this issue: I do not believe (in particular based on the counter-examples I mentioned above) that one will be able to come with a use of prf's for "extracting randomness" a la UH which will be based SOLELY on the pseudorandomness assumption. I will be happy (and surprised) to see this done. Finally, regarding the "belt and suspenders" approach you mention below, there is a simple way to realize it in ike: when deriving SKEYSEED, XOR to the result of the prf the n upper bits of the DH value (n being the output length of prf). If these DH bits are distributed uniformly (as more or less expected via DDH) then you have "provable security". I have not suggested that in the past since it seems to me really unnecessary (moreover, since the DH value is not really uniformly distributed in the strings of length |p| then even if DDH holds this is not a purely provable condition). BTW, note that in ike's standarized DH groups the DDH assumption does NOT hold, since the generator is NOT of prime order. There is more to be said about this but again this is not the right technical forum for it. Hugo PS: Your feelings (expressed below) that using SHA1 directly or HMAC make the use of the prf in ike better justified is, in my opinion, incorrect. All the above reservations on the analytical strength of this use apply equaly to these other functions (not just to block ciphers). In particular, it is NOT the case that in SHA1 or HMAC the positioning of the key vs input is immaterial (not even if you assume the compression functions to behave as idealized "random oracles"). In some sense the main contribution of HMAC is in telling you how to position these bits to get provable guarantees. On Mon, 9 Jun 2003, Uri Blumenthal wrote: > Hugo Krawczyk wrote: > >>> I see no need for further I-D's. As I said in a recent message all > >>> is needed is a pointer to the AES-XCBC-MAC draft for the definition > >>> of what ikev2 calls PRF_AES128_CBC. All other issues regarding the > >>> use of prf are taken care by the ikev2 draft itself. > >> > >> Respectfully disagree. > > > > care to explain? > > Of course. > > First - a fundamental question. The draft (page 26, section 2.14) uses > Ni | Nr as a key to PRF, and g^ir as data. I understand that for an > essentially keyless function like SHA1 (and HMAC) it doesn't really > matter in what sequence to grok the inputs. However when you use a > keyed algorithm (such as AES), then doesn't it matter what data > (and of what randomness and secrecy) you use as a key, and > what - as a plaintext to crunch? > > Second, as far as I know, all the security proofs around block > ciphers are assuming that the key is secret. If one is using > AES-XCBC-MAC as PRF, following section 2.14 (page 26), then > the key is known. What kind of security proofs are you > getting? How secure is XCBC-MAC with a known key? > > Third, in our public discussion with David Wagner and Ran Canetti, > David mentioned the "belt and suspenders" approach: a semi-provable > PRF, based on the assumption that as long as EITHER Decisional > Diffie-Hellman holds OR hmac behaves as a random oracle - the > PRF constructed of hmac is secure. What assumptions are > taken with AES-XCBC-MAC used as PRF? > > > >>> In particular, the draft completely specifies the use of prf's > >>> whether with variable length key (such as HMAC-SHA) or fixed > >>> length key (such as aes128-cbc). > >> > >> Except for how to construct a pure AES-based PRF. > > > > what do you mean by "pure AES-based PRF"? Isnt AES-XCBC > > a pure AES-based prf? > > In my understanding, it is "pure AES-based", but under the > assumptions I see in the draft - not necessarily a PRF due > to its key being publicly known. > > > Uri. > > From owner-ipsec@lists.tislabs.com Tue Jun 10 10:22:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5AHMBAF085014; Tue, 10 Jun 2003 10:22:15 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03713 Tue, 10 Jun 2003 12:46:29 -0400 (EDT) Date: Tue, 10 Jun 2003 19:52:37 +0300 (IDT) From: Hugo Krawczyk To: Tschofenig Hannes cc: "'ipsec@lists.tislabs.com'" Subject: RE: Question regarding user identity confidentiality In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F036760C2@mchp905a.mch.sbs.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk You are right that the solution you propose achieves user's id protection, and that it is trivial to specify this solution given the current text. However, it is also true that this adds a round-trip to the protocol. It seemed from the discussion in the past on this issue that people did not consider this as a justified trade-off between privacy and communication latency. In any case, I believe that the WG made a decision here. One that I do not like but certainly not one that can be blamed on people not paying attention. If you want to support the review of this issue during last call you should support Scott Kelly's recent motion in this regard. (Having said the above, I am quite sure that if this issue would have brought to a "show of hands" in an ipsec meeting there would have been majority to the identity protection measure -- provided that someone presented the options and their trade-offs in that same meeting). Hugo On Tue, 10 Jun 2003, Tschofenig Hannes wrote: > hi hugo, > > thank you for your quick response. > > > Hannes, > > > > You are late to this party... > > i know. sorry about it. > > > This issue has been discussed in a couple of threads in this list > > (the last of which took place in March and carried the subject > > "Do ipsec vendors care about privacy?"). > > i roughly followed the discussions. i will, however, look at them again. > > to provide the required protection only a single sentence needs to be > changed - no modification to ikev2 itself. > > the following sentence in section 3.16 should be changed (particularly the > should not part): > > "Note that since IKE passes an indication of initiator identity in message 3 > of the protocol, EAP based prompts for Identity SHOULD NOT be used." > > if user identity conf. is required then the initiator would not provide its > user identity with message 3. instead the eap-request/identity is > transmitted by the responder in message 4. message 4 authenticates the > responder to the initiator. the identity of the client is subsequently > provided with message 5 as part of the eap-response/identity message. > > using this procedure the client is can enable user identity confidentiality > only if required. > > what do you think? > > ciao > hannes > > > > This represented my failed attempt to get the WG to decide on > > what seems > > as the obvious requirement to protect the user's id in the > > EAP exchange. > > Even the "provocative" subject of the thread (and the > > positive answer to > > that question given by several ipsec vendors) was > > insufficient to market > > the idea. If you read the thread you'll see some people claiming that > > doing so would add significant complexity to the protocol. I > > do not agree. > > I have the feeling that a silent majority would have supported this, > > but that's how silent majorities work, they remain silent... :) > > > > Hugo > > > > > > > > On Fri, 6 Jun 2003, Tschofenig Hannes wrote: > > > > > hi all, > > > > > > i have read the ikev2 tuturial and ikev2 and i have a > > question about the > > > user identity confidentiality: > > > > > > before secure legacy authentication was added to ikev2 i > > agreed with the > > > selected user id confidentiality approach where the identity of the > > > initiator is revealed first. at that time it is was > > difficult to assume a > > > client-server architecture (i.e. which entity starts ike) > > and therefore > > > which entity has to be protected. > > > > > > for remote access solutions using secure legacy > > authentication (by using > > > eap) things are a little bit different. > > > > > > with eap you have the following message flow (taken from > > section 3.16 of > > > [draft-ietf-ipsec-ikev2-08.txt]): > > > > > > Initiator Responder > > > ----------- ----------- > > > HDR, SAi1, KEi, Ni --> > > > > > > <-- HDR, SAr1, KEr, > > Nr, [CERTREQ] > > > > > > HDR, SK {IDi, [CERTREQ,] [IDr,] > > > SAi2, TSi, TSr} --> > > > > > > <-- HDR, SK {IDr, [CERT,] AUTH, > > > EAP } > > > > > > HDR, SK {EAP, [AUTH] } --> > > > > > > The draft says "By including an IDi payload but not an AUTH > > payload, the > > > initiator has declared an identity but has not proven it." > > (message 3) > > > > > > Section 3.16 additionally says: "Note that since IKE passes > > an indication of > > > initiator identity in message 3 of the protocol, EAP based > > prompts for > > > Identity SHOULD NOT be used." > > > > > > To me this seems that protection of the user identity > > against an active > > > attack cannot be provided for eap methods (except if > > tunneled methods are > > > used). this seems to have some disadvantages for remote > > access solutions > > > where you have a client-server relationship. > > > > > > possible solutions are: > > > > > > a) ignore user id conf. > > > b) suggest to use a tunneled method within ikev2/eap when > > user identity > > > confidentiality is required. this clearly has a performance > > disadvantage > > > since you create two tunnels (for server to client > > authentication) in > > > addition to the eap method for client to server authentication. > > > c) change the handling for secure legacy auth. and let the responder > > > authenticate to the initiator first > > > d) others? > > > > > > am i wrong with my observations? > > > > > > ciao > > > hannes > > > > > > > > From owner-ipsec@lists.tislabs.com Tue Jun 10 10:26:25 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5AHQLAF085088; Tue, 10 Jun 2003 10:26:24 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03790 Tue, 10 Jun 2003 12:55:58 -0400 (EDT) Date: 9 Jun 2003 13:37:48 -0000 Message-ID: <20030609133748.30437.qmail@webmail7.rediffmail.com> MIME-Version: 1.0 From: "praveen kumar vemula" Reply-To: "praveen kumar vemula" To: ipsec@lists.tislabs.com Subject: IPSec NAT Pass thorugh .. Content-type: text/plain; format=flowed Content-Disposition: inline Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi all, i doing study on IPSec NAT pass though . in IPSec automatic key negotiation using IKE ( Main mode) , negotiating packets will be carrying peers IP Address. when it has to pass through NAT , surely it will fail at the other end, as ip address get translated . (please correct if my understanding is wrong) so, for SA estabilishment in main mode we have to use identification other than ip address, like domain name , email id .. is there any free softwares, or well known vendors have implemnation with this . i tired using windows 2000, looks like it not supporting .. any inputs for this mail will be great helpful .. thanks in advance , Praveen ___________________________________________________ Impress your clients! Send mail from me @ mycompany.com . Just Rs.1499/year. Click http://www.rediffmailpro.com to know more. From owner-ipsec@lists.tislabs.com Tue Jun 10 10:26:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5AHQwAF085108; Tue, 10 Jun 2003 10:26:58 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03797 Tue, 10 Jun 2003 12:56:58 -0400 (EDT) Message-ID: <3EE490E7.8080101@sockeye.com> Date: Mon, 09 Jun 2003 09:51:35 -0400 From: John Shriver Organization: Sockeye Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Barbara Fraser CC: John Shriver , tytso@mit.edu, angelos@cs.columbia.edu, Bert Wijnen , "Hilarie Orman, Purple Streak Development" , Luis Sanchez , "C. M. Heard" , Russ Housley , Paul Hoffman / VPNC , ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-doi-tc-mib-07.txt and friends References: <4.3.2.7.2.20030606162749.04395f00@mira-sjc5-4.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Barbara Fraser wrote: > Hi John, > > Ted and I have been, once again, digging back into the status of 5 of > the MIB documents and would like to see us once and for all get these > documents put to bed. We've seen and read the thread concerning > draft-ietf-ipsec-doi-tc-mib-07.txt. Everything seems to have come to a > halt after Mike Heard posted his summary MIB doctor comments on April > 28. This document is referenced in the an IPSP document so we need to > somehow resolve the issues surrounding it, which is why there is such a > wide distribution on this message. First question is, are you willing > to continue to work on this document as the editor? Absolutely. The problem is that we lack a consensus on what to do about Mike Heard's comments. Honestly, nobody but Mike and I appear to give a darn, at least on the IPsec mailing list! Even if I do decide to agree with the change from enumerations to simple typedefs, is an agreement of two people out of the entire IPsec list really a consensus? Maybe it is, in the absence of any dissenting opinion! Myself, I think the MIB is far more useful if we ignore Mike's comments. But, realistically, it would _never_ get through last call, and it would be futile to proceeed in that direction. > Second, it seems > there has been some difference of opinion between you and Mike. One > comment made was that some of the difficulties arose from this document > being looked at in isolation of the other related documents. This brings > me to a question. Every time Ted and I have asked if anyone is > implementing these MIBs, there has been total silence leading us to > believe nobody is implementing them. I suspect that nobody is implementing the related MIBs. I may remember one vendor implementing the drafts, but I wouldn't be surprised if they've been swept away by the dot-com meltdown of the last two years. > Paul Hoffman has kindly resubmitted > draft-ietf-ipsec-ike-monitor-mib-04.txt, > draft-ietf-ipsec-isakmp-di-mon-mib-05.txt, and > draft-ietf-ipsec-monitor-mib-06.txt for us in the new format, and if he, > or someone else is willing to take them on, we could continue to > progress all of them. I think that IKEv2 is rendering much of the content of these MIBs as obsolete. Plus the competiting IPsec Flow Monitoring MIB effort from Cisco & Tivoli people, which has the advantadge of being implemented. (You can't get through the standards track without implementations...) Hopefully the folks authoring the Flow Monitoring MIB will continue to pick up some of the good points from the earlier set of MIBs, I will concede that later versions were improved. But I've seen little standards effort there, they may have decided to abandon the standards track, and just publish the MIBs under their trees? > If that's what folks want to do. On the other > hand, we could also choose to progress only the document that Hilary's > group needs and drop the other three due to lack of > interest/implementation. It's also fair to remind folks that these are > all IKEv1 MIB docs. > > All this boils down to the following: > 1. Are you willing to continue to edit draft-ietf-ipsec-doi-tc-mib-07.txt? Yes. > 2. We need to come to agreement on what changes are needed, that is we > must address the MIB doctor comments. Well, I can make the changes from enumerations to simple typedefs. The real question is whether the IPSP folks are still interested in using this MIB if it doesn't have the enumerations in it. To me, that was the primary value of the MIB, and why I convinced Tim to let me do it. He was just exporting the variables as INTEGERs, which I found unfriendly. At least with any of the tools inheriting from the CMU ones, the enumerations are much more useful. So, IPSP folks (you are on the CC: list, right?), do you still want this MIB without the enumerations? If so, I'll make Mike's changes, and ship it out again. > 3. Are we going to continue to support > draft-ietf-ipsec-ike-monitor-mib-04.txt, > draft-ietf-ipsec-isakmp-di-mon-mib-05.txt, and > draft-ietf-ipsec-monitor-mib-06.txt? I think we can let them die, unless someone someone is wanting them. > If so, who's willing to take on the > document editor job? And, more importantly, how do we decide what > changes are needed to them. > > I feel like we're living in Groundhog Day with these MIB docs. We keep > living the same thing over and over. Let's please get to the end :-) Yeah, it would have been _easier_ if there had been some controversy, rather than stunning silence all the way... > > thanks, > Barb and Ted From owner-ipsec@lists.tislabs.com Tue Jun 10 10:28:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5AHSLAF085184; Tue, 10 Jun 2003 10:28:22 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03806 Tue, 10 Jun 2003 12:57:59 -0400 (EDT) Cc: "Theodore Ts'o" , David Blaker , IPsec WG Message-ID: <3EE5100E.3020608@bell-labs.com> Date: Mon, 09 Jun 2003 18:54:06 -0400 From: Uri Blumenthal Organization: Lucent Tehcnologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en, zh-cn, ru, de, he MIME-Version: 1.0 To: Hugo Krawczyk Original-CC: "Theodore Ts'o" , David Blaker , IPsec WG Subject: Re: Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96 from SHOULD to SHOULD+ References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo Krawczyk wrote: >>I'd volunteer, since I've been working on the thing (on and off) >>for a while now. But as the discussion demonstrated, it's not as >>simple - if you want to use that PRF in IKEv2. > > I see no need for further I-D's. As I said in a recent message all is > needed is a pointer to the AES-XCBC-MAC draft for the definition of what > ikev2 calls PRF_AES128_CBC. All other issues regarding the use of prf are > taken care by the ikev2 draft itself. Respectfully disagree. > In particular, the draft completely > specifies the use of prf's whether with variable length key (such as > HMAC-SHA) or fixed length key (such as aes128-cbc). Except for how to construct a pure AES-based PRF. I understand that HMAC is good, but for some application is may be preferred to stay within one algorithm (AES). From owner-ipsec@lists.tislabs.com Tue Jun 10 10:36:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5AHaNAF085418; Tue, 10 Jun 2003 10:36:23 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03833 Tue, 10 Jun 2003 12:59:02 -0400 (EDT) Cc: IPsec WG Message-ID: <3EE53648.3090608@bell-labs.com> Date: Mon, 09 Jun 2003 21:37:12 -0400 From: Uri Blumenthal Organization: Lucent Tehcnologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en, zh-cn, ru, de, he MIME-Version: 1.0 To: Hugo Krawczyk Original-CC: IPsec WG Subject: Re: Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96 from SHOULD to SHOULD+ References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hugo Krawczyk wrote: >>> I see no need for further I-D's. As I said in a recent message all >>> is needed is a pointer to the AES-XCBC-MAC draft for the definition >>> of what ikev2 calls PRF_AES128_CBC. All other issues regarding the >>> use of prf are taken care by the ikev2 draft itself. >> >> Respectfully disagree. > > care to explain? Of course. First - a fundamental question. The draft (page 26, section 2.14) uses Ni | Nr as a key to PRF, and g^ir as data. I understand that for an essentially keyless function like SHA1 (and HMAC) it doesn't really matter in what sequence to grok the inputs. However when you use a keyed algorithm (such as AES), then doesn't it matter what data (and of what randomness and secrecy) you use as a key, and what - as a plaintext to crunch? Second, as far as I know, all the security proofs around block ciphers are assuming that the key is secret. If one is using AES-XCBC-MAC as PRF, following section 2.14 (page 26), then the key is known. What kind of security proofs are you getting? How secure is XCBC-MAC with a known key? Third, in our public discussion with David Wagner and Ran Canetti, David mentioned the "belt and suspenders" approach: a semi-provable PRF, based on the assumption that as long as EITHER Decisional Diffie-Hellman holds OR hmac behaves as a random oracle - the PRF constructed of hmac is secure. What assumptions are taken with AES-XCBC-MAC used as PRF? >>> In particular, the draft completely specifies the use of prf's >>> whether with variable length key (such as HMAC-SHA) or fixed >>> length key (such as aes128-cbc). >> >> Except for how to construct a pure AES-based PRF. > > what do you mean by "pure AES-based PRF"? Isnt AES-XCBC > a pure AES-based prf? In my understanding, it is "pure AES-based", but under the assumptions I see in the draft - not necessarily a PRF due to its key being publicly known. Uri. From owner-ipsec@lists.tislabs.com Tue Jun 10 10:36:31 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5AHaUAF085432; Tue, 10 Jun 2003 10:36:31 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03832 Tue, 10 Jun 2003 12:59:00 -0400 (EDT) Message-ID: <3EE53750.7000801@bell-labs.com> Date: Mon, 09 Jun 2003 21:41:36 -0400 From: Uri Blumenthal Organization: Lucent Tehcnologies / Bell Labs User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en, zh-cn, ru, de, he MIME-Version: 1.0 To: IPsec WG Subject: ikev2-08 last nit Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, Here's a nit I stumbled upon. Page 24 section 2.10 says that nonces must be at least 128 bits in size and at least half the size of the key of the negotiated PRF. That's fine. But on page 60, last paragraph before section 3.10, it says that the length of the nonce must be between 8 and 256 octets. So are nonces of 64 bits allowed (as per page 60) or forbidden (as per page 24)? The fix probably is to change the text on page 60 to "between 16 and 256 octets". Regards, Uri. From owner-ipsec@lists.tislabs.com Tue Jun 10 10:38:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5AHc4AF085479; Tue, 10 Jun 2003 10:38:06 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03845 Tue, 10 Jun 2003 13:00:01 -0400 (EDT) Message-ID: <2A8DB02E3018D411901B009027FD3A3F036760C2@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Hugo Krawczyk'" Cc: "'ipsec@lists.tislabs.com'" Subject: RE: Question regarding user identity confidentiality Date: Tue, 10 Jun 2003 16:13:20 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi hugo, thank you for your quick response. > Hannes, > > You are late to this party... i know. sorry about it. > This issue has been discussed in a couple of threads in this list > (the last of which took place in March and carried the subject > "Do ipsec vendors care about privacy?"). i roughly followed the discussions. i will, however, look at them again. to provide the required protection only a single sentence needs to be changed - no modification to ikev2 itself. the following sentence in section 3.16 should be changed (particularly the should not part): "Note that since IKE passes an indication of initiator identity in message 3 of the protocol, EAP based prompts for Identity SHOULD NOT be used." if user identity conf. is required then the initiator would not provide its user identity with message 3. instead the eap-request/identity is transmitted by the responder in message 4. message 4 authenticates the responder to the initiator. the identity of the client is subsequently provided with message 5 as part of the eap-response/identity message. using this procedure the client is can enable user identity confidentiality only if required. what do you think? ciao hannes > This represented my failed attempt to get the WG to decide on > what seems > as the obvious requirement to protect the user's id in the > EAP exchange. > Even the "provocative" subject of the thread (and the > positive answer to > that question given by several ipsec vendors) was > insufficient to market > the idea. If you read the thread you'll see some people claiming that > doing so would add significant complexity to the protocol. I > do not agree. > I have the feeling that a silent majority would have supported this, > but that's how silent majorities work, they remain silent... :) > > Hugo > > > > On Fri, 6 Jun 2003, Tschofenig Hannes wrote: > > > hi all, > > > > i have read the ikev2 tuturial and ikev2 and i have a > question about the > > user identity confidentiality: > > > > before secure legacy authentication was added to ikev2 i > agreed with the > > selected user id confidentiality approach where the identity of the > > initiator is revealed first. at that time it is was > difficult to assume a > > client-server architecture (i.e. which entity starts ike) > and therefore > > which entity has to be protected. > > > > for remote access solutions using secure legacy > authentication (by using > > eap) things are a little bit different. > > > > with eap you have the following message flow (taken from > section 3.16 of > > [draft-ietf-ipsec-ikev2-08.txt]): > > > > Initiator Responder > > ----------- ----------- > > HDR, SAi1, KEi, Ni --> > > > > <-- HDR, SAr1, KEr, > Nr, [CERTREQ] > > > > HDR, SK {IDi, [CERTREQ,] [IDr,] > > SAi2, TSi, TSr} --> > > > > <-- HDR, SK {IDr, [CERT,] AUTH, > > EAP } > > > > HDR, SK {EAP, [AUTH] } --> > > > > The draft says "By including an IDi payload but not an AUTH > payload, the > > initiator has declared an identity but has not proven it." > (message 3) > > > > Section 3.16 additionally says: "Note that since IKE passes > an indication of > > initiator identity in message 3 of the protocol, EAP based > prompts for > > Identity SHOULD NOT be used." > > > > To me this seems that protection of the user identity > against an active > > attack cannot be provided for eap methods (except if > tunneled methods are > > used). this seems to have some disadvantages for remote > access solutions > > where you have a client-server relationship. > > > > possible solutions are: > > > > a) ignore user id conf. > > b) suggest to use a tunneled method within ikev2/eap when > user identity > > confidentiality is required. this clearly has a performance > disadvantage > > since you create two tunnels (for server to client > authentication) in > > addition to the eap method for client to server authentication. > > c) change the handling for secure legacy auth. and let the responder > > authenticate to the initiator first > > d) others? > > > > am i wrong with my observations? > > > > ciao > > hannes > > > > From owner-ipsec@lists.tislabs.com Tue Jun 10 10:50:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5AHoHAF085713; Tue, 10 Jun 2003 10:50:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA03942 Tue, 10 Jun 2003 13:13:13 -0400 (EDT) Message-Id: <200306101718.h5AHIeof007555@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Joe Touch cc: ipsec@lists.tislabs.com Subject: Re: issue with "per-interface SAD/SPD" In-reply-to: Your message of Mon, 09 Jun 2003 09:47:48 PDT. <3EE4BA34.5010308@isi.edu> Date: Tue, 10 Jun 2003 19:18:40 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: FYI, we addressed this sort of issue in draft-touch-ipsec-vpn-05.txt, which was submitted independently as an Informational in April. => this is a very nice news! Introducing an interface selector is insufficient; the selector needs to indicate the next-hop IP address and interface, as both are required for IP forwarding. The details of this issue, and simpler alternatives are discussed in the draft. => the problem I tried to address is a bit different: for instance in Mobile IPv6 only the packets with a Mobility Header must be protected, so a transport interface over the IP-in-IP tunnel is too much... In fact, my message was mainly for the 2401bis authors, as the "per interface" stuff is clearly inadapted. Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Tue Jun 10 20:37:09 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5B3b4rb003743; Tue, 10 Jun 2003 20:37:09 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA06349 Tue, 10 Jun 2003 23:03:30 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 10 Jun 2003 20:09:30 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Editorial: Use of | instead of , for concatenation Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi again. In section 2.14 of draft-ietf-ipsec-ikev2, it says: SKEYSEED and its derivatives are computed as follows: SKEYSEED = prf(Ni | Nr, g^ir) {SK_d, SK_ai, SK_ar, SK_ei, SK_er} = prf+ (SKEYSEED, Ni | Nr | SPIi | SPIr ) (indicating that the quantities SK_d, SK_ai, SK_ar, SK_ei, and SK_er are taken in order from the generated bits of the prf+). The parenthetical statement after the equations show that the list "{SK_d, SK_ai, SK_ar, SK_ei, SK_er}" is really concatenated. That list should instead be shown as "{SK_d | SK_ai | SK_ar | SK_ei | SK_er}" to make it clearer that this is not a bunch of arguments but a stream of octets. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Jun 10 20:37:11 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5B3b9rb003755; Tue, 10 Jun 2003 20:37:11 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA06343 Tue, 10 Jun 2003 23:03:20 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 10 Jun 2003 20:09:12 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Editorial: Values for Traffic Selector Types in draft-ietf-ipsec-ikev2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk . In section 3.13.1 of draft-ietf-ipsec-ikev2, the Traffic Selector Types are listed as: TS Type Value ------- ----- RESERVED 0 TS_IPV4_ADDR_RANGE 7 A range of IPv4 addresses, represented by two four (4) octet values. The first value is the beginning IPv4 address (inclusive) and the second value is the ending IPv4 address (inclusive). All addresses falling between the two specified addresses are considered to be within the list. TS_IPV6_ADDR_RANGE 8 A range of IPv6 addresses, represented by two sixteen (16) octet values. The first value is the beginning IPv6 address (inclusive) and the second value is the ending IPv6 address (inclusive). All addresses falling between the two specified addresses are considered to be within the list. Either the two values should be renumbered to 1 and 2, or the first line should be changed to "RESERVED 0-6". Otherwise, someone later is going to try to assign the lower-value numbers or, worse, think that they can use the other values from IKEv1. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Jun 10 20:37:17 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5B3bGrb003769; Tue, 10 Jun 2003 20:37:16 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA06342 Tue, 10 Jun 2003 23:03:20 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 10 Jun 2003 20:05:43 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Duplication: Remove most of section 3.3.2 and all of 3.3.4 of draft-ietf-ipsec-ikev2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi again. Most of section 3.3.2 in draft-ietf-ipsec-ikev2 (almost) duplicates the text from Jeff's algorithms document. Everything in the section after the Transform Type Values table should be removed. All of section 3.3.4 of draft-ietf-ipsec-ikev2 is now covered in Jeff's algorithms document. Thus, the whole section should be removed. (Yes, this begs the question of whether or not anyone is reading the three documents at all...) --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Jun 10 20:38:55 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5B3csrb003803; Tue, 10 Jun 2003 20:38:54 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA06341 Tue, 10 Jun 2003 23:03:19 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 10 Jun 2003 20:01:00 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Editorial: Reservations for IKEv1 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings again. In section 3.1 of draft-ietf-ipsec-ikev2, it says: Exchange Type Value RESERVED 0 Reserved for ISAKMP 1-31 Reserved for IKEv1 32-33 IKE_SA_INIT 34 IKE_AUTH 35 CREATE_CHILD_SA 36 INFORMATIONAL 37 Reserved for IKEv2+ 38-239 Reserved for private use 240-255 This is pretty confusing, because the IANA consideration section says clearly that the registries are for IKEv2 only. Further, the other tables in the document list the things that are resevered for future assignments and private use in text, not in the tables themselves. I propose that the chart be replaced with: Exchange Type Value RESERVED 0-33 IKE_SA_INIT 34 IKE_AUTH 35 CREATE_CHILD_SA 36 INFORMATIONAL 37 Exchange type values 38-239 are reserved to IANA for future assignment in IKEv2 (see section 6). Exchange type values 240-255 are for private use among mutually consenting parties. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Jun 10 20:43:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5B3hErb003891; Tue, 10 Jun 2003 20:43:15 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA06338 Tue, 10 Jun 2003 23:03:18 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 10 Jun 2003 19:52:45 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings again. The tables in draft-ietf-ipsec-ikev2-algorithms have MUST, SHOULD, MUST-, SHOULD+, SHOULD- (which I have proposed removing), and MAY. The MAY designation is silly, since an implementation MAY do whatever it pleases for non-mandatory algorithms. The reason I bring this up was the proposal that DES should be demoted to SHOULD NOT. That is somewhat harsh given that there are places where DES is appropriate (low value transactions in implementations that already have DES in them). Listing DES as "MAY" gives the wrong impression. The document should be re-cast to list all the registered algorithms, but to remove "MAY" from those that do not have a stronger designation. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Jun 11 05:01:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BC1Frb052205; Wed, 11 Jun 2003 05:01:19 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA08026 Wed, 11 Jun 2003 07:31:46 -0400 (EDT) Date: Wed, 11 Jun 2003 13:36:50 +0200 From: Jean-Francois Dive To: ipsec@lists.tislabs.com Cc: jef@linuxbe.org Subject: draft-ietf-ipsec-udp-encaps-06 comments. Message-ID: <20030611113650.GD1043@gardafou.assamite.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.3i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi all, I am actually busy with implementing NAT-T in IKEv1 context and found something which may have been overlooked (or that i missed the discussion on this list). In section 3.1.2, the author talk about the procedure to follow for udp encpasulated transport mode NAT decapsulation. I totally agress with the first point (point (a)) but think the second point (point (b)) is totally wrong and should never be implemented as such: it is suggested that if we dont have the original source or destination ip addresses, the TCP/UDP checksum of the packet should be recomputed to match the NAT'ed ip pseudo header. This cant happen as it would make corrupted packets appears as proper packets, the checksum "mangling" or update beeing right as a wrong checksum at the start would remain wrong. The only proper way to deal with this would be to go with checksum update when you have the information and no checksum at all if you dont have the information. Any comments ? Thanks, Regards, Jean-Francois Dive -- -> Jean-Francois Dive --> jef@linuxbe.org There is no such thing as randomness. Only order of infinite complexity. - Marquis de LaPlace - deterministic Principles - From owner-ipsec@lists.tislabs.com Wed Jun 11 06:43:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BDhFrb061120; Wed, 11 Jun 2003 06:43:15 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08323 Wed, 11 Jun 2003 09:13:15 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16103.11318.799282.793338@pkoning.dev.equallogic.com> Date: Wed, 11 Jun 2003 09:18:46 -0400 From: Paul Koning To: paul.hoffman@vpnc.org Cc: ipsec@lists.tislabs.com Subject: Re: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms References: X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Paul" == Paul Hoffman > writes: Paul> Greetings again. The tables in Paul> draft-ietf-ipsec-ikev2-algorithms have MUST, SHOULD, MUST-, Paul> SHOULD+, SHOULD- (which I have proposed removing), and MAY. The Paul> MAY designation is silly, since an implementation MAY do Paul> whatever it pleases for non-mandatory algorithms. Paul> The reason I bring this up was the proposal that DES should be Paul> demoted to SHOULD NOT. That is somewhat harsh given that there Paul> are places where DES is appropriate (low value transactions in Paul> implementations that already have DES in them). Listing DES as Paul> "MAY" gives the wrong impression. So what is wrong with "SHOULD NOT"? Two points. First, "SHOULD NOT" permits the implementation to do the thing being discouraged, but it explicitly warns that one must first consider whether it's wise to do so. I think that is exactly the correct message for DES. Second, what implementation already has DES that doesn't also have 3DES? I'm hard pressed to think of any. In a software implementation, 3DES is of course quite slow, but if so, the sensible answer is AES, which is faster than either. In a hardware implementation, you're stuck with what's in the chip, but if so, you have 3DES. paul From owner-ipsec@lists.tislabs.com Wed Jun 11 06:51:12 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BDpBrb061685; Wed, 11 Jun 2003 06:51:11 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08371 Wed, 11 Jun 2003 09:27:40 -0400 (EDT) Message-ID: <3EE72FB1.1040507@f-secure.com> Date: Wed, 11 Jun 2003 16:33:37 +0300 From: Ari Huttunen Organization: F-Secure Corporation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jean-Francois Dive CC: ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-udp-encaps-06 comments. References: <20030611113650.GD1043@gardafou.assamite.eu.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 11 Jun 2003 13:33:37.0830 (UTC) FILETIME=[105EB460:01C3301E] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jean-Francois Dive wrote: > Hi all, > > I am actually busy with implementing NAT-T in IKEv1 context and found something which may have been > overlooked (or that i missed the discussion on this list). In section 3.1.2, the author talk about the > procedure to follow for udp encpasulated transport mode NAT decapsulation. I totally agress with the > first point (point (a)) but think the second point (point (b)) is totally wrong and should never be > implemented as such: it is suggested that if we dont have the original source or destination ip > addresses, the TCP/UDP checksum of the packet should be recomputed to match the NAT'ed ip pseudo header. > This cant happen as it would make corrupted packets appears as proper packets, the checksum "mangling" > or update beeing right as a wrong checksum at the start would remain wrong. The only proper way to > deal with this would be to go with checksum update when you have the information and no checksum > at all if you dont have the information. > > Any comments ? You wouldn't use ESP without authentication, would you? In transport mode there's no chance that the packet contents accidentally changed if the packet is authenticated. It wouldn't pass authentication checking. Ari -- I play it cool and dig all jive, that's the reason I stay alive. My motto as I live and learn, is dig and be dug in return. Ari Huttunen phone: +358 9 2520 0700 Software Architect fax : +358 9 2520 5001 F-Secure Corporation http://www.F-Secure.com F(ully)-Secure products: Securing the Mobile Enterprise From owner-ipsec@lists.tislabs.com Wed Jun 11 07:06:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BE65rb062982; Wed, 11 Jun 2003 07:06:10 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08401 Wed, 11 Jun 2003 09:40:27 -0400 (EDT) From: "Yoav Nir" To: "'Paul Koning'" , Cc: Subject: RE: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms Date: Wed, 11 Jun 2003 16:44:27 +0200 Message-ID: <000401c33027$f5ca27b0$292e1dc2@YnirNew> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <16103.11318.799282.793338@pkoning.dev.equallogic.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk So RC4, Blowfish and IDEA are "MAY", but DES is "SHOULD NOT"? I think those should be at least as discouraged as DES. -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Koning Sent: Wednesday, June 11, 2003 3:19 PM To: paul.hoffman@vpnc.org Cc: ipsec@lists.tislabs.com Subject: Re: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms >>>>> "Paul" == Paul Hoffman > writes: Paul> Greetings again. The tables in Paul> draft-ietf-ipsec-ikev2-algorithms have MUST, SHOULD, MUST-, Paul> SHOULD+, SHOULD- (which I have proposed removing), and MAY. The Paul> MAY designation is silly, since an implementation MAY do Paul> whatever it pleases for non-mandatory algorithms. Paul> The reason I bring this up was the proposal that DES should be Paul> demoted to SHOULD NOT. That is somewhat harsh given that there Paul> are places where DES is appropriate (low value transactions in Paul> implementations that already have DES in them). Listing DES as Paul> "MAY" gives the wrong impression. So what is wrong with "SHOULD NOT"? Two points. First, "SHOULD NOT" permits the implementation to do the thing being discouraged, but it explicitly warns that one must first consider whether it's wise to do so. I think that is exactly the correct message for DES. Second, what implementation already has DES that doesn't also have 3DES? I'm hard pressed to think of any. In a software implementation, 3DES is of course quite slow, but if so, the sensible answer is AES, which is faster than either. In a hardware implementation, you're stuck with what's in the chip, but if so, you have 3DES. paul From owner-ipsec@lists.tislabs.com Wed Jun 11 07:11:53 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BEBqrb063261; Wed, 11 Jun 2003 07:11:53 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08449 Wed, 11 Jun 2003 09:48:21 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16103.13425.642338.266792@pkoning.dev.equallogic.com> Date: Wed, 11 Jun 2003 09:53:53 -0400 From: Paul Koning To: ynir@CheckPoint.com Cc: paul.hoffman@vpnc.org, ipsec@lists.tislabs.com Subject: RE: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms References: <16103.11318.799282.793338@pkoning.dev.equallogic.com> <000401c33027$f5ca27b0$292e1dc2@YnirNew> X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Yoav" == Yoav Nir writes: Yoav> So RC4, Blowfish and IDEA are "MAY", but DES is "SHOULD NOT"? Yoav> I think those should be at least as discouraged as DES. Why? DES is known to be weak (inadequate key size), while the others are (unless I missed something recent) not substantially weaker than exhaustive search of their key. Then again, RC4 shouldn't be in there at all since there is no spec for the use of RC4 in IPsec. Blowfish and IDEA are questionable for the same reason, although there the generic CBC spec arguably can be used. paul From owner-ipsec@lists.tislabs.com Wed Jun 11 07:48:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BEmtrb064975; Wed, 11 Jun 2003 07:48:55 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08604 Wed, 11 Jun 2003 10:22:04 -0400 (EDT) From: "Yoav Nir" To: Subject: RE: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms Date: Wed, 11 Jun 2003 17:26:34 +0200 Message-ID: <000501c3302d$d863da30$292e1dc2@YnirNew> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <16103.13425.642338.266792@pkoning.dev.equallogic.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk DES may be too weak for some applications, but it is a widely used standard. It is up to the user to decide whether DES is strong enough for their application or not. We wish the standards to ensure interoperability, and that means AES, 3DES and DES because these are widely implemented. Blowfish and IDEA are relatively rare, and have not received the scrutiny that DES and AES have. That's why they should be discouraged. Not because they are weak, but because we don't know for sure how weak they are. I agree though, that the argument for DES is no longer as strong as it was a few years ago, when you had to support DES (and a DES-only license) to export an encryption product out of the US. -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Koning Sent: Wednesday, June 11, 2003 3:54 PM To: ynir@CheckPoint.com Cc: paul.hoffman@vpnc.org; ipsec@lists.tislabs.com Subject: RE: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms >>>>> "Yoav" == Yoav Nir writes: Yoav> So RC4, Blowfish and IDEA are "MAY", but DES is "SHOULD NOT"? Yoav> I think those should be at least as discouraged as DES. Why? DES is known to be weak (inadequate key size), while the others are (unless I missed something recent) not substantially weaker than exhaustive search of their key. Then again, RC4 shouldn't be in there at all since there is no spec for the use of RC4 in IPsec. Blowfish and IDEA are questionable for the same reason, although there the generic CBC spec arguably can be used. paul From owner-ipsec@lists.tislabs.com Wed Jun 11 07:48:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BEmvrb064986; Wed, 11 Jun 2003 07:48:58 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08595 Wed, 11 Jun 2003 10:21:03 -0400 (EDT) Date: Wed, 11 Jun 2003 16:25:38 +0200 From: Jean-Francois Dive To: Ari Huttunen Cc: Jean-Francois Dive , ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-udp-encaps-06 comments. Message-ID: <20030611142538.GE1043@gardafou.assamite.eu.org> References: <20030611113650.GD1043@gardafou.assamite.eu.org> <3EE72FB1.1040507@f-secure.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3EE72FB1.1040507@f-secure.com> User-Agent: Mutt/1.5.3i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Jun 11, 2003 at 04:33:37PM +0300, Ari Huttunen wrote: > Jean-Francois Dive wrote: > >Hi all, > > > >I am actually busy with implementing NAT-T in IKEv1 context and found > >something which may have been > >overlooked (or that i missed the discussion on this list). In section > >3.1.2, the author talk about the > >procedure to follow for udp encpasulated transport mode NAT decapsulation. > >I totally agress with the first point (point (a)) but think the second > >point (point (b)) is totally wrong and should never be implemented as > >such: it is suggested that if we dont have the original source or > >destination ip addresses, the TCP/UDP checksum of the packet should be > >recomputed to match the NAT'ed ip pseudo header. This cant happen as it > >would make corrupted packets appears as proper packets, the checksum > >"mangling" > >or update beeing right as a wrong checksum at the start would remain > >wrong. The only proper way to deal with this would be to go with checksum > >update when you have the information and no checksum at all if you dont > >have the information. > >Any comments ? > > You wouldn't use ESP without authentication, would you? In transport > mode there's no chance that the packet contents accidentally changed > if the packet is authenticated. It wouldn't pass authentication checking. consider the following: - packet is xmt'ed from a station. - hope trough a dodgy router which corrupt it. - Go trough the the ipsec gateway, get UDPinESP'ed. - Go trough a NAT gateway. - Arrive in the ipsec gateway, the issue raise, the authenticated content never changed on the path. > > Ari > > -- > I play it cool and dig all jive, > that's the reason I stay alive. > My motto as I live and learn, > is dig and be dug in return. > > Ari Huttunen phone: +358 9 2520 0700 > Software Architect fax : +358 9 2520 5001 > > F-Secure Corporation http://www.F-Secure.com > > F(ully)-Secure products: Securing the Mobile Enterprise -- -> Jean-Francois Dive --> jef@linuxbe.org There is no such thing as randomness. Only order of infinite complexity. - Marquis de LaPlace - deterministic Principles - From owner-ipsec@lists.tislabs.com Wed Jun 11 08:36:32 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BFaWrb067018; Wed, 11 Jun 2003 08:36:32 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA08874 Wed, 11 Jun 2003 11:08:15 -0400 (EDT) Date: Wed, 11 Jun 2003 11:14:12 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: SHOULD NOT DES (was RE: Editorial: Use of MAY...) In-Reply-To: <000501c3302d$d863da30$292e1dc2@YnirNew> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 11 Jun 2003, Yoav Nir wrote: > DES may be too weak for some applications, but it is a widely used standard. As is sending passwords in clear with no encryption at all. Just because it is widely used doesn't mean it is good enough for us to recommend it for use in IPsec. "Neglect of duty does not cease, by repetition, to be neglect of duty." -- Napoleon > It is up to the user to decide whether DES is strong enough for their > application or not. Correct, and it is up to us to indicate wise choices for the bulk of applications. "SHOULD NOT" is precisely the right wording here -- it specifies something that is typically unwise but may be necessary in unusual circumstances. IPsec has long suffered from an unwillingness to make decisions and give specific recommendations, even when the technical issues were clear-cut. It is time to be a bit more decisive. > We wish the standards to ensure interoperability... And security. Which DES no longer delivers very well. The FreeS/WAN project dropped single-DES support over four years ago, at management insistence. This caused surprisingly few interoperability problems. (There were one or two.) I think it is now quite safe to say that DES-only environments involve either obsolete software or specialized requirements -- a perfect case for SHOULD NOT. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Jun 11 08:39:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BFdPrb067702; Wed, 11 Jun 2003 08:39:25 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA08861 Wed, 11 Jun 2003 11:06:43 -0400 (EDT) Date: Wed, 11 Jun 2003 17:11:42 +0200 From: Jean-Francois Dive To: Jean-Francois Dive Cc: Ari Huttunen , ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-udp-encaps-06 comments. Message-ID: <20030611151142.GG1043@gardafou.assamite.eu.org> References: <20030611113650.GD1043@gardafou.assamite.eu.org> <3EE72FB1.1040507@f-secure.com> <20030611142538.GE1043@gardafou.assamite.eu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030611142538.GE1043@gardafou.assamite.eu.org> User-Agent: Mutt/1.5.3i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Jun 11, 2003 at 04:25:38PM +0200, Jean-Francois Dive wrote: > On Wed, Jun 11, 2003 at 04:33:37PM +0300, Ari Huttunen wrote: > > Jean-Francois Dive wrote: > > >Hi all, > > > > > >I am actually busy with implementing NAT-T in IKEv1 context and found > > >something which may have been > > >overlooked (or that i missed the discussion on this list). In section > > >3.1.2, the author talk about the > > >procedure to follow for udp encpasulated transport mode NAT decapsulation. > > >I totally agress with the first point (point (a)) but think the second > > >point (point (b)) is totally wrong and should never be implemented as > > >such: it is suggested that if we dont have the original source or > > >destination ip addresses, the TCP/UDP checksum of the packet should be > > >recomputed to match the NAT'ed ip pseudo header. This cant happen as it > > >would make corrupted packets appears as proper packets, the checksum > > >"mangling" > > >or update beeing right as a wrong checksum at the start would remain > > >wrong. The only proper way to deal with this would be to go with checksum > > >update when you have the information and no checksum at all if you dont > > >have the information. > > >Any comments ? > > > > You wouldn't use ESP without authentication, would you? In transport > > mode there's no chance that the packet contents accidentally changed > > if the packet is authenticated. It wouldn't pass authentication checking. > > consider the following: > - packet is xmt'ed from a station. > - hope trough a dodgy router which corrupt it. > - Go trough the the ipsec gateway, get UDPinESP'ed. > - Go trough a NAT gateway. > - Arrive in the ipsec gateway, the issue raise, the authenticated > content never changed on the path. ok, something slept away from my mind when coding this thing, we are in transport mode so this is hardly going to happen.... > > > > > > Ari > > > > -- > > I play it cool and dig all jive, > > that's the reason I stay alive. > > My motto as I live and learn, > > is dig and be dug in return. > > > > Ari Huttunen phone: +358 9 2520 0700 > > Software Architect fax : +358 9 2520 5001 > > > > F-Secure Corporation http://www.F-Secure.com > > > > F(ully)-Secure products: Securing the Mobile Enterprise > From owner-ipsec@lists.tislabs.com Wed Jun 11 09:18:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BGINrb073077; Wed, 11 Jun 2003 09:18:24 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09195 Wed, 11 Jun 2003 11:49:02 -0400 (EDT) Message-Id: <200306111554.h5BFsXq3001831@thunk.east.sun.com> From: Bill Sommerfeld To: Henry Spencer cc: IP Security List Subject: Re: SHOULD NOT DES (was RE: Editorial: Use of MAY...) In-Reply-To: Your message of "Wed, 11 Jun 2003 11:14:12 EDT." Reply-to: sommerfeld@east.sun.com Date: Wed, 11 Jun 2003 11:54:33 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > The FreeS/WAN project dropped single-DES support over four years ago, at > management insistence. This caused surprisingly few interoperability > problems. (There were one or two.) I think it is now quite safe to say > that DES-only environments involve either obsolete software or specialized > requirements -- a perfect case for SHOULD NOT. It appears that the US government agrees with your management on this point. section 12 of FIPS 46-3 (issued in 1999) says, in part: Single DES (i.e., DES) will be permitted for legacy systems only. New procurements to support legacy systems should, where feasible, use Triple DES products running in the single DES configuration. Since there is no installed base of IKEv2 to interoperate with, this FIPS would appear to prohibit use of single-DES with IKEv2 for government use. One more vote for SHOULD NOT. - Bill From owner-ipsec@lists.tislabs.com Wed Jun 11 09:22:38 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BGMcrb073230; Wed, 11 Jun 2003 09:22:38 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA09227 Wed, 11 Jun 2003 11:52:18 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16103.20863.459623.479274@pkoning.dev.equallogic.com> Date: Wed, 11 Jun 2003 11:57:51 -0400 From: Paul Koning To: ynir@CheckPoint.com Cc: ipsec@lists.tislabs.com Subject: RE: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms References: <16103.13425.642338.266792@pkoning.dev.equallogic.com> <000501c3302d$d863da30$292e1dc2@YnirNew> X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Yoav" == Yoav Nir writes: Yoav> DES may be too weak for some applications, but it is a widely Yoav> used standard. It is up to the user to decide whether DES is Yoav> strong enough for their application or not. We wish the Yoav> standards to ensure interoperability, and that means AES, 3DES Yoav> and DES because these are widely implemented. There are lots of RFCs that say SHOULD NOT or MUST NOT for security weaknesses. Just because you can argue "the customer should decide whether xyz is strong enough" doesn't justify a MAY there -- and I don't think it does here, either. Yoav> Blowfish and IDEA are relatively rare, and have not received Yoav> the scrutiny that DES and AES have. That's why they should be Yoav> discouraged. Not because they are weak, but because we don't Yoav> know for sure how weak they are. Ok, then the simple answer is to remove them entirely from the spec, because they aren't really specified explicitly anyway for IPsec and probably not implemented anywhere anyway. paul From owner-ipsec@lists.tislabs.com Wed Jun 11 09:36:35 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BGaZrb073743; Wed, 11 Jun 2003 09:36:35 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA09389 Wed, 11 Jun 2003 12:11:57 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <16103.13425.642338.266792@pkoning.dev.equallogic.com> References: <16103.11318.799282.793338@pkoning.dev.equallogic.com> <000401c33027$f5ca27b0$292e1dc2@YnirNew> <16103.13425.642338.266792@pkoning.dev.equallogic.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Wed, 11 Jun 2003 09:17:47 -0700 To: Paul Koning , ynir@CheckPoint.com From: Paul Hoffman / VPNC Subject: RE: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:53 AM -0400 6/11/03, Paul Koning wrote: > >>>>> "Yoav" == Yoav Nir writes: > > Yoav> So RC4, Blowfish and IDEA are "MAY", but DES is "SHOULD NOT"? > Yoav> I think those should be at least as discouraged as DES. > >Why? DES is known to be weak (inadequate key size), while the others >are (unless I missed something recent) not substantially weaker than >exhaustive search of their key. Any algorithm with a variable key size could be considerably weaker than DES. Unless you are going to start listing key sizes and giving each size a rating, saying SHOULD NOT for DES but MAY for some other algorithm that can use 40-bit keys is silly. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Jun 11 09:37:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BGb5rb073786; Wed, 11 Jun 2003 09:37:06 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA09365 Wed, 11 Jun 2003 12:10:17 -0400 (EDT) In-Reply-To: <20030611142538.GE1043@gardafou.assamite.eu.org> References: <20030611113650.GD1043@gardafou.assamite.eu.org> <3EE72FB1.1040507@f-secure.com> <20030611142538.GE1043@gardafou.assamite.eu.org> Mime-Version: 1.0 (Apple Message framework v574) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <09AEE282-9C28-11D7-B6C4-000A959D832C@apple.com> Content-Transfer-Encoding: 7bit Cc: Ari Huttunen , ipsec@lists.tislabs.com From: Joshua Graessley Subject: Re: draft-ietf-ipsec-udp-encaps-06 comments. Date: Wed, 11 Jun 2003 09:16:20 -0700 To: Jean-Francois Dive X-Mailer: Apple Mail (2.574) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wednesday, June 11, 2003, at 7:25, Jean-Francois Dive wrote: > On Wed, Jun 11, 2003 at 04:33:37PM +0300, Ari Huttunen wrote: >> Jean-Francois Dive wrote: >>> Hi all, >>> >>> I am actually busy with implementing NAT-T in IKEv1 context and found >>> something which may have been >>> overlooked (or that i missed the discussion on this list). In section >>> 3.1.2, the author talk about the >>> procedure to follow for udp encpasulated transport mode NAT >>> decapsulation. >>> I totally agress with the first point (point (a)) but think the >>> second >>> point (point (b)) is totally wrong and should never be implemented as >>> such: it is suggested that if we dont have the original source or >>> destination ip addresses, the TCP/UDP checksum of the packet should >>> be >>> recomputed to match the NAT'ed ip pseudo header. This cant happen as >>> it >>> would make corrupted packets appears as proper packets, the checksum >>> "mangling" >>> or update beeing right as a wrong checksum at the start would remain >>> wrong. The only proper way to deal with this would be to go with >>> checksum >>> update when you have the information and no checksum at all if you >>> dont >>> have the information. >>> Any comments ? >> >> You wouldn't use ESP without authentication, would you? In transport >> mode there's no chance that the packet contents accidentally changed >> if the packet is authenticated. It wouldn't pass authentication >> checking. > > consider the following: > - packet is xmt'ed from a station. > - hope trough a dodgy router which corrupt it. > - Go trough the the ipsec gateway, get UDPinESP'ed. > - Go trough a NAT gateway. > - Arrive in the ipsec gateway, the issue raise, the authenticated > content never changed on the path. Is transport mode commonly implemented in an IPSec gateway? Would such a gateway be configured behind a NAT a hop away from the host that originated the traffic? This seems like a very unlikely scenario that would lead to other complications. Is anyone actually implementing an ipsec gateway with NAT traversal? This can still be addressed in the gateway, the ipsec gateway could simply verify the checksum before it performs the ESP encapsulation. There's no point in wasting all the CPU power of encrypting the packet if the packet will just get dropped on the end. -josh From owner-ipsec@lists.tislabs.com Wed Jun 11 10:32:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BHWrrb076071; Wed, 11 Jun 2003 10:32:54 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA09689 Wed, 11 Jun 2003 12:59:12 -0400 (EDT) Date: Wed, 11 Jun 2003 13:05:10 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: SHOULD NOT DES (was RE: Editorial: Use of MAY...) In-Reply-To: <200306111554.h5BFsXq3001831@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 11 Jun 2003, Bill Sommerfeld wrote: > > The FreeS/WAN project dropped single-DES support over four years ago, at > > management insistence... > > It appears that the US government agrees with your management on this > point... In fact, at the time *I* disagreed with my then-management, and did my best to talk them out of it -- I thought that dropping support was premature and was going to cause us serious grief. To my considerable surprise, I was wrong. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Jun 11 10:33:08 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BHX8rb076092; Wed, 11 Jun 2003 10:33:08 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09720 Wed, 11 Jun 2003 13:02:10 -0400 (EDT) Date: Wed, 11 Jun 2003 13:08:09 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: RE: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms In-Reply-To: <16103.20863.459623.479274@pkoning.dev.equallogic.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 11 Jun 2003, Paul Koning wrote: > Yoav> Blowfish and IDEA are relatively rare... [and poorly studied] > > Ok, then the simple answer is to remove them entirely from the spec, > because they aren't really specified explicitly anyway for IPsec and > probably not implemented anywhere anyway. Almost nowhere -- there was a user-contributed FreeS/WAN patch that did IDEA, Blowfish, and CAST, and some folks used it. We never adopted it as part of the official distribution, though, and I don't think that's changed since I left the project. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Jun 11 10:35:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BHZJrb076195; Wed, 11 Jun 2003 10:35:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09776 Wed, 11 Jun 2003 13:04:55 -0400 (EDT) X-Envelope-To: ipsec@lists.tislabs.com To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms Date: 11 Jun 2003 16:44:19 GMT Organization: University of California, Berkeley Lines: 10 Distribution: isaac Message-ID: References: <16103.11318.799282.793338@pkoning.dev.equallogic.com> <000401c33027$f5ca27b0$292e1dc2@YnirNew> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1055349859 21719 128.32.153.211 (11 Jun 2003 16:44:19 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 11 Jun 2003 16:44:19 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yoav Nir wrote: >So RC4, Blowfish and IDEA are "MAY", but DES is "SHOULD NOT"? I think those >should be at least as discouraged as DES. That seems about right. DES has a 56-bit key, and hence is a poor choice for deployment in new systems. Blowfish and IDEA are believed to be much stronger. RC4, on the hand, shouldn't be there. Are you sure that RC4 is a "MAY" in the IPSec RFCs? If so, that should be fixed. From owner-ipsec@lists.tislabs.com Wed Jun 11 10:36:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BHakrb076281; Wed, 11 Jun 2003 10:36:46 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09708 Wed, 11 Jun 2003 13:00:32 -0400 (EDT) To: ipsec@lists.tislabs.com cc: byfraser@cisco.com Subject: LAST CALL: IKE Crypto documents I-D's From: "Theodore Ts'o" Phone: (781) 391-3464 Message-Id: Date: Wed, 11 Jun 2003 08:06:15 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a working group last call for comments on the following drafts. For progression to Proposed Standard: draft-ietf-ipsec-ikev2-algorithms-02.txt For progression to Informational: draft-ietf-ipsec-ui-suites-00.txt This last call with expire on June 23rd. - Ted and Barbara From owner-ipsec@lists.tislabs.com Wed Jun 11 10:40:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BHeorb076452; Wed, 11 Jun 2003 10:40:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09800 Wed, 11 Jun 2003 13:08:48 -0400 (EDT) X-Envelope-To: ipsec@lists.tislabs.com To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms Date: 11 Jun 2003 16:48:13 GMT Organization: University of California, Berkeley Lines: 18 Distribution: isaac Message-ID: References: <16103.11318.799282.793338@pkoning.dev.equallogic.com> <000401c33027$f5ca27b0$292e1dc2@YnirNew> <16103.13425.642338.266792@pkoning.dev.equallogic.com> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1055350093 21719 128.32.153.211 (11 Jun 2003 16:48:13 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 11 Jun 2003 16:48:13 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman / VPNC wrote: >Any algorithm with a variable key size could be considerably weaker >than DES. Unless you are going to start listing key sizes and giving >each size a rating, saying SHOULD NOT for DES but MAY for some other >algorithm that can use 40-bit keys is silly. I don't recall a MAY requirement for any 40-bit cipher. We debated 40-bit ciphers a long time ago (remember export controls?), and we came to consensus many years ago that 40-bit ciphers have no place in IPSec. Are you saying there is a MAY requirement for a 40-bit cipher? If so, that should be fixed, but I don't believe it. In short, I don't see how your argument is relevant to whether DES is a SHOULD NOT, a MAY, or something else. By the way, what matters is not whether a cipher could support 40-bit keys, but whether, /as standardized in IPSec/, it uses 40-bit keys. There's nothing wrong with the former; but the latter is to be avoided. From owner-ipsec@lists.tislabs.com Wed Jun 11 11:03:04 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BI34rb077319; Wed, 11 Jun 2003 11:03:04 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA09973 Wed, 11 Jun 2003 13:34:34 -0400 (EDT) Message-ID: <74AB2EDFB513564CB272F5FF0E956CD201BF4D2C@exch4.rhul.ac.uk> From: Pagliusi PS To: ipsec@lists.tislabs.com Cc: Mitchell C Subject: RE: Identity protection [Re: Working Group Last Call IKEv2] Date: Wed, 11 Jun 2003 14:48:10 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear all, In accordance with Hannes e-mail (please see below) related to ikev2, I would like to support the idea to add active user identity confidentiality protection for the initiator (eap message handling). And Chris J. Mitchell shares the same opinion. Cheers, Paulo Pagliusi ----- Original Message ----- From: "Tschofenig Hannes" To: Sent: Wednesday, June 11, 2003 1:37 PM Subject: FW: Identity protection [Re: Working Group Last Call IKEv2] > hi all, > > i would like to draw your attention to the following issue discussed > in the ipsec mailing list. > > ikev2 is current in last call. we would like to add active user > identity confidentiality protection for the initiator (eap message > handling). > > if you think that this is a good idea then please send a posting to > the ipsec mailing supporting this idea. during our shaman wp1 > activities we concluded that this would be necessary (see jfk > analysis). > > ciao > hannes > > ps: attached you will find my simple proposal for adding support > within ikev2 which does not require any modification to the ikev2 > protocol itself. > From owner-ipsec@lists.tislabs.com Wed Jun 11 11:05:08 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BI57rb077408; Wed, 11 Jun 2003 11:05:07 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10017 Wed, 11 Jun 2003 13:38:02 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <200306111554.h5BFsXq3001831@thunk.east.sun.com> References: <200306111554.h5BFsXq3001831@thunk.east.sun.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Wed, 11 Jun 2003 10:43:10 -0700 To: sommerfeld@east.sun.com, Henry Spencer From: Paul Hoffman / VPNC Subject: Re: SHOULD NOT DES (was RE: Editorial: Use of MAY...) Cc: IP Security List Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:54 AM -0400 6/11/03, Bill Sommerfeld wrote: >One more vote for SHOULD NOT. So you think it is better to give a lower recommendation for an algorithm with a known (weak) key strength than to algorithms that could be much weaker, including zero encryption. That sure sends a clear message to implementers... --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Jun 11 11:06:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BI6Grb077493; Wed, 11 Jun 2003 11:06:19 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10041 Wed, 11 Jun 2003 13:38:28 -0400 (EDT) Date: Wed, 11 Jun 2003 13:44:27 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On 11 Jun 2003, David Wagner wrote: > I don't recall a MAY requirement for any 40-bit cipher. We debated > 40-bit ciphers a long time ago (remember export controls?), and we came > to consensus many years ago that 40-bit ciphers have no place in IPSec. > Are you saying there is a MAY requirement for a 40-bit cipher? If so, > that should be fixed, but I don't believe it. RFC 2451 Blowfish allows keys as short as 40 bits, as does RFC 2451 CAST. RFC 2451 IDEA does not. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Jun 11 11:06:49 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BI6nrb077525; Wed, 11 Jun 2003 11:06:49 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10058 Wed, 11 Jun 2003 13:40:50 -0400 (EDT) Date: Wed, 11 Jun 2003 13:46:50 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: SHOULD NOT DES (was RE: Editorial: Use of MAY...) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 11 Jun 2003, Paul Hoffman / VPNC wrote: > At 11:54 AM -0400 6/11/03, Bill Sommerfeld wrote: > >One more vote for SHOULD NOT. > > So you think it is better to give a lower recommendation for an > algorithm with a known (weak) key strength than to algorithms that > could be much weaker, including zero encryption. Where, exactly, did either Bill or I say that? Please be precise. This is a gross misrepresentation of my views, and probably Bill's as well. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Jun 11 11:18:55 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BIIsrb078145; Wed, 11 Jun 2003 11:18:55 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA10131 Wed, 11 Jun 2003 13:51:18 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: <16103.11318.799282.793338@pkoning.dev.equallogic.com> <000401c33027$f5ca27b0$292e1dc2@YnirNew> <16103.13425.642338.266792@pkoning.dev.equallogic.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Wed, 11 Jun 2003 10:57:15 -0700 To: daw@mozart.cs.berkeley.edu (David Wagner), ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:48 PM +0000 6/11/03, David Wagner wrote: >I don't recall a MAY requirement for any 40-bit cipher. We debated >40-bit ciphers a long time ago (remember export controls?), and we came >to consensus many years ago that 40-bit ciphers have no place in IPSec. >Are you saying there is a MAY requirement for a 40-bit cipher? If so, >that should be fixed, but I don't believe it. draft-ietf-ipsec-ikev2-algorithms-02.txt, the document under discussion, has MAY level for many encryption algorithms that have key sizes down to 40. It's pretty clear in the draft, regardless of what you believe. >By the way, what matters is not whether a cipher could support 40-bit >keys, but whether, /as standardized in IPSec/, it uses 40-bit keys. >There's nothing wrong with the former; but the latter is to be avoided. Anyone who wanted to write a replacement for RFC 2451 has had almost five years to do so; so far, no one has. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Jun 11 11:42:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BIgJrb079218; Wed, 11 Jun 2003 11:42:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10423 Wed, 11 Jun 2003 14:12:15 -0400 (EDT) Message-Id: <5.2.0.9.2.20030611141434.01fcb268@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 11 Jun 2003 14:18:12 -0400 To: ipsec@lists.tislabs.com From: Russ Housley Subject: Fwd: LAST CALL: IKE Crypto documents I-D's Cc: tytso@mit.edu, byfraser@cisco.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I am confused here. Based on the front matter in both documents, the authors of each document appear to have Standards Track in mind. Standards Track seems reasonable to me in both cases. Russ >This is a working group last call for comments on the following drafts. > >For progression to Proposed Standard: > > draft-ietf-ipsec-ikev2-algorithms-02.txt > >For progression to Informational: > > draft-ietf-ipsec-ui-suites-00.txt > >This last call with expire on June 23rd. From owner-ipsec@lists.tislabs.com Wed Jun 11 12:18:47 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BJIkrb081902; Wed, 11 Jun 2003 12:18:46 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10743 Wed, 11 Jun 2003 14:50:28 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Wed, 11 Jun 2003 11:56:25 -0700 To: Henry Spencer , IP Security List From: Paul Hoffman / VPNC Subject: Re: SHOULD NOT DES (was RE: Editorial: Use of MAY...) Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 1:46 PM -0400 6/11/03, Henry Spencer wrote: >On Wed, 11 Jun 2003, Paul Hoffman / VPNC wrote: >> At 11:54 AM -0400 6/11/03, Bill Sommerfeld wrote: >> >One more vote for SHOULD NOT. >> >> So you think it is better to give a lower recommendation for an >> algorithm with a known (weak) key strength than to algorithms that >> could be much weaker, including zero encryption. > >Where, exactly, did either Bill or I say that? Please be precise. I only saw messages about making DES be SHOULD NOT, not any messages about making all the other variable-length ciphers SHOULD NOT. If you sent such a message and I missed it, I apologize. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Jun 11 12:21:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BJL3rb082305; Wed, 11 Jun 2003 12:21:07 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA10800 Wed, 11 Jun 2003 14:54:39 -0400 (EDT) X-Envelope-To: ipsec@lists.tislabs.com To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms Date: 11 Jun 2003 18:34:04 GMT Organization: University of California, Berkeley Lines: 28 Distribution: isaac Message-ID: References: NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1055356444 22752 128.32.153.211 (11 Jun 2003 18:34:04 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 11 Jun 2003 18:34:04 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Henry Spencer wrote: >On 11 Jun 2003, David Wagner wrote: >> I don't recall a MAY requirement for any 40-bit cipher. We debated >> 40-bit ciphers a long time ago (remember export controls?), and we came >> to consensus many years ago that 40-bit ciphers have no place in IPSec. >> Are you saying there is a MAY requirement for a 40-bit cipher? If so, >> that should be fixed, but I don't believe it. > >RFC 2451 Blowfish allows keys as short as 40 bits, as does RFC 2451 CAST. >RFC 2451 IDEA does not. That's different. IPSec does not have a MAY requirement for 40-bit ciphers. It has a MAY requirement for ciphers like Blowfish which can be used with 40-bit keys, but the default key size for Blowfish is 128 bits, which is adequate. With DES, not only is the default key inadequate (56 bits), that's the *only* supported key size; as a result, DES is clearly inadequate for deployment in most new systems. It's not what size keys the cipher supports that matters; it's what size keys are standardized for use in IPSEc. Maybe we should add a line to RFC2451 saying that users SHOULD NOT use key sizes shorter than the default. There's no good reason to use shorter keys. This addition would make everything consistent with a SHOULD NOT policy for DES. Will this make everyone happy? (Amusingly, RFC2451 suggests that implementors SHOULD check for weak keys. Personally, I consider *every* 40-bit key a weak key.) From owner-ipsec@lists.tislabs.com Wed Jun 11 12:33:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BJXWrb083080; Wed, 11 Jun 2003 12:33:32 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10868 Wed, 11 Jun 2003 15:05:08 -0400 (EDT) X-Envelope-To: ipsec@lists.tislabs.com To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms Date: 11 Jun 2003 18:44:34 GMT Organization: University of California, Berkeley Lines: 40 Distribution: isaac Message-ID: References: <16103.11318.799282.793338@pkoning.dev.equallogic.com> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1055357074 22752 128.32.153.211 (11 Jun 2003 18:44:34 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 11 Jun 2003 18:44:34 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman / VPNC wrote: >draft-ietf-ipsec-ikev2-algorithms-02.txt, the document under >discussion, has MAY level for many encryption algorithms that have >key sizes down to 40. It's pretty clear in the draft, regardless of >what you believe. Ok, I didn't realize that. I'm not convinced this respects the consensus established by the working group years ago, but arguing about this might take us into a rathole from which we never recover, so let's not go there. Instead, let me just note that the situation with draft-ietf-ipsec-ikev2-algorithms-02.txt is very different from the situation with DES. DES can't go higher than 56 bits. The algorithms in draft-ietf-ipsec-ikev2-algorithms-02.txt go up to 128 bits and higher, and indeed, their default is 128 bits. So, I still think DES should be a SHOULD NOT. And, if consistency matters, there's a simple fix. Let's change draft-ietf-ipsec-ikev2-algorithms-02.txt to make clear that short keys SHOULD NOT be used, just like DES SHOULD NOT be used. I'm fine with that. I do think the DES issue is more important in practice than the draft-ietf-ipsec-ikev2-algorithms-02.txt issue. Not many implementations will use, say, Blowfish, and for those that do, it's pretty unlikely they will go out of their way to use a smaller-than-default key size. (If they do, maybe they deserve what they get.) But it is quite likely that many implementations will use DES with its 56 bit keys. As a result, I feel it is more important to fix the DES issue than to worry about Blowfish minimum key sizes. If we don't do anything, the DES failure mode could become widespread, while the Blowfish failure mode is likely to be very rare. As a result, if there is some reason we can't fix the draft-ietf-ipsec-ikev2-algorithms-02.txt minimum key size issue, we shouldn't let that stop us from fixing the DES issue. Getting security right is more important than consistency. But if we can fix the ikev2-algorithms draft, I have no objection to upping the Blowfish minimum key sizes, if that is preferable. It's not a bad idea. From owner-ipsec@lists.tislabs.com Wed Jun 11 12:53:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BJrQrb083850; Wed, 11 Jun 2003 12:53:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA11073 Wed, 11 Jun 2003 15:27:37 -0400 (EDT) Date: Wed, 11 Jun 2003 15:33:36 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: SHOULD NOT DES (was RE: Editorial: Use of MAY...) In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 11 Jun 2003, Paul Hoffman / VPNC wrote: > >> So you think it is better to give a lower recommendation for an > >> algorithm with a known (weak) key strength than to algorithms that > >> could be much weaker, including zero encryption. > >Where, exactly, did either Bill or I say that? Please be precise. > > I only saw messages about making DES be SHOULD NOT, not any messages > about making all the other variable-length ciphers SHOULD NOT. If you > sent such a message and I missed it, I apologize. You're still jumping to conclusions -- the fact that you have not heard from me about the variable-length ciphers tells you nothing about my position on them, so you cannot legitimately infer that I consider dealing with them unimportant. (And your "zero encryption" remark remains odd, because none of the RFC 2451 variable-length ciphers goes down to zero.) My position on them actually lines up closely with David Wagner's most recent message: they *are* lower priority -- not because they are better, but because they are little-used and do have at least the option of longer keys -- but it would nevertheless be good to deal with them too. Dealing properly with DES, however, is *important*. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Wed Jun 11 12:54:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BJsirb083908; Wed, 11 Jun 2003 12:54:44 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA11060 Wed, 11 Jun 2003 15:24:53 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Wed, 11 Jun 2003 12:30:44 -0700 To: daw@mozart.cs.berkeley.edu (David Wagner), ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 6:34 PM +0000 6/11/03, David Wagner wrote: >It's not what size keys the cipher supports that matters; it's what size >keys are standardized for use in IPSEc. Exactly right. >Maybe we should add a line to RFC2451 saying that users SHOULD NOT >use key sizes shorter than the default. There's no good reason to use >shorter keys. This addition would make everything consistent with a >SHOULD NOT policy for DES. Will this make everyone happy? It would certainly make me happier. That way, we would not be having different recommendations for IKEv1 than what we have for IKEv2. Actually, a complete revision to RFC 2451 would be nice, including removing algorithms for which there are not stable references. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Jun 11 13:01:28 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BK1Srb084191; Wed, 11 Jun 2003 13:01:28 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA11105 Wed, 11 Jun 2003 15:33:05 -0400 (EDT) Date: Wed, 11 Jun 2003 10:39:05 -0400 From: "Theodore Ts'o" To: Russ Housley Cc: ipsec@lists.tislabs.com, byfraser@cisco.com Subject: Re: Fwd: LAST CALL: IKE Crypto documents I-D's Message-ID: <20030611143905.GB2575@think> References: <5.2.0.9.2.20030611141434.01fcb268@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <5.2.0.9.2.20030611141434.01fcb268@mail.binhost.com> User-Agent: Mutt/1.5.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, Jun 11, 2003 at 02:18:12PM -0400, Russ Housley wrote: > I am confused here. Based on the front matter in both documents, the > authors of each document appear to have Standards Track in mind. Standards > Track seems reasonable to me in both cases. Well, maybe we need to have a discussion the working group and the AD's about this question. The reason why Barbara and I thought Informational track would be more appropriate for draft-ietf-ipsec-ui-suites is because it doesn't actually impose any MUST's on the protocol, as defined as bits-on-the-wire. So with no impliciations on bits-on-the-wire, what "at least two interoperable implementations" means is an interesting question indeed. On the other hand, there the IETF advanced the GSSAPI specifications as Proposed Standard even though there little to no protocol implication. That might argue that the ui-suites I-D should be a Proposed Standard, and we'll simply leave the headache of what "interoperable implementations" mean to the IESG in that case. All of this being said, neither Barbara nor I have any strong feelings on this matter, so we are certainly open to any strong sense from the wg, or direction from the AD's. - Ted From owner-ipsec@lists.tislabs.com Wed Jun 11 14:40:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BLeFrb089082; Wed, 11 Jun 2003 14:40:17 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11707 Wed, 11 Jun 2003 17:11:57 -0400 (EDT) Message-Id: <200306112117.h5BLH0of012114@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Theodore Ts'o" cc: Russ Housley , ipsec@lists.tislabs.com, byfraser@cisco.com Subject: Re: Fwd: LAST CALL: IKE Crypto documents I-D's In-reply-to: Your message of Wed, 11 Jun 2003 10:39:05 EDT. <20030611143905.GB2575@think> Date: Wed, 11 Jun 2003 23:17:00 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: > Standards Track seems reasonable to me in both cases. All of this being said, neither Barbara nor I have any strong feelings on this matter, so we are certainly open to any strong sense from the wg, or direction from the AD's. => why not a BCP? Thanks Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Wed Jun 11 14:40:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BLeKrb089093; Wed, 11 Jun 2003 14:40:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11722 Wed, 11 Jun 2003 17:12:47 -0400 (EDT) Message-Id: <5.2.0.9.2.20030611171254.03d82698@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Wed, 11 Jun 2003 17:18:33 -0400 To: "Theodore Ts'o" From: Russ Housley Subject: Re: Fwd: LAST CALL: IKE Crypto documents I-D's Cc: ipsec@lists.tislabs.com, byfraser@cisco.com In-Reply-To: <20030611143905.GB2575@think> References: <5.2.0.9.2.20030611141434.01fcb268@mail.binhost.com> <5.2.0.9.2.20030611141434.01fcb268@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Ted: > > I am confused here. Based on the front matter in both documents, the > > authors of each document appear to have Standards Track in > mind. Standards > > Track seems reasonable to me in both cases. > >Well, maybe we need to have a discussion the working group and the >AD's about this question. The reason why Barbara and I thought >Informational track would be more appropriate for >draft-ietf-ipsec-ui-suites is because it doesn't actually impose any >MUST's on the protocol, as defined as bits-on-the-wire. It does impact interoperability. If the same string is used by two different vendors to mean different collections of algorithms, then the protocol negations will probably fail in a reasonable way to people that look at the actual packets. However, two administrators will say that the boxes are configured in the same way, but they fail to interoperate. >So with no impliciations on bits-on-the-wire, what "at least two >interoperable implementations" means is an interesting question >indeed. > >On the other hand, there the IETF advanced the GSSAPI specifications >as Proposed Standard even though there little to no protocol >implication. That might argue that the ui-suites I-D should be a >Proposed Standard, and we'll simply leave the headache of what >"interoperable implementations" mean to the IESG in that case. > >All of this being said, neither Barbara nor I have any strong feelings >on this matter, so we are certainly open to any strong sense from the >wg, or direction from the AD's. I understand your points. I will discuss with the rest of the IESG and report back. We happen to have a telechat scheduled for tomorrow, Russ From owner-ipsec@lists.tislabs.com Wed Jun 11 14:57:23 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BLvMrb089962; Wed, 11 Jun 2003 14:57:23 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11837 Wed, 11 Jun 2003 17:30:20 -0400 (EDT) Message-Id: <200306112135.h5BLZoq3002115@thunk.east.sun.com> From: Bill Sommerfeld To: Henry Spencer cc: IP Security List Subject: Re: SHOULD NOT DES (was RE: Editorial: Use of MAY...) In-Reply-To: Your message of "Wed, 11 Jun 2003 15:33:36 EDT." Reply-to: sommerfeld@east.sun.com Date: Wed, 11 Jun 2003 17:35:50 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > You're still jumping to conclusions -- the fact that you have not heard > from me about the variable-length ciphers tells you nothing about my > position on them, so you cannot legitimately infer that I consider dealing > with them unimportant. (And your "zero encryption" remark remains odd, > because none of the RFC 2451 variable-length ciphers goes down to > zero.) And the null cipher for ESP is qualitatively different; it's an alternative to AH for applications where privacy is clearly not required. > My position on them actually lines up closely with David Wagner's most > recent message: they *are* lower priority -- not because they are better, > but because they are little-used and do have at least the option of longer > keys -- but it would nevertheless be good to deal with them too. Dealing > properly with DES, however, is *important*. And, for the record, "What Henry Said". - Bill From owner-ipsec@lists.tislabs.com Wed Jun 11 14:57:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BLvMrb089961; Wed, 11 Jun 2003 14:57:27 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA11849 Wed, 11 Jun 2003 17:31:07 -0400 (EDT) Date: Wed, 11 Jun 2003 23:35:41 +0200 From: Tobias Poppe To: Bill Sommerfeld Cc: IP Security List Subject: Re: SHOULD NOT DES (was RE: Editorial: Use of MAY...) Message-ID: <20030611213541.GA4201@stud.uni-karlsruhe.de> References: <200306111554.h5BFsXq3001831@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200306111554.h5BFsXq3001831@thunk.east.sun.com> User-Agent: Mutt/1.4.1i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, On Wed, Jun 11, 2003 at 11:54:33AM -0400, Bill Sommerfeld wrote: > > The FreeS/WAN project dropped single-DES support over four years ago, at > > management insistence. This caused surprisingly few interoperability > > problems. (There were one or two.) I think it is now quite safe to say > > that DES-only environments involve either obsolete software or specialized > > requirements -- a perfect case for SHOULD NOT. > > One more vote for SHOULD NOT. One more vote for SHOULD NOT. Single-DES should be treated like NULL cipher. It has been broken. People will start laughting at you if this goes into the RFC any different than SHOULD NOT. > - Bill -tp p.s. I actually know people who are already 'amused' that this topic requires such an extensive discussion. p.s.s.: History taught us that the 'we let it up to the user to decide'-attitude does not work in the real world. From jkathleengsfif27gln3er@msn.com Wed Jun 11 15:23:03 2003 Received: from hotmail.com (bay3-dav136.bay3.hotmail.com [65.54.169.166]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5BMN3rb090791 for ; Wed, 11 Jun 2003 15:23:03 -0700 (PDT) (envelope-from jkathleengsfif27gln3er@msn.com) Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Wed, 11 Jun 2003 15:23:00 -0700 Received: from 66.207.70.2 by bay3-dav136.bay3.hotmail.com with DAV; Wed, 11 Jun 2003 22:22:59 +0000 X-Originating-IP: [66.207.70.2] X-Originating-Email: [jkathleengsfif27gln3er@msn.com] To: "Ptomey Derflinger" Subject: Elude Expensive Septic Repairs From: "Goble Lio" Organization: Lj7O321DFG3RVlQ2s3WvJIEk2nKsw4qH Importance: Normal X-Originating-Ip: [3.6.851.6] Content-Type: multipart/alternative; boundary="F07jt66IBHQ5pw57Wt4tl33A6X32GUhQCTnF0ytTPX03Mv28k05mA07uxfBJn1IY3" Content-Transfer-Encoding: 7bit Message-ID: X-OriginalArrivalTime: 11 Jun 2003 22:23:00.0287 (UTC) FILETIME=[044504F0:01C33068] Date: 11 Jun 2003 15:23:00 -0700 --F07jt66IBHQ5pw57Wt4tl33A6X32GUhQCTnF0ytTPX03Mv28k05mA07uxfBJn1IY3 Content-Transfer-Encoding: 7bit Content-Type: text/html; charset="US-ASCII"
Dramatically Increase The Life And Effectiveness of Your Septic System.

Try SPC Septic Cleaner For Free By Clicking Here

You'll keep your septic system free flowing as SPC breaks down large waste materials into smaller
particles and liquids so that they pass quickly through your septic system.

Visit our site and try it for free.

To Take Yourself Off our list here
--F07jt66IBHQ5pw57Wt4tl33A6X32GUhQCTnF0ytTPX03Mv28k05mA07uxfBJn1IY3-- From owner-ipsec@lists.tislabs.com Wed Jun 11 18:49:53 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5C1nmrb097132; Wed, 11 Jun 2003 18:49:52 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA12918 Wed, 11 Jun 2003 21:11:45 -0400 (EDT) Date: Wed, 11 Jun 2003 21:16:25 -0400 (EDT) From: "Catherine A. Meadows" Message-Id: <200306120116.h5C1GPXT014125@itd.nrl.navy.mil> To: ipsec@lists.tislabs.com Subject: question about IKE on IPv4 and IPv6 Cc: meadows@itd.nrl.navy.mil X-Sun-Charset: US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've got a question about IKE that came up here today. It is: is there any way that a node running IPv6 sest up an IKE SA with a node IPv4? What about the same question for IKEv2? In either case, are there any implementations out there that do this? Thanks in advance, Cathy Meadows From owner-ipsec@lists.tislabs.com Thu Jun 12 02:40:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5C9e5rb043012; Thu, 12 Jun 2003 02:40:05 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA14612 Thu, 12 Jun 2003 05:00:09 -0400 (EDT) From: "Yoav Nir" To: "'Paul Hoffman / VPNC'" , "'David Wagner'" , Subject: RE: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms Date: Thu, 12 Jun 2003 12:04:05 +0200 Message-ID: <003101c330c9$f57681d0$292e1dc2@YnirNew> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Me too. With a statement that keys weaker than a certain level (say, 128 bits although 96 is probably enough) SHOULD NOT be used, I can live with DES being demoted to a SHOULD NOT. Still, I think that DES fits better with the definition of MAY: "One vendor may choose to include the item because a particular marketplace requires it or because the vendor feels that it enhances the product while another vendor may omit the same item." -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Paul Hoffman / VPNC Sent: Wednesday, June 11, 2003 9:31 PM To: David Wagner; ipsec@lists.tislabs.com Subject: Re: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms At 6:34 PM +0000 6/11/03, David Wagner wrote: >It's not what size keys the cipher supports that matters; it's what size >keys are standardized for use in IPSEc. Exactly right. >Maybe we should add a line to RFC2451 saying that users SHOULD NOT >use key sizes shorter than the default. There's no good reason to use >shorter keys. This addition would make everything consistent with a >SHOULD NOT policy for DES. Will this make everyone happy? It would certainly make me happier. That way, we would not be having different recommendations for IKEv1 than what we have for IKEv2. Actually, a complete revision to RFC 2451 would be nice, including removing algorithms for which there are not stable references. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Jun 12 06:48:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CDm2rb057165; Thu, 12 Jun 2003 06:48:02 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA15357 Thu, 12 Jun 2003 09:16:31 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16104.35977.651000.712505@gargle.gargle.HOWL> Date: Thu, 12 Jun 2003 10:22:01 -0400 From: Paul Koning To: ynir@CheckPoint.com Cc: paul.hoffman@vpnc.org, daw@mozart.cs.berkeley.edu, ipsec@lists.tislabs.com Subject: RE: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms References: <003101c330c9$f57681d0$292e1dc2@YnirNew> X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Yoav" == Yoav Nir writes: Yoav> Me too. With a statement that keys weaker than a certain level Yoav> (say, 128 bits although 96 is probably enough) SHOULD NOT be Yoav> used, I can live with DES being demoted to a SHOULD NOT. 96 is probably enough but it's not a common keysize, so 128 makes sense. Yoav> Still, I think that DES fits better with the definition of MAY: Yoav> "One vendor may choose to include the item because a particular Yoav> marketplace requires it or because the vendor feels that it Yoav> enhances the product while another vendor may omit the same Yoav> item." But "MAY" is neutral, it expresses no value judgement about the choice. "SHOULD NOT" also allows the vendor to choose but clearly recommends that you don't implement it. That's the messsage I'd like to see for short-key ciphers. paul From owner-ipsec@lists.tislabs.com Thu Jun 12 07:36:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CEa6rb062154; Thu, 12 Jun 2003 07:36:06 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15512 Thu, 12 Jun 2003 10:08:41 -0400 (EDT) Message-Id: <4.3.2.7.2.20030611151310.02bf0b00@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Wed, 11 Jun 2003 15:16:01 -0700 To: Russ Housley From: Barbara Fraser Subject: Re: Fwd: LAST CALL: IKE Crypto documents I-D's Cc: "Theodore Ts'o" , ipsec@lists.tislabs.com In-Reply-To: <5.2.0.9.2.20030611171254.03d82698@mail.binhost.com> References: <20030611143905.GB2575@think> <5.2.0.9.2.20030611141434.01fcb268@mail.binhost.com> <5.2.0.9.2.20030611141434.01fcb268@mail.binhost.com> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_28649565==_.ALT" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --=====================_28649565==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed Hi, Thanks for taking this process question to the IESG. Ted and I would like to urge the working group to focus on the technical content of these drafts. That's where the energy needs to be spent. thanks, Barb We'll deal with the appropriate handling of these documents as a At 02:18 PM 6/11/2003, Russ Housley wrote: >Ted: > >> > I am confused here. Based on the front matter in both documents, the >> > authors of each document appear to have Standards Track in >> mind. Standards >> > Track seems reasonable to me in both cases. >> >>Well, maybe we need to have a discussion the working group and the >>AD's about this question. The reason why Barbara and I thought >>Informational track would be more appropriate for >>draft-ietf-ipsec-ui-suites is because it doesn't actually impose any >>MUST's on the protocol, as defined as bits-on-the-wire. > >It does impact interoperability. If the same string is used by two >different vendors to mean different collections of algorithms, then the >protocol negations will probably fail in a reasonable way to people that >look at the actual packets. However, two administrators will say that the >boxes are configured in the same way, but they fail to interoperate. > >>So with no impliciations on bits-on-the-wire, what "at least two >>interoperable implementations" means is an interesting question >>indeed. >> >>On the other hand, there the IETF advanced the GSSAPI specifications >>as Proposed Standard even though there little to no protocol >>implication. That might argue that the ui-suites I-D should be a >>Proposed Standard, and we'll simply leave the headache of what >>"interoperable implementations" mean to the IESG in that case. >> >>All of this being said, neither Barbara nor I have any strong feelings >>on this matter, so we are certainly open to any strong sense from the >>wg, or direction from the AD's. > >I understand your points. I will discuss with the rest of the IESG and >report back. We happen to have a telechat scheduled for tomorrow, > >Russ --=====================_28649565==_.ALT Content-Type: text/html; charset="us-ascii" Hi,

Thanks for taking this process question to the IESG. Ted and I would like to urge the working group to focus on the technical content of these drafts. That's where the energy needs to be spent.

thanks,
Barb

We'll deal with the appropriate handling of these documents as a

At 02:18 PM 6/11/2003, Russ Housley wrote:
Ted:

> I am confused here.  Based on the front matter in both documents, the
> authors of each document appear to have Standards Track in mind.  Standards
> Track seems reasonable to me in both cases.

Well, maybe we need to have a discussion the working group and the
AD's about this question.  The reason why Barbara and I thought
Informational track would be more appropriate for
draft-ietf-ipsec-ui-suites is because it doesn't actually impose any
MUST's on the protocol, as defined as bits-on-the-wire.

It does impact interoperability.  If the same string is used by two different vendors to mean different collections of algorithms, then the protocol negations will probably fail in a reasonable way to people that look at the actual packets.  However, two administrators will say that the boxes are configured in the same way, but they fail to interoperate.

So with no impliciations on bits-on-the-wire, what "at least two
interoperable implementations" means is an interesting question
indeed.

On the other hand, there the IETF advanced the GSSAPI specifications
as Proposed Standard even though there little to no protocol
implication.  That might argue that the ui-suites I-D should be a
Proposed Standard, and we'll simply leave the headache of what
"interoperable implementations" mean to the IESG in that case.

All of this being said, neither Barbara nor I have any strong feelings
on this matter, so we are certainly open to any strong sense from the
wg, or direction from the AD's.

I understand your points.  I will discuss with the rest of the IESG and report back.  We happen to have a telechat scheduled for tomorrow,

Russ
--=====================_28649565==_.ALT-- From owner-ipsec@lists.tislabs.com Thu Jun 12 07:47:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CElkrb062715; Thu, 12 Jun 2003 07:47:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15574 Thu, 12 Jun 2003 10:20:42 -0400 (EDT) X-Authentication-Warning: desire.geoffk.org: geoffk set sender to geoffk@geoffk.org using -f To: Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com Subject: Re: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms References: <16103.11318.799282.793338@pkoning.dev.equallogic.com> <000401c33027$f5ca27b0$292e1dc2@YnirNew> <16103.13425.642338.266792@pkoning.dev.equallogic.com> From: Geoff Keating Date: 11 Jun 2003 14:44:57 -0700 In-Reply-To: Message-ID: Lines: 33 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman / VPNC writes: > At 9:53 AM -0400 6/11/03, Paul Koning wrote: > > >>>>> "Yoav" == Yoav Nir writes: > > > > Yoav> So RC4, Blowfish and IDEA are "MAY", but DES is "SHOULD NOT"? > > Yoav> I think those should be at least as discouraged as DES. > > > >Why? DES is known to be weak (inadequate key size), while the others > >are (unless I missed something recent) not substantially weaker than > >exhaustive search of their key. > > Any algorithm with a variable key size could be considerably weaker > than DES. Unless you are going to start listing key sizes and giving > each size a rating, saying SHOULD NOT for DES but MAY for some other > algorithm that can use 40-bit keys is silly. It might be a good idea to have a SHOULD NOT for too-short key lengths (maybe under 'Security Considerations'), independent of algorithm. The IKE RFC, for instance, says > For this reason, a prf function whose output is less than 128 bits > (e.g., 3DES-CBC) MUST never be used with this protocol. Proposed wording is: Implementors and administrators should carefully consider what algorithms and key sizes are appropriate for each situation; as a minimum, an implementation SHOULD NOT use an algorithm with a key size of 64 bits or less in its default configuration. -- - Geoffrey Keating From owner-ipsec@lists.tislabs.com Thu Jun 12 08:22:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CFMQrb064046; Thu, 12 Jun 2003 08:22:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA15678 Thu, 12 Jun 2003 10:54:27 -0400 (EDT) From: "Yoav Nir" To: Subject: RE: LAST CALL: IKE Crypto documents I-D's Date: Thu, 12 Jun 2003 17:58:53 +0200 Message-ID: <004801c330fb$8692fb90$292e1dc2@YnirNew> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It's good that we're getting there, but I still think we haven't addressed the issue of AES and key sizes. The algorithms draft refers only to AES-128. We should either add AES-256 or else rename the transforms to simply "ENCR_AES_CBC" and "ENCR_AES_CTR" and use the keylength attribute to determine the specific "flavor" or AES. IMO it doesn't make sense to use "ENCR_AES_128_CBC" with a 256-bit key. -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Theodore Ts'o Sent: Wednesday, June 11, 2003 2:06 PM To: ipsec@lists.tislabs.com Cc: byfraser@cisco.com Subject: LAST CALL: IKE Crypto documents I-D's This is a working group last call for comments on the following drafts. For progression to Proposed Standard: draft-ietf-ipsec-ikev2-algorithms-02.txt For progression to Informational: draft-ietf-ipsec-ui-suites-00.txt This last call with expire on June 23rd. - Ted and Barbara From owner-ipsec@lists.tislabs.com Thu Jun 12 10:06:09 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CH68rb071459; Thu, 12 Jun 2003 10:06:09 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA16085 Thu, 12 Jun 2003 12:26:20 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <16104.35977.651000.712505@gargle.gargle.HOWL> References: <003101c330c9$f57681d0$292e1dc2@YnirNew> <16104.35977.651000.712505@gargle.gargle.HOWL> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 12 Jun 2003 09:32:15 -0700 To: Paul Koning , ynir@CheckPoint.com From: Paul Hoffman / VPNC Subject: RE: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms Cc: daw@mozart.cs.berkeley.edu, ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:22 AM -0400 6/12/03, Paul Koning wrote: >96 is probably enough but it's not a common keysize, so 128 makes >sense. But only if you want to eliminate TripleDES, whose key size is 112 bits. No one counts the parity bits as meaningful. Yes, I'm being picky about this. As we have seen from IKEv1, sloppy wording which "everybody" understands at the time the RFC is issued becomes confusing and leads to lack of interoperability within a few short years. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Jun 12 10:57:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CHvkrb072919; Thu, 12 Jun 2003 10:57:46 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA16264 Thu, 12 Jun 2003 13:18:20 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16104.46887.397423.89027@pkoning.dev.equallogic.com> Date: Thu, 12 Jun 2003 13:23:51 -0400 From: Paul Koning To: paul.hoffman@vpnc.org Cc: ynir@CheckPoint.com, daw@mozart.cs.berkeley.edu, ipsec@lists.tislabs.com Subject: RE: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms References: <003101c330c9$f57681d0$292e1dc2@YnirNew> <16104.35977.651000.712505@gargle.gargle.HOWL> X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Paul" == Paul Hoffman > writes: Paul> At 10:22 AM -0400 6/12/03, Paul Koning wrote: >> 96 is probably enough but it's not a common keysize, so 128 makes >> sense. Paul> But only if you want to eliminate TripleDES, whose key size is Paul> 112 bits. No one counts the parity bits as meaningful. Indeed, one doesn't count the parity bits. So the 3DES key length is 168 bits, because IPsec uses 3-key 3DES. Paul> Yes, I'm being picky about this. As we have seen from IKEv1, Paul> sloppy wording which "everybody" understands at the time the Paul> RFC is issued becomes confusing and leads to lack of Paul> interoperability within a few short years. Agreed. paul From owner-ipsec@lists.tislabs.com Thu Jun 12 11:32:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CIWsrb074728; Thu, 12 Jun 2003 11:32:56 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16423 Thu, 12 Jun 2003 14:03:31 -0400 (EDT) To: Paul Hoffman / VPNC Cc: Paul Koning , ynir@CheckPoint.com, daw@mozart.cs.berkeley.edu, ipsec@lists.tislabs.com Subject: Re: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms References: <003101c330c9$f57681d0$292e1dc2@YnirNew> <16104.35977.651000.712505@gargle.gargle.HOWL> Reply-To: EKR From: Eric Rescorla Date: 12 Jun 2003 11:15:15 -0700 In-Reply-To: Message-ID: Lines: 16 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Paul Hoffman / VPNC writes: > At 10:22 AM -0400 6/12/03, Paul Koning wrote: > >96 is probably enough but it's not a common keysize, so 128 makes > >sense. > > But only if you want to eliminate TripleDES, whose key size is 112 > bits. No one counts the parity bits as meaningful. As I understand RFC 2451, the 3DES we uses is 3-key 3DES in EDE mode, so the effective key size should be 168 bits. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Thu Jun 12 12:28:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CJSgrb078082; Thu, 12 Jun 2003 12:28:42 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA16657 Thu, 12 Jun 2003 14:58:18 -0400 (EDT) Date: Thu, 12 Jun 2003 12:03:38 -0700 (PDT) From: Scott Fluhrer To: Eric Rescorla cc: Paul Hoffman / VPNC , Paul Koning , ynir@CheckPoint.com, daw@mozart.cs.berkeley.edu, ipsec@lists.tislabs.com Subject: Re: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms In-Reply-To: Message-ID: References: <003101c330c9$f57681d0$292e1dc2@YnirNew> <16104.35977.651000.712505@gargle.gargle.HOWL> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 12 Jun 2003, Eric Rescorla wrote: > Paul Hoffman / VPNC writes: > > > At 10:22 AM -0400 6/12/03, Paul Koning wrote: > > >96 is probably enough but it's not a common keysize, so 128 makes > > >sense. > > > > But only if you want to eliminate TripleDES, whose key size is 112 > > bits. No one counts the parity bits as meaningful. > As I understand RFC 2451, the 3DES we uses is 3-key 3DES in > EDE mode, so the effective key size should be 168 bits. For a cryptographical standpoint, there may be 168 distinct key bits that affect the ciphertext, but it is well known that you can break 3DES with far less work than O(2**168) effort. There is a meet-in-the-middle attack that (with a lot of memory) brings the effort down to around O(2**112), which is what I assume Paul was refering to. In addition, if you have vast quantities of known plaintext encrypted with the same key, Stephan Lucks' attack becomes interesting, which reduces the effort a bit more (I don't have a solid estimate at hand). Neither of these attacks are practical given current current limitations, but one should remember that they do exist. -- scott From owner-ipsec@lists.tislabs.com Thu Jun 12 12:50:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CJoCrb078605; Thu, 12 Jun 2003 12:50:13 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA16691 Thu, 12 Jun 2003 15:14:47 -0400 (EDT) To: Scott Fluhrer Cc: Paul Hoffman / VPNC , Paul Koning , ynir@CheckPoint.com, daw@mozart.cs.berkeley.edu, ipsec@lists.tislabs.com Subject: Re: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms References: <003101c330c9$f57681d0$292e1dc2@YnirNew> <16104.35977.651000.712505@gargle.gargle.HOWL> Reply-To: EKR From: Eric Rescorla Date: 12 Jun 2003 12:26:28 -0700 In-Reply-To: Message-ID: Lines: 41 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott Fluhrer writes: > On Thu, 12 Jun 2003, Eric Rescorla wrote: > > > Paul Hoffman / VPNC writes: > > > > > At 10:22 AM -0400 6/12/03, Paul Koning wrote: > > > >96 is probably enough but it's not a common keysize, so 128 makes > > > >sense. > > > > > > But only if you want to eliminate TripleDES, whose key size is 112 > > > bits. No one counts the parity bits as meaningful. > > As I understand RFC 2451, the 3DES we uses is 3-key 3DES in > > EDE mode, so the effective key size should be 168 bits. > > For a cryptographical standpoint, there may be 168 distinct key bits that > affect the ciphertext, but it is well known that you can break 3DES with > far less work than O(2**168) effort. There is a meet-in-the-middle attack > that (with a lot of memory) brings the effort down to around O(2**112), > which is what I assume Paul was refering to. Uh, "lot" means O(2**56), no? >> In addition, if you have > vast quantities of known plaintext encrypted with the same key, Stephan > Lucks' attack becomes interesting, which reduces the effort a bit more > (I don't have a solid estimate at hand). > > Neither of these attacks are practical given current current limitations, > but one should remember that they do exist. Sure, but under practical conditions the effective key size of 3DES-EDE3 168 bits and it's conventional to refer to it this way. In the same way, it's conventional to refer to DES as having a strength of 56 bits despite the fact that if you somehow laid your hands on 2^47 chosen plaintexts the complexity of DES would be a measly O(2^47). -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Thu Jun 12 13:04:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CK4grb079081; Thu, 12 Jun 2003 13:04:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA16783 Thu, 12 Jun 2003 15:37:07 -0400 (EDT) Date: Thu, 12 Jun 2003 12:42:26 -0700 (PDT) From: Scott Fluhrer To: Eric Rescorla cc: Paul Hoffman / VPNC , Paul Koning , ynir@CheckPoint.com, daw@mozart.cs.berkeley.edu, ipsec@lists.tislabs.com Subject: Re: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms In-Reply-To: Message-ID: References: <003101c330c9$f57681d0$292e1dc2@YnirNew> <16104.35977.651000.712505@gargle.gargle.HOWL> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 12 Jun 2003, Eric Rescorla wrote: > Scott Fluhrer writes: > > > On Thu, 12 Jun 2003, Eric Rescorla wrote: > > > > > Paul Hoffman / VPNC writes: > > > > > > > At 10:22 AM -0400 6/12/03, Paul Koning wrote: > > > > >96 is probably enough but it's not a common keysize, so 128 makes > > > > >sense. > > > > > > > > But only if you want to eliminate TripleDES, whose key size is 112 > > > > bits. No one counts the parity bits as meaningful. > > > As I understand RFC 2451, the 3DES we uses is 3-key 3DES in > > > EDE mode, so the effective key size should be 168 bits. > > > > For a cryptographical standpoint, there may be 168 distinct key bits that > > affect the ciphertext, but it is well known that you can break 3DES with > > far less work than O(2**168) effort. There is a meet-in-the-middle attack > > that (with a lot of memory) brings the effort down to around O(2**112), > > which is what I assume Paul was refering to. > Uh, "lot" means O(2**56), no? Well, yes, but the attack scales to lesser amounts of memory. If you had only O(2**40) memory, then the attack works in O(2**128) time -- still far less than 2**168. > > >> In addition, if you have > > vast quantities of known plaintext encrypted with the same key, Stephan > > Lucks' attack becomes interesting, which reduces the effort a bit more > > (I don't have a solid estimate at hand). > > > > Neither of these attacks are practical given current current limitations, > > but one should remember that they do exist. > > Sure, but under practical conditions the effective key size of > 3DES-EDE3 168 bits Actually, as I pointed out above, even if you restrict the amount of memory an attacker has available to a reaonable amount, the strength of 3DES is still less than 168 bits. > and it's conventional to refer to it this way. Conventional, perhaps, to people who aren't too concerned with precision (although, in my experience, the estimate of 112 bits is rather more common). On the IPSec mailing list, we're supposed to be (one of the) IETF expert groups on security -- I would hope that some greater amount of precision is appropriate. > In the same way, it's conventional to refer to DES as having a strength > of 56 bits despite the fact that if you somehow laid your hands on 2^47 > chosen plaintexts the complexity of DES would be a measly O(2^47). Actually, if you're refering to linear cryptanalysis, the common result is that it takes 2^47 known plaintexts. -- scott From owner-ipsec@lists.tislabs.com Thu Jun 12 13:20:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CKK0rb079563; Thu, 12 Jun 2003 13:20:05 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA16849 Thu, 12 Jun 2003 15:54:10 -0400 (EDT) Date: Thu, 12 Jun 2003 23:00:28 +0300 (IDT) From: Hugo Krawczyk To: IPsec WG Subject: full version of the SIGMA paper Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It is now available (as postscript) via http://www.ee.technion.ac.il/~hugo/sigma.html In general, the paper tries to answer the many questions asked (and some of those never asked) regarding the design of the signature modes of IKE v1 and IKE v2. It now also includes an appendix describing the rationale for the key derivation techniques in IKE. MAY+ be you SHOULD- consider reading the paper a MUST+- :) Hugo From owner-ipsec@lists.tislabs.com Thu Jun 12 15:32:28 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CMWOrb084465; Thu, 12 Jun 2003 15:32:28 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA17307 Thu, 12 Jun 2003 17:52:14 -0400 (EDT) Cc: Scott Fluhrer , Paul Hoffman / VPNC , Paul Koning , ynir@CheckPoint.com, daw@mozart.cs.berkeley.edu, ipsec@lists.tislabs.com Subject: Re: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms In-reply-to: Your message of "12 Jun 2003 14:59:23 PDT." X-Mailer: mh-e 6.1; nmh 1.0.4; Emacs 21.1 Date: Thu, 12 Jun 2003 15:03:54 -0700 From: Eric Rescorla Message-Id: <20030612220354.D365E73B5@sierra.rtfm.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Just so we're clear. > Scott Fluhrer writes: > > On Thu, 12 Jun 2003, Eric Rescorla wrote: > > > > For a cryptographical standpoint, there may be 168 distinct key bits that > > > > affect the ciphertext, but it is well known that you can break 3DES with > > > > far less work than O(2**168) effort. There is a meet-in-the-middle attack > > > > that (with a lot of memory) brings the effort down to around O(2**112), > > > > which is what I assume Paul was refering to. > > > Uh, "lot" means O(2**56), no? > > > > Well, yes, but the attack scales to lesser amounts of memory. If you > > had only O(2**40) memory, then the attack works in O(2**128) time -- > > still far less than 2**168. > And if you have O(2^336) blocks of memory then you could do in > O(1) steps. And of course, if you paid the modest O(2^336) precomputation cost. > > > In the same way, it's conventional to refer to DES as having a strength > > > of 56 bits despite the fact that if you somehow laid your hands on 2^47 > > > chosen plaintexts the complexity of DES would be a measly O(2^47). > > Actually, if you're refering to linear cryptanalysis, the common result is > > that it takes 2^47 known plaintexts. > No, I'm referring to differential. See the HAC, pag 259. > Not that it really matters. Of course, it matters in some cosmic sense, but for the current purposes, its merely "impractically large". -Ekr From owner-ipsec@lists.tislabs.com Thu Jun 12 15:33:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5CMXjrb084483; Thu, 12 Jun 2003 15:33:45 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA17298 Thu, 12 Jun 2003 17:48:12 -0400 (EDT) To: Scott Fluhrer Cc: Paul Hoffman / VPNC , Paul Koning , ynir@CheckPoint.com, daw@mozart.cs.berkeley.edu, ipsec@lists.tislabs.com Subject: Re: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms References: <003101c330c9$f57681d0$292e1dc2@YnirNew> <16104.35977.651000.712505@gargle.gargle.HOWL> Reply-To: EKR From: Eric Rescorla Date: 12 Jun 2003 14:59:23 -0700 In-Reply-To: Message-ID: Lines: 40 User-Agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (Cuyahoga Valley) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott Fluhrer writes: > On Thu, 12 Jun 2003, Eric Rescorla wrote: > > > For a cryptographical standpoint, there may be 168 distinct key bits that > > > affect the ciphertext, but it is well known that you can break 3DES with > > > far less work than O(2**168) effort. There is a meet-in-the-middle attack > > > that (with a lot of memory) brings the effort down to around O(2**112), > > > which is what I assume Paul was refering to. > > Uh, "lot" means O(2**56), no? > > Well, yes, but the attack scales to lesser amounts of memory. If you > had only O(2**40) memory, then the attack works in O(2**128) time -- > still far less than 2**168. And if you have O(2^336) blocks of memory then you could do in O(1) steps. > > Sure, but under practical conditions the effective key size of > > 3DES-EDE3 168 bits > Actually, as I pointed out above, even if you restrict the amount of > memory an attacker has available to a reaonable amount, the strength of > 3DES is still less than 168 bits. Only if you behave as if memory is costless. > On the IPSec mailing list, we're supposed to be (one of the) IETF expert > groups on security -- I would hope that some greater amount of precision > is appropriate. I don't consider ignoring the cost of memory particularly precise. > > In the same way, it's conventional to refer to DES as having a strength > > of 56 bits despite the fact that if you somehow laid your hands on 2^47 > > chosen plaintexts the complexity of DES would be a measly O(2^47). > Actually, if you're refering to linear cryptanalysis, the common result is > that it takes 2^47 known plaintexts. No, I'm referring to differential. See the HAC, pag 259. Not that it really matters. -Ekr -- [Eric Rescorla ekr@rtfm.com] http://www.rtfm.com/ From owner-ipsec@lists.tislabs.com Fri Jun 13 05:25:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5DCPvrb042865; Fri, 13 Jun 2003 05:25:58 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA19773 Fri, 13 Jun 2003 07:52:15 -0400 (EDT) Message-Id: <5.2.0.9.2.20030613075414.037a7498@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 13 Jun 2003 07:57:50 -0400 To: ipsec@lists.tislabs.com From: Russ Housley Subject: Re: Fwd: LAST CALL: IKE Crypto documents I-D's Cc: tytso@mit.edu, byfraser@cisco.com, phoffman@imc.org In-Reply-To: <4.3.2.7.2.20030611151310.02bf0b00@mira-sjc5-4.cisco.com> References: <5.2.0.9.2.20030611171254.03d82698@mail.binhost.com> <20030611143905.GB2575@think> <5.2.0.9.2.20030611141434.01fcb268@mail.binhost.com> <5.2.0.9.2.20030611141434.01fcb268@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have some advice from the IESG on draft-ietf-ipsec-ui-suites. It comes in the form of two suggestions. First, change the structure of draft-ietf-ipsec-ui-suites so that it establishes an IANA registry for the ASCII strings that identify the suites. Second, publish draft-ietf-ipsec-ui-suites as a BCP. Russ At 03:16 PM 6/11/2003 -0700, Barbara Fraser wrote: >Hi, > >Thanks for taking this process question to the IESG. Ted and I would like >to urge the working group to focus on the technical content of these >drafts. That's where the energy needs to be spent. > >thanks, >Barb > >We'll deal with the appropriate handling of these documents as a > >At 02:18 PM 6/11/2003, Russ Housley wrote: >>Ted: >> >>> > I am confused here. Based on the front matter in both documents, the >>> > authors of each document appear to have Standards Track in >>> mind. Standards >>> > Track seems reasonable to me in both cases. >>> >>>Well, maybe we need to have a discussion the working group and the >>>AD's about this question. The reason why Barbara and I thought >>>Informational track would be more appropriate for >>>draft-ietf-ipsec-ui-suites is because it doesn't actually impose any >>>MUST's on the protocol, as defined as bits-on-the-wire. >> >>It does impact interoperability. If the same string is used by two >>different vendors to mean different collections of algorithms, then the >>protocol negations will probably fail in a reasonable way to people that >>look at the actual packets. However, two administrators will say that >>the boxes are configured in the same way, but they fail to interoperate. >> >>>So with no impliciations on bits-on-the-wire, what "at least two >>>interoperable implementations" means is an interesting question >>>indeed. >>> >>>On the other hand, there the IETF advanced the GSSAPI specifications >>>as Proposed Standard even though there little to no protocol >>>implication. That might argue that the ui-suites I-D should be a >>>Proposed Standard, and we'll simply leave the headache of what >>>"interoperable implementations" mean to the IESG in that case. >>> >>>All of this being said, neither Barbara nor I have any strong feelings >>>on this matter, so we are certainly open to any strong sense from the >>>wg, or direction from the AD's. >> >>I understand your points. I will discuss with the rest of the IESG and >>report back. We happen to have a telechat scheduled for tomorrow, >> >>Russ From owner-ipsec@lists.tislabs.com Fri Jun 13 05:26:38 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5DCQbrb042890; Fri, 13 Jun 2003 05:26:38 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA19772 Fri, 13 Jun 2003 07:52:14 -0400 (EDT) Message-Id: <5.2.0.9.2.20030612171804.01f5fc78@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 12 Jun 2003 17:32:16 -0400 To: ipsec@lists.tislabs.com From: Russ Housley Subject: WG Last Call: draft-ietf-ipsec-esn-addendum-01 Cc: kent@bbn.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have two comments on draft-ietf-ipsec-esn-addendum-01. 1. I propose an alternative Abstract. The IP Security Authentication Header (AH) and Encapsulating Security Payload (ESP) protocols use a sequence number to detect replay. This document describes extensions to the Internet IP Security Domain of Interpretation (DOI) for Internet Security Association and Key Management Protocol (ISAKMP) to negotiate the use of traditional 32-bit sequence numbers or extended 64-bit sequence numbers for a particular AH or ESP security association. 2. It would be helpful if the IANA Considerations section indicated the portion of the registry where the TBD value needs to be assigned. Russ From owner-ipsec@lists.tislabs.com Fri Jun 13 07:17:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5DEHHrb052137; Fri, 13 Jun 2003 07:17:17 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA20110 Fri, 13 Jun 2003 09:47:26 -0400 (EDT) Message-ID: <59697CCC6CE3D411B4CD00805FBB776704148126@gbrwgcms03.wgc.gbr.xerox.com> From: "Brookes, Stuart P" To: "'ipsec@lists.tislabs.com'" Subject: Implementing an IPsec MIB? Advice/Opinions sought? Date: Fri, 13 Jun 2003 10:02:55 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2654.89) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I am fairly new to SNMP & MIBs. I need to add a new read-only MIB object that will inform whether IPsec is enabled or disabled... I think the IPsec Monitoring MIB is too low-level for what I require. So I have looked at the IPsec Flow Monitoring MIB draft document. Because I am new to this, I'm not sure exactly what I have to implement. I have been asked if it possible to just implement some sort of single MIB object that will display whether IPsec is enabled or disabled? Is this possible? Do I have to implement various other MIBs in order to do this? As a result, in terms of documentation, where are these MIB objects stored? I was presuming they are placed under the IP Group of MIB objects, am I wrong? If so, where should they be located? I hope this is not to basic and I am not asking stupid questions. As I say, I am pretty much learning as I go along... Regards Stuart From owner-ipsec@lists.tislabs.com Fri Jun 13 07:57:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5DEv6rb053877; Fri, 13 Jun 2003 07:57:06 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA20327 Fri, 13 Jun 2003 10:29:32 -0400 (EDT) Date: Fri, 13 Jun 2003 16:32:09 +0200 From: Markus Friedl To: ipsec@lists.tislabs.com Cc: Paul Hoffman / VPNC , Jakob Schlyter , =?iso-8859-1?Q?H=E5kan?= Olsson Subject: Re: NAT-T Message-ID: <20030613143209.GA5863@folly> References: <20030612114352.GA28314@folly> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.1i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Paul Hoffman think is hould take this to the WG list: We are trying to add support for NAT-T to the OpenBSD IPsec stack, but because of the confusing IPR claims about NAT-T (e.g. http://www.ietf.org/ietf/IPR/MICROSOFT-NAT-Traversal.txt) we are not sure what part of NAT-T can be integrated into OpenBSD without risking patent related problems. Any help appreciated, -markus On Thu, Jun 12, 2003 at 09:09:23AM -0700, Paul Hoffman / VPNC wrote: > At 1:43 PM +0200 6/12/03, Markus Friedl wrote: > >On Wed, Jun 11, 2003 at 12:38:32PM -0700, Paul Hoffman / VPNC wrote: > >> >If Microsoft's contribution(s) is(are) included in an IETF standard and > >> >Microsoft has patent rights that are essential to implement such > >> >standard, Microsoft is prepared to grant a license to the necessary > >> >claims of Microsoft patent rights, to the extent that such claims are > >> >required to implement that IETF standard, on a royalty-free basis with > >> >other reasonable and non-discriminatory terms and conditions, provided a > >> >reciprocal license is granted to Microsoft for any patent claims > >> >necessary to implement the following IETF NAT-Traversal drafts: > >> > and > >> >. > >> > >> Hope this helps. > > > >Hm, the problem with this statement is, that's almost of no value. > >It states "Microsoft is prepared to grant a license", "If Microsoft's > >contribution(s) is(are) included in an IETF standard", so this text > >grants nothing and can be applied to anything. > > Actually, that's standard wording for IETF IPR for companies doing > The Right Thing. Companies doing The Typical Thing do not include the > "royalty-free" clause. So Microsoft is being good here. > > >So I'm not sure what part of NAT-T can be integrated into OpenBSD > >without risking patent related problems. > > That is always true. And you certainly shouldn't do anything until > whatever Microsoft claims becomes part of a standard. That is, if it > doesn't become part of a standard, Microsoft isn't giving away > anything (and I agree with that stance on their part). > > You might want to take this to the WG mailing list. > > --Paul Hoffman, Director > --VPN Consortium From owner-ipsec@lists.tislabs.com Fri Jun 13 09:54:17 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5DGsCrb062311; Fri, 13 Jun 2003 09:54:17 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA20740 Fri, 13 Jun 2003 12:23:20 -0400 (EDT) To: John Shriver Cc: Barbara Fraser , tytso@mit.edu, angelos@cs.columbia.edu, Bert Wijnen , "Hilarie Orman, Purple Streak Development" , Luis Sanchez , "C. M. Heard" , Russ Housley , Paul Hoffman / VPNC , ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-doi-tc-mib-07.txt and friends References: <4.3.2.7.2.20030606162749.04395f00@mira-sjc5-4.cisco.com> <3EE490E7.8080101@sockeye.com> From: Wes Hardaker X-Face: #qW^}a%m*T^{A:Cp}$R\"38+d}41-Z}uU8,r%F#c#s:~Nzp0G9](s?,K49KJ]s"*7gvRgA SrAvQc4@/}L7Qc=w{)]ACO\R{LF@S{pXfojjjGg6c;q6{~C}CxC^^&~(F]`1W)%9j/iS/ IM",B1M.?{w8ckLTYD'`|kTr\i\cgY)P4 Organization: Network Associates Laboratories Date: Fri, 13 Jun 2003 09:29:05 -0700 In-Reply-To: <3EE490E7.8080101@sockeye.com> (John Shriver's message of "Mon, 09 Jun 2003 09:51:35 -0400") Message-ID: User-Agent: Gnus/5.1002 (Gnus v5.10.2) XEmacs/21.5 (brussels sprouts, linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> On Mon, 09 Jun 2003 09:51:35 -0400, John Shriver said: John> Absolutely. The problem is that we lack a consensus on what to John> do about Mike Heard's comments. I'm pretty sure I remember posting quite a few posts about it (on your side of things). Also, there were a lot of other discussions (off-list) held by the MIB experts that sided with Mike... John> I suspect that nobody is implementing the related MIBs. The IPSEC-POLICY-MIB has already been implemented (see the net-policy project on sourceforge for details), which does depend on your draft to date. Specifically, I really need to know if your going to publish a new draft or not and send it through last call. If you don't, I'll need to remove the dependencies from the IPSEC-POLICY-MIB. >> 2. We need to come to agreement on what changes are needed, that is >> we must address the MIB doctor comments. John> Well, I can make the changes from enumerations to simple typedefs. John> The real question is whether the IPSP folks are still interested in John> using this MIB if it doesn't have the enumerations in it. To me, that John> was the primary value of the MIB, and why I convinced Tim to let me do John> it. He was just exporting the variables as INTEGERs, which I found John> unfriendly. At least with any of the tools inheriting from the CMU John> ones, the enumerations are much more useful. John> So, IPSP folks (you are on the CC: list, right?), do you still want John> this MIB without the enumerations? If so, I'll make Mike's changes, John> and ship it out again. I'd do it just because it still provides a standard convention for the datatypes and a standard place where the documentation about them can be listed. However, I agree it's less useful with the enums removed. >> draft-ietf-ipsec-ike-monitor-mib-04.txt, >> draft-ietf-ipsec-isakmp-di-mon-mib-05.txt, and >> draft-ietf-ipsec-monitor-mib-06.txt? John> I think we can let them die, unless someone someone is wanting them. I think they'd be useful, but I haven't read them recently. The concepts in them are definitely needed and I've spoken to various people lately about them and they agree that they'd be useful to put into their products. However, that doesn't mean they will. -- Wes Hardaker Network Associates Laboratories From owner-ipsec@lists.tislabs.com Fri Jun 13 11:35:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5DIZ4rb066459; Fri, 13 Jun 2003 11:35:09 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA20985 Fri, 13 Jun 2003 13:59:25 -0400 (EDT) Message-ID: <3EEA10F7.1070402@sockeye.com> Date: Fri, 13 Jun 2003 13:59:19 -0400 From: John Shriver Organization: Sockeye Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Wes Hardaker CC: John Shriver , Barbara Fraser , tytso@mit.edu, angelos@cs.columbia.edu, Bert Wijnen , "Hilarie Orman, Purple Streak Development" , Luis Sanchez , "C. M. Heard" , Russ Housley , Paul Hoffman / VPNC , ipsec@lists.tislabs.com Subject: Re: draft-ietf-ipsec-doi-tc-mib-07.txt and friends References: <4.3.2.7.2.20030606162749.04395f00@mira-sjc5-4.cisco.com> <3EE490E7.8080101@sockeye.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Wes Hardaker wrote: >>>>>>On Mon, 09 Jun 2003 09:51:35 -0400, John Shriver said: >>>>> > > John> Absolutely. The problem is that we lack a consensus on what to > John> do about Mike Heard's comments. > > I'm pretty sure I remember posting quite a few posts about it (on your > side of things). > > Also, there were a lot of other discussions (off-list) held by the MIB > experts that sided with Mike... Yes. But only a very small percentage of the WG has anything to say. Perhaps the absence of dissent counts as consensus... > > John> I suspect that nobody is implementing the related MIBs. > > The IPSEC-POLICY-MIB has already been implemented (see the net-policy > project on sourceforge for details), which does depend on your draft > to date. Specifically, I really need to know if your going to publish > a new draft or not and send it through last call. If you don't, I'll > need to remove the dependencies from the IPSEC-POLICY-MIB. > I meant the three IPSec MIB that Tim and I did. I know that the policy MIB has legs. > >>>2. We need to come to agreement on what changes are needed, that is >>>we must address the MIB doctor comments. >> > > John> Well, I can make the changes from enumerations to simple typedefs. > John> The real question is whether the IPSP folks are still interested in > John> using this MIB if it doesn't have the enumerations in it. To me, that > John> was the primary value of the MIB, and why I convinced Tim to let me do > John> it. He was just exporting the variables as INTEGERs, which I found > John> unfriendly. At least with any of the tools inheriting from the CMU > John> ones, the enumerations are much more useful. > > John> So, IPSP folks (you are on the CC: list, right?), do you still want > John> this MIB without the enumerations? If so, I'll make Mike's changes, > John> and ship it out again. > > I'd do it just because it still provides a standard convention for the > datatypes and a standard place where the documentation about them > can be listed. However, I agree it's less useful with the enums removed. > Well, I will go ahead and do those changes. I've even been working on MIBs in my paying job recently. > >>>draft-ietf-ipsec-ike-monitor-mib-04.txt, >>>draft-ietf-ipsec-isakmp-di-mon-mib-05.txt, and >>>draft-ietf-ipsec-monitor-mib-06.txt? >> > > John> I think we can let them die, unless someone someone is wanting them. > > I think they'd be useful, but I haven't read them recently. The > concepts in them are definitely needed and I've spoken to various > people lately about them and they agree that they'd be useful to put > into their products. However, that doesn't mean they will. > If we were to keep them alive, they would need to migrate to IKEv2, which is no small project. I don't see any point in MIB-ing IKEv1. There would need to be authors who were committed to implementing it. From owner-ipsec@lists.tislabs.com Fri Jun 13 13:29:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5DKTNrb072150; Fri, 13 Jun 2003 13:29:23 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA21466 Fri, 13 Jun 2003 15:56:25 -0400 (EDT) Message-ID: <3EEA2CF9.50106@sockeye.com> Date: Fri, 13 Jun 2003 15:58:49 -0400 From: John Shriver Organization: Sockeye Networks User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20020826 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: abandoning ike-monitor-mib, isakmp-di-mon-mib, and monitor-mib? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk OK, let's try and sort out the MIB issues one decision at a time. The first thing is to decide if we want to abandon the original set of MIBs: draft-ietf-ipsec-ike-monitor-mib-04.txt, draft-ietf-ipsec-isakmp-di-mon-mib-05.txt, and draft-ietf-ipsec-monitor-mib-06.txt They have never attracted much interest. Neither of the original authors work in the IPsec marketplace anymore, so they can't contribute any implementations to get them through the standards process. I think that there is only one implementation of them, ever. Moreover, both the ISAKMP and IKE MIB modules would require MAJOR rewriting to be compatible with IKE Version 2. Like merging them, since the ISAKMP/IKE layering is extinct in v2. So, given this set of considerable problems, is there anyone who wants these MIBs to track the IPsec standards going forwards, and can find resources to update them and implement them? If nobody wants to do this, will we take the lack of any dissent on their death as "consensus" per the "IETF Process"? I *NEED* to know this, because there are a number of TEXTUAL-CONVENTIONS in the doi-tc-mib that were only used by these three MIBs, and are not used by the IPsec flow MIB, or by the Policy MIB. Since it looks like the doi-tc-mib will NOT be maintained by the IANA (no enumerations), the TC's have to be used in some MIB to progress through the standards process, so we can't stock up on "spare" TCs for possible future needs. So, please consider this a "last call", only for termination instead of promotion along the standards track. From owner-ipsec@lists.tislabs.com Fri Jun 13 14:05:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5DL5Wrb073475; Fri, 13 Jun 2003 14:05:32 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA21626 Fri, 13 Jun 2003 16:38:46 -0400 (EDT) From: rks@cisco.com Date: Fri, 13 Jun 2003 13:44:16 -0700 (PDT) To: John Shriver cc: Leo Temoshenko , Bret Harrison , ipsec@lists.tislabs.com Subject: Re: abandoning ike-monitor-mib, isakmp-di-mon-mib, and monitor-mib? In-Reply-To: <3EEA2CF9.50106@sockeye.com> Message-ID: References: <3EEA2CF9.50106@sockeye.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk About the TCs alone: as you and Mike Heard have pointed out, ipsec-flowmon-mib-tc duplicates much of doi-tc-mib. Since the latter is also used by the Policy MIB, I feel that it would be better for the Flow MIB to be layered on the same set of textual conventions. I hope that you would include the couple of TCs which the Flow MIB needs which are missing in your draft. Thanks, Rk x77309 On Fri, 13 Jun 2003, John Shriver wrote: > OK, let's try and sort out the MIB issues one decision at a time. The > first thing is to decide if we want to abandon the original set of MIBs: > > draft-ietf-ipsec-ike-monitor-mib-04.txt, > draft-ietf-ipsec-isakmp-di-mon-mib-05.txt, and > draft-ietf-ipsec-monitor-mib-06.txt > > They have never attracted much interest. Neither of the original > authors work in the IPsec marketplace anymore, so they can't contribute > any implementations to get them through the standards process. I think > that there is only one implementation of them, ever. > > Moreover, both the ISAKMP and IKE MIB modules would require MAJOR > rewriting to be compatible with IKE Version 2. Like merging them, since > the ISAKMP/IKE layering is extinct in v2. > > So, given this set of considerable problems, is there anyone who wants > these MIBs to track the IPsec standards going forwards, and can find > resources to update them and implement them? > > If nobody wants to do this, will we take the lack of any dissent on > their death as "consensus" per the "IETF Process"? > > > I *NEED* to know this, because there are a number of TEXTUAL-CONVENTIONS > in the doi-tc-mib that were only used by these three MIBs, and are not > used by the IPsec flow MIB, or by the Policy MIB. Since it looks like > the doi-tc-mib will NOT be maintained by the IANA (no enumerations), the > TC's have to be used in some MIB to progress through the standards > process, so we can't stock up on "spare" TCs for possible future needs. > > > So, please consider this a "last call", only for termination instead of > promotion along the standards track. > > From owner-ipsec@lists.tislabs.com Fri Jun 13 15:42:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5DMgIrb075882; Fri, 13 Jun 2003 15:42:19 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA22098 Fri, 13 Jun 2003 18:13:10 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Fri, 13 Jun 2003 15:19:12 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: ipsec@lists.tislabs.com cc: Bert Wijnen Subject: Re: draft-ietf-ipsec-doi-tc-mib-07.txt and friends In-Reply-To: <3EEA10F7.1070402@sockeye.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [ Discussion moved to IPsec list at Barbare Fraser's request. ] On Fri, 13 Jun 2003, John Shriver wrote: JS> Wes Hardaker wrote: JS> > John> So, IPSP folks (you are on the CC: list, right?), do you JS> > John> still want this MIB without the enumerations? If so, JS> > John> I'll make Mike's changes, and ship it out again. JS> > JS> > I'd do it just because it still provides a standard convention JS> > for the datatypes and a standard place where the documentation JS> > about them can be listed. However, I agree it's less useful JS> > with the enums removed. JS> > JS> JS> Well, I will go ahead and do those changes. I've even been working JS> on MIBs in my paying job recently. Sounds good. JS> >>>draft-ietf-ipsec-ike-monitor-mib-04.txt, JS> >>>draft-ietf-ipsec-isakmp-di-mon-mib-05.txt, and JS> >>>draft-ietf-ipsec-monitor-mib-06.txt? JS> >> JS> > JS> > John> I think we can let them die, unless someone someone is JS> > John> wanting them. JS> > JS> > I think they'd be useful, but I haven't read them recently. The JS> > concepts in them are definitely needed and I've spoken to various JS> > people lately about them and they agree that they'd be useful to put JS> > into their products. However, that doesn't mean they will. JS> > JS> JS> If we were to keep them alive, they would need to migrate to IKEv2, JS> which is no small project. I don't see any point in MIB-ing IKEv1. JS> JS> There would need to be authors who were committed to implementing it. On the other hand, there is an author committed to finishing off the IPsec Flow Monitor MIB module: >>>>> On Fri, 13 Jun 2003 rks@cisco.com wrote: RKS> We are still pursuing the IPsec Flow Monitor for standard track. RKS> Could you please list the TopN good points of the drafts listed RKS> above which may be incoprorated into the Flow Monitor MIB? RKS> RKS> I know you dissected at length the Flow Monitor MIB in 2001. RKS> While I have read that (and addressed many of those criticisms RKS> in the latest draft), I am hoping you could identify what features RKS> of the MIBs listed above we could borrow into the Flow Monitor MIB. Currently there is a flow monitor TC MIB that duplicates a lot of the functionality of John's DOI TC MIB, which would be hard to accept, but the flow mon mib author has indicated that he's willing to switch: >>>>> On Mon, 9 Jun 2003 rks@cisco.com wrote: RKS> All that is of course irrelevant in addressing your comment about RKS> duplication. I am quite willing to base the Flow Monitor MIB on the RKS> textual conventions defined in draft-ietf-ipsec-doi-tc-mib-07.txt RKS> provided it accomodates the textual convention defining the Control RKS> Protocol: the IPsec Flow MIB can support different keying protocols RKS> based on ISAKMP (termed 'control protocol') and uses a distinct TC RKS> to type this value. Actually, there are two TCs in the flow monitor TC MIB that are not accounted for. One is ControlProtocol, mentioned above, and the other is Spi. After looking over the Flow Monitor MIB in more detail, I see that ControlProtocol (formerly named KeyType) does not represent an actual field in a PDU whose value is defined in an IANA registry -- which is the case for everything currently defined in the DOI TC MIB -- but instead just serves to identify keying and control protocols in the flow monitor MIB. In my opinion a TC local to the IPsec Flow monitor MIB (preferably with a less generic a name like IPsecFlowMonControlProto) would suffice for that purpose. If it is really supposed to reflect the content of an IANA registry, then there is already such a TC in the DOI TC MIB; it is called IpsecDoiTransformIdent, and it represents values recorded the "IPSEC ISAKMP Transform Identifiers" entry in the IANA registry http://www.iana.org//assignments/isakmp-registry Now, the Spi TC (as I understand it) is supposed to represent possible SPI values for AH (RFC 2402), ESP (RFC 2406), and IPComp (RFC 3173). The IANA registry http://www.iana.org//assignments/spi-numbers captures the special values for AH and ESP. For IPComp the special values are different: they are "IPCOMP Transform identifiers" and are recorded in http://www.iana.org//assignments/isakmp-registry (and represented in MIBs by DOI TC IpsecDoiIpcompTransform). However, the SYNTAX of Spi is Unsigned32 (256..4294967295) which excludes all the special values. So, again, this TC is unaffected by the contents of IANA registries it seems to me that it would be more appropriate to use a TC that is local to the IPsec Flow Monitor MIB rather than putting it in the DOI TC MIB. In other words, I don't think that the DOI TC MIB should have to change to accomodate these two TCs because (unlike all the stuff currently in the DOI TC MIB) these things aren't linked 1-for-1 with something in one of the IPsec-related IANA registries. RKS, can you live with these two TCs being defined locally in the IPsec Flow Monitor MIB? >>>>> On Mon, 9 Jun 2003, C. M. Heard wrote (off-list): CMH> John -- [ ... ] CMH> If the decision is made to abandon the following three drafts: CMH> CMH> draft-ietf-ipsec-ike-monitor-mib-04.txt, CMH> draft-ietf-ipsec-isakmp-di-mon-mib-05.txt CMH> draft-ietf-ipsec-monitor-mib-06.txt CMH> CMH> then you should consider removing the TCs that are not used by CMH> either the IPSP MIB or the IPsec Flow MIB. Those would be: CMH> CMH> IpsecDoiSituation CMH> IpsecDoiTransformIdent CMH> IpsecDoiAhTransform CMH> IsakmpDOI CMH> IsakmpCertificateEncoding CMH> IsakmpExchangeType CMH> IsakmpNotifyMessageType CMH> IkeGroupType CMH> IkePrf CMH> IkeNotifyMessageType Because of some stuff I've found in the client MIBs I am going to back-pedal a little bit on this advice. Specifically, in the IPSP MIB I see: ipspAhTransformTable OBJECT-TYPE SYNTAX SEQUENCE OF IpspAhTransformEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table lists all the AH transforms which can be used to build IPsec proposals." [ ... ] ipspAhTranAlgorithm OBJECT-TYPE SYNTAX IpsecDoiAuthAlgorithm MAX-ACCESS read-create STATUS current DESCRIPTION "This object specifies the AH algorithm for this transform." Based on the followind DESCRIPTION clause, it seems to me that the SYNTAX value of ipspAhTranAlgorithm should probably be IpsecDoiAhTransform: IpsecDoiAhTransform ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The values of the IPsec DOI AH Transform Identifier which identify a particular algorithm to be used to provide integrity protection for AH. It is used in the Tranform-ID field of a ISAKMP Transform Payload for the IPsec DOI, when the Protocol-Id of the associated Proposal Payload is 2 (AH). (I also notices that the IPSP object ipspEspTranIntegrityAlgorithmId has a SYNTAX value of IpsecDoiAuthAlgorithm, but that seems to be correct.) So before anything actually gets removed, I would like to suggest that the authors of the IPSP MIB and IPsec flow monitoring MIB check their stuff very carefully for errors like this. Finally, I noticed something in the DOI TC MIB that appears to be erroneous, and which I did not flag in the previous MIB doctor review: IpsecDoiEspTransform ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The values of the IPsec DOI ESP Transform Identifier which identify a particular algorithm to be used to provide secrecy protection for ESP. It is used in the Tranform-ID field of a ISAKMP Transform Payload for the IPsec DOI, when the Protocol-Id of the associated Proposal Payload is 2 (AH), 3 (ESP), and 4 (IPCOMP). ^^^^^^ bug??? Since this and IpsecDoiAhTransform have different values, they can't both apply then the Protocol-Id of the associated Proposal Payload is 2 (AH). Thanks, Mike Heard From owner-ipsec@lists.tislabs.com Fri Jun 13 17:03:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5E03Jrb078221; Fri, 13 Jun 2003 17:03:19 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA22386 Fri, 13 Jun 2003 19:33:23 -0400 (EDT) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0564CD89@corpmx14.corp.emc.com> To: ipsec@lists.tislabs.com Subject: RE: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms Date: Fri, 13 Jun 2003 19:30:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Me too. With a statement that keys weaker than a certain > level (say, 128 bits although 96 is probably enough) SHOULD > NOT be used, I can live with DES being demoted to a SHOULD NOT. > > Still, I think that DES fits better with the definition of > MAY: "One vendor may choose to include the item because a > particular marketplace requires it or because the vendor > feels that it enhances the product while another vendor may > omit the same item." We need to write requirements that have a reasonable lifetime; keep in mind how long the MUST for DES survived. DES is already embarrassingly weak, and will only get weaker. In the algorithms draft, I'd like to see: - SHOULD NOT use DES - SHOULD NOT use keys shorter than 128 bits The latter is about key length, not effective strength of the cipher against best known attack. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ipsec@lists.tislabs.com Sat Jun 14 23:56:35 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5F6uYrb079735; Sat, 14 Jun 2003 23:56:35 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA27064 Sun, 15 Jun 2003 02:14:56 -0400 (EDT) From: "Yoav Nir" To: , Subject: RE: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms Date: Sun, 15 Jun 2003 09:19:19 +0200 Message-ID: <004701c3330e$70abc590$292e1dc2@YnirNew> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564CD89@corpmx14.corp.emc.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Why not make the requirement about effective strength? That way, if ever it turns out that AES_128 can be broken in 2**90 steps, it automatically becomes a SHOULD NOT. -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Black_David@emc.com Sent: Saturday, June 14, 2003 1:31 AM To: ipsec@lists.tislabs.com Subject: RE: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms > Me too. With a statement that keys weaker than a certain > level (say, 128 bits although 96 is probably enough) SHOULD > NOT be used, I can live with DES being demoted to a SHOULD NOT. > > Still, I think that DES fits better with the definition of > MAY: "One vendor may choose to include the item because a > particular marketplace requires it or because the vendor > feels that it enhances the product while another vendor may > omit the same item." We need to write requirements that have a reasonable lifetime; keep in mind how long the MUST for DES survived. DES is already embarrassingly weak, and will only get weaker. In the algorithms draft, I'd like to see: - SHOULD NOT use DES - SHOULD NOT use keys shorter than 128 bits The latter is about key length, not effective strength of the cipher against best known attack. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ipsec@lists.tislabs.com Sun Jun 15 01:46:42 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5F8kfrb098029; Sun, 15 Jun 2003 01:46:42 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id EAA27428 Sun, 15 Jun 2003 04:13:40 -0400 (EDT) Message-ID: <3EEC2C43.9060302@nomadiclab.com> Date: Sun, 15 Jun 2003 11:20:19 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Barbara Fraser Cc: ipsec@lists.tislabs.com, tytso@mit.edu, James Kempf , SEND WG Subject: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> In-Reply-To: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Based on our experiences in the SEND WG, I would like to offer the following comments to the IPSEC WG, regarding to the AHbis draft. > 1. Introduction > > .... > > host. ESP may be used to provide the same anti-replay and similar > integrity services, and it also provides a confidentiality > (encryption) service. The primary difference between the integrity > provided by ESP and AH is the extent of the coverage. Specifically, > ESP does not protect any IP header fields unless those fields are > encapsulated by ESP (e.g., via use of tunnel mode). ... Comments: - Even though the text above is true and correct, it may give a wrong impression. The most important difference is packet size. If ESP is used, it is necessary to copy all the important information from the fields that precede ESP into ESP (typically by employing tunneling), thereby making the packet larger. Additionally, if the protocols protected by ESP rely on any fields that precede ESP, ESP processing should check that the fields within the ESP header and the fields outside of it are equal. This is, by no means, trivial, since tunnel mode is not always a solution, depending on context. Hence, I would suggest adding the following piece of text: It should be noticed that some applications (such as IPv6 Neighbor Discovery or Mobile IPv6) rely on the integrity of some of the fields in the IP header. Furthermore, using tunnel mode may not be an option, since the very precense of a tunnel may open attacks. Finally, the incresed packet size caused by tunneling may be unacceptable to some applications. -------------- > 3.2 Integrity Algorithms > > The integrity algorithm employed for the ICV computation is specified > by the SA. For point-to-point communication, suitable integrity > algorithms include keyed Message Authentication Codes (MACs) based on > symmetric encryption algorithms (e.g., AES [AES] or on one-way hash > functions (e.g., MD5, SHA-1, SHA-256, etc.). For multicast > communication, a variety of cryptographic strategies for providing > integrity have been developed and research continues in this area. Comment: - In the current SEND working group proposal, a public key algorithm is proposed to be used even for point-to-point communication. However, this probably does not warrant changing the text above. -------------- > 3.4.2 Security Association Lookup > > .... > document.) The SAD entry for the SA also [...] > indicates the key required to validate the ICV. Comment - In the current SEND WG proposal, the SA does not indicate the key to be used. Instead, the AH header itself contains the public key. However, I don't know if the text above should be changed. --Pekka Nikander SEND WG co-chair From owner-ipsec@lists.tislabs.com Sun Jun 15 07:09:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5FE9Qrb018869; Sun, 15 Jun 2003 07:09:27 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA28367 Sun, 15 Jun 2003 09:34:18 -0400 (EDT) Date: Sun, 15 Jun 2003 12:27:51 +0200 From: Jean-Francois Dive To: "Brookes, Stuart P" Cc: "'ipsec@lists.tislabs.com'" Subject: Re: Implementing an IPsec MIB? Advice/Opinions sought? Message-ID: <20030615102751.GA1771@gardafou.assamite.eu.org> References: <59697CCC6CE3D411B4CD00805FBB776704148126@gbrwgcms03.wgc.gbr.xerox.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <59697CCC6CE3D411B4CD00805FBB776704148126@gbrwgcms03.wgc.gbr.xerox.com> User-Agent: Mutt/1.5.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Sometimes SNMP is not a that simple protocol... As of rules, you should not implement part of mibs, and should not add/change definitions of drafted/documented mibs. For your problem, i reckon the best approach (especically for a single object as you require) would be to add an object somewhere in your enterprise private OID tree. (If you already have for exemple a list of active/inactive services). There are no requirement of implementing any MIB object to be able to implement another . On Fri, Jun 13, 2003 at 10:02:55AM +0100, Brookes, Stuart P wrote: > Hi, > > I am fairly new to SNMP & MIBs. I need to add a new read-only MIB object > that will inform whether IPsec is enabled or disabled... > I think the IPsec Monitoring MIB is too low-level for what I require. So I > have looked at the IPsec Flow Monitoring MIB draft document. > > Because I am new to this, I'm not sure exactly what I have to implement. I > have been asked if it possible to just implement some sort of single MIB > object that will display whether IPsec is enabled or disabled? Is this > possible? Do I have to implement various other MIBs in order to do this? > > As a result, in terms of documentation, where are these MIB objects stored? > I was presuming they are placed under the IP Group of MIB objects, am I > wrong? If so, where should they be located? > > I hope this is not to basic and I am not asking stupid questions. As I say, > I am pretty much learning as I go along... > > Regards > Stuart -- -> Jean-Francois Dive --> jef@linuxbe.org There is no such thing as randomness. Only order of infinite complexity. - Marquis de LaPlace - deterministic Principles - From owner-ipsec@lists.tislabs.com Sun Jun 15 17:29:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5G0TVrb040252; Sun, 15 Jun 2003 17:29:36 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA29935 Sun, 15 Jun 2003 19:53:58 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16109.2150.162000.496740@gargle.gargle.HOWL> Date: Sun, 15 Jun 2003 19:59:34 -0400 From: Paul Koning To: ynir@CheckPoint.com Cc: Black_David@emc.com, ipsec@lists.tislabs.com Subject: RE: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms References: <277DD60FB639D511AC0400B0D068B71E0564CD89@corpmx14.corp.emc.com> <004701c3330e$70abc590$292e1dc2@YnirNew> X-Mailer: VM 7.07 under 21.4 (patch 10) "Military Intelligence (Windows)" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Yoav" == Yoav Nir writes: Yoav> Why not make the requirement about effective strength? That Yoav> way, if ever it turns out that AES_128 can be broken in 2**90 Yoav> steps, it automatically becomes a SHOULD NOT. That idea is somewhat appealing, but how would you define effective strength? There's memory, there's precomputation, and there's the subsequent computation for the attack. All three parts matter. (If you omit precomputation and memory, then all block ciphers have strength 1...) paul From owner-ipsec@lists.tislabs.com Sun Jun 15 22:33:25 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5G5XOrb049126; Sun, 15 Jun 2003 22:33:24 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA00904 Mon, 16 Jun 2003 00:59:59 -0400 (EDT) X-Envelope-To: ipsec@lists.tislabs.com To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms Date: 16 Jun 2003 04:39:26 GMT Organization: University of California, Berkeley Lines: 15 Distribution: isaac Message-ID: References: <277DD60FB639D511AC0400B0D068B71E0564CD89@corpmx14.corp.emc.com> <004701c3330e$70abc590$292e1dc2@YnirNew> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1055738366 17729 128.32.153.211 (16 Jun 2003 04:39:26 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 16 Jun 2003 04:39:26 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yoav Nir wrote: >Why not make the requirement about effective strength? That way, if ever it >turns out that AES_128 can be broken in 2**90 steps, it automatically >becomes a SHOULD NOT. I don't recommend this. I can just see the debates this might spawn. Cryptographers already can't agree whether the Courtois-Pieprzyk attack works or not, and that might be a 2^80 attack on AES -- if it works (which nobody knows). I'd recommend to keep it simple. KISS. Isn't it easier to simply write that implementors SHOULD NOT use key sizes shorter than the default key size? From owner-ipsec@lists.tislabs.com Sun Jun 15 22:57:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5G5vhrb049471; Sun, 15 Jun 2003 22:57:43 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA00995 Mon, 16 Jun 2003 01:28:46 -0400 (EDT) From: "Yoav Nir" To: "'David Wagner'" , Subject: RE: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms Date: Mon, 16 Jun 2003 08:33:00 +0200 Message-ID: <001601c333d1$2285a070$292e1dc2@YnirNew> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It MAY be simple, but it is wrong, so it SHOULD NOT be used. WEP offers 128-bit keys, but only 24-bit security (or 12, depending on your definition) -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of David Wagner Sent: Monday, June 16, 2003 6:39 AM To: ipsec@lists.tislabs.com Subject: Re: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms Yoav Nir wrote: >Why not make the requirement about effective strength? That way, if ever it >turns out that AES_128 can be broken in 2**90 steps, it automatically >becomes a SHOULD NOT. I don't recommend this. I can just see the debates this might spawn. Cryptographers already can't agree whether the Courtois-Pieprzyk attack works or not, and that might be a 2^80 attack on AES -- if it works (which nobody knows). I'd recommend to keep it simple. KISS. Isn't it easier to simply write that implementors SHOULD NOT use key sizes shorter than the default key size? From owner-ipsec@lists.tislabs.com Sun Jun 15 23:34:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5G6Y1rb057977; Sun, 15 Jun 2003 23:34:02 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA01130 Mon, 16 Jun 2003 02:05:06 -0400 (EDT) X-Envelope-To: ipsec@lists.tislabs.com To: ipsec@lists.tislabs.com Path: not-for-mail From: daw@mozart.cs.berkeley.edu (David Wagner) Newsgroups: isaac.lists.ipsec Subject: Re: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms Date: 16 Jun 2003 05:44:32 GMT Organization: University of California, Berkeley Lines: 18 Distribution: isaac Message-ID: References: <001601c333d1$2285a070$292e1dc2@YnirNew> NNTP-Posting-Host: mozart.cs.berkeley.edu X-Trace: abraham.cs.berkeley.edu 1055742272 18210 128.32.153.211 (16 Jun 2003 05:44:32 GMT) X-Complaints-To: news@abraham.cs.berkeley.edu NNTP-Posting-Date: 16 Jun 2003 05:44:32 GMT X-Newsreader: trn 4.0-test74 (May 26, 2000) Originator: daw@mozart.cs.berkeley.edu (David Wagner) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yoav Nir wrote: >It MAY be simple, but it is wrong, so it SHOULD NOT be used. WEP offers >128-bit keys, but only 24-bit security (or 12, depending on your definition) That's irrelevant: WEP isn't on the list of recommended algorithms. If our recommended key sizes were inadequate, then complain about that. But I think that you'll find that the default key sizes in draft-...-ikev2-algorithms are eminently reasonable. I think you're making this more complicated than it should be. Let me take this to absurd extremes: Imagine adding a sentence to the standard saying "All IPSec implementations MUST be secure. Insecure implementations are non-complying." Such a sentence would add little value, because it doesn't tell the implementor *how* to achieve compliance. The purpose of the standard is not to list a set of requirements or desirable features; the purpose of the standard is to promote interoperability and to specify a protocol that (we believe) meets those requirements. From owner-ipsec@lists.tislabs.com Mon Jun 16 01:01:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5G81lrb074653; Mon, 16 Jun 2003 01:01:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA01507 Mon, 16 Jun 2003 03:25:14 -0400 (EDT) Message-ID: <3EED726A.7060502@nomadiclab.com> Date: Mon, 16 Jun 2003 10:31:54 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> In-Reply-To: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk [Resending to the ipsec list, the original did not get through.] Based on our experiences in the SEND WG, I would like to offer the following comments to the IPSEC WG, regarding to the AHbis draft. > 1. Introduction > > .... > > host. ESP may be used to provide the same anti-replay and similar > integrity services, and it also provides a confidentiality > (encryption) service. The primary difference between the integrity > provided by ESP and AH is the extent of the coverage. Specifically, > ESP does not protect any IP header fields unless those fields are > encapsulated by ESP (e.g., via use of tunnel mode). ... Comments: - Even though the text above is true and correct, it may give a wrong impression. The most important difference is packet size. If ESP is used, it is necessary to copy all the important information from the fields that precede ESP into ESP (typically by employing tunneling), thereby making the packet larger. Additionally, if the protocols protected by ESP rely on any fields that precede ESP, ESP processing should check that the fields within the ESP header and the fields outside of it are equal. This is, by no means, trivial, since tunnel mode is not always a solution, depending on context. Hence, I would suggest adding the following piece of text: It should be noticed that some applications (such as IPv6 Neighbor Discovery or Mobile IPv6) rely on the integrity of some of the fields in the IP header. Furthermore, using tunnel mode may not be an option, since the very precense of a tunnel may open attacks. Finally, the incresed packet size caused by tunneling may be unacceptable to some applications. -------------- > 3.2 Integrity Algorithms > > The integrity algorithm employed for the ICV computation is specified > by the SA. For point-to-point communication, suitable integrity > algorithms include keyed Message Authentication Codes (MACs) based on > symmetric encryption algorithms (e.g., AES [AES] or on one-way hash > functions (e.g., MD5, SHA-1, SHA-256, etc.). For multicast > communication, a variety of cryptographic strategies for providing > integrity have been developed and research continues in this area. Comment: - In the current SEND working group proposal, a public key algorithm is proposed to be used even for point-to-point communication. However, this probably does not warrant changing the text above. -------------- > 3.4.2 Security Association Lookup > > .... > document.) The SAD entry for the SA also [...] > indicates the key required to validate the ICV. Comment - In the current SEND WG proposal, the SA does not indicate the key to be used. Instead, the AH header itself contains the public key. However, I don't know if the text above should be changed. --Pekka Nikander SEND WG co-chair From owner-ipsec@lists.tislabs.com Mon Jun 16 01:13:11 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5G8DBrb076289; Mon, 16 Jun 2003 01:13:11 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA01598 Mon, 16 Jun 2003 03:41:16 -0400 (EDT) Message-ID: <3EED762C.5060306@nomadiclab.com> Date: Mon, 16 Jun 2003 10:47:56 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Cc: Barbara Fraser , tytso@mit.edu, Stephen Kent , SEND WG Subject: AHbis WG LC: need for source address based selectors References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> In-Reply-To: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk One more comment to the AHbis WG LC: AHbis currently states the following: > 2.4 Security Parameters Index (SPI) > > The SPI is an arbitrary 32-bit value that is used by a receiver to > identify the SA to which an incoming packet is bound. For a unicast > SA, the SPI can be used by itself to specify an SA, or it may be used > in conjunction with the IPsec protocol type (in this case AH). > Since, for unicast SAs, the SPI value is generated by the receiver, > whether the value is sufficient to identify an SA by itself, or > whether it must be used in conjunction with the IPsec protocol value > is a local matter. The SPI field is mandatory and this mechanism for > mapping inbound traffic to unicast SAs described above MUST be > supported by all AH implementations. However, in the SEND WG we are using AH with public key crypto, with a fixed SPI. There the key used depends on the sender of the message, not the receiver. Hence, for our purposes neither the SPI alone nor SPI + protocol are enough. We need also the ability to select the SA based on SPI + source address, even for unicast. > If an IPsec implementation supports multicast, then it MUST support > multicast SAs using the following algorithm for mapping inbound IPsec > datagrams to SAs. ... Each entry in the Security Association > Database (SAD) [KA98a] must indicate whether the SA lookup makes use > of the source and destination IP addresses, in addition to the SPI. > ... (There is no current requirement to support SA mapping based on > the source address but not the destination address, thus one of the > possible four values is not meaningful.) .... Since we are using PK crypto, we also need the possibility for selecting the SA based solely on the source address. In fact, for our fixed SPI, the destination address does not have any role, not even whether the destination address is unicast or multicast. I don't know how to handle this so late in the process. I would like to see the text to be sufficiently revised to allow source address based SA selection, so that we could use it directly in SEND. However, I have no idea how the IPSEC WG would feel about that. --Pekka Nikander SEND WG co-chair From owner-ipsec@lists.tislabs.com Mon Jun 16 06:31:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5GDV1rb099647; Mon, 16 Jun 2003 06:31:01 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA02586 Mon, 16 Jun 2003 08:56:56 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16109.49130.228945.48614@pkoning.dev.equallogic.com> Date: Mon, 16 Jun 2003 09:02:34 -0400 From: Paul Koning To: ynir@CheckPoint.com Cc: daw@mozart.cs.berkeley.edu, ipsec@lists.tislabs.com Subject: RE: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms References: <001601c333d1$2285a070$292e1dc2@YnirNew> X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Yoav" == Yoav Nir writes: Yoav> It MAY be simple, but it is wrong, so it SHOULD NOT be used. Yoav> WEP offers 128-bit keys, but only 24-bit security (or 12, Yoav> depending on your definition) Yes, but the troubles with WEP, as I recall, don't come from its cipher, but rather from the stuff that was wrapped around it without any regard to proper cryptographic design. So are you proposing that the rule should be on the effective strength of the whole system? Yes, that's theoretically what you'd want, but no, I don't see how that's feasible. paul From owner-ipsec@lists.tislabs.com Mon Jun 16 06:50:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5GDoSrb000329; Mon, 16 Jun 2003 06:50:28 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02704 Mon, 16 Jun 2003 09:23:02 -0400 (EDT) Message-ID: <3EEC1EC9.1040506@nomadiclab.com> Date: Sun, 15 Jun 2003 10:22:49 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Cc: Barbara Fraser , tytso@mit.edu, Stephen Kent Subject: Minor comments to draft-ietf-ipsec-esp-v3-05.txt References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> In-Reply-To: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> Content-Type: multipart/mixed; boundary="------------030403000302070405080308" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------030403000302070405080308 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Barbara Fraser wrote: > This is a working group last call for comments on the following drafts, > for progression to Proposed Standard: > > ... > draft-ietf-ipsec-rfc2402bis-03.txt Enclosed a set of minor comments to the rfc2402bis draft. I am reviewing the draft from the SEND WG point of view, and these comments are ones that do involve any SEND specific issues. However, even though these are really minor, they are not purely editorial, and may have some WG interest. I will shortly send another set of comments, more from the SEND WG point of view. --Pekka Nikander SEND WG co-chair --------------030403000302070405080308 Content-Type: text/plain; name="draft-ietf-ipsec-rfc2402bis-03-small.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-ipsec-rfc2402bis-03-small.txt" > 2.2 Payload Length > > This 8-bit field specifies the length of AH in 32-bit words (4-byte > units), minus "2". (This means of expressing the length of AH was > selected to allow its use as an IPv6 extension header. Thus the > length computation is consistent with the algorithm described in RFC > 1883.) In the case of an integrity algorithm that yields a 96-bit > authentication value, plus the 3 32-bit word fixed portion, this > length field will be "4". See Section 2.6, "Integrity Check Value > (ICV)", for comments on padding of this field, and Section 3.3.3.2.1 > "ICV Padding". Comments: - Shouldn't the reference to RFC1883 be replaced with a reference to RFC2460, or better, to [DH95]? - It is probably far too late to change this, but all the other IPv6 extension headers define the length in 8-octet units, not 4-byte units. If possible, it *would* be desirable to update this for IPv6. However, I fully understand that such a change may not be possible at this late in standardization. (This comment may be ignored, as it most probably has been extensively discussed in the past by the WG.) - For IPv6, there should be a requirement that the length MUST be integral in 8-octet units, i.e., that the length must be evenly divisible by two. The requirement for that does exist in 3.3.3.2.1, but it would be good to briefly repeat it here. Suggestion: Insert the following text before "See Section 2.6" For IPv6, the total length of the header must be a multiple of 8-octet units. -------------- > 2.3 Reserved > > This 16-bit field is reserved for future use. It MUST be set to > "zero." (Note that the value is included in the ICV calculation, but > is otherwise ignored by the recipient.) Comments: - Why is the value of the field defined as it is? The more usual wording seems to be 'MUST be set to "zero" by the sender, and SHOULD be ignored by the recipient'. The effect of the text above is the same, but someone may try to read it is the value must always be zero, and e.g. implement a firewall that drops packets where it is non-zero. Suggestion: Replace with the following text. This 16-bit field is reserved for future use. It MUST be set to "zero" by the sender, and it SHOULD be ignored by the recipient. (Note that the value is included in the ICV calculation, but is currently otherwise ignored by the recipient.) -------------- > 3.3.3.1.2.1 Base Header Fields > > The IPv6 base header fields are classified as follows: > > Immutable > Version > Payload Length > Next Header (This should be the value for AH.) Comments: - The note in the paranthesis is both unnecessary and misleading, as there may well be intevening extension headers. Suggestion: Remove the text in paranthesis. -------------- > [DH95] Deering, S., and B. Hinden, "Internet Protocol version 6 > (IPv6) Specification", RFC 1883, December 1995. Comments: - Should this be replaced with a reference to RFC 2460? Suggestion: Replace with a reference to RFC2460. --------------030403000302070405080308-- From owner-ipsec@lists.tislabs.com Mon Jun 16 06:51:17 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5GDpGrb000357; Mon, 16 Jun 2003 06:51:17 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02782 Mon, 16 Jun 2003 09:27:03 -0400 (EDT) Message-Id: <200306161155.HAA09086@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: ipsec@lists.tislabs.com From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Subject: I-D ACTION:draft-ietf-ipsec-ui-suites-01.txt Date: Mon, 16 Jun 2003 07:55:54 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the IP Security Protocol Working Group of the IETF. Title : Cryptographic Suites for IPsec Author(s) : P. Hoffman Filename : draft-ietf-ipsec-ui-suites-01.txt Pages : 5 Date : 2003-6-13 The IPsec, IKE, and IKEv2 protocols rely on security algorithms to provide privacy and authentication between the initiator and responder. There are many such algorithms available, and two IPsec systems cannot interoperate unless they are using the same algorithms. This document specifies optional suites of algorithms and attributes that can be used to simplify the administration of IPsec when used in manual keying mode, with IKE version 1, or with IKEv2. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipsec-ui-suites-01.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-ipsec-ui-suites-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-ipsec-ui-suites-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2003-6-16080831.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-ipsec-ui-suites-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-ipsec-ui-suites-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2003-6-16080831.I-D@ietf.org> --OtherAccess-- --NextPart-- From owner-ipsec@lists.tislabs.com Mon Jun 16 06:53:49 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5GDrirb000561; Mon, 16 Jun 2003 06:53:48 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA02757 Mon, 16 Jun 2003 09:26:01 -0400 (EDT) Message-ID: <3EED7241.1080904@nomadiclab.com> Date: Mon, 16 Jun 2003 10:31:13 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ipsec@lists.tislabs.com Subject: Minor comments to draft-ietf-ipsec-esp-v3-05.txt References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> In-Reply-To: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> Content-Type: multipart/mixed; boundary="------------010605000102030009060102" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. --------------010605000102030009060102 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit [Resending to the list, the original did not get through.] Barbara Fraser wrote: > This is a working group last call for comments on the following drafts, > for progression to Proposed Standard: > > ... > draft-ietf-ipsec-rfc2402bis-03.txt Enclosed a set of minor comments to the rfc2402bis draft. I am reviewing the draft from the SEND WG point of view, and these comments are ones that do involve any SEND specific issues. However, even though these are really minor, they are not purely editorial, and may have some WG interest. I will shortly send another set of comments, more from the SEND WG point of view. --Pekka Nikander SEND WG co-chair --------------010605000102030009060102 Content-Type: text/plain; name="draft-ietf-ipsec-rfc2402bis-03-small.txt" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="draft-ietf-ipsec-rfc2402bis-03-small.txt" > 2.2 Payload Length > > This 8-bit field specifies the length of AH in 32-bit words (4-byte > units), minus "2". (This means of expressing the length of AH was > selected to allow its use as an IPv6 extension header. Thus the > length computation is consistent with the algorithm described in RFC > 1883.) In the case of an integrity algorithm that yields a 96-bit > authentication value, plus the 3 32-bit word fixed portion, this > length field will be "4". See Section 2.6, "Integrity Check Value > (ICV)", for comments on padding of this field, and Section 3.3.3.2.1 > "ICV Padding". Comments: - Shouldn't the reference to RFC1883 be replaced with a reference to RFC2460, or better, to [DH95]? - It is probably far too late to change this, but all the other IPv6 extension headers define the length in 8-octet units, not 4-byte units. If possible, it *would* be desirable to update this for IPv6. However, I fully understand that such a change may not be possible at this late in standardization. (This comment may be ignored, as it most probably has been extensively discussed in the past by the WG.) - For IPv6, there should be a requirement that the length MUST be integral in 8-octet units, i.e., that the length must be evenly divisible by two. The requirement for that does exist in 3.3.3.2.1, but it would be good to briefly repeat it here. Suggestion: Insert the following text before "See Section 2.6" For IPv6, the total length of the header must be a multiple of 8-octet units. -------------- > 2.3 Reserved > > This 16-bit field is reserved for future use. It MUST be set to > "zero." (Note that the value is included in the ICV calculation, but > is otherwise ignored by the recipient.) Comments: - Why is the value of the field defined as it is? The more usual wording seems to be 'MUST be set to "zero" by the sender, and SHOULD be ignored by the recipient'. The effect of the text above is the same, but someone may try to read it is the value must always be zero, and e.g. implement a firewall that drops packets where it is non-zero. Suggestion: Replace with the following text. This 16-bit field is reserved for future use. It MUST be set to "zero" by the sender, and it SHOULD be ignored by the recipient. (Note that the value is included in the ICV calculation, but is currently otherwise ignored by the recipient.) -------------- > 3.3.3.1.2.1 Base Header Fields > > The IPv6 base header fields are classified as follows: > > Immutable > Version > Payload Length > Next Header (This should be the value for AH.) Comments: - The note in the paranthesis is both unnecessary and misleading, as there may well be intevening extension headers. Suggestion: Remove the text in paranthesis. -------------- > [DH95] Deering, S., and B. Hinden, "Internet Protocol version 6 > (IPv6) Specification", RFC 1883, December 1995. Comments: - Should this be replaced with a reference to RFC 2460? Suggestion: Replace with a reference to RFC2460. --------------010605000102030009060102-- From owner-ipsec@lists.tislabs.com Mon Jun 16 07:50:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5GEoNrb006350; Mon, 16 Jun 2003 07:50:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA03069 Mon, 16 Jun 2003 10:13:00 -0400 (EDT) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0564CD8B@corpmx14.corp.emc.com> To: ynir@CheckPoint.com, ipsec@lists.tislabs.com Subject: RE: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms Date: Mon, 16 Jun 2003 10:09:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yoav, > >Why not make the requirement about effective strength? That way, if > >ever it turns out that AES_128 can be broken in 2**90 steps, it > >automatically becomes a SHOULD NOT. That's fine for a working guideline within the WG, but we need to produce protocol specifications that don't require implementers to do a serious analysis of the latest cryptographic literature to determine whether 128-bit AES still has an effective strength of at least 100 bits. IMHO, that's this WG's responsibility, and the new document structure should make it easier to update cipher recommendations/requirements as things change. > It MAY be simple, but it is wrong, so it SHOULD NOT be used. > WEP offers 128-bit keys, but only 24-bit security (or 12, > depending on your definition) Again, it's the WG's responsibility in keep junk like that (including horribly weak ciphers) out of the protocol specs; I can't believe any of the cryptographers in this WG would allow something as weak/broken as WEP to survive WG Last Call. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ipsec@lists.tislabs.com Mon Jun 16 08:23:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5GFN2rb007566; Mon, 16 Jun 2003 08:23:02 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA03255 Mon, 16 Jun 2003 10:50:31 -0400 (EDT) Date: Mon, 16 Jun 2003 10:56:38 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: RE: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms In-Reply-To: <16109.49130.228945.48614@pkoning.dev.equallogic.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 16 Jun 2003, Paul Koning wrote: > Yes, but the troubles with WEP, as I recall, don't come from its > cipher, but rather from the stuff that was wrapped around it without > any regard to proper cryptographic design. Correct. The cipher is RC4, which is (last I heard) still thought to be okay. The problem is that WEP generates keys by a distinctly non-random process which produces many closely-related keys, and nobody thought to ask whether this was a weakness. It is. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Jun 16 09:23:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5GGNgrb010803; Mon, 16 Jun 2003 09:23:43 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA03672 Mon, 16 Jun 2003 11:50:26 -0400 (EDT) Message-Id: <200306161556.h5GFuYq3005910@thunk.east.sun.com> From: Bill Sommerfeld To: Henry Spencer cc: IP Security List Subject: Re: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms In-Reply-To: Your message of "Mon, 16 Jun 2003 10:56:38 EDT." Reply-to: sommerfeld@east.sun.com Date: Mon, 16 Jun 2003 11:56:34 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Correct. The cipher is RC4, which is (last I heard) still thought to be > okay. Okay, but not great. RC4 is a stream cipher which comes with additional special handling recommendations ("For best results, discard first N bytes of output after keying"). > The problem is that WEP generates keys by a distinctly non-random > process which produces many closely-related keys, and nobody thought to > ask whether this was a weakness. It is. The WEP related-key attacks exploit the first-byte weaknesses of RC4. - Bill From owner-ipsec@lists.tislabs.com Mon Jun 16 09:37:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5GGbJrb012777; Mon, 16 Jun 2003 09:37:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03756 Mon, 16 Jun 2003 12:07:36 -0400 (EDT) Date: Mon, 16 Jun 2003 12:13:43 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms In-Reply-To: <200306161556.h5GFuYq3005910@thunk.east.sun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Mon, 16 Jun 2003, Bill Sommerfeld wrote: > > Correct. The cipher is RC4, which is (last I heard) still thought to be > > okay. > > Okay, but not great. > RC4 is a stream cipher which comes with additional special handling > recommendations ("For best results, discard first N bytes of output > after keying"). My impression is that said recommendation applies only with non-random keys. When I dug into this (albeit briefly) a while back, I was unable to find any source for that recommendation which didn't trace back to WEP's disastrously non-random key-generation procedure. I would be curious to know whether this is still an issue *with* good random-bits keys. (With a reference, not just folklore; my suspicion is that the WEP problem is being over-generalized in the folklore.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Mon Jun 16 11:11:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5GIBorb016560; Mon, 16 Jun 2003 11:11:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04134 Mon, 16 Jun 2003 13:39:33 -0400 (EDT) From: "Russ Housley" To: , "'Henry Spencer'" Cc: "'IP Security List'" Subject: RE: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms Date: Mon, 16 Jun 2003 13:45:42 -0400 Message-ID: <000301c3342f$1b6e3320$6401a8c0@RussLaptop> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.4024 In-Reply-To: <200306161556.h5GFuYq3005910@thunk.east.sun.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk WEP causes a problem from RC4 because it "publishes" the first 24 bits of the key. The RC4 key schedule is not robust enough to deal with part of its input being disclosed. If RC4 is used in a system where none of the keying material is disclosed, as is the case with TLS, then it holds up just fine. In ESP, the use of RC4 would require special handling to avoid WEP-like issues. I do not believe that anyone has written a specification for RC4 and ESP. Russ > -----Original Message----- > From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com] > On Behalf Of Bill Sommerfeld > Sent: Monday, June 16, 2003 11:57 AM > To: Henry Spencer > Cc: IP Security List > Subject: Re: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms > > > Correct. The cipher is RC4, which is (last I heard) still thought to be > > okay. > > Okay, but not great. > > RC4 is a stream cipher which comes with additional special handling > recommendations ("For best results, discard first N bytes of output > after keying"). > > > The problem is that WEP generates keys by a distinctly non-random > > process which produces many closely-related keys, and nobody thought to > > ask whether this was a weakness. It is. > > The WEP related-key attacks exploit the first-byte weaknesses of RC4. > > - Bill From owner-ipsec@lists.tislabs.com Mon Jun 16 12:03:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5GJ3Wrb018385; Mon, 16 Jun 2003 12:03:33 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04424 Mon, 16 Jun 2003 14:34:03 -0400 (EDT) From: "Lee Dilkie" To: "'Russ Housley'" , , "'Henry Spencer'" Cc: "'IP Security List'" Subject: RE: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms Date: Mon, 16 Jun 2003 14:36:03 -0400 Message-ID: <005301c33436$247a0280$8a3bc786@software.mitel.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <000301c3342f$1b6e3320$6401a8c0@RussLaptop> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4925.2800 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I thought also that RC4 was not a restartable(seekable?) stream cipher and thus cannot tolerate lost or out of order packets unless special steps were taken (re-gen the key schedule for each packet?). > -----Original Message----- > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Russ Housley > Sent: Monday, June 16, 2003 1:46 PM > To: sommerfeld@east.sun.com; 'Henry Spencer' > Cc: 'IP Security List' > Subject: RE: Editorial: Use of MAY in > draft-ietf-ipsec-ikev2-algorithms > > > WEP causes a problem from RC4 because it "publishes" the first 24 bits > of the key. The RC4 key schedule is not robust enough to > deal with part > of its input being disclosed. If RC4 is used in a system > where none of > the keying material is disclosed, as is the case with TLS, > then it holds > up just fine. > > In ESP, the use of RC4 would require special handling to > avoid WEP-like > issues. I do not believe that anyone has written a specification for > RC4 and ESP. > > Russ > > > > -----Original Message----- > > From: owner-ipsec@lists.tislabs.com > [mailto:owner-ipsec@lists.tislabs.com] > > On Behalf Of Bill Sommerfeld > > Sent: Monday, June 16, 2003 11:57 AM > > To: Henry Spencer > > Cc: IP Security List > > Subject: Re: Editorial: Use of MAY in > draft-ietf-ipsec-ikev2-algorithms > > > > > Correct. The cipher is RC4, which is (last I heard) still thought > to be > > > okay. > > > > Okay, but not great. > > > > RC4 is a stream cipher which comes with additional special handling > > recommendations ("For best results, discard first N bytes of output > > after keying"). > > > > > The problem is that WEP generates keys by a distinctly non-random > > > process which produces many closely-related keys, and > nobody thought > to > > > ask whether this was a weakness. It is. > > > > The WEP related-key attacks exploit the first-byte > weaknesses of RC4. > > > > - Bill > > From owner-ipsec@lists.tislabs.com Mon Jun 16 13:36:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5GKaKrb022971; Mon, 16 Jun 2003 13:36:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04809 Mon, 16 Jun 2003 16:07:33 -0400 (EDT) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0564CD9A@corpmx14.us.dg.com> To: ipsec@lists.tislabs.com Subject: AHbis comments Date: Mon, 16 Jun 2003 16:04:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Here are a couple of transport related comments on draft-ietf-ipsec-rfc2402bis-03.txt . These have no effect on the specified processing - they're mostly about updating the explanation and references. Section 3.3.3.1.1.1 describes the TOS field in the IP Header as mutable (that's correct) and says: TOS -- This field is excluded because some routers are known to change the value of this field, even though the IP specification does not consider TOS to be a mutable header field. That's no longer correct. The TOS field has now been replaced by a 6 bit DS field (contains a Diffserv codepoint) plus a 2 bit ECN field, and both are defined to be mutable. RFC 2780 and RFC 3168 should be cited as the basis for this, and possibly also RFC 2474. The same 6 bit DS + 2 bit ECN structure applies to the IPv6 (Traffic) Class field (section 3.3.3.1.2.1), which has always been mutable, as the same RFCs specify it. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ipsec@lists.tislabs.com Mon Jun 16 13:41:28 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5GKfSrb023085; Mon, 16 Jun 2003 13:41:28 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA04899 Mon, 16 Jun 2003 16:16:08 -0400 (EDT) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0564CD9B@corpmx14.us.dg.com> To: ipsec@lists.tislabs.com Subject: ESN Addendum comment Date: Mon, 16 Jun 2003 16:13:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This one's entirely procedural: In draft-ietf-ipsec-esn-addendum-01.txt, the IANA Considerations section needs to be replaced by text asking IANA to allocate an "IPSEC Security Association Attributes" value and using that number to replace the TBD under the "value" heading in Section 2. It may be necessary to include text in the IANA Considerations section saying that this value "is assigned by the standards action of this RFC" or something like that. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ipsec@lists.tislabs.com Mon Jun 16 14:23:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5GLNDrb024081; Mon, 16 Jun 2003 14:23:16 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05077 Mon, 16 Jun 2003 16:57:16 -0400 (EDT) Message-Id: <5.2.0.9.2.20030616162449.03dc0280@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 16 Jun 2003 16:28:28 -0400 To: "Lee Dilkie" From: Russ Housley Subject: RE: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms Cc: "'IP Security List'" In-Reply-To: <005301c33436$247a0280$8a3bc786@software.mitel.com> References: <000301c3342f$1b6e3320$6401a8c0@RussLaptop> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Lee: >I thought also that RC4 was not a restartable(seekable?) stream cipher and >thus cannot tolerate lost or out of order packets unless special steps were >taken (re-gen the key schedule for each packet?). All stream ciphers use a key to produce a key stream. WEP needs a different key stream for each packet, as would IPsec ESP if one tried to use RC4 in this context. WEP achieved this by constructing a per-packet key. An IV was simply concatenated with the rest of the key. This is how the first three bytes of the packet key are "published." Russ From owner-ipsec@lists.tislabs.com Mon Jun 16 15:01:17 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5GM1Crb024909; Mon, 16 Jun 2003 15:01:16 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA05311 Mon, 16 Jun 2003 17:33:34 -0400 (EDT) Message-Id: <5.2.0.9.2.20030616152833.03e76520@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Mon, 16 Jun 2003 17:39:27 -0400 To: ipsec@lists.tislabs.com From: Russ Housley Subject: WG Last Call: draft-ietf-ipsec-esp-v3-05 Cc: kent@bbn.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have a few comments on the updated ESP specification. 1. Please delete the last line of the Abstract. In my opinion, pointers to subsequent sections belong in the Introduction, not the Abstract. 2. Please move the last two paragraphs of the Introduction to the beginning. This will tell the reader the material that the expected to be understood before they get too deep, and it will define MAY. SHOULD, MUST, and so on before they are used. 3. The last paragraph on page 4 includes: Typically this binding is effected through the use of a shared, symmetric key, but an asymmetric cryptographic algorithm also may be employed, e.g., to sign a hash.) Digitally signing individual packets should not be encouraged. The performance ramifications, both computational and packet bloat, are extreme. I suggest dropping the second half of the sentence. Just do not bring it up. 4. The first full paragraph at the top of page 5 includes: Although confidentiality and integrity can be offered independently, most ESP use typically will employ both services, i.e., packets will be protected with regard to confidentiality and integrity. s/use/uses/ 5. The following paragraph appears on the second half of page 7: When any combined mode algorithm is employed, the algorithm itself is expected to return both decrypted plaintext and a pass/fail indication for the integrity check. For combined mode algorithms, the ICV that would normally appear at the end of the ESP packet (when integrity is selected) is omitted. It is the responsibility of the combined mode algorithm to encode within the payload data an ICV- equivalent means of verifying the integrity of the packet. I consider CCM (see draft-ietf-ipsec-ciph-aes-ccm-03) to be a combined mode. The referenced specification makes use of the ICV field. Therefore, I propose two changes: - Please replace "is omitted" to "may be omitted" - Please change "It is the responsibility of the combined mode algorithm ..." to "When the ICV is omitted and integrity is selected, it is the responsibility of the combined mode algorithm ..." 6. Figure 2 include "IV (optional]. " s/]/)/ 7. Below Figure 2, the following paragraph appears: If a combined algorithm mode is employed, the explicit ICV shown in Figures 1 and 2 is omitted (see Section 3.3.2.2 below). Since algorithms and modes are fixed when an SA is established, the detailed format of ESP packets for a given SA (including the Payload Data substructure) is fixed, for all traffic on the SA. s/is omitted/may be omitted/ 8. In Table 2, the ICV row should be "O" in the "Requ'd" column. 9. The first sentence in section 2.2.1, has the flavor of a new option that is under development, rather than one that is ready to be finalized. I propose an alternative: To support high-speed IPsec implementations, extended sequence numbers SHOULD be implemented. 10. At the beginning of section 2.4, the following sentence is followed by two bullets. Something is not quite right. Three factors require or motivate use of the Padding field. 11. Please reword the paragraph in section 2.8 to permit the ICV field to be present when a combined mode is employed, which is consistent with the wording used in section 3.2.3. 12. Please reword the 4th bullet following the paragraph numbered 3 in section 3.3.2.2 to permit the ICV field to be present when a combined mode is employed. 13. I am confused by "DISCUSSION" in section 3.4.4.1. Russ From owner-ipsec@lists.tislabs.com Mon Jun 16 23:46:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5H6kNrb046565; Mon, 16 Jun 2003 23:46:23 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA06819 Tue, 17 Jun 2003 02:15:53 -0400 (EDT) From: "Yoav Nir" To: "'Henry Spencer'" , "'IP Security List'" Subject: RE: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms Date: Tue, 17 Jun 2003 09:20:16 +0200 Message-ID: <004601c334a0$e76a7030$292e1dc2@YnirNew> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The problem with WEP is that although there's a secret part to the key (40 or 104 bits), that part never changes. The IV is 24 bits which means that there are only 2^24 possible streams. Even assuming that the IVs are uniformly random, you can expect collisions after a few thousand packets. But we're not here to discuss WEP. I only brought it up as an example of how key-length does not equal security. -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Henry Spencer Sent: Monday, June 16, 2003 6:14 PM To: IP Security List Subject: Re: Editorial: Use of MAY in draft-ietf-ipsec-ikev2-algorithms On Mon, 16 Jun 2003, Bill Sommerfeld wrote: > > Correct. The cipher is RC4, which is (last I heard) still thought to be > > okay. > > Okay, but not great. > RC4 is a stream cipher which comes with additional special handling > recommendations ("For best results, discard first N bytes of output > after keying"). My impression is that said recommendation applies only with non-random keys. When I dug into this (albeit briefly) a while back, I was unable to find any source for that recommendation which didn't trace back to WEP's disastrously non-random key-generation procedure. I would be curious to know whether this is still an issue *with* good random-bits keys. (With a reference, not just folklore; my suspicion is that the WEP problem is being over-generalized in the folklore.) Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Tue Jun 17 08:32:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5HFWorb092966; Tue, 17 Jun 2003 08:32:51 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08349 Tue, 17 Jun 2003 10:51:35 -0400 (EDT) Message-Id: <5.2.0.9.2.20030617105616.03b23130@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 17 Jun 2003 10:57:42 -0400 To: ipsec@lists.tislabs.com From: Russ Housley Subject: Re: WG Last Call: draft-ietf-ipsec-esp-v3-05 Cc: kent@bbn.com In-Reply-To: <5.2.0.9.2.20030616152833.03e76520@mail.binhost.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I failed to include a comment in yesterday's posting. Here it is. I really did not want to have 13 comments anyway. So, here is number 14. 14. The references need to be divided in to normative and informative. Russ From owner-ipsec@lists.tislabs.com Tue Jun 17 08:32:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5HFWsrb092982; Tue, 17 Jun 2003 08:32:56 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA08335 Tue, 17 Jun 2003 10:49:31 -0400 (EDT) Message-Id: <5.2.0.9.2.20030617104718.03b2f940@mail.binhost.com> X-Sender: housley@mail.binhost.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 17 Jun 2003 10:55:29 -0400 To: ipsec@lists.tislabs.com From: Russ Housley Subject: WG Last Call: draft-ietf-ipsec-rfc2402bis-03 Cc: kent@bbn.com Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I have a few comments on the updated AH specification. 1. Please delete the last line of the Abstract. In my opinion, pointers to subsequent sections belong in the Introduction, not the Abstract. 2. Please move the last two paragraphs of the Introduction to the beginning. This will tell the reader the material that the expected to be understood before they get too deep, and it will define MAY. SHOULD, MUST, and so on before they are used. 3. There is a reference to [STD-2] in the first paragraph of section 2, but [STD-2] is not listed in the references. 4. The references need to be divided in to normative and informative. Russ From owner-ipsec@lists.tislabs.com Tue Jun 17 11:33:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5HIXNrb002885; Tue, 17 Jun 2003 11:33:24 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA09125 Tue, 17 Jun 2003 14:01:30 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3EED762C.5060306@nomadiclab.com> References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EED762C.5060306@nomadiclab.com> Date: Tue, 17 Jun 2003 13:59:00 -0400 To: Pekka Nikander From: Stephen Kent Subject: Re: AHbis WG LC: need for source address based selectors Cc: ipsec@lists.tislabs.com, Barbara Fraser , tytso@mit.edu, SEND WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:47 AM +0300 6/16/03, Pekka Nikander wrote: >One more comment to the AHbis WG LC: > >AHbis currently states the following: > >>2.4 Security Parameters Index (SPI) >> >>The SPI is an arbitrary 32-bit value that is used by a receiver to >>identify the SA to which an incoming packet is bound. For a unicast >>SA, the SPI can be used by itself to specify an SA, or it may be >>used >>in conjunction with the IPsec protocol type (in this case AH). >>Since, for unicast SAs, the SPI value is generated by the receiver, >>whether the value is sufficient to identify an SA by itself, or >>whether it must be used in conjunction with the IPsec protocol >>value is a local matter. The SPI field is mandatory and this >>mechanism for >>mapping inbound traffic to unicast SAs described above MUST be >>supported by all AH implementations. > >However, in the SEND WG we are using AH with public key crypto, >with a fixed SPI. There the key used depends on the sender of >the message, not the receiver. Hence, for our purposes neither >the SPI alone nor SPI + protocol are enough. We need also the ability >to select the SA based on SPI + source address, even for unicast. > > >>If an IPsec implementation supports multicast, then it MUST support >>multicast SAs using the following algorithm for mapping inbound >>IPsec >>datagrams to SAs. ... Each entry in the Security Association >>Database (SAD) [KA98a] must indicate whether the SA lookup makes use >>of the source and destination IP addresses, in addition to the SPI. >>... (There is no current requirement to support SA mapping based on >>the source address but not the destination address, thus one of the >>possible four values is not meaningful.) .... > >Since we are using PK crypto, we also need the possibility for >selecting the SA based solely on the source address. In fact, >for our fixed SPI, the destination address does not have any role, >not even whether the destination address is unicast or multicast. > >I don't know how to handle this so late in the process. I would >like to see the text to be sufficiently revised to allow source >address based SA selection, so that we could use it directly in SEND. >However, I have no idea how the IPSEC WG would feel about that. > >--Pekka Nikander > SEND WG co-chair It sounds like SEND would like to use the AH format, but has a processing model that is not aligned with the way IPsec uses SAs in general. We had extensive discussion in this WG about demuxing for inbound IPsec traffic after the MSEC folks expressed concern about the current process last fall. The demuxing spec has been very stable for several YEARS; we tweaked it very slightly for MSEC, after considerable debate and analysis, to accommodate SSM. Your proposed change represents yet another bit of complexity for an IPsec implementation and I question whether the WG ought to agree to such a change at this late date. Steve From owner-ipsec@lists.tislabs.com Tue Jun 17 13:28:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5HKSSrb008793; Tue, 17 Jun 2003 13:28:28 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA09454 Tue, 17 Jun 2003 15:29:33 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Tue, 17 Jun 2003 12:35:33 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: Promoting PRF_AES128_CBC and AUTH_AES_XCBC_96 from SHOULD to SHOULD+ Cc: Hugo Krawczyk , "Theodore Ts'o" , Barbara Fraser Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 1:16 AM +0300 6/10/03, Hugo Krawczyk wrote: >I see no need for further I-D's. As I said in a recent message all is >needed is a pointer to the AES-XCBC-MAC draft for the definition of what >ikev2 calls PRF_AES128_CBC. All other issues regarding the use of prf are >taken care by the ikev2 draft itself. In particular, the draft completely >specifies the use of prf's whether with variable length key (such as >HMAC-SHA) or fixed length key (such as aes128-cbc). The only prf's that >are defined as MUST NOT USE are those whose output is shorter than the key >itself (such as 3DES). All other discussions regarding prf use in ikev2 >were resolved and reflected in the ikev2 draft. Based on the fact that the AES-XCBC-MAC-96 draft is in the RFC Editor's queue and therefore cannot be changed, I wrote a very short Internet Draft embodying what Hugo said here. It is available at . Assuming Hugo agrees that this matches his intent above, would the WG chairs please add this as a WG item as soon as possible so that Jeff's document and my document can point to it? --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Tue Jun 17 16:34:17 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5HNYFrb016110; Tue, 17 Jun 2003 16:34:17 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA10189 Tue, 17 Jun 2003 18:50:53 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16111.40043.641263.120711@ryijy.hel.fi.ssh.com> Date: Wed, 18 Jun 2003 01:55:39 +0300 From: Tero Kivinen To: Stephen Kent Cc: Pekka Nikander , ipsec@lists.tislabs.com, Barbara Fraser , tytso@mit.edu, SEND WG Subject: Re: AHbis WG LC: need for source address based selectors In-Reply-To: References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EED762C.5060306@nomadiclab.com> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 8 min X-Total-Time: 11 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > >I don't know how to handle this so late in the process. I would > >like to see the text to be sufficiently revised to allow source > >address based SA selection, so that we could use it directly in SEND. > >However, I have no idea how the IPSEC WG would feel about that. ... > considerable debate and analysis, to accommodate SSM. Your proposed > change represents yet another bit of complexity for an IPsec > implementation and I question whether the WG ought to agree to such a > change at this late date. If I undestand correctly Pekka is asking that the document does not say you MUST NOT allow source address based SA selection (I do not thing it currently says so). I assume that if it does not say anything that this is forbidden or even better says that implementation MAY support SA selection based on the SPI and source address, he will be happy. Even if the document says "MAY" to this thing, it does not require anybody to change anything nor does it make any implementations non-conforming. We are simply allowing implementations to also have this kind of features too. I.e adding something like this to the text: "The SPIs from the reserved range may used different demultiplexing algorithms and use source and/or destination address and/or protocols and/or some other information for the actual demultiplexing. A document describing new reserved SPI number MUST also specify the demultiplexing algorithm used for that specific SPI." -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Jun 17 19:37:40 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5I2bdrb020502; Tue, 17 Jun 2003 19:37:39 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA10884 Tue, 17 Jun 2003 22:08:18 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <16111.40043.641263.120711@ryijy.hel.fi.ssh.com> References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EED762C.5060306@nomadiclab.com> <16111.40043.641263.120711@ryijy.hel.fi.ssh.com> Date: Tue, 17 Jun 2003 22:12:53 -0400 To: Tero Kivinen From: Stephen Kent Subject: Re: AHbis WG LC: need for source address based selectors Cc: Pekka Nikander , ipsec@lists.tislabs.com, Barbara Fraser , tytso@mit.edu, SEND WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 1:55 AM +0300 6/18/03, Tero Kivinen wrote: >Stephen Kent writes: >> >I don't know how to handle this so late in the process. I would >> >like to see the text to be sufficiently revised to allow source >> >address based SA selection, so that we could use it directly in SEND. >> >However, I have no idea how the IPSEC WG would feel about that. >... >> considerable debate and analysis, to accommodate SSM. Your proposed >> change represents yet another bit of complexity for an IPsec >> implementation and I question whether the WG ought to agree to such a >> change at this late date. > >If I undestand correctly Pekka is asking that the document does not >say you MUST NOT allow source address based SA selection (I do not >thing it currently says so). I assume that if it does not say anything >that this is forbidden or even better says that implementation MAY >support SA selection based on the SPI and source address, he will be >happy. > >Even if the document says "MAY" to this thing, it does not require >anybody to change anything nor does it make any implementations >non-conforming. We are simply allowing implementations to also have >this kind of features too. > >I.e adding something like this to the text: > >"The SPIs from the reserved range may used different demultiplexing >algorithms and use source and/or destination address and/or protocols >and/or some other information for the actual demultiplexing. A >document describing new reserved SPI number MUST also specify the >demultiplexing algorithm used for that specific SPI." Tero, The primary motivation in the IETF for developing standards is to promote interoperability. What you seem to suggest is a that we not preclude someone from saying that they comply with IPsec, even though they would be following a demuxing policy that is not used in any extant implementations and thus would not be interoperable with any of these implementations. This does not promote interoperability; all it does is allow someone to claim conformance with a standard. That does not seem constructive and, as I noted, it only add to complexity. Am I missing something in your suggestion? Steve From owner-ipsec@lists.tislabs.com Tue Jun 17 20:30:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5I3UIrb022132; Tue, 17 Jun 2003 20:30:18 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA11020 Tue, 17 Jun 2003 23:01:28 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <3EEC2C43.9060302@nomadiclab.com> References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EEC2C43.9060302@nomadiclab.com> Date: Tue, 17 Jun 2003 23:05:11 -0400 To: Pekka Nikander , Barbara Fraser From: Stephen Kent Subject: Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences Cc: ipsec@lists.tislabs.com, tytso@mit.edu, James Kempf , SEND WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:20 AM +0300 6/15/03, Pekka Nikander wrote: >Based on our experiences in the SEND WG, I would like >to offer the following comments to the IPSEC WG, regarding >to the AHbis draft. > >> 1. Introduction >> >> .... >> >> host. ESP may be used to provide the same anti-replay and similar >> integrity services, and it also provides a confidentiality >> (encryption) service. The primary difference between the integrity >> provided by ESP and AH is the extent of the coverage. Specifically, >> ESP does not protect any IP header fields unless those fields are >> encapsulated by ESP (e.g., via use of tunnel mode). ... > >Comments: > > - Even though the text above is true and correct, it may give a wrong > impression. The most important difference is packet size. If ESP > is used, it is necessary to copy all the important information from > the fields that precede ESP into ESP (typically by employing > tunneling), thereby making the packet larger. Additionally, if the > protocols protected by ESP rely on any fields that precede ESP, ESP > processing should check that the fields within the ESP header and > the fields outside of it are equal. This is, by no means, trivial, > since tunnel mode is not always a solution, depending on context. > > Hence, I would suggest adding the following piece of text: > > It should be noticed that some applications (such as IPv6 > Neighbor Discovery or Mobile IPv6) rely on the integrity of some > of the fields in the IP header. Furthermore, using tunnel mode > may not be an option, since the very precense of a tunnel may > open attacks. Finally, the incresed packet size caused by > tunneling may be unacceptable to some applications. The extant text is correct. Until SEND has a comprehensive, coherent model for using AH that does not require changes to other parts of IPsec processing, I think it is appropriate to retain the current text. >-------------- > >> 3.2 Integrity Algorithms >> >> The integrity algorithm employed for the ICV computation is specified >> by the SA. For point-to-point communication, suitable integrity >> algorithms include keyed Message Authentication Codes (MACs) based on >> symmetric encryption algorithms (e.g., AES [AES] or on one-way hash >> functions (e.g., MD5, SHA-1, SHA-256, etc.). For multicast >> communication, a variety of cryptographic strategies for providing >> integrity have been developed and research continues in this area. > >Comment: > > - In the current SEND working group proposal, a public key algorithm > is proposed to be used even for point-to-point communication. > However, this probably does not warrant changing the text above. No, it does not. >-------------- > >> 3.4.2 Security Association Lookup >> >> .... >> document.) The SAD entry for the SA also [...] >> indicates the key required to validate the ICV. > >Comment > > - In the current SEND WG proposal, the SA does not indicate the key > to be used. Instead, the AH header itself contains the public > key. However, I don't know if the text above should be changed. > This is not consistent with the IPsec specs! Remember that a protocol such as AH is not just syntax; it also encompasses the rules for processing packets. In IPsec, the SAD entry for an SA stores the keys that are employed to process packets. In turn, the SAD entry is located by using the SPI from an inbound packet (for unicast traffic). If SEND wants to use AH then you need to use the protocol (including the processing spec) as defined in IPsec, not just the syntax from 2402. Suggesting that we change AH to accommodate SEND's possible use of it, in a fashion not consistent with the current specs, is asking quite a lot. Steve From owner-ipsec@lists.tislabs.com Tue Jun 17 21:07:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5I471rb023034; Tue, 17 Jun 2003 21:07:06 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA11156 Tue, 17 Jun 2003 23:39:18 -0400 (EDT) Date: Tue, 17 Jun 2003 23:43:39 -0400 From: "Theodore Ts'o" To: Paul Hoffman / VPNC Cc: ipsec@lists.tislabs.com Subject: Re: Duplication: Remove most of section 3.3.2 and all of 3.3.4 of draft-ietf-ipsec-ikev2 Message-ID: <20030618034339.GA713@think> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, Jun 10, 2003 at 08:05:43PM -0700, Paul Hoffman / VPNC wrote: > Hi again. Most of section 3.3.2 in draft-ietf-ipsec-ikev2 (almost) > duplicates the text from Jeff's algorithms document. Everything in > the section after the Transform Type Values table should be removed. > > All of section 3.3.4 of draft-ietf-ipsec-ikev2 is now covered in > Jeff's algorithms document. Thus, the whole section should be removed. None of the code points in the IKEV2 document are authoratative; that honor belongs to the IANA registry. Yet, they are useful because there are a useful guide to initial implementors. It is for that reason that I believe a little duplication can be a good thing. Otherwise, one could argue that all of the tables in IKEv2 are duplicative of the IANA registry, and therefore aren't needed; we should just establish the IANA registry and just delete all of the tables from the I-D (and from every other RFC that has initial codepoint values in them). - Ted From owner-ipsec@lists.tislabs.com Tue Jun 17 22:22:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5I5Mirb026216; Tue, 17 Jun 2003 22:22:45 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA11460 Wed, 18 Jun 2003 00:54:34 -0400 (EDT) Message-Id: <200306180500.h5I50PUe005589@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com, ietf-send@standards.ericsson.net Subject: Re: AHbis WG LC: need for source address based selectors In-reply-to: Your message of "Tue, 17 Jun 2003 22:12:53 EDT." Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 18 Jun 2003 01:00:23 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- I think that we are rushing the 2401bis/ESPbis/AHbis. I agree that there are lots of nice things that people want out there (64-bit replay counters, etc.), but I think that for AH in particular, we should let SEND do its thing first. I see no one waiting for AHbis to go forward. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPu/x5IqHRg3pndX9AQFgmgQAqpNV3b48kQSMF1jKopmmVKxqb63By9th Eh0nCyqIGMES655ipAF+rQiw4kT54RPfZmPQYeolXcYGvXokGjxdLCIMwNRzoirF r0okf1SoDOfMSqr+gdroR4repWc9C4/N4ufi1NoiIoBswLaYZa38emclTXZr2UlO 5BzuIqJFZZY= =d5lG -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Tue Jun 17 23:31:25 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5I6VOrb035113; Tue, 17 Jun 2003 23:31:25 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA11710 Wed, 18 Jun 2003 02:04:14 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16112.509.854857.215970@ryijy.hel.fi.ssh.com> Date: Wed, 18 Jun 2003 09:09:01 +0300 From: Tero Kivinen To: Stephen Kent Cc: Pekka Nikander , ipsec@lists.tislabs.com, Barbara Fraser , tytso@mit.edu, SEND WG Subject: Re: AHbis WG LC: need for source address based selectors In-Reply-To: References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EED762C.5060306@nomadiclab.com> <16111.40043.641263.120711@ryijy.hel.fi.ssh.com> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 14 min X-Total-Time: 13 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > >"The SPIs from the reserved range may used different demultiplexing ^ => use > >algorithms and use source and/or destination address and/or protocols > >and/or some other information for the actual demultiplexing. A > >document describing new reserved SPI number MUST also specify the ^ => must > >demultiplexing algorithm used for that specific SPI." ... > promote interoperability. What you seem to suggest is a that we not > preclude someone from saying that they comply with IPsec, even though > they would be following a demuxing policy that is not used in any > extant implementations and thus would not be interoperable with any > of these implementations. I have little problems of parsing what you are saying above, but what I said there does not affect interoperability at all, as it does not change any current implemenation to conforming or non-conforming. If the implementation wants to follow the AHbis then it must implement the demux policy that is MUST in it. This text does not change that. What that text says (or at least tries to say) is that there is future work in progress that might use different demuliplexing policies IN ADDITION to the current ones, and those future documents will define them later. What this means to implementator is that if he feels he might be wanting to comply to those (future) documents later he might want to write implementation so that new demultiplexing policies can also be used. The only MUST (or perhaps it should be "must") in my text was for the future document writers, not to any implementator. For implementators we just give hint that "yes, there is work going on, and you might want to create your architecture so that it can handle those future demultiplexing algorithms". > This does not promote interoperability; > all it does is allow someone to claim conformance with a standard. It will be conforming to the AHbis if and only if it implements the demultiplexing algorithms specified as MUST in the AHbis. This text does not change it. It will be conforming to some other future documents if it implements demultiplexing algorithms specified there. This text will not change that either. Only thing I was (trying) to say in the text was that "be prepared, there is other demultiplexing algorithm(s) coming in the future documents". > That does not seem constructive and, as I noted, it only add to > complexity. Adds complexity to where? I do not thing it changes anything in the implementations unless you plan to implement those future documents, and it will not change any bits in the wire, nor can you remove any of the current demultiplexing algorithm currently mandated by AHbis. > Am I missing something in your suggestion? I think so. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Jun 17 23:51:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5I6pWrb039056; Tue, 17 Jun 2003 23:51:32 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA11778 Wed, 18 Jun 2003 02:23:36 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16112.1673.849180.847121@ryijy.hel.fi.ssh.com> Date: Wed, 18 Jun 2003 09:28:25 +0300 From: Tero Kivinen To: Stephen Kent Cc: Pekka Nikander , Barbara Fraser , ipsec@lists.tislabs.com, tytso@mit.edu, James Kempf , SEND WG Subject: Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences In-Reply-To: References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EEC2C43.9060302@nomadiclab.com> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 16 min X-Total-Time: 16 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > syntax from 2402. Suggesting that we change AH to accommodate SEND's > possible use of it, in a fashion not consistent with the current > specs, is asking quite a lot. The SEND is a user of the AH. Are there any other real users for the AH? In earlier days there was people saying that we should remove the whole AH as nobody uses. Now there seems to be SEND that is using it, but they want to do something differently. Do we want to say to our (only?) user that no we do not allow you to do anything differently? Do we want them to create another protocol replacing their use of AH? Another people who have been saying that they want to use AH is Mobile IP people. What do they want? Is the current spec fine with them or do the want similar processing than SEND? Actually they quite often want to do demultiplexing based on the fields inside the mobility or routing header not the outer IP address. I.e they might need different demultiplexing algorithm too. So the real questions are: Is there any use for the AH as it is now specified? What are application(s) / protocol(s) which will use it? If we cannot answer to those questions I think we should drop the current AH from the IPsec WG and say that SEND/Mobile IP etc can specify it so that it will be suitable for them :-) I do not want any generic text saying "someone might want to use it if the phase of the moon is full and ..., and,... and ... export control ... and ... goverment ... and ...". I do want current real word example (where the current AH as specified in the current document) is actually used or is planned to be used. I do NOT see any use for the AH on the VPNs or road warriors IPsec clients. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Jun 17 23:57:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5I6vhrb039776; Tue, 17 Jun 2003 23:57:43 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA11823 Wed, 18 Jun 2003 02:32:01 -0400 (EDT) To: Tero Kivinen Cc: Stephen Kent , Pekka Nikander , Barbara Fraser , ipsec@lists.tislabs.com, tytso@mit.edu, James Kempf , SEND WG In-reply-to: kivinen's message of Wed, 18 Jun 2003 09:28:25 +0300. <16112.1673.849180.847121@ryijy.hel.fi.ssh.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences From: itojun@iijlab.net Date: Wed, 18 Jun 2003 15:38:08 +0900 Message-Id: <20030618063808.697EE92@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >So the real questions are: >Is there any use for the AH as it is now specified? >What are application(s) / protocol(s) which will use it? i believe there are real use of AH, we have been using AH to protect BGP sessions, and i'm about to write up a draft to use AH for protecting RIPng conversation among routers. even if there's very little use of AH in the community, major change to AH that SEND requires would require another IP protocol #, IMHO. itojun From owner-ipsec@lists.tislabs.com Wed Jun 18 00:06:19 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5I76Erb041177; Wed, 18 Jun 2003 00:06:18 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id CAA11861 Wed, 18 Jun 2003 02:41:09 -0400 (EDT) Message-Id: <200306180647.h5I6l6h6009703@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com, SEND WG Subject: Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences In-reply-to: Your message of "Wed, 18 Jun 2003 09:28:25 +0300." <16112.1673.849180.847121@ryijy.hel.fi.ssh.com> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Wed, 18 Jun 2003 02:47:05 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I agree strongly with Tero. I said for years that AH would get used - but certainly not for VPNs. That we didn't know where it would be important, that it would be. SEND is a customer here. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Wed Jun 18 00:37:50 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5I7bnrb045463; Wed, 18 Jun 2003 00:37:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA12102 Wed, 18 Jun 2003 03:08:05 -0400 (EDT) Message-ID: <3EF01165.1040906@nomadiclab.com> Date: Wed, 18 Jun 2003 10:14:45 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen Cc: Stephen Kent , ipsec@lists.tislabs.com, SEND WG Subject: SEND vs. IPsec AH (was Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt...) References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EEC2C43.9060302@nomadiclab.com> <16112.1673.849180.847121@ryijy.hel.fi.ssh.com> In-Reply-To: <16112.1673.849180.847121@ryijy.hel.fi.ssh.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve and Tero, [Taking my SEND WG chair hat firmly *off*, i.e., speaking for myself only.] Stephen Kent wrote: > Until SEND has a comprehensive, coherent model for using AH that does > not require changes to other parts of IPsec processing, ... With all respect, I sincerely believe that SEND will never come up with "a comprehensive, coherent model for using AH that does not require changes to other parts of IPsec processing". More on that below. If you disagree, please try to come up with a scheme where you use AH when you - don't have any IP addresses (i.e. during IPv6 DAD) - do not know in which network you are (public access) - do not trust most nodes in the network (public access) - and are still trying to figure out what node(s) to trust, how much, and in which respects - do not know which of the potentially many trust roots you should use to establish trust with the possibly existing trusted nodes in the otherwise untrusted network - want to operate, at a lower level of security, when you are unable to establish pre-configured trust with anyone - want to make this all *effectively*, without using zillions of messges, since you potentially have to do this each time you roam to a different IP network I still claim that there are situations where the integrity and data origin authentication of the IP header is important. Hence, I firmly believe that the text concerning the relationship between AH and ESP is misleading at best and perhaps even outright wrong. Using tunnel mode is not an answer, at least sometimes. >> - In the current SEND WG proposal, the SA does not indicate the key >> to be used. Instead, the AH header itself contains the public >> key. .... >> > This is not consistent with the IPsec specs! Actually I more or less agree with you, Steve! Indeed, that is one of the reasons why I am proposing changes to the current AH usage in SEND, basically moving the public key from the AH header to a separate extension header, to be placed before the AH header. (See the separate discussion at the SEND WG ML.) > In IPsec, the SAD entry for an SA stores the keys that are employed > to process packets. In turn, the SAD entry is located by using the > SPI from an inbound packet (for unicast traffic). I am very very well aware of that. I quite well remember what I learned while I implemented one of the early BITS IPsec stacks as a part of my PhD work back in 1994-1995. However, sometimes the SPI alone is not very useful, and sometimes using the destination address as a selector is not the right choice. (More on this on the separate thread.) > If SEND wants to use AH then you need to use the protocol (including > the processing spec) as defined in IPsec, not just the syntax from > 2402. Suggesting that we change AH to accommodate SEND's possible use > of it, in a fashion not consistent with the current specs, is asking > quite a lot. I agree. Actually, using the revised suggestion of moving the public key from the AH header to a separate extension header, thereby creating an "implicit" or "inline" one message KMP, seems to simplify issue. However, even in that case it would really make sense to perform SA selection based on the source address. However, I defer that discussion to the other thread. Tero Kivinen wrote: > The SEND is a user of the AH. ... Do we want to say to our > (only?) user that no we do not allow you to do anything differently? As Itojun pointed out (and Steve well knows), SEND is indeed not the only user of AH. Anyway, thanks for your supporting words. We should also remember that RFC2461/2462 explicitly states that AH is the method to be used for protecting IPv6 ND. That is, in fact, quite doable if you have a static environment with pre-configured security associations, PK based or symmetric. However, once you want to use AH in the public access environment, things get harder. See the outline above. > Do we want them to create another protocol replacing their use of AH? This is the very question. There are lots of folks at the SEND WG who believe so. That is, they believe that AH should not be used for securing IPv6 ND, and a separate protocol should be developed instead. > Another people who have been saying that they want to use AH is > Mobile IP people. What do they want? Is the current spec fine with > them or do the want similar processing than SEND? Having been there too (though recently not very actively), I strongly suspect that some of the MIPv6 requirements will be fairly similar to those of SEND. Both deal with IP address mappings, MIP with IP -> IP mappings and ND with IP -> lladdr mappings. > Is there any use for the AH as it is now specified? > What are application(s) / protocol(s) which will use it? I think Itojun answered to these. > If we cannot answer to those questions I think we should drop the > current AH from the IPsec WG and say that SEND/Mobile IP etc can > specify it so that it will be suitable for them :-) Thanks. See the other thread at saag. > I do NOT see any use for the AH on the VPNs or road > warriors IPsec clients. Here I tend to agree with you, Tero, but that is really beside the point of this discussion, IMHO. --Pekka Nikander From owner-ipsec@lists.tislabs.com Wed Jun 18 00:55:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5I7t0rb050727; Wed, 18 Jun 2003 00:55:00 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA12236 Wed, 18 Jun 2003 03:27:48 -0400 (EDT) Message-ID: <3EF01607.3080900@nomadiclab.com> Date: Wed, 18 Jun 2003 10:34:31 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Cc: ipsec@lists.tislabs.com, SEND WG Subject: Re: AHbis WG LC: need for source address based selectors References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EED762C.5060306@nomadiclab.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: >> Since we are using PK crypto, we also need the possibility for >> selecting the SA based solely on the source address. In fact, for >> our fixed SPI, the destination address does not have any role, not >> even whether the destination address is unicast or multicast. > It sounds like SEND would like to use the AH format, but has a > processing model that is not aligned with the way IPsec uses SAs in > general. Right now, yes indeed. With the proposed change of moving the public key to a separate extension header, thereby generating a one-message "inline" KMP, not really, IMHO. > We had extensive discussion in this WG about demuxing for inbound > IPsec traffic after the MSEC folks expressed concern about the > current process last fall. The demuxing spec has been very stable for > several YEARS; we tweaked it very slightly for MSEC, after > considerable debate and analysis, to accommodate SSM. I sort of followed that discussion, but not very closely. I can't claim that I would remember all the details. > Your proposed change represents yet another bit of complexity for an > IPsec implementation and I question whether the WG ought to agree to > such a change at this late date. I am sorry of the late date. My only excuse is that SEND has only recently progressed to a level where we are able to comment AHbis. Returning to the real question, I actually claim that the proposed change would simplify a typical implementation. According to the current spec, you may have to handle unicast and multicast addresses differently, and you have to implement the restriction that the "use source address, don't use destination address" is forbidden. Remember, IPv6 ND requires multicast, and hence a conforming implementation MUST implement the multicast demultiplexing algorithm anyway. One way of implementing the current specification is to implement the two nominal bits into the SAD database, and all the code required to check the source address, the destionation address, both, or neither. After that, one would *add* the code to forbid the bit pattern indicating that only the source address check sould be made. From an implementation point of view, these restrictions are additional complexity, and removing them would reduce complexity. But maybe you had some other type of complexity in mind? Actually, the minimum change to AHbis would be to remove the paranthesized sentence "(There is no current requirement to support SA mapping based on the source address but not the destination address, thus one of the possible four values is not meaningful.)" Adding some clarifying text, indicating that if only the source address is used for demultiplexing, then whether the destination address is multicast or unicast does not matter, would be helpful, too. --Pekka Nikander From owner-ipsec@lists.tislabs.com Wed Jun 18 01:12:11 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5I8CArb054335; Wed, 18 Jun 2003 01:12:10 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA12371 Wed, 18 Jun 2003 03:44:59 -0400 (EDT) Message-ID: <3EF01A0E.3020908@nomadiclab.com> Date: Wed, 18 Jun 2003 10:51:42 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Cc: Tero Kivinen , ipsec@lists.tislabs.com, SEND WG Subject: Re: AHbis WG LC: need for source address based selectors References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EED762C.5060306@nomadiclab.com> <16111.40043.641263.120711@ryijy.hel.fi.ssh.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve and Tero, Tero wrote: >> If I undestand correctly Pekka is asking that the document does not >> say you MUST NOT allow source address based SA selection (I do not >> thing it currently says so). I assume that if it does not say anything >> that this is forbidden or even better says that implementation MAY >> support SA selection based on the SPI and source address, he will be >> happy. I would be quite happy if the AHbis allowed source address based selectors even implicitly. Right now it has the paranthesized sentense saying that the particular nominal bit pattern is not meaningful, thereby implicitly forbidding selecting SA using only the source address. Tero wrote: >> "The SPIs from the reserved range may used different demultiplexing >> algorithms and use source and/or destination address and/or protocols >> and/or some other information for the actual demultiplexing. A >> document describing new reserved SPI number MUST also specify the >> demultiplexing algorithm used for that specific SPI." I don't even need this much to be said. Just removing the paranthesized sentence would be mostly enough. Let me reiterate here why source address based selection would be useful. Right now SEND carries a public signature key and other parameters in the AH header, and uses only one AH SA which extracts the key from the header, checks the validity of the key either with CGA or against certificates, and verifies the signature. I tend to agree with Steve that this is not really consistent with the IPsec model. Hence, what I have proposed is to move the key and associated data from the AH header to a separate extension header that would precede the AH header in processing order. In this scheme, the extension header creates an AH SA on the fly. (Didn't SKIP do something like this?) If CGA is used, the AH SA is only valid for processing this single packet; if certificates is used, the lifetime of the SA depends on what the certs and what the local policy state. When the AH header is handled, the SA is already there, and AH just does the "usual thing", in this case checks the signature. The problem is really how to find the right SA. Destination address is not the answer, since the scheme must work both with multicast and with unicast. With multicast only you perhaps could use a combination of destination and source addresses, but not with unicast. In many cases you don't have any state associated with the destination node, you are just replying to a multicast message. You can't really allocate a new SPI in the inline KMP, since you have only one message, and the destination selects the SPI values to be used. Consequently, the only reasonable field to use for selecting the right SA would be the source address. Furthermore, that would be the logical choice, since the public key is directly related to the source address anyway. I hope this makes this all clearer. --Pekka Nikander From owner-ipsec@lists.tislabs.com Wed Jun 18 09:00:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5IG07rb087526; Wed, 18 Jun 2003 09:00:07 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA13844 Wed, 18 Jun 2003 11:19:17 -0400 (EDT) Message-ID: <00e001c335a9$4bef1250$4204300a@DCLKEMPFTP> From: "James Kempf" To: "Tero Kivinen" , "Stephen Kent" Cc: "Pekka Nikander" , , "Barbara Fraser" , , "SEND WG" References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EED762C.5060306@nomadiclab.com> <16111.40043.641263.120711@ryijy.hel.fi.ssh.com> Subject: Re: AHbis WG LC: need for source address based selectors Date: Wed, 18 Jun 2003 07:52:48 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, > The primary motivation in the IETF for developing standards is to > promote interoperability. What you seem to suggest is a that we not > preclude someone from saying that they comply with IPsec, even though > they would be following a demuxing policy that is not used in any > extant implementations and thus would not be interoperable with any > of these implementations. This does not promote interoperability; > all it does is allow someone to claim conformance with a standard. > That does not seem constructive and, as I noted, it only add to > complexity. > > Am I missing something in your suggestion? > I read Tero's suggested text as only applying to a new SPI in the reserved region. It would therefore promote interoperability for that SPI, but should not impact any other. Perhaps the text needs to be strengthened to make this clearer? jak From owner-ipsec@lists.tislabs.com Wed Jun 18 10:13:39 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5IHDcrb094245; Wed, 18 Jun 2003 10:13:39 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14113 Wed, 18 Jun 2003 12:43:19 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <20030618034339.GA713@think> References: <20030618034339.GA713@think> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Wed, 18 Jun 2003 09:49:27 -0700 To: "Theodore Ts'o" From: Paul Hoffman / VPNC Subject: Re: Duplication: Remove most of section 3.3.2 and all of 3.3.4 of draft-ietf-ipsec-ikev2 Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:43 PM -0400 6/17/03, Theodore Ts'o wrote: >On Tue, Jun 10, 2003 at 08:05:43PM -0700, Paul Hoffman / VPNC wrote: >> Hi again. Most of section 3.3.2 in draft-ietf-ipsec-ikev2 (almost) >> duplicates the text from Jeff's algorithms document. Everything in >> the section after the Transform Type Values table should be removed. >> >> All of section 3.3.4 of draft-ietf-ipsec-ikev2 is now covered in >> Jeff's algorithms document. Thus, the whole section should be removed. > >None of the code points in the IKEV2 document are authoratative; that >honor belongs to the IANA registry. Very true. > Yet, they are useful because >there are a useful guide to initial implementors. Correct. > It is for that >reason that I believe a little duplication can be a good thing. If you have to read two RFCs in order to implement IKEv2, having some duplication between them doesn't help anyone. And having differences between the two RFCs for the same values is exactly wrong. What you are proposing is exactly one of the mistakes that we had in IKEv1 that we said many times we wanted to avoid in IKEv2. >Otherwise, one could argue that all of the tables in IKEv2 are >duplicative of the IANA registry, and therefore aren't needed; we >should just establish the IANA registry and just delete all of the >tables from the I-D (and from every other RFC that has initial >codepoint values in them). This isn't the way that the IETF works. New registries get established by RFCs that have values in them, and then can be expanded based on the rules established in the RFCs. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Wed Jun 18 10:22:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5IHMNrb094496; Wed, 18 Jun 2003 10:22:24 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA14157 Wed, 18 Jun 2003 12:55:51 -0400 (EDT) Message-ID: <014801c335ae$5e53aeb0$4204300a@DCLKEMPFTP> From: "James Kempf" To: "Pekka Nikander" , "Tero Kivinen" Cc: "Stephen Kent" , , "SEND WG" References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EEC2C43.9060302@nomadiclab.com> <16112.1673.849180.847121@ryijy.hel.fi.ssh.com> <3EF01165.1040906@nomadiclab.com> Subject: Re: SEND vs. IPsec AH (was Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt...) Date: Wed, 18 Jun 2003 08:29:11 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Just to clarify a bit to what Pekka has said (and with my SEND WG chair hat on). Mobile IP faced some similar issues to what SEND is currently facing in the area of securing binding updates to correspondent nodes, which caused them to abandon AH and develop a new protocol. In SEND, we have a reasonably complete design using AH based on a reserved SPI that would work with RSA, but it does require an implementation for the SA that behaves somewhat differently from the two standard cases of a manual SA or an SA established with IKE. Pekka has suggested some baseline changes in the design that would reduce the IPsec implementation work, so most of these differences are due to the fact the public key is being used, some are due to other factors around the particular application. Depending on what you believe the reserved SPI were for, this could be viewed either as an unnecessary complexity or an extension. That said, there is strong feeling from some security-knowledgable SEND WG members and a major vendor that reviewed the initial design that too many changes would be required in IPsec, and that SEND should also develop a new protocol. We'll be discussing a proposal from Jari Arkko on the list and at the meeting to use ND options rather than AH, despite the fact the AH was specified in RFC 2461/2462. This is something we've been very strongly trying to avoid, since the intent of SEND was to be very conservative. There is no concensus in the WG at the moment about which way to go, since we've just begun the discussion. Now removing my WG chair hat and more or less quietly and inobtrusively slipping on my IAB hat (but not, of course, in any way speaking for the IAB), these two cases where AH has been tried to secure IP signaling traffic and found significant difficulties suggest that there might be a more fundamental problem involving securing IP signaling that might benefit from some additional attention. From Ito-jun's email, it sounds like he has examples of cases where AH out of the box works with securing BGP updates, so the perhaps there is a class of IP signaling security problems that can be solved by AH. Knowing the boundaries of that class might be helpful. jak ----- Original Message ----- From: "Pekka Nikander" To: "Tero Kivinen" Cc: "Stephen Kent" ; ; "SEND WG" Sent: Wednesday, June 18, 2003 12:14 AM Subject: SEND vs. IPsec AH (was Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt...) > Steve and Tero, > > [Taking my SEND WG chair hat firmly *off*, i.e., speaking for > myself only.] > > Stephen Kent wrote: > > Until SEND has a comprehensive, coherent model for using AH that does > > not require changes to other parts of IPsec processing, ... > > With all respect, I sincerely believe that SEND will never come up > with "a comprehensive, coherent model for using AH that does > not require changes to other parts of IPsec processing". More on that > below. If you disagree, please try to come up with a scheme where > you use AH when you > > - don't have any IP addresses (i.e. during IPv6 DAD) > > - do not know in which network you are (public access) > > - do not trust most nodes in the network (public access) > - and are still trying to figure out what node(s) to trust, > how much, and in which respects > > - do not know which of the potentially many trust roots you > should use to establish trust with the possibly existing > trusted nodes in the otherwise untrusted network > > - want to operate, at a lower level of security, when you > are unable to establish pre-configured trust with anyone > > - want to make this all *effectively*, without using zillions > of messges, since you potentially have to do this each time > you roam to a different IP network > > I still claim that there are situations where the integrity and > data origin authentication of the IP header is important. > Hence, I firmly believe that the text concerning the relationship > between AH and ESP is misleading at best and perhaps even outright > wrong. Using tunnel mode is not an answer, at least sometimes. > > >> - In the current SEND WG proposal, the SA does not indicate the key > >> to be used. Instead, the AH header itself contains the public > >> key. .... > >> > > This is not consistent with the IPsec specs! > > Actually I more or less agree with you, Steve! Indeed, that is > one of the reasons why I am proposing changes to the current AH > usage in SEND, basically moving the public key from the AH header > to a separate extension header, to be placed before the AH header. > (See the separate discussion at the SEND WG ML.) > > > In IPsec, the SAD entry for an SA stores the keys that are employed > > to process packets. In turn, the SAD entry is located by using the > > SPI from an inbound packet (for unicast traffic). > > I am very very well aware of that. I quite well remember what > I learned while I implemented one of the early BITS IPsec stacks > as a part of my PhD work back in 1994-1995. > > However, sometimes the SPI alone is not very useful, and sometimes > using the destination address as a selector is not the right choice. > (More on this on the separate thread.) > > > If SEND wants to use AH then you need to use the protocol (including > > the processing spec) as defined in IPsec, not just the syntax from > > 2402. Suggesting that we change AH to accommodate SEND's possible use > > of it, in a fashion not consistent with the current specs, is asking > > quite a lot. > > I agree. Actually, using the revised suggestion of moving the > public key from the AH header to a separate extension header, > thereby creating an "implicit" or "inline" one message KMP, > seems to simplify issue. However, even in that case it > would really make sense to perform SA selection based on the > source address. However, I defer that discussion to the other > thread. > > Tero Kivinen wrote: > > The SEND is a user of the AH. ... Do we want to say to our > > (only?) user that no we do not allow you to do anything differently? > > As Itojun pointed out (and Steve well knows), SEND is indeed not > the only user of AH. Anyway, thanks for your supporting words. > > We should also remember that RFC2461/2462 explicitly states that > AH is the method to be used for protecting IPv6 ND. That is, in fact, > quite doable if you have a static environment with pre-configured > security associations, PK based or symmetric. However, once you > want to use AH in the public access environment, things get harder. > See the outline above. > > > Do we want them to create another protocol replacing their use of AH? > > This is the very question. There are lots of folks at the > SEND WG who believe so. That is, they believe that AH should > not be used for securing IPv6 ND, and a separate protocol should > be developed instead. > > > Another people who have been saying that they want to use AH is > > Mobile IP people. What do they want? Is the current spec fine with > > them or do the want similar processing than SEND? > > Having been there too (though recently not very actively), I strongly > suspect that some of the MIPv6 requirements will be fairly similar > to those of SEND. Both deal with IP address mappings, MIP with > IP -> IP mappings and ND with IP -> lladdr mappings. > > > Is there any use for the AH as it is now specified? > > What are application(s) / protocol(s) which will use it? > > I think Itojun answered to these. > > > If we cannot answer to those questions I think we should drop the > > current AH from the IPsec WG and say that SEND/Mobile IP etc can > > specify it so that it will be suitable for them :-) > > Thanks. See the other thread at saag. > > > I do NOT see any use for the AH on the VPNs or road > > warriors IPsec clients. > > Here I tend to agree with you, Tero, but that is really beside > the point of this discussion, IMHO. > > --Pekka Nikander > > -------------------------------------------------------------------- > To unsubscribe from this list, send email with "UNSUBSCRIBE" in the > body to . > Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html > -------------------------------------------------------------------- > From owner-ipsec@lists.tislabs.com Wed Jun 18 19:51:13 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5J2p9rb017368; Wed, 18 Jun 2003 19:51:12 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA15888 Wed, 18 Jun 2003 22:16:40 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: References: Date: Wed, 18 Jun 2003 22:22:50 -0400 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: Re: LAST CALL: IKE Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In anticipation of several proposed changes to RFC 2401, I would like to suggest a few additional payloads to be added to IKE v2. Several folks have asked for the ability to place traffic with different TOS values on different SAs, which requires that the TOS field (IPv4) and the flow spec field (IPv6) be useable as selectors. If we agree to add this feature, we need the ability to negootiate this in IKE. A few folks have observed that the current mandate for black side fragmentation poses DoS vulnerabilities for receivers. Thus we may choose to allow (or recommend) red side fragmentation. If so, we need to be able to negotiate use of this capability on a per-SA basis, and to notify the receiver that NO black fragments should be accepted, because none will be sent on this SA. As a separate matter, I had requested a few months ago that we allow IKE peers to negotiate use of groups other than the set defined in Oakley. I see that there is a provision to negotiate other choices for P, but not for G. I apologize for not noticing this sooner. I would like to see the negotiation made more general, so that both the generator as well as the exponent are values that peers can negotiate. Thanks, Steve From owner-ipsec@lists.tislabs.com Wed Jun 18 19:52:35 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5J2qYrb017503; Wed, 18 Jun 2003 19:52:34 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA15915 Wed, 18 Jun 2003 22:26:48 -0400 (EDT) To: jari.arkko@piuha.net Cc: Tero Kivinen , Stephen Kent , Pekka Nikander , Barbara Fraser , ipsec@lists.tislabs.com, tytso@mit.edu, James Kempf , SEND WG In-reply-to: jari.arkko's message of Wed, 18 Jun 2003 23:26:39 +0300. <3EF0CAFF.20106@piuha.net> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences From: itojun@iijlab.net Date: Thu, 19 Jun 2003 11:32:57 +0900 Message-Id: <20030619023257.0A66889@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> even if there's very little use of AH in the community, major change >> to AH that SEND requires would require another IP protocol #, IMHO. >I'm not sure how significant the changes are, e.g. much of it can be seen >as the properties of a new algorithm. draft-ietf-send-ipsec-00.txt section 7 looks like a totally new protocol proposal (not a new algorithm) to me. AH needs to fall into what is defined in RFC2402, and draft-ietf-send-ipsec-00.txt goes far beyond what defined in RFC2402. itojun From owner-ipsec@lists.tislabs.com Wed Jun 18 20:06:09 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5J364rb017870; Wed, 18 Jun 2003 20:06:09 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA15930 Wed, 18 Jun 2003 22:36:46 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <16112.1673.849180.847121@ryijy.hel.fi.ssh.com> References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EEC2C43.9060302@nomadiclab.com> <16112.1673.849180.847121@ryijy.hel.fi.ssh.com> Date: Wed, 18 Jun 2003 22:42:20 -0400 To: Tero Kivinen From: Stephen Kent Subject: Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences Cc: Pekka Nikander , Barbara Fraser , ipsec@lists.tislabs.com, tytso@mit.edu, James Kempf , SEND WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 9:28 AM +0300 6/18/03, Tero Kivinen wrote: >Stephen Kent writes: >> syntax from 2402. Suggesting that we change AH to accommodate SEND's >> possible use of it, in a fashion not consistent with the current >> specs, is asking quite a lot. > >The SEND is a user of the AH. Are there any other real users for the >AH? In earlier days there was people saying that we should remove the >whole AH as nobody uses. Now there seems to be SEND that is using it, >but they want to do something differently. Do we want to say to our >(only?) user that no we do not allow you to do anything differently? The way you seem to want to use AH is so different from normal IPsec processing as to warrant having a different protocol, in my view. You can't just appropriate the name of the protocol and its syntax, but change the processing model. >Do we want them to create another protocol replacing their use of AH? >Another people who have been saying that they want to use AH is Mobile >IP people. What do they want? Is the current spec fine with them or do >the want similar processing than SEND? Good question. >Actually they quite often want to do demultiplexing based on the >fields inside the mobility or routing header not the outer IP address. >I.e they might need different demultiplexing algorithm too. Then we have a BIG problem. So far I have not seen a mature proposal from mobile IP that requires what you suggest. > >So the real questions are: > > >Is there any use for the AH as it is now specified? Very little. But, that does not mean that one can redefine it and still have it be part of IPsec. >What are application(s) / protocol(s) which will use it? This is not the right question. The question is whether AH does what you want for SEND. if not, and if the changes are significant, then create a different protocol. >If we cannot answer to those questions I think we should drop the >current AH from the IPsec WG and say that SEND/Mobile IP etc can >specify it so that it will be suitable for them :-) The SEND WG can create its own protocol, but there is no technical rationale for reusing the AH name. Reuse would only cause confusion. >I do not want any generic text saying "someone might want to use it if >the phase of the moon is full and ..., and,... and ... export control >... and ... goverment ... and ...". > >I do want current real word example (where the current AH as specified >in the current document) is actually used or is planned to be used. I >do NOT see any use for the AH on the VPNs or road warriors IPsec >clients. We appear to disagree on the ground rules. You seem to be suggesting that AH is like an abandoned ship, and whoever gets to it first can claim the name and redefine it :-) If IPsec has no continuing use for AH, then maybe we can retire the protocol number after a few years, but we seem to have some folks who suggest otherwise. I think the best course is to define a protocol that does what SEND needs and not try to twist AH into that protocol. Steve From owner-ipsec@lists.tislabs.com Wed Jun 18 20:56:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5J3ugrb019373; Wed, 18 Jun 2003 20:56:48 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA16231 Wed, 18 Jun 2003 23:28:23 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <00e001c335a9$4bef1250$4204300a@DCLKEMPFTP> References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EED762C.5060306@nomadiclab.com> <16111.40043.641263.120711@ryijy.hel.fi.ssh.com> <00e001c335a9$4bef1250$4204300a@DCLKEMPFTP> Date: Wed, 18 Jun 2003 23:32:04 -0400 To: "James Kempf" , "Tero Kivinen" From: Stephen Kent Subject: Re: AHbis WG LC: need for source address based selectors Cc: "Pekka Nikander" , , "Barbara Fraser" , , "SEND WG" , kent@bbn.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 7:52 AM -0700 6/18/03, James Kempf wrote: >Steve, > >> The primary motivation in the IETF for developing standards is to >> promote interoperability. What you seem to suggest is a that we not >> preclude someone from saying that they comply with IPsec, even >though >> they would be following a demuxing policy that is not used in any >> extant implementations and thus would not be interoperable with any >> of these implementations. This does not promote interoperability; >> all it does is allow someone to claim conformance with a standard. >> That does not seem constructive and, as I noted, it only add to >> complexity. >> >> Am I missing something in your suggestion? >> > >I read Tero's suggested text as only applying to a new SPI in the >reserved region. It would therefore promote interoperability for that >SPI, but should not impact any other. Perhaps the text needs to be >strengthened to make this clearer? > > jak reserved SPIs are a holdover from the early days of IPsec and are generally not used. But, the change in processing that has been proposed is simply not consistent with the overall IPsec processing model and saying that it applies to only this one SPI does not make life better. I'm afraid that this is just a bad fit. Steve From owner-ipsec@lists.tislabs.com Wed Jun 18 22:17:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5J5HWrb021722; Wed, 18 Jun 2003 22:17:36 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id AAA16532 Thu, 19 Jun 2003 00:48:13 -0400 (EDT) Message-ID: <3EF14222.5000700@nomadiclab.com> Date: Thu, 19 Jun 2003 07:54:58 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: itojun@iijlab.net, jari.arkko@piuha.net Cc: Tero Kivinen , Stephen Kent , ipsec@lists.tislabs.com, James Kempf , SEND WG Subject: Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences References: <20030619023257.0A66889@coconut.itojun.org> In-Reply-To: <20030619023257.0A66889@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Itojun, itojun@iijlab.net wrote: > draft-ietf-send-ipsec-00.txt section 7 looks like a totally new protocol > proposal (not a new algorithm) to me. AH needs to fall into what is > defined in RFC2402, and draft-ietf-send-ipsec-00.txt goes far beyond > what defined in RFC2402. I more or less agree with you. In fact, I have proposed moving the keying material into a separate header, as I have explained in length in other messages. If such a change is made, the role of AH would be within the purpose of RFC2402, IMHO. This issue will be discussed in Vienna; we've reserved time for it at the SEND WG meeting. See the proposed WG agenda at the SEND ML. Now, independent on that, the newest version of the said draft is draft-ietf-send-ipsec-01.txt --Pekka Nikander From owner-ipsec@lists.tislabs.com Wed Jun 18 23:21:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5J6LTrb030670; Wed, 18 Jun 2003 23:21:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA16749 Thu, 19 Jun 2003 01:51:11 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Wed, 18 Jun 2003 22:57:21 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: ipsec@lists.tislabs.com Subject: Re: Duplication: Remove most of section 3.3.2 and all of 3.3.4 of draft-ietf-ipsec-ikev2 In-Reply-To: <20030618034339.GA713@think> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tue, 17 Jun 2003, Theodore Ts'o wrote: > None of the code points in the IKEV2 document are authoratative; that > honor belongs to the IANA registry. Yet, they are useful because > there are a useful guide to initial implementors. It is for that > reason that I believe a little duplication can be a good thing. > > Otherwise, one could argue that all of the tables in IKEv2 are > duplicative of the IANA registry, and therefore aren't needed; we > should just establish the IANA registry and just delete all of the > tables from the I-D (and from every other RFC that has initial > codepoint values in them). FWIW, this position is consistent with a recent IESG decision that initial versions of IANA-maintained MIB modules (which are a special type of registry) shall be published in an RFC, but shall be accompanied by a normative reference to the actual IANA registry URL and a note stating that the version maintained in that registry is the definitive one. //cmh From owner-ipsec@lists.tislabs.com Thu Jun 19 01:33:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5J8XDrb053171; Thu, 19 Jun 2003 01:33:13 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA17139 Thu, 19 Jun 2003 03:58:56 -0400 (EDT) Message-ID: <3EF16ED1.3040908@nomadiclab.com> Date: Thu, 19 Jun 2003 11:05:37 +0300 From: Pekka Nikander User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent Cc: Tero Kivinen , ipsec@lists.tislabs.com, James Kempf , SEND WG Subject: Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EEC2C43.9060302@nomadiclab.com> <16112.1673.849180.847121@ryijy.hel.fi.ssh.com> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, Tero Kivinen wrote: >> The SEND is a user of the AH. ... A major reason why why SEND currently uses AH is that Bellovin suggested that at the Yokohama BoF. James and I, as WC chairs, felt that we should at least *attempt* the way suggested by an AD. However, as it should be clear from this on-going discussion, it is far from clear if that is the right way. Personally, I believe that it indeed is, but others clearly disagree. Stephen Kent wrote: > The way you seem to want to use AH is so different from normal IPsec > processing as to warrant having a different protocol, in my view. You > can't just appropriate the name of the protocol and its syntax, but > change the processing model. I have already addressed this in a separate message. As a summary of that: if we are speaking about the current WG proposal, I tend to agree with you , but I also think that the issues can be solved fairly easily, with just a minor technical change to AHbis. >> Do we want them to create another protocol replacing their use of AH? > > Good question. Indeed. >> Is there any use for the AH as it is now specified? > > Very little. But, that does not mean that one can redefine it and still > have it be part of IPsec. Just out of curiosity: How do you define IPsec? RFC2401? > The SEND WG can create its own protocol, but there is no technical > rationale for reusing the AH name. Reuse would only cause confusion. In my (in this case very) humble opinion, I think that the question of reusing the AH name depends on the intent of the protocol, not only on its syntax. If the goal is the same, to provide integrity and data origin authentication for the whole IP packet, including the immutable or predictable header fields, then I think that the protocol could and should be called AH. If it uses public key crypto, and thereby creates (conceptual) Security Associations that are associated with the source of the packet rather than the destination, even for unicast, that does not change the intent. OTOH, I do agree that embedding KMP functionality into the AH header does not sound that good an idea. However, it did not appear to me how to separate the KMP functionality before I started to implement the current SEND proposal. AH has a long history. I think it would be better to return to the some early goals of AH rather than to deprecate it and start anew. --Pekka Nikander From owner-ipsec@lists.tislabs.com Thu Jun 19 06:31:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JDVirb074872; Thu, 19 Jun 2003 06:31:44 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18376 Thu, 19 Jun 2003 09:02:03 -0400 (EDT) Message-ID: <3EF0D24B.3080407@piuha.net> Date: Wed, 18 Jun 2003 23:57:47 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Pekka Nikander , Stephen Kent Cc: Tero Kivinen , ipsec@lists.tislabs.com, SEND WG Subject: Re: SEND vs. IPsec AH (was Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt...) References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EEC2C43.9060302@nomadiclab.com> <16112.1673.849180.847121@ryijy.hel.fi.ssh.com> <3EF01165.1040906@nomadiclab.com> In-Reply-To: <3EF01165.1040906@nomadiclab.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent wrote: >> Another people who have been saying that they want to use AH is Mobile >> IP people. What do they want? Is the current spec fine with them or do >> the want similar processing than SEND? Mobile IPv6 does not employ AH. Most of the security solution in MIPv6 is in the "application" layer. It does use ESP for one thing, namely the protection of signaling between the mobile node and its home agent where traditional security associations can be assumed to exist. It does place some requirements on IPsec, but the requirements for SEND are tougher. I still think current SEND approach is within the bounds of the IPsec architecture. And I think it would be a good idea for the IETF to think where it will apply AH, and what its future role is. However, I suspect an ND layer solution would be a surer bet, mainly because in SEND it would have access to all information, such as some of the addresses that don't appear in the IP header. --Jari From owner-ipsec@lists.tislabs.com Thu Jun 19 06:31:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JDVjrb074881; Thu, 19 Jun 2003 06:31:45 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18377 Thu, 19 Jun 2003 09:02:08 -0400 (EDT) Message-ID: <3EF0CAFF.20106@piuha.net> Date: Wed, 18 Jun 2003 23:26:39 +0300 From: Jari Arkko Reply-To: jari.arkko@piuha.net Organization: None User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: itojun@iijlab.net Cc: Tero Kivinen , Stephen Kent , Pekka Nikander , Barbara Fraser , ipsec@lists.tislabs.com, tytso@mit.edu, James Kempf , SEND WG Subject: Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences References: <20030618063808.697EE92@coconut.itojun.org> In-Reply-To: <20030618063808.697EE92@coconut.itojun.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk itojun wrote: > even if there's very little use of AH in the community, major change > to AH that SEND requires would require another IP protocol #, IMHO. I'm not sure how significant the changes are, e.g. much of it can be seen as the properties of a new algorithm. Nevertheless, I'm personally in favor of a SEND approach which uses ND options. More details at http://www.piuha.net/~jarkko/publications/send/dafts/draft-send-ndopt.txt --Jari From owner-ipsec@lists.tislabs.com Thu Jun 19 06:32:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JDVtrb074910; Thu, 19 Jun 2003 06:32:00 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA18407 Thu, 19 Jun 2003 09:07:11 -0400 (EDT) content-class: urn:content-classes:message Subject: DOI for ESP v3 Date: Thu, 19 Jun 2003 18:45:42 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Message-ID: <36993D449C7FA647BF43568E0793AB3E067BCC@nevis_pune_xchg.pune.nevisnetworks.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 Thread-Topic: DOI for ESP v3 Thread-Index: AcM1b5LKazkbaGP9SY+EY9fOC7l9qgA9M2dQ From: "Gandhar Gokhale" To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id JAA18404 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, I've come across drafts for ESP v3. I wanted to know is there any proposal/discussion going on for supporting different DOI values for ESP versions? If not, what about the coexistence of old IPSec entities and the new ones with the newer versions of ESP? Thanks and regards, Gandhar From owner-ipsec@lists.tislabs.com Thu Jun 19 09:06:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JG65rb085436; Thu, 19 Jun 2003 09:06:05 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA18926 Thu, 19 Jun 2003 11:27:20 -0400 (EDT) Message-ID: <002d01c33673$c578e7c0$416015ac@dclkempt40> From: "James Kempf" To: , Cc: "Tero Kivinen" , "Stephen Kent" , "Pekka Nikander" , "Barbara Fraser" , , , "SEND WG" References: <20030619023257.0A66889@coconut.itojun.org> Subject: Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences Date: Thu, 19 Jun 2003 08:02:14 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Itojun, > >> even if there's very little use of AH in the community, major change > >> to AH that SEND requires would require another IP protocol #, IMHO. > >I'm not sure how significant the changes are, e.g. much of it can be seen > >as the properties of a new algorithm. > > draft-ietf-send-ipsec-00.txt section 7 looks like a totally new protocol > proposal (not a new algorithm) to me. AH needs to fall into what is > defined in RFC2402, and draft-ietf-send-ipsec-00.txt goes far beyond > what defined in RFC2402. Could you clarify? What specifically leads you to conclude that SEND should be a new algorithm? I'm particularly interested in understanding what your feelings are about what should and should not be legitimately included under one of the reserved SPI before a protocol should be separated. jak From owner-ipsec@lists.tislabs.com Thu Jun 19 11:39:57 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JIdurb096108; Thu, 19 Jun 2003 11:39:57 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA19558 Thu, 19 Jun 2003 14:04:27 -0400 (EDT) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0564CDC6@corpmx14.us.dg.com> To: kent@bbn.com, ipsec@lists.tislabs.com Subject: QoS selectors (was LAST CALL: IKE) Date: Thu, 19 Jun 2003 14:01:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, > Several folks have asked for the ability to place traffic with > different TOS values on different SAs, which requires that the TOS > field (IPv4) and the flow spec field (IPv6) be useable as selectors. > If we agree to add this feature, we need the ability to negootiate > this in IKE. That would be the 6 bit DS Field, as defined in RFC 2780. The other two bits in the same header octets are used for ECN and should not be used as selectors. There are some subtle issues in QoS specification across administrative domain boundaries - in full generality, the DiffServ Code Point (DSCP) values used in the DS Field do not have global validity or meaning. It's ok to use DSCPs when the values are only expected to be meaningful to one end of the connection (e.g., receiver tells sender to set DSCP to in inner IP header for tunnel mode SA), or something in the middle can be expected to do the translation if necessary - the latter does not apply to IKE for obvious reasons. For more general negotiation, where both ends are expected to understand what is being negotiated, PHBIDs (RFC 3140) are appropriate. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ipsec@lists.tislabs.com Thu Jun 19 13:08:41 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JK8erb000182; Thu, 19 Jun 2003 13:08:40 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA19971 Thu, 19 Jun 2003 15:35:47 -0400 (EDT) Message-Id: <200306191941.h5JJfS824195@yogi> X-Mailer: exmh version 2.6.2 03/21/2003 with nmh-1.0.4 To: ipsec@lists.tislabs.com Subject: IKEv2 payload #14 Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Thu, 19 Jun 2003 14:41:28 -0500 From: "Stephen C. Koehler" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I recently noticed that payload type 14, which was the attribute payload for mode config and xauth in IKEv1 as been reused for TSi in IKEv2. This causes some hardships for IKEv1 implementations that support mode config and xauth, because now payload 14 will have completely different meanings, based on context. I think it would be better to leave payload 14 reserved in IKEv2. A couple of weeks ago I sent out a message noting the changed encoding for protocols in proposals (between IKEv1 and IKEv2). I didn't get any responses on this. Is anyone else having trouble dealing with changed encoding in IKEv2 implementations? I realize fixing these things would require bits on the wire changes, and it's rather late for that. However, I think it's important to make people aware of implementation issues, like this. -- Steve Koehler koehler@securecomputing.com From owner-ipsec@lists.tislabs.com Thu Jun 19 16:15:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5JNFWrb007976; Thu, 19 Jun 2003 16:15:32 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA20590 Thu, 19 Jun 2003 18:44:22 -0400 (EDT) Message-Id: <200306192249.h5JMnps21656@sydney.East.Sun.COM> Date: Thu, 19 Jun 2003 18:49:51 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Reply-To: Radia Perlman - Boston Center for Networking Subject: Re: QoS selectors (was LAST CALL: IKE) To: kent@bbn.com, ipsec@lists.tislabs.com, Black_David@emc.com MIME-Version: 1.0 Content-Type: TEXT/plain; charset=us-ascii Content-MD5: IHVaBhwbBVDyDTjuGsF1iA== X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.5.3_06 SunOS 5.9 sun4u sparc Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hmm. Actually, I think there is no reason to negotiate which TOS values go on which SA. The reason for different SAs for different TOS values is so that the sequence numbers don't get too far off (assuming that different TOS's go at different speeds). So it seems like the sender, which knows it wants to send n different TOSs for which speeds will vary, can open n SAs, and choose which of the TOSs to send on which of them. If A and B have n SAs already, then if A has k different TOS's, A can use the other half of the n SAs (and doesn't need to open more of them) if k < n. I *think* the current IKEv2 spec supports this. The previous draft said something about having to close redundant SAs. This one at least implies that the only time you'd close a redundant SA is if it happened as a result of a rekeying collision. A few of us had worked out language in the hallway at the last IETF, explicitly saying things like that only the creator of an SA could delete a redundant SA, but I think it was declared too late to make design decisions like that that might have other implications. Radia From: Black_David@emc.com To: kent@bbn.com, ipsec@lists.tislabs.com Subject: QoS selectors (was LAST CALL: IKE) MIME-Version: 1.0 Steve, > Several folks have asked for the ability to place traffic with > different TOS values on different SAs, which requires that the TOS > field (IPv4) and the flow spec field (IPv6) be useable as selectors. > If we agree to add this feature, we need the ability to negootiate > this in IKE. That would be the 6 bit DS Field, as defined in RFC 2780. The other two bits in the same header octets are used for ECN and should not be used as selectors. There are some subtle issues in QoS specification across administrative domain boundaries - in full generality, the DiffServ Code Point (DSCP) values used in the DS Field do not have global validity or meaning. It's ok to use DSCPs when the values are only expected to be meaningful to one end of the connection (e.g., receiver tells sender to set DSCP to in inner IP header for tunnel mode SA), or something in the middle can be expected to do the translation if necessary - the latter does not apply to IKE for obvious reasons. For more general negotiation, where both ends are expected to understand what is being negotiated, PHBIDs (RFC 3140) are appropriate. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ipsec@lists.tislabs.com Thu Jun 19 17:01:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5K01Lrb009869; Thu, 19 Jun 2003 17:01:21 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA20728 Thu, 19 Jun 2003 19:35:04 -0400 (EDT) Message-Id: <200306192341.h5JNexPj029036@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: IKEv2 payload #14 In-reply-to: Your message of "Thu, 19 Jun 2003 14:41:28 CDT." <200306191941.h5JJfS824195@yogi> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 19 Jun 2003 19:40:58 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Stephen" == Stephen C Koehler writes: Stephen> context. I think it would be better to leave payload 14 Stephen> reserved in IKEv2. I'd like IKEv2 to use all payloads that are entirely different in #. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ From owner-ipsec@lists.tislabs.com Thu Jun 19 17:06:53 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5K06rrb010043; Thu, 19 Jun 2003 17:06:53 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA20749 Thu, 19 Jun 2003 19:40:30 -0400 (EDT) Date: Thu, 19 Jun 2003 16:46:42 -0700 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Nat Traversal concern in IKEv2 From: Ricky Charlet To: ipsec mailingList Content-Transfer-Encoding: 7bit Message-Id: <473686B7-A2B0-11D7-9A9E-00039349B0FC@speakeasy.net> X-Mailer: Apple Mail (2.552) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy, I've wound up with some extra time on my hands lately and thought I'd contribute some more. So when sending NAT_DETECTION_SOURCE_IP or NAT_DETECTION_DESTINATION_IP these payloads contain a SHA1 hash of the IP address and port. First of all, there is no specification as to what key to use for the SHA1. And this is before the DH has completed. So I see no reasonable choice for how to key this algorithm. But more worrisome would be that a dictionary attack on all possible IP addresses with 500 and 4500 for ports would reveal the key with fairly light effort. So I perceive a requirement that the key used for this SHA1 in the NAT_DETECTION_* payloads MUST NOT be related in any way to the keys or key generating material used for privacy, integrity and authentication later. This requirement seems onerous. So perhaps we could move the NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads to somewhere in the protected portion of the IKE exchanges and just put the IP/port in the packet directly (not a SHA1 hash). What do y'all think? --- Ricky Charlet (formerly with Sonciwall and before that formerly with Redcreek) rcharlet@alumni.calpoly.edu 510.324.3163 From owner-ipsec@lists.tislabs.com Thu Jun 19 18:31:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5K1VXrb012455; Thu, 19 Jun 2003 18:31:33 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA21250 Thu, 19 Jun 2003 21:00:11 -0400 (EDT) Date: Thu, 19 Jun 2003 18:06:23 -0700 Subject: Re: Nat Traversal concern in IKEv2 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) From: Ricky Charlet To: ipsec mailingList Content-Transfer-Encoding: 7bit In-Reply-To: <473686B7-A2B0-11D7-9A9E-00039349B0FC@speakeasy.net> Message-Id: <694773BF-A2BB-11D7-9F93-00039349B0FC@speakeasy.net> X-Mailer: Apple Mail (2.552) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thursday, June 19, 2003, at 04:46 PM, Ricky Charlet wrote: > Howdy, > > I've wound up with some extra time on my hands lately and thought I'd > contribute some more. > > > So when sending NAT_DETECTION_SOURCE_IP or > NAT_DETECTION_DESTINATION_IP these payloads contain a SHA1 hash of the > IP address and port. > > First of all, there is no specification as to what key to use for the > SHA1. And this is before the DH has completed. So I see no reasonable > choice for how to key this algorithm. > > But more worrisome would be that a dictionary attack on all possible > IP addresses with 500 and 4500 for ports would reveal the key with > fairly light effort. So I perceive a requirement that the key used for > this SHA1 in the NAT_DETECTION_* payloads MUST NOT be related in any > way to the keys or key generating material used for privacy, integrity > and authentication later. This requirement seems onerous. > oops. Just a bit more thinking about the matter and I realized that knowing the 8 billion possible plain texts does not constitute a dictionary attack on the secret. And probably does not give much value to an attacker trying to recover the key. But, still, what key to use? And why not put this under the protected IKE exchanges? > > So perhaps we could move the NAT_DETECTION_SOURCE_IP and > NAT_DETECTION_DESTINATION_IP payloads to somewhere in the protected > portion of the IKE exchanges and just put the IP/port in the packet > directly (not a SHA1 hash). > > What do y'all think? > > > > > > --- > Ricky Charlet > (formerly with Sonciwall and before that formerly with Redcreek) > rcharlet@alumni.calpoly.edu > 510.324.3163 > > --- Ricky Charlet rcharlet@alumni.calpoly.edu 510.324.3163 From owner-ipsec@lists.tislabs.com Thu Jun 19 18:31:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5K1VXrb012456; Thu, 19 Jun 2003 18:31:33 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA21265 Thu, 19 Jun 2003 21:07:17 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Message-Id: <200306200113.h5K1DKs01069@sydney.East.Sun.COM> Date: Thu, 19 Jun 2003 21:13:29 -0400 To: "Ricky Charlet" , "ipsec mailingList" Reply-To: Subject: Re: Nat Traversal concern in IKEv2 X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk 1) it's not a keyed hash...it's just the straight SHA1. So that part is OK in the spec 2) You are right that it is mysterious to send the hashes of the addresses instead of the addresses themselves. It's computationally annoying to compute the actual addresses (in case a good guy wanted to do it for logging or debugging), but not sufficiently computationally difficult to prevent a bad guy from computing them. Luckily in practice the good guy doesn't need to know the exact addresses...they can just hash the addresses from the IP header and compare them with the NAT_DETECTION addresses. So it's not really a problem to do it the way it is. The theory behind hashing them was to prevent leaking internal net numbers outside. We (IKEv2) just copied the design from what was already implemented for NAT traversal for IKEv1. In the draft that we copied it acknowledged, in the "security considerations" section, the weakness that you mentioned (that a bad guy could compute it). Radia "Ricky Charlet" wrote: >So when sending NAT_DETECTION_SOURCE_IP or NAT_DETECTION_DESTINATION_IP >these payloads contain a SHA1 hash of the IP address and port. > >First of all, there is no specification as to what key to use for the >SHA1. And this is before the DH has completed. So I see no reasonable >choice for how to key this algorithm. > >But more worrisome would be that a dictionary attack on all possible IP >addresses with 500 and 4500 for ports would reveal the key with fairly >light effort. So I perceive a requirement that the key used for this >SHA1 in the NAT_DETECTION_* payloads MUST NOT be related in any way to >the keys or key generating material used for privacy, integrity and >authentication later. This requirement seems onerous. > > >So perhaps we could move the NAT_DETECTION_SOURCE_IP and >NAT_DETECTION_DESTINATION_IP payloads to somewhere in the protected >portion of the IKE exchanges and just put the IP/port in the packet >directly (not a SHA1 hash). > >What do y'all think? > From owner-ipsec@lists.tislabs.com Thu Jun 19 19:02:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5K223rb013389; Thu, 19 Jun 2003 19:02:03 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA21415 Thu, 19 Jun 2003 21:38:48 -0400 (EDT) Message-Id: <200306200144.h5K1ij6c032249@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com Subject: Re: QoS selectors (was LAST CALL: IKE) In-reply-to: Your message of "Thu, 19 Jun 2003 18:49:51 EDT." <200306192249.h5JMnps21656@sydney.East.Sun.COM> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Thu, 19 Jun 2003 21:44:44 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Radia" == Radia Perlman <- Boston Center for Networking > writes: Radia> Hmm. Actually, I think there is no reason to negotiate which Radia> TOS values go on which SA. The reason for different SAs for Radia> different TOS values is so that the sequence numbers don't get Radia> too far off (assuming that different TOS's go at different speeds). Radia> So it seems like the sender, which knows it wants to send n Radia> different Radia> TOSs for which speeds will vary, can open n SAs, and choose which Radia> of the TOSs to send on which of them. Sounds good in theory. It is not clear to me that everyone agrees that they can negotiate multiple SAs with IKEvX that do not apparently differ in terms of negotiated selectors. Further, the *responding* system doesn't know what the initiator wanted, so even if the initiator knows how to demux, it needs a way to tell the responder. Radia> A few of us had worked out language in the hallway at the last IETF, Radia> explicitly saying things like that only the creator of an SA could Radia> delete a redundant SA, but I think it was declared too late to make Radia> design decisions like that that might have other implications. That sounds okay, but still isn't perfect. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPvJnCoqHRg3pndX9AQGyUwP9EJTWcvJ4oCSd88KrYGtgsFVRw4Si96SO NHydCWHdBYdv4Gkk8FOr/wmhO+31EOwUjwGSN+hqTBkW1xA7cEhulCNY6HBLKbAg J0Yp4F/3rD0TKSJ8K2PSArXXvHeZXF4aC6sh6pzeAX3o+awkt7dgIEA2IjNzSVNI NokYfP19z2I= =10Kh -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Jun 19 19:32:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5K2WZrb014175; Thu, 19 Jun 2003 19:32:35 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA21559 Thu, 19 Jun 2003 22:06:29 -0400 (EDT) To: "James Kempf" Cc: jari.arkko@piuha.net, "Tero Kivinen" , "Stephen Kent" , "Pekka Nikander" , "Barbara Fraser" , ipsec@lists.tislabs.com, tytso@mit.edu, "SEND WG" In-reply-to: kempf's message of Thu, 19 Jun 2003 08:02:14 MST. <002d01c33673$c578e7c0$416015ac@dclkempt40> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences From: itojun@iijlab.net Date: Fri, 20 Jun 2003 11:12:38 +0900 Message-Id: <20030620021238.2E40E89@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> >> even if there's very little use of AH in the community, major change >> >> to AH that SEND requires would require another IP protocol #, IMHO. >> >I'm not sure how significant the changes are, e.g. much of it can be seen >> >as the properties of a new algorithm. >> >> draft-ietf-send-ipsec-00.txt section 7 looks like a totally new protocol >> proposal (not a new algorithm) to me. AH needs to fall into what is >> defined in RFC2402, and draft-ietf-send-ipsec-00.txt goes far beyond >> what defined in RFC2402. > >Could you clarify? What specifically leads you to conclude that SEND should >be a new algorithm? I'm particularly interested in understanding what your >feelings are about what should and should not be legitimately included under >one of the reserved SPI before a protocol should be separated. none of existing algorithm for AH defines structure within AH authentication data. therefore i assume AH algorithm to be some crypto-checksum algorithm, not a new protocol definition. for instance, if you write a program to support the draft, SEND use of AH would require certain amount of new code for parsing SEND authentication data packet format, not just a set of calls to crypto- checksum algorithm. AH packet processing should not be that different depending on SPI value. itojun From owner-ipsec@lists.tislabs.com Thu Jun 19 20:44:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5K3iLrb016098; Thu, 19 Jun 2003 20:44:22 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA21851 Thu, 19 Jun 2003 23:16:22 -0400 (EDT) Date: Thu, 19 Jun 2003 20:22:33 -0700 Subject: Re: Nat Traversal concern in IKEv2 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v552) Cc: "ipsec mailingList" To: From: Ricky Charlet In-Reply-To: <200306200113.h5K1DKs01069@sydney.East.Sun.COM> Message-Id: <6EE9BABC-A2CE-11D7-9F08-00039349B0FC@speakeasy.net> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.552) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Well this was pretty silly of me then. I had gotten so used to using SHA1 in a HMAC context that I forgot it was an H. My apologies for the confusion. But still, if there is a concern about leaking identities, then why not move the NAT_DETECTION payloads into the protected part of the exchange? The knowledge that we (or our peer) are behind a NAT is not needed until we attempt to send and/or receive ESP or AH. I guess that one (very good) reason not to change this, is that this is too late in the process to change something this insignificant. I don't have a strong opinion about this either way since I got my initial confusion corrected. --- Ricky Charlet (formerly with Sonicwall and before that formerly with Redcreek) rcharlet@alumni.calpoly.edu 510.324.3163 On Thursday, June 19, 2003, at 06:13 PM, Radia Perlman - Boston Center for Networking wrote: > 1) it's not a keyed hash...it's just the straight SHA1. > So that part is OK in the spec > > 2) You are right that it is mysterious to send > the hashes of the addresses instead of the addresses > themselves. It's computationally annoying to compute > the actual addresses (in case a good guy wanted > to do it for logging or debugging), > but not sufficiently computationally difficult to > prevent a bad guy from computing them. Luckily > in practice the good guy doesn't need to know > the exact addresses...they can just hash the > addresses from the IP header and compare them > with the NAT_DETECTION addresses. So it's > not really a problem to do it the way it is. > > The theory behind hashing them was to prevent leaking > internal net numbers outside. > > We (IKEv2) just copied the design from what was > already implemented for NAT traversal for IKEv1. > In the draft that we copied it acknowledged, in > the "security considerations" section, the weakness > that you mentioned (that a bad guy could compute it). > > Radia > > > > "Ricky Charlet" wrote: > >> So when sending NAT_DETECTION_SOURCE_IP or >> NAT_DETECTION_DESTINATION_IP >> these payloads contain a SHA1 hash of the IP address and port. >> >> First of all, there is no specification as to what key to use for the >> SHA1. And this is before the DH has completed. So I see no reasonable >> choice for how to key this algorithm. >> >> But more worrisome would be that a dictionary attack on all possible >> IP >> addresses with 500 and 4500 for ports would reveal the key with fairly >> light effort. So I perceive a requirement that the key used for this >> SHA1 in the NAT_DETECTION_* payloads MUST NOT be related in any way to >> the keys or key generating material used for privacy, integrity and >> authentication later. This requirement seems onerous. >> >> >> So perhaps we could move the NAT_DETECTION_SOURCE_IP and >> NAT_DETECTION_DESTINATION_IP payloads to somewhere in the protected >> portion of the IKE exchanges and just put the IP/port in the packet >> directly (not a SHA1 hash). >> >> What do y'all think? >> > > > > From owner-ipsec@lists.tislabs.com Fri Jun 20 07:30:38 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5KEUbrb077980; Fri, 20 Jun 2003 07:30:37 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA24057 Fri, 20 Jun 2003 10:02:07 -0400 (EDT) Message-Id: <200306201407.h5KE7n828394@yogi> X-Mailer: exmh version 2.6.2 03/21/2003 with nmh-1.0.4 To: ipsec@lists.tislabs.com Subject: Re: IKEv2 payload #14 In-Reply-To: Your message of "Thu, 19 Jun 2003 19:40:58 EDT." <200306192341.h5JNexPj029036@sandelman.ottawa.on.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 20 Jun 2003 09:07:49 -0500 From: "Stephen C. Koehler" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Thanks, Richard. Does anyone else have concerns about this? It seems to me that the options are (assuming there are any options this late in the game): 1. Leave the spec as it currently stands with conflicting use of payload 14 and changed structure definitions of a number of other payloads. 2. Move TSi to another number and leave payload 14 reserved in IKEv2. 3. Move any conflicting payload definitions to new numbers in IKEv2, but don't change the ones that have not changed in structure. 4. Make all IKEv2 payloads have numbers distinct from those in IKEv1, regardless of whether the structure or meaning has changed. I would very much like for IKEv2 to use option (3). (4) is perhaps overkill, but I could be convinced otherwise. > >>>>> "Stephen" == Stephen C Koehler writes: > Stephen> context. I think it would be better to leave payload 14 > Stephen> reserved in IKEv2. > > I'd like IKEv2 to use all payloads that are entirely different in #. > -- Steve Koehler koehler@securecomputing.com From owner-ipsec@lists.tislabs.com Fri Jun 20 07:37:05 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5KEb4rb079008; Fri, 20 Jun 2003 07:37:04 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA24035 Fri, 20 Jun 2003 09:58:13 -0400 (EDT) Message-Id: <200306201403.h5KE3rof045432@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Ricky Charlet cc: ipsec mailingList Subject: Re: Nat Traversal concern in IKEv2 In-reply-to: Your message of Thu, 19 Jun 2003 16:46:42 PDT. <473686B7-A2B0-11D7-9A9E-00039349B0FC@speakeasy.net> Date: Fri, 20 Jun 2003 16:03:53 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: So when sending NAT_DETECTION_SOURCE_IP or NAT_DETECTION_DESTINATION_IP these payloads contain a SHA1 hash of the IP address and port. ^^^^ => please note this is a plain hash. So I perceive a requirement that the key used for this SHA1 in the NAT_DETECTION_* payloads MUST NOT be related in any way to the keys or key generating material used for privacy, integrity and authentication later. This requirement seems onerous. => as there is no such key the requirement is fulfilled. So perhaps we could move the NAT_DETECTION_SOURCE_IP and NAT_DETECTION_DESTINATION_IP payloads to somewhere in the protected portion of the IKE exchanges and just put the IP/port in the packet directly (not a SHA1 hash). => this should give another useful but different property: protection of the peer addresses and ports... Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Fri Jun 20 08:07:25 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5KF7Orb080039; Fri, 20 Jun 2003 08:07:24 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA24189 Fri, 20 Jun 2003 10:40:26 -0400 (EDT) Message-ID: From: "Vohra, Meenakshi" To: ipsec@lists.tislabs.com Subject: Nortel Contivity Client with XAuth (Key-ID) Date: Thu, 19 Jun 2003 19:34:58 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C336D4.8B005F90" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C336D4.8B005F90 Content-Type: text/plain; charset="ISO-8859-1" Hello Everyone, I am trying to evaluate the Nortel's Contivity Client evaluation copy. After discovering the user name being sent as hash by Nortel client which I am able to resolve I am also seeing the client sending authentication method as pre-shared key. I want to test the client with XAuth so was wondering if someone could suggest me how to configure xauth-preshared-key as authentication method on the Nortel Client. So far I am using Authentication option as Username and password Authentication on Nortel Client. Thanks a lot, Meenakshi ------_=_NextPart_001_01C336D4.8B005F90 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Nortel Contivity Client with XAuth (Key-ID)

Hello Everyone,

I am trying to evaluate the Nortel's = Contivity Client evaluation copy. After discovering the user name being = sent as hash by Nortel client which I am able to resolve I am also = seeing the client sending authentication method as pre-shared key. I = want to test the client with XAuth so was wondering if someone could = suggest me how to configure xauth-preshared-key as authentication = method on the Nortel Client. So far I am using Authentication option as = Username and password Authentication on Nortel Client.


Thanks a lot,
Meenakshi

------_=_NextPart_001_01C336D4.8B005F90-- From owner-ipsec@lists.tislabs.com Fri Jun 20 08:10:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5KFAHrb080183; Fri, 20 Jun 2003 08:10:18 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA24205 Fri, 20 Jun 2003 10:45:25 -0400 (EDT) Message-ID: <0580F806F396E546B6505E66431AB143E41C7D@exch7.rhul.ac.uk> From: Schwiderski-Grosche Scarlet To: "'ipsec@lists.tislabs.com'" Subject: active user identity confidentiality protection Date: Fri, 20 Jun 2003 08:39:27 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C336FF.13E28AC0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C336FF.13E28AC0 Content-Type: text/plain; charset="iso-8859-1" Hi all, I would like to support the idea of protecting the user's identity against active attacks in IKEv2 for the remote access case (i.e. EAP message exchange), as recently raised by Hugo, Hannes and Scott. In the SHAMAN project, we identified this to be an important/essential requirement for access to future mobile networks. In GSM and UMTS, this is also a well-established requirement which is "solved" by using temporary identities (can be circumvented by using "false base station attacks"). Not protecting the user's identity against active attacks would mean to ignore long identified security requirements and may allow a bogus access network to get hold of the user's identity. Best wishes, Scarlet Dr. Scarlet Schwiderski-Grosche Information Security Group Royal Holloway, University of London Egham, Surrey TW20 0EX, UK Tel.: ++44-1784-443089 ------_=_NextPart_001_01C336FF.13E28AC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi = all,

 

I would like to support the idea of protecting the user's identity against active = attacks in IKEv2 for the remote access case (i.e. EAP message exchange), as = recently raised by Hugo, Hannes and Scott.

 

In the SHAMAN project, we identified this to be an important/essential = requirement for access to future mobile networks. In GSM and UMTS, this is also a well-established requirement which is "solved" by using = temporary identities (can be circumvented by using "false base station attacks"). Not protecting the user's identity against active = attacks would mean to ignore long identified security requirements and may allow a = bogus access network to get hold of the user's = identity.

 

Best wishes,

Scarlet

 

Dr. Scarlet = Schwiderski-Grosche

Information Security = Group

Royal Holloway, = University of = London

Egham, = Surrey = TW20 0EX, = UK

Tel.: = ++44-1784-443089

 

------_=_NextPart_001_01C336FF.13E28AC0-- From owner-ipsec@lists.tislabs.com Fri Jun 20 15:59:06 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5KMx5rb007387; Fri, 20 Jun 2003 15:59:05 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA25704 Fri, 20 Jun 2003 18:22:13 -0400 (EDT) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0564CDE2@corpmx14.us.dg.com> To: ipsec@lists.tislabs.com Subject: IKEv2 last call: editorial request Date: Fri, 20 Jun 2003 18:19:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Section 3.10.1 specifies tunnel/transport mode negotiation as: USE_TRANSPORT_MODE 24585 This notification MAY be included in a request message that also includes an SA requesting a CHILD_SA. It requests that the CHILD_SA use transport mode rather than tunnel mode for the SA created. If the request is accepted, the response MUST also include a notification of type USE_TRANSPORT_MODE. If the responder declines the request, the CHILD_SA will be established in tunnel mode. If this is unacceptable to the initiator, the initiator MUST delete the SA. Note: except when using this option to negotiate transport mode, all CHILD_SAs will use tunnel mode. Please add: Note: The ECN decapsulation modifications specified in Section 2.24 MUST be performed for every tunnel mode SA created by IKEv2. This complements the forward reference from 2.24 to 3.10.1. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ipsec@lists.tislabs.com Fri Jun 20 16:22:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5KNMSrb008260; Fri, 20 Jun 2003 16:22:28 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA25845 Fri, 20 Jun 2003 18:57:50 -0400 (EDT) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0564CDE3@corpmx14.us.dg.com> To: ipsec@lists.tislabs.com Subject: IKEv2 algorithms and UI suites comments Date: Fri, 20 Jun 2003 18:54:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Algorithms: draft-ietf-ipsec-ikev2-algorithms-02.txt Section 4.1.2: They are references by group number. Change "references" to "identified" or "referenced". Also I'd like to see a sentence added to say that all other groups not listed in the table are MAY. Section 4.1.3 At the risk of reopening an old topic, given the absence of a specification for use of RC4 with ESP and the known risks of stream cipher-based design by non-experts, would SHOULD NOT be more appropriate than MAY for ENCR_RC4? UI Suites: draft-ietf-ipsec-ui-suites-01.txt Section 2.2, "VPN-B" suite specifies: Pseudo-random function AES-XCBC-MAC-96 [AES-XCBC-MAC] Shouldn't that be AES-XCBC-MAC without the -96 (only for the prf)? The -96 version discards 32 bits at the final step because only 96 bits are sent on the wire, but that's not desirable behavior for a prf, and the full specification of the 128 bit version (including 128 bit test vectors) is in the [AES-XCBC-MAC] draft. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ipsec@lists.tislabs.com Fri Jun 20 17:09:57 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5L09urb009431; Fri, 20 Jun 2003 17:09:57 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA26000 Fri, 20 Jun 2003 19:42:37 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564CDE3@corpmx14.us.dg.com> References: <277DD60FB639D511AC0400B0D068B71E0564CDE3@corpmx14.us.dg.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Fri, 20 Jun 2003 16:48:47 -0700 To: Black_David@emc.com, ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Re: IKEv2 algorithms and UI suites comments Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 6:54 PM -0400 6/20/03, Black_David@emc.com wrote: >Section 4.1.3 > >At the risk of reopening an old topic, given the >absence of a specification for use of RC4 with ESP >and the known risks of stream cipher-based design >by non-experts, would SHOULD NOT be more appropriate >than MAY for ENCR_RC4? Or, better yet, not list it at all? If we can't define precisely how to use it, we shouldn't give it an IANA number at all. If someone later defines it in an RFC, they can get an IANA number then. >UI Suites: draft-ietf-ipsec-ui-suites-01.txt > >Section 2.2, "VPN-B" suite specifies: > >Pseudo-random function AES-XCBC-MAC-96 [AES-XCBC-MAC] > >Shouldn't that be AES-XCBC-MAC without the -96 (only >for the prf)? > >The -96 version discards 32 bits at the final >step because only 96 bits are sent on the wire, but >that's not desirable behavior for a prf, and the full >specification of the 128 bit version (including >128 bit test vectors) is in the [AES-XCBC-MAC] draft. It should actually be to the new PRF-AES-XCBC-128 draft. I'm waiting for the WG chairs to approve the document as a WG document, or to say that we should use 96-bit PRF here. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Fri Jun 20 18:39:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5L1d6rb011870; Fri, 20 Jun 2003 18:39:07 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id VAA26300 Fri, 20 Jun 2003 21:06:04 -0400 (EDT) Date: Fri, 20 Jun 2003 18:12:18 -0700 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Q on Traffic Selector Payload From: Ricky Charlet To: ipsec mailingList Content-Transfer-Encoding: 7bit Message-Id: <6731CEDC-A385-11D7-B51A-00039349B0FC@speakeasy.net> X-Mailer: Apple Mail (2.552) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy, Why are there TS payloads in both IKE_AUTH and CREATE_CHILD_SA? Section 2.9 "Traffic Selector Negotiation" seems to discuss the TS payloads only in the context of CREATE_CHILD_SA. --- Ricky Charlet (formerly with Sonicwall and before that Redcreek) rcharlet@alumni.calpoly.edu 510.324.3163 From owner-ipsec@lists.tislabs.com Sat Jun 21 15:14:52 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5LMEprb098951; Sat, 21 Jun 2003 15:14:52 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA29388 Sat, 21 Jun 2003 17:35:10 -0400 (EDT) Message-Id: <200306212141.h5LLf9u8021992@sandelman.ottawa.on.ca> To: ipsec@lists.tislabs.com cc: "Stephen C. Koehler" Subject: Re: IKEv2 payload #14 In-reply-to: Your message of "Fri, 20 Jun 2003 09:07:49 CDT." <200306201407.h5KE7n828394@yogi> Mime-Version: 1.0 (generated by tm-edit 1.8) Content-Type: text/plain; charset=US-ASCII Date: Sat, 21 Jun 2003 17:41:08 -0400 From: Michael Richardson Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- >>>>> "Stephen" == Stephen C Koehler writes: Stephen> 3. Move any conflicting payload definitions to new numbers Stephen> in IKEv2, but Stephen> don't change the ones that have not changed in structure. Stephen> 4. Make all IKEv2 payloads have numbers distinct from those Stephen> in IKEv1, Stephen> regardless of whether the structure or meaning has changed. Stephen> I would very much like for IKEv2 to use option (3). (4) is Stephen> perhaps overkill, Stephen> but I could be convinced otherwise. #4 has the advantage if there are any semantic differences. Also, it likely has better debugging characteristics... So, I agree - 3 or 4. ] ON HUMILITY: to err is human. To moo, bovine. | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Finger me for keys iQCVAwUBPvTQ8oqHRg3pndX9AQFgNQQA4nC/k7cEjKEFD3I+y9tjiI3o14Lrt6lM QtzZlkGNx65t8kwNGAZYa/6+SahIqQeQoL5pkCRo3woQVrWa9IGTftR9vpg/pZNK xCyixNiUkRqXG59Eqz3Flt39lMsCMazvbnT97eRkkOHO3zoYKAEsHSq4cqIYqFPQ xfKL7WZN/OU= =0fZ+ -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Sat Jun 21 15:34:12 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5LMYBrb099374; Sat, 21 Jun 2003 15:34:11 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA29441 Sat, 21 Jun 2003 18:05:21 -0400 (EDT) From: Radia Perlman - Boston Center for Networking Message-Id: <200306212211.h5LMAws18357@sydney.East.Sun.COM> Date: Sat, 21 Jun 2003 18:11:09 -0400 To: "Ricky Charlet" , "ipsec mailingList" Reply-To: Subject: Re: Q on Traffic Selector Payload X-Mailer: Sun NetMail 2.3 MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The reason they're in IKE_AUTH is because creation of the first child SA is piggybacked on the initial creation of the IKE SA. (so really the IKE-AUTH is doing a CREATE_CHILD_SA simultaneously). Radia "Ricky Charlet" wrote: >Howdy, > > Why are there TS payloads in both IKE_AUTH and CREATE_CHILD_SA? >Section 2.9 "Traffic Selector Negotiation" seems to discuss the TS >payloads only in the context of CREATE_CHILD_SA. > > >--- >Ricky Charlet >(formerly with Sonicwall and before that Redcreek) >rcharlet@alumni.calpoly.edu >510.324.3163 > From owner-ipsec@lists.tislabs.com Sat Jun 21 17:31:09 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5M0V8rb001606; Sat, 21 Jun 2003 17:31:09 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA29762 Sat, 21 Jun 2003 19:56:18 -0400 (EDT) X-Authentication-Warning: shell4.bayarea.net: heard owned process doing -bs Date: Sat, 21 Jun 2003 17:02:34 -0700 (PDT) From: "C. M. Heard" X-Sender: heard@shell4.bayarea.net To: ipsec@lists.tislabs.com cc: "Wijnen, Bert (Bert)" Subject: Re: abandoning ike-monitor-mib, isakmp-di-mon-mib, and monitor-mib? In-Reply-To: <3EEA2CF9.50106@sockeye.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Fri, 13 Jun 2003, John Shriver wrote: > OK, let's try and sort out the MIB issues one decision at a > time. The first thing is to decide if we want to abandon the > original set of MIBs: > > draft-ietf-ipsec-ike-monitor-mib-04.txt, > draft-ietf-ipsec-isakmp-di-mon-mib-05.txt, and > draft-ietf-ipsec-monitor-mib-06.txt [ ... list of problems snipped ... ] > So, given this set of considerable problems, is there anyone who > wants these MIBs to track the IPsec standards going forwards, > and can find resources to update them and implement them? > > If nobody wants to do this, will we take the lack of any dissent > on their death as "consensus" per the "IETF Process"? > > I *NEED* to know this, because there are a number of > TEXTUAL-CONVENTIONS in the doi-tc-mib that were only used by > these three MIBs, and are not used by the IPsec flow MIB, or by > the Policy MIB. Since it looks like the doi-tc-mib will NOT be > maintained by the IANA (no enumerations), the TC's have to be > used in some MIB to progress through the standards process, so > we can't stock up on "spare" TCs for possible future needs. It's been a week, and not even one word has been uttered on the WG mailing list. I'm reminded of the closing words in Barbara Fraser's message of 6 June asking us to get this stuff done: % I feel like we're living in Ground Day with these MIB docs. We % keep living the same thing over and over. Let's please get to % the end :-) I think that the silence very eloquently states that there is no further interest in these MIB modules. In the interest of allowing John to get on with the edits to the doi-tc MIB, will the chairs please make a ruling that these MIB modules are abandoned owing to lack of WG interest? Thanks, Mike Heard From owner-ipsec@lists.tislabs.com Mon Jun 23 06:36:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NDaXrb055103; Mon, 23 Jun 2003 06:36:33 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04641 Mon, 23 Jun 2003 09:02:56 -0400 (EDT) Message-ID: From: "Vohra, Meenakshi" To: "'ipsec@lists.tislabs.com'" Subject: Re: [sfs-dev] Nortel Contivity Client with XAuth (Key-ID) Date: Fri, 20 Jun 2003 20:08:03 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C337A2.54615380" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C337A2.54615380 Content-Type: text/plain; charset="ISO-8859-1" Actually, I am trying to evaluate Nortel Client with our VPN gateway that supports XAuth. Following are the two observations I have seen so far: Firstly, I am seeing that Contivity Client is sending me the authentication method as pre-shared key instead of expected xauth-presharedkey even though I have selected Authentication option as "Username and Password authentication" on Client. How to configure client to make it send xauth-presharedkey as authentication method. Secondly, if I try with the preshared key authentication method in the Aggressive mode message sent by the client, the Gateway's response is not being accepted by Nortel Client even though I took care of the pre-shared key as prf(passphrase, username) as mentioned in this mail and the draft Some non-standard attributes are also being sent by the Client. Does the client expects them back ? Any help would be appreciated Thanks, - Meenakshi -----Original Message----- From: Ken Bantoft [mailto:ken@freeswan.ca] Sent: Friday, June 20, 2003 4:45 AM To: Vohra, Meenakshi Cc: users@lists.freeswan.org; sfs-dev@freeswan.ca Subject: [Users] Re: [sfs-dev] Nortel Contivity Client with XAuth (Key-ID) -----BEGIN PGP SIGNED MESSAGE----- On Thu, 19 Jun 2003, Vohra, Meenakshi wrote: > Hello Everyone, > > I am trying to evaluate the Nortel's Contivity Client evaluation copy with > my gateway. After discovering the user name being sent as hash by Nortel > client which I am able to resolve I am also seeing the client sending > authentication method as pre-shared key. I want to test the client with > XAuth so was wondering if someone could suggest me how to configure > xauth-preshared-key as authentication method on the Nortel Client. So far I > am using Authentication option as Username and password Authentication on > Nortel Client. I don't quite understand what you're trying to do here... but FreeS/WAN doesn't support XAUTH, so if you're trying inter-op, it won't work. - -- Ken Bantoft Super FreeS/WAN Maintainer ken@freeswan.ca http://www.freeswan.ca PGP Key: finger ken@bantoft.org "It is dangerous to be right when the government is wrong." -- Voltaire -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv iQCVAwUBPvLzvFiWUusaxGxpAQGpJAP/dFAWQSKzKj5qgZfQwbwnG7EIQKt9pQkQ 6vnk5lf7uqcVVi0bhuZSS2mAAkHjVMA/6mjrnFZt73Kv8EfhJN3fiXEpoSCmMVNU 9v2/bhqSnHLkz9wqT+Ai0G5LzeRxzveCxKbAB3Jw71gRcbMs62uU0fgKPjqBOogm Ds9fLtY38JE= =vV5e -----END PGP SIGNATURE----- _______________________________________________ Users mailing list Users@lists.freeswan.org http://lists.freeswan.org/mailman/listinfo/users ------_=_NextPart_001_01C337A2.54615380 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Re: [sfs-dev] Nortel Contivity Client with XAuth = (Key-ID)

Actually, I am trying to evaluate Nortel Client with = our VPN gateway that supports XAuth. Following are the two observations = I have seen so far:

Firstly, I am seeing that Contivity Client is sending = me the authentication method as pre-shared key instead of expected = xauth-presharedkey even though I have selected Authentication option as = "Username and Password authentication" on Client. How to = configure client to make it send xauth-presharedkey as authentication = method.

Secondly, if I try with the preshared key = authentication method in the Aggressive mode message sent by the = client, the Gateway's response is not being accepted by Nortel Client = even though I took care of the pre-shared key as prf(passphrase, = username) as mentioned in this mail and the draft <http://www.globecom.net/ietf/draft/draft-mamros-pskeye= xt-00.html>

Some non-standard attributes are also being sent by = the Client. Does the client expects them back ?

Any help would be appreciated
Thanks,
- Meenakshi

-----Original Message-----
From: Ken Bantoft [mailto:ken@freeswan.ca]
Sent: Friday, June 20, 2003 4:45 AM
To: Vohra, Meenakshi
Cc: users@lists.freeswan.org; = sfs-dev@freeswan.ca
Subject: [Users] Re: [sfs-dev] Nortel Contivity = Client with XAuth
(Key-ID)


-----BEGIN PGP SIGNED MESSAGE-----


On Thu, 19 Jun 2003, Vohra, Meenakshi wrote:

> Hello Everyone,
>
> I am trying to evaluate the Nortel's Contivity = Client evaluation copy with
> my gateway. After discovering the user name = being sent as hash by Nortel
> client which I am able to resolve I am also = seeing the client sending
> authentication method as pre-shared key. I want = to test the client with
> XAuth so was wondering if someone could suggest = me how to configure
> xauth-preshared-key as authentication method on = the Nortel Client. So far I
> am using Authentication option as Username and = password Authentication on
> Nortel Client.

I don't quite understand what you're trying to do = here... but FreeS/WAN
doesn't support XAUTH, so if you're trying inter-op, = it won't work.



- --
Ken = Bantoft           = ;     Super FreeS/WAN Maintainer
ken@freeswan.ca        =     http://www.freeswan.ca
          &nb= sp;           &nb= sp;    PGP Key: finger ken@bantoft.org
"It is dangerous to be right when the = government is wrong."
          &nb= sp;             =         -- Voltaire

-----BEGIN PGP SIGNATURE-----
Version: 2.6.3ia
Charset: noconv

iQCVAwUBPvLzvFiWUusaxGxpAQGpJAP/dFAWQSKzKj5qgZfQwbwnG7EIQKt9pQk= Q
6vnk5lf7uqcVVi0bhuZSS2mAAkHjVMA/6mjrnFZt73Kv8EfhJN3fiXEpoSCmMVN= U
9v2/bhqSnHLkz9wqT+Ai0G5LzeRxzveCxKbAB3Jw71gRcbMs62uU0fgKPjqBOog= m
Ds9fLtY38JE=3D
=3DvV5e
-----END PGP SIGNATURE-----

_______________________________________________
Users mailing list
Users@lists.freeswan.org
http://lists.freeswan.org/mailman/listinfo/users

------_=_NextPart_001_01C337A2.54615380-- From owner-ipsec@lists.tislabs.com Mon Jun 23 06:36:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NDahrb055120; Mon, 23 Jun 2003 06:36:43 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA04647 Mon, 23 Jun 2003 09:05:55 -0400 (EDT) To: msec@securemulticast.org, ipsec@lists.tislabs.com Subject: IKE cookies X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: ID = 35367602890184dc30ae33595b56de25 Reply-To: lujesa@excite.com From: "" MIME-Version: 1.0 X-Sender: lujesa@excite.com X-Mailer: PHP Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <20030620184307.441751E44B@xmxpita.excite.com> Date: Fri, 20 Jun 2003 14:43:07 -0400 (EDT) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm doing a cost/benefit study on GSAKMP (group secure association key management protocol). It is expected that GSAKMP will include a cookie just as implemented in IKE, to provide some protection against DOS attacks. Would anyone have a copy of the cookie code implemented in IKE, either in the first or later version? Thanks in advance for any help. Lucia J. GWU Graduate student _______________________________________________ Join Excite! - http://www.excite.com The most personalized portal on the Web! From owner-ipsec@lists.tislabs.com Mon Jun 23 07:16:11 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NEGArb056445; Mon, 23 Jun 2003 07:16:10 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA05021 Mon, 23 Jun 2003 09:52:26 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16119.1857.662910.752695@ryijy.hel.fi.ssh.com> Date: Mon, 23 Jun 2003 16:57:21 +0300 From: Tero Kivinen To: "Stephen C. Koehler" Cc: ipsec@lists.tislabs.com Subject: Re: IKEv2 payload #14 In-Reply-To: <200306201407.h5KE7n828394@yogi> References: <200306192341.h5JNexPj029036@sandelman.ottawa.on.ca> <200306201407.h5KE7n828394@yogi> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 1 min X-Total-Time: 1 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen C. Koehler writes: > 3. Move any conflicting payload definitions to new numbers in IKEv2, but > don't change the ones that have not changed in structure. > 4. Make all IKEv2 payloads have numbers distinct from those in IKEv1, > regardless of whether the structure or meaning has changed. I would say number 3 or 4 are good. Actually I think 4 is better. > I would very much like for IKEv2 to use option (3). (4) is perhaps overkill, > but I could be convinced otherwise. BTW, this is not only about the paylaod number 14, the payload numbers 15, and 16 are used by the draft-ietf-ipsec-nat-t-ike-06.txt for IKEv1 also... -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Jun 23 12:54:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NJssrb077640; Mon, 23 Jun 2003 12:54:54 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00451 Mon, 23 Jun 2003 15:21:15 -0400 (EDT) Message-Id: <200306231921.PAA00447@lists.tislabs.com> X-Mailer: exmh version 2.6.2 03/21/2003 with nmh-1.0.4 To: ipsec@lists.tislabs.com Subject: Re: IKEv2 payload #14 In-Reply-To: Your message of "Mon, 23 Jun 2003 16:57:21 +0300." <16119.1857.662910.752695@ryijy.hel.fi.ssh.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Jun 2003 11:01:46 -0500 From: "Stephen C. Koehler" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We now have a few folks who see this as a problem, and would prefer a renumbering of the IKEv2 payloads. Is there any chance for this suggestion to be considered seriously? I would like to hear a response from those who have the most say about the final spec. Charlie? Paul? (I don't really know who should be included in this list.) This feedback comes from an implementer's perspective. Conflicting payload numbers are causing me a fairly large amount of difficulty combining v1 and v2 code that I would be very happy to have go away. > Stephen C. Koehler writes: > > 3. Move any conflicting payload definitions to new numbers in IKEv2, but > > don't change the ones that have not changed in structure. > > 4. Make all IKEv2 payloads have numbers distinct from those in IKEv1, > > regardless of whether the structure or meaning has changed. > > I would say number 3 or 4 are good. Actually I think 4 is better. > > > I would very much like for IKEv2 to use option (3). (4) is perhaps overkill, > > but I could be convinced otherwise. > > BTW, this is not only about the paylaod number 14, the payload numbers > 15, and 16 are used by the draft-ietf-ipsec-nat-t-ike-06.txt for IKEv1 > also... > -- > kivinen@ssh.fi > SSH Communications Security http://www.ssh.fi/ > SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ -- Steve Koehler koehler@securecomputing.com From owner-ipsec@lists.tislabs.com Mon Jun 23 12:54:56 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NJstrb077645; Mon, 23 Jun 2003 12:54:56 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00329 Mon, 23 Jun 2003 15:10:10 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3EF01165.1040906@nomadiclab.com> References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EEC2C43.9060302@nomadiclab.com> <16112.1673.849180.847121@ryijy.hel.fi.ssh.com> <3EF01165.1040906@nomadiclab.com> Date: Mon, 23 Jun 2003 12:52:52 -0400 To: Pekka Nikander From: Stephen Kent Subject: Re: SEND vs. IPsec AH (was Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt...) Cc: Tero Kivinen , ipsec@lists.tislabs.com, SEND WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:14 AM +0300 6/18/03, Pekka Nikander wrote: >Steve and Tero, > >[Taking my SEND WG chair hat firmly *off*, i.e., speaking for > myself only.] > >Stephen Kent wrote: >>Until SEND has a comprehensive, coherent model for using AH that does >>not require changes to other parts of IPsec processing, ... > >With all respect, I sincerely believe that SEND will never come up >with "a comprehensive, coherent model for using AH that does >not require changes to other parts of IPsec processing". More on that >below. If you disagree, please try to come up with a scheme where >you use AH when you > > - don't have any IP addresses (i.e. during IPv6 DAD) > > - do not know in which network you are (public access) > > - do not trust most nodes in the network (public access) > - and are still trying to figure out what node(s) to trust, > how much, and in which respects > > - do not know which of the potentially many trust roots you > should use to establish trust with the possibly existing > trusted nodes in the otherwise untrusted network > > - want to operate, at a lower level of security, when you > are unable to establish pre-configured trust with anyone > > - want to make this all *effectively*, without using zillions > of messges, since you potentially have to do this each time > you roam to a different IP network I don't disagree that SEND has a number of security constraints with which it must deal. However, AH was not designed to address this set of constraints and thus trying to twist AH to meet the needs of SEND is inappropriate. >I still claim that there are situations where the integrity and >data origin authentication of the IP header is important. >Hence, I firmly believe that the text concerning the relationship >between AH and ESP is misleading at best and perhaps even outright >wrong. Using tunnel mode is not an answer, at least sometimes. The IPsec WG does not seem to share this view, based on previous, extensive discussions. We rarely have circumstances where AH makes more sense than ESP in either tunnel or transport mode. And, there is a strong desire in the WG to simplify the IPsec specs, which runs counter to your suggestion. > >>>- In the current SEND WG proposal, the SA does not indicate the key >>> to be used. Instead, the AH header itself contains the public >>>key. .... >>> >>This is not consistent with the IPsec specs! > >Actually I more or less agree with you, Steve! Indeed, that is >one of the reasons why I am proposing changes to the current AH >usage in SEND, basically moving the public key from the AH header >to a separate extension header, to be placed before the AH header. >(See the separate discussion at the SEND WG ML.) There is NO public key in the AH header. There is a place for an ICV. >>In IPsec, the SAD entry for an SA stores the keys that are employed >>to process packets. In turn, the SAD entry is located by using the >>SPI from an inbound packet (for unicast traffic). > >I am very very well aware of that. I quite well remember what >I learned while I implemented one of the early BITS IPsec stacks >as a part of my PhD work back in 1994-1995. > >However, sometimes the SPI alone is not very useful, and sometimes >using the destination address as a selector is not the right choice. >(More on this on the separate thread.) I don't think this WG has identified a set of contexts in which the current SA selection mechanisms are not sufficient. We made some changes to accommodate MSEc requirements, but it's very late in the process to assert that there needs to be fundamental changes to this mechanism. >>If SEND wants to use AH then you need to use the protocol (including >>the processing spec) as defined in IPsec, not just the syntax from >>2402. Suggesting that we change AH to accommodate SEND's possible use >>of it, in a fashion not consistent with the current specs, is asking >>quite a lot. > >I agree. Actually, using the revised suggestion of moving the >public key from the AH header to a separate extension header, >thereby creating an "implicit" or "inline" one message KMP, >seems to simplify issue. However, even in that case it >would really make sense to perform SA selection based on the >source address. However, I defer that discussion to the other >thread. As noted above, there was NEVER a provision to carry ANY key in the AH header, so this whole thread seem rather odd to me. >Tero Kivinen wrote: >>The SEND is a user of the AH. ... Do we want to say to our >>(only?) user that no we do not allow you to do anything differently? > >As Itojun pointed out (and Steve well knows), SEND is indeed not >the only user of AH. Anyway, thanks for your supporting words. > >We should also remember that RFC2461/2462 explicitly states that >AH is the method to be used for protecting IPv6 ND. That is, in fact, >quite doable if you have a static environment with pre-configured >security associations, PK based or symmetric. However, once you >want to use AH in the public access environment, things get harder. >See the outline above. The RFC numbers cited above obviously refer to specs issued after the IPsec specs were published. I don't think the IPsec WG can be responsible for what other WGs may choose to say about how to use the protocols developed here, but I think it fair to say that maybe someone made an assertion without thinking it through. >>Do we want them to create another protocol replacing their use of AH? > >This is the very question. There are lots of folks at the >SEND WG who believe so. That is, they believe that AH should >not be used for securing IPv6 ND, and a separate protocol should >be developed instead. I'm all in favor of that, if the alternative is to make the sort of changes you suggest to AH, to accommodate SEND requirements. >>Another people who have been saying that they want to use AH is >>Mobile IP people. What do they want? Is the current spec fine with >>them or do the want similar processing than SEND? > >Having been there too (though recently not very actively), I strongly >suspect that some of the MIPv6 requirements will be fairly similar >to those of SEND. Both deal with IP address mappings, MIP with >IP -> IP mappings and ND with IP -> lladdr mappings. We have had interactions with folks about mobile IPv6 and its uses of IPsec. A previous version of the ID was held up in the IESG because it seemed to suggest changes to IPsec that had not been agreed to by this WG. Steve From owner-ipsec@lists.tislabs.com Mon Jun 23 12:55:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NJtsrb077762; Mon, 23 Jun 2003 12:55:54 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00425 Mon, 23 Jun 2003 15:19:23 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16119.5371.22150.897999@ryijy.hel.fi.ssh.com> Date: Mon, 23 Jun 2003 17:55:55 +0300 From: Tero Kivinen To: ipsec@lists.tislabs.com CC: housley@vigilsec.com Subject: Comments to draft-ietf-ipsec-ciph-aes-ctr-04.txt X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 10 min X-Total-Time: 13 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The document draft-ietf-ipsec-ciph-aes-ctr-04 talks about generating keying material in section 5.1, which only is valid to IKEv2 and Phase 1 SA creation. This should be change to apply to both IKEv1 and IKEv2 keying material generation. The current text: ---------------------------------------------------------------------- 5.1. Keying Material and Nonces As described in section 2.1, implementations MUST use fresh keys with AES-CTR. IKE can be used to establish fresh keys. This section describes the conventions for obtaining the unpredictable nonce value from IKE. Note that this convention provides a nonce value that is secret as well as unpredictable. IKE makes use of a pseudo-random function (PRF) to derive keying material. The PRF is used iteratively to derive keying material of arbitrary size. Keying material is extracted from the output string without regard to boundaries. IKE uses the PRF to generate an output stream that parsed into five keys: SK_d, SK_ai, SK_ar, SK_ei, and SK_er. SK_d is used to derive new keys for the child security associations. SK_ai and SK_ar are the authentication keys for the initiator and the responder, respectively. SK_ei and SK_er are the encryption keys for the initiator and the responder, respectively. SK_ai and SK_ei are used to protect traffic from the initiator to the responder. SK_ar and SK_er are used to protect traffic from the responder to the initiator. The size of SK_ei and SK_er are each four octets longer than is needed by the associated AES key. The keying material is used as follows: AES-CTR with a 128 bit key SK_ei and SK_er are each 20 octets. The first 16 octets are the 128-bit AES key, and the remaining four octets are used as the nonce value in the counter block. AES-CTR with a 192 bit key SK_ei and SK_er are each 28 octets. The first 24 octets are the 192-bit AES key, and the remaining four octets are used as the nonce value in the counter block. AES-CTR with a 256 bit key SK_ei and SK_er are each 36 octets. The first 32 octets are the 256-bit AES key, and the remaining four octets are used as the nonce value in the counter block. ---------------------------------------------------------------------- The SK_ai, SK_ar, SK_ei, SK_er are only used in the IKEv2 SA packet encryption and authentication. The IPsec keys are generated from the KEYMAT generated from the SK_d. I.e the IKEv2 draft says: ---------------------------------------------------------------------- For CREATE_CHILD_SA exchanges with PFS the keying material is defined as: KEYMAT = prf+(SK_d, g^ir (new) | Ni | Nr ) ... ---------------------------------------------------------------------- and the IKEv1 RFC 2409 says: ---------------------------------------------------------------------- If PFS is not needed, and KE payloads are not exchanged, the new keying material is defined as KEYMAT = prf(SKEYID_d, protocol | SPI | Ni_b | Nr_b). If PFS is desired and KE payloads were exchanged, the new keying material is defined as KEYMAT = prf(SKEYID_d, g(qm)^xy | protocol | SPI | Ni_b | Nr_b) ... ---------------------------------------------------------------------- They both define how to expand the KEYMAT if needed. So the proposed replacement text is: ---------------------------------------------------------------------- 5.1. Keying Material and Nonces As described in section 2.1, implementations MUST use fresh keys with AES-CTR. IKE can be used to establish fresh keys. This section describes the conventions for obtaining the unpredictable nonce value from IKE. Note that this convention provides a nonce value that is secret as well as unpredictable. IKE makes use of a pseudo-random function (PRF) to derive keying material. The PRF is used iteratively to derive keying material KEYMAT of arbitrary size. Keying material is extracted from the output string without regard to boundaries. The size of KEYMAT requested is four octets longer than is needed by the associated AES key. The keying material is used as follows: AES-CTR with a 128 bit key KEYMAT requested for each AES-CTR key are each 20 octets. The first 16 octets are the 128-bit AES key, and the remaining four octets are used as the nonce value in the counter block. AES-CTR with a 192 bit key KEYMAT requested for each AES-CTR key are each 28 octets. The first 24 octets are the 192-bit AES key, and the remaining four octets are used as the nonce value in the counter block. AES-CTR with a 256 bit key KEYMAT requested for each AES-CTR key are each 36 octets. The first 32 octets are the 256-bit AES key, and the remaining four octets are used as the nonce value in the counter block. ---------------------------------------------------------------------- The wording is like that, because in the IKEv1 the KEYMAT is generated for each SPI separetely, i.e inbound/outbound etc AH/ESP have separete KEYMAT. For the IKEv2 the keying material is generated from one call to the KEYMAT. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Jun 23 12:59:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NJxjrb077994; Mon, 23 Jun 2003 12:59:45 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00498 Mon, 23 Jun 2003 15:29:22 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16119.19925.894893.524696@ryijy.hel.fi.ssh.com> Date: Mon, 23 Jun 2003 21:58:29 +0300 From: Tero Kivinen To: ipsec@lists.tislabs.com Subject: Comments to draft-ietf-ipsec-ikev2-08.txt NAT-traversal X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 10 min X-Total-Time: 39 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The current draft-ietf-ipsec-ikev2-08.txt is still missing some small pieces of the text needed for the NAT-Traversal to work. First the NAT_DETECTION_DESTINATION_IP should specify that if this end is behind a NAT, then this end SHOULD start sending keepalive packets as defined in [Hutt02]. ---------------------------------------------------------------------- NAT_DETECTION_DESTINATION_IP 24583 This notification is used to by its recipient to determine whether it is behind a NAT box. The data associated with this notification is a SHA-1 digest of the SPIs (in the order they appear in the header), IP address and port to which this packet was sent. The recipient of this notification MAY compare the supplied value to a hash of the SPIs, destination IP address and port and if they don't match it SHOULD invoke NAT traversal (see section 2.23). If they don't match, it means that this end is behind a NAT. Alternately, it MAY reject the connection attempt if NAT traversal is not supported. ---------------------------------------------------------------------- => ---------------------------------------------------------------------- ... match it SHOULD invoke NAT traversal (see section 2.23). If they don't match, it means that this end is behind a NAT and this end SHOULD start sending keepalive packets as defined in [Hutt02]. Alternately, it MAY reject the connection attempt if NAT traversal is not supported. ---------------------------------------------------------------------- Also there is some text missing explainging where the nodes, can get the original source and destination addresses (i.e from the traffic selectors). As the traffic selectors are mandatory, they will always contain the original ip address for the connection (i.e wihtout the NAT processing). Those values can the be used in the transport mode NAT-T to do the checksum fixup for the TCP and UDP packets. This text should be added to section 2.23: ---------------------------------------------------------------------- The original source and destination IP address required for the transport mode TCP and UPD packet checksum fixup (see [Hutt02]) is obtained from the Traffic Selectors associated with the exchange. In case of the NAT-T the Traffic Selectors MUST contain exactly one IP address which is then used as original IP address. ---------------------------------------------------------------------- The current draft also does not say anything about the how to recover from the expiring NAT mappings, i.e if the NAT box changes the NAT mapping in the middle of the IKE SA use. For the implicit address update we need following changes: 1) Add paragrap to the NAT_DETECTION_SOURCE_IP notification description about when to enable the implicit addres update: ---------------------------------------------------------------------- If this check fails it means that the other end is behind NAT and this end SHOULD enable the NAT Traversal implicit address updating (see section X.XX). ---------------------------------------------------------------------- 2) Add the section about the implicit address updating (2.24?) ---------------------------------------------------------------------- X.XX NAT Traversal Implicit Address Updating There are cases where NAT box decides to remove mappings that are still alive (for example, the keepalive interval is too long, or the NAT box is rebooted). To recover from those hosts which are NOT behind NAT SHOULD use the last valid authenticated packet from the other end to determine which IP and port addresses should be used. The host behind dynamic NAT MUST NOT do this as otherwise it opens DoS attack possibility, and there is no need for that, because the IP address or port of other host will not change (it is not behind NAT). Keepalives cannot be used for this purposes as they are not authenticated, but any IKE authenticated IKE packet or UDP encapsulated ESP packet can be used to detect that the IP address or the port has changed. ---------------------------------------------------------------------- Note, that those text DO NOT have anything to do with Mobile IP, they are only needed and useful for the NAT-T case. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Jun 23 13:00:12 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NK0Brb078020; Mon, 23 Jun 2003 13:00:11 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00503 Mon, 23 Jun 2003 15:29:27 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16119.17412.231940.346484@ryijy.hel.fi.ssh.com> Date: Mon, 23 Jun 2003 21:16:36 +0300 From: Tero Kivinen To: ipsec@lists.tislabs.com CC: housley@vigilsec.com Subject: Comments to draft-ietf-ipsec-ciph-aes-ccm-03.txt X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 5 min X-Total-Time: 12 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The document draft-ietf-ipsec-ciph-aes-ccm-03 talks about generating keying material in section 5.1, which only is valid to IKEv2 and Phase 1 SA creation. This should be change to apply to both IKEv1 and IKEv2 keying material generation. The current text: ---------------------------------------------------------------------- 7.1. Keying Material and Salt Values As previously described, implementations MUST use fresh keys with AES-CCM. IKE can be used to establish fresh keys. This section describes the conventions for obtaining the unpredictable salt value for use in the nonce from IKE. Note that this convention provides a salt value that is secret as well as unpredictable. IKE makes use of a pseudo-random function (PRF) to derive keying material. The PRF is used iteratively to derive keying material of arbitrary size. Keying material is extracted from the output string without regard to boundaries. IKE uses the PRF to generate an output stream that parsed into five keys: SK_d, SK_ai, SK_ar, SK_ei, and SK_er. SK_d is used to derive new keys for the child security associations. SK_ai and SK_ar are the authentication keys for the initiator and the responder, respectively. SK_ei and SK_er are the encryption keys for the initiator and the responder, respectively. SK_ai and SK_ei are used to protect traffic from the initiator to the responder. SK_ar and SK_er are used to protect traffic from the responder to the initiator. The size of SK_ei and SK_er are each three octets longer than is needed by the associated AES key. The keying material is used as follows: AES-CCM with a 128 bit key SK_ei and SK_er are each 19 octets. The first 16 octets are the 128-bit AES key, and the remaining three octets are used as the salt value in the counter block. AES-CCM with a 192 bit key SK_ei and SK_er are each 27 octets. The first 24 octets are the 192-bit AES key, and the remaining three octets are used as the salt value in the counter block. AES-CCM with a 256 bit key SK_ei and SK_er are each 35 octets. The first 32 octets are the 256-bit AES key, and the remaining three octets are used as the salt value in the counter block. ---------------------------------------------------------------------- In my previous mail about the aes-ctr I already cut & pasted the relevant pieces from the IKEv2 draft and RFC2409, so I do not repeat them here. The proposed replacement text is: ----------------------------------------------------------------------7.1. Keying Material and Salt Values As previously described, implementations MUST use fresh keys with AES-CCM. IKE can be used to establish fresh keys. This section describes the conventions for obtaining the unpredictable salt value for use in the nonce from IKE. Note that this convention provides a salt value that is secret as well as unpredictable. IKE makes use of a pseudo-random function (PRF) to derive keying material. The PRF is used iteratively to derive keying material "KEYMAT" of arbitrary size. Keying material is extracted from the output string without regard to boundaries. The size of KEYMAT needed for each AES-CTR key is each three octets longer than is needed by the associated AES key. The keying material is used as follows: AES-CCM with a 128 bit key KEYMAT requested for each AES-CCM key are each 19 octets. The first 16 octets are the 128-bit AES key, and the remaining three octets are used as the salt value in the counter block. AES-CCM with a 192 bit key KEYMAT requested for each AES-CCM key are each 27 octets. The first 24 octets are the 192-bit AES key, and the remaining three octets are used as the salt value in the counter block. AES-CCM with a 256 bit key KEYMAT requested for each AES-CCM key are each 35 octets. The first 32 octets are the 256-bit AES key, and the remaining three octets are used as the salt value in the counter block. ---------------------------------------------------------------------- Also the draft-ietf-ipsec-ciph-aes-ccm-03.txt is missing section "8. Test Vectors"... -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Jun 23 13:18:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5NKIorb079647; Mon, 23 Jun 2003 13:18:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA00700 Mon, 23 Jun 2003 15:47:55 -0400 (EDT) Message-Id: <200306231943.h5NJhmvo000346@coredump.cs.columbia.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: ipsec@lists.tislabs.com, housley@vigilsec.com Subject: IPsec working group ticket tracker Cc: smb@research.att.com, tytso@mit.edu, byfraser@cisco.com, kivinen@ssh.fi Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 23 Jun 2003 15:43:48 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk It took a bit longer than expected due to technical problems (and extended travel), but here it is: https://roundup.machshav.com/ There are tickets for items in the following documents: 2401bis AHbis ESPbis draft-ietf-ipsec-ciph-aes-ctr draft-ietf-ipsec-ciph-aes-ccm draft-ietf-ipsec-aes-cbc draft-ietf-ipsec-ikev2 draft-ietf-ipsec-ikev2-algorithms draft-ietf-ipsec-algorithms draft-ietf-ipsec-esn-addendum draft-ietf-ipsec-ui-suites Note that I am still updating 2401bis, so the list is not complete there (but will be in the next hour or so). The remaining documents are complete to my knowledge. Priorities and categories were assigned semi-arbitrarily (based on my sense of urgency, importance, and ease of dealing with the issue). -Angelos From owner-ipsec@lists.tislabs.com Tue Jun 24 08:53:00 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OFqxrb073360; Tue, 24 Jun 2003 08:53:00 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04239 Tue, 24 Jun 2003 11:01:12 -0400 (EDT) X-Originating-IP: [24.68.19.178] X-Originating-Email: [askrywan@hotmail.com] From: "Andrew Krywaniuk" To: ipsec@lists.tislabs.com Subject: Re: QoS selectors (was LAST CALL: IKE) Date: Tue, 24 Jun 2003 04:13:31 -0400 Mime-Version: 1.0 Content-Type: text/plain; format=flowed Message-ID: X-OriginalArrivalTime: 24 Jun 2003 08:13:32.0901 (UTC) FILETIME=[80B5D950:01C33A28] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >So it seems like the sender, which knows it wants to send n different >TOSs for which speeds will vary, can open n SAs, and choose which >of the TOSs to send on which of them. I don't see why we would want to do it that way. The problem isn't so much on the initiator side. We negotiate SAs in pairs, so if the initiator sets up 5 SAs, the responder now has to monitor the traffic on the inbound SAs in order to figure out what QoS applies to the outbound SA. This, of course, assumes that we want to match the selectors on the inbound and outbound SAs, which I would prefer. Sure we could do this heuristically, but why would we want to? Andrew -------------------------------------- Lead something-or-other at Fortinet Technologies "Always post from the address that already receives the most spam." -- Sun Tzu _________________________________________________________________ The new MSN 8: advanced junk mail protection and 2 months FREE* http://join.msn.com/?page=features/junkmail From owner-ipsec@lists.tislabs.com Tue Jun 24 09:00:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OG0Hrb073686; Tue, 24 Jun 2003 09:00:17 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA04297 Tue, 24 Jun 2003 11:21:49 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 23 Jun 2003 13:33:49 -0400 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: Re: LAST CALL: IKE Content-Type: multipart/alternative; boundary="============_-1155732864==_ma============" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --============_-1155732864==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" >In anticipation of several proposed changes to RFC 2401, I would >like to suggest a few additional payloads to be added to IKE v2. Paul Hoffman sent me a nice, private note suggesting that I needed to do a much better job of describing, and motivating the changes I suggested. He's absolutely right. And, while I was away on a business trip (after my vacation caused me to miss most of the last call comment period), David Black provided excellent clarification for one of my suggestions. So, let me try again. >Several folks have asked for the ability to place traffic with >different TOS values on different SAs, which requires that the TOS >field (IPv4) and the flow spec field (IPv6) be useable as selectors. >If we agree to add this feature, we need the ability to negootiate >this in IKE. What I meant to say is what David said in his message, i.e.: That would be the 6 bit DS Field, as defined in RFC 2780. The other two bits in the same header octets are used for ECN and should not be used as selectors. There are some subtle issues in QoS specification across administrative domain boundaries - in full generality, the DiffServ Code Point (DSCP) values used in the DS Field do not have global validity or meaning. It's ok to use DSCPs when the values are only expected to be meaningful to one end of the connection (e.g., receiver tells sender to set DSCP to in inner IP header for tunnel mode SA), or something in the middle can be expected to do the translation if necessary - the latter does not apply to IKE for obvious reasons. For more general negotiation, where both ends are expected to understand what is being negotiated, PHBIDs (RFC 3140) are appropriate. At least this covers the IPv4 case. I'm open to suggestions from IPv6 experts about what to do there, for flows. Radia also comment on this issue, but I have to disagree with her a bit; I think it is important to allow the initiator to specify the intent to segregate traffic by the DS field, e.g., to try to get the responder to treat return traffic accordingly. Thinking ahead, we ought to decide if there are other fields we want to specify as selectors, now. For example, we've had discussion on the list about using ICMP message type fields in lieu of port fields, when ICMP was the payload. >A few folks have observed that the current mandate for black side >fragmentation poses DoS vulnerabilities for receivers. Thus we may >choose to allow (or recommend) red side fragmentation. If so, we >need to be able to negotiate use of this capability on a per-SA >basis, and to notify the receiver that NO black fragments should be >accepted, because none will be sent on this SA. My terminology here was sloppy, relative to what we usually use in IPsec. Today, we require an IPsec implementation to fragment a packet after processing, if we increase its size beyond the MTU for the link via which the packet is being transmitted from the IPsec implementation. This creates a problem for a receiver, because an attacker can create what appear to be legitimate, non-initial fragments and cause reassembly problems. If we allowed a sender to fragment a packet prior to IPsec encapsulation, then we could avoid this problem. So, I was suggesting that we add a paylod to IKE to allow an initiator to indicate the intent to perform such fragmentation on an SA, with the ability of the responder to indicate whether this is OK (i.e., it knows how to manage the reassembly after IPsec decapsulation), or not (the status quo). An acceptance by the responder would imply that it could choose to do the same for the companion SA. A logical, but separable, companion to this feature is to allow the initiator to request the responder to accept fragments on an SA where port fields are used as selectors. The issue here is that a host may send fragments to an IPsec device that requires port field examination for the SA to which the fragments will be mapped. It seems reasonably safe to allow fragments (with a suitable., minimum offset) to pass through such as SA, with only the initial fragment having the port fields examined. This is a separate negotiation because the fragments arise from hosts behind the IPsec device, but it is related, because if one fragments at the sending IPsec device, it would be nice to be able to use this feature to allow the receiver to pass on fragments, not reassemble them (in the case of a SG). >As a separate matter, I had requested a few months ago that we allow >IKE peers to negotiate use of groups other than the set defined in >Oakley. I see that there is a provision to negotiate other choices >for P, but not for G. I apologize for not noticing this sooner. I >would like to see the negotiation made more general, so that both >the generator as well as the exponent are values that peers can >negotiate. This is a request to make the IKE parameter space negotiation more flexible. there would be no requirement that a conforming implementation support other groups than the ones defined in the separate IKE algorithms spec. But it would allow user communities to specify other groups for their own use. I thought we agreed on this a while ago, but I didn't check closely enough to realize that the current IKE version allows only the exponent, not the generator, to be specified. My intent had been to allow both to be specified. Steve --============_-1155732864==_ma============ Content-Type: text/html; charset="us-ascii" >In anticipation of several proposed changes to RFC 2401, I would like to suggest a few additional payloads to be added to IKE v2. Paul Hoffman sent me a nice, private note suggesting that I needed to do a much better job of describing, and motivating the changes I suggested. He's absolutely right. And, while I was away on a business trip (after my vacation caused me to miss most of the last call comment period), David Black provided excellent clarification for one of my suggestions. So, let me try again. >Several folks have asked for the ability to place traffic with different TOS values on different SAs, which requires that the TOS field (IPv4) and the flow spec field (IPv6) be useable as selectors. If we agree to add this feature, we need the ability to negootiate this in IKE. What I meant to say is what David said in his message, i.e.: That would be the 6 bit DS Field, as defined in RFC 2780. The other two bits in the same header octets are used for ECN and should not be used as selectors. There are some subtle issues in QoS specification across administrative domain boundaries - in full generality, the DiffServ Code Point (DSCP) values used in the DS Field do not have global validity or meaning. It's ok to use DSCPs when the values are only expected to be meaningful to one end of the connection (e.g., receiver tells sender to set DSCP to in inner IP header for tunnel mode SA), or something in the middle can be expected to do the translation if necessary - the latter does not apply to IKE for obvious reasons. For more general negotiation, where both ends are expected to understand what is being negotiated, PHBIDs (RFC 3140) are appropriate. At least this covers the IPv4 case. I'm open to suggestions from IPv6 experts about what to do there, for flows. Radia also comment on this issue, but I have to disagree with her a bit; I think it is important to allow the initiator to specify the intent to segregate traffic by the DS field, e.g., to try to get the responder to treat return traffic accordingly. Thinking ahead, we ought to decide if there are other fields we want to specify as selectors, now. For example, we've had discussion on the list about using ICMP message type fields in lieu of port fields, when ICMP was the payload. >A few folks have observed that the current mandate for black side fragmentation poses DoS vulnerabilities for receivers. Thus we may choose to allow (or recommend) red side fragmentation. If so, we need to be able to negotiate use of this capability on a per-SA basis, and to notify the receiver that NO black fragments should be accepted, because none will be sent on this SA. My terminology here was sloppy, relative to what we usually use in IPsec. Today, we require an IPsec implementation to fragment a packet after processing, if we increase its size beyond the MTU for the link via which the packet is being transmitted from the IPsec implementation. This creates a problem for a receiver, because an attacker can create what appear to be legitimate, non-initial fragments and cause reassembly problems. If we allowed a sender to fragment a packet prior to IPsec encapsulation, then we could avoid this problem. So, I was suggesting that we add a paylod to IKE to allow an initiator to indicate the intent to perform such fragmentation on an SA, with the ability of the responder to indicate whether this is OK (i.e., it knows how to manage the reassembly after IPsec decapsulation), or not (the status quo). An acceptance by the responder would imply that it could choose to do the same for the companion SA. A logical, but separable, companion to this feature is to allow the initiator to request the responder to accept fragments on an SA where port fields are used as selectors. The issue here is that a host may send fragments to an IPsec device that requires port field examination for the SA to which the fragments will be mapped. It seems reasonably safe to allow fragments (with a suitable., minimum offset) to pass through such as SA, with only the initial fragment having the port fields examined. This is a separate negotiation because the fragments arise from hosts behind the IPsec device, but it is related, because if one fragments at the sending IPsec device, it would be nice to be able to use this feature to allow the receiver to pass on fragments, not reassemble them (in the case of a SG). >As a separate matter, I had requested a few months ago that we allow IKE peers to negotiate use of groups other than the set defined in Oakley. I see that there is a provision to negotiate other choices for P, but not for G. I apologize for not noticing this sooner. I would like to see the negotiation made more general, so that both the generator as well as the exponent are values that peers can negotiate. This is a request to make the IKE parameter space negotiation more flexible. there would be no requirement that a conforming implementation support other groups than the ones defined in the separate IKE algorithms spec. But it would allow user communities to specify other groups for their own use. I thought we agreed on this a while ago, but I didn't check closely enough to realize that the current IKE version allows only the exponent, not the generator, to be specified. My intent had been to allow both to be specified. Steve --============_-1155732864==_ma============-- --=====================_8198508==_.ALT Content-Type: text/html; charset="us-ascii" Approved: Dob.ipsec >From majordomo-owner Mon Jun 23 15:02:08 2003 Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id PAA00256 Mon, 23 Jun 2003 15:01:58 -0400 (EDT) Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h5NHW9D9016259 for ; Mon, 23 Jun 2003 13:32:10 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 23 Jun 2003 13:33:49 -0400 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: Re: LAST CALL: IKE Content-Type: multipart/alternative; boundary="============_-1155732864==_ma============" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) --============_-1155732864==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" >In anticipation of several proposed changes to RFC 2401, I would >like to suggest a few additional payloads to be added to IKE v2. Paul Hoffman sent me a nice, private note suggesting that I needed to do a much better job of describing, and motivating the changes I suggested. He's absolutely right. And, while I was away on a business trip (after my vacation caused me to miss most of the last call comment period), David Black provided excellent clarification for one of my suggestions. So, let me try again. >Several folks have asked for the ability to place traffic with >different TOS values on different SAs, which requires that the TOS >field (IPv4) and the flow spec field (IPv6) be useable as selectors. >If we agree to add this feature, we need the ability to negootiate >this in IKE. What I meant to say is what David said in his message, i.e.: That would be the 6 bit DS Field, as defined in RFC 2780. The other two bits in the same header octets are used for ECN and should not be used as selectors. There are some subtle issues in QoS specification across administrative domain boundaries - in full generality, the DiffServ Code Point (DSCP) values used in the DS Field do not have global validity or meaning. It's ok to use DSCPs when the values are only expected to be meaningful to one end of the connection (e.g., receiver tells sender to set DSCP to in inner IP header for tunnel mode SA), or something in the middle can be expected to do the translation if necessary - the latter does not apply to IKE for obvious reasons. For more general negotiation, where both ends are expected to understand what is being negotiated, PHBIDs (RFC 3140) are appropriate. At least this covers the IPv4 case. I'm open to suggestions from IPv6 experts about what to do there, for flows. Radia also comment on this issue, but I have to disagree with her a bit; I think it is important to allow the initiator to specify the intent to segregate traffic by the DS field, e.g., to try to get the responder to treat return traffic accordingly. Thinking ahead, we ought to decide if there are other fields we want to specify as selectors, now. For example, we've had discussion on the list about using ICMP message type fields in lieu of port fields, when ICMP was the payload. >A few folks have observed that the current mandate for black side >fragmentation poses DoS vulnerabilities for receivers. Thus we may >choose to allow (or recommend) red side fragmentation. If so, we >need to be able to negotiate use of this capability on a per-SA >basis, and to notify the receiver that NO black fragments should be >accepted, because none will be sent on this SA. My terminology here was sloppy, relative to what we usually use in IPsec. Today, we require an IPsec implementation to fragment a packet after processing, if we increase its size beyond the MTU for the link via which the packet is being transmitted from the IPsec implementation. This creates a problem for a receiver, because an attacker can create what appear to be legitimate, non-initial fragments and cause reassembly problems. If we allowed a sender to fragment a packet prior to IPsec encapsulation, then we could avoid this problem. So, I was suggesting that we add a paylod to IKE to allow an initiator to indicate the intent to perform such fragmentation on an SA, with the ability of the responder to indicate whether this is OK (i.e., it knows how to manage the reassembly after IPsec decapsulation), or not (the status quo). An acceptance by the responder would imply that it could choose to do the same for the companion SA. A logical, but separable, companion to this feature is to allow the initiator to request the responder to accept fragments on an SA where port fields are used as selectors. The issue here is that a host may send fragments to an IPsec device that requires port field examination for the SA to which the fragments will be mapped. It seems reasonably safe to allow fragments (with a suitable., minimum offset) to pass through such as SA, with only the initial fragment having the port fields examined. This is a separate negotiation because the fragments arise from hosts behind the IPsec device, but it is related, because if one fragments at the sending IPsec device, it would be nice to be able to use this feature to allow the receiver to pass on fragments, not reassemble them (in the case of a SG). >As a separate matter, I had requested a few months ago that we allow >IKE peers to negotiate use of groups other than the set defined in >Oakley. I see that there is a provision to negotiate other choices >for P, but not for G. I apologize for not noticing this sooner. I >would like to see the negotiation made more general, so that both >the generator as well as the exponent are values that peers can >negotiate. This is a request to make the IKE parameter space negotiation more flexible. there would be no requirement that a conforming implementation support other groups than the ones defined in the separate IKE algorithms spec. But it would allow user communities to specify other groups for their own use. I thought we agreed on this a while ago, but I didn't check closely enough to realize that the current IKE version allows only the exponent, not the generator, to be specified. My intent had been to allow both to be specified. Steve --============_-1155732864==_ma============ Content-Type: text/html; charset="us-ascii" >In anticipation of several proposed changes to RFC 2401, I would like to suggest a few additional payloads to be added to IKE v2. Paul Hoffman sent me a nice, private note suggesting that I needed to do a much better job of describing, and motivating the changes I suggested. He's absolutely right. And, while I was away on a business trip (after my vacation caused me to miss most of the last call comment period), David Black provided excellent clarification for one of my suggestions. So, let me try again. >Several folks have asked for the ability to place traffic with different TOS values on different SAs, which requires that the TOS field (IPv4) and the flow spec field (IPv6) be useable as selectors. If we agree to add this feature, we need the ability to negootiate this in IKE. What I meant to say is what David said in his message, i.e.: That would be the 6 bit DS Field, as defined in RFC 2780. The other two bits in the same header octets are used for ECN and should not be used as selectors. There are some subtle issues in QoS specification across administrative domain boundaries - in full generality, the DiffServ Code Point (DSCP) values used in the DS Field do not have global validity or meaning. It's ok to use DSCPs when the values are only expected to be meaningful to one end of the connection (e.g., receiver tells sender to set DSCP to in inner IP header for tunnel mode SA), or something in the middle can be expected to do the translation if necessary - the latter does not apply to IKE for obvious reasons. For more general negotiation, where both ends are expected to understand what is being negotiated, PHBIDs (RFC 3140) are appropriate. At least this covers the IPv4 case. I'm open to suggestions from IPv6 experts about what to do there, for flows. Radia also comment on this issue, but I have to disagree with her a bit; I think it is important to allow the initiator to specify the intent to segregate traffic by the DS field, e.g., to try to get the responder to treat return traffic accordingly. Thinking ahead, we ought to decide if there are other fields we want to specify as selectors, now. For example, we've had discussion on the list about using ICMP message type fields in lieu of port fields, when ICMP was the payload. >A few folks have observed that the current mandate for black side fragmentation poses DoS vulnerabilities for receivers. Thus we may choose to allow (or recommend) red side fragmentation. If so, we need to be able to negotiate use of this capability on a per-SA basis, and to notify the receiver that NO black fragments should be accepted, because none will be sent on this SA. My terminology here was sloppy, relative to what we usually use in IPsec. Today, we require an IPsec implementation to fragment a packet after processing, if we increase its size beyond the MTU for the link via which the packet is being transmitted from the IPsec implementation. This creates a problem for a receiver, because an attacker can create what appear to be legitimate, non-initial fragments and cause reassembly problems. If we allowed a sender to fragment a packet prior to IPsec encapsulation, then we could avoid this problem. So, I was suggesting that we add a paylod to IKE to allow an initiator to indicate the intent to perform such fragmentation on an SA, with the ability of the responder to indicate whether this is OK (i.e., it knows how to manage the reassembly after IPsec decapsulation), or not (the status quo). An acceptance by the responder would imply that it could choose to do the same for the companion SA. A logical, but separable, companion to this feature is to allow the initiator to request the responder to accept fragments on an SA where port fields are used as selectors. The issue here is that a host may send fragments to an IPsec device that requires port field examination for the SA to which the fragments will be mapped. It seems reasonably safe to allow fragments (with a suitable., minimum offset) to pass through such as SA, with only the initial fragment having the port fields examined. This is a separate negotiation because the fragments arise from hosts behind the IPsec device, but it is related, because if one fragments at the sending IPsec device, it would be nice to be able to use this feature to allow the receiver to pass on fragments, not reassemble them (in the case of a SG). >As a separate matter, I had requested a few months ago that we allow IKE peers to negotiate use of groups other than the set defined in Oakley. I see that there is a provision to negotiate other choices for P, but not for G. I apologize for not noticing this sooner. I would like to see the negotiation made more general, so that both the generator as well as the exponent are values that peers can negotiate. This is a request to make the IKE parameter space negotiation more flexible. there would be no requirement that a conforming implementation support other groups than the ones defined in the separate IKE algorithms spec. But it would allow user communities to specify other groups for their own use. I thought we agreed on this a while ago, but I didn't check closely enough to realize that the current IKE version allows only the exponent, not the generator, to be specified. My intent had been to allow both to be specified. Steve --============_-1155732864==_ma============-- --=====================_8198508==_.ALT-- --=====================_3145122==_.ALT Content-Type: text/html; charset="us-ascii" Approved: Dob.ipsec >From majordomo-owner Mon Jun 23 15:02:08 2003 Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id PAA00256 Mon, 23 Jun 2003 15:01:58 -0400 (EDT) Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h5NHW9D9016259 for ; Mon, 23 Jun 2003 13:32:10 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 23 Jun 2003 13:33:49 -0400 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: Re: LAST CALL: IKE Content-Type: multipart/alternative; boundary="============_-1155732864==_ma============" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) --============_-1155732864==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" >In anticipation of several proposed changes to RFC 2401, I would >like to suggest a few additional payloads to be added to IKE v2. Paul Hoffman sent me a nice, private note suggesting that I needed to do a much better job of describing, and motivating the changes I suggested. He's absolutely right. And, while I was away on a business trip (after my vacation caused me to miss most of the last call comment period), David Black provided excellent clarification for one of my suggestions. So, let me try again. >Several folks have asked for the ability to place traffic with >different TOS values on different SAs, which requires that the TOS >field (IPv4) and the flow spec field (IPv6) be useable as selectors. >If we agree to add this feature, we need the ability to negootiate >this in IKE. What I meant to say is what David said in his message, i.e.: That would be the 6 bit DS Field, as defined in RFC 2780. The other two bits in the same header octets are used for ECN and should not be used as selectors. There are some subtle issues in QoS specification across administrative domain boundaries - in full generality, the DiffServ Code Point (DSCP) values used in the DS Field do not have global validity or meaning. It's ok to use DSCPs when the values are only expected to be meaningful to one end of the connection (e.g., receiver tells sender to set DSCP to in inner IP header for tunnel mode SA), or something in the middle can be expected to do the translation if necessary - the latter does not apply to IKE for obvious reasons. For more general negotiation, where both ends are expected to understand what is being negotiated, PHBIDs (RFC 3140) are appropriate. At least this covers the IPv4 case. I'm open to suggestions from IPv6 experts about what to do there, for flows. Radia also comment on this issue, but I have to disagree with her a bit; I think it is important to allow the initiator to specify the intent to segregate traffic by the DS field, e.g., to try to get the responder to treat return traffic accordingly. Thinking ahead, we ought to decide if there are other fields we want to specify as selectors, now. For example, we've had discussion on the list about using ICMP message type fields in lieu of port fields, when ICMP was the payload. >A few folks have observed that the current mandate for black side >fragmentation poses DoS vulnerabilities for receivers. Thus we may >choose to allow (or recommend) red side fragmentation. If so, we >need to be able to negotiate use of this capability on a per-SA >basis, and to notify the receiver that NO black fragments should be >accepted, because none will be sent on this SA. My terminology here was sloppy, relative to what we usually use in IPsec. Today, we require an IPsec implementation to fragment a packet after processing, if we increase its size beyond the MTU for the link via which the packet is being transmitted from the IPsec implementation. This creates a problem for a receiver, because an attacker can create what appear to be legitimate, non-initial fragments and cause reassembly problems. If we allowed a sender to fragment a packet prior to IPsec encapsulation, then we could avoid this problem. So, I was suggesting that we add a paylod to IKE to allow an initiator to indicate the intent to perform such fragmentation on an SA, with the ability of the responder to indicate whether this is OK (i.e., it knows how to manage the reassembly after IPsec decapsulation), or not (the status quo). An acceptance by the responder would imply that it could choose to do the same for the companion SA. A logical, but separable, companion to this feature is to allow the initiator to request the responder to accept fragments on an SA where port fields are used as selectors. The issue here is that a host may send fragments to an IPsec device that requires port field examination for the SA to which the fragments will be mapped. It seems reasonably safe to allow fragments (with a suitable., minimum offset) to pass through such as SA, with only the initial fragment having the port fields examined. This is a separate negotiation because the fragments arise from hosts behind the IPsec device, but it is related, because if one fragments at the sending IPsec device, it would be nice to be able to use this feature to allow the receiver to pass on fragments, not reassemble them (in the case of a SG). >As a separate matter, I had requested a few months ago that we allow >IKE peers to negotiate use of groups other than the set defined in >Oakley. I see that there is a provision to negotiate other choices >for P, but not for G. I apologize for not noticing this sooner. I >would like to see the negotiation made more general, so that both >the generator as well as the exponent are values that peers can >negotiate. This is a request to make the IKE parameter space negotiation more flexible. there would be no requirement that a conforming implementation support other groups than the ones defined in the separate IKE algorithms spec. But it would allow user communities to specify other groups for their own use. I thought we agreed on this a while ago, but I didn't check closely enough to realize that the current IKE version allows only the exponent, not the generator, to be specified. My intent had been to allow both to be specified. Steve --============_-1155732864==_ma============ Content-Type: text/html; charset="us-ascii" >In anticipation of several proposed changes to RFC 2401, I would like to suggest a few additional payloads to be added to IKE v2. Paul Hoffman sent me a nice, private note suggesting that I needed to do a much better job of describing, and motivating the changes I suggested. He's absolutely right. And, while I was away on a business trip (after my vacation caused me to miss most of the last call comment period), David Black provided excellent clarification for one of my suggestions. So, let me try again. >Several folks have asked for the ability to place traffic with different TOS values on different SAs, which requires that the TOS field (IPv4) and the flow spec field (IPv6) be useable as selectors. If we agree to add this feature, we need the ability to negootiate this in IKE. What I meant to say is what David said in his message, i.e.: That would be the 6 bit DS Field, as defined in RFC 2780. The other two bits in the same header octets are used for ECN and should not be used as selectors. There are some subtle issues in QoS specification across administrative domain boundaries - in full generality, the DiffServ Code Point (DSCP) values used in the DS Field do not have global validity or meaning. It's ok to use DSCPs when the values are only expected to be meaningful to one end of the connection (e.g., receiver tells sender to set DSCP to in inner IP header for tunnel mode SA), or something in the middle can be expected to do the translation if necessary - the latter does not apply to IKE for obvious reasons. For more general negotiation, where both ends are expected to understand what is being negotiated, PHBIDs (RFC 3140) are appropriate. At least this covers the IPv4 case. I'm open to suggestions from IPv6 experts about what to do there, for flows. Radia also comment on this issue, but I have to disagree with her a bit; I think it is important to allow the initiator to specify the intent to segregate traffic by the DS field, e.g., to try to get the responder to treat return traffic accordingly. Thinking ahead, we ought to decide if there are other fields we want to specify as selectors, now. For example, we've had discussion on the list about using ICMP message type fields in lieu of port fields, when ICMP was the payload. >A few folks have observed that the current mandate for black side fragmentation poses DoS vulnerabilities for receivers. Thus we may choose to allow (or recommend) red side fragmentation. If so, we need to be able to negotiate use of this capability on a per-SA basis, and to notify the receiver that NO black fragments should be accepted, because none will be sent on this SA. My terminology here was sloppy, relative to what we usually use in IPsec. Today, we require an IPsec implementation to fragment a packet after processing, if we increase its size beyond the MTU for the link via which the packet is being transmitted from the IPsec implementation. This creates a problem for a receiver, because an attacker can create what appear to be legitimate, non-initial fragments and cause reassembly problems. If we allowed a sender to fragment a packet prior to IPsec encapsulation, then we could avoid this problem. So, I was suggesting that we add a paylod to IKE to allow an initiator to indicate the intent to perform such fragmentation on an SA, with the ability of the responder to indicate whether this is OK (i.e., it knows how to manage the reassembly after IPsec decapsulation), or not (the status quo). An acceptance by the responder would imply that it could choose to do the same for the companion SA. A logical, but separable, companion to this feature is to allow the initiator to request the responder to accept fragments on an SA where port fields are used as selectors. The issue here is that a host may send fragments to an IPsec device that requires port field examination for the SA to which the fragments will be mapped. It seems reasonably safe to allow fragments (with a suitable., minimum offset) to pass through such as SA, with only the initial fragment having the port fields examined. This is a separate negotiation because the fragments arise from hosts behind the IPsec device, but it is related, because if one fragments at the sending IPsec device, it would be nice to be able to use this feature to allow the receiver to pass on fragments, not reassemble them (in the case of a SG). >As a separate matter, I had requested a few months ago that we allow IKE peers to negotiate use of groups other than the set defined in Oakley. I see that there is a provision to negotiate other choices for P, but not for G. I apologize for not noticing this sooner. I would like to see the negotiation made more general, so that both the generator as well as the exponent are values that peers can negotiate. This is a request to make the IKE parameter space negotiation more flexible. there would be no requirement that a conforming implementation support other groups than the ones defined in the separate IKE algorithms spec. But it would allow user communities to specify other groups for their own use. I thought we agreed on this a while ago, but I didn't check closely enough to realize that the current IKE version allows only the exponent, not the generator, to be specified. My intent had been to allow both to be specified. Steve --============_-1155732864==_ma============-- --=====================_8198508==_.ALT Content-Type: text/html; charset="us-ascii" Approved: Dob.ipsec >From majordomo-owner Mon Jun 23 15:02:08 2003 Received: from aragorn.bbn.com (aragorn.bbn.com [128.33.0.62]) by lists.tislabs.com (8.9.1/8.9.1) with ESMTP id PAA00256 Mon, 23 Jun 2003 15:01:58 -0400 (EDT) Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h5NHW9D9016259 for ; Mon, 23 Jun 2003 13:32:10 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Mon, 23 Jun 2003 13:33:49 -0400 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: Re: LAST CALL: IKE Content-Type: multipart/alternative; boundary="============_-1155732864==_ma============" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) --============_-1155732864==_ma============ Content-Type: text/plain; charset="us-ascii" ; format="flowed" >In anticipation of several proposed changes to RFC 2401, I would >like to suggest a few additional payloads to be added to IKE v2. Paul Hoffman sent me a nice, private note suggesting that I needed to do a much better job of describing, and motivating the changes I suggested. He's absolutely right. And, while I was away on a business trip (after my vacation caused me to miss most of the last call comment period), David Black provided excellent clarification for one of my suggestions. So, let me try again. >Several folks have asked for the ability to place traffic with >different TOS values on different SAs, which requires that the TOS >field (IPv4) and the flow spec field (IPv6) be useable as selectors. >If we agree to add this feature, we need the ability to negootiate >this in IKE. What I meant to say is what David said in his message, i.e.: That would be the 6 bit DS Field, as defined in RFC 2780. The other two bits in the same header octets are used for ECN and should not be used as selectors. There are some subtle issues in QoS specification across administrative domain boundaries - in full generality, the DiffServ Code Point (DSCP) values used in the DS Field do not have global validity or meaning. It's ok to use DSCPs when the values are only expected to be meaningful to one end of the connection (e.g., receiver tells sender to set DSCP to in inner IP header for tunnel mode SA), or something in the middle can be expected to do the translation if necessary - the latter does not apply to IKE for obvious reasons. For more general negotiation, where both ends are expected to understand what is being negotiated, PHBIDs (RFC 3140) are appropriate. At least this covers the IPv4 case. I'm open to suggestions from IPv6 experts about what to do there, for flows. Radia also comment on this issue, but I have to disagree with her a bit; I think it is important to allow the initiator to specify the intent to segregate traffic by the DS field, e.g., to try to get the responder to treat return traffic accordingly. Thinking ahead, we ought to decide if there are other fields we want to specify as selectors, now. For example, we've had discussion on the list about using ICMP message type fields in lieu of port fields, when ICMP was the payload. >A few folks have observed that the current mandate for black side >fragmentation poses DoS vulnerabilities for receivers. Thus we may >choose to allow (or recommend) red side fragmentation. If so, we >need to be able to negotiate use of this capability on a per-SA >basis, and to notify the receiver that NO black fragments should be >accepted, because none will be sent on this SA. My terminology here was sloppy, relative to what we usually use in IPsec. Today, we require an IPsec implementation to fragment a packet after processing, if we increase its size beyond the MTU for the link via which the packet is being transmitted from the IPsec implementation. This creates a problem for a receiver, because an attacker can create what appear to be legitimate, non-initial fragments and cause reassembly problems. If we allowed a sender to fragment a packet prior to IPsec encapsulation, then we could avoid this problem. So, I was suggesting that we add a paylod to IKE to allow an initiator to indicate the intent to perform such fragmentation on an SA, with the ability of the responder to indicate whether this is OK (i.e., it knows how to manage the reassembly after IPsec decapsulation), or not (the status quo). An acceptance by the responder would imply that it could choose to do the same for the companion SA. A logical, but separable, companion to this feature is to allow the initiator to request the responder to accept fragments on an SA where port fields are used as selectors. The issue here is that a host may send fragments to an IPsec device that requires port field examination for the SA to which the fragments will be mapped. It seems reasonably safe to allow fragments (with a suitable., minimum offset) to pass through such as SA, with only the initial fragment having the port fields examined. This is a separate negotiation because the fragments arise from hosts behind the IPsec device, but it is related, because if one fragments at the sending IPsec device, it would be nice to be able to use this feature to allow the receiver to pass on fragments, not reassemble them (in the case of a SG). >As a separate matter, I had requested a few months ago that we allow >IKE peers to negotiate use of groups other than the set defined in >Oakley. I see that there is a provision to negotiate other choices >for P, but not for G. I apologize for not noticing this sooner. I >would like to see the negotiation made more general, so that both >the generator as well as the exponent are values that peers can >negotiate. This is a request to make the IKE parameter space negotiation more flexible. there would be no requirement that a conforming implementation support other groups than the ones defined in the separate IKE algorithms spec. But it would allow user communities to specify other groups for their own use. I thought we agreed on this a while ago, but I didn't check closely enough to realize that the current IKE version allows only the exponent, not the generator, to be specified. My intent had been to allow both to be specified. Steve --============_-1155732864==_ma============ Content-Type: text/html; charset="us-ascii" >In anticipation of several proposed changes to RFC 2401, I would like to suggest a few additional payloads to be added to IKE v2. Paul Hoffman sent me a nice, private note suggesting that I needed to do a much better job of describing, and motivating the changes I suggested. He's absolutely right. And, while I was away on a business trip (after my vacation caused me to miss most of the last call comment period), David Black provided excellent clarification for one of my suggestions. So, let me try again. >Several folks have asked for the ability to place traffic with different TOS values on different SAs, which requires that the TOS field (IPv4) and the flow spec field (IPv6) be useable as selectors. If we agree to add this feature, we need the ability to negootiate this in IKE. What I meant to say is what David said in his message, i.e.: That would be the 6 bit DS Field, as defined in RFC 2780. The other two bits in the same header octets are used for ECN and should not be used as selectors. There are some subtle issues in QoS specification across administrative domain boundaries - in full generality, the DiffServ Code Point (DSCP) values used in the DS Field do not have global validity or meaning. It's ok to use DSCPs when the values are only expected to be meaningful to one end of the connection (e.g., receiver tells sender to set DSCP to in inner IP header for tunnel mode SA), or something in the middle can be expected to do the translation if necessary - the latter does not apply to IKE for obvious reasons. For more general negotiation, where both ends are expected to understand what is being negotiated, PHBIDs (RFC 3140) are appropriate. At least this covers the IPv4 case. I'm open to suggestions from IPv6 experts about what to do there, for flows. Radia also comment on this issue, but I have to disagree with her a bit; I think it is important to allow the initiator to specify the intent to segregate traffic by the DS field, e.g., to try to get the responder to treat return traffic accordingly. Thinking ahead, we ought to decide if there are other fields we want to specify as selectors, now. For example, we've had discussion on the list about using ICMP message type fields in lieu of port fields, when ICMP was the payload. >A few folks have observed that the current mandate for black side fragmentation poses DoS vulnerabilities for receivers. Thus we may choose to allow (or recommend) red side fragmentation. If so, we need to be able to negotiate use of this capability on a per-SA basis, and to notify the receiver that NO black fragments should be accepted, because none will be sent on this SA. My terminology here was sloppy, relative to what we usually use in IPsec. Today, we require an IPsec implementation to fragment a packet after processing, if we increase its size beyond the MTU for the link via which the packet is being transmitted from the IPsec implementation. This creates a problem for a receiver, because an attacker can create what appear to be legitimate, non-initial fragments and cause reassembly problems. If we allowed a sender to fragment a packet prior to IPsec encapsulation, then we could avoid this problem. So, I was suggesting that we add a paylod to IKE to allow an initiator to indicate the intent to perform such fragmentation on an SA, with the ability of the responder to indicate whether this is OK (i.e., it knows how to manage the reassembly after IPsec decapsulation), or not (the status quo). An acceptance by the responder would imply that it could choose to do the same for the companion SA. A logical, but separable, companion to this feature is to allow the initiator to request the responder to accept fragments on an SA where port fields are used as selectors. The issue here is that a host may send fragments to an IPsec device that requires port field examination for the SA to which the fragments will be mapped. It seems reasonably safe to allow fragments (with a suitable., minimum offset) to pass through such as SA, with only the initial fragment having the port fields examined. This is a separate negotiation because the fragments arise from hosts behind the IPsec device, but it is related, because if one fragments at the sending IPsec device, it would be nice to be able to use this feature to allow the receiver to pass on fragments, not reassemble them (in the case of a SG). >As a separate matter, I had requested a few months ago that we allow IKE peers to negotiate use of groups other than the set defined in Oakley. I see that there is a provision to negotiate other choices for P, but not for G. I apologize for not noticing this sooner. I would like to see the negotiation made more general, so that both the generator as well as the exponent are values that peers can negotiate. This is a request to make the IKE parameter space negotiation more flexible. there would be no requirement that a conforming implementation support other groups than the ones defined in the separate IKE algorithms spec. But it would allow user communities to specify other groups for their own use. I thought we agreed on this a while ago, but I didn't check closely enough to realize that the current IKE version allows only the exponent, not the generator, to be specified. My intent had been to allow both to be specified. Steve --============_-1155732864==_ma============-- --=====================_8198508==_.ALT-- --=====================_3145122==_.ALT-- From owner-ipsec@lists.tislabs.com Tue Jun 24 10:41:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OHf6rb081950; Tue, 24 Jun 2003 10:41:07 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04864 Tue, 24 Jun 2003 13:06:28 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16120.34361.478936.810170@ryijy.hel.fi.ssh.com> Date: Tue, 24 Jun 2003 20:11:21 +0300 From: Tero Kivinen To: Stephen Kent Cc: ipsec@lists.tislabs.com Subject: Re: LAST CALL: IKE In-Reply-To: References: X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 15 min X-Total-Time: 21 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > >As a separate matter, I had requested a few months ago that we allow > >IKE peers to negotiate use of groups other than the set defined in > >Oakley. I see that there is a provision to negotiate other choices > >for P, but not for G. I apologize for not noticing this sooner. I > >would like to see the negotiation made more general, so that both > >the generator as well as the exponent are values that peers can > >negotiate. > > This is a request to make the IKE parameter space negotiation more > flexible. there would be no requirement that a conforming > implementation support other groups than the ones defined in the > separate IKE algorithms spec. But it would allow user communities to > specify other groups for their own use. I thought we agreed on this a > while ago, but I didn't check closely enough to realize that the > current IKE version allows only the exponent, not the generator, to > be specified. My intent had been to allow both to be specified. This is one of the features of the IKEv1 that I would really like to be removed from IKEv2. The problem with private diffie-hellman groups is that you do now know how the group was generated, and is it safe. If you try to do online checks for the groups it takes time and adds more code to the ipsec, causing more bugs. I do know this, as I did implement that feature in the IKEv1. We do have 16-bit number for groups. We do have private use space for groups to be used. I suggest we remove the options to negotiate any group parameters inside the IKE, and say that if you want to use other groups, you either 1) write a document describing the groups, and allocate proper number for them from IANA. or 2) Define the group parameters in both ends and take number from private use space and use that ine IKE. In that case the adminstrator can do all verifications it wants when allowing the group to be used. If someone really wants to have new groups to be automatically generated every day and use them in the IKE, they can defined their own protocol how to move those group descriptions from one IKE peer to the other, before starting the use them in IKE (i.e http-post of signed group description config file :-) Ups, the transform ID field is now only 8-bits, thus we can only have 255 different groups, but there is 16-bits of RESERVED before that, thus we could very easily extend it to the 24-bit number, thus having definately enough different groups... So, my suggestion is to: 1) modify the Transform ID field to be 16-bits. 2) Remove Transform type 4 (Diffie-Hellman Group) Transform ID numbers 201-203, and the text describing anything about them. 3) Fix the text in the 3.3.5 saying that only thing that use attributes are when we define our own Diffie-Hellman groups, to say that only thing that actually uses the attributes are the ciphers having different key lengths (i.e AES). 4) Remove all "Group *" attribute types, and also the Field Size attribute type. 5) Remove text in the 3.3.6 Attribute Negotiation about the defining the groups on the fly. 6) Extend the DH Group # in the Key exchange payload to be 16 or 24 bites as the Transform ID also is made bigger. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Jun 24 10:42:08 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OHg8rb082125; Tue, 24 Jun 2003 10:42:08 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04852 Tue, 24 Jun 2003 13:05:38 -0400 (EDT) From: "Jesse Alpert" To: Cc: "'Tero Kivinen'" Subject: Question about draft-ietf-ipsec-nat-t-ike-06.txt. Date: Tue, 24 Jun 2003 20:12:28 +0300 Message-ID: <004201c33a73$cae8a480$7b2e1dc2@jesse> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, In section 3.2 of the nat-t draft (version 06) it says: "If the sender of the packet does not know his own IP address ... he can include multiple ..." But in section 5.2. - Sending the original source and destination addresses, there is no discussion about this problem. Question: If the sender of the packet does not know his own IP address what address is he supposed to put in his NAT-OA payload? What am I missing? Thanks, Jesse From owner-ipsec@lists.tislabs.com Tue Jun 24 10:44:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OHiLrb082277; Tue, 24 Jun 2003 10:44:21 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04883 Tue, 24 Jun 2003 13:11:43 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16120.34684.788047.259680@ryijy.hel.fi.ssh.com> Date: Tue, 24 Jun 2003 20:16:44 +0300 From: Tero Kivinen To: ipsec@lists.tislabs.com Subject: Still more comments to the draft-ietf-ipsec-ikev2-08.txt X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 2 min X-Total-Time: 4 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I think we should remove the Appendix B.5, as the group is already defined in the [ADDGROUP]. I.e change the section 3.3.2 Transform Substructure: ---------------------------------------------------------------------- For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs are: Name Number NONE 0 Defined in Appendix B 1 - 5 Defined in [ADDGROUP] 14 - 18 ... ---------------------------------------------------------------------- To: ---------------------------------------------------------------------- For Transform Type 4 (Diffie-Hellman Group), defined Transform IDs are: Name Number NONE 0 Defined in Appendix B 1 - 4 Defined in [ADDGROUP] 5, 14 - 18 ... ---------------------------------------------------------------------- and remove the section B.5 Group 5. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Jun 24 11:00:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OI0Erb083549; Tue, 24 Jun 2003 11:00:14 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04980 Tue, 24 Jun 2003 13:25:34 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16120.35513.332017.12389@ryijy.hel.fi.ssh.com> Date: Tue, 24 Jun 2003 20:30:33 +0300 From: Tero Kivinen To: ipsec@lists.tislabs.com Subject: Key length attribute and draft-ietf-ipsec-ikev2-08.txt X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 8 min X-Total-Time: 13 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk The IANA registry has allocated number 12 for the draft-ietf-ipsec-ciph-aes-cbc draft, and that is using the key length attribute to distinguish the 128, 192, and 256 bit keys. The current IKEv2 draft only defines the number 12 to be ENCR_AES_128_CBC. I.e it seems to be saying that no key length attribute is used and the that AES is always 128 bits. This is not consistent with the use defined in the draft-ietf-ipsec-ciph-aes-cbc. I suggest that we use the AES same way, i.e use the key length attribute to actually set the key length and rename the ENCR_AES_128_CBC to ENCR_AES_CBC. The draft-ietf-ipsec-ciph-aes-cbc is in the rfc editor queue, so we cannot change that anymore... All the other numbers except those with AES in the section 3.3.2 Transform Substructure Transform type 1 (encryption algorithms) table match the current IANA registry. I do not see any point to make it mostly similar but still different especially when the draft-ietf-ipsec-ciph-aes-cbc should be easily usable for both IKEv1 and IKEv2. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Tue Jun 24 11:37:38 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OIbcrb085061; Tue, 24 Jun 2003 11:37:38 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05253 Tue, 24 Jun 2003 14:02:39 -0400 (EDT) Message-ID: <422D14738F68944389E0217727D2BDCD070746@AAKASH.infrasofttech.biz> From: "narasimha.reddy" To: "'ipsec@lists.tislabs.com'" Cc: "narasimha.reddy" Subject: IP in Sun Solaris Date: Tue, 24 Jun 2003 23:07:26 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33A77.4724D020" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C33A77.4724D020 Content-Type: text/plain Hi All, Please bare my simple query about IP security. I am running one process on the port number 9876 in Sun Solaris. Here I want to allow the connections from remote machines. Can I allow only certain certain remote client IPs to my 9876 port number... Is it possible in Sun Solaris? If so , it will be great if you can guide of how to do go about this ? any documents on this will be appreciated.. Since I am not member of this list, Please send replies to my mailID 'narasimha.reddy@infrasofttech.biz' only.. Thanks.. Regards Narasimha reddy.V ------_=_NextPart_001_01C33A77.4724D020 Content-Type: text/html Content-Transfer-Encoding: quoted-printable IP in Sun Solaris Hi All, Please bare my simple query about IP security. = I am running one process on the port number 9876 in = Sun Solaris. Here I want to allow the connections from remote = machines. Can I allow only certain certain remote client IPs to = my 9876 port number... Is it possible in Sun Solaris? If so , it will be great if you can guide of how to = do go about this ? any documents on this will be appreciated.. Since I am not member of this list, Please send = replies to my mailID 'narasimha.reddy@infrasofttech.biz' only.. Thanks.. Regards Narasimha reddy.V ------_=_NextPart_001_01C33A77.4724D020-- From owner-ipsec@lists.tislabs.com Tue Jun 24 13:09:44 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OK9hrb089527; Tue, 24 Jun 2003 13:09:43 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA05757 Tue, 24 Jun 2003 15:26:17 -0400 (EDT) Message-ID: From: "Vohra, Meenakshi" To: "'ipsec@lists.tislabs.com'" Subject: a free VPN client with KEY_ID support Date: Tue, 24 Jun 2003 10:57:36 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C33A7A.1873F6E0" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C33A7A.1873F6E0 Content-Type: text/plain; charset="ISO-8859-1" Hello Everyone, Can anyone give me an idea of a available free VPN Client that supports KEY_ID Regards, Meenakshi ------_=_NextPart_001_01C33A7A.1873F6E0 Content-Type: text/html; charset="ISO-8859-1" Hello Everyone, Can anyone give me an idea of a available free VPN Client that supports KEY_ID Regards, Meenakshi ------_=_NextPart_001_01C33A7A.1873F6E0-- From owner-ipsec@lists.tislabs.com Tue Jun 24 13:47:18 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OKlHrb092283; Tue, 24 Jun 2003 13:47:17 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05899 Tue, 24 Jun 2003 16:09:13 -0400 (EDT) In-Reply-To: <004201c33a73$cae8a480$7b2e1dc2@jesse> References: <004201c33a73$cae8a480$7b2e1dc2@jesse> Mime-Version: 1.0 (Apple Message framework v578) Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: Content-Transfer-Encoding: 7bit Cc: ipsec@lists.tislabs.com, "'Tero Kivinen'" From: Joshua Graessley Subject: Re: Question about draft-ietf-ipsec-nat-t-ike-06.txt. Date: Tue, 24 Jun 2003 13:15:40 -0700 To: Jesse Alpert X-Mailer: Apple Mail (2.578) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Tuesday, June 24, 2003, at 10:12, Jesse Alpert wrote: > Hi, > > In section 3.2 of the nat-t draft (version 06) it says: > "If the sender of the packet does not know his own IP address ... > he can include multiple ..." > > But in section 5.2. - Sending the original source and destination > addresses, > there is no discussion about this problem. > > Question: If the sender of the packet does not know his own IP address > what > address is he supposed to put in his NAT-OA payload? > > What am I missing? I believe this is done to handle the case where a multihomed host may send from a number of addresses. The IKE implementation may not know which address will be used to send the packet, so it may include a nat detection payload for each address. When the packet is received, if none of the nat detection payloads match the address the packet was from, then a NAT is there. The sender must know the possible IP addresses. It may not know the specific address that will be picked by the stack. -josh From owner-ipsec@lists.tislabs.com Tue Jun 24 13:48:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5OKmDrb092433; Tue, 24 Jun 2003 13:48:13 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA05959 Tue, 24 Jun 2003 16:17:51 -0400 (EDT) Message-Id: <5.2.0.9.0.20030624152301.00a97e78@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Tue, 24 Jun 2003 16:07:38 -0400 To: Radia Perlman - Boston Center for Networking , kent@bbn.com, ipsec@lists.tislabs.com, Black_David@emc.com From: Mark Duffy Subject: Re: QoS selectors (was LAST CALL: IKE) In-Reply-To: <200306192249.h5JMnps21656@sydney.East.Sun.COM> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I like Radia's proposal, mainly because I think trying to bind the SAs to DSCPs or PHBIDs is likely to become a bit of a rathole and really doesn't gain much. I don't see why the receiver should care which packets arrive on which SA, so long as they match all the (other) selectors. Some complications I see with negotiating DSCP or PHBID as a selector: . I agree with David that PHBID would be the correct beast to negotiate, from the Diffserv perspective. But since PHBIDs require a (locally unique) mapping to be translated to the actual bits (DSCP) in the packet, it is a bit of a leap for IPsec compared to the other selectors where the literal selector bits to be seen on the wire are negotiated. Moreover, the mapping from PHBID to DSCP may be 1:n, imposing perhaps a significant burden on an implementation to evaluate for any of multiple possible DSCP values. . For transport mode, the DSCP that the selectors are evaluated against is that in the outer (only) IP header. This is mutable and hence may be remapped at a Diffserv domain boundary while still representing the same semantics as represented by the corresponding negotiated PHBID. But for tunnel mode the selectors are evaluated against the inner IP header and this DSCP would *not* be mapped at a Diffserv domain boundary. This packet might fail at the receiver to match the negotiated PHBID. IF we negotiated DSCP instead of PHBID we'd just have the opposite problem instead. --Mark At 06:49 PM 6/19/2003 -0400, Radia Perlman - Boston Center for Networking wrote: >Hmm. Actually, I think there is no reason to negotiate which >TOS values go on which SA. The reason for different SAs for >different TOS values is so that the sequence numbers don't get >too far off (assuming that different TOS's go at different speeds). > >So it seems like the sender, which knows it wants to send n different >TOSs for which speeds will vary, can open n SAs, and choose which >of the TOSs to send on which of them. > >If A and B have n SAs already, then if A has k different TOS's, A >can use the other half of the n SAs (and doesn't need to open more >of them) if k < n. > >I *think* the current IKEv2 spec supports this. The previous draft >said something about having to close redundant SAs. This one at >least implies that the only time you'd close a redundant SA is if >it happened as a result of a rekeying collision. > >A few of us had worked out language in the hallway at the last IETF, >explicitly saying things like that only the creator of an SA could >delete a redundant SA, but I think it was declared too late to make >design decisions like that that might have other implications. > >Radia > > > > From: Black_David@emc.com > To: kent@bbn.com, ipsec@lists.tislabs.com > Subject: QoS selectors (was LAST CALL: IKE) > MIME-Version: 1.0 > > Steve, > > > Several folks have asked for the ability to place traffic with > > different TOS values on different SAs, which requires that the TOS > > field (IPv4) and the flow spec field (IPv6) be useable as > selectors. > > If we agree to add this feature, we need the ability to negootiate > > this in IKE. > > That would be the 6 bit DS Field, as defined in RFC 2780. The other > two bits in the same header octets are used for ECN and should not be > used as selectors. There are some subtle issues in QoS specification > across administrative domain boundaries - in full generality, the > DiffServ Code Point (DSCP) values used in the DS Field do not have > global validity or meaning. > > It's ok to use DSCPs when the values are only expected to be > meaningful to one end of the connection (e.g., receiver tells > sender to set DSCP to in inner IP header for tunnel mode > SA), or something in the middle can be expected to do the > translation if necessary - the latter does not apply to IKE > for obvious reasons. For more general negotiation, where both > ends are expected to understand what is being negotiated, > PHBIDs (RFC 3140) are appropriate. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- From owner-ipsec@lists.tislabs.com Tue Jun 24 16:55:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5ONtrrb098813; Tue, 24 Jun 2003 16:55:53 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA06518 Tue, 24 Jun 2003 19:20:26 -0400 (EDT) Message-Id: <200306242326.h5ONQIq3028171@thunk.east.sun.com> From: Bill Sommerfeld To: "Stephen C. Koehler" cc: ipsec@lists.tislabs.com Subject: Re: IKEv2 payload #14 In-Reply-To: Your message of "Mon, 23 Jun 2003 11:01:46 CDT." <200306231921.PAA00447@lists.tislabs.com> Reply-to: sommerfeld@east.sun.com Date: Tue, 24 Jun 2003 19:26:18 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Renumbering the payloads so they're non-overlapping sounds like a good idea. Now's the time to do it.. From owner-ipsec@lists.tislabs.com Tue Jun 24 18:23:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5P1NOrb001172; Tue, 24 Jun 2003 18:23:24 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA06838 Tue, 24 Jun 2003 20:50:16 -0400 (EDT) Date: Tue, 24 Jun 2003 17:56:38 -0700 Mime-Version: 1.0 (Apple Message framework v552) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Q: ikev2 notify status ranges reserved to IANNA From: Ricky Charlet To: ipsec mailingList Content-Transfer-Encoding: 7bit Message-Id: X-Mailer: Apple Mail (2.552) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Howdy, ikev2 draft 08 reserves two different ranges of notify status numbers for IANNA use: RESERVED TO IANA - STATUS 16384 - 24577 RESERVED TO IANA - STATUS 24587 - 40959 Why the two ranges? --- Ricky Charlet rcharlet@alumni.calpoly.edu 510.324.3163 From owner-ipsec@lists.tislabs.com Tue Jun 24 21:04:09 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5P448rb006245; Tue, 24 Jun 2003 21:04:08 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id XAA07284 Tue, 24 Jun 2003 23:21:33 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <16120.34361.478936.810170@ryijy.hel.fi.ssh.com> References: <16120.34361.478936.810170@ryijy.hel.fi.ssh.com> Date: Tue, 24 Jun 2003 22:32:36 -0400 To: Tero Kivinen From: Stephen Kent Subject: Re: LAST CALL: IKE Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 8:11 PM +0300 6/24/03, Tero Kivinen wrote: >Stephen Kent writes: >> >As a separate matter, I had requested a few months ago that we allow >> >IKE peers to negotiate use of groups other than the set defined in >> >Oakley. I see that there is a provision to negotiate other choices >> >for P, but not for G. I apologize for not noticing this sooner. I >> >would like to see the negotiation made more general, so that both >> >the generator as well as the exponent are values that peers can >> >negotiate. >> >> This is a request to make the IKE parameter space negotiation more >> flexible. there would be no requirement that a conforming >> implementation support other groups than the ones defined in the >> separate IKE algorithms spec. But it would allow user communities to >> specify other groups for their own use. I thought we agreed on this a >> while ago, but I didn't check closely enough to realize that the >> current IKE version allows only the exponent, not the generator, to >> be specified. My intent had been to allow both to be specified. > >This is one of the features of the IKEv1 that I would really like to >be removed from IKEv2. The problem with private diffie-hellman groups >is that you do now know how the group was generated, and is it safe. >If you try to do online checks for the groups it takes time and adds >more code to the ipsec, causing more bugs. I agree with your observation that it would be unsafe to accept such a group simply as a result of negotiation. What I want is the ability for a community to accept a given group, a priori, and be able to tell one another that the group they previously agreed to use is the one to use for a given SA. >I do know this, as I did implement that feature in the IKEv1. > >We do have 16-bit number for groups. We do have private use space for >groups to be used. I suggest we remove the options to negotiate any >group parameters inside the IKE, and say that if you want to use other >groups, you either > > 1) write a document describing the groups, and allocate > proper number for them from IANA. > > or > > 2) Define the group parameters in both ends and take number > from private use space and use that ine IKE. The problem my clients have encountered is that vendors generally provide NO management interface to enter the parameters for private groups. Thus the existence of this facility has, in effect, been useless. However, if we mandated in IKEv2 that a management interface MUST be present to configure private groups, which can then be referenced as you note above, I think that would suffice. Steve From owner-ipsec@lists.tislabs.com Wed Jun 25 06:39:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5PDdZrb062128; Wed, 25 Jun 2003 06:39:36 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08858 Wed, 25 Jun 2003 08:58:54 -0400 (EDT) Message-ID: <004201c33aff$86f46160$6a05a8c0@charleslaptop> From: "Lin Yi-Chang" To: "._IPSEC" Subject: ASK for IPSEC Help! Date: Wed, 25 Jun 2003 17:52:43 +0800 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_003D_01C33B42.93DCD770" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2720.3000 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2727.1300 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk This is a multi-part message in MIME format. ------=_NextPart_000_003D_01C33B42.93DCD770 Content-Type: text/plain; charset="big5" Content-Transfer-Encoding: quoted-printable Dear ALL:=20 I have encounter a situation I can't handle it, Plz help me if u know. This is the freeswan (whack --status) The following case will work!!! (Client to Gateway case) 000 interface ipsec0/ixp1 192.168.5.120 000 000 "ips0": = 192.168.2.0/24=3D=3D=3D192.168.5.120---192.168.5.1...192.168.5.148 000 "ips0": ike_life: 3600s; ipsec_life: 28000s; rekey_margin: 540s; = rekey_fuz z: 100%; keyingtries: 3 000 "ips0": policy: PSK+TUNNEL+PFS; interface: ixp1; erouted 000 "ips0": newest ISAKMP SA: #0; newest IPsec SA: #33; eroute owner: = #33 000 000 #33: "ips0" STATE_QUICK_I2 (sent QI2, IPsec SA established); = EVENT_SA_REPLAC E in 26939s; newest IPSEC; eroute owner 000 #33: "ips0" esp.866d1ec9@192.168.5.148 esp.7c18934f@192.168.5.120 = tun.1025@1 92.168.5.148 tun.1024@192.168.5.120 000 -------------------------------------------------------------------------= --------------------------------------------- But if the situation is shown below (The Road warrior case) 000 interface ipsec0/ixp1 192.168.5.120 000 000 "ips0"[1]: = 192.168.2.0/24=3D=3D=3D192.168.5.120---192.168.5.1...192.168.5.148 000 "ips0"[1]: ike_life: 3600s; ipsec_life: 28000s; rekey_margin: = 540s; rekey_ fuzz: 100%; keyingtries: 3 000 "ips0"[1]: policy: PSK+TUNNEL+PFS; interface: ixp1; erouted 000 "ips0"[1]: newest ISAKMP SA: #34; newest IPsec SA: #35; eroute = owner: #35 000 "ips0": 192.168.2.0/24=3D=3D=3D192.168.5.120---192.168.5.1...%any 000 "ips0": ike_life: 3600s; ipsec_life: 28000s; rekey_margin: 540s; = rekey_fuz z: 100%; keyingtries: 3 000 "ips0": policy: PSK+TUNNEL+PFS; interface: ixp1; unrouted 000 "ips0": newest ISAKMP SA: #0; newest IPsec SA: #0; eroute owner: = #0 000 000 #35: "ips0"[1] 192.168.5.148 STATE_QUICK_R2 (IPsec SA established); = EVENT_SA _REPLACE in 87s; newest IPSEC; eroute owner 000 #35: "ips0"[1] 192.168.5.148 esp.224d0706@192.168.5.148 = esp.7c189350@192.168 .5.120 tun.1027@192.168.5.148 tun.1026@192.168.5.120 000 #34: "ips0"[1] 192.168.5.148 STATE_MAIN_R3 (sent MR3, ISAKMP SA = established) ; EVENT_SA_REPLACE in 85s; newest ISAKMP 000 When the ICMP start from the right, 192.168.2.2 will return the ICMP but = 192.168.5.120 didn't do anything for the=20 ICMP reply packet (should change it into ESP and back to the right) , = How can I solve the problem? Where is the packet entry point (file) in KLIPS??? Thanks for ur help -charles=20 ------=_NextPart_000_003D_01C33B42.93DCD770 Content-Type: text/html; charset="big5" Content-Transfer-Encoding: quoted-printable Dear ALL: I have encounter a situation I can't handle it, Plz help me if u=20 know. This is the freeswan (whack --status) The following case will work!!! (Client to Gateway case) 000 interface ipsec0/ixp1 192.168.5.120 000 000 "ips0":=20 192.168.2.0/24=3D=3D=3D192.168.5.120---192.168.5.1...192.168.5.148 000= =20 "ips0": ike_life: 3600s; ipsec_life: 28000s; rekey_margin: = 540s;=20 rekey_fuz z: 100%; keyingtries: 3 000 "ips0": policy:=20 PSK+TUNNEL+PFS; interface: ixp1; erouted 000 "ips0": = newest=20 ISAKMP SA: #0; newest IPsec SA: #33; eroute owner: #33 000 000 = #33: "ips0"=20 STATE_QUICK_I2 (sent QI2, IPsec SA established); EVENT_SA_REPLAC E in = 26939s;=20 newest IPSEC; eroute owner 000 #33: "ips0" <3d.htm>esp.866d1ec9@192.168.5.148= <3d.htm>esp.7c18934f@192.168.5.120= <3d.htm>tun.1025@1 92.168.5.148 <3d.htm>tun.1024@192.168.5.120 000<= /DIV> --------------------------------------------------------------------= -------------------------------------------------- But if the situation is shown below (The Road warrior = case) 000 interface ipsec0/ixp1 192.168.5.120 000 000 "ips0"[1]:=20 192.168.2.0/24=3D=3D=3D192.168.5.120---192.168.5.1...192.168.5.148 000= =20 "ips0"[1]: ike_life: 3600s; ipsec_life: 28000s; = rekey_margin: 540s;=20 rekey_ fuzz: 100%; keyingtries: 3 000 "ips0"[1]: = policy:=20 PSK+TUNNEL+PFS; interface: ixp1; erouted 000 "ips0"[1]: = newest=20 ISAKMP SA: #34; newest IPsec SA: #35; eroute owner: #35 000 "ips0":=20 192.168.2.0/24=3D=3D=3D192.168.5.120---192.168.5.1...%any 000 = "ips0": =20 ike_life: 3600s; ipsec_life: 28000s; rekey_margin: 540s; rekey_fuz z: = 100%;=20 keyingtries: 3 000 "ips0": policy: PSK+TUNNEL+PFS; = interface:=20 ixp1; unrouted 000 "ips0": newest ISAKMP SA: #0; newest = IPsec SA:=20 #0; eroute owner: #0 000 000 #35: "ips0"[1] 192.168.5.148 = STATE_QUICK_R2=20 (IPsec SA established); EVENT_SA _REPLACE in 87s; newest IPSEC; = eroute=20 owner 000 #35: "ips0"[1] 192.168.5.148 <3d.htm>esp.224d0706@192.168.5.148= <3d.htm>esp.7c189350@192.168 .5.120 = <3d.htm>tun.1027@192.168.5.148 <3d.htm>tun.1026@192.168.5.120 000 = #34:=20 "ips0"[1] 192.168.5.148 STATE_MAIN_R3 (sent MR3, ISAKMP SA = established) ;=20 EVENT_SA_REPLACE in 85s; newest ISAKMP 000 When the ICMP start from the right, 192.168.2.2 will return the = ICMP=20 but 192.168.5.120 didn't do anything for the ICMP reply packet (should change it into ESP and back to the = right) ,=20 How can I solve the problem? Where is the packet entry point (file) in KLIPS??? Thanks for ur help -charles ------=_NextPart_000_003D_01C33B42.93DCD770-- From owner-ipsec@lists.tislabs.com Wed Jun 25 06:39:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5PDdZrb062129; Wed, 25 Jun 2003 06:39:36 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id IAA08843 Wed, 25 Jun 2003 08:54:46 -0400 (EDT) Message-Id: <4.3.2.7.2.20030624151559.04945568@mira-sjc5-4.cisco.com> X-Sender: byfraser@mira-sjc5-4.cisco.com X-Mailer: QUALCOMM Windows Eudora Version 4.3.2 Date: Tue, 24 Jun 2003 15:17:57 -0700 To: ipsec@lists.tislabs.com From: Barbara Fraser Subject: End of WG Last Call - IKEv2, algorithms, and UI suites documents Cc: byfraser@cisco.com, tytso@mit.edu, Tero Kivinen , angelos@cs.columbia.edu Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="=====================_39655181==_.ALT" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk --=====================_39655181==_.ALT Content-Type: text/plain; charset="us-ascii"; format=flowed I sent this before lunch on Monday but still haven't seen it on the list. According to the postmaster at tislabs they had an outage until 4pm yesterday but since I've seen more recent mail posted, and still haven't seen my original, I'm resending. Barb From Monday: Today marks the end of the WG last call on the following documents. Angelos is collating the issues and will be posting a note regarding them in the near future. draft-ietf-ipsec-ikev2-08.txt draft-ietf-ipsec-ikev2-algorithms-02.txt draft-ietf-ipsec-ui-suites-01.txt thanks, Barb and Ted --=====================_39655181==_.ALT Content-Type: text/html; charset="us-ascii" I sent this before lunch on Monday but still haven't seen it on the list. According to the postmaster at tislabs they had an outage until 4pm yesterday but since I've seen more recent mail posted, and still haven't seen my original, I'm resending. Barb >From Monday: Today marks the end of the WG last call on the following documents. Angelos is collating the issues and will be posting a note regarding them in the near future. draft-ietf-ipsec-ikev2-08.txt draft-ietf-ipsec-ikev2-algorithms-02.txt draft-ietf-ipsec-ui-suites-01.txt thanks, Barb and Ted --=====================_39655181==_.ALT-- From owner-ipsec@lists.tislabs.com Wed Jun 25 06:41:25 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5PDfPrb062397; Wed, 25 Jun 2003 06:41:25 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08898 Wed, 25 Jun 2003 09:04:38 -0400 (EDT) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: 21-25 July 2003 IPsec bakeoff ETSI Sophia Antipolis - last reminder to IETF IPsec list Date: Wed, 25 Jun 2003 15:10:24 +0200 Message-ID: <4091553999CBE4409CC2B562152B5A330231827F@email10.etsihq.org> Thread-Topic: 21-25 July 2003 IPsec bakeoff ETSI Sophia Antipolis - last reminder to IETF IPsec list Thread-Index: AcM7GyPgN43LaOJvRmyFJR0Tl5Zxvg== From: =?iso-8859-1?Q?Patrick_Ren=E9_Guillemin?= To: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id JAA08895 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear All, Please let me remind you that the Plugtests interoperability event IPsec will take place soon at ETSI (21-25 July 2003)! The IPsec registration closing date is approaching (6 July 2003) If interested, please register using the following url www.etsi.org/plugtests/02UpcomingEvents/IPsec/IPSec_registration.htm or click "Registration/login" in www.etsi.org/plugtests/02UpcomingEvents/IPsec/IPsec_home.htm Any comments are welcome! Details: In addition to testbed native IPv6 access, ETSI will provide (LAN and WLAN) with direct IPv4 access at 2x10 Mbps on the same network to test: - IPsec over IPv4 and IPv6 - Manual IPsec - IKEv1 and IKEv2 - NAT-T - Remote access extensions - ... and more as you like As for other events, testing guidelines will be given but no tests are mandatory and participants select tests according to their wish. In addition to interoperability we could organize IPsec performance and scalability tests if enough participants are interested. During the week, we could book rooms to allow attendees to organize talks about subjects such as: - IPsec benchmarking methodology IETF draft - PPVPN Feedback on generic problems encountered will be shared during the event. It is reminded that detailed information shared during the event is confidential and the event strictly reserved to technical people with products. Marketing and Sales representatives as well as observers are not allowed. Best Regards, Patrick GUILLEMIN Plugtests Technical Coordinator www.etsi.org/plugtests tel +33(0)4 92 94 43 31 fax +33(0)4 92 38 52 31 From owner-ipsec@lists.tislabs.com Wed Jun 25 06:47:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5PDlErb063231; Wed, 25 Jun 2003 06:47:14 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA08924 Wed, 25 Jun 2003 09:09:05 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16121.41019.94248.838665@ryijy.hel.fi.ssh.com> Date: Wed, 25 Jun 2003 16:14:35 +0300 From: Tero Kivinen To: Stephen Kent Cc: ipsec@lists.tislabs.com Subject: Re: LAST CALL: IKE In-Reply-To: References: <16120.34361.478936.810170@ryijy.hel.fi.ssh.com> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 4 min X-Total-Time: 5 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > I agree with your observation that it would be unsafe to accept such > a group simply as a result of negotiation. What I want is the ability > for a community to accept a given group, a priori, and be able to > tell one another that the group they previously agreed to use is the > one to use for a given SA. This can be archieved by the private number space groups. Also note that the current draft do say: ---------------------------------------------------------------------- 3.3.4 Mandatory Transform IDs ... It is likely that IANA will add additional transforms in the future, and some users may want to use private suites, especially for IKE where implementations should be capable of supporting different parameters, up to certain size limits. In support of this goal, all implementations of IKEv2 SHOULD include a management facility that allows specification (by a user or system administrator) of Diffie- Hellman parameters (the generator, modulus, and exponent lengths and values) for new DH groups. Implementations SHOULD provide a management interface via which these parameters and the associated transform IDs may be entered (by a user or system administrator), to enable negotiating such groups. ... ---------------------------------------------------------------------- I.e implementations SHOULD have capability to input those private groups to the system. > The problem my clients have encountered is that vendors generally > provide NO management interface to enter the parameters for private > groups. Thus the existence of this facility has, in effect, been I think most of them do not provide the management interface, because the do not provide any way to use private groups at all. Now this management interface is "SHOULD", so hopefully more people will implement it. It is also much easier to implement only the adding of new groups without the capability of sending the group parameters in the wire, so hopefully more implementations will follow this "SHOULD". > useless. However, if we mandated in IKEv2 that a management > interface MUST be present to configure private groups, which can then > be referenced as you note above, I think that would suffice. I am fine with MUST too, but I think SHOULD is enough. For some very small boxes they might want to limit to the only one group or something, and they might not have any configuration interface at all... -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Wed Jun 25 13:03:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5PK31rb083886; Wed, 25 Jun 2003 13:03:01 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA10700 Wed, 25 Jun 2003 15:17:33 -0400 (EDT) Message-ID: <3EF9F6C4.5030203@creeksidenet.com> Date: Wed, 25 Jun 2003 15:23:48 -0400 From: jeff pickering User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Stephen Kent CC: Tero Kivinen , ipsec@lists.tislabs.com Subject: Re: LAST CALL: IKE References: <16120.34361.478936.810170@ryijy.hel.fi.ssh.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk We have mandated no management interface for any other feature so it would seem extremely inconsistent to me to do this here. Stephen Kent wrote: > At 8:11 PM +0300 6/24/03, Tero Kivinen wrote: > >> Stephen Kent writes: >> >>> >As a separate matter, I had requested a few months ago that we allow >>> >IKE peers to negotiate use of groups other than the set defined in >>> >Oakley. I see that there is a provision to negotiate other choices >>> >for P, but not for G. I apologize for not noticing this sooner. I >>> >would like to see the negotiation made more general, so that both >>> >the generator as well as the exponent are values that peers can >>> >negotiate. >>> >>> This is a request to make the IKE parameter space negotiation more >>> flexible. there would be no requirement that a conforming >>> implementation support other groups than the ones defined in the >>> separate IKE algorithms spec. But it would allow user communities to >>> specify other groups for their own use. I thought we agreed on this a >>> while ago, but I didn't check closely enough to realize that the >>> current IKE version allows only the exponent, not the generator, to >>> be specified. My intent had been to allow both to be specified. >> >> >> This is one of the features of the IKEv1 that I would really like to >> be removed from IKEv2. The problem with private diffie-hellman groups >> is that you do now know how the group was generated, and is it safe. >> If you try to do online checks for the groups it takes time and adds >> more code to the ipsec, causing more bugs. > > > I agree with your observation that it would be unsafe to accept such a > group simply as a result of negotiation. What I want is the ability > for a community to accept a given group, a priori, and be able to tell > one another that the group they previously agreed to use is the one to > use for a given SA. > >> I do know this, as I did implement that feature in the IKEv1. >> >> We do have 16-bit number for groups. We do have private use space for >> groups to be used. I suggest we remove the options to negotiate any >> group parameters inside the IKE, and say that if you want to use other >> groups, you either >> >> 1) write a document describing the groups, and allocate >> proper number for them from IANA. >> >> or >> >> 2) Define the group parameters in both ends and take number >> from private use space and use that ine IKE. > > > The problem my clients have encountered is that vendors generally > provide NO management interface to enter the parameters for private > groups. Thus the existence of this facility has, in effect, been > useless. However, if we mandated in IKEv2 that a management interface > MUST be present to configure private groups, which can then be > referenced as you note above, I think that would suffice. > > Steve > > From owner-ipsec@lists.tislabs.com Wed Jun 25 16:26:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5PNQgrb090327; Wed, 25 Jun 2003 16:26:42 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA12139 Wed, 25 Jun 2003 18:33:59 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <5.2.0.9.0.20030624152301.00a97e78@email> References: <5.2.0.9.0.20030624152301.00a97e78@email> Date: Wed, 25 Jun 2003 14:29:28 -0400 To: Mark Duffy , Radia Perlman - Boston Center for Networking , ipsec@lists.tislabs.com, Black_David@emc.com From: Stephen Kent Subject: Re: QoS selectors (was LAST CALL: IKE) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:07 PM -0400 6/24/03, Mark Duffy wrote: >I like Radia's proposal, mainly because I think trying to bind the >SAs to DSCPs or PHBIDs is likely to become a bit of a rathole and >really doesn't gain much. > >I don't see why the receiver should care which packets arrive on >which SA, so long as they match all the (other) selectors. > >Some complications I see with negotiating DSCP or PHBID as a selector: > >. I agree with David that PHBID would be the correct beast to >negotiate, from the Diffserv perspective. But since PHBIDs require >a (locally unique) mapping to be translated to the actual bits >(DSCP) in the packet, it is a bit of a leap for IPsec compared to >the other selectors where the literal selector bits to be seen on >the wire are negotiated. Moreover, the mapping from PHBID to DSCP >may be 1:n, imposing perhaps a significant burden on an >implementation to evaluate for any of multiple possible DSCP values. > >. For transport mode, the DSCP that the selectors are evaluated >against is that in the outer (only) IP header. This is mutable and >hence may be remapped at a Diffserv domain boundary while still >representing the same semantics as represented by the corresponding >negotiated PHBID. But for tunnel mode the selectors are evaluated >against the inner IP header and this DSCP would *not* be mapped at a >Diffserv domain boundary. This packet might fail at the receiver to >match the negotiated PHBID. IF we negotiated DSCP instead of PHBID >we'd just have the opposite problem instead. > >--Mark The motivation that other had raised, and that I was merely responding to, is that if one puts traffic with different service characteristics on one SA, then it is likely that the traffic will arrive very much out of order and as a result the receiver sequence window will reject more traffic than under better circumstances. I don't understand how the comments above address this concern. Could you clarify? Thanks, Steve From owner-ipsec@lists.tislabs.com Wed Jun 25 16:27:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5PNRJrb090361; Wed, 25 Jun 2003 16:27:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA12144 Wed, 25 Jun 2003 18:34:03 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <3EF16ED1.3040908@nomadiclab.com> References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EEC2C43.9060302@nomadiclab.com> <16112.1673.849180.847121@ryijy.hel.fi.ssh.com> <3EF16ED1.3040908@nomadiclab.com> Date: Wed, 25 Jun 2003 18:07:58 -0400 To: Pekka Nikander From: Stephen Kent Subject: Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences Cc: Tero Kivinen , ipsec@lists.tislabs.com, James Kempf , SEND WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:05 AM +0300 6/19/03, Pekka Nikander wrote: >>>Is there any use for the AH as it is now specified? >> >>Very little. But, that does not mean that one can redefine it and >>still have it be part of IPsec. > >Just out of curiosity: How do you define IPsec? RFC2401? RFC 2401 defines IPsec processing and semantics. ESP and AH are the two subscriber traffic protocols whose syntax is separately defined. We put the common processing and context discussion in 2401, to avoid repetition. I do not view AH and ESP as protocols that should be viewed outside of the context of 2401. > >>The SEND WG can create its own protocol, but there is no technical >>rationale for reusing the AH name. Reuse would only cause confusion. > >In my (in this case very) humble opinion, I think that the question >of reusing the AH name depends on the intent of the protocol, not >only on its syntax. If the goal is the same, to provide integrity >and data origin authentication for the whole IP packet, including the >immutable or predictable header fields, then I think that the protocol >could and should be called AH. If it uses public key crypto, and >thereby creates (conceptual) Security Associations that are associated >with the source of the packet rather than the destination, even for >unicast, that does not change the intent. > >OTOH, I do agree that embedding KMP functionality into the AH header >does not sound that good an idea. However, it did not appear to me how >to separate the KMP functionality before I started to implement the >current SEND proposal. Embedding key management data in the transit traffic headers is what SKIP proposed a long time ago. The IPsec WG spent over 2 years arguing about this before we adopted IKE. >AH has a long history. I think it would be better to return to the >some early goals of AH rather than to deprecate it and start anew. Some of the early goals are no longer relevant, e.g., because of the advent of integrity-only ESP. Steve From owner-ipsec@lists.tislabs.com Wed Jun 25 16:27:21 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5PNRKrb090362; Wed, 25 Jun 2003 16:27:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA12145 Wed, 25 Jun 2003 18:34:04 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564CD9A@corpmx14.us.dg.com> References: <277DD60FB639D511AC0400B0D068B71E0564CD9A@corpmx14.us.dg.com> Date: Wed, 25 Jun 2003 16:18:06 -0400 To: Black_David@emc.com, ipsec@lists.tislabs.com From: Stephen Kent Subject: Re: AHbis comments Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:04 PM -0400 6/16/03, Black_David@emc.com wrote: >Here are a couple of transport related comments on >draft-ietf-ipsec-rfc2402bis-03.txt . These have no >effect on the specified processing - they're mostly >about updating the explanation and references. > >Section 3.3.3.1.1.1 describes the TOS field in the IP >Header as mutable (that's correct) and says: > > TOS -- This field is excluded because some routers are known to > change the value of this field, even though the IP specification > does not consider TOS to be a mutable header field. > >That's no longer correct. The TOS field has now been >replaced by a 6 bit DS field (contains a Diffserv >codepoint) plus a 2 bit ECN field, and both are defined >to be mutable. RFC 2780 and RFC 3168 should be cited >as the basis for this, and possibly also RFC 2474. The >same 6 bit DS + 2 bit ECN structure applies to the IPv6 >(Traffic) Class field (section 3.3.3.1.2.1), which >has always been mutable, as the same RFCs specify it. > >Thanks, >--David > Thanks for the corrections. We obviously didn't look closely at this part of the document when we edited the rest. We will make the appropriate changes. Steve From owner-ipsec@lists.tislabs.com Wed Jun 25 16:54:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5PNsLrb090926; Wed, 25 Jun 2003 16:54:21 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA12490 Wed, 25 Jun 2003 19:07:05 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: Date: Wed, 25 Jun 2003 18:46:06 -0400 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: IKE negotiation for fragmentation controls in IPsec Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk A few folks have observed that the current processing requirements for AH and ESP mandate ciphertext (post IPsec encapsulation) fragmentation and that this poses DoS vulnerabilities for receivers. (An attacker can create what appear to be legitimate, non-initial fragments and cause reassembly problems for the receiver). As we revise 2401, we may choose to allow (or even recommend) plaintext (pre-IPsec encapsulation) fragmentation. If so, we need to be able to negotiate use of this capability on a per-SA basis, and to notify the receiver that NO ciphertext fragments should be accepted for this SA, because none will be sent by this transmitter. So, I suggest that we add a paylod to IKE to allow an initiator to indicate the intent to never send ciphertext fragments. The responder can take advantage of this info to better protect itself, or it can ignore the info, but it needs to be told to be able to take advantage of the capability. I would also like to see the responder be able to notify the initiator of its intent re the companion (reverse) SA, if appropriate. A logical (but admittedly separable) companion to this feature is to allow the initiator to request the responder to accept fragments on an SA where port fields are used as selectors. The issue here is that a host may send fragments to an IPsec device that requires port field examination for the SA to which the fragments will be mapped. It seems reasonably safe to allow fragments (with a suitable, minimum offset) to pass through such as SA, with only the initial fragment having the port fields examined. This is a separate negotiation because the fragments arise from hosts behind the IPsec device, but it is related, because if one fragments at the sending IPsec device, it would be nice to be able to use this feature to allow the receiver to pass on fragments, not reassemble them (in the case of a SG). Steve From owner-ipsec@lists.tislabs.com Wed Jun 25 16:54:50 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5PNsorb090954; Wed, 25 Jun 2003 16:54:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA12495 Wed, 25 Jun 2003 19:07:08 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <3EF9F6C4.5030203@creeksidenet.com> References: <16120.34361.478936.810170@ryijy.hel.fi.ssh.com> <3EF9F6C4.5030203@creeksidenet.com> Date: Wed, 25 Jun 2003 19:00:37 -0400 To: jeff pickering From: Stephen Kent Subject: Re: LAST CALL: IKE Cc: Tero Kivinen , ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:23 PM -0400 6/25/03, jeff pickering wrote: >We have mandated no management interface for any other feature so it would >seem extremely inconsistent to me to do this here. > >Stephen Kent wrote: Jeff, I'm not sure what scope you had in mind when you made this comment. RFC 2401 mandates lots of management features for IPsec implementations, in terms of the ability to configure SPD entries. In that light, mandating support for a management capability to specify private group parameters is completely consistent with what we have done previously, in the larger IPsec context. Steve From owner-ipsec@lists.tislabs.com Wed Jun 25 16:55:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5PNtFrb090973; Wed, 25 Jun 2003 16:55:15 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA12487 Wed, 25 Jun 2003 19:07:03 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: Date: Wed, 25 Jun 2003 18:41:50 -0400 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: Fwd: Re: LAST CALL: IKE Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, I have no idea what happened to my original message that transformed it into the long, continuos string of text that was distributed to the list. Needless to say, it didn't look like that when I sent it! Anyway, here it is again, with more reasonable formatting, and a couple of edits. In anticipation of several proposed changes to RFC 2401, I would like to suggest a few additional payloads to be added to IKE v2. Paul Hoffman sent me a nice, private note suggesting that I needed to do a much better job of describing, and motivating the changes I suggested. He's absolutely right. And, while I was away on a business trip (after my vacation caused me to miss most of the last call comment period), David Black provided excellent clarification for one of my suggestions and Mark Duffy and radia raised some questions about the need/use of QoS selector. So, let me try again. I'll split the message into separate parts, one per topic, to make it easier to deal with each thread. Steve --- From owner-ipsec@lists.tislabs.com Wed Jun 25 16:58:09 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5PNw9rb091033; Wed, 25 Jun 2003 16:58:09 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA12523 Wed, 25 Jun 2003 19:10:46 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <16121.41019.94248.838665@ryijy.hel.fi.ssh.com> References: <16120.34361.478936.810170@ryijy.hel.fi.ssh.com> <16121.41019.94248.838665@ryijy.hel.fi.ssh.com> Date: Wed, 25 Jun 2003 19:09:57 -0400 To: Tero Kivinen From: Stephen Kent Subject: Re: LAST CALL: IKE Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:14 PM +0300 6/25/03, Tero Kivinen wrote: >Stephen Kent writes: >> I agree with your observation that it would be unsafe to accept such >> a group simply as a result of negotiation. What I want is the ability >> for a community to accept a given group, a priori, and be able to >> tell one another that the group they previously agreed to use is the >> one to use for a given SA. > >This can be archieved by the private number space groups. Also note >that the current draft do say: >---------------------------------------------------------------------- >3.3.4 Mandatory Transform IDs >... > It is likely that IANA will add additional transforms in the future, > and some users may want to use private suites, especially for IKE > where implementations should be capable of supporting different > parameters, up to certain size limits. In support of this goal, all > implementations of IKEv2 SHOULD include a management facility that > allows specification (by a user or system administrator) of Diffie- > Hellman parameters (the generator, modulus, and exponent lengths and > values) for new DH groups. Implementations SHOULD provide a > management interface via which these parameters and the associated > transform IDs may be entered (by a user or system administrator), to > enable negotiating such groups. >... >---------------------------------------------------------------------- > >I.e implementations SHOULD have capability to input those private >groups to the system. > >> The problem my clients have encountered is that vendors generally >> provide NO management interface to enter the parameters for private >> groups. Thus the existence of this facility has, in effect, been > >I think most of them do not provide the management interface, because >the do not provide any way to use private groups at all. Now this >management interface is "SHOULD", so hopefully more people will >implement it. It is also much easier to implement only the adding of >new groups without the capability of sending the group parameters in >the wire, so hopefully more implementations will follow this "SHOULD". > >> useless. However, if we mandated in IKEv2 that a management >> interface MUST be present to configure private groups, which can then >> be referenced as you note above, I think that would suffice. > >I am fine with MUST too, but I think SHOULD is enough. For some very >small boxes they might want to limit to the only one group or >something, and they might not have any configuration interface at >all... >-- Thanks for the explanation. I agree that we have what we need here already, and I apologize for not reading closely enough. Or, as they used to say on SNL "NEVERMIND." Steve From owner-ipsec@lists.tislabs.com Wed Jun 25 17:24:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5Q0OXrb091636; Wed, 25 Jun 2003 17:24:33 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA12814 Wed, 25 Jun 2003 19:36:45 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: Date: Wed, 25 Jun 2003 19:43:45 -0400 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: IKE negotiation for ICMP message type selectors Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk One last selector negotiation suggestion: We ought to decide now if there are other fields we want to specify as selectors AND that need to be negotiated (unlike the DiffServ bits). For example, we've had discussion on the list about using ICMP message type fields in lieu of port fields, when ICMP was the payload. What do people think, and why? Steve From owner-ipsec@lists.tislabs.com Wed Jun 25 17:24:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5Q0OZrb091637; Wed, 25 Jun 2003 17:24:36 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA12807 Wed, 25 Jun 2003 19:36:28 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: In-Reply-To: <200306091606.h59G62of004050@givry.rennes.enst-bretagne.fr> References: <200306091606.h59G62of004050@givry.rennes.enst-bretagne.fr> Date: Wed, 25 Jun 2003 19:18:10 -0400 To: Francis Dupont , ipsec@lists.tislabs.com From: Stephen Kent Subject: Re: issue with "per-interface SAD/SPD" Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >At 6:06 PM +0200 6/9/03, Francis Dupont wrote: >>The RFC 2401 mandates (section 4.4, page 13) separate inbound and >>outbound databases (SAD and SPD) for each IPsec-enabled interface. >>This doesn't work in a dynamic environment where for instance dynamic >>routing makes the arrival of a packet for an address of a node possible >>on more than one interface in a long term, or where the peer is a mobile >>node. >>The problem exists at least in SAD lookup for incoming traffic and for >>SPD matching in IKE... IMHO the simplest (so the best :-) solution is >>to introduce an interface selector: the "firewall" properties are kept >>but a SPD entry can be "shared" between some interfaces. >>How this will be handled in the revision of RFC 2401? >> >>Regards >> >>Francis.Dupont@enst-bretagne.fr > >Francis, > >Good points. We'll be presenting a new IPsec processing model to >the list next week, and one facet of it will be a clarification of >the relationship between SPDs, SADs, interfaces and routing. We >will be introducing an explicit forwarding function call, that will >select an interface prior to SPD lookup. > >Going forward, we still need per (logical) interface SPDs, but the >SAD is really per implementation, not per interface. By this I mean >that if a device centrally manages SPI assignment, then only one >SAD is needed. In contrast, if a router had one IPsec process on >each interface card, it would probably want an SAD per card (because >of the difficulties of coordination across interfaces) and that is a >reasonable implementation strategy as well. > >Steve From owner-ipsec@lists.tislabs.com Wed Jun 25 17:24:49 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5Q0Onrb091668; Wed, 25 Jun 2003 17:24:49 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA12808 Wed, 25 Jun 2003 19:36:29 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@localhost Message-Id: Date: Wed, 25 Jun 2003 19:42:07 -0400 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: Re: QoS selectors (was LAST CALL: IKE) Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Several folks have asked for the ability to place traffic with different TOS values on different SAs, which requires that the TOS field (IPv4) and the flow spec field (IPv6) be useable as selectors. If we agree to add this feature, we need the ability to negotiate this in IKE. What I meant to say is closer to what David referred to in his message, i.e., I would anticipate a sender using the 6-bit DS field as an additional selector value (not the ECN bits). I don't think this is affected by the question of whether the interpretatioon of these bits is uniform across ISPs. The concern is that if these bits really do have an affect on the order of delivery of traffic, then putting different classes of traffic into the same SA has the potential to cause a non-trivial percentage of the (lower priority) traffic to be rejected due to receiver window mismatches. Now this is not a problem if the bits are inside a tunnel and NOT propagated to the outer header, but then they are not helping out during transit across unprotected nets. I admit to not being familiar with PHIBs, so I'm not sure what the issues are there. I'm also open to suggestions from IPv6 experts about what to do there, for flows. Mark & Radia suggest that we don't need this facility to be negotiated. I didn;'t understand the arguments until I worked my way through the cases. Now I think I understand the arguments, and basically agree. Let me try to examine the relevant cases: 1. traffic with varying DiffServ bits mapped to one tunnel mode SA, but not copied to the outer header - because the network between the IPsec devices will not see per-packet markings, there would be no addition reordering influence and thus no motivation for separate SAs, hence no need for using these bist as selectors 2. traffic with varying DiffServ bits mapped to one tunnel mode SA and copied to the outer header - this is the obvious case where more significant reordering by the net between the IPsec devices might cause problems (undesirable receiver discards due to receive window mismatches) and what motivated the suggestion to create different SAs for each class of traffic. 3. traffic with varying DiffServ bits mapped to tunnel mode SAs using these bits as selector values, and the bits are copied to the outer header even if the nets between the IPsec devices modify the values in the outer header, this would not affect the inner header values and so I think would work as desired. however, it is correct that this could be done unilaterally by the sender using selectors but not telling the reeciver, and still have this work for an SA, unidirectionally. What we would loose is the ability to tell the receiver what we are doing, or not doing, and thus trigger the reciprocal behavior by the responder, if appropriate. 4. traffic with varying DiffServ bits mapped to one transport mode SA - as in case 2, the traffic has an increased opportunity to be delivered out of order, causing problems at the receiver. again, this motivates using these bits to select different SAs at the sender. 5. traffic with varying DiffServ bits mapped to transport mode SAs using these bits as selector values if the nets between the IPsec devices modifies the bits, we would have a problem when we tried to match the bits against the selectors at the receiver. if the sender maps the traffic to different SAs, using selectors, but does not tell the receiver, then there would be no problems with mismatches in the SPD checks at the receiver. so, I guess I would agree there here too this could be done by the sender unilaterally and the effect would be OK. So, what this seems to suggest is that there is a good use for DiffServ bits (or PHIBs, or whatever) as selectors, but that if one uses them, one need not tell the receiver. Is that right? Steve From owner-ipsec@lists.tislabs.com Wed Jun 25 18:48:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5Q1mwrb093859; Wed, 25 Jun 2003 18:48:58 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA13692 Wed, 25 Jun 2003 20:53:50 -0400 (EDT) Message-Id: <200306260059.h5Q0xeq3003180@thunk.east.sun.com> From: Bill Sommerfeld To: Stephen Kent cc: ipsec@lists.tislabs.com Subject: Re: IKE negotiation for ICMP message type selectors In-Reply-To: Your message of "Wed, 25 Jun 2003 19:43:45 EDT." Reply-to: sommerfeld@east.sun.com Date: Wed, 25 Jun 2003 20:59:40 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > For example, we've had discussion on the list about using ICMP > message type fields in lieu of port fields, when ICMP was the > payload. > > What do people think, and why? Long overdue. Particularly important for IKE and IPv6 (as, pending introduction of some facility to secure Neighbor Discovery) you likely want ND traffic in clear while other ICMPv6 traffic is protected. - Bill From owner-ipsec@lists.tislabs.com Wed Jun 25 19:49:11 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5Q2nBrb094843; Wed, 25 Jun 2003 19:49:11 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA14347 Wed, 25 Jun 2003 22:06:45 -0400 (EDT) X-mProtect: <200306260212> Nokia Silicon Valley Messaging Protection Message-ID: <3EFA5693.7422F7DC@iprg.nokia.com> Date: Wed, 25 Jun 2003 19:12:35 -0700 From: Vijay Devarapalli X-Mailer: Mozilla 4.7 [en] (X11; I; FreeBSD 3.4-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Stephen Kent CC: sommerfeld@east.sun.com, ipsec@lists.tislabs.com Subject: Re: IKE negotiation for ICMP message type selectors References: <200306260059.h5Q0xeq3003180@thunk.east.sun.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bill Sommerfeld wrote: > > > For example, we've had discussion on the list about using ICMP > > message type fields in lieu of port fields, when ICMP was the > > payload. > > > > What do people think, and why? > > Long overdue. > > Particularly important for IKE and IPv6 (as, pending introduction of > some facility to secure Neighbor Discovery) you likely want ND traffic > in clear while other ICMPv6 traffic is protected. agree. infact Mobile IPv6 makes use of ICMP messages to convey to the mobile node changes in the set of IPv6 prefixes advertised on the home link. we use ESP in transport mode betwen the Home Agent and the mobile node for protecting these messages. since IPsec does not look at the ICMP type, it ends up protecting all ICMP messages between the mobile node and the Home Agent. and I believe ICMP can be used for lot more than just error messages. a lot of protocols can make use of ICMP for signaling. so, it would be great if IPsec looks at the ICMP type field. Vijay From owner-ipsec@lists.tislabs.com Wed Jun 25 20:20:53 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5Q3Kqrb095503; Wed, 25 Jun 2003 20:20:52 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id WAA14536 Wed, 25 Jun 2003 22:46:51 -0400 (EDT) To: sommerfeld@east.sun.com Cc: Stephen Kent , ipsec@lists.tislabs.com In-reply-to: sommerfeld's message of Wed, 25 Jun 2003 20:59:40 -0400. <200306260059.h5Q0xeq3003180@thunk.east.sun.com> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IKE negotiation for ICMP message type selectors From: itojun@iijlab.net Date: Thu, 26 Jun 2003 11:53:13 +0900 Message-Id: <20030626025313.0405A9B@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >> For example, we've had discussion on the list about using ICMP >> message type fields in lieu of port fields, when ICMP was the >> payload. >> >> What do people think, and why? > >Long overdue. > >Particularly important for IKE and IPv6 (as, pending introduction of >some facility to secure Neighbor Discovery) you likely want ND traffic >in clear while other ICMPv6 traffic is protected. we will need to do this every time new protocol becomes available. i guess we should make the concept of "selector" more generic. (for KAME implementation i'm thinking of switching to BPF-based policy) itojun From owner-ipsec@lists.tislabs.com Wed Jun 25 23:08:20 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5Q68Krb002032; Wed, 25 Jun 2003 23:08:20 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id BAA15469 Thu, 26 Jun 2003 01:31:30 -0400 (EDT) Message-ID: <3EFA862B.2040405@kolumbus.fi> Date: Thu, 26 Jun 2003 08:35:39 +0300 From: Jari Arkko User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: sommerfeld@east.sun.com Cc: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: IKE negotiation for ICMP message type selectors References: <200306260059.h5Q0xeq3003180@thunk.east.sun.com> In-Reply-To: <200306260059.h5Q0xeq3003180@thunk.east.sun.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Bill Sommerfeld wrote: >>For example, we've had discussion on the list about using ICMP >>message type fields in lieu of port fields, when ICMP was the >>payload. > > Long overdue. > > Particularly important for IKE and IPv6 (as, pending introduction of > some facility to secure Neighbor Discovery) you likely want ND traffic > in clear while other ICMPv6 traffic is protected. I agree. --Jari From owner-ipsec@lists.tislabs.com Thu Jun 26 05:08:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QC8Drb045892; Thu, 26 Jun 2003 05:08:13 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id HAA16874 Thu, 26 Jun 2003 07:28:16 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16122.55806.305977.986255@ryijy.hel.fi.ssh.com> Date: Thu, 26 Jun 2003 14:33:18 +0300 From: Tero Kivinen To: Stephen Kent Cc: ipsec@lists.tislabs.com Subject: IKE negotiation for fragmentation controls in IPsec In-Reply-To: References: X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 9 min X-Total-Time: 10 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > for this SA, because none will be sent by this transmitter. So, I > suggest that we add a paylod to IKE to allow an initiator to indicate > the intent to never send ciphertext fragments. The responder can take > advantage of this info to better protect itself, or it can ignore the > info, but it needs to be told to be able to take advantage of the > capability. I would also like to see the responder be able to notify > the initiator of its intent re the companion (reverse) SA, if > appropriate. Would it be enough to have ---------------------------------------------------------------------- FRAGMENTATION_BEFORE_IPSEC 24587 By sending this notification the sender announces that it can process packets which are fragmented before being encapsulated to the IPSec packets, i.e the recipient of this notification can send such packets and assume that the other end can process them. If this notification payload is sent by both ends (i.e both ends support this feature), then both ends MUST NOT send packets fragmented after the IPsec encapsulation and SHOULD (configurable by local policy) reject incoming packets which are fragmented after IPsec encapsulation (i.e as the other end must not send them it was either some other router which fragmented it or it was an attack). ---------------------------------------------------------------------- in the section 3.10.1 Notify Message Types - STATUS TYPES? > A logical (but admittedly separable) companion to this feature is to > allow the initiator to request the responder to accept fragments on > an SA where port fields are used as selectors. The issue here is that > a host may send fragments to an IPsec device that requires port field > examination for the SA to which the fragments will be mapped. It > seems reasonably safe to allow fragments (with a suitable, minimum > offset) to pass through such as SA, with only the initial fragment > having the port fields examined. This is a separate negotiation > because the fragments arise from hosts behind the IPsec device, but > it is related, because if one fragments at the sending IPsec device, > it would be nice to be able to use this feature to allow the receiver > to pass on fragments, not reassemble them (in the case of a SG). The normal processing of those packets on the firewalls is to put those non-first fragments to (small) queue and when the first fragment then arrives, then do the policy check and forward the first fragment and all additional fragments forward (and also mark the fragment id so that all future fragments to same packet will get through for some time). Also care should be taken that the any fragments do not overwrite anything from the first fragment that was used for the policy checks (i.e the port numbers are not overwritten by later non-first fragment). I am not sure that we should allow sending of the non-first fragments to IPsec SAs using the port selectors unless we have validated that the port numbers match the policy. There is no need to do the actual reassembly, simply queuing the non-first framents coming before the first fragment and adding entry that will allow rest of the fragments to the packet to get through for some time is enough. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Thu Jun 26 07:20:08 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QEK7rb051338; Thu, 26 Jun 2003 07:20:07 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA17708 Thu, 26 Jun 2003 09:35:22 -0400 (EDT) From: Charles Lynn To: Stephen Kent Cc: ipsec@lists.tislabs.com Subject: Re: Re: QoS selectors (was LAST CALL: IKE) In-Reply-To: Message-Id: <20030626134108.AE97F16484@wolfe.bbn.com> Date: Thu, 26 Jun 2003 09:41:08 -0400 (EDT) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve and IKEv2 folks, > So, what this seems to suggest is that there is a good use for > DiffServ bits (or PHIBs, or whatever) as selectors, Yes, I agree. > but that if one uses them, one need not tell the receiver. Is that right? I am not sure. Consider the receiver. If the receiver has the same "policy" as the sender, then it will also want to have multiple SAs. Since, to its knowledge, none of the existing SAs from the initiator have DiffServ markings, and it wants to use them, then it will setup its own SAs back to the original initiator. Now there are 2 * N SAs half of which will never be used by each endpoint. We can do better. Can the responder even setup its own SAs? Do the duplicate detection rules need to be expanded? What about detection of unused or half-dead SAs? Do they need to be more complicated to achieve the desired results? Recent text says half open connections should be audited. The false positives would lead to reduced confidence in auditing: "ignore it". Are there other ramifications that we need to consider? Charlie From owner-ipsec@lists.tislabs.com Thu Jun 26 07:52:31 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QEqUrb054058; Thu, 26 Jun 2003 07:52:30 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA18088 Thu, 26 Jun 2003 10:12:16 -0400 (EDT) From: Charles Lynn To: Stephen Kent Cc: Bill Sommerfeld , Vijay Devarapalli , itojun@iijlab.net, Jari Arkko , ipsec@lists.tislabs.com Subject: Re: IKE negotiation for ICMP message type selectors In-Reply-To: <200306260059.h5Q0xeq3003180@thunk.east.sun.com> <3EFA5693.7422F7DC@iprg.nokia.com> <20030626025313.0405A9B@coconut.itojun.org> <3EFA862B.2040405@kolumbus.fi> Message-Id: <20030626141810.0027816484@wolfe.bbn.com> Date: Thu, 26 Jun 2003 10:18:10 -0400 (EDT) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, > For example, we've had discussion on the list about using ICMP > message type fields in lieu of port fields, when ICMP was the payload. I agree that the type and code fields need to be selectors. The next question is whether there needs to be "sub-selectors" for the fields a packet that, e.g., caused an error. I think that this issue is related to whether ICMP messages MUST/SHOULD/MAY be sent in the SA of the packet that caused the error, or whether the ICMP should cause its own SA to be created. (If the answer is MUST in the SA of the packet that caused the error, then the selectors are "implicit"; if there MUST be a separate SA, then, I think, IKE would have to make them explicit. Do folks agree?) If the answer is SHOULD/MAY, then I think that the sub-selectors would be needed. What do the folks who have said "agree" to ICMP type and code think? itojun commented... > we will need to do this every time new protocol becomes available. > i guess we should make the concept of "selector" more generic. > (for KAME implementation i'm thinking of switching to BPF-based policy) I agree that some extensible mechanism is needed. Selectors form a tree (or maybe lattice if one wants to simplify "reuse"). I do not think that this is a problem that the current IPsec working group will have as a work item, and not before IKEv2 advances. Obvious issues are "complexity" of the packet parsing/description language (of which BPF is an example), and whether the concept or implementations introduce unacceptable risks. Charlie From owner-ipsec@lists.tislabs.com Thu Jun 26 08:11:32 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QFBWrb056371; Thu, 26 Jun 2003 08:11:32 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA18260 Thu, 26 Jun 2003 10:32:10 -0400 (EDT) From: Charles Lynn To: ipsec@lists.tislabs.com Cc: ipsec-policy@vpnc.org Subject: IKEv2 selectors for IPsec? Message-Id: <20030626143806.880D316484@wolfe.bbn.com> Date: Thu, 26 Jun 2003 10:38:06 -0400 (EDT) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Folks, What do folks think of making the IPsec (AH/ESP) protocol and SPI an IKEv2 selector? Its use gets into the area of dynamically created policy, e.g., when an end-to-end SA has to traverse intermediate security gateways. The question might be more appropriate for the IP Security Policy WG (is there any progress there or have folks lost interest?). A catch-22 might be that AH is not currently treated as an "upper layer protocol", so the processing model might need to be extended a bit. That in turn leads to the question of whether folks see any advantage to having IPv6 extension headers -- fragmentation header, routing header, jumbogram, destination options (and maybe Option Type), be selectors. One might argue that they are useful for filtering (access control) but not not useful as items that would select a policy action -- i.e., IPsec should use them but there is no need for IKEv2 negotiation. Charlie From owner-ipsec@lists.tislabs.com Thu Jun 26 08:12:55 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QFCsrb056619; Thu, 26 Jun 2003 08:12:54 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA18251 Thu, 26 Jun 2003 10:30:45 -0400 (EDT) From: "Jesse Alpert" To: "'Joshua Graessley'" Cc: , "'Tero Kivinen'" Subject: RE: Question about draft-ietf-ipsec-nat-t-ike-06.txt. Date: Thu, 26 Jun 2003 17:37:15 +0300 Message-ID: <005c01c33bf0$70b9f210$7b2e1dc2@jesse> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook CWS, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Thanks for your reply, but I was referring to the phase 2 negotiation (where NAT-OA payloads are used). I understand the phase1 negotiation using NAT-D payloads. My question is: Given that the sender may not know his own IP address, the draft specifies that in phase 1 he should send multiple NAT-D payloads corresponding to all of his possible IP addresses. - What is the sender supposed to do in phase 2 in this case. What address should he specify in his NAT-OA payload. (Is there a relation between the NAT-OA content and the Quick Mode ID payload?) Thanks again, Jesse -----Original Message----- From: owner-ipsec@lists.tislabs.com [mailto:owner-ipsec@lists.tislabs.com]On Behalf Of Joshua Graessley Sent: Tuesday, June 24, 2003 11:16 PM To: Jesse Alpert Cc: ipsec@lists.tislabs.com; 'Tero Kivinen' Subject: Re: Question about draft-ietf-ipsec-nat-t-ike-06.txt. On Tuesday, June 24, 2003, at 10:12, Jesse Alpert wrote: > Hi, > > In section 3.2 of the nat-t draft (version 06) it says: > "If the sender of the packet does not know his own IP address ... > he can include multiple ..." > > But in section 5.2. - Sending the original source and destination > addresses, > there is no discussion about this problem. > > Question: If the sender of the packet does not know his own IP address > what > address is he supposed to put in his NAT-OA payload? > > What am I missing? I believe this is done to handle the case where a multihomed host may send from a number of addresses. The IKE implementation may not know which address will be used to send the packet, so it may include a nat detection payload for each address. When the packet is received, if none of the nat detection payloads match the address the packet was from, then a NAT is there. The sender must know the possible IP addresses. It may not know the specific address that will be picked by the stack. -josh From owner-ipsec@lists.tislabs.com Thu Jun 26 09:00:22 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QG0Mrb058309; Thu, 26 Jun 2003 09:00:22 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA18544 Thu, 26 Jun 2003 11:06:33 -0400 (EDT) Message-Id: <5.2.0.9.0.20030626101831.00a96bb0@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 26 Jun 2003 11:04:57 -0400 To: Stephen Kent , ipsec@lists.tislabs.com From: Mark Duffy Subject: Re: QoS selectors (was LAST CALL: IKE) In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, I would say that your analysis is basically correct, by my understanding. I would argue that in tunnel mode it is basically a local matter for the sender how it wants to initialize the DiffServ bits in the outer header. It might be "set to k" or "copy from inner" but could also be anything else. So the cases to be considered might be a somewhat different set than you have below but the important points are the same. I do not see a need however for the receiver to know exactly what the sender is doing or to know which DiffServ bits to expect on a given SA. I also think there might be significant difficulties in trying to negotiate DiffServ whatevers (DSCPs or PHB-IDs) as selectors in the traditional sense (described in my earlier email in this thread). So I would opt for letting the sender make a local choice which SA to send on, and all the receiver needs to do is support multiple "redundant" SAs. I added 3 comments in the message below. --Mark At 07:42 PM 6/25/2003 -0400, Stephen Kent wrote: >Several folks have asked for the ability to place traffic with different >TOS values on different SAs, which requires that the TOS field (IPv4) and >the flow spec field (IPv6) be useable as selectors. If we agree to add >this feature, we need the ability to negotiate this in IKE. What I meant >to say is closer to what David referred to in his message, i.e., I would >anticipate a sender using the 6-bit DS field as an additional selector >value (not the ECN bits). I don't think this is affected by the question >of whether the interpretatioon of these bits is uniform across ISPs. The >concern is that if these bits really do have an affect on the order of >delivery of traffic, then putting different classes of traffic into the >same SA has the potential to cause a non-trivial percentage of the (lower >priority) traffic to be rejected due to receiver window mismatches. Now >this is not a problem if the bits are inside a tunnel and NOT propagated >to the outer header, but then they are not helping out during transit >across unprotected nets. I admit to not being familiar with PHIBs, so I'm >not sure what the issues are there. I'm also open to suggestions from IPv6 >experts about what to do there, for flows. > >Mark & Radia suggest that we don't need this facility to be negotiated. I >didn;'t understand the arguments until I worked my way through the cases. >Now I think I understand the arguments, and basically agree. Let me try >to examine the relevant cases: > >1. traffic with varying DiffServ bits mapped to one tunnel mode SA, but >not copied to the outer header > - because the network between the IPsec devices will not see > per-packet markings, there would be no addition reordering influence and > thus no motivation for separate SAs, hence no need for using these bist > as selectors > >2. traffic with varying DiffServ bits mapped to one tunnel mode SA and >copied to the outer header > - this is the obvious case where more significant reordering by > the net between the IPsec devices might cause problems (undesirable > receiver discards due to receive window mismatches) and what motivated > the suggestion to create different SAs for each class of traffic. > >3. traffic with varying DiffServ bits mapped to tunnel mode SAs using >these bits as selector values, and the bits are copied to the outer header >even if the nets between the IPsec devices modify the values in the outer >header, this would not affect the inner header values and so I think would >work as desired. however, it is correct that this could be done >unilaterally by the sender using selectors but not telling the reeciver, >and still have this work for an SA, unidirectionally. What we would loose >is the ability to tell the receiver what we are doing, or not doing, and >thus trigger the reciprocal behavior by the responder, if appropriate. I don't think any reciprocal behavior is needed. Each sender can do its own thing with regard to making sure the desired number of SAa are present, and deciding which packets to send on which SAs. This may offend some by its lack of symmetry but then the set of DiffServ values flowing in the two directions may not even be symmetrical in the first place. >4. traffic with varying DiffServ bits mapped to one transport mode SA > - as in case 2, the traffic has an increased opportunity to be > delivered out of order, causing problems at the receiver. again, this > motivates using these bits to select different SAs at the sender. > >5. traffic with varying DiffServ bits mapped to transport mode SAs using >these bits as selector values if the nets between the IPsec devices >modifies the bits, we would have a problem when we tried to match the bits >against the selectors at the receiver. if the sender maps the traffic to >different SAs, using selectors, but does not tell the receiver, then there >would be no problems with mismatches in the SPD checks at the receiver. >so, I guess I would agree there here too this could be done by the sender >unilaterally and the effect would be OK. These mismatches in SPD checks at the reciever could be prevented by negotiating PHB-IDs (globally meaningful) instead of DiffServ codepoints, but then that would break case 3 :-) >So, what this seems to suggest is that there is a good use for DiffServ >bits (or PHIBs, or whatever) as selectors, but that if one uses them, one >need not tell the receiver. Is that right? I think that is right (but I wouldn't call them selectors then). I would just say that to avoid sequence number problems with packets reordered by the DiffServ network "the sender SHOULD use separate SAs to send packets whose DiffServ codepoints (in the outermost IP header) place them in different Ordered Aggregates [RFC 3260]" Keep it simple! >Steve From owner-ipsec@lists.tislabs.com Thu Jun 26 09:47:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QGlSrb059536; Thu, 26 Jun 2003 09:47:28 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19055 Thu, 26 Jun 2003 12:05:35 -0400 (EDT) Message-ID: <3EFB1BD2.4020609@airespace.com> Date: Thu, 26 Jun 2003 09:14:10 -0700 From: "Scott G. Kelly" Organization: Airespace User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: itojun@iijlab.net CC: sommerfeld@east.sun.com, Stephen Kent , ipsec@lists.tislabs.com Subject: Re: IKE negotiation for ICMP message type selectors References: <20030626025313.0405A9B@coconut.itojun.org> X-Enigmail-Version: 0.75.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jun 2003 16:11:29.0135 (UTC) FILETIME=[99E767F0:01C33BFD] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I agree. We need ports for tcp/udp, and (at minimum) type/code for icmp, but we cannot always be sure that two 16/32-bit fields will suffice for all future (or even current) protocols. One way would be to come up with a general protocol sub-selector field which is implicitly defined by the protocol in question, and make it large enough to hold what we expect to be enough demuxing info for any forseeable protocol (sounds prone to error). Another way would be to specify explicit selector types for tcp/udp, icmp, and whatever else comes up. If we only add icmp to the current spec, then it would be nice to do so in an open-ended way so we can easily add new protocol sub-selectors later. Scott itojun@iijlab.net wrote: |>>For example, we've had discussion on the list about using ICMP |>>message type fields in lieu of port fields, when ICMP was the |>>payload. |>> |>>What do people think, and why? |> |>Long overdue. |> |>Particularly important for IKE and IPv6 (as, pending introduction of |>some facility to secure Neighbor Discovery) you likely want ND traffic |>in clear while other ICMPv6 traffic is protected. | | | we will need to do this every time new protocol becomes available. | i guess we should make the concept of "selector" more generic. | (for KAME implementation i'm thinking of switching to BPF-based policy) | | itojun -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE++xvRMtIdhO0pgN4RAsmYAKDi9LGFkP2pRFj0PKILdc8WKudzYgCeLulZ BTQFmovu2BOGX+Tm5WfwkHM= =rLxa -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Jun 26 10:09:04 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QH93rb060924; Thu, 26 Jun 2003 10:09:03 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19311 Thu, 26 Jun 2003 12:29:32 -0400 (EDT) Date: Thu, 26 Jun 2003 12:35:18 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: IKE negotiation for fragmentation controls in IPsec In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Wed, 25 Jun 2003, Stephen Kent wrote: > As we revise 2401, we may choose to allow (or even recommend) > plaintext (pre-IPsec encapsulation) fragmentation. If so, we need to > be able to negotiate use of this capability on a per-SA basis, and to > notify the receiver that NO ciphertext fragments should be accepted > for this SA, because none will be sent by this transmitter... There is a problem here, in that fragmentation is not entirely under the control of the transmitter. Intervening gateways may fragment the encrypted packets. This situation can change dynamically, as routing changes, and the transmitter can't count on getting feedback about it, because many firewalls apparently block ICMP Fragmentation Required messages. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Jun 26 10:10:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QHADrb060978; Thu, 26 Jun 2003 10:10:13 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19297 Thu, 26 Jun 2003 12:27:20 -0400 (EDT) Message-ID: <3EFB20EB.3080005@airespace.com> Date: Thu, 26 Jun 2003 09:35:55 -0700 From: "Scott G. Kelly" Organization: Airespace User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Charles Lynn CC: ipsec@lists.tislabs.com, ipsec-policy@vpnc.org Subject: Re: IKEv2 selectors for IPsec? References: <20030626143806.880D316484@wolfe.bbn.com> X-Enigmail-Version: 0.75.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jun 2003 16:33:14.0286 (UTC) FILETIME=[A3D5A4E0:01C33C00] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Charles Lynn wrote: | Folks, | | What do folks think of making the IPsec (AH/ESP) protocol and SPI an | IKEv2 selector? Agree - this has its uses. We need a more general model for protocol selectors. Scott -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE++yDrMtIdhO0pgN4RArXxAJ463XU3vTfDkoXRqoKF95hnHdLDiACg45G/ F/Mss9G0g+ggnuQcLIUtUVU= =G+64 -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Thu Jun 26 10:33:50 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QHXnrb063127; Thu, 26 Jun 2003 10:33:49 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA19542 Thu, 26 Jun 2003 12:50:05 -0400 (EDT) Message-Id: <200306261655.h5QGtuof070900@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Charles Lynn cc: Stephen Kent , Bill Sommerfeld , Vijay Devarapalli , itojun@iijlab.net, Jari Arkko , ipsec@lists.tislabs.com Subject: Re: IKE negotiation for ICMP message type selectors In-reply-to: Your message of Thu, 26 Jun 2003 10:18:10 EDT. <20030626141810.0027816484@wolfe.bbn.com> Date: Thu, 26 Jun 2003 18:55:56 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: > For example, we've had discussion on the list about using ICMP > message type fields in lieu of port fields, when ICMP was the payload. I agree that the type and code fields need to be selectors. The next question is whether there needs to be "sub-selectors" for the => far too complex. IMHO this is like trying to extend selectors to encapsulated traffic: reasonable for a firewall *only*. fields a packet that, e.g., caused an error. I think that this issue is related to whether ICMP messages MUST/SHOULD/MAY be sent in the SA of the packet that caused the error, or whether the ICMP should cause its own SA to be created. (If the answer is MUST in the SA of the packet that caused the error, then the selectors are "implicit"; if there MUST be a separate SA, then, I think, IKE would have to make them explicit. Do folks agree?) If the answer is SHOULD/MAY, then I think that the sub-selectors would be needed. What do the folks who have said "agree" to ICMP type and code think? => add me in the list (in case some people disagree :-) itojun commented... > we will need to do this every time new protocol becomes available. > i guess we should make the concept of "selector" more generic. > (for KAME implementation i'm thinking of switching to BPF-based policy) I agree that some extensible mechanism is needed. Selectors form a tree (or maybe lattice if one wants to simplify "reuse"). I do not think that this is a problem that the current IPsec working group will have as a work item, and not before IKEv2 advances. Obvious issues are "complexity" of the packet parsing/description language (of which BPF is an example), and whether the concept or implementations introduce unacceptable risks. => OpenBSD has an unified filtering/classifying stuff which can (should!) be used for QoS (aka ALTQ), IPsec and firewall. Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Thu Jun 26 11:17:42 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QIHgrb066834; Thu, 26 Jun 2003 11:17:42 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA19839 Thu, 26 Jun 2003 13:32:13 -0400 (EDT) Message-ID: <090701c33c09$7ebd6720$0202a8c0@SindhuSriha> Reply-To: "Srinivasa Rao Addepalli" From: "Srinivasa Rao Addepalli" To: , "Stephen Kent" References: Subject: Re: IKE negotiation for fragmentation controls in IPsec Date: Thu, 26 Jun 2003 10:36:36 -0700 Organization: Intoto Inc. 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Imagine this scenario: -----------SecurityGW1----------Router1----Router2------------SecurityGW2--- As I understand from the description, once SG1 and SG2 negotiate and come to understanding, then SG2 can drop fragmented secured packets. But the routers in between can fragment the packets. To avoid this situation, SG1 has to set the DF bit and PMTU processing should be MUST in this case. Is it right to assume that all core and edge routers/firewalls in Internet and enterprise support passing the ICMP error messages? I keep hearing that most (may be some) firewalls can be explicitly configured to discard ICMP error messages. Thanks Srini Intoto Inc. Enabling Security Infrastructure 3160, De La Cruz Blvd #100 Santa Clara, CA 95054 www.intotoinc.com ----- Original Message ----- From: "Stephen Kent" To: Sent: Wednesday, June 25, 2003 3:46 PM Subject: IKE negotiation for fragmentation controls in IPsec > > A few folks have observed that the current processing requirements > for AH and ESP mandate ciphertext (post IPsec encapsulation) > fragmentation and that this poses DoS vulnerabilities for receivers. > (An attacker can create what appear to be legitimate, non-initial > fragments and cause reassembly problems for the receiver). > > As we revise 2401, we may choose to allow (or even recommend) > plaintext (pre-IPsec encapsulation) fragmentation. If so, we need to > be able to negotiate use of this capability on a per-SA basis, and to > notify the receiver that NO ciphertext fragments should be accepted > for this SA, because none will be sent by this transmitter. So, I > suggest that we add a paylod to IKE to allow an initiator to indicate > the intent to never send ciphertext fragments. The responder can take > advantage of this info to better protect itself, or it can ignore the > info, but it needs to be told to be able to take advantage of the > capability. I would also like to see the responder be able to notify > the initiator of its intent re the companion (reverse) SA, if > appropriate. > > A logical (but admittedly separable) companion to this feature is to > allow the initiator to request the responder to accept fragments on > an SA where port fields are used as selectors. The issue here is that > a host may send fragments to an IPsec device that requires port field > examination for the SA to which the fragments will be mapped. It > seems reasonably safe to allow fragments (with a suitable, minimum > offset) to pass through such as SA, with only the initial fragment > having the port fields examined. This is a separate negotiation > because the fragments arise from hosts behind the IPsec device, but > it is related, because if one fragments at the sending IPsec device, > it would be nice to be able to use this feature to allow the receiver > to pass on fragments, not reassemble them (in the case of a SG). > > > Steve From owner-ipsec@lists.tislabs.com Thu Jun 26 11:36:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QIa9rb067304; Thu, 26 Jun 2003 11:36:10 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA20065 Thu, 26 Jun 2003 13:53:15 -0400 (EDT) Message-ID: <090b01c33c0c$a709b050$0202a8c0@SindhuSriha> Reply-To: "Srinivasa Rao Addepalli" From: "Srinivasa Rao Addepalli" To: , "Stephen Kent" References: Subject: Re: IKE negotiation for fragmentation controls in IPsec Date: Thu, 26 Jun 2003 10:59:13 -0700 Organization: Intoto Inc. 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Steve, Negotiation on SA basis: Assuming that intermediate router fragmentation problem is solved, does it require negotiation on SA basis? I feel, it can be on peer basis. Either it can be set as local configuration on peer basis or capabilities of the peers can be exchanged using Vendor ID attributes. Port Selector information: I did not understand all the details you mentioned. I feel, there is no need for any IKE negotiation for tunnel mode sessions. I try to list down the steps. Outbound Processing steps: - Reassemble the packet (Packet coming from trusted network). - Search for outbound SPD and corresponding SA Bundle to use. - (New step, based on local configuration): * Determine the packet size increase (based on SAs, Padding, outer IP header etc.. ) * Get the PMTU * Fragment the packet so that there is no fragmentation is required after doing ciphering and adding SA headers etc.. - Pass the fragments through outbound SA processing. - Send out the secured packets. Inbound Processing steps: (Assuming that the local configuration requires that all secured packets from a particular peer have to be complete packets ) - (New Step): Check for Destination IP and Protocol field from IP header. If it indicates AH/ESP or Destination IP is local SG IP address and if it is not full packet, discard the packet. - Pass the packet through the inbound SA processing. - Reassemble the clear packets - Check against the inbound policies. Based on above steps, I feel there is no need for IKE negotiation for this. Am I missing anything? Thanks Srini Intoto Inc. Enabling Security Infrastructure 3160, De La Cruz Blvd #100 Santa Clara, CA 95054 www.intotoinc.com ----- Original Message ----- From: "Stephen Kent" To: Sent: Wednesday, June 25, 2003 3:46 PM Subject: IKE negotiation for fragmentation controls in IPsec > > A few folks have observed that the current processing requirements > for AH and ESP mandate ciphertext (post IPsec encapsulation) > fragmentation and that this poses DoS vulnerabilities for receivers. > (An attacker can create what appear to be legitimate, non-initial > fragments and cause reassembly problems for the receiver). > > As we revise 2401, we may choose to allow (or even recommend) > plaintext (pre-IPsec encapsulation) fragmentation. If so, we need to > be able to negotiate use of this capability on a per-SA basis, and to > notify the receiver that NO ciphertext fragments should be accepted > for this SA, because none will be sent by this transmitter. So, I > suggest that we add a paylod to IKE to allow an initiator to indicate > the intent to never send ciphertext fragments. The responder can take > advantage of this info to better protect itself, or it can ignore the > info, but it needs to be told to be able to take advantage of the > capability. I would also like to see the responder be able to notify > the initiator of its intent re the companion (reverse) SA, if > appropriate. > > A logical (but admittedly separable) companion to this feature is to > allow the initiator to request the responder to accept fragments on > an SA where port fields are used as selectors. The issue here is that > a host may send fragments to an IPsec device that requires port field > examination for the SA to which the fragments will be mapped. It > seems reasonably safe to allow fragments (with a suitable, minimum > offset) to pass through such as SA, with only the initial fragment > having the port fields examined. This is a separate negotiation > because the fragments arise from hosts behind the IPsec device, but > it is related, because if one fragments at the sending IPsec device, > it would be nice to be able to use this feature to allow the receiver > to pass on fragments, not reassemble them (in the case of a SG). > > > Steve From owner-ipsec@lists.tislabs.com Thu Jun 26 11:44:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QIiWrb067567; Thu, 26 Jun 2003 11:44:32 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA20202 Thu, 26 Jun 2003 14:08:45 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 26 Jun 2003 11:15:00 -0700 To: ipsec@lists.tislabs.com From: Paul Hoffman / VPNC Subject: Suggested wording for weak key lengths in IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Greetings again. Now that the WG last call is finished , it seems like having proposed wording might help resolve some of the open issues on Angelos' issue list. (You all are watching , yes?) The issue that has the most issue numbers is the deprecating DES and weak keys issue in the ipsec-ikev2-algorithms document. To resolve it, I propose the following changes for section 4.1.3: - ENCR_DES_IV64 and ENCR_DES be listed as "SHOULD NOT" - A sentence be added to the end of that section as a free-standing paragraph that says: "Implementations that use algorithms with variable-length keys SHOULD NOT use keys that are weaker than the effective strength of ENCR_3DES." If we do this, we can eliminate the definition of "SHOULD-", because it was only used for the two DES algorithms. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Jun 26 12:10:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QJASrb068170; Thu, 26 Jun 2003 12:10:28 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA20509 Thu, 26 Jun 2003 14:34:38 -0400 (EDT) Message-ID: <095201c33c12$6d2ed710$0202a8c0@SindhuSriha> Reply-To: "Srinivasa Rao Addepalli" From: "Srinivasa Rao Addepalli" To: , "Stephen Kent" References: Subject: Re: IKE negotiation for ICMP message type selectors Date: Thu, 26 Jun 2003 11:40:33 -0700 Organization: Intoto Inc. 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi, Yes. ICMP message type as one of the selectors is very helpful. ICMP is not only used to find out the host liveness, but also for mobile agent discovery, registration etc. and admins would not want to secure all kinds of ICMP packets. In general, we seem to be finding the requirements that selectors space needs to be increased. ICMP message type is one and TOS bits for QoS. I feel that we should have some extensible mechanism such that when we add new selectors to the protocol (assigned numbers), protocol implementation need not change. Also, the end users can choose their own selector space that is agreed upon between two SG administrators. For example, there may be a requirement where different SA Bundles are required for different RPC program numbers. One way to achieve is to define selectors by offset into the protocol headers, length and mask. Srini Intoto Inc. Enabling Security Infrastructure 3160, De La Cruz Blvd #100 Santa Clara, CA 95054 www.intotoinc.com ----- Original Message ----- From: "Stephen Kent" To: Sent: Wednesday, June 25, 2003 4:43 PM Subject: IKE negotiation for ICMP message type selectors > One last selector negotiation suggestion: > > We ought to decide now if there are other fields we want to specify > as selectors AND that need to be negotiated (unlike the DiffServ > bits). For example, we've had discussion on the list about using ICMP > message type fields in lieu of port fields, when ICMP was the payload. > > What do people think, and why? > > Steve > > From owner-ipsec@lists.tislabs.com Thu Jun 26 12:13:54 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QJDsrb068353; Thu, 26 Jun 2003 12:13:54 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA20533 Thu, 26 Jun 2003 14:36:32 -0400 (EDT) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0564CE31@corpmx14.us.dg.com> To: kent@bbn.com, ipsec@lists.tislabs.com Subject: RE: QoS selectors (was LAST CALL: IKE) Date: Thu, 26 Jun 2003 14:33:34 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, > Several folks have asked for the ability to place traffic with > different TOS values on different SAs, which requires that the TOS > field (IPv4) and the flow spec field (IPv6) be useable as selectors. That includes me - see Section 4.1 of RFC 2983. > If we agree to add this feature, we need the ability to negotiate > this in IKE. What I meant to say is closer to what David referred to > in his message, i.e., I would anticipate a sender using the 6-bit DS > field as an additional selector value (not the ECN bits). I don't > think this is affected by the question of whether the interpretation > of these bits is uniform across ISPs. The concern is that if these > bits really do have an affect on the order of delivery of traffic, > then putting different classes of traffic into the same SA has the > potential to cause a non-trivial percentage of the (lower priority) > traffic to be rejected due to receiver window mismatches. Use of DSCPs (6-bit DS Field) as selectors is fine as long as the receiver is not expected to be able to understand/check/verify how the sender assigned traffic to the SAs. That does appear to be the case here (receiver doesn't have to check how sender assigns traffic to SAs). One note for selector design - with the exception of "all", masks or wildcards are not to be used; there will be cases in which multiple DSCPs are needed in a single selector (e.g., when indicating different levels of drop preference) - in all such cases, an explicit list is the right approach. This is based on the diffserv architecture, as specified/described in RFCs 2474/2475. > Now this is > not a problem if the bits are inside a tunnel and NOT propagated to > the outer header, but then they are not helping out during transit > across unprotected nets. I admit to not being familiar with PHIBs, so > I'm not sure what the issues are there. I'm also open to suggestions > from IPv6 experts about what to do there, for flows. PHBs are only relevant to this discussion if there's a need for both ends to understand the QoS-based SA selection, as their purpose is t provide a network domain-independent representation of traffic QoS classes. > Mark & Radia suggest that we don't need this facility to be > negotiated. I didn;'t understand the arguments until I worked my way > through the cases. Now I think I understand the arguments, and > basically agree. Let me try to examine the relevant cases: [... Analysis snipped, as I basically agree ...] > So, what this seems to suggest is that there is a good use for > DiffServ bits (or PHIBs, or whatever) as selectors, but that if one > uses them, one need not tell the receiver. Is that right? That sounds good to me. I strongly prefer to keep IKE out of the QoS negotiation business. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ipsec@lists.tislabs.com Thu Jun 26 12:18:34 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QJIXrb068857; Thu, 26 Jun 2003 12:18:33 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA20665 Thu, 26 Jun 2003 14:42:51 -0400 (EDT) Date: Thu, 26 Jun 2003 14:48:36 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: Suggested wording for weak key lengths in IKEv2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 26 Jun 2003, Paul Hoffman / VPNC wrote: > - ENCR_DES_IV64 and ENCR_DES be listed as "SHOULD NOT" > - A sentence be added to the end of that section as a free-standing > paragraph that says: "Implementations that use algorithms with > variable-length keys SHOULD NOT use keys that are weaker than the > effective strength of ENCR_3DES." This sounds good to me, except that I would be tempted to pin down the latter more by adding "(112 bits)" at the end. Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Jun 26 12:41:32 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QJfVrb069315; Thu, 26 Jun 2003 12:41:31 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA21048 Thu, 26 Jun 2003 15:05:41 -0400 (EDT) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0564CE32@corpmx14.us.dg.com> To: mduffy@quarrytech.com, ipsec@lists.tislabs.com Subject: RE: QoS selectors (was LAST CALL: IKE) Date: Thu, 26 Jun 2003 15:02:38 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Mark, > I would argue that in tunnel mode it is basically a local matter for the > sender how it wants to initialize the DiffServ bits in the outer > header. It might be "set to k" or "copy from inner" but could also be > anything else. So the cases to be considered might be a somewhat different > set than you have below but the important points are the same. Yes, RFC 2983 contains more on this topic. > I do not see a need however for the receiver to know exactly what the > sender is doing or to know which DiffServ bits to expect on a given SA. I agree, and in particular this is the basic response to Charles Lynn's concern: Consider the receiver. If the receiver has the same "policy" as the sender, then it will also want to have multiple SAs. Since, to its knowledge, none of the existing SAs from the initiator have DiffServ markings, and it wants to use them, then it will setup its own SAs back to the original initiator. The DiffServ marking policy can be different in each direction, even across a common set of paired SAs. There's nothing wrong with CREATE_CHILD_SA setting up an SA that is used to carry routing traffic (e.g., Class Selector/IP Precedence 6) in one direction and best effort traffic in the reverse as long as the routing traffic in the reverse direction doesn't get mixed with the best effort traffic on the same SA. > I also think there might be significant difficulties in trying to negotiate > DiffServ whatevers (DSCPs or PHB-IDs) as selectors in the traditional sense > (described in my earlier email in this thread). So I would opt for letting > the sender make a local choice which SA to send on, and all the receiver > needs to do is support multiple "redundant" SAs. I completely agree. IKEv2 has enough challenges; there's no need to add QoS negotiation. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ---------------------------------------------------- From owner-ipsec@lists.tislabs.com Thu Jun 26 13:33:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QKXirb071771; Thu, 26 Jun 2003 13:33:45 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA21460 Thu, 26 Jun 2003 15:50:50 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16123.20476.974084.413863@pkoning.dev.equallogic.com> Date: Thu, 26 Jun 2003 15:56:44 -0400 From: Paul Koning To: paul.hoffman@vpnc.org Cc: ipsec@lists.tislabs.com Subject: Re: Suggested wording for weak key lengths in IKEv2 References: X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Paul" == Paul Hoffman > writes: Paul> The issue that has the most issue numbers is the deprecating Paul> DES and weak keys issue in the ipsec-ikev2-algorithms Paul> document. To resolve it, I propose the following changes for Paul> section 4.1.3: Paul> - ENCR_DES_IV64 and ENCR_DES be listed as "SHOULD NOT" Great. Paul> - A sentence be added to the end of that section as a Paul> free-standing paragraph that says: "Implementations that use Paul> algorithms with variable-length keys SHOULD NOT use keys that Paul> are weaker than the effective strength of ENCR_3DES." How about "... strength of ENCR_3DES (112 bits)." Otherwise it might cause confusion, because some will think that this rules out 128-bit keys, which isn't the intent. paul From owner-ipsec@lists.tislabs.com Thu Jun 26 13:36:04 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QKa3rb072271; Thu, 26 Jun 2003 13:36:03 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA21530 Thu, 26 Jun 2003 15:58:53 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: <16123.20476.974084.413863@pkoning.dev.equallogic.com> References: <16123.20476.974084.413863@pkoning.dev.equallogic.com> X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 26 Jun 2003 13:00:55 -0700 To: Paul Koning From: Paul Hoffman / VPNC Subject: Re: Suggested wording for weak key lengths in IKEv2 Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 3:56 PM -0400 6/26/03, Paul Koning wrote: > Paul> - A sentence be added to the end of that section as a > Paul> free-standing paragraph that says: "Implementations that use > Paul> algorithms with variable-length keys SHOULD NOT use keys that > Paul> are weaker than the effective strength of ENCR_3DES." > >How about "... strength of ENCR_3DES (112 bits)." Otherwise it might >cause confusion, because some will think that this rules out 128-bit >keys, which isn't the intent. As noted on the list, not everyone agrees that the effective strength of TripleDES is 112 bits, given differing values for amount of RAM and so on. I think it is better to just leave it as "effective strength" and let folks decide what that means. If anyone reads the sentence and think that it means that AES-128 (which is listed as a SHOULD) is weaker than TripleDES, well, I don't think I would call them an implementer that we need to worry about... --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Jun 26 14:10:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QLA3rb073954; Thu, 26 Jun 2003 14:10:03 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA21972 Thu, 26 Jun 2003 16:33:12 -0400 (EDT) Date: Thu, 26 Jun 2003 16:38:57 -0400 (EDT) From: Henry Spencer To: IP Security List Subject: Re: Suggested wording for weak key lengths in IKEv2 In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-ipsec@lists.tislabs.com Precedence: bulk On Thu, 26 Jun 2003, Paul Hoffman / VPNC wrote: > As noted on the list, not everyone agrees that the effective strength > of TripleDES is 112 bits, given differing values for amount of RAM > and so on. I think it is better to just leave it as "effective > strength" and let folks decide what that means. NO NO NO NO NO! That means we have a standard which means different things to different people, and nobody can tell which interpretation is right! This is TOTALLY UNACCEPTABLE. If the problem is that people don't agree on 3DES's "effective strength", then get rid of those words, and say something people can understand and agree on, like "minimum 100 bits". Henry Spencer henry@spsystems.net From owner-ipsec@lists.tislabs.com Thu Jun 26 14:39:12 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QLdBrb075693; Thu, 26 Jun 2003 14:39:11 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA22195 Thu, 26 Jun 2003 17:03:13 -0400 (EDT) Message-Id: <5.2.0.9.0.20030626165534.05649cf0@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 26 Jun 2003 17:08:30 -0400 To: Black_David@emc.com, kent@bbn.com, ipsec@lists.tislabs.com From: Mark Duffy Subject: RE: QoS selectors (was LAST CALL: IKE) In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564CE31@corpmx14.us.dg.co m> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In my understanding, everything that we today call "selectors" are negotiated in IKE, used at the IPsec sender to decide how to send packets, and used at the IPsec receiver to decide whether to accept packets. If we agree that it is a local matter for the sender to decide which packets to send on which of n "redundant" SAs (whether this decision is based on DiffServ codepoint/PHB or whatever) then I would propose we don't call whatever rules govern that selectors. I think to do so would create confusion vs the exisiting concept of selectors. Moreover, if it is a local matter at the sender I don't see any need to standardize it at all. Let's just say you are allowed to have "redundant" SAs (with the same properties) and the sender can use whichever of those SAs it wants to to send any given packet. For the current discussion that decision would be to send packets of different Ordered Aggregates [RFC 3260] on different SAs but it could be for any other reason as well. (Load balancing across encryption hardware units, perhaps?) --Mark From owner-ipsec@lists.tislabs.com Thu Jun 26 14:40:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QLeirb075843; Thu, 26 Jun 2003 14:40:45 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA22155 Thu, 26 Jun 2003 16:58:04 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16123.24479.325439.126662@thomasm-u1.cisco.com> Date: Thu, 26 Jun 2003 14:03:27 -0700 (PDT) To: Black_David@emc.com Cc: kent@bbn.com, ipsec@lists.tislabs.com Subject: RE: QoS selectors (was LAST CALL: IKE) In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564CE31@corpmx14.us.dg.com> References: <277DD60FB639D511AC0400B0D068B71E0564CE31@corpmx14.us.dg.com> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Just as a general note, the ip6 flowlabel is not akin to the DSCP. The flowlabel is much more akin to the 5-tuple. I'm not sure that it's a good idea to select flows based on it. Or at least via IKE right now. What is the downside to deferring saying anything about the flowlabel here? If it must be done now, it would be a good idea to run this all by the authors... Mike Black_David@emc.com writes: > Steve, > > > Several folks have asked for the ability to place traffic with > > different TOS values on different SAs, which requires that the TOS > > field (IPv4) and the flow spec field (IPv6) be useable as selectors. > > That includes me - see Section 4.1 of RFC 2983. > > > If we agree to add this feature, we need the ability to negotiate > > this in IKE. What I meant to say is closer to what David referred to > > in his message, i.e., I would anticipate a sender using the 6-bit DS > > field as an additional selector value (not the ECN bits). I don't > > think this is affected by the question of whether the interpretation > > of these bits is uniform across ISPs. The concern is that if these > > bits really do have an affect on the order of delivery of traffic, > > then putting different classes of traffic into the same SA has the > > potential to cause a non-trivial percentage of the (lower priority) > > traffic to be rejected due to receiver window mismatches. > > Use of DSCPs (6-bit DS Field) as selectors is fine as long as the > receiver is not expected to be able to understand/check/verify how > the sender assigned traffic to the SAs. That does appear to be > the case here (receiver doesn't have to check how sender assigns > traffic to SAs). > > One note for selector design - with the exception of "all", masks > or wildcards are not to be used; there will be cases in which multiple > DSCPs are needed in a single selector (e.g., when indicating different > levels of drop preference) - in all such cases, an explicit list > is the right approach. This is based on the diffserv architecture, > as specified/described in RFCs 2474/2475. > > > Now this is > > not a problem if the bits are inside a tunnel and NOT propagated to > > the outer header, but then they are not helping out during transit > > across unprotected nets. I admit to not being familiar with PHIBs, so > > I'm not sure what the issues are there. I'm also open to suggestions > > from IPv6 experts about what to do there, for flows. > > PHBs are only relevant to this discussion if there's a need for both > ends to understand the QoS-based SA selection, as their purpose is t > provide a network domain-independent representation of traffic QoS classes. > > > Mark & Radia suggest that we don't need this facility to be > > negotiated. I didn;'t understand the arguments until I worked my way > > through the cases. Now I think I understand the arguments, and > > basically agree. Let me try to examine the relevant cases: > > [... Analysis snipped, as I basically agree ...] > > > So, what this seems to suggest is that there is a good use for > > DiffServ bits (or PHIBs, or whatever) as selectors, but that if one > > uses them, one need not tell the receiver. Is that right? > > That sounds good to me. I strongly prefer to keep IKE > out of the QoS negotiation business. > > Thanks, > --David > ---------------------------------------------------- > David L. Black, Senior Technologist > EMC Corporation, 176 South St., Hopkinton, MA 01748 > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > black_david@emc.com Mobile: +1 (978) 394-7754 > ---------------------------------------------------- From owner-ipsec@lists.tislabs.com Thu Jun 26 15:20:49 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QMKmrb077392; Thu, 26 Jun 2003 15:20:48 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA22516 Thu, 26 Jun 2003 17:46:06 -0400 (EDT) Message-Id: <200306262152.h5QLqUq3007809@thunk.east.sun.com> From: Bill Sommerfeld To: Henry Spencer cc: IP Security List Subject: Re: Suggested wording for weak key lengths in IKEv2 In-Reply-To: Your message of "Thu, 26 Jun 2003 16:38:57 EDT." Reply-to: sommerfeld@east.sun.com Date: Thu, 26 Jun 2003 17:52:30 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > NO NO NO NO NO! That means we have a standard which means different > things to different people, and nobody can tell which interpretation is > right! This is TOTALLY UNACCEPTABLE. > > If the problem is that people don't agree on 3DES's "effective strength", > then get rid of those words, and say something people can understand and > agree on, like "minimum 100 bits". Agreed. We know that the key size is an upper bound on effective strength. And it's an objective measure which doesn't change as research evolves. To select an actual value quickly, maybe we should just pick N cryptographers at random, have each suggest a recommended minimum symmetric key bit length and just take the average. ;-) - Bill From owner-ipsec@lists.tislabs.com Thu Jun 26 15:49:47 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QMnlrb077919; Thu, 26 Jun 2003 15:49:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA22732 Thu, 26 Jun 2003 18:14:13 -0400 (EDT) Mime-Version: 1.0 X-Sender: phoffvpnc@mail.vpnc.org Message-Id: In-Reply-To: References: X-Habeas-SWE-1: winter into spring X-Habeas-SWE-2: brightly anticipated X-Habeas-SWE-3: like Habeas SWE (tm) X-Habeas-SWE-4: Copyright 2002 Habeas (tm) X-Habeas-SWE-5: Sender Warranted Email (SWE) (tm). The sender of this X-Habeas-SWE-6: email in exchange for a license for this Habeas X-Habeas-SWE-7: warrant mark warrants that this is a Habeas Compliant X-Habeas-SWE-8: Message (HCM) and not spam. Please report use of this X-Habeas-SWE-9: mark in spam to . Date: Thu, 26 Jun 2003 15:20:38 -0700 To: IP Security List From: Paul Hoffman / VPNC Subject: Re: Suggested wording for weak key lengths in IKEv2 Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 4:38 PM -0400 6/26/03, Henry Spencer wrote: >On Thu, 26 Jun 2003, Paul Hoffman / VPNC wrote: >> As noted on the list, not everyone agrees that the effective strength >> of TripleDES is 112 bits, given differing values for amount of RAM >> and so on. I think it is better to just leave it as "effective >> strength" and let folks decide what that means. > >NO NO NO NO NO! That means we have a standard which means different >things to different people, and nobody can tell which interpretation is >right! This is TOTALLY UNACCEPTABLE. Ah, a return to calm discussion about simple topics. :-) >If the problem is that people don't agree on 3DES's "effective strength", >then get rid of those words, and say something people can understand and >agree on, like "minimum 100 bits". I'm fine with this as well. --Paul Hoffman, Director --VPN Consortium From owner-ipsec@lists.tislabs.com Thu Jun 26 16:00:03 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QN02rb078272; Thu, 26 Jun 2003 16:00:02 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA22835 Thu, 26 Jun 2003 18:25:29 -0400 (EDT) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16123.29754.887914.818656@pkoning.dev.equallogic.com> Date: Thu, 26 Jun 2003 18:31:22 -0400 From: Paul Koning To: paul.hoffman@vpnc.org Cc: ipsec@lists.tislabs.com Subject: Re: Suggested wording for weak key lengths in IKEv2 References: <16123.20476.974084.413863@pkoning.dev.equallogic.com> X-Mailer: VM 7.07 under 21.4 (patch 8) "Honest Recruiter" XEmacs Lucid Sender: owner-ipsec@lists.tislabs.com Precedence: bulk >>>>> "Paul" == Paul Hoffman > writes: Paul> At 3:56 PM -0400 6/26/03, Paul Koning wrote: - A sentence be Paul> added to the end of that section as a free-standing paragraph Paul> that says: "Implementations that use algorithms with Paul> variable-length keys SHOULD NOT use keys that are weaker than Paul> the effective strength of ENCR_3DES." >> How about "... strength of ENCR_3DES (112 bits)." Otherwise it >> might cause confusion, because some will think that this rules out >> 128-bit keys, which isn't the intent. Paul> As noted on the list, not everyone agrees that the effective Paul> strength of TripleDES is 112 bits, given differing values for Paul> amount of RAM and so on. I think it is better to just leave it Paul> as "effective strength" and let folks decide what that means. Paul> If anyone reads the sentence and think that it means that Paul> AES-128 (which is listed as a SHOULD) is weaker than TripleDES, Paul> well, I don't think I would call them an implementer that we Paul> need to worry about... I'm sorry I have to disagree. You seem to assume, or expect, that implementers have significant knowledge of cryptography. That isn't always true, and I don't think it should be a requirement. I mentioned earlier that I don't really like talking about "effective strength" in the first place since it's so much subject to debate and opinion. Can we just talk about raw key lengths? If so, then 128 is a good limit. paul From owner-ipsec@lists.tislabs.com Thu Jun 26 16:06:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QN6irb078423; Thu, 26 Jun 2003 16:06:44 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA22915 Thu, 26 Jun 2003 18:32:20 -0400 (EDT) To: Francis Dupont Cc: Charles Lynn , Stephen Kent , Bill Sommerfeld , Vijay Devarapalli , Jari Arkko , ipsec@lists.tislabs.com In-reply-to: Francis.Dupont's message of Thu, 26 Jun 2003 18:55:56 +0200. <200306261655.h5QGtuof070900@givry.rennes.enst-bretagne.fr> X-Template-Reply-To: itojun@itojun.org X-Template-Return-Receipt-To: itojun@itojun.org X-PGP-Fingerprint: F8 24 B4 2C 8C 98 57 FD 90 5F B4 60 79 54 16 E2 Subject: Re: IKE negotiation for ICMP message type selectors From: itojun@iijlab.net Date: Fri, 27 Jun 2003 07:38:41 +0900 Message-Id: <20030626223841.3F59B9A@coconut.itojun.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > itojun commented... > > we will need to do this every time new protocol becomes available. > > i guess we should make the concept of "selector" more generic. > > (for KAME implementation i'm thinking of switching to BPF-based policy) > > I agree that some extensible mechanism is needed. Selectors form a tree > (or maybe lattice if one wants to simplify "reuse"). I do not think that > this is a problem that the current IPsec working group will have as a > work item, and not before IKEv2 advances. Obvious issues are "complexity" > of the packet parsing/description language (of which BPF is an example), > and whether the concept or implementations introduce unacceptable risks. > >=> OpenBSD has an unified filtering/classifying stuff which can (should!) >be used for QoS (aka ALTQ), IPsec and firewall. actually yesterday i changed my mind and working on PF-based policy lookup. stay tuned (but i need to think about IKE-interaction more... hi, sakane-san!) itojun From owner-ipsec@lists.tislabs.com Thu Jun 26 16:11:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5QNB9rb078528; Thu, 26 Jun 2003 16:11:10 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA22995 Thu, 26 Jun 2003 18:39:05 -0400 (EDT) Message-Id: <5.2.0.9.0.20030626184116.05660d70@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Thu, 26 Jun 2003 18:44:26 -0400 To: Michael Thomas , Black_David@emc.com From: Mark Duffy Subject: RE: QoS selectors (was LAST CALL: IKE) Cc: kent@bbn.com, ipsec@lists.tislabs.com In-Reply-To: <16123.24479.325439.126662@thomasm-u1.cisco.com> References: <277DD60FB639D511AC0400B0D068B71E0564CE31@corpmx14.us.dg.com> <277DD60FB639D511AC0400B0D068B71E0564CE31@corpmx14.us.dg.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Yes, I think for ipv6 we should be talking about the traffic class field, not the flow label. From RFC 2474, Differentiated Services Field, sect. 3: A replacement header field, called the DS field, is defined, which is intended to supersede the existing definitions of the IPv4 TOS octet [RFC791] and the IPv6 Traffic Class octet [IPv6]. Mark At 02:03 PM 6/26/2003 -0700, Michael Thomas wrote: >Just as a general note, the ip6 flowlabel is not >akin to the DSCP. The flowlabel is much more akin >to the 5-tuple. I'm not sure that it's a good idea >to select flows based on it. Or at least via IKE >right now. What is the downside to deferring >saying anything about the flowlabel here? If it >must be done now, it would be a good idea to run >this all by the authors... > > Mike From owner-ipsec@lists.tislabs.com Thu Jun 26 17:30:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5R0Uarb079937; Thu, 26 Jun 2003 17:30:37 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id TAA23771 Thu, 26 Jun 2003 19:53:01 -0400 (EDT) Message-ID: <0a7301c33c3e$e9d4c460$0202a8c0@SindhuSriha> Reply-To: "Srinivasa Rao Addepalli" From: "Srinivasa Rao Addepalli" To: "Francis Dupont" , , "Stephen Kent" References: <200306091606.h59G62of004050@givry.rennes.enst-bretagne.fr> Subject: Re: issue with "per-interface SAD/SPD" Date: Thu, 26 Jun 2003 16:58:58 -0700 Organization: Intoto Inc. 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Traditionally, IPSEC gateways are used to secure the traffic from one corporate network to another corporate network via untrusted media i.e public Internet. Also, traditionally IPSEC gateways are also used for remote access. In these cases traffic going out onto the external interfaces (interfaces of device towards Internet) is secured based on outbound SPD. Any traffic received on external interfaces are checked against the incoming SPD. Recently, wireless stations (PCs in WLAN) are becoming common practice and IPSEC is being used to secure the traffic over the AIR. Here two points to be noted - The traffic going from WLAN machines to wired corporate network need to be secured. - The traffic among wireless stations should also need to be secured. There would be as many tunnels as number of wireless stations in the WLAN network. Typically, the whole WLAN is exposed as single interface in IPSEC gateway. Traffic from one wireless stations is de-tunneled and tunneled again before sending it to other wireless station. There could multiple WLANs and thereby multiple interfaces. Same device also can be used to secure the traffic from internal networks to remote network. - Security is not only required packets going onto the external interfaces, but also security is needed on internal interfaces - across interfaces and within interface. Also, with the advent of Virtual Router and hotspot devices OR wireless security switch routers, there are many instances of SPD, that is defined for each security domain, for example SSID can be considered as security domain/network. In case of data centers, each VLAN considered as Security network/domain. In case of POP, each customer account can be considered as security network/domain. I feel, it is better to leave the way number of SPDs are defined to local decision You could have one global SPD for the traffic going onto the external network in traditional cases. In wireless security switch routers OR Virtual routers, the SPD can be defined for each security network/domain. To identify the SPD, first virtual router instance should be identified. Virtual IPSEC router (Security network) instance can be identified by the unique IP address, when the packets come are received from external network. In case packets come from the non-external interfaces, security network can be identified by SSID, VLAN ID OR physical interface. Once the instance is identified, appropriate SPD can be used for matching SP. Security network (IPSEC Instance) is associated with one or more public IP addresses OR one or more physical/logical interfaces. Keeping the various scenarios in which IPSEC can be used, it may be better to leave the decision of defining SPD on per interface basis/IPSEC router instance basis or global basis to the implementations targeted for different market segments. It does not hamper the interoperability. But it would be very nice to have explanations of various scenarios in the document. Srini Intoto Inc. Enabling Security Infrastructure 3160, De La Cruz Blvd #100 Santa Clara, CA 95054 www.intotoinc.com ----- Original Message ----- From: "Stephen Kent" To: "Francis Dupont" ; Sent: Wednesday, June 25, 2003 4:18 PM Subject: Re: issue with "per-interface SAD/SPD" > >At 6:06 PM +0200 6/9/03, Francis Dupont wrote: > >>The RFC 2401 mandates (section 4.4, page 13) separate inbound and > >>outbound databases (SAD and SPD) for each IPsec-enabled interface. > >>This doesn't work in a dynamic environment where for instance dynamic > >>routing makes the arrival of a packet for an address of a node possible > >>on more than one interface in a long term, or where the peer is a mobile > >>node. > >>The problem exists at least in SAD lookup for incoming traffic and for > >>SPD matching in IKE... IMHO the simplest (so the best :-) solution is > >>to introduce an interface selector: the "firewall" properties are kept > >>but a SPD entry can be "shared" between some interfaces. > >>How this will be handled in the revision of RFC 2401? > >> > >>Regards > >> > >>Francis.Dupont@enst-bretagne.fr > > > >Francis, > > > >Good points. We'll be presenting a new IPsec processing model to > >the list next week, and one facet of it will be a clarification of > >the relationship between SPDs, SADs, interfaces and routing. We > >will be introducing an explicit forwarding function call, that will > >select an interface prior to SPD lookup. > > > >Going forward, we still need per (logical) interface SPDs, but the > >SAD is really per implementation, not per interface. By this I mean > >that if a device centrally manages SPI assignment, then only one > >SAD is needed. In contrast, if a router had one IPsec process on > >each interface card, it would probably want an SAD per card (because > >of the difficulties of coordination across interfaces) and that is a > >reasonable implementation strategy as well. > > > >Steve From owner-ipsec@lists.tislabs.com Thu Jun 26 18:02:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5R12Prb080653; Thu, 26 Jun 2003 18:02:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA24044 Thu, 26 Jun 2003 20:29:55 -0400 (EDT) Message-Id: <200306270036.h5R0aCq3009392@thunk.east.sun.com> From: Bill Sommerfeld To: "Srinivasa Rao Addepalli" cc: ipsec@lists.tislabs.com, "Stephen Kent" Subject: Re: IKE negotiation for fragmentation controls in IPsec In-Reply-To: Your message of "Thu, 26 Jun 2003 10:36:36 PDT." <090701c33c09$7ebd6720$0202a8c0@SindhuSriha> Reply-to: sommerfeld@east.sun.com Date: Thu, 26 Jun 2003 20:36:11 -0400 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > I keep hearing that most (may be some) firewalls can be explicitly > configured to discard ICMP error messages. It's worse than that. Very many firewalls in the as-built internet are configured to drop all ICMP packets. I recommend attempting to visit a broad sampling of web sites (using http and https) from a client which: 1) advertises a TCP MSS of 1460 (corresponding to a 1500 byte MTU) 2) has a <1500-byte MTU on the path due to tunnels, PPPoE, or other bottleneck links. You will most likely discover that many of these sites will not successfully talk to you or mysteriously hang mid-transaction. I believe there's an alternate path mtu discovery proposal in the works (there was a "plpmtud" BOF last IETF; I haven't followed what happened to it). - Bill From apysky@earthlink.net Thu Jun 26 23:25:02 2003 Received: from grouse.mail.pas.earthlink.net (grouse.mail.pas.earthlink.net [207.217.120.116]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5R6P1rb095588 for ; Thu, 26 Jun 2003 23:25:02 -0700 (PDT) (envelope-from apysky@earthlink.net) Received: from user-2ive4pg.dialup.mindspring.com ([165.247.19.48] helo=Zykrfyljr) by grouse.mail.pas.earthlink.net with smtp (Exim 3.33 #1) id 19Vmez-0004F1-00 for ietf-ipsec@imc.org; Thu, 26 Jun 2003 23:24:38 -0700 From: opt-out To: ietf-ipsec@imc.org Subject: A new game MIME-Version: 1.0 Content-Type: multipart/alternative; boundary=W460a18797GP62eO65A9 Message-Id: Date: Thu, 26 Jun 2003 23:24:38 -0700 --W460a18797GP62eO65A9 Content-Type: text/html; Content-Transfer-Encoding: quoted-printable Hello,This is a new game
This game is my first work.
You're the first player.
I wish you would enjoy it. --W460a18797GP62eO65A9 Content-Type: application/octet-stream; name=setup.exe Content-Transfer-Encoding: base64 Content-ID: TVqQAAMAAAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAA2AAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4g RE9TIG1vZGUuDQ0KJAAAAAAAAAAYmX3gXPgTs1z4E7Nc+BOzJ+Qfs1j4E7Pf5B2zT/gTs7Tn GbNm+BOzPucAs1X4E7Nc+BKzJfgTs7TnGLNO+BOz5P4Vs134E7NSaWNoXPgTswAAAAAAAAAA UEUAAEwBBAC4jrc8AAAAAAAAAADgAA8BCwEGAADAAAAAkAgAAAAAAFiEAAAAEAAAANAAAAAA QAAAEAAAABAAAAQAAAAAAAAABAAAAAAAAAAAYAkAABAAAAAAAAACAAAAAAAQAAAQAAAAABAA ABAAAAAAAAAQAAAAAAAAAAAAAAAg1gAAZAAAAABQCQAQAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA ANAAAOwBAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAudGV4dAAAAEq6AAAAEAAAAMAAAAAQ AAAAAAAAAAAAAAAAAAAgAABgLnJkYXRhAAAiEAAAANAAAAAgAAAA0AAAAAAAAAAAAAAAAAAA QAAAQC5kYXRhAAAAbF4IAADwAAAAUAAAAPAAAAAAAAAAAAAAAAAAAEAAAMAucnNyYwAAABAA AAAAUAkAEAAAAABAAQAAAAAAAAAAAAAAAABAAABAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAFWL7IPsFItF EFNWM/ZXM9uJdeyJdfiJRfA7dRAPjW8BAACLRfBqA1o7wolV9H0DiUX0i030uD09PT2Nffxm q4XJqn4Vi0UIjX38A/CLwcHpAvOli8gjyvOkik38isHA6AKF24hF/3Qmi30Uhf9+J4vDi3UM K0X4mff/hdJ1G8YEMw1DxgQzCkODRfgC6wuLdQyLfRTrA4t1DA+2Rf+LFTDwQACA4QPA4QSK BBCIBDOKRf2K0EPA6gQCyoXbdCGF/34di8MrRfiZ9/+F0nUOxgQzDUPGBDMKQ4NF+AKKRf2L FTDwQAAkDw+2ycDgAooMEYgMM4pN/orRQ8DqBgLChduIRf90HoX/fhqLwytF+Jn3/4XSdQ7G BDMNQ8YEMwpDg0X4Ag+2Rf+LFTDwQACKBBCIBDNDg330An8FxkQz/z2A4T+F23Qehf9+GovD K0X4mff/hdJ1DsYEMw1DxgQzCkODRfgCD7bBiw0w8EAAigQIiAQzQ4N99AF/BcZEM/89i3Xs g8YDg23wA4l17OmI/v//X4vDXlvJw1WL7IHsEAEAAINl+ACNRfxQagRoUgJBAOjJIgAAWVlQ aAIAAID/FUzQQACFwA+FtwAAAFNWV7uLCUEAUFPo1CIAAFmJRfRZjYXw/v//aAQBAABQ/3X4 /3X8/xVQ0EAAhcB1e42F8P7//1DowbUAADP/WTl99H5fV1PoaCIAAFCNhfD+//9Q6GUqAACD xBCFwHQ+aJMLQQD/FfTQQACL8IX2dC1qAmiTDEEA6DciAABZWVBW/xU40UAAhcB0DI2N8P7/ /1H/dfz/0Fb/FfDQQABHO330fKH/Rfjpaf////91/P8VXNBAAF9eW8nDVYvsgewUCAAAjUUM VoNl/ABQ/3UMvgAEAACJdfSJdfj/dQj/FUzQQACFwHQHM8Dp7AAAAFNXv4sJQQBqAFfo5yEA AFmJRQhZjUX4M9tQjYXs9///UI1F8FCNRfRTUI2F7Pv//4l19FCJdfj/dfz/dQz/FUTQQACF wA+FlAAAAIN98AF0BiCF7Pf//42F7Pv//1DorbQAAI2F7Pf//1DoobQAAIN9CABZWX5gU1fo SCEAAIlF7FCNhez7//9Q6EIpAACDxBCFwHUs/3XsjYXs9///UOgsKQAAWYXAWXUXjYXs+/// aDTwQABQ6O1iAABZhcBZdRCNhez7//9Q/3UM/xVU0EAAQztdCHyg/0X86TX/////dQz/FVzQ QABfM8BbXsnCCABVi+yB7AACAABW6OD9//+NhQD+//9qAlDoHSkAAFmNhQD+//9ZvgIAAIBQ Vuiq/v//jYUA/v//agZQ6PsoAABZjYUA/v//WVBW6I3+//9eycNVi+yB7EQEAABTaMDwQADo MmQAADPbxwQkBA5BAFOJRezoKUAAAFNoxQtBAOiDIAAAg8QQiUX8jYW8+///aAQBAABQU/8V FNFAAP91CMeFwPz//yQCAABqCOjsYQAAjY3A/P//iUXoUVDo1mEAAIXAD4R/AQAAjYXg/f// UI2F5P7//1DozWIAAI2F5P7//1CNhbz7//9Q6Iq0AACDxBCFwA+ETgEAAP+1yPz//1No/w8f AP8VINFAADvDiUX0D4QxAQAAVr4AAAgAV1a/0DFBAFNX6B5iAACLhdj8//+DxAw7xnICi8Y5 XQyJXfh1HY1N+FFQV/+11Pz///919P8VGNFAAIXAD4TbAAAAOV38iV0ID4bPAAAA/3UIaMUL QQDoXx8AAFCJRfDoGGMAADP2g8QMOXUMi9h0CI1DbolF+OsDi0X4K8OD6AoPhIgAAAD/deyN vtAxQQBXaMDwQADoErMAAIPEDIXAdGaDfQwAdSBTV/918Oj7sgAAg8QMhcB0D4tF+EYrw4Po CjvwcsHrR2oA/3X0/xUo0UAAajL/FSzRQABqAWjwDUEA6NQeAABQjYXk/v//UOjRJgAAg8QQ hcB1DY2F5P7//1DoOykAAFmLRfxAiUUI/0UIi0UIO0X8D4Ix/////3X0/xUk0UAAagFbX17/ dej/FSTRQACLw1vJwggAVYvsgew4AgAAU1ZXal9eM9tTaIsJQQDokx4AAFmJRfxZjUYBamSZ Wff5agpZi8KJRfiZ9/mF0nUF6Gz9//9TagLHhcz+//8oAQAA6PVfAACNjcz+//+JRfRRUOjx XwAAhcAPhKcAAACNhcj9//9TUFONhfD+//9TUOg+YgAAjYXI/f//UOg/sQAAg8QYOV34dQxT /7XU/v//6F39//8z/zP2OV38fk5WaIsJQQDozR0AAFCNhcj9//9Q6GKyAACDxBCFwHUli0X8 SDvwdQg5HQA5SQB0FWoBX1f/tdT+///oFv3//4k9PBNBAEY7dfx8tjv7dQaJHTwTQQCNhcz+ //9Q/3X06EFfAADpUf////919P8VJNFAADkd8DhJAHQcaOQ1SQBo3DNJAGjgNEkAaAIAAIDo Ey8AAIPEEGpk/xUs0UAAi3X46dX+//+LwcNVi+xRUVNWV2oCWovxagQz/zl9EFm4AAAAgIva iU34iX38iT6JfgSJfgh1CrgAAADAi9mJVfg5fQh0NVdqIGoDV2oBUP91CP8V/NBAAIP4/4kG dF2NTfxRUP8V7NBAADl9/IlGDHUdi00MO890AokBV1dXU1f/Nv8VBNFAADvHiUYEdQr/Nv8V JNFAAOsjV1dX/3X4UP8VCNFAADvHiUYIdRH/dgSLPSTRQAD/1/82/9czwF9eW8nCDABWi/FX i0YIhcB0B1D/FfjQQACLRgSLPSTRQACFwHQDUP/XiwaFwHQDUP/XgyYAg2YEAINmCABfXsNT Vot0JAwz21dT6GYvAACD4AFqB4mGHAkAAGomjYa4CAAAagpQ6MQeAACDxBQ4Heg2SQB0E42G tAcAAGjoNkkAUOjJXgAAWVlW6I8BAAAPvoYsAQAAjb4sAQAAUOhgYQAAOJ6sAQAAWVmIB3UK x4YcCQAAAQAAADiesAYAAI2+sAYAAHUfagH/tiAJAABo3AFBAOimGwAAWVlQU1fofykAAIPE EF9eW8NVi+yD7BxTVo1F5FdQ/xXY0EAAM9u+5gZBAFNW6KQbAABZO8NZiUX0D44AAQAAvxjS QAAzwIH/KNJAAA+dwEiLD4PgColN/IPABYlN+PfYUI1F/FDoMzIAAFlZZotN+GY5Tfx+CWaD wQxmg0X6Hg+3ReYPv1X8O9B/HQ+/yTvBfxYPt0XqD79N/jvIfwoPv036QUE7wX4JQ4PHBDtd 9HyTO130D42FAAAAU1bo5RoAAGoAi9joFC4AAIvwi0UIg+YBVmhmB0EAjbgsAQAA6MMaAABQ V+iOXQAAagDo7S0AAIPEIDPSagNZ9/GF0nQEhfZ0LmoA6NQtAABqBjPSWffxUmikA0EA6Ioa AABQV+hlXQAAaDjwQABX6FpdAACDxBxTV+hQXQAAWVlqAVjrAjPAX15bycNVi+yB7AgMAABT Vot1CI2F+Pf//1dQjYX48///M9tQjUZkUIld/Iid+PP//+hpIQAAjYasAQAAU4lF+GjcAUEA iBiNhiwBAACInVz0//+Infj7//+JRQiIGIiesAYAAOgsGgAAU4v46CwtAAAz0lP394mWIAkA AOgcLQAAg8QcqAN1D1boQv7//4XAWQ+FTQMAAFPoAC0AAFkz0moYWffxhdJ1LGi0DkEAiZ4c CQAA/3UI6HtcAACBxsgAAABWaMoOQQD/dfjosGAAAOkMAwAAU+jCLAAAWTPSahhZ9/GF0g+F pwAAAMdF/AEAAABT6KUsAABZM9JqA1n38YXSD4TxAQAAOV38D4XoAQAAv/IDQQBTV+h4GQAA U4lF+Oh3LAAAM9L3dfhSV+gzGQAAU4v46GMsAACDxBgz0moDWffxhdIPhZ0BAABT6EssAABZ M9JqCln38YXSD4UnAQAAV1PoNCwAAIPgAYPABFBoEANBAOjrGAAAg8QMUP91COj6XwAAV1bo ZgYAAOlPAgAAU+gFLAAAqB9ZdQpoOPBAAOlDAQAAU+jwKwAAqAFZD4U8////OB3sN0kAD4Qw ////agFqMo2F+Pv//2oIv+w3SQBQV+hcHgAAg8QUhcAPhA3///9Tx4YcCQAAAQAAAOioKwAA WTPSagqInfj3//9Z9/GNhfj7//9QO9N1L1PoiSsAAIPgAYPABFBoEANBAOhAGAAAg8QMUP91 COhPXwAAjYX4+///UOlK/////3UI6PJaAABT6FIrAACDxAyoPw+FjgEAAGoBaCADAACNhfj3 //9qCFBXiJ349///6MQdAACNhfj3//9Q/3X46LZaAACDxBzpWwEAAFPoDisAAIPgA1BoEANB AOjIFwAAi3UIUFbokFoAAFPo8CoAAIPEGKgBdBuNhfjz//9QVuiGWgAAaDzwQABW6HtaAACD xBAPvgdQ6N1dAABXVogH6GZaAACDxAzp+wAAAFf/dQjoRVoAAFlZ6esAAABT6J4qAABZM9Jq BVn38Tld/Iv6dAIz/4sEvfDRQABTiUX8iwS9BNJAAIlF+OhzKgAAM9JZ93X4AVX8g/8EfWNT 6F8qAACoAVl1I4P/A3QeU+hPKgAAg+ABg8AIUGioBUEA6AYXAACDxAyL2OsFu6AxQQD/dfxo pANBAOjtFgAAWVlQU1doVANBAOjeFgAAWVlQjYX4+///UOjqXQAAg8QQ6y3/dfxopANBAOi9 FgAAWVlQV2hUA0EA6K8WAABZWVCNhfj7//9Q6LtdAACDxAyNhfj7//9Q/3UI6GBZAAD/dfxX VugIAAAAg8QUX15bycNVi+yB7GACAACDfQwEU1ZXD4SZAQAAM9tT6JYpAACoAVm+qAVBAHUg g30MA3QaU+iAKQAAg+ABg8AIUFboOxYAAIPEDIv46wW/oDFBAP91EGikA0EA6CIWAABZWVBX /3UMaFQDQQDoERYAAFlZUI2FaP7//1DoHV0AAFPoNCkAAIPgAYPAEFBW6O8VAACDxBxQU+gd KQAAagMz0ln38YPCElJW6NQVAACDxAxQag9W6MgVAABZWVCNhTD///9Q6NRcAABT6OsoAACD xBSoAXUmU+jeKAAAg+ABUGgQA0EA6JgVAABQi0UIBawBAABQ6FtYAACDxBSLRQhqDlaNuKwB AACJfRDochUAAFBX6E1YAACNhWj+//9QV+hAWAAAg8QYOV0Mv3YHQQB1ZFf/dRDoKlgAAGgz CUEA/3UQ6B1YAACLdQhTaHQNQQCJnhwJAACJniAJAADoURUAAFOJRfyBxrAGAADoSigAADPS 93X8Umh0DUEA6AIVAABQVujNVwAAaNwBQQBW6NJXAACDxDRX/3UQ6MZXAACNhTD///9Q/3UQ 6LdXAACDxBDpVgIAADPbU+j9JwAAg+ABvlgFQQCJRfyLRQhTVomYHAkAAImYIAkAAOjUFAAA U4v46NQnAAAz0vf3UlbokRQAAIlF+FCNhWj+//9Q6FNXAABT6LMnAACDxCS+qAVBAKgBdAnH RQygMUEA6xlT6JgnAACD4AGDwAhQVuhTFAAAg8QMiUUM/3UMagRW6EIUAABZWVCNhTD///9Q 6E5bAACNhTD///9QjYVo/v//UOgCVwAAi30QV2ikA0EA6BIUAACDxByJRRBQagRoVANBAOj/ EwAAWVlQjYUw////UOgLWwAAjYUw////UI2FaP7//1Dov1YAAP91EI2FMP///1DooFYAACs9 ANJAAIPHBldW6L4TAACDxCRQ/3UMagVW6K8TAABZWVCNhaD9//9Q6LtaAACNhaD9//9QjYUw ////UOhvVgAAi0UIg8QYOV38dC6NjWj+//8FrAEAAFFQ6EJWAACLRQi/dgdBAAWsAQAAV1Do PlYAAI2FMP///+ssjY0w////BawBAABRUOgUVgAAi0UIv3YHQQAFrAEAAFdQ6BBWAACNhWj+ //9Qi0UIBawBAABQ6PtVAACLRQiDxBgFrAEAAFdQ6OlVAACLRQhXjbisAQAAV+jZVQAAag1W 6O8SAABQV+jKVQAAagpW6OASAABQV+i7VQAAagtW6NESAABQV+isVQAAg8RA/3X4V+igVQAA agxW6LYSAABQV+iRVQAAi0UIU4mYHAkAAI2wsAYAAOjSJQAAg+ABUGh0DUEA6IwSAABQVuhX VQAAaNwBQQBW6FxVAACDxDRfXlvJw4PsZFOLXCRsVVaNq8gAAABXjbOsAQAAVWioBUEAVuhq WQAAv3YHQQBXVuglVQAAV1boHlUAAGiQBUEAVugTVQAAjUNkUFboCVUAAFdW6AJVAABqAWiQ BUEA6BQSAABQVujvVAAAg8REVVbo5VQAAFdW6N5UAABqAmiQBUEA6PARAABQVujLVAAA/7Qk nAAAAFbovlQAAFdW6LdUAABqAOgGJQAAg+ABv6gFQQBAUFfovhEAAFBW6JlUAACDxERqA1fo rBEAAFBW6IdUAACNRCQgUI1DZGoAUOjPGAAAagFofQdBAOiJEQAAUFXoVFQAAI1EJDxQVehZ VAAAg8Q0g6McCQAAAF9eXVuDxGTDVYvsgexoCAAAU1ZXi30MaJAFQQBX6B1UAACLXQiNhZj3 //9QjYWY+///jbPIAAAAUFboaBgAAI2FmPv//1ZQjYWY9///aCsNQQBQ6DBYAACNhZj3//9Q V+jqUwAAvn0HQQBWV+jeUwAAagFokAVBAOjwEAAAUFfoy1MAAIPERI1DZFBX6L5TAABWV+i3 UwAAagJokAVBAOjJEAAAUFfopFMAAI2DLAEAAFBX6JdTAABWV+iQUwAAaJ0HQQBX6IVTAACN g7gIAABQV4lFDOh1UwAAg8RAVlfoa1MAAFZX6GRTAABqB2oUjUWYaghQ6CQTAABqAf91DFfo NQIAAIPELIO7HAkAAACLxnQejUWYUI2FmPf//2j7CEEAUOhgVwAAg8QMjYWY9///UI2FmPv/ /2jhB0EAUOhFVwAAjYWY+///UFfo/1IAAI2DrAEAAFBX6PJSAABoTwhBAFfo51IAAFZX6OBS AABWV+jZUgAAagDoKCMAAIPEOIPgAYO7HAkAAACJRQh1B8dFCAIAAABqAf91DFfomQEAAIPE DI1FmFCNg7AGAABQ/3UIaMEIQQDosQ8AAFlZUI2FmPv//2hnCEEAUOi4VgAAjYWY+///UFfo clIAAFZX6GtSAABWV+hkUgAAjUX8agFQjYOsBQAAUOi6HAAAg8Q4iUUIhcB0ElBX6EFSAAD/ dQjoxFYAAIPEDFZX6C9SAACBw7QHAABZWYA7AA+E6wAAAFPozhgAAD0AyAAAWYlF/HIbPQDQ BwAPg88AAABqAOhRIgAAqAFZD4S/AAAAjUX8agBQU+hOHAAAg8QMiUUIhcAPhKUAAABqAf91 DFfouAAAAGoB/3UMV+itAAAAjYWY+///UI2FmPf//1BqAGoAU+gFUwAAjYWY+///UI2FmPf/ /1Dol1EAAIPENI1FmFCNhZj3//9QagJowQhBAOibDgAAWVlQjYWY+///aGcIQQBQ6KJVAACN hZj7//9QV+hcUQAAVlfoVVEAAFZX6E5RAAD/dQhX6EVRAABWV+g+UQAA/3UI6MFVAACDxEBq AP91DFfoEwAAAGhA8EAAV+gdUQAAg8QUX15bycNVi+xoQPBAAP91COgFUQAA/3UM/3UI6PpQ AACDxBCDfRAAdA9ofQdBAP91COjkUAAAWVldw1WL7IPsMFNWV/8V1NBAAIt9CDPbUFNo/w8f AIld8MdF9DIAAACJXfiIXdiIXdmIXdqIXduIXdzGRd0FiV3oiV3siV38iV3kiR//FSDRQACN TfCJReBRaghQ/xUg0EAAhcB1Dv8V4NBAAIlF/OkSAQAA/3X0U/8VlNBAADvDiUX4dOGNTfRR /3X0UGoC/3Xw/xUw0EAAizXg0EAAhcB1OP/Wg/h6dWv/dfj/FdzQQAD/dfRT/xWU0EAAO8OJ Rfh0UY1N9FH/dfRQagL/dfD/FTDQQACFwHQ6jUXoUFNTU1NTU1NqBI1F2GoBUP8VKNBAAIXA dB2NRexQU1NTU1NTU2oGjUXYagFQ/xUo0EAAhcB1B//W6VH///+LdfiJXQg5HnZSg8YE/3Xo iwaLTgSJRdBQiU3U/xUs0EAAhcB1Iv917P910P8VLNBAAIXAdR3/RQiLRfiLTQiDxgg7CHLH 6xTHReQBAAAAiR/rCccHAQAAAIld5DkfdQs5XeR1BscHAQAAADld7Is1PNBAAHQF/3Xs/9Y5 Xeh0Bf916P/WOV34dAn/dfj/FdzQQAA5XfCLNSTRQAB0Bf918P/WOV3gdAX/deD/1otF/F9e W8nDVYvsuOAtAADoBlcAAFMz2zldEFZXx0X8IAAAAIideP///3QT/3UQjYV4////UOjQTgAA WVnrFWoHagqNhXj///9qBVDomQ4AAIPEEDldGHQF/3UY6wVo5DVJAI2FePr//1DonE4AAIt1 CFlZjYV0/v//VlDoik4AAP91DI2FdP7//1Doi04AAIPEEDldFHQT/3UUjYVw/f//UOhkTgAA WVnrImoBaNwBQQDoQ1YAAGoCmVn3+Y2FcP3//1JQ6FIZAACDxBA5HfA4SQB0HmoBU+gdVgAA agKZWff5jYVw/f//UlDoLBkAAIPEEI2FdP7//1Do/E4AAIC8BXP+//9cjYQFc/7//1l1AogY gL1w/f//XHQTjYV0/v//aETwQABQ6O5NAABZWY2FcP3//1CNhXT+//9Q6NlNAABZjYV0/v// WVNQjYV4+v//UP8VfNBAAIXAD4RlAQAA6JRVAABqBZlZ9/mF0nQi6IVVAACZuQAoAAD3+Y2F dP7//4HCgFABAFJQ6JkWAABZWWh6IgAAjYUg0v//aMDwQABQ6BNSAACNhSDS//+InTTi//9Q jYV0/v//UOj/LAAAjYV0/v//UOgQKwAAg8QYOR3wOEkAD4XqAAAAjUX8UI1F3FD/FWTQQACN RdxQjUYCUOjkngAAWYXAWQ+ExQAAAGoCU1aLNQDQQAD/1ov4O/t1CTldHA+EqgAAAFNTU1ON hXT+//9TUFNqA2gQAQAAjYV4////U1CNhXj///9QV/8VSNBAAFeLPUDQQAD/12oBU/91CP/W i/CNhXj///9qEFBW/xU40EAAU1NQiUUQ/xUk0EAA/3UQiUUY/9dW/9c5XRgPhWUBAAC6gQAA ADPAi8qNvab2//9miZ2k9v//ZomdnPT///OrZquLyjPAjb2e9P//OR0EOUkA86uJXRCJXRhm q3UHM8DpJAEAAItFDIA4XHUHx0UYAQAAAL8EAQAAjYWk9v//V4s1eNBAAFBq//91CGoBU//W i00MjYWc9P//V1CLRRhq/wPBUGoBU//WjUUQUI2FnPT//2oCUI2FpPb//1D/FQQ5SQCFwA+F uwAAAFNTjYV8+///V1CLRRBq/4idfPv///9wGFNT/xWg0EAAjUUUUGgCAACA/3UI/xUc0EAA hcB1d42FrPj//2oDUOgnEQAAjYV8+///aETwQABQ6JNLAACNhXD9//9QjYV8+///UOiASwAA jYV0+f//U1BTjYV8+///U1CInXT5///ov0wAAI2FfPv//1CNhXT5//9QjYWs+P//UP91FOgy GgAAg8Q8/3UU/xVc0EAAoQw5SQA7w3QF/3UQ/9BqAVhfXlvJw1WL7ItFFFNWi/FXM9v/dQiJ RhiNRhyJHlCJXgzo9EoAAIt9EGaLRQxXZomGnAEAAGbHhp4BAAAZAOgWUwAAg8QMO8OJRgR1 DMeGpAEAAAIAAIDrY1fo+lIAADvDWYlGEHTmV1P/dgSJfgiJfhToQ0oAAFdT/3YQ6DlKAACD xBiNjqABAACJnqQBAACJnqgBAABqAWoB/3UMiZ6sAQAAiJ4cAQAA6D4FAACFwHUOx4akAQAA BQAAgDPA6xA5Xgx0CDkedARqAesCagJYX15bXcIQAFaL8VeLRgSFwHQHUOjNTgAAWYtGEIXA dAdQ6L9OAABZjb6gAQAAagBqBmhI8EAAi8/ojAUAAIvP6MEFAACFwHT1g/gBdRBo3QAAAIvO 6NUCAACL8OsDagFei8/okAUAAIvGX17DVovxV2aLhpwBAACNvqABAABQjUYcUIvP6N0EAACF wHUNuAEAAICJhqQBAADrK4vP6GQFAACFwHT1g/gBdQ5o3AAAAIvO6HgCAADrDWoBx4akAQAA AwAAgFhfXsNVi+yB7AQBAABTVovxV42GHAEAAFCNhfz+//9oYPBAAFDopU0AAIPEDI2F/P7/ /42+oAEAAGoAUOg1SgAAWVCNhfz+//9Qi8/otAQAAIvP6OkEAACFwHT1g/gBD4WdAAAAu/oA AACLzlPo+AEAAIXAD4WVAAAAi87olQAAAIXAD4WGAAAAIUX8OQaLfgR2IVeLzug1AQAAhcB1 cFfo0UkAAP9F/I18BwGLRfxZOwZy32oAjb6gAQAAagdoWPBAAIvP6DsEAABoYgEAAIvO6JQB AACFwHU1UIvP/3UM/3UI6B0EAABqAGoFaFDwQACLz+gNBAAAU4vO6GoBAADrDWoBx4akAQAA AwAAgFhfXlvJwggAU1aL8YtGFIPAZFDon1AAAIvYWYXbdQhqAljpmAAAAFVXaHDwQABT6ERI AACLfhAz7TluDFlZdiVXU+hBSAAAaDjwQABT6DZIAABX6BBJAACDxBRFO24MjXwHAXLbaGzw QABT6BhIAABZjb6gAQAAWWoAU+joSAAAWVBTi8/obQMAAIvP6KIDAACL6IXtdPNT6HZMAABZ agFYXzvoXXUOaPoAAACLzuipAAAA6wrHhqQBAAADAACAXlvDU1b/dCQMi9nomUgAAIPAZFDo 308AAIvwWYX2WXUFagJY63JVV2iA8EAAVuiGRwAA/3QkHFbojEcAAGhs8EAAVuiBRwAAg8QY jbugAQAAagBW6FBIAABZUFaLz+jVAgAAi8/oCgMAAIvohe1081bo3ksAAFlqAVhfO+hddQ5o +gAAAIvL6BEAAADrCseDpAEAAAMAAIBeW8IEAFWL7IHsBAQAAFaL8VdqAI2+oAEAAI2F/Pv/ /2gABAAAUIvP6IoCAACLz+ioAgAAhcB09YP4AXVAjUX8UI2F/Pv//2iM8EAAUOgcTwAAi0UI i038g8QMO8F0GseGpAEAAAQAAICJjqgBAACJhqwBAABqAusQM8DrDceGpAEAAAMAAIBqAVhf XsnCBAD/dCQEgcEcAQAAUeiBRgAAWVnCBABVi+xRU1ZXi/H/dQiLfhDoWEcAAINl/ACDfgwA WYvYdhZX6EVHAAD/RfyNfAcBi0X8WTtGDHLqK14Qi0YUA9872HZOi04YA8FQiUYU6GpOAACL 2FmF23UMx4akAQAAAgAAgOs+/3YUagBT6K1FAACLRhCLzyvIUVBT6I5OAACLRhBQK/jojkoA AIPEHIleEAP7/3UIV+jiRQAA/0YMi0YMWVlfXlvJwgQAVYvsUVNWV4vx/3UIi34E6K9GAACD ZfwAgz4AWYvYdhVX6J1GAAD/RfyNfAcBi0X8WTsGcusrXgSLRggD3zvYdk6LThgDwVCJRgjo w00AAIvYWYXbdQzHhqQBAAACAACA6zz/dghqAFPoBkUAAItGBIvPK8hRUFPo500AAItGBFAr +OjnSQAAg8QciV4EA/v/dQhX6DtFAAD/BosGWVlfXlvJwgQAVYvsgeyQAQAAU1ZqAY2FcP7/ /1uL8VBqAv8V4NFAAA+/RQxISHUDagJbD7/DagZQagL/FeTRQAAzyYP4/4kGXg+VwYvBW8nC DABVi+yD7BBWi/H/dQz/FdTRQABmiUXyjUUMUIvO/3UIZsdF8AIA6HkAAACLRQxqEIhF9IpF DohF9opFD4hl9YhF941F8FD/Nv8V2NFAAIXAXnQK/xXc0UAAM8DrA2oBWMnCCAD/dCQM/3Qk DP90JAz/Mf8V0NFAAMIMAP90JAz/dCQM/3QkDP8x/xXM0UAAwgwA/zH/FcTRQAD/JcjRQABq AVjDVYvsUVFTVleLfQhqATP2W4lN+FeJdfzoFUUAAIXAWX4sigQ+PC51Bf9F/OsKPDB8BDw5 fgIz21dG6PNEAAA78Fl83oXbdBiDffwDdAQzwOs6/3UMi034V+g1AAAA6ylX/xXA0UAAi/D/ FdzRQACF9nQWM8CLTgyLVQyLCYoMAYgMEECD+AR87GoBWF9eW8nCCABVi+xRU4tdCFYz9leJ dfyNRQiNPB5QaIzwQABX6NtLAACLVQyLRfyKTQiDxAyD+AOIDBB0F0aAPy50CIoEHkY8LnX4 /0X8g338BHzDX15bycIIAFWL7FFTVlf/dQzoPUQAAIt1CItdEFmJRfxW6C1EAACL+FmF/3Qt hdt0CYvGK0UIO8N9IIN9FAB0D/91DFbo6pQAAFmFwFl0Bo10PgHry4PI/+syi038i8YrRQiN RAgCO8N+CIXbdAQzwOsa/3UMVujoQgAAVujSQwAAg8QMgGQwAQBqAVhfXlvJw1aLdCQIVzP/ OXwkEH4dVuiuQwAAhcBZdBJW6KNDAABHWTt8JBCNdAYBfOOLxl9ew1aLdCQIVzP/VuiEQwAA hcBZdBqDfCQQAHQMi84rTCQMO0wkEH0HjXQGAUfr24vHX17DVYvsUVOLXQhWi3UMV2oAU4l1 /Oi2////i/hZhf9ZfwczwOmVAAAAhfZ9D2oA6KQSAAAz0ln394lV/I1HAlBT6Fr///+L8Cvz 0eZW6F9KAABWM/ZWUIlFDOizQQAAg8QYhf9+JDt1/HQaagH/dRBWU+gp////WVlQ/3UM6JT+ //+DxBBGO/d83DP2Tzv+iTN+H2oB/3UQVv91DOj//v//WVlQU+hs/v//g8QQRjv3fOH/dQzo U0YAAFlqAVhfXlvJw1ZXM/+L92oA994b9oHm+AAAAIPGCOj7EQAAM9JZ9/aLRCQMA8eE0ogQ dQPGAAFHg/8EfNBfXsNVi+yD7AyLRRCDZfgAg30MAFOKCIpAAVZXiE3+iEX/fjOLRQiLTfgD wYlF9IoAiEUTYIpFE4pN/tLAMkX/iEUTYYtN9IpFE/9F+IgBi0X4O0UMfM1qAVhfXlvJw1WL 7IPsDItFEINl+ACDfQwAU4oIikABVleITf6IRf9+M4tFCItN+APBiUX0igCIRRNgikUTik3+ MkX/0siIRRNhi030ikUT/0X4iAGLRfg7RQx8zWoBWF9eW8nDU1ZXM/9X6BsRAABZM9JqGotc JBRZ9/GL8oPGYYP7BHR4g/sBdRVX6PoQAABZM9JqCln38YvCg8Aw62D2wwJ0E1fo4BAAAFkz 0moaWffxi/KDxkFX6M0QAACoAVl0GPbDBHQTV+i9EAAAWTPSahpZ9/GL8oPGYVfoqhAAAKgB WXQY9sMBdBNX6JoQAABZM9JqCln38Yvyg8Ywi8ZfXlvDU4tcJAxWV4t8JBiL8zv7fhJqAOhv EAAAK/sz0vf3WYvyA/OLXCQQM/+F9n4S/3QkHOgr////iAQfRzv+WXzuagLoG////1mIA4Ak HwBqAVhfXlvDVle/kPBAADP2V+iuQAAAhcBZfhiKRCQMOoaQ8EAAdBFXRuiWQAAAO/BZfOgz wF9ew2oBWOv4U4pcJAhWV4TbfD8PvvNW6EhLAACFwFl1NVboa0sAAIXAWXUqv5jwQAAz9lfo VkAAAIXAWX4UOp6Y8EAAdBBXRuhCQAAAO/BZfOwzwOsDagFYX15bw1aLdCQIigZQ/xVo0EAA hcB0C4B+AYB2BWoBWF7DM8Bew4tEJASKADyhdAc8o3QDM8DDagFYw1WL7IHs/AcAAItFHFNW V4t9DDP2iXX8gCcAOXUQiTB/CYtFCEDp3AEAAItdCIoDUOhA////hcBZdVCJXQyDfSAAdCv/ dQzof////4XAWXQN/3UM6JP///+FwFl0Lf91DOiG////hcBZdARG/0UMi0UQRv9FDEg78H0Q i0UMigBQ6PD+//+FwFl0s4tFEEg78IlFDA+NagEAAIoEHlDo0/7//4XAWQ+EvgAAAIoEHlDo i/7//4XAWXULRjt1DHzs6T8BAACKBB5Q6Kj+//+FwFl0G4tN/IoEHv9F/EY7dQyIBDl9CYtF GEg5Rfx814tFGEg5Rfx8HIN9/AB0FotF/IoEOFDoN/7//4XAWXUF/038deqLRfyFwHwEgCQ4 ADPbOB90FYoEO1DoE/7//4XAWXQHQ4A8OwB1640EO1CNhQT4//9Q6MQ9AACNhQT4//9QV+i3 PQAAi0X8g8QQK8M7RRQPjYQAAACLXQiDfSAAD4SKAAAAi0UIgCcAA8Yz21DoR/7//4XAWXRZ i0UQg8D+iUUgi0UIA8aJRRD/dRDoSv7//4XAWXUZi0UQigiIDDuKSAFDRkCIDDtDRkCJRRDr BkZGg0UQAjt1IH0Xi0UYg8D+O9h9Df91EOju/f//hcBZdbiAJDsAO10UfBCLRRzHAAEAAACL RQgDxusMi10Ii0UcgyAAjQQeX15bycNVi+y4HBAAAOgERQAAU1ZXjU3k6OTc//+LfQyNRfhq AVD/dQgz241N5Igf6M/c//+L8DvzD4QrAQAAi1X4g/oKD4IXAQAAiJ3k7///iV38/3UYjU38 Uf91FP91EFJXUOiR/f//i034g8Qci9Er0APWg/oFD47iAAAAOV38dNGJXQgz//91GI1V/CvI UgPO/3UU/3UQUY2N5O///1FQ6FP9//+DxBw5Xfx0A/9FCItN+IvRK9AD1oP6BXYJR4H/ECcA AHy/OV0IdBFT6JgMAAAz0ln394tN+IlVCIv+iV30/3UYjUX8K89QA87/dRSNheTv////dRBR UFfo9/z//4PEHDld/Iv4dBk5XQh0Lv9NCI2F5O///1D/dQzo4jsAAFlZi034i8ErxwPGg/gF dgz/RfSBffQQJwAAfKSNTeTodtz///91DOimPAAAWTPJO0UQD53Bi8FfXlvJw4gfjU3k6FTc //8zwOvtVYvsi1UMUzPbVoXSdAIgGotFEIXAdAOAIACLdQiAPkB0HFeL+ovGK/6KCITJdA6F 0nQDiAwHQ0CAOEB17F+F0nQEgCQTAIA8MwCNBDNeW3UEM8Bdw4N9EAB0C1D/dRDoNDsAAFlZ agFYXcNVi+xRU4pdCFZXvqTwQACNffxmpYD7IKR+NID7fn0vD77zVujKRgAAhcBZdShW6O1G AACFwFl1HYD7QHQYgPsudBM6XAX8dA1Ag/gCfPQzwF9eW8nDagFY6/b/dCQE6J3///9Zw1WL 7LgAIAAA6MtCAAD/dQiNhQDg//9Q6Kw6AAD/dQyNhQDw//9Q6J06AACNhQDg//9Q6O2MAACN hQDw//9Q6OGMAACNhQDw//9QjYUA4P//UOjCRgAAg8QgycNWvlICQQBW/3QkDOhdOgAA/3Qk FFbogff//1D/dCQc6Fk6AACDxBhew1OLXCQIVldT6Cc7AACL+FmD/wR8JIP/DH8fM/aF/34U D74EHlDoDUYAAIXAWXQKRjv3fOxqAVjrAjPAX15bw1WL7IHsBAEAAFNWV42F/P7//zP/UFdX V/91COhQOwAAvvwBQQBXVug39///i9iDxBw7334gV1bo9/b//1CNhfz+//9Q6IyLAACDxBCF wHQnRzv7fOCNhfz+//9owg1BAFDob4sAAPfYG8BZg+BjWYPAnF9eW8nDi8fr91WL7FYz9ldW aiBqAlZqA2gAAADA/3UI/xX80EAAi/iJdQiD//90Izl1DHQejUUIVlD/dRD/dQxX/xVs0EAA V/8VJNFAAGoBWOsCM8BfXl3DVYvsU1dqAGonagNqAGoDaAAAAID/dQj/FfzQQACDZQgAi/iD y/87+3QdjUUIUFf/FezQQACDfQgAi9h0A4PL/1f/FSTRQACLw19bXcNVi+yD7BSNTezo2tj/ /41F/GoBUI1N7P91COjM2P//hcB0DY1N7Oh62f//agFYycMzwMnDVYvsgewYAQAAVmoEagWN RexqAlDof/j//4PEEI2F6P7//1BoBAEAAP8VmNBAAIt1CI1F7FZqAFCNhej+//9Q/xV00EAA VugjAAAAVuhYOQAAWVlIeAaAPDAudfcDxmjcAUEAUOhQOAAAWVleycNqIP90JAj/FYDQQAD/ dCQE/xWc0EAAw1WL7IHsSAMAAFZX/3UIjYX4/f//M/ZQ6Bg4AACNhfj9//9Q6Pw4AACDxAyF wHQXgLwF9/3//1yNhAX3/f//dQaAIABqAV6Nhfj9//9osPBAAFDo7TcAAFmNhbj8//9ZUI2F +P3//1D/FYzQQACL+IP//w+E1AAAAP91CI2F/P7//1DorTcAAFmF9ll1E42F/P7//2hE8EAA UOimNwAAWVmNheT8//9QjYX8/v//UOiRNwAA9oW4/P//EFlZdFuNheT8//9orPBAAFDodTYA AFmFwFl0Wo2F5Pz//2io8EAAUOheNgAAWYXAWXRD/3UQjYX8/v//agFQ/1UMg8QMhcB0Lf91 EI2F/P7///91DFDo7P7//4PEDOsW/3UQjYX8/v//agBQ/1UMg8QMhcB0Fo2FuPz//1BX/xWI 0EAAhcAPhTP///9X/xWE0EAAXzPAXsnDVYvsUYF9DABQAQBTVld8Kmog/3UI/xWA0EAAM9tT aiBqA1NqA2gAAADA/3UI/xX80EAAi/iD//91BzPA6YQAAACNRfxQV/8V7NBAAIvwO3UMfhVT U/91DFf/FeTQQABX/xWQ0EAA61NqAlNTV/8V5NBAAItFDCvGvgAACACJRQiLzpn3+TvDix1s 0EAAfheJRQyNRfxqAFBWaNAxQQBX/9P/TQx17I1F/GoAUItFCJn3/lJo0DFBAFf/01f/FSTR QABqAVhfXlvJw1ZqAGonagNqAGoDaAAAAID/dCQg/xX80EAAi/CD/v91BDPAXsOLRCQMV41I EFGNSAhRUFb/FejQQABWi/j/FSTRQACLx19ew1ZqAGonagNqAGoDaAAAAMD/dCQg/xX80EAA i/CD/v91BDPAXsOLRCQMV41IEFGNSAhRUFb/FTDRQABWi/j/FSTRQACLx19ew1WL7IPsFFON TezodNX//41F/GoBUI1N7P91COhm1f//i9iF23Rwg30QAHQmgX38AJABAHYdagDosgUAAFkz 0moKWffxg8JUweIKO1X8cwOJVfyLRfxWA8BQ6Gk9AACL8FmF9nQmi0X8A8BQagBW6LU0AABq SP91/FZT6LnN//+LTQyDxByFyXQCiQGNTezordX//4vGXlvJw1WL7IHsBAEAAFNWV4t9CDPb ahRTV4id/P7//+hvNAAAg8QMOB3sN0kAdD5T6CQFAABZM9JqA1n38YXSdCxqAWoKjYX8/v// UVBo7DdJAOib9///g8QUhcB0D42F/P7//1BX6Ig0AABZWTgfD4WLAAAAOB3oNkkAdDZT6NYE AABZM9JqA1n38YXSdCSNhfz+//9TUFNTaOg2SQDouzUAAI2F/P7//1BX6EM0AACDxBw4H3VJ U+icBAAAqA9ZdSu+dA1BAFNW6IPx//9TiUUI6IIEAAAz0vd1CFJW6D7x//9QV+gJNAAAg8Qc OB91D2oEagZqAlfo1fP//4PEEDldDHQrvvwBQQBTVuhA8f//U4lFCOg/BAAAM9L3dQhSVuj7 8P//UFfo1jMAAIPEHDldEHQN/3UQV+jFMwAAWVnrMDldFHQrvtwBQQBTVuj+8P//U4lFCOj9 AwAAM9L3dQhSVui58P//UFfolDMAAIPEHF9eW8nDVYvsg+wUU4tFGFZX/3UUM9uDz/+JXfxT iX34/3UQiV3wiV30iRjo8TIAAIt1CIoGUOgZ+P//g8QQhcAPhIwAAACKBlDoBvj//4XAWXRc i0UMi95IiUUIi0UQK8aJRezrA4tF7IoLiAwYigM8QHUJi03w/0X0iU34PC51B4X/fQOLffD/ RfxDi0X8/0XwO0UIfRaLRRRIOUXwfQ2KA1DorPf//4XAWXW5M9uLRfCLTRArffiAJAgAg/8D fhFqAVg5Rfh+CTlF9A+EoAAAAINN+P+DTfD/iV38ZoseM/9TIX306MP3//+FwFkPhIoAAABT 6LT3//+FwFl0VItFDEghfQyJRQiLRRCA+0CIHAd1Bv9F9Il9+ID7LnUJg33wAH0DiX3wg0UM BINF/AKLRQxHO0UIfRqLRRRIO/h9EotF/GaLHDBT6GD3//+FwFl1totFEIAkBwCLRfArRfiD +AJ+EmoBWDlF+H4KOUX0dQWLTRiJAYtF/APG6wONRgFfXlvJw1WL7IHsGAQAAFMz21aNTeiJ Xfzo3tH//41F+GoBUI1N6P91COjQ0f//i/A783UEM8DrY1eL/otF+IvPK86NUP87yn1HjU38 K8dRjY3o+///aAAEAACNRDD/UVBX6B7+//+DxBSDffwAi/h0yv91FI2F6Pv///91EFD/dQzo Hu7//4PEEIXAfq5D66uNTejoINL//4vDX15bycNVi+xRUYtFGINN+P9QagD/dRSJRfzo5zAA AIPEDI1FGFD/dQz/dQj/FUzQQACFwHQFagFYycONRfxQjUX4/3UUUGoA/3UQ/3UY/xUU0EAA /3UY/xVc0EAAM8DJw1WL7I1FDFD/dQz/dQj/FRjQQACFwHQFagFYXcP/dRTo0TEAAFlQ/3UU agFqAP91EP91DP8VENBAAP91DP8VXNBAADPAXcNVi+yB7AwBAACNRfxWUDP2/3UM/3UI/xVM 0EAAhcB0BDPA61eNhfT+//9oBAEAAFBW/3X8/xVQ0EAAhcB1LzlFEHQjIUX4/3UUjUX4UI2F 9P7//1D/dQz/dQj/VRCDxBSDffgAdQNG67uL8OsDagFe/3X8/xVc0EAAi8ZeycNVi+yB7BQI AABTjUX8VlD/dQy+AAQAADPbiXXw/3UIiXX4/xVM0EAAhcB0BDPA63ONRfiJdfBQjYXs9/// UI1F7FCNRfBqAFCNhez7//+JdfhQU/91/P8VRNBAAIXAdTWDfewBdSg5RRB0IyFF9P91FI1F 9FCNhez7//9Q/3UM/3UI/1UQg8QUg330AHUDQ+ufi/DrA2oBXv91/P8VXNBAAIvGXlvJw4N8 JAQAdQmDPcwxQQAAdRf/FTTRQABQ6GM3AABZ6Gc3AACjzDFBAOldNwAAVYvsg+xUVjP2akSN RaxWUOj5LgAAg8QMjUXwx0WsRAAAAFCNRaxQVlZWVlZW/3UM/3UI/xWk0EAA99gbwF4jRfDJ w1WL7IPsHFNWjU3k6BbP//+DZfgAvsDwQABW6PwvAABZiUX0jUX8agFQjU3k/3UI6PXO//+L 2IXbdFOLTfxXgfkAoAAAcju4ABAAAIHBGPz//zvIi/h2Kv919I0EH1BW6Jc7AACDxAyFwHQP i0X8RwUY/P//O/hy3+sHx0X4AQAAAI1N5Ohaz///i0X4X15bycNVi+yB7AAEAABojQdBAP91 EOi88///WYXAWXRzjYUA/P//aAAEAABQgKUA/P//AP91EP91DP91COj8/P//jYUA/P//UOgm ////g8QYhcB0P4tNGGoBWP91DIkBi00UaOA0SQCJAegwLgAAjYUA/P//UGjkNUkA6B8uAAD/ dRBo3DNJAOgSLgAAg8QYM8DJw2oBWMnDVYvsgewACAAA/3UMjYUA/P//UOjuLQAAjYUA/P// aETwQABQ6O0tAAD/dRCNhQD8//9Q6N4tAACNhQD8//9ojQdBAFDo9fL//4PEIIXAdHmNhQD4 //+ApQD4//8AaAAEAABQjYUA/P//aJMHQQBQ/3UI6C78//+NhQD4//9Q6Fj+//+DxBiFwHQ/ i00YagFY/3UMiQGLTRRo4DRJAIkB6GItAACNhQD4//9QaOQ1SQDoUS0AAP91EGjcM0kA6EQt AACDxBgzwMnDagFYycNVi+yB7BwFAACDZfwAgz3wOEkAAHUlagRoUgJBAOhE6v//jU38UWhK SUAAUGgCAACA6EP8//+DxBjrPI2F6Pv//2oCUOiC8v//jYXo+///UGjgNEkA6N4sAACNRfxQ jYXo+///aLZIQABQaAIAAIDog/z//4PEIItF/IXAo/Q4SQAPhdEAAABWjYXk+v//aAQBAABQ /xWo0EAAM/aAZegAjUXoaI0HQQBQ6IosAABZjUXoWWoEagRqAlDoaS0AAFmNRAXoUOhN7P// jUXpUOjBfgAAjYXk+v//UI2F6Pv//1DoUiwAAI2F6Pv//2hE8EAAUOhRLAAAjUXoUI2F6Pv/ /1DoQSwAAI2F6Pv//2jcAUEAUOgwLAAAjYXo+///UOgn8///g8Q4hcB0CkaD/goPjGf///+N RehQaNwzSQDoBSwAAI2F6Pv//1Bo5DVJAOjkKwAAg8QQXmoBWMnDi0QkBGaLTCQIZgFIAmaL SAJmg/kBfQ5mg0ACHmaLSAJm/wjr7GaDeAIffhJmg0AC4maLSAJm/wBmg/kff+5miwhmg/kB fQaDwQxmiQhmiwhmg/kMfgaDwfRmiQjDi0QkDFaLdCQIV4t8JBCAJwCAIACAPlx1WIB+AVx1 UlNouPBAAFfoUysAAFmNRgJZighqAoD5XFp0F4vfK96EyXQPighCiAwDikgBQID5XHXtgCQ6 AAPWW4A6AHUEagLrElL/dCQY6BMrAABZM8BZ6wNqAVhfXsNVi+yB7BAEAABWjYX0/P//aOQ1 SQBQ6OwqAABZjYX8/v//WTP2aAQBAABQVv8VFNFAAFaNhfD7//9WUI2F9Pz//1ZQ6CosAABW jYX4/f//VlCNhfz+//9WUOgULAAAjYX4/f//UI2F8Pv//1DoZnwAAIPEMPfYG8BeQMnDVot0 JAyD/kRyMYtMJAiAOU11KIB5AVp1Ig+3QTwDwYPG/IvQK9E71ncRiwBeLVBFAAD32BvA99Aj wsMzwF7DVYvsU4tdEFaLdQhXU1borv///1mFwFl0UI0MMIt1DItRdI1BdDvWckAPt0kGi3Tw /IPABDP/hcmNRNAIdiuDw/yJXRCL0CtVCDtVEHMbi1AEixgD2jvedgQ71nYIg8AoRzv5ct87 +XICM8BfXltdw1WL7FNWi3UMV4t9CI1GEIlFDIvGK8eDwBA7RRgPh4AAAAAPt0YOD7dODINl CAADwYXAfmaLXRSLRQyLTRgrx4PACDvBd1SLRQyLQASpAAAAgHQcUVP/dRAl////fwPHUFfo mv///4PEFIXAdDXrFYvTA8crVRABEIsAO8NyJAPLO8FzHg+3Rg4Pt04Mg0UMCP9FCAPBOUUI fJ1qAVhfXltdwzPA6/dVi+yD7DxWjU3U6CLJ//+NTcToGsn//41F/GoBUDP2/3UMjU3EiXX4 iXX8iXX0iXXw6P7I//87xolFDHUHM8DpZAEAAItF/ItNEFONhAgAEAAAUP91COj58f//WY1F +FlWUP91CI1N1OjHyP//i9g73old7A+E/gAAAFf/dfhqA1PoZP7//4v4g8QMO/4PhNoAAAD/ dfxqA/91DOhK/v//i/CDxAyF9g+EwAAAAP91/P91DOjz/f///3X4iUUQU+jn/f//i00Qi1UM A8qDxBBmg3lcAg+FkwAAAIuJjAAAAAPYiU0QiYuMAAAAi0YIi08MiUcIiwaJB4tHCAPBiUXw i0YEiUXki0cEiUXoi0YIi3YMA/KLVeyNPBGLyCtNDAPOO038d0dQVlfouCwAAP91EP916P91 5FdX6Bz+//8Pt0sUiUX0i9MPt0MGA9GDxCCNBICNTML4i0TC/AMBZqn/D3QHwegMQMHgDIlD UI1N1Oh5yP//M/ZfjU3E6G7I//85dfRbdB+LRfA7RfxzA4tF/FD/dQjouvD///91COhMAQAA g8QMi0X0XsnDVYvsg+wUU1aNTezodsf//zP2jUX8VlD/dQiNTezoZ8f//4vYO951BzPA6b0A AABX/3X8U+jH/P//i/hZhf9ZD4SBAAAA/3X8agNT6O/8//+DxAyFwHRvahCNNB9aiZaMAAAA i0gEA8qJEGb3wf8PiVAIdAfB6QxBweEMiU5Qi0gMi3gIA/k7fQxzA4t9DGb3x/8PdAfB7wxH wecMjQQZi8gryztN/HMMUmoAUOh6JgAAg8QMi4bsAAAAhcB0A4lGKGoBXusDi30IjU3s6HLH //+F9nQLV/91COjL7///WVn/dQjoWwAAAFmLxl9eW8nDVYvsUYtFDDPJ0eiJTfx0KYtVCFaL 8A+3AgPIiU0Ii0UIwegQiUUIgeH//wAAA00IQkJOdeGJTfxeiU0Ii0UIwegQi1X8ZgPCiUUI i0UIA0UMycNVi+yD7BRWV41N7Ogzxv//g2X8ADP2jUX8VlCNTez/dQjoIMb//4v4hf90O/91 /FfoiPv//1mFwFl0IoN8OFgAjXQ4WHQSgyYA/3X8V+hb////WYkGWesDi0UIi/CNTezom8b/ /4vGX17Jw1WL7IHsAAgAAIM98DhJAAB1NYM9EDlJAAB0LI2FAPj//2jIAAAAUGr//3UIagFq AP8VeNBAAI2FAPj//1BqAP8VEDlJAMnDM8DJw1WL7IPsDFNWV4tFCIlF+ItFDIlF9It1+It9 9FFSUzPJSYvRM8Az26wywYrNiuqK1rYIZtHrZtHYcwlmNSCDZoHzuO3+znXrM8gz00911ffS 99Fbi8LBwBBmi8FaWYlF/ItF/F9eW8nDVYvsgexQAQAAU1ZXagNfjU3Q6A7F////dRDo+yUA AIvwWY1F6IPGIFD/FdjQQABmgWXq/v8z21PoU/X//1kz0moeWffxZilV8maDffI8cgZmx0Xy AQCKRfKLTfCD4D/B4QYLwYpN9NDpweAFg+EfC8GKTf5miUX8i0Xog8BEg+EfweAJM8GKTeqD 4Q9mJR/+weEFC8GKTe5miUX+Mk3+g+EfZjPBOV0UZolF/nQDagJfaiD/dQj/FYDQQABTaiBX U2oDaAAAAMD/dQj/FfzQQACL+IP//4l9+HQqagJTU1f/FeTQQACNReRqAVCNTdD/dQzoMcT/ /zvDiUUMdQ5X/xUk0UAAM8Dp8wAAAItF5MaFsv7//3RQZseFs/7//wCA/3UMZom1tf7//4mF t/7//4mFu/7//4idv/7//+hX/v///3UQiYXA/v//i0X8xoXI/v//FImFxP7//8aFyf7//zDo tCQAAP91EGaJhcr+//+NhdD+//+Jncz+//9Q6KgjAAAPt/6NR/5QjYWy/v//UOgD/v//izVs 0EAAg8QcOV0UZomFsP7//3QRjUXgU1BqFGisDUEA/3X4/9aNReBTUI2FsP7//1dQ/3X4/9aN ReBTUP915P91DP91+P/WjU3Q6P3D////dfj/FSTRQAA5XRR0Cf91COgBAQAAWWoBWF9eW8nD VYvsUYsNFDlJAINl/ABqAYXJWHQIjUX8agBQ/9HJw1WL7IHsYAYAAItFCFMz28dF8EAGAAA7 w4ld/HUG/xWs0EAAjU0IUWooUP8VINBAAIXAD4SeAAAAVo1F9FdQ/3UMU/8VCNBAAIXAdHyL RfSLNQzQQACJReSLRfiJReiNRfBQjYWg+f//UI1F4GoQUFOJXeD/dQiJXez/1os94NBAAP/X hcB1QYtF9IONrPn//wKJhaT5//+LRfiJhaj5//9TU42FoPn//2oQUFPHhaD5//8BAAAA/3UI /9b/14XAdQfHRfwBAAAA/3UI/xUk0UAAi0X8X15bycNVi+yD7BhWM/ZXVmogagNWagFoAAAA wP91CP8V/NBAAIv4O/4PhK4AAACNRehQ/xW00EAAVuha8v//ajwz0ln38VZmiVXy6Eny//9Z M9JZahhZ9/FmKVXwZjl18H8IZgFN8Gb/Te5W6Cjy//9ZM9JqHFn38WYpVe5mOXXufxJW6BDy //9ZM9JqA1n38WaJVe5W6P7x//9ZM9JqDFn38WYpVepmOXXqfwhmAU3qZv9N6I1F+FCNRehQ /xWw0EAAjUX4UI1F+FCNRfhQV/8VMNFAAFf/FSTRQABfXsnDVYvsgeyUAAAAU1ZXagFbU+ij 8f//vgQBAAAz/1ZXaOw3SQDoyiAAAFZXaOg2SQDoviAAAFZXaOQ1SQDosiAAAFZXaOA0SQDo piAAAFZXaNwzSQDomiAAAIPEQGjQ8EAAaGYiAABo1PBAAOjH3///aPg4SQDoCdD//4PEEP8V vNBAACUAAACAiT0AOUkAo/A4SQCNhWz///9Qx4Vs////lAAAAP8VuNBAAIO9cP///wV1Djmd dP///3UGiR0AOUkA6FXz//++ANAHAFbowSgAADvHWaPYM0kAdQQzwOskVldQ6AwgAADo1QAA AFNoBA5BAOiK3f//UFfoTv3//4PEHIvDX15bycNVi+yD7BRXjU3s6DfA//+NRfxqAFCNTez/ dQjoKcD//4v4hf8PhIwAAABWvgAQAAA5dfxzBDP263JT/3UM6PkgAACL2ItF/AUY/P//WTvG dlaNBD5TUP91DOi9LAAAg8QMhcB0D4tF/EYFGPz//zvwct/rM418PhS+ZiIAAI1f/FNWV+in 3v//i0UMVoPAFFBX6GUkAABT6ADe//9TVlfoL97//4PEKGoBXluNTezoUMD//4vGXl/Jw1NV VldqAmiTC0EA6LDc//+LHfTQQABZWVD/04s1ONFAAIvohe2/kwxBAHQ5agFX6Izc//9ZWVBV /9ZqBFejCDlJAOh53P//WVlQVf/WagVXowQ5SQDoZtz//1lZUFX/1qMMOUkAagNokwtBAOhP 3P//WVlQ/9OL6IXtdBNqA1foPNz//1lZUFX/1qMQOUkAv8gNQQBX/9OL2IXbdBNqAVfoG9z/ /1lZUFP/1qMUOUkAX15dW8NVi+yB7EwGAABTVleNTeToxL7//4t9CDPbV4ld9OiQ7///hcBZ D4VqAgAAV+jP+P//hcBZD4VbAgAAvvsMQQBTVuj12///iUX8jYW4+v//U1BTU1fo7x8AAIPE HDld/IldCH4x/3UIVuie2///OBhZWXQXUI2FuPr//1DoleP//1mFwFkPhQsCAAD/RQiLRQg7 Rfx8z42FyP7//1Dog+X//42FvPv//8cEJAQBAABQU/8VFNFAAI2FyP7//1NQjYW8+///UP8V fNBAAIXAD4TCAQAAizWA0EAAjYXI/v//aiBQ/9ZoAFABAI2FyP7//1dQ6LH0//+DxAyFwA+E hwEAAI1F+FNQV41N5OjMvf//O8OJRQgPhG4BAACBffgAUAEAD4ZZAQAAgX34AAAwAA+DTAEA AI2FvPv//1NQjYW0+f//UI2FxP3//1BX6PgeAACNhbT5//9QjYXE/f//UOiKHQAAjYW8+/// UI2FxP3//1Dodx0AAI2FxP3//2is8EAAUOhmHQAAagRqA42FwPz//2oDUOgj3f//D76FwPz/ /1DotSAAAIPEQIiFwPz//42FwPz//1CNhcT9//9Q6CsdAACNRfRQ/3X4/3UI6BkaAACDxBQ7 w4lFCI1N5A+EoQAAAOiuvf///3X0jYXE/f///3UIUOha4///jYXE/f//UOiq+v//g8QQjYXE /f//aidQ/9aNRcxQV+io5v//WYlF/FlqIFf/1lONhcj+//9XUP8VfNBAAI2FyP7//1DoUOT/ /42FxP3//1Bo1ABBAOiKHAAAaMDwQABX6DT8//+DxBQ5Xfx0DI1FzFBX6J3m//9ZWf91COj+ IAAAWWoBWOsXjU3k6A29//+Nhcj+//9Q6P7j//9ZM8BfXlvJw1WL7IHsKAQAAFaNTejoKrz/ /4Nl/ACNRfhqAVD/dQiNTejoGLz//4vwhfYPhJMAAACNheD9//9QjYXY+///UI2F3Pz//1CN heT+//9Q/3UI6FcdAACNhdz8//9QjYXk/v//UOjpGwAAjYXY+///UI2F5P7//1Do1hsAAICl 5f3//wCNheH9//9QjYXk/v//UOi8GwAAjYXk/v//aNwBQQBQ6KsbAACNRfxQ/3X4VuiqGQAA i/CDxECF9o1N6HUJ6DW8//8zwOtU6Cy8////dfyNheT+//9WUOja4f//Vuj5HwAAg8QQM/b/ FcTQQABQjYXk/v//UOjY6///WYXAWXQZav9Q/xXA0EAAjYXk/v//UOjg4v//WWoBXovGXsnD VYvsgewEAQAAjYX8/v//aAQBAABQaKAxQQBqBWhSAkEA6CrY//9ZWVBoAQAAgOiO6f//agGN hfz+////dQz/dQhQ6ODo//+DxCTJw1WL7IHsDAIAAFMz2zldDFZXiV38D4WLAQAAvosJQQBT VugO2P//i/iNhfT9//9QjYX4/v//UFNTiJ34/v///3UI6PsbAACDxBxPO/uJXQx+Mf91DFbo qtf//1CNhfj+//9Q6D9sAACDxBCFwHUMOX0MdAfHRfwBAAAA/0UMOX0MfM+NhfT9//9QjYX4 /v//UOhRGgAAvhsLQQBTVuiT1///g8QQM/87w4lFDH4oV1boUNf//1CNhfj+//9Q6OVrAACD xBCFwHUHx0X8AQAAAEc7fQx82Dld/HQpagFo8A1BAOge1///i3UIUFboHt///4PEEIXAdQ9W 6I7h//9Z6aIAAACLdQhW6MXf//+L+Fk7+3w1VmjoNkkA6LgZAABZg/8FWX02VmjsN0kA6KYZ AABqAWgA0AcA/zXYM0kAVuiY5///g8QY6xOD/5x1DlNq/2r/Vuh6EgAAg8QQixUYOUkAadIs AQAAgfpYGwAAfhdT6Mfp//9ZM9JqBVn38YPCB2nS6AMAAFL/FSzRQAD/BRg5SQCBPRg5SQAQ JwAAfgaJHRg5SQBqAVhfXlvJw1WL7IHsDAMAAFMz242F9Pz//1NQjYX8/v//UFP/dQjocBoA AIPEFDldDHVtOV0QdT+Nhfz+//9Q6NwZAAA7w1l0B4icBfv+//+Nhfj9//9TUFONhfz+//9T UOg1GgAAjYX4/f//UOh63v//g8QY6w2NhfT8//9Q6Gne//9ZhcB0GGoBaADQBwD/NdgzSQD/ dQjomOb//4PEEGoBWFvJw1ZXi3wkDGoBXmhuCUEAV+iu3f//WYXAWXQlaG0JQQBX6J3d//9Z hcBZdAIz9lZoJ15AAFfoHeD//4PEDGoBWF9ew1WL7IHsDAsAAItFFFNWV/91DDPbiRiNhfT0 //9Q6CYYAACNhfT0//9oRPBAAFDoJRgAAP91EI2F9PT//1DoFhgAAI2F9Pj//2gABAAAUI2F 9PT//1NQaAIAAIDoh+b//42F9Pj//1CNhfz+//9Q6NUXAACDxDSNhfT4//9oBAEAAFCNhfz+ //9Q/xXI0EAAvosJQQBTVugL1f//iUUUjYX0/P//U1BTjYX0+P//U1Do/xgAAIPEHDP/OV0U fitXVuix1P//OBhZWXQTUI2F9Pz//1DoqNz//1mFwFl1Bkc7fRR82jt9FHwkjYX0+P//aCMN QQBQ6Ibc//9ZhcBZdA2NhfT4//9Q6F/4//9ZU42F+P3//1NQjYX8/v//UI2F9Pj//1DoihgA AI2F+P3//1CNhfz+//9Q6BwXAACNhfz+//9Q6Hb+//+DxCBo6AMAAP8VLNFAAGoBWF9eW8nD VYvsgewIAQAAgKX4/v//AI2F+P7//2oBUOhf3P//jUX8UI2F+P7//2gIX0AAUGgCAACA6PPl //+DxBhogO42AP8VLNFAAOvBVYvsg30MAHU0g30QAHUIagX/FSzRQAD/dQjoftz//4XAWXwU g/gDfQ//dQho7DdJAOhsFgAAWVlqAVhdw/91COjT/f//hcBZdAQzwF3DM8A5RRAPlMBdw1WL 7IHsDAEAAICl9P7//wBTjYX0/v//aAQBAABQagFobQlBAOhP0///WVlQaFICQQBoAgAAgOiu 5P//jYX0/v//UOh5/f//D76F9P7//4qd9v7//1DobhkAAIPEHINl+ACIRf+KRfgEYTpF/3Q8 gKX2/v//AIiF9P7//42F9P7//1D/FczQQACD+AOInfb+//91F/91CI2F9P7//2iuYEAAUOhv 3f//g8QM/0X4g334GnyxM8BbycIEAFZohQlBAP90JBDogRUAAIt0JBBW6GcWAACDxAwzyYXA fguAPDFAdAVBO8h89Ug7yHwEM8Bew41EMQFQ/3QkEOhcFQAAWVlqAVhew1WL7IHsFAIAAIA9 1DJJAABWD4SbAAAAgD3QMUkAAA+EjgAAAIN9EACLdQh0ElboA7b///91DFbo0sD//4PEDGpk aAABAABqGWjUMkkAjY3s/f//6NjJ//9qBGoKjUWcagNQ6L3U//+DxBCNRZyNjez9//9Q6DvO //+DxmSNjez9//9W6OrO//9o0DFJAI2N7P3//+gxzv//jY3s/f//6MTK//+FwHQQjY3s/f// 6FDK//8zwF7Jw/91DOh2FQAAWVCNjez9////dQzo9Mr//42N7P3//4vw6CbK//8zwIX2D5TA 689Vi+yB7BgDAABWi3UIjYXo/P//UFbotv7//1mFwFl1BzPA6boAAACDfRAAdBJW6B61//// dQxW6O2///+DxAxqZGgAAQAAjYXo/P//ahlQjY3s/f//6PHI//9qBGoKjUWcagNQ6NbT//+D xBCNRZyNjez9//9Q6FTN//+NRmSNjez9//9Q6APO//9WjY3s/f//6E7N//+Njez9///o4cn/ /4XAdBCNjez9///obcn//+lr/////3UM6JMUAABZUI2N7P3///91DOgRyv//jY3s/f//i/Do Q8n//zPAhfYPlMBeycNVi+yB7AAIAACApQD4//8AgKUA/P//AI2FAPj//1D/dQjoxv3//42F APz//1D/dQzot/3//42FAPz//1CNhQD4//9Q6ARlAACDxBj32BvAQMnDg+wQVVZXg0wkGP+9 ABAAAGoBVb7U8EAA/3QkKDP/iXwkIFbops///4PEEIXAD4XvAAAAV1boTtD//1k7x1mJRCQQ D46yAAAAUzPbhf+JXCQQfjNTVuj+z///WVlQV1bo9M///1lZUOhC////WYXAWXQIx0QkEAEA AABDO9981IN8JBAAdUxqAY1fATtcJBhYiUQkEH0uU1bou8///1lZUFdW6LHP//9ZWVDo//7/ /1mFwFl0BP9EJBBDO1wkFHzWi0QkEDtEJBh+CIlEJBiJfCQcRzt8JBQPjGz///+DfCQYAFt+ FYN8JBgAfA5V/3QkHFbow8///4PEDDP/agFV/3QkKFboxc7//4PEEIXAdRJVav9W6KHP//+D xAxHg/8KfNpqAVhfXl2DxBDDgewEAgAAU1VWV8dEJBABAAAAMtu+Xg5BAL0EAQAAvwEAAID/ dCQQjUQkGIgd1DJJAIgd0DFJAFZo6ChBAFDoBBYAAIPEEFVo1DJJAGoBVujYzv//WVlQjUQk IFBX6Dvg//+DxBQ4HdQySQB0J1Vo0DFJAGoCVuixzv//WVlQjUQkIFBX6BTg//+DxBQ4HdAx SQB1F/9EJBCDfCQQCX6EiB3UMkkAiB3QMUkAX15dW4HEBAIAAMNVi+y4IDAAAOhLGQAAU1ZX aAAAEADobRkAADPbWTvDiUXsdQlfXjPAW8nCBADo8O3//4XAdQ1oYOoAAP8VLNFAAOvqaADQ BwD/NdgzSQDo0/X//1lZagHoovr//+jp/v//jYWI8///aAQBAABQU/8VFNFAAI2F3P7//1Do D9j//1mJXfi+JAkAAOiU7f//hcB1Cmhg6gAA6YcDAACNhdz+//9Q6LPX//+FwFl1Wo2F3P7/ /1NQjYWI8///UP8VfNBAAI2F3P7//2ogUP8VgNBAAI2F3P7//2gAUAEAUOjb6P//U+jG4P// M9K5ACgAAPfxjYXc/v//gcIAUgEAUlDoYtn//4PEFFP/NdgzSQDok83//zlF+FlZiUXoD439 AgAAaHoiAACNheDP//9owPBAAFDowRQAAI2F4M///4id9N///1CNhdz+//9Q6K3v//9WjYWM 9P//U1Doig8AAP91+P812DNJAOgKzf//g8QoOBiJReQPhJUCAABQjYXw9P//UOjBDwAAU+gh 4P//M9KDxAz3deg7Vfh1AUI7Veh8AjPSUv812DNJAOjIzP//i/hZWTgfdRBT/zXYM0kA6LTM //9Zi/hZjYXc/v//UI2FOPr//1Dobw8AAI2FVPX//1dQ6GIPAACNhYz0//9XUOhVDwAAagGN hYz0////dexQ6P/5//+DxCSFwA+FAAIAAFaNhYz0//9TUOjLDgAAjYXc/v//UI2FOPr//1Do GA8AAI2FVPX//1dQ6AsPAACNhYz0//9XUOj+DgAA/3XkjYXw9P//UOjvDgAAagGNhYz0//// dexQ6H76//+DxDiFwHQMV+in+///WemSAQAAU2jU8EAA6B7M//+DTeD/WVmJRfSJXfBWjYWM 9P//U1DoRg4AAI2F3P7//1CNhTj6//9Q6JMOAACNhVT1//9XUOiGDgAA/3XkjYXw9P//UOh3 DgAAU+jX3v//M9KDxCj3dfQ7VeCJVfx1BEKJVfw7VfR8A4ld/P91/GjU8EAA6HbL//9QjYWM 9P//UOg7DgAAagGNhYz0////dexQ6Mr5//+DxByFwHUT/0Xwi0X8g33wBolF4A+MXP///4N9 8AYPjM0AAABTaCwOQQDoWcv//1OJRfToWN7//zPSg8QM93X0O1X0iVX8fAOJXfyNhVzy//9Q jYWw/f//UFfoM9L//42FsP3//2g08EAAUOjKDQAA/3X8aCwOQQDo28r//1CNhbD9//9Q6LAN AABWjYWM9P//U1DoMg0AAI2F3P7//1CNhTj6//9Q6H8NAACNhVT1//9XUOhyDQAAg8RAjYXw 9P///3XkUOhgDQAAjYWw/f//UI2FjPT//1DoTQ0AAGoBjYWM9P///3XsUOjc+P//g8Qc/0X4 i0X4O0XoD4wD/f//aMAnCQD/FSzRQADpW/z//1WL7IHsYAUAAGah9ChBAFZXagdmiUWgWTPA jX2i86tmq6HwKEEAjX3oiUXkM8CrZqsz/8dF4CAAAAA5PfA4SQCJffSJffgPhd8BAAA5PQg5 SQAPhNMBAACLdQg793QljUXgUI1FgFD/FWTQQACNRYBQjUYCUOhwXgAAWYXAWQ+EpwEAAI2F WP///4NN0P+JRdiNhbD+//+JRcCNhbD+//+JRciNRYBTUI1FoIl9xFCJfdSJfdzHRcx/AAAA 6GkMAABZjYUY////WWoiUGr/Vos1eNBAAGoBV//Wx0X8AgAAALtE8EAAikX8ahQEQYhF5I2F WP///1CNReRq/1BqAVf/1opF5Go0iEWgjYWw/v//UI1FoGr/UGoBV//WjUX0UI1FwFCNhRj/ //9qAlD/FQg5SQA5fQyJRfAPhN4AAAA7x3VgOX34dVtqAWjcAUEAV+gr3P//WYPgAVCNhaT7 //9Q6MXW//+Nhaj8//9TUOinCwAAjUWgUI2FqPz//1DopwsAAGoBjYWk+///V1CNhaj8//9X UP91COh6vP//g8Q4iUX4OX3wdXVqAWjCDUEAjYWg+v//V1Dob9b///91CI2FrP3//1DoTwsA AI2FrP3//1NQ6FILAACNRaBQjYWs/f//UOhCCwAAjYWs/f//U1DoNQsAAI2FoPr//1CNhaz9 //9Q6CILAABqAWr/jYWs/f//av9Q6PwDAACDxEj/RfyDffwFD4y8/v//W19eycNVi+y4nEMA AOjuEgAAjUUMV1CDTfz//3UIx0X4gD4AAGoDagFfV/91DOgpWwAAhcAPhUABAACNRfhTUI2F ZLz//1CNRfxQ/3UM6ANbAAAz2zld/IldCA+GEQEAAFaNtXi8///2RvgCjUbsdBP/dRBqAlDo if///4PEDOnbAAAAjYXs/P//UI2F8P3//1D/NujZ3v//g8QMhcAPhbsAAAD/dRCNhfD9//9Q 6CP9//9ZWVdo3AFBAFPoldr//1kjx1CNheT6//9Q6DDV//+DxBA5XRAPhIIAAABXjYXk+v// U1CNhez8//9TUI2F8P3//1Do87r//4PEGFdowg1BAFPoTdr//1kjx1CNhej7//9Q6OjU//// No2F9P7//1DoyQkAAI2F9P7//2hE8EAAUOjICQAAjYXo+///UI2F9P7//1DotQkAAFdq/42F 9P7//2r/UOiQAgAAg8Q4/0UIg8Ygi0UIO0X8D4L3/v//Xv91DOjWWQAAW1/Jw2oBWFBqAmoA 6Hr+//+DxAxoAN1tAP8VLNFAADPA6+S4hCMAAOhZEQAAU1VWV41EJBRoBAEAADPbUFP/FRTR QACLPYDQQAC+5DVJAGogVv/XU41EJBhWUP8VfNBAAGogVolEJBj/1zlcJBB0Vmh6IgAAjYQk HAEAAGjA8EAAUOifDQAAjYQkJAEAAIicJDgRAABQVuiP6P//aABQAQBW6ETh//9T6C/Z//8z 0rkAKAAA9/GBwgBSAQBSVujR0f//g8QoVuh85v//WWonVv/XOR3wOEkAv9wzSQB0RVZXaOA0 SQBoAgAAgOiB1///agFokwtBAOioxf//g8QYUP8V9NBAAIvoaJMMQQBV/xU40UAAO8N0BWoB U//QVf8V8NBAADlcJBB1BDPA63U5HfA4SQB0C1NW6MvY//9ZWetfOR34OEkAdVeLLQDQQABq AlNT/9VTU1NTU1ZTagJoEAEAAFNXV1CJRCRE/xVI0EAA/3QkEIs1QNBAAP/WagFTU//Vi+hq EFdV/xU40EAAi/hTU1f/FSTQQABX/9ZV/9ZqAVhfXl1bgcSEIwAAw1WL7FGh8ChBAIlF/IpF CABF/I1F/FD/FczQQACD+AN0DIP4BHQHagFYycIEAGoAjUX8aHpcQABQ6FfP//+DxAxoAHS3 Af8VLNFAAOvgVYvsgexYAgAAVr5SAkEAjYXU/v//VlDoXwcAAGoHVuiFxP//UI2F1P7//1Do WgcAAIClqP3//wCNhaj9//9oLAEAAFCNhdT+//9o8A1BAFBoAgAAgOjA1f//agCNhaj9//9o elxAAFDo2s7//4PEODPAXsnCBABVi+y4kCUAAOgHDwAAi0UQU1aLdQwz21c5XRSJdfyJRfh1 Ef91COiu1///hcBZD4U+AQAAv3QNQQBTV+gixP//WTvzWYlFDH0PU+gb1///M9JZ93UMiVX8 vtwBQQBTVuj+w///OV0QWVmJRQx9D1Po9tb//zPSWfd1DIlV+I2F9P7//1Dows3//42F7Pz/ /8cEJAQBAABQU/8VFNFAAI2F9P7//1NQjYXs/P//UP8VfNBAAIXAD4S3AAAAjYX0/v//aiBQ /xWA0EAAaHoiAACNhXDa//9owPBAAFDo1AoAAI2FcNr//4idhOr//1CNhfT+//9Q6MDl//9T 6GvW//8z0rkAKAAA9/GNhfT+//+BwgBSAQBSUOgHz////3X8V+gOw///UI2F8P3//1Do0wUA AP91+Fbo+ML//1CNhfD9//9Q6M0FAACDxECNhfD9////dRRQjYX0/v//UP91COh34P//jYX0 /v//UOhKzf//g8QUX15bycNq//8VLNFAAOv2VYvsgewgAgAAagRqBY1F6GoCUOhKxf//gKXg /f//AIPEEI2F4P3//2gEAQAAUGoBaG0JQQDod8L//1lZUGhSAkEAaAIAAIDo1tP//4PEFI2F 5P7//1CNRehqAFCNheD9//9Q/xV00EAAjYXk/v//UOjDzP//jYXk/v//UOjyBQAAWVlIeAqA vAXk/v//LnXzhcB+FI2EBeT+//9o3AFBAFDo3QQAAFlZjUX8VlBophUAAGhAE0EA6OMCAAD/ dfyL8I2F5P7//1ZQ6CvL//+DxBiFwHUfjYXk/v//UOjpy////3X8jYXk/v//VlDoCMv//4PE EI2F5P7//2oAUOgT1f//WVlehcB0Fmr/UP8VwNBAAI2F5P7//1DoGsz//1kzwMnCBABVi+xR U1aLNdDQQABXjUX8M/9QV1do/xVAAFdX/9aNRfxQV1doCGZAAFdX/9aNRfxQV1do3m1AAFdX /9aNRfxQV1doZmBAAFdX/9aNRfxQV1dozXFAAFdX/9aNRfxQV1do1W9AAFdX/9Yz241F/FBX U2iIb0AAV1f/1kOD+xp86+hM/v//X15bycNVi+yD7BwzwMdF5BABAACJReyJRfCJRfSJRfiJ RfyNReRQx0XoBAAAAP81HDlJAP8VWNBAAOiT2P//hcB0Begz////ycIEAGh8c0AAaNwzSQD/ FTTQQABqAKMcOUkA6J3////CCABVi+yB7KABAACNhWD+//9QagL/FeDRQADo/+H//4XAdFTo 9fn//4A91ABBAAB0D2jUAEEA6PTm//+FwFl1N4M9+DhJAAB0IINl+ACDZfwAjUXwx0Xw3DNJ AFDHRfTDc0AA/xUE0EAA6PvX//+FwHQF6Jv+//8zwMnCEABVi+y4jDgBAOj2CgAAU1b/dQzo GwsAAIvYM/Y73lmJXfSJdfiJdfx1BzPA6dsAAABXaIA4AQCNhXTH/v9WUOhQAgAAg8QMM8CN vXjH/v87RQxzZotNCIoMCITJdA2IDB5GQIl1/DtFDHLpO0UMc0qLyItVCIA8EQB1BkE7TQxy 8YvRK9CD+gpzETvBc8GLVQiKFBCIFB5GQOvvgX34ECcAAHMP/0X4iUf8iReDxwiLweuciXX8 M/brSItF+Il1/Iv4wecDjVw3BFPoZAoAAIvwi0X4V4kGjYV0x/7/UI1GBFDovQYAAP91/I1E NwT/dfRQ6K0GAACLRRCDxByJGItd9FPohwYAAFmLxl9eW8nDVYvsg+wMU4tdCFZXiwMz0ov4 jUsEwecDiVX8iU30jXcEiUX4OXUMcwczwOmcAAAAhcB2I4vxiUUIiw470XMHK8oD0QFN/ItG BIXAdgID0IPGCP9NCHXii0UMK8eDwPw5RfyJRQxzBStF/APQi0UQM/YhdfxSiRDopwkAAI18 HwSLXfiF21l2LotN9Dsxcw+LVfyKFDqIFDBG/0X86+0z0jlRBHYLgCQwAEZCO1EEcvWDwQhL ddWLTfw7TQxzDgPwihQ5iBZGQTtNDHL0X15bycPM/yUc0UAA/yUM0UAA/yUQ0UAA/yUA0UAA zMzMzMzMzMzMzItUJASLTCQI98IDAAAAdTyLAjoBdS4KwHQmOmEBdSUK5HQdwegQOkECdRkK wHQROmEDdRCDwQSDwgQK5HXSi/8zwMOQG8DR4EDDi//3wgEAAAB0FIoCQjoBdelBCsB04PfC AgAAAHSoZosCg8ICOgF10grAdMo6YQF1yQrkdMGDwQLrjMzMzMzMzMzMzMzMzItUJAyLTCQE hdJ0RzPAikQkCFeL+YP6BHIt99mD4QN0CCvRiAdHSXX6i8jB4AgDwYvIweAQA8GLyoPiA8Hp AnQG86uF0nQGiAdHSnX6i0QkCF/Di0QkBMPMzMzMzMzMzFeLfCQI62qNpCQAAAAAi/+LTCQE V/fBAwAAAHQPigFBhMB0O/fBAwAAAHXxiwG6//7+fgPQg/D/M8KDwQSpAAEBgXToi0H8hMB0 I4TkdBqpAAD/AHQOqQAAAP90AuvNjXn/6w2Nef7rCI15/esDjXn8i0wkDPfBAwAAAHQZihFB hNJ0ZIgXR/fBAwAAAHXu6wWJF4PHBLr//v5+iwED0IPw/zPCixGDwQSpAAEBgXThhNJ0NIT2 dCf3wgAA/wB0EvfCAAAA/3QC68eJF4tEJAhfw2aJF4tEJAjGRwIAX8NmiReLRCQIX8OIF4tE JAhfw4tMJAT3wQMAAAB0FIoBQYTAdED3wQMAAAB18QUAAAAAiwG6//7+fgPQg/D/M8KDwQSp AAEBgXToi0H8hMB0MoTkdCSpAAD/AHQTqQAAAP90AuvNjUH/i0wkBCvBw41B/otMJAQrwcON Qf2LTCQEK8HDjUH8i0wkBCvBw1WL7FGDZfwAU4tdCFZXU+hx////g/gBWXIhgHsBOnUbi3UM hfZ0EGoCU1bojBAAAIPEDIBmAgBDQ+sKi0UMhcB0A4AgAINlDACAOwCLw77/AAAAiUUIdGWK CA+20faCYU1JAAR0A0DrGoD5L3QPgPlcdAqA+S51C4lF/OsGjUgBiU0MQIA4AHXPi30MiUUI hf90KoN9EAB0Hyv7O/5yAov+V1P/dRDoERAAAItFEIPEDIAkBwCLRQiLXQzrCotNEIXJdAOA IQCLffyF/3RMO/tySIN9FAB0Hyv7O/5yAov+V1P/dRTo0g8AAItFFIPEDIAkBwCLRQiLfRiF /3REK0X8O8ZzAovwVv91/Ffoqw8AAIPEDIAkPgDrKIt9FIX/dBcrwzvGcwKL8FZTV+iLDwAA g8QMgCQ+AItFGIXAdAOAIABfXlvJw1WL7FGDPTw5SQAAU3Udi0UIg/hhD4yvAAAAg/h6D4+m AAAAg+gg6Z4AAACLXQiB+wABAAB9KIM9HCxBAAF+DGoCU+gHEgAAWVnrC6EQKkEAigRYg+AC hcB1BIvD62uLFRAqQQCLw8H4CA+2yPZESgGAdA6AZQoAiEUIiF0JagLrCYBlCQCIXQhqAViN TfxqAWoAagNRUI1FCFBoAAIAAP81PDlJAOhVDwAAg8QghcB0qYP4AXUGD7ZF/OsND7ZF/Q+2 TfzB4AgLwVvJw1WL7FGDPTw5SQAAU1ZXdR2LRQiD+EEPjKoAAACD+FoPj6EAAACDwCDpmQAA AItdCL8AAQAAagE73159JTk1HCxBAH4LVlPoNxEAAFlZ6wqhECpBAIoEWCPGhcB1BIvD62WL FRAqQQCLw8H4CA+2yPZESgGAdA+AZQoAagKIRQiIXQlY6wmAZQkAiF0Ii8ZWagCNTfxqA1FQ jUUIUFf/NTw5SQDoiw4AAIPEIIXAdK47xnUGD7ZF/OsND7ZF/Q+2TfzB4AgLwV9eW8nDVYvs g+wgi0UIVolF6IlF4I1FEMdF7EIAAABQjUXg/3UMx0Xk////f1DoExIAAIPEDP9N5IvweAiL ReCAIADrDY1F4FBqAOjhEAAAWVmLxl7Jw/90JATo8BkAAFnDzMzMzMzMzMzMzFWL7FdWi3UM i00Qi30Ii8GL0QPGO/52CDv4D4J4AQAA98cDAAAAdRTB6QKD4gOD+QhyKfOl/ySVSH1AAIvH ugMAAACD6QRyDIPgAwPI/ySFYHxAAP8kjVh9QACQ/ySN3HxAAJBwfEAAnHxAAMB8QAAj0YoG iAeKRgGIRwGKRgLB6QKIRwKDxgODxwOD+QhyzPOl/ySVSH1AAI1JACPRigaIB4pGAcHpAohH AYPGAoPHAoP5CHKm86X/JJVIfUAAkCPRigaIB0bB6QJHg/kIcozzpf8klUh9QACNSQA/fUAA LH1AACR9QAAcfUAAFH1AAAx9QAAEfUAA/HxAAItEjuSJRI/ki0SO6IlEj+iLRI7siUSP7ItE jvCJRI/wi0SO9IlEj/SLRI74iUSP+ItEjvyJRI/8jQSNAAAAAAPwA/j/JJVIfUAAi/9YfUAA YH1AAGx9QACAfUAAi0UIXl/Jw5CKBogHi0UIXl/Jw5CKBogHikYBiEcBi0UIXl/Jw41JAIoG iAeKRgGIRwGKRgKIRwKLRQheX8nDkI10MfyNfDn898cDAAAAdSTB6QKD4gOD+QhyDf3zpfz/ JJXgfkAAi//32f8kjZB+QACNSQCLx7oDAAAAg/kEcgyD4AMryP8kheh9QAD/JI3gfkAAkPh9 QAAYfkAAQH5AAIpGAyPRiEcDTsHpAk+D+Qhytv3zpfz/JJXgfkAAjUkAikYDI9GIRwOKRgLB 6QKIRwKD7gKD7wKD+QhyjP3zpfz/JJXgfkAAkIpGAyPRiEcDikYCiEcCikYBwekCiEcBg+4D g+8Dg/kID4Ja/////fOl/P8kleB+QACNSQCUfkAAnH5AAKR+QACsfkAAtH5AALx+QADEfkAA 135AAItEjhyJRI8ci0SOGIlEjxiLRI4UiUSPFItEjhCJRI8Qi0SODIlEjwyLRI4IiUSPCItE jgSJRI8EjQSNAAAAAAPwA/j/JJXgfkAAi//wfkAA+H5AAAh/QAAcf0AAi0UIXl/Jw5CKRgOI RwOLRQheX8nDjUkAikYDiEcDikYCiEcCi0UIXl/Jw5CKRgOIRwOKRgKIRwKKRgGIRwGLRQhe X8nDi0QkBKMAKUEAw6EAKUEAacD9QwMABcOeJgCjAClBAMH4ECX/fwAAw8zMzFE9ABAAAI1M JAhyFIHpABAAAC0AEAAAhQE9ABAAAHPsK8iLxIUBi+GLCItABFDDagH/dCQI6IsWAABZWcNV i+yD7CCLRQjHRexJAAAAUIlF6IlF4OiH+P//iUXkjUUQUI1F4P91DFDouxYAAIPEEMnDzMzM zMzMzMzMzMzMzMzMVYvsV1aLdQyLTRCLfQiLwYvRA8Y7/nYIO/gPgngBAAD3xwMAAAB1FMHp AoPiA4P5CHIp86X/JJUogUAAi8e6AwAAAIPpBHIMg+ADA8j/JIVAgEAA/ySNOIFAAJD/JI28 gEAAkFCAQAB8gEAAoIBAACPRigaIB4pGAYhHAYpGAsHpAohHAoPGA4PHA4P5CHLM86X/JJUo gUAAjUkAI9GKBogHikYBwekCiEcBg8YCg8cCg/kIcqbzpf8klSiBQACQI9GKBogHRsHpAkeD +QhyjPOl/ySVKIFAAI1JAB+BQAAMgUAABIFAAPyAQAD0gEAA7IBAAOSAQADcgEAAi0SO5IlE j+SLRI7oiUSP6ItEjuyJRI/si0SO8IlEj/CLRI70iUSP9ItEjviJRI/4i0SO/IlEj/yNBI0A AAAAA/AD+P8klSiBQACL/ziBQABAgUAATIFAAGCBQACLRQheX8nDkIoGiAeLRQheX8nDkIoG iAeKRgGIRwGLRQheX8nDjUkAigaIB4pGAYhHAYpGAohHAotFCF5fycOQjXQx/I18Ofz3xwMA AAB1JMHpAoPiA4P5CHIN/fOl/P8klcCCQACL//fZ/ySNcIJAAI1JAIvHugMAAACD+QRyDIPg AyvI/ySFyIFAAP8kjcCCQACQ2IFAAPiBQAAggkAAikYDI9GIRwNOwekCT4P5CHK2/fOl/P8k lcCCQACNSQCKRgMj0YhHA4pGAsHpAohHAoPuAoPvAoP5CHKM/fOl/P8klcCCQACQikYDI9GI RwOKRgKIRwKKRgHB6QKIRwGD7gOD7wOD+QgPglr////986X8/ySVwIJAAI1JAHSCQAB8gkAA hIJAAIyCQACUgkAAnIJAAKSCQAC3gkAAi0SOHIlEjxyLRI4YiUSPGItEjhSJRI8Ui0SOEIlE jxCLRI4MiUSPDItEjgiJRI8Ii0SOBIlEjwSNBI0AAAAAA/AD+P8klcCCQACL/9CCQADYgkAA 6IJAAPyCQACLRQheX8nDkIpGA4hHA4tFCF5fycONSQCKRgOIRwOKRgKIRwKLRQheX8nDkIpG A4hHA4pGAohHAopGAYhHAYtFCF5fycODPRwsQQABfhFoAwEAAP90JAjoJAkAAFlZw4tEJASL DRAqQQBmiwRBJQMBAADDgz0cLEEAAX4OagT/dCQI6PkIAABZWcOLRCQEiw0QKkEAigRBg+AE w4M9HCxBAAF+DmoI/3QkCOjRCAAAWVnDi0QkBIsNECpBAIoEQYPgCMPMzMzMzMzMzMzMzMzM i0wkCFdTVooRi3wkEITSdGmKcQGE9nRPi/eLTCQUigdGONB0FYTAdAuKBkY40HQKhMB19V5b XzPAw4oGRjjwdeuNfv+KYQKE5HQoigaDxgI44HXEikEDhMB0GIpm/4PBAjjgdN/rsTPAXltf isLpQx0AAI1H/15bX8OLx15bX8NVi+xXVlOLTRDjJovZi30Ii/czwPKu99kDy4v+i3UM86aK Rv8zyTpH/3cEdARJSffRi8FbXl/Jw1WL7Gr/aEDSQABoBKxAAGShAAAAAFBkiSUAAAAAg+xY U1ZXiWXo/xW80EAAM9KK1IkVbDlJAIvIgeH/AAAAiQ1oOUkAweEIA8qJDWQ5SQDB6BCjYDlJ ADP2VugWJgAAWYXAdQhqHOiwAAAAWYl1/OhWJAAA/xXE0EAAo2hOSQDoFCMAAKMgOUkA6L0g AADo/x8AAOgcHQAAiXXQjUWkUP8VeNFAAOiQHwAAiUWc9kXQAXQGD7dF1OsDagpYUP91nFZW /xV00UAAUOi87v//iUWgUOgKHQAAi0XsiwiLCYlNmFBR6M4dAABZWcOLZej/dZjo/BwAAIM9 KDlJAAF1BeiAJwAA/3QkBOiwJwAAaP8AAAD/FRApQQBZWcODPSg5SQABdQXoWycAAP90JATo iycAAFlo/wAAAP8VfNFAAMNVi+yD7BhTVlf/dQjoiAEAAIvwWTs1OExJAIl1CA+EagEAADPb O/MPhFYBAAAz0rggKUEAOTB0coPAMEI9ECpBAHzxjUXoUFb/FYDRQACD+AEPhSQBAABqQDPA Wb9gTUkAg33oAYk1OExJAPOrqokdZE5JAA+G7wAAAIB97gAPhLsAAACNTe+KEYTSD4SuAAAA D7ZB/w+20jvCD4eTAAAAgIhhTUkABEDr7mpAM8BZv2BNSQDzq400Uold/MHmBKqNnjApQQCA OwCLy3QsilEBhNJ0JQ+2AQ+2+jvHdxSLVfyKkhgpQQAIkGFNSQBAO8d29UFBgDkAddT/RfyD wwiDffwEcsGLRQjHBUxMSQABAAAAUKM4TEkA6MYAAACNtiQpQQC/QExJAKWlWaNkTkkApetV QUGAef8AD4VI////agFYgIhhTUkACEA9/wAAAHLxVuiMAAAAWaNkTkkAxwVMTEkAAQAAAOsG iR1MTEkAM8C/QExJAKurq+sNOR0sOUkAdA7ojgAAAOiyAAAAM8DrA4PI/19eW8nDi0QkBIMl LDlJAACD+P51EMcFLDlJAAEAAAD/JYjRQACD+P11EMcFLDlJAAEAAAD/JYTRQACD+Px1D6FM OUkAxwUsOUkAAQAAAMOLRCQELaQDAAB0IoPoBHQXg+gNdAxIdAMzwMO4BAQAAMO4EgQAAMO4 BAgAAMO4EQQAAMNXakBZM8C/YE1JAPOrqjPAv0BMSQCjOExJAKNMTEkAo2ROSQCrq6tfw1WL 7IHsFAUAAI1F7FZQ/zU4TEkA/xWA0UAAg/gBD4UWAQAAM8C+AAEAAIiEBez+//9AO8Zy9IpF 8saF7P7//yCEwHQ3U1eNVfMPtgoPtsA7wXcdK8iNvAXs/v//QbggICAgi9nB6QLzq4vLg+ED 86pCQopC/4TAddBfW2oAjYXs+v///zVkTkkA/zU4TEkAUI2F7P7//1ZQagHo8yUAAGoAjYXs /f///zU4TEkAVlCNhez+//9WUFb/NWROSQDoaAEAAGoAjYXs/P///zU4TEkAVlCNhez+//9W UGgAAgAA/zVkTkkA6EABAACDxFwzwI2N7Pr//2aLEfbCAXQWgIhhTUkAEIqUBez9//+IkGBM SQDrHPbCAnQQgIhhTUkAIIqUBez8///r44CgYExJAABAQUE7xnK/60kzwL4AAQAAg/hBchmD +Fp3FICIYU1JABCKyIDBIIiIYExJAOsfg/hhchOD+Hp3DoCIYU1JACCKyIDpIOvggKBgTEkA AEA7xnK+XsnDgz0oTEkAAHUSav3oLPz//1nHBShMSQABAAAAw1WL7IM9TExJAABXi30IiX0I dRH/dRD/dQxX6ComAACDxAzrY4tVEFaF0nQ9i00MigFKD7bw9oZhTUkABIgHdBNHQYXSdBmK AUqIB0dBhMB0FOsGR0GEwHQQhdJ10usKgGf/AOsEgGf+AIvCSoXAXnQTjUoBM8CL0cHpAvOr i8qD4QPzqotFCF9dw1WL7Gr/aFjSQABoBKxAAGShAAAAAFBkiSUAAAAAg+wcU1ZXiWXoM/85 PTA5SQB1RldXagFbU2hQ0kAAvgABAABWV/8VPNFAAIXAdAiJHTA5SQDrIldXU2hM0kAAVlf/ FUDRQACFwA+EIgEAAMcFMDlJAAIAAAA5fRR+EP91FP91EOieAQAAWVmJRRShMDlJAIP4AnUd /3Uc/3UY/3UU/3UQ/3UM/3UI/xVA0UAA6d4AAACD+AEPhdMAAAA5fSB1CKFMOUkAiUUgV1f/ dRT/dRCLRST32BvAg+AIQFD/dSD/FXjQQACL2Ild5DvfD4ScAAAAiX38jQQbg8ADJPzoXfT/ /4ll6IvEiUXcg038/+sTagFYw4tl6DP/iX3cg038/4td5Dl93HRmU/913P91FP91EGoB/3Ug /xV40EAAhcB0TVdXU/913P91DP91CP8VPNFAAIvwiXXYO/d0MvZFDQR0QDl9HA+EsgAAADt1 HH8e/3Uc/3UYU/913P91DP91CP8VPNFAAIXAD4WPAAAAM8CNZciLTfBkiQ0AAAAAX15bycPH RfwBAAAAjQQ2g8ADJPzoqfP//4ll6IvciV3gg038/+sSagFYw4tl6DP/M9uDTfz/i3XYO990 tFZT/3Xk/3Xc/3UM/3UI/xU80UAAhcB0nDl9HFdXdQRXV+sG/3Uc/3UYVlNoIAIAAP91IP8V oNBAAIvwO/cPhHH///+Lxuls////i1QkCItEJASF0laNSv90DYA4AHQIQIvxSYX2dfOAOABe dQUrRCQEw4vCw1WL7FGLRQiNSAGB+QABAAB3DIsNECpBAA+3BEHrUovIVos1ECpBAMH5CA+2 0fZEVgGAXnQOgGX+AIhN/IhF/WoC6wmAZf0AiEX8agFYjU0KagFqAGoAUVCNRfxQagHotSEA AIPEHIXAdQLJww+3RQojRQzJw1WL7FNWi3UMi0YMi14QqIIPhPMAAACoQA+F6wAAAKgBdBaD ZgQAqBAPhNsAAACLTggk/okOiUYMi0YMg2YEAINlDAAk7wwCZqkMAYlGDHUigf6gLUEAdAiB /sAtQQB1C1PoHiYAAIXAWXUHVujPJQAAWWb3RgwIAVd0ZItGCIs+K/iNSAGJDotOGEmF/4lO BH4QV1BT6PkjAACDxAyJRQzrM4P7/3QWi8OLy8H4BYPhH4sEhSBLSQCNBMjrBbjILEEA9kAE IHQNagJqAFPoJyMAAIPEDItGCIpNCIgI6xRqAY1FCF9XUFPopiMAAIPEDIlFDDl9DF90BoNO DCDrD4tFCCX/AAAA6wgMIIlGDIPI/15bXcNVi+yB7EgCAABTVleLfQwz9oofR4TbiXX0iXXs iX0MD4T0BgAAi03wM9LrCItN8It10DPSOVXsD4zcBgAAgPsgfBOA+3h/Dg++w4qAUNJAAIPg D+sCM8APvoTGcNJAAMH4BIP4B4lF0A+HmgYAAP8khfuUQACDTfD/iVXMiVXYiVXgiVXkiVX8 iVXc6XgGAAAPvsOD6CB0O4PoA3Qtg+gIdB9ISHQSg+gDD4VZBgAAg038COlQBgAAg038BOlH BgAAg038Aek+BgAAgE38gOk1BgAAg038AuksBgAAgPsqdSONRRBQ6PUGAACFwFmJReAPjRIG AACDTfwE99iJReDpBAYAAItF4A++y40EgI1EQdDr6YlV8OntBQAAgPsqdR6NRRBQ6LYGAACF wFmJRfAPjdMFAACDTfD/6coFAACNBIkPvsuNREHQiUXw6bgFAACA+0l0LoD7aHQggPtsdBKA +3cPhaAFAACATf0I6ZcFAACDTfwQ6Y4FAACDTfwg6YUFAACAPzZ1FIB/ATR1DkdHgE39gIl9 DOlsBQAAiVXQiw0QKkEAiVXcD7bD9kRBAYB0GY1F7FD/dQgPvsNQ6H8FAACKH4PEDEeJfQyN RexQ/3UID77DUOhmBQAAg8QM6SUFAAAPvsOD+GcPjxwCAACD+GUPjZYAAACD+FgPj+sAAAAP hHgCAACD6EMPhJ8AAABISHRwSEh0bIPoDA+F6QMAAGb3RfwwCHUEgE39CIt18IP+/3UFvv// /3+NRRBQ6JwFAABm90X8EAhZi8iJTfgPhP4BAACFyXUJiw0sLEEAiU34x0XcAQAAAIvBi9ZO hdIPhNQBAABmgzgAD4TKAQAAQEDr58dFzAEAAACAwyCDTfxAjb24/f//O8qJffgPjc8AAADH RfAGAAAA6dEAAABm90X8MAh1BIBN/Qhm90X8EAiNRRBQdDvoMAUAAFCNhbj9//9Q6HUjAACD xAyJRfSFwH0yx0XYAQAAAOspg+hadDKD6Al0xUgPhOgBAADpCAMAAOjYBAAAWYiFuP3//8dF 9AEAAACNhbj9//+JRfjp5wIAAI1FEFDoswQAAIXAWXQzi0gEhcl0LPZF/Qh0Fw+/ANHoiU34 iUX0x0XcAQAAAOm1AgAAg2XcAIlN+A+/AOmjAgAAoSgsQQCJRfhQ6Y4AAAB1DID7Z3UHx0Xw AQAAAItFEP91zIPACIlFEP918ItI+IlNuItA/IlFvA++w1CNhbj9//9QjUW4UP8VADBBAIt1 /IPEFIHmgAAAAHQUg33wAHUOjYW4/f//UP8VDDBBAFmA+2d1EoX2dQ6Nhbj9//9Q/xUEMEEA WYC9uP3//y11DYBN/QGNvbn9//+JffhX6GHm//9Z6fwBAACD6GkPhNEAAACD6AUPhJ4AAABI D4SEAAAASHRRg+gDD4T9/f//SEgPhLEAAACD6AMPhckBAADHRdQnAAAA6zwrwdH46bQBAACF yXUJiw0oLEEAiU34i8GL1k6F0nQIgDgAdANA6/ErwemPAQAAx0XwCAAAAMdF1AcAAAD2RfyA x0X0EAAAAHRdikXUxkXqMARRx0XkAgAAAIhF6+tI9kX8gMdF9AgAAAB0O4BN/QLrNY1FEFDo GwMAAPZF/CBZdAlmi03sZokI6wWLTeyJCMdF2AEAAADpIwIAAINN/EDHRfQKAAAA9kX9gHQM jUUQUOjtAgAAWetB9kX8IHQh9kX8QI1FEFB0DOjIAgAAWQ+/wJnrJei8AgAAWQ+3wOvy9kX8 QI1FEFB0COinAgAAWevg6J8CAABZM9L2RfxAdBuF0n8XfASFwHMR99iD0gCL8PfagE39AYv6 6wSL8Iv69kX9gHUDg+cAg33wAH0Jx0XwAQAAAOsEg2X894vGC8d1BINl5ACNRbeJRfiLRfD/ TfCFwH8Gi8YLx3Q7i0X0mVJQV1aJRcCJVcTobyEAAP91xIvYg8Mw/3XAV1bo7SAAAIP7OYvw i/p+AwNd1ItF+P9N+IgY67WNRbcrRfj/Rfj2Rf0CiUX0dBmLTfiAOTB1BIXAdQ3/TfhAi034 xgEwiUX0g33YAA+F9AAAAItd/PbDQHQm9scBdAbGReot6xT2wwF0BsZF6ivrCfbDAnQLxkXq IMdF5AEAAACLdeArdeQrdfT2wwx1Eo1F7FD/dQhWaiDoFwEAAIPEEI1F7FCNRer/dQj/deRQ 6DIBAACDxBD2wwh0F/bDBHUSjUXsUP91CFZqMOjlAAAAg8QQg33cAHRBg330AH47i0X0i134 jXj/ZosDQ1CNRchQQ+iWHwAAWYXAWX4yjU3sUf91CFCNRchQ6NgAAACDxBCLx0+FwHXQ6xWN RexQ/3UI/3X0/3X46LoAAACDxBD2RfwEdBKNRexQ/3UIVmog6HEAAACDxBCLfQyKH0eE24l9 DA+FE/n//4tF7F9eW8nDeY9AAE+OQABqjkAAto5AAO2OQAD1jkAAKo9AAL2PQABVi+yLTQz/ SQR4DosRikUIiAL/AQ+2wOsLUf91COiI9///WVmD+P+LRRB1BYMI/13D/wBdw1ZXi3wkEIvH T4XAfiGLdCQYVv90JBj/dCQU6Kz///+DxAyDPv90B4vHT4XAf+NfXsNTi1wkDIvDS1ZXhcB+ Jot8JByLdCQQD74GV0b/dCQcUOh1////g8QMgz//dAeLw0uFwH/iX15bw4tEJASDAASLAItA /MOLRCQEgwAIiwiLQfiLUfzDi0QkBIMABIsAZotA/MNWi3QkCIX2dCRW6MAfAABZhcBWdApQ 6N8fAABZWV7DagD/NQRLSQD/FZDRQABew/81uDpJAP90JAjoAwAAAFlZw4N8JATgdyL/dCQE 6BwAAACFwFl1FjlEJAh0EP90JATodScAAIXAWXXeM8DDVot0JAg7NSAwQQB3C1bopSIAAIXA WXUchfZ1A2oBXoPGD4Pm8FZqAP81BEtJAP8VlNFAAF7DVYvsgezEAQAAgGXrAFNWi3UMM9tX igaJXfyEwIldzA+E4QkAAIt9COsFi30IM9uDPRwsQQABfg8PtsBqCFDohvX//1lZ6w+LDRAq QQAPtsCKBEGD4Ag7w3Q2/038V41F/FdQ6CUKAABZWVDoBgoAAA+2RgFGUOhp7P//g8QMhcB0 Dg+2RgFGUOhX7P//WevugD4lD4XZCAAAgGXLAIBl6ACAZekAgGXyAIBl8QCAZeoAM/+AZfsA iV3kiV3giV30xkXzAYld0A+2XgFGgz0cLEEAAX4PD7bDagRQ6On0//9ZWesPiw0QKkEAD7bD igRBg+AEhcB0EotF9P9F4I0EgI1EQ9CJRfTrZYP7Tn8+dF6D+yp0MoP7RnRUg/tJdAqD+0x1 N/5F8+tFgH4BNnUsgH4CNI1GAnUj/0XQg2XYAINl3ACL8Osn/kXy6yKD+2h0F4P7bHQKg/t3 dAj+RfHrDv5F8/5F++sG/k3z/k37gH3xAA+ET////4B98gCJdQx1EotFEIlFvIPABIlFEItA /IlF1IBl8QCAffsAdRSKBjxTdAo8Q3QGgE37/+sExkX7AYtdDA+2M4POIIP+bol1xHQog/5j dBSD/nt0D/91CI1F/FDotQgAAFnrC/91CP9F/Oh2CAAAWYlF7DPAOUXgdAk5RfQPhNwHAACD /m8Pj14CAAAPhAoFAACD/mMPhCwCAACD/mQPhPgEAAAPjmoCAACD/md+OIP+aXQbg/5uD4VX AgAAgH3yAIt9/A+EAAcAAOkhBwAAamRei13sg/stD4V+AgAAxkXpAel6AgAAi13sjbU8/v// g/stdQ6InTz+//+NtT3+///rBYP7K3UXi30I/030/0X8V+jOBwAAi9hZiV3s6wOLfQiDfeAA dAmBffRdAQAAfgfHRfRdAQAAgz0cLEEAAX4MagRT6Anz//9ZWesLoRAqQQCKBFiD4ASFwHQh i0X0/030hcB0F/9F5IgeRv9F/FfocAcAAIvYWYld7Ou7OB0gLEEAdWaLRfT/TfSFwHRc/0X8 V+hNBwAAi9igICxBAIgGWYld7EaDPRwsQQABfgxqBFPom/L//1lZ6wuhECpBAIoEWIPgBIXA dCGLRfT/TfSFwHQX/0XkiB5G/0X8V+gCBwAAi9hZiV3s67uDfeQAD4SOAAAAg/tldAmD+0UP hYAAAACLRfT/TfSFwHR2xgZlRv9F/FfoywYAAIvYWYP7LYld7HUFiAZG6wWD+yt1HotF9P9N 9IXAdQUhRfTrD/9F/FfongYAAIvYWYld7IM9HCxBAAF+DGoEU+j08f//WVnrC6EQKkEAigRY g+AEhcB0EotF9P9N9IXAdAj/ReSIHkbru/9N/FdT6HIGAACDfeQAWVkPhPYFAACAffIAD4VN BQAA/0XMgCYAjYU8/v//UA++RfP/ddRIUP8VCDBBAIPEDOkpBQAAOUXgdQr/RfTHReABAAAA gH37AH4ExkXqAb84LEEA6QsBAACLxoPocA+EowIAAIPoAw+E6AAAAEhID4SWAgAAg+gDD4TD /f//g+gDdCQPtgM7RewPhT8FAAD+TeuAffIAD4XDBAAAi0W8iUUQ6bgEAACAffsAfgTGReoB i30MR4l9DIA/Xg+FpwAAAIvHjXgB6ZkAAACD+yt1Iv9N9HUMg33gAHQGxkXxAesR/3UI/0X8 6GgFAACL2FmJXeyD+zAPhUUCAAD/dQj/RfzoTgUAAIvYWYD7eIld7HQvgPtYdCqD/njHReQB AAAAdAhqb17pFgIAAP91CP9N/FPoOAUAAFlZajBb6f0BAAD/dQj/RfzoCQUAAFmL2Ild7Gp4 68+AffsAfgTGReoBvzAsQQCATej/aiCNRZxqAFDo7Nr//4PEDIN9xHt1DoA/XXUJsl1HxkWn IOsDilXLigc8XXRfRzwtdUGE0nQ9ig+A+V10Nkc60XMEisHrBIrCitE60HchD7bSD7bwK/JG i8qLwoPhB7MBwegD0uONRAWcCBhCTnXoMtLrtA+2yIrQi8GD4QezAcHoA9LjjUQFnAgY65uA PwAPhAEEAACDfcR7dQOJfQyLfQiLddT/TfxX/3XsiXXQ6FMEAABZWYN94AB0DotF9P9N9IXA D4ScAAAA/0X8V+gaBAAAg/j/WYlF7HR+i8hqAYPhB1oPvl3o0+KLyMH5Aw++TA2cM8uF0XRg gH3yAHVSgH3qAHRBiw0QKkEAiEXID7bA9kRBAYB0Df9F/FfoywMAAFmIRcn/NRwsQQCNRchQ jUXCUOiqIAAAZotFwoPEDGaJBkZG6wOIBkaJddTpZP////9F0Olc/////038V1DoowMAAFlZ OXXQD4QoAwAAgH3yAA+FfwIAAP9FzIN9xGMPhHICAACAfeoAi0XUdAlmgyAA6WACAACAIADp WAIAAMZF8wGLXeyD+y11BsZF6QHrBYP7K3Ui/030dQyDfeAAdAbGRfEB6xH/dQj/RfzoGgMA AFmL2Ild7IN90AAPhA8BAACAffEAD4XjAAAAg/54dU+DPRwsQQABfg9ogAAAAFPoVO7//1lZ 6w2hECpBAIoEWCWAAAAAhcAPhKMAAACLRdiLVdxqBFnozSAAAFOJRdiJVdzofQIAAIvYWYld 7OtTgz0cLEEAAX4MagRT6Aju//9ZWesLoRAqQQCKBFiD4ASFwHRdg/5vdRWD+zh9U4tF2ItV 3GoDWeh9IAAA6w9qAGoK/3Xc/3XY6CwgAACJRdiJVdz/ReSNQ9CZAUXYEVXcg33gAHQF/030 dCT/dQj/RfzoNgIAAIvYWYld7Okr/////3UI/038U+g5AgAAWVmAfekAD4TcAAAAi0XYi03c 99iD0QCJRdj32YlN3OnEAAAAgH3xAA+FsgAAAIP+eHQ/g/5wdDqDPRwsQQABfgxqBFPoQ+3/ /1lZ6wuhECpBAIoEWIPgBIXAdHaD/m91CoP7OH1swecD6z+NPL/R5+s4gz0cLEEAAX4PaIAA AABT6Abt//9ZWesNoRAqQQCKBFglgAAAAIXAdDdTwecE6EQBAACL2FmJXez/ReSDfeAAjXwf 0HQF/030dCT/dQj/RfzoWAEAAIvYWYld7Olc/////3UI/038U+hbAQAAWVmAfekAdAL334P+ RnUEg2XkAIN95AAPhM4AAACAffIAdSn/RcyDfdAAdBCLRdSLTdiJCItN3IlIBOsQgH3zAItF 1HQEiTjrA2aJOP5F6/9FDIt1DOtC/0X8V+jhAAAAi9hZD7YGRjvDiV3siXUMdVWLDRAqQQAP tsP2REEBgHQY/0X8V+i3AAAAWQ+2DkY7yIl1DHU+/038g33s/3UQgD4ldU2LRQyAeAFudUSL 8IoGhMAPhVb2///rMP91CP9N/P917OsF/038V1PoiwAAAFlZ6xf/TfxXUOh9AAAA/038V1Po cwAAAIPEEIN97P91EYtFzIXAdQ04Ret1CIPI/+sDi0XMX15bycODPRwsQQABVn4Qi3QkCGoE VuiO6///WVnrD4t0JAihECpBAIoEcIPgBIXAdQaD5t+D7geLxl7Di1QkBP9KBHgJiwoPtgFB iQrDUugUHgAAWcODfCQE/3QP/3QkCP90JAjo1x4AAFlZw1aLdCQIV/90JBD/Bui+////i/hX 6D7i//9ZhcBZdeeLx19ew8zMzMzMzMzMjUL/W8ONpCQAAAAAjWQkADPAikQkCFOL2MHgCItU JAj3wgMAAAB0E4oKQjjZdNGEyXRR98IDAAAAde0L2FeLw8HjEFYL2IsKv//+/n6LwYv3M8sD 8AP5g/H/g/D/M88zxoPCBIHhAAEBgXUcJQABAYF00yUAAQEBdQiB5gAAAIB1xF5fWzPAw4tC /DjYdDaEwHTvONx0J4TkdOfB6BA42HQVhMB03DjcdAaE5HTU65ZeX41C/1vDjUL+Xl9bw41C /V5fW8ONQvxeX1vDoTRMSQCFwHQC/9BoFPBAAGgI8EAA6M4AAABoBPBAAGgA8EAA6L8AAACD xBDDagBqAP90JAzoFQAAAIPEDMNqAGoB/3QkDOgEAAAAg8QMw1dqAV85PZw5SQB1Ef90JAj/ FazQQABQ/xUo0UAAg3wkDABTi1wkFIk9mDlJAIgdlDlJAHU8oTBMSQCFwHQiiw0sTEkAVo1x /DvwchOLBoXAdAL/0IPuBDs1MExJAHPtXmgg8EAAaBjwQADoKgAAAFlZaCjwQABoJPBAAOgZ AAAAWVmF21t1EP90JAiJPZw5SQD/FXzRQABfw1aLdCQIO3QkDHMNiwaFwHQC/9CDxgTr7V7D VYvsU/91COg1AQAAhcBZD4QgAQAAi1gIhdsPhBUBAACD+wV1DINgCABqAVjpDQEAAIP7AQ+E 9gAAAIsNoDlJAIlNCItNDIkNoDlJAItIBIP5CA+FyAAAAIsNuCxBAIsVvCxBAAPRVjvKfRWN NEkr0Y00tUgsQQCDJgCDxgxKdfeLAIs1xCxBAD2OAADAdQzHBcQsQQCDAAAA63A9kAAAwHUM xwXELEEAgQAAAOtdPZEAAMB1DMcFxCxBAIQAAADrSj2TAADAdQzHBcQsQQCFAAAA6zc9jQAA wHUMxwXELEEAggAAAOskPY8AAMB1DMcFxCxBAIYAAADrET2SAADAdQrHBcQsQQCKAAAA/zXE LEEAagj/01mJNcQsQQBZXusIg2AIAFH/01mLRQijoDlJAIPI/+sJ/3UM/xWY0UAAW13Di1Qk BIsNwCxBADkVQCxBAFa4QCxBAHQVjTRJjTS1QCxBAIPADDvGcwQ5EHX1jQxJXo0MjUAsQQA7 wXMEORB0AjPAw4M9KExJAAB1Bei75P//Vos1aE5JAIoGPCJ1JYpGAUY8InQVhMB0EQ+2wFDo lBsAAIXAWXTmRuvjgD4idQ1G6wo8IHYGRoA+IHf6igaEwHQEPCB26YvGXsNTM9s5HShMSQBW V3UF6F/k//+LNSA5SQAz/4oGOsN0Ejw9dAFHVugr0///WY10BgHr6I0EvQQAAABQ6Orw//+L 8Fk784k1fDlJAHUIagnoEeD//1mLPSA5SQA4H3Q5VVfo8dL//4voWUWAPz10IlXotfD//zvD WYkGdQhqCeji3///WVf/Nujb0f//WYPGBFkD/Tgfdcld/zUgOUkA6Fjw//9ZiR0gOUkAiR5f XscFJExJAAEAAABbw1WL7FFRUzPbOR0oTEkAVld1Beih4///vqQ5SQBoBAEAAFZT/xUU0UAA oWhOSQCJNYw5SQCL/jgYdAKL+I1F+FCNRfxQU1NX6E0AAACLRfiLTfyNBIhQ6BXw//+L8IPE GDvzdQhqCOhA3///WY1F+FCNRfxQi0X8jQSGUFZX6BcAAACLRfyDxBRIiTV0OUkAX16jcDlJ AFvJw1WL7ItNGItFFFNWgyEAi3UQV4t9DMcAAQAAAItFCIX/dAiJN4PHBIl9DIA4InVEilAB QID6InQphNJ0JQ+20vaCYU1JAAR0DP8BhfZ0BooQiBZGQP8BhfZ01YoQiBZG687/AYX2dASA JgBGgDgidUZA60P/AYX2dAWKEIgWRooQQA+22vaDYU1JAAR0DP8BhfZ0BYoYiB5GQID6IHQJ hNJ0CYD6CXXMhNJ1A0jrCIX2dASAZv8Ag2UYAIA4AA+E4AAAAIoQgPogdAWA+gl1A0Dr8YA4 AA+EyAAAAIX/dAiJN4PHBIl9DItVFP8Cx0UIAQAAADPbgDhcdQRAQ+v3gDgidSz2wwF1JTP/ OX0YdA2AeAEijVABdQSLwusDiX0Ii30MM9I5VRgPlMKJVRjR64vTS4XSdA5DhfZ0BMYGXEb/ AUt184oQhNJ0SoN9GAB1CoD6IHQ/gPoJdDqDfQgAdC6F9nQZD7ba9oNhTUkABHQGiBZGQP8B ihCIFkbrDw+20vaCYU1JAAR0A0D/Af8BQOlY////hfZ0BIAmAEb/AekX////hf90A4MnAItF FF9eW/8AXcNRUaGoOkkAU1WLLajRQABWVzPbM/Yz/zvDdTP/1YvwO/N0DMcFqDpJAAEAAADr KP8VpNFAAIv4O/sPhOoAAADHBag6SQACAAAA6Y8AAACD+AEPhYEAAAA783UM/9WL8DvzD4TC AAAAZjkei8Z0DkBAZjkYdflAQGY5GHXyK8aLPaDQQADR+FNTQFNTUFZTU4lEJDT/14voO+t0 MlXogu3//zvDWYlEJBB0I1NTVVD/dCQkVlNT/9eFwHUO/3QkEOgw7f//WYlcJBCLXCQQVv8V oNFAAIvD61OD+AJ1TDv7dQz/FaTRQACL+Dv7dDw4H4vHdApAOBh1+0A4GHX2K8dAi+hV6Bvt //+L8Fk783UEM/brC1VXVuj10v//g8QMV/8VnNFAAIvG6wIzwF9eXVtZWcOD7ERTVVZXaAAB AADo4Oz//4vwWYX2dQhqG+gN3P//WYk1IEtJAMcFIExJACAAAACNhgABAAA78HMagGYEAIMO /8ZGBQqhIEtJAIPGCAUAAQAA6+KNRCQQUP8VeNFAAGaDfCRCAA+ExQAAAItEJESFwA+EuQAA AIswjWgEuAAIAAA78I0cLnwCi/A5NSBMSQB9Ur8kS0kAaAABAADoUOz//4XAWXQ4gwUgTEkA IIkHjYgAAQAAO8FzGIBgBACDCP/GQAUKiw+DwAiBwQABAADr5IPHBDk1IExJAHy76waLNSBM SQAz/4X2fkaLA4P4/3Q2ik0A9sEBdC72wQh1C1D/FWzRQACFwHQei8eLz8H4BYPhH4sEhSBL SQCNBMiLC4kIik0AiEgER0WDwwQ7/ny6M9uhIEtJAIM82P+NNNh1TYXbxkYEgXUFavZY6wqL w0j32BvAg8D1UP8VcNFAAIv4g///dBdX/xVs0UAAhcB0DCX/AAAAiT6D+AJ1BoBOBEDrD4P4 A3UKgE4ECOsEgE4EgEOD+wN8m/81IExJAP8VjNFAAF9eXVuDxETDM8BqADlEJAhoABAAAA+U wFD/FWTRQACFwKMES0kAdBXogwoAAIXAdQ//NQRLSQD/FWjRQAAzwMNqAVjDzMzMVYvsU1ZX VWoAagBoJKtAAP91COieHAAAXV9eW4vlXcOLTCQE90EEBgAAALgBAAAAdA+LRCQIi1QkEIkC uAMAAADDU1ZXi0QkEFBq/mgsq0AAZP81AAAAAGSJJQAAAACLRCQgi1gIi3AMg/7/dC47dCQk dCiNNHaLDLOJTCQIiUgMg3yzBAB1EmgBAQAAi0SzCOhAAAAA/1SzCOvDZI8FAAAAAIPEDF9e W8MzwGSLDQAAAACBeQQsq0AAdRCLUQyLUgw5UQh1BbgBAAAAw1NRu9QsQQDrClNRu9QsQQCL TQiJSwiJQwSJawxZW8IEAMzMVkMyMFhDMDBVi+yD7AhTVldV/ItdDItFCPdABAYAAAAPhYIA AACJRfiLRRCJRfyNRfiJQ/yLcwyLewiD/v90YY0MdoN8jwQAdEVWVY1rEP9UjwRdXotdDAvA dDN4PIt7CFPoqf7//4PEBI1rEFZT6N7+//+DxAiNDHZqAYtEjwjoYf///4sEj4lDDP9UjwiL ewiNDHaLNI/robgAAAAA6xy4AQAAAOsVVY1rEGr/U+ie/v//g8QIXbgBAAAAXV9eW4vlXcNV i0wkCIspi0EcUItBGFDoef7//4PECF3CBAChKDlJAIP4AXQNhcB1KoM9FClBAAF1IWj8AAAA 6BgAAAChrDpJAFmFwHQC/9Bo/wAAAOgCAAAAWcNVi+yB7KQBAACLVQgzybjoLEEAOxB0C4PA CEE9eC1BAHzxVovxweYDO5boLEEAD4UcAQAAoSg5SQCD+AEPhOgAAACFwHUNgz0UKUEAAQ+E 1wAAAIH6/AAAAA+E8QAAAI2FXP7//2gEAQAAUGoA/xUU0UAAhcB1E42FXP7//2i81UAAUOiz yf//WVmNhVz+//9XUI29XP7//+iOyv//QFmD+Dx2KY2FXP7//1Doe8r//4v4jYVc/v//g+g7 agMD+Gi41UAAV+jhAQAAg8QQjYVg////aJzVQABQ6F3J//+NhWD///9XUOhgyf//jYVg//// aJjVQABQ6E/J////tuwsQQCNhWD///9Q6D3J//9oECABAI2FYP///2hw1UAAUOhfEgAAg8Qs X+smjUUIjbbsLEEAagBQ/zbo7sn//1lQ/zZq9P8VcNFAAFD/FWzQQABeycNVi+xq/2jY1UAA aASsQABkoQAAAABQZIklAAAAAIPsGFNWV4ll6KGwOkkAM9s7w3U+jUXkUGoBXlZoUNJAAFb/ FVTRQACFwHQEi8brHY1F5FBWaEzSQABWU/8VWNFAAIXAD4TOAAAAagJYo7A6SQCD+AJ1JItF HDvDdQWhPDlJAP91FP91EP91DP91CFD/FVjRQADpnwAAAIP4AQ+FlAAAADldGHUIoUw5SQCJ RRhTU/91EP91DItFIPfYG8CD4AhAUP91GP8VeNBAAIlF4DvDdGOJXfyNPACLx4PAAyT86BTQ //+JZeiL9Il13FdTVuiUx///g8QM6wtqAVjDi2XoM9sz9oNN/P8783Qp/3XgVv91EP91DGoB /3UY/xV40EAAO8N0EP91FFBW/3UI/xVU0UAA6wIzwI1lzItN8GSJDQAAAABfXlvJw8zMzMzM zMzMzMzMzMzMzItMJAxXhcl0elZTi9mLdCQU98YDAAAAi3wkEHUHwekCdW/rIYoGRogHR0l0 JYTAdCn3xgMAAAB164vZwekCdVGD4wN0DYoGRogHR4TAdC9LdfOLRCQQW15fw/fHAwAAAHQS iAdHSQ+EigAAAPfHAwAAAHXui9nB6QJ1bIgHR0t1+ltei0QkCF/DiReDxwRJdK+6//7+fosG A9CD8P8zwosWg8YEqQABAYF03oTSdCyE9nQe98IAAP8AdAz3wgAAAP91xokX6xiB4v//AACJ F+sOgeL/AAAAiRfrBDPSiReDxwQzwEl0CjPAiQeDxwRJdfiD4wN1hYtEJBBbXl/Di0QkBFM7 BSBMSQBWV3Nzi8iL8MH5BYPmH408jSBLSQDB5gOLD/ZEMQQBdFZQ6BIRAACD+P9ZdQzHBVQ5 SQAJAAAA60//dCQYagD/dCQcUP8V5NBAAIvYg/v/dQj/FeDQQADrAjPAhcB0CVDo8w8AAFnr IIsHgGQwBP2NRDAEi8PrFIMlWDlJAADHBVQ5SQAJAAAAg8j/X15bw1WL7IHsFAQAAItNCFM7 DSBMSQBWVw+DeQEAAIvBi/HB+AWD5h+NHIUgS0kAweYDiwOKRDAEqAEPhFcBAAAz/zl9EIl9 +Il98HUHM8DpVwEAAKggdAxqAldR6Aj///+DxAyLAwPG9kAEgA+EwQAAAItFDDl9EIlF/Il9 CA+G5wAAAI2F7Pv//4tN/CtNDDtNEHMpi038/0X8igmA+Qp1B/9F8MYADUCICECLyI2V7Pv/ /yvKgfkABAAAfMyL+I2F7Pv//yv4jUX0agBQjYXs+///V1CLA/80MP8VbNBAAIXAdEOLRfQB Rfg7x3wLi0X8K0UMO0UQcooz/4tF+DvHD4WLAAAAOX0IdF9qBVg5RQh1TMcFVDlJAAkAAACj WDlJAOmAAAAA/xXg0EAAiUUI68eNTfRXUf91EP91DP8w/xVs0EAAhcB0C4tF9Il9CIlF+Oun /xXg0EAAiUUI65z/dQjoZA4AAFnrPYsD9kQwBEB0DItFDIA4Gg+Ezf7//8cFVDlJABwAAACJ PVg5SQDrFitF8OsUgyVYOUkAAMcFVDlJAAkAAACDyP9fXlvJw/8FtDpJAGgAEAAA6P7i//9Z i0wkBIXAiUEIdA2DSQwIx0EYABAAAOsRg0kMBI1BFIlBCMdBGAIAAACLQQiDYQQAiQHDi0Qk BDsFIExJAHIDM8DDi8iD4B/B+QWLDI0gS0kAikTBBIPgQMOhAEtJAFZqFIXAXnUHuAACAADr BjvGfQeLxqMAS0kAagRQ6KkOAABZo+Q6SQCFwFl1IWoEVok1AEtJAOiQDgAAWaPkOkkAhcBZ dQhqGuiN0f//WTPJuIAtQQCLFeQ6SQCJBBGDwCCDwQQ9ADBBAHzqM9K5kC1BAIvCi/LB+AWD 5h+LBIUgS0kAiwTwg/j/dASFwHUDgwn/g8EgQoH58C1BAHzUXsPokg8AAIA9lDlJAAB0BemV DgAAw1WL7ItFCIXAdQJdw4M9PDlJAAB1EmaLTQxmgfn/AHc5agGICFhdw41NCINlCABRagD/ NRwsQQBQjUUMagFQaCACAAD/NUw5SQD/FaDQQACFwHQGg30IAHQNxwVUOUkAKgAAAIPI/13D U1aLRCQYC8B1GItMJBSLRCQQM9L38YvYi0QkDPfxi9PrQYvIi1wkFItUJBCLRCQM0enR29Hq 0dgLyXX09/OL8PdkJBiLyItEJBT35gPRcg47VCQQdwhyBztEJAx2AU4z0ovGXlvCEADMzMzM zMzMzFOLRCQUC8B1GItMJBCLRCQMM9L38YtEJAj38YvCM9LrUIvIi1wkEItUJAyLRCQI0enR 29Hq0dgLyXX09/OLyPdkJBSR92QkEAPRcg47VCQMdwhyDjtEJAh2CCtEJBAbVCQUK0QkCBtU JAz32vfYg9oAW8IQAGhAAQAAagD/NQRLSQD/FZTRQACFwKPgOkkAdQHDgyXYOkkAAIMl3DpJ AABqAaPUOkkAxwXMOkkAEAAAAFjDodw6SQCNDICh4DpJAI0MiDvBcxSLVCQEK1AMgfoAABAA cgeDwBTr6DPAw1WL7IPsFItVDItNCFNWi0EQi/IrcQyLWvyDwvxXwe4Pi86LevxpyQQCAABL iX38jYwBRAEAAIld9IlN8IsME/bBAYlN+HV/wfkEaj9JX4lNDDvPdgOJfQyLTBMEO0wTCHVI i00Mg/kgcxy/AAAAgNPvjUwBBPfXIXywRP4JdSuLTQghOeskg8HgvwAAAIDT74tNDI1MAQT3 1yG8sMQAAAD+CXUGi00IIXkEi0wTCIt8EwSJeQSLTBMEi3wTCANd+Il5CIld9Iv7wf8ET4P/ P3YDaj9fi038g+EBiU3sD4WgAAAAK1X8i038wfkEaj+JVfhJWjvKiU0MdgWJVQyLygNd/Iv7 iV30wf8ETzv6dgKL+jvPdGuLTfiLUQQ7UQh1SItNDIP5IHMcugAAAIDT6o1MAQT30iFUsET+ CXUri00IIRHrJIPB4LoAAACA0+qLTQyNTAEE99IhlLDEAAAA/gl1BotNCCFRBItN+ItRCItJ BIlKBItN+ItRBItJCIlKCItV+IN97AB1CTl9DA+EiQAAAItN8I0M+YtJBIlKBItN8I0M+YlK CIlRBItKBIlRCItKBDtKCHVjikwHBIP/IIhND/7BiEwHBHMlgH0PAHUOuwAAAICLz9Pri00I CRm7AAAAgIvP0+uNRLBECRjrKYB9DwB1EI1P4LsAAACA0+uLTQgJWQSNT+C/AAAAgNPvjYSw xAAAAAk4i130i0XwiRqJXBP8/wgPhfoAAACh2DpJAIXAD4TfAAAAiw3QOkkAiz1g0UAAweEP A0gMuwCAAABoAEAAAFNR/9eLDdA6SQCh2DpJALoAAACA0+oJUAih2DpJAIsN0DpJAItAEIOk iMQAAAAAodg6SQCLQBD+SEOh2DpJAItIEIB5QwB1CYNgBP6h2DpJAIN4CP91bFNqAP9wDP/X odg6SQD/cBBqAP81BEtJAP8VkNFAAKHcOkkAixXgOkkAjQSAweACi8ih2DpJACvIjUwR7FGN SBRRUOgPx///i0UIg8QM/w3cOkkAOwXYOkkAdgOD6BSLDeA6SQCJDdQ6SQDrA4tFCKPYOkkA iTXQOkkAX15bycNVi+yD7BSh3DpJAIsV4DpJAFNWjQSAV408gotFCIl9/I1IF4Ph8IlN8MH5 BEmD+SB9DoPO/9Pug034/4l19OsQg8Hgg8j/M/bT6Il19IlF+KHUOkkAi9g734ldCHMZi0sE izsjTfgj/gvPdQuDwxQ7XfyJXQhy5ztd/HV5i9o72IldCHMVi0sEizsjTfgj/gvPdQWDwxTr 5jvYdVk7XfxzEYN7CAB1CIPDFIldCOvtO138dSaL2jvYiV0Icw2DewgAdQWDwxTr7jvYdQ7o OAIAAIvYhduJXQh0FFPo2gIAAFmLSxCJAYtDEIM4/3UHM8DpDwIAAIkd1DpJAItDEIsQg/r/ iVX8dBSLjJDEAAAAi3yQRCNN+CP+C891N4uQxAAAAItwRCNV+CN19INl/ACNSEQL1ot19HUX i5GEAAAA/0X8I1X4g8EEi/4jOQvXdOmLVfyLyjP/ackEAgAAjYwBRAEAAIlN9ItMkEQjznUN i4yQxAAAAGogI034X4XJfAXR4Ufr94tN9ItU+QSLCitN8IvxiU34wf4EToP+P34Daj9eO/cP hA0BAACLSgQ7Sgh1YYP/IH0ruwAAAICLz9Pri038jXw4BPfTiV3sI1yIRIlciET+D3U4i10I i03sIQvrMY1P4LsAAACA0+uLTfyNfDgEjYyIxAAAAPfTIRn+D4ld7HULi10Ii03sIUsE6wOL XQiLSgiLegSDffgAiXkEi0oEi3oIiXkID4SUAAAAi030i3zxBI0M8Yl6BIlKCIlRBItKBIlR CItKBDtKCHVkikwGBIP+IIhNC30p/sGAfQsAiEwGBHULvwAAAICLztPvCTu/AAAAgIvO0++L TfwJfIhE6y/+wYB9CwCITAYEdQ2NTuC/AAAAgNPvCXsEi038jbyIxAAAAI1O4L4AAACA0+4J N4tN+IXJdAuJColMEfzrA4tN+It18APRjU4BiQqJTDL8i3X0iw6FyY15AYk+dRo7Hdg6SQB1 EotN/DsN0DpJAHUHgyXYOkkAAItN/IkIjUIEX15bycOh3DpJAIsNzDpJAFZXM/87wXUwjUSJ UMHgAlD/NeA6SQBX/zUES0kA/xVM0UAAO8d0YYMFzDpJABCj4DpJAKHcOkkAiw3gOkkAaMRB AABqCI0EgP81BEtJAI00gf8VlNFAADvHiUYQdCpqBGgAIAAAaAAAEABX/xVQ0UAAO8eJRgx1 FP92EFf/NQRLSQD/FZDRQAAzwOsXg04I/4k+iX4E/wXcOkkAi0YQgwj/i8ZfXsNVi+xRi00I U1ZXi3EQi0EIM9uFwHwF0eBD6/eLw2o/acAEAgAAWo2EMEQBAACJRfyJQAiJQASDwAhKdfSL +2oEwecPA3kMaAAQAABoAIAAAFf/FVDRQACFwHUIg8j/6ZMAAACNlwBwAAA7+nc8jUcQg0j4 /4OI7A8AAP+NiPwPAADHQPzwDwAAiQiNiPzv//+JSATHgOgPAADwDwAABQAQAACNSPA7ynbH i0X8jU8MBfgBAABqAV+JSASJQQiNSgyJSAiJQQSDZJ5EAIm8nsQAAACKRkOKyP7BhMCLRQiI TkN1Awl4BLoAAACAi8vT6vfSIVAIi8NfXlvJw6G8OkkAhcB0D/90JAT/0IXAWXQEagFYwzPA w1WL7FNWi3UMM9s783QVOV0QdBCKBjrDdRCLRQg7w3QDZokYM8BeW13DOR08OUkAdROLTQg7 y3QHZg+2wGaJAWoBWOvhiw0QKkEAD7bA9kRBAYB0TaEcLEEAg/gBfio5RRB8LzPJOV0ID5XB Uf91CFBWagn/NUw5SQD/FXjQQACFwKEcLEEAdZ05RRByBTheAXWTxwVUOUkAKgAAAIPI/+uE M8A5XQgPlcBQ/3UIagFWagn/NUw5SQD/FXjQQACFwA+Fef///+vKzMzMzMzMzMzMzMzMzMzM i0QkCItMJBALyItMJAx1CYtEJAT34cIQAFP34YvYi0QkCPdkJBQD2ItEJAj34QPTW8IQAMzM zMzMzMzMzMzMzID5QHMVgPkgcwYPpcLT4MOL0DPAgOEf0+LDM8Az0sNWi3QkCItGDKiDD4TE AAAAqEAPhbwAAACoAnQKDCCJRgzprgAAAAwBZqkMAYlGDHUJVui/8///WesFi0YIiQb/dhj/ dgj/dhDozgQAAIPEDIlGBIXAdGyD+P90Z4tWDPbCgnU0i04QV4P5/3QUi/nB/wWD4R+LPL0g S0kAjTzP6wW/yCxBAIpPBF+A4YKA+YJ1BoDOIIlWDIF+GAACAAB1FItODPbBCHQM9sUEdQfH RhgAEAAAiw5IiUYED7YBQYkOXsP32BvAg+AQg8AQCUYMg2YEAIPI/17DU4tcJAiD+/9WdEGL dCQQi0YMqAF1CKiAdDKoAnUug34IAHUHVujz8v//WYsGO0YIdQmDfgQAdRRAiQb2RgxAdBH/ DosGOBh0D0CJBoPI/15bw/8OiwaIGItGDP9GBCTvDAGJRgyLwyX/AAAA6+FqBGoA/3QkDOgE AAAAg8QMww+2RCQEikwkDISIYU1JAHUcg3wkCAB0Dg+3BEUaKkEAI0QkCOsCM8CFwHUBw2oB WMNTM9s5HcA6SQBWV3VCaBTWQAD/FfTQQACL+Dv7dGeLNTjRQABoCNZAAFf/1oXAo8A6SQB0 UGj41UAAV//WaOTVQABXo8Q6SQD/1qPIOkkAocQ6SQCFwHQW/9CL2IXbdA6hyDpJAIXAdAVT /9CL2P90JBj/dCQY/3QkGFP/FcA6SQBfXlvDM8Dr+ItMJAQz0okNWDlJALgwMEEAOwh0IIPA CEI9mDFBAHzxg/kTch2D+SR3GMcFVDlJAA0AAADDiwTVNDBBAKNUOUkAw4H5vAAAAHISgfnK AAAAxwVUOUkACAAAAHYKxwVUOUkAFgAAAMOLTCQEVjsNIExJAFdzVYvBi/HB+AWD5h+NPIUg S0kAweYDiwcDxvZABAF0N4M4/3Qygz0UKUEAAXUfM8AryHQQSXQISXUTUGr06whQavXrA1Bq 9v8VSNFAAIsHgwww/zPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19ew4tEJAQ7BSBMSQBzHIvI g+AfwfkFiwyNIEtJAPZEwQQBjQTBdAOLAMODJVg5SQAAxwVUOUkACQAAAIPI/8NTVot0JAxX D690JBSD/uCL3ncNhfZ1A2oBXoPGD4Pm8DP/g/7gdyo7HSAwQQB3DVPolfb//4v4WYX/dStW agj/NQRLSQD/FZTRQACL+IX/dSKDPbg6SQAAdBlW6B/7//+FwFl0FOu5U2oAV+hBtP//g8QM i8dfXlvDM8Dr+FZXagMz/145NQBLSQB+RKHkOkkAiwSwhcB0L/ZADIN0DVDoPQMAAIP4/1l0 AUeD/hR8F6HkOkkA/zSw6OjS//+h5DpJAFmDJLAARjs1AEtJAHy8i8dfXsNWi3QkCIX2dQlW 6JEAAABZXsNW6CMAAACFwFl0BYPI/17D9kYNQHQP/3YQ6DIDAAD32FleG8DDM8Bew1NWi3Qk DDPbV4tGDIvIg+EDgPkCdTdmqQgBdDGLRgiLPiv4hf9+JldQ/3YQ6Njt//+DxAw7x3UOi0YM qIB0DiT9iUYM6weDTgwgg8v/i0YIg2YEAIkGX4vDXlvDagHoAgAAAFnDU1ZXM/Yz2zP/OTUA S0kAfk2h5DpJAIsEsIXAdDiLSAz2wYN0MIN8JBABdQ9Q6C7///+D+P9ZdB1D6xqDfCQQAHUT 9sECdA5Q6BP///+D+P9ZdQIL+EY7NQBLSQB8s4N8JBABi8N0AovHX15bw2oC6CbB//9Zw1WL 7IPsDFNWi3UIVzs1IExJAA+DxQEAAIvGg+YfwfgFweYDjRyFIEtJAIsEhSBLSQADxopQBPbC AQ+EngEAAINl+ACLfQyDfRAAi890Z/bCAnVi9sJIdB2KQAU8CnQW/00QiAeLA41PAcdF+AEA AADGRDAFCo1F9GoAUIsD/3UQUf80MP8VcNBAAIXAdTr/FeDQQABqBVk7wXUVxwVUOUkACQAA AIkNWDlJAOk+AQAAg/htdQczwOk1AQAAUOg1/P//WekmAQAAiwOLVfQBVfiNTDAEikQwBKiA D4T4AAAAhdJ0CYA/CnUEDATrAiT7iAGLRQyLTfiJRRADyDvBiU34D4PLAAAAi0UQigA8Gg+E rgAAADwNdAuIB0f/RRDpkQAAAEk5TRBzGItFEECAOAp1BoNFEALrXsYHDUeJRRDrc41F9GoA UP9FEI1F/2oBUIsD/zQw/xVw0EAAhcB1Cv8V4NBAAIXAdUeDffQAdEGLA/ZEMARIdBOKRf88 CnQXxgcNiwtHiEQxBespO30MdQuAff8KdQXGBwrrGGoBav//dQjo7er//4PEDIB9/wp0BMYH DUeLTfg5TRAPgkf////rEIsDjXQwBIoGqEB1BAwCiAYrfQyJffiLRfjrFIMlWDlJAADHBVQ5 SQAJAAAAg8j/X15bycNWi3QkCFeDz/+LRgyoQHQFg8j/6zqog3Q0VugQ/f//Vov46DkBAAD/ dhDofgAAAIPEDIXAfQWDz//rEotGHIXAdAtQ6HzP//+DZhwAWYvHg2YMAF9ew4tEJAQ7BSBM SQBzPYvIi9DB+QWD4h+LDI0gS0kA9kTRBAF0JVDoYvv//1lQ/xVE0UAAhcB1CP8V4NBAAOsC M8CFwHQSo1g5SQDHBVQ5SQAJAAAAg8j/w1NVVleLfCQUOz0gTEkAD4OGAAAAi8eL98H4BYPm H40chSBLSQDB5gOLA/ZEMAQBdGlX6P76//+D+P9ZdDyD/wF0BYP/AnUWagLo5/r//2oBi+jo 3vr//1k7xVl0HFfo0vr//1lQ/xUk0UAAhcB1Cv8V4NBAAIvo6wIz7VfoOvr//4sDWYBkMAQA he10CVXowfn//1nrFTPA6xSDJVg5SQAAxwVUOUkACQAAAIPI/19eXVvDVot0JAiLRgyog3Qd qAh0Gf92COhMzv//ZoFmDPf7M8BZiQaJRgiJRgRew8zMzMzM/yW40UAA/yW00UAA/yWw0UAA /yVc0UAAVYvsUaE8OUkAUzPbO8OJXfx1IYtFCIvQOBh0f4oKgPlhfAqA+Xp/BYDpIIgKQjga derrZ1ZXagFTU1Nq/74AAgAA/3UIVlDo7cH//4v4g8QgO/t0OFfo8M3//zvDWYlF/HQqagFT V1Bq//91CFb/NTw5SQDowMH//4PEIIXAdA3/dfz/dQjo/a7//1lZ/3X86IfN//+LRQhZX15b ycPMzMzMzMzMzMzMVYvsV1ZTi00QC8kPhJUAAACLdQiLfQyNBTQ5SQCDeAgAdUO3QbNatiCN SQCKJgrkigd0IQrAdB1GRzj8cgY43HcCAuY4+HIGONh3AgLGOMR1CUl11zPJOMR0S7n///// ckT32etAM8Az24v/igYLwIofdCML23QfRkdRUFPo3LH//4vYg8QE6NKx//+DxARZO8N1CUl1 1TPJO8N0Cbn/////cgL32YvBW15fycPMzMxVi+xXVlOLdQyLfQiNBTQ5SQCDeAgAdTuw/4v/ CsB0LooGRoonRzjEdPIsQTwaGsmA4SACwQRBhuAsQTwaGsmA4SACwQRBOOB00hrAHP8PvsDr NLj/AAAAM9uL/wrAdCeKBkaKH0c42HTyUFPoPbH//4vYg8QE6DOx//+DxAQ4w3TaG8CD2P9b Xl/Jw1WL7FGhPDlJAFMz2zvDiV38dSGLRQiL0DgYdH+KCoD5QXwKgPlafwWAwSCICkI4GnXq 62dWV2oBU1NTav++AAEAAP91CFZQ6AnA//+L+IPEIDv7dDhX6AzM//87w1mJRfx0KmoBU1dQ av//dQhW/zU8OUkA6Ny///+DxCCFwHQN/3X8/3UI6Bmt//9ZWf91/Oijy///i0UIWV9eW8nD AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAJbcAACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrd AADq3AAA2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAA QNoAAFLaAABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7a AAD02QAALtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA 3tkAAKTZAADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZ AAD82AAALtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAA nN4AAA7gAAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbe AABa3gAAbN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAA AAAAAC7eAAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMA AIAXAACAAAAAAAAAAAAAAAAABQAAAAAAAAAHAAAACQAAAAUAAAACAAAAAgAAAAIAAAACAAAA DAAZAAEAAQACAA4ACgAfAAQAAQADABkACAAPAAIAAgALAAIAAQAGAP////8vhUAAQ4VAAAAA AAAAAAAAAAAAAP////8Ri0AAFYtAAP/////Fi0AAyYtAAAYAAAYAAQAAEAADBgAGAhAERUVF BQUFBQU1MABQAAAAACAoOFBYBwgANzAwV1AHAAAgIAgAAAAACGBoYGBgYAAAcHB4eHh4CAcI AAAHAAgICAAACAAIAAcIAAAAKABuAHUAbABsACkAAAAAAChudWxsKQAAcnVudGltZSBlcnJv ciAAAA0KAABUTE9TUyBlcnJvcg0KAAAAU0lORyBlcnJvcg0KAAAAAERPTUFJTiBlcnJvcg0K AABSNjAyOA0KLSB1bmFibGUgdG8gaW5pdGlhbGl6ZSBoZWFwDQoAAAAAUjYwMjcNCi0gbm90 IGVub3VnaCBzcGFjZSBmb3IgbG93aW8gaW5pdGlhbGl6YXRpb24NCgAAAABSNjAyNg0KLSBu b3QgZW5vdWdoIHNwYWNlIGZvciBzdGRpbyBpbml0aWFsaXphdGlvbg0KAAAAAFI2MDI1DQot IHB1cmUgdmlydHVhbCBmdW5jdGlvbiBjYWxsDQoAAABSNjAyNA0KLSBub3QgZW5vdWdoIHNw YWNlIGZvciBfb25leGl0L2F0ZXhpdCB0YWJsZQ0KAAAAAFI2MDE5DQotIHVuYWJsZSB0byBv cGVuIGNvbnNvbGUgZGV2aWNlDQoAAAAAUjYwMTgNCi0gdW5leHBlY3RlZCBoZWFwIGVycm9y DQoAAAAAUjYwMTcNCi0gdW5leHBlY3RlZCBtdWx0aXRocmVhZCBsb2NrIGVycm9yDQoAAAAA UjYwMTYNCi0gbm90IGVub3VnaCBzcGFjZSBmb3IgdGhyZWFkIGRhdGENCgANCmFibm9ybWFs IHByb2dyYW0gdGVybWluYXRpb24NCgAAAABSNjAwOQ0KLSBub3QgZW5vdWdoIHNwYWNlIGZv ciBlbnZpcm9ubWVudA0KAFI2MDA4DQotIG5vdCBlbm91Z2ggc3BhY2UgZm9yIGFyZ3VtZW50 cw0KAAAAUjYwMDINCi0gZmxvYXRpbmcgcG9pbnQgbm90IGxvYWRlZA0KAAAAAE1pY3Jvc29m dCBWaXN1YWwgQysrIFJ1bnRpbWUgTGlicmFyeQAAAAAKCgAAUnVudGltZSBFcnJvciEKClBy b2dyYW06IAAAAC4uLgA8cHJvZ3JhbSBuYW1lIHVua25vd24+AAAAAAAA/////2GvQABlr0AA R2V0TGFzdEFjdGl2ZVBvcHVwAABHZXRBY3RpdmVXaW5kb3cATWVzc2FnZUJveEEAdXNlcjMy LmRsbAAA6NYAAAAAAAAAAAAAFNwAAGTQAACE1gAAAAAAAAAAAADw3QAAANAAAETYAAAAAAAA AAAAAP7dAADA0QAANNgAAAAAAAAAAAAAPt4AALDRAAAAAAAAAAAAAAAAAAAAAAAAAAAAAJbc AACo3AAA2N0AAMDdAACe3QAAit0AALDdAABk3QAAUN0AAHrdAAAe3QAAEt0AADrdAADq3AAA 2twAAAjdAABu3AAAXtwAAITcAAA+3AAAMNwAAEzcAADG3AAAItwAAAAAAAAg2gAAQNoAAFLa AABe2gAAatoAAAraAAA02gAAnNoAALLaAAC+2gAAztoAAODaAADQ2QAAftoAAI7aAAD02QAA LtsAAEDbAABW2wAAatsAAILbAACS2wAAotsAALDbAADG2wAA2NsAAPTbAAAE3AAA3tkAAKTZ AADE2QAAtNkAAPDaAAAC2wAAdtkAAHDYAACQ2AAAktkAAITZAAA+2QAAYNkAAFDZAAD82AAA LtkAABjZAADK2AAA7NgAAN7YAACg2AAAttgAAK7YAAAQ2wAAHtsAAH7YAACs3gAAnN4AAA7g AAD+3wAA8N8AAODfAADO3wAAvN8AALDfAACi3wAAlN8AAIbfAAB43wAAaN8AAEbeAABa3gAA bN4AAHreAACG3gAAkN4AAFbfAAC83gAAyN4AANTeAADw3gAACt8AACTfAAA83wAAAAAAAC7e AAAa3gAACt4AAAAAAAA0AACAAwAAgHQAAIAQAACAEwAAgAkAAIAEAACAbwAAgHMAAIAXAACA AAAAALQARnJlZUxpYnJhcnkAPgFHZXRQcm9jQWRkcmVzcwAAwgFMb2FkTGlicmFyeUEAABsA Q2xvc2VIYW5kbGUAlgJTbGVlcACeAlRlcm1pbmF0ZVByb2Nlc3MAABwCUmVhZFByb2Nlc3NN ZW1vcnkA7wFPcGVuUHJvY2VzcwDZAU1vZHVsZTMyRmlyc3QATABDcmVhdGVUb29saGVscDMy U25hcHNob3QAACQBR2V0TW9kdWxlRmlsZU5hbWVBAAD+AVByb2Nlc3MzMk5leHQA/AFQcm9j ZXNzMzJGaXJzdAAA1gFNYXBWaWV3T2ZGaWxlADUAQ3JlYXRlRmlsZU1hcHBpbmdBAAASAUdl dEZpbGVTaXplADQAQ3JlYXRlRmlsZUEAsAJVbm1hcFZpZXdPZkZpbGUAGwFHZXRMb2NhbFRp bWUAABoBR2V0TGFzdEVycm9yAADMAUxvY2FsRnJlZQDIAUxvY2FsQWxsb2MAAPgAR2V0Q3Vy cmVudFByb2Nlc3NJZADSAldpZGVDaGFyVG9NdWx0aUJ5dGUA5AFNdWx0aUJ5dGVUb1dpZGVD aGFyAM4AR2V0Q29tcHV0ZXJOYW1lQQAAKABDb3B5RmlsZUEAuQFJc0RCQ1NMZWFkQnl0ZQAA 3wJXcml0ZUZpbGUAGAJSZWFkRmlsZQAAYwFHZXRUZW1wRmlsZU5hbWVBAABlAUdldFRlbXBQ YXRoQQAAVwBEZWxldGVGaWxlQQBoAlNldEZpbGVBdHRyaWJ1dGVzQQAAkABGaW5kQ2xvc2UA nQBGaW5kTmV4dEZpbGVBAJQARmluZEZpcnN0RmlsZUEAAGECU2V0RW5kT2ZGaWxlAABqAlNl dEZpbGVQb2ludGVyAAAUAUdldEZpbGVUaW1lAGwCU2V0RmlsZVRpbWUAbQFHZXRUaWNrQ291 bnQAAEQAQ3JlYXRlUHJvY2Vzc0EAAFkBR2V0U3lzdGVtRGlyZWN0b3J5QQD3AEdldEN1cnJl bnRQcm9jZXNzAJsCU3lzdGVtVGltZVRvRmlsZVRpbWUAAF0BR2V0U3lzdGVtVGltZQB1AUdl dFZlcnNpb25FeEEAdAFHZXRWZXJzaW9uAADOAldhaXRGb3JTaW5nbGVPYmplY3QAygBHZXRD b21tYW5kTGluZUEAgABFeHBhbmRFbnZpcm9ubWVudFN0cmluZ3NBAAQBR2V0RHJpdmVUeXBl QQBKAENyZWF0ZVRocmVhZAAAS0VSTkVMMzIuZGxsAABbAVJlZ0Nsb3NlS2V5AGYBUmVnRW51 bUtleUEAcQFSZWdPcGVuS2V5QQBkAVJlZ0RlbGV0ZVZhbHVlQQBqAVJlZ0VudW1WYWx1ZUEA NABDbG9zZVNlcnZpY2VIYW5kbGUAAEwAQ3JlYXRlU2VydmljZUEAAEUBT3BlblNDTWFuYWdl ckEAALMBU3RhcnRTZXJ2aWNlQ3RybERpc3BhdGNoZXJBAK4BU2V0U2VydmljZVN0YXR1cwAA RwFPcGVuU2VydmljZUEAAI4BUmVnaXN0ZXJTZXJ2aWNlQ3RybEhhbmRsZXJBAJ0ARnJlZVNp ZACYAEVxdWFsU2lkAAAYAEFsbG9jYXRlQW5kSW5pdGlhbGl6ZVNpZAAA0ABHZXRUb2tlbklu Zm9ybWF0aW9uAEIBT3BlblByb2Nlc3NUb2tlbgAAXAFSZWdDb25uZWN0UmVnaXN0cnlBALIB U3RhcnRTZXJ2aWNlQQB7AVJlZ1F1ZXJ5VmFsdWVFeEEAAIYBUmVnU2V0VmFsdWVFeEEAAF4B UmVnQ3JlYXRlS2V5QQAXAEFkanVzdFRva2VuUHJpdmlsZWdlcwD1AExvb2t1cFByaXZpbGVn ZVZhbHVlQQBBRFZBUEkzMi5kbGwAAFdTMl8zMi5kbGwAABEAV05ldENsb3NlRW51bQAcAFdO ZXRFbnVtUmVzb3VyY2VBAEAAV05ldE9wZW5FbnVtQQBNUFIuZGxsACYBR2V0TW9kdWxlSGFu ZGxlQQAAUAFHZXRTdGFydHVwSW5mb0EAfQBFeGl0UHJvY2VzcwC/AEdldENQSW5mbwC5AEdl dEFDUAAAMQFHZXRPRU1DUAAAvwFMQ01hcFN0cmluZ0EAAMABTENNYXBTdHJpbmdXAACfAUhl YXBGcmVlAACZAUhlYXBBbGxvYwCtAlVuaGFuZGxlZEV4Y2VwdGlvbkZpbHRlcgAAsgBGcmVl RW52aXJvbm1lbnRTdHJpbmdzQQCzAEZyZWVFbnZpcm9ubWVudFN0cmluZ3NXAAYBR2V0RW52 aXJvbm1lbnRTdHJpbmdzAAgBR2V0RW52aXJvbm1lbnRTdHJpbmdzVwAAbQJTZXRIYW5kbGVD b3VudAAAUgFHZXRTdGRIYW5kbGUAABUBR2V0RmlsZVR5cGUAnQFIZWFwRGVzdHJveQCbAUhl YXBDcmVhdGUAAL8CVmlydHVhbEZyZWUALwJSdGxVbndpbmQAUwFHZXRTdHJpbmdUeXBlQQAA VgFHZXRTdHJpbmdUeXBlVwAAuwJWaXJ0dWFsQWxsb2MAAKIBSGVhcFJlQWxsb2MAfAJTZXRT dGRIYW5kbGUAAKoARmx1c2hGaWxlQnVmZmVycwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA W4lAAG+zQAAAAAAAAAAAABS0QAAAAAAAAAAAAAAAAAAAAAAAMw1BAEAAAAAgAAAALAAAAC0t AABcAAAAUVVJVA0KAAANCi4NCgAAAERBVEEgDQoASEVMTyAlcw0KAAAAPg0KAE1BSUwgRlJP TTogPAAAAABSQ1BUIFRPOjwAAAAlZAAAIAkNCgAAAAAuLCgpJSRAIWB+IAAtXwAALi4AAC4A AABcKi4qAAAAAFxcAAAAAAAAiRV37zMZmXgQWLjJ8pkAAANEL3rVxcXFRgc/N38fPzd/NV8/ L0SH7083h+9PN0bVzV83NV8/L0RPJ4WNRvdv1w+XPzc1N2/nRFcP12dGZw93T181Xz8vRA9P H0YHPzd/Hz83fzVfPy9Ejz/vL29GBz83fx8/N381Xz8vROc/L0b/Tw8HTzd/NV8/LzUHH0Tv Z1dG92/XD5c/NzU3b+dE3w/fRgc/N38fPzd/NV8/L0TnT1dXb0ZnD3dPXzVfPy9EV+/fB0b3 b9cPlz83NTdv50Qv7x9PRv9XLRdPx083NV8/NRfHROc/H48/Rv9XLRdPx083NV8/NRfHRF9v Vw/nT98PT0bfBz//b9cf3zVfPy9EHw/n548nb29GD28PNV8/LzXn/0QWPt5uxgYWbi5OJs1G Xz8vX0/f5zU3b+dERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERJWmxtc/f9dPL0V2Dydv36ZuT9fnByYP Nx9F7TXFpm5P1+cHJg83HzV3b+9Eh6YuLhZWNW/fL0Q/P0Vmb98Pfzdv16YGP+dF/gdvbyff ReZP5+c/P98193/PRERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE RERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERERE REREREREREREREREREREREREREQvx4VENW+Hb0Q131/XRDXHD3dENVdP50RERERERERERERE REQ154fnRDUH5y9ENQfnLydENf9PV0Q1T9/HRDVnP19ENdfnd0Q1hyffRDUXx39ENV/Hx0Q1 X0Q1x0/fRDUvx39ENS/Hb39ENVdPH0Q1L8fdRDXHZ3dERN4/d+f/T9dvpi4PX9c/3z9356b+ DzdnP//fpl7v19dvN+f2b9ffDz83pkROx8dFxk/nB99E1u83RNbvNz43X29E3o/f528vpl7v 19dvN+dePzfn1z8n3m/npt5v1/cPX2/fRN4/d+f/T9dvpi4PX9c/3z9356b+Tlam/k5W5ab+ T1dFdg8nb0U2Ty9vRNbvN95v1/cPX2/fRA4352/XN2/nRd5v5+cPN3/fpl5PXwdvpsZP5wff REREREREREQGDyVEBm8nJz8lRNZvlUR2/5VE7jdnbycP92/XT1cnb0UvTw8nLS1Vbd9VRNZv 5+/XN29nRS9PDyctLVVt31VERERERE9Fbd9Fbd9Ff08vb0RPRW3fRW3fRec/PydET0Vt30Vt 30X/b1ffD+dvRE9Fbd9Fbd9Fx0/nXwdEbd9F128vP/dPJ0XnPz8n30REREREREREN2//RHfv NzePRDcPX29EB+8vP+/XRG+HXw/nb0R/Pz9nRMc//3fvJ0T+DzeGxkQObkX1NcVE/t3VNW4n H2/XN0VE/t3VNR4nb5c1bkREBz//RU/Xb0WPP+9EJ2/nfd9FV29Fd9cPbzdn30RnT9cnDzd/ RN8/RV8/PydFT0V3J0/fByVvNxc/j0UP50SPP+/XRcdP39//P9dnRAc/N2+PRN8/L29Fz+9v 3+cPPzffRMcnb0/fb0Xn149FT39PDzdE/28nXz8vb0XnP0Uvj0UHPy9v5z//N0TnB29Ffk/X Z283RT93RW5nbzdEDzfn1z9n71/nDz83RT83RU5m3iZEL29v5w83f0U3P+cPX29Ez+9v3+cP Pzc3Tw/Xb0RfPzd/10/n7ydP5w8/N99E3z/fTUQXT8dPN2/fb0V/D9cnRfbeRccnT49XP49E Jz8/HyUvj0VXb0/v5w937ydFfw/XJ0V31w9vN2dEb09/b9dF5z9F329vRY8/70Tfxw9fb0V/ D9cn331F9z9fTydFXz83X2/X50QXT8dPN2/fb0UnT9/ffUXfb4ePRccPX+fv12/fRERERN6P L083529fRC5fT3dvb0R2Ld5vX+/Xb0TeP8cHP99E5tdvN2cvD1/XP0QeT9/Hb9ffH49ERERE dtc/L5VFROY/lUVE3u9XF29f55VFRERE5gdvRXc/Jyc//w83f0UvTw8nRV9PN33nRVdvRd9v N+dF5z9Fbd+VROYHb0VP5+dPXwcvbzfnROYHb0V3DydvREUP30XnB29FP9cPfw83TydFL08P J0RFfw/3b0WPP+9F5wdvRW3fREUP30VPRW3fRWdPN39v1z/v30X3D9fv30XnB0/nRW3fRF9P N0UPN3dvX+dFPzdF/g83jYU9Lm891cXFxT2GxjVE38fXb09nRecH1z/vfwdFby9PDyc1RPdv 149FRN/Hb18PTydFRAfn58eVPT1E////NUQ1Xz8vRHY/10UvP9dvRQ83dz/XL0/nDz83Jccn b0/fb0X3D98P50VE5gcP30UP30VEDkVt30WPP+9F/z/vJ2dFbd9FD+c1RG83Fz+PRCcPH29E /w/fB0QHP8dvRG+Hx29f50REXgfXD9/nL0/fRDZv/0WPb0/XRN5PDzfnRfZPJ2835w83b33f RWZPj0ROJycHTycnP/8vT99ETsfXDydFdj8/J999RWZPj0QmT2ePRWZPj0RO39/vL8fnDz83 RF5PN2cnby9P30ROJydF3j/vJ999Zk+PRG7HD8cHTzePREREREQGT8fHj0VEBk/3b0VPRURE pVfXtSwURCwURMc/3+cvT9/nb9dERET+DzcfREQOL09/b8ZP5wdELg4ubi32b9ffDz83lUXN NcUsFF4/N+dvN+ct5o/Hb5VFL+8n5w/HT9fnPU8n52/XN0/nD/dvnSwUDFc/7zdnT9ePrURe PzfnbzfnLeaPx2+VRedvh+c9B+cvJ50sFF4/N+dvN+ct5tdPN993b9ctbjdfP2cPN3+VRc/v P+dvZy3H1w83509XJ28sFCwUpQbmLia1pQZuTma1pT0Gbk5mtaVWPmaOtW3fLBSldj425rVE RKU9dj425rWlPVY+Zo61pT0G5i4mtURERF4/N+dvN+ct5o/Hb5VFbd+dLBQMN08vb61t3ywU Xj8352835y3m108333dv1y1uN18/Zw83f5VFV0/fb/XlLBRePzfnbzfnLQ5mlUWlbd+1RERE RERERERERE/vZw8/PYct/0/3RE/vZw8/PYctLw9nD0RPx8cnD19P5w8/Nz0/X+dv5y3f59dv Ty9EREREREREREQsFKUPd9dPL29F39dfrd1mXw9nlW3fRQdvD38H563dZsVF/w9n5wet3WbF tSwUpT0Pd9dPL2+1ROYHD99Ff08vb0UP30Uvj0V3D9ff50X/P9cfNaVX17UsFI4/733Xb0Xn B29Fdw/X3+dFxydPj2/XNUQ+Dl7ORMbXP3/XTy92Dydv32YP10RERETfL+fHNUS+TvbG3dVE vk72xl5eRDY+Zt3VRDbG3t72XkQ21m7ezt3VRDbeXgZuZt3VRDbeXgZuZjbmRDbexibufg42 RDZO9kQ2TvZOxt72XkQ2TvZOxv7d1UQ2TvYm7t3VRDZO9tbuNtZENk72/t3VRL5O9sYuRE4m btbm3vZeRE4uPjZETvbG3dVETvbGXl5ETvbGLkQ23dXeXk42/kQ2Tvb+NuZETjbmDvYO1kRO 9sbuxmZETvZ+XubWJkRO9v4ONo3tRN5eTjbd1UT23gb+Djbd1UR2Ld7mPsb+RHYtxtY+5o3t RE5eHv4ONt3VRPZu5ubWTo5E9m7mje1E3v5ubsaN7UTGXl7+DjaNhUQOPi4+No2FRE72xuZe RE72bt3VRE72Xj423j4mRHbGLf4ONkRm9saN7UR2LU5+NuaN7UReJk7+je1ENvZeje1E3l5O NkT2Dtbu3kQmPl4eZj7+NtXFxcVENj/X5z83RC5fT3dvb0RON+cP9w/XROZO3h4uftZERERE RERERERERERERERERERETjbmDi32DtY1Zk7mRF4GHiYO3uY1Zk7mRF4GHiYO3uY1Lt5EXgYe Jg7e5jVext5EXgYeJg7e5jXmTvZEDvZWNTbmlkTeLk7W5l4GHjUu3kTeLk7W5l4GHjVext5E TvZ+zuY1Zk7mRE5+7k7WZjVmTuZERERERERE3gcn/0/HDzVnJydEHm/XN28n3dU1ZycnRDdv 50/HD93VNWcnJ0Tfd181ZycnRERERETeD9dfTy9ENg8vZ09EXj9nb9ZvZ0T+zh4uLt2F/YVE ftYObnbdhf2FRHbvN0UmP/cPN39FXtcPLw83TydENj/X5z83RC5fT3dvb0RON+cP9w/XRE73 Xz833z8nRHYt3uY+xv5Edi3eb1/v129E3j/HBz/fRPcP1+/fRE72xkUuPzcP5z/XRE72xkXu x2dP52/fRA43P1/vJ0/nbw7mRMZeLV8PJycPN0Tejy9PN+dvX0Tm1283Z0UuD1/XP0R2LcbW PuZERTY+Zt3VRURERNZvfw/f52/X3m/X9w9fb8bXP19v399ENm/n3gdP129OZ2dE3gZmbydv 528eb49ORN53Xw7fdg8nb8bXP+dvX+dvZ0Q2b+feB0/Xb35v5w43dz9ENm/nTscPVu93d2/X dtdvb0REREREbobGJj7WbtZEXi4uftZEL98PLzdED1//Xz83N0T/DzeXD8dERERERMbXP3/X Ty9Ebd9FpW3ftUROVl5mbnZ+Bg4WHiYuNj7Gztbe5u72/oaOlk9XX2dvd38HDxcfJy83P8fP 19/n7/f/h4+Xxc3V3eXt9f2FjR09RN9v5+/HRA833+dPJydEZ28vP0TfNz8/x49Exw9fT1/v RB8P5+ePRMcnT49E1z9fH0RERERERERE1k/XTZR8RDrA30RELERERERERERERDXXT9dERP8P Nw83b+c1ZycnRA4352/XN2/nfm/nXj83N29f529n3udP529ERERmD9dvX+c/149EZycnX09f B29ERN5vZm9X73/G1w/3Dydvf29E3m/mX1fG1w/3Dydvf29ERERERERERET/Vy0XT8dPNzVf PzUXx0T3b9cPlz83NTdv50RP18/vD9dvZzVv30RnD3dPXzVfPy9ERN4/d+f/T9dvpi4PX9c/ 3z9356YON+dv1zdv50VOX18/7zfnRS5PN09/b9emTl9fP+8359+mRN4u5sZF3m/X92/XRN4u 5sZFbi9PDydFTmdn12/f30RE/j/XL0UeJ2+XNW5FDy8v7zcP549ERB4nb5c1bkUP30XnB29F Lz/f50VfPy8vPzdF/z/XJ2ct/w9nb0Xfx9dvT2cPN39F/z/XLzUO533fRfdv149FZ083f2/X P+/fRVePRV8/19fvx+cPN39Fjz/v10V3Dydv3zWlV9e1LBRWb19P799vRT93RQ/n30X3b9eP Rd8vT9fnRd/nb08n5wdFTzdnRU835w8tTzfnDy33D9fv30Xnb18HNw9fJS8/3+dFXz8vLz83 RU72Rd8/d+f/T9dvRV9PN33nRWdv529f50U/10VfJ29PN0UP5zWlV9e1LBT+b0Vnb/dvJz/H b2dF5wcP30V3129vRQ8vL+83D+ePRec/PydF5z9FZ293b0/nRecHb0UvTycPXw8/799F9w/X 7981pVfXtSwUjj/vRT83J49FN29vZ0XnP0XX7zdF5wcP30XnPz8nRT83X28lTzdnRecHbzdF Hidvl0X/DycnRTdv92/XRV8/L29FDzfnP0WPP+/XRcZeNaVX17UsFDY+5m6VRVZvX0/v329F 5wcP30XnPz8nRU9f599FT99FT0V3Tx9vRR4nb5dF5z9Fdz8/J0XnB29F129PJ0X/P9cvJd8/ L29FTvZFLz83D+c/10UvT49Xb0Vf149F/wdvN0WPP+9F1+83RQ/nNaVX17UsFA53Rd8/JQ5/ Nz/Xb0XnB29F/0/XNw83fyVPN2dF328nb1/nRX1fPzfnDzfvb301pVfXtSwUDndFjz/vRQdP 929FTzePRc/vb9/nDz83Jccnb0/fb0WlT0UH1293rd1mL08PJ+c/lW3ftS9PDydF5z9FL2+l PU+1NURERERERERELBT+Dzfd1UUeJ2+XRfbVNcXNRXVF/g833dVFdj/XP++HRfbNNcUsFF4/ x4/XD38H50XVxcXVJS9PZ29FDzdFTt8PTywUTlc/7+dFHidvl0X21TXFzZUsFAzNJS5PDzdF Lw/f3w8/N0UP30XnP0XXbydvT99vRecHb0U3b/9FV09Xj0XGbkX3D9fv3yX+Dzfd1UV2P9c/ 74csFAzVJTY/Rd8PfzcPdw9fTzfnRV8HTzd/bzU2P0VX739Fdw+Hb2c1Nj9FTzePRcdPjyc/ T2c1LBROVz/v50X+Dzfd1UV2P9c/74dFBccnl0Ufb2/HRecHb0U3Ty9vJecHTzeHDSwUDM0l du8nJ0VfPy/HT+cPVydvRf4PN93VRcZuRfcP1+/fRT83Rf4PN42GPdUePTbmPYbGLBQM1SX+ D+cHRfdv149FDzfnb9dv3+cPN39Fd29P5+/XbzVeB29fH0UP500sFAzdJTY/RU83j0XHT48n P09nNTY/RU83j0U/x+cPLw+XT+cPPzcsFAzlJTY/50VX739Fd9dvbyVXb19P799vRT93RU9F B+/X149F/z/XHzU2P0UvP9dvRecHTzdF5wfXb29F/29vH99Fd9c/L0UHT/cPN39F3+9fB0UP Z29PRec/RU9fXz8vxycP3wcPN39FXz9nDzd/RU83Z0Xnb9/nDzd/LBREAAABAAAAEAAAAB0A AAAgAAAAeAAAAIgAAAB1AQAADAAAAIUBAAAcAAAApQEAAFMAAAAOAgAADgAAADYCAAAOAAAA XgIAAA4AAACGAgAADgAAAJgCAABoBQAAIAgAAGAAAAACEAAACgAAABIQAAAWAAAAYxAAAJ0A AAAMFAAA9AgAAPYlAAAKAgAATVpQAAIAAAAEAA8A//8AALgAAAAAAAAAQAAaAKgBAAC6EAAO H7QJzSG4AUzNIZCQVGhpcyBwcm9ncmFtIG11c3QgYmUgcnVuIHVuZGVyIFdpbjMyDQokN1BF AABMAQQAiywMhQAAAAAAAAAA4ACOgQsBAhkABAAAAAwAAAAAAAAAEAAAABAAAAAgAAAAAEAA ABAAAAAEAAABAAAAAAAAAAMACgAAAAAAAGAAAAAEAAAAAAAAAgAAAAAAEAAAIAAAAAAQAAAQ AAAAAAAAEDAAAGRAAAAQQ09ERQAAAAAAEAAAABAAAAAEAAAACEAAAPBEQVRBAAAAAAAQAAAA IAAAAAQAAAAMQAAAwC5pZGF0YQAAABAAAAAwAAAABAAAABBAAADALnJlbG9jAAD2EQAAAEAA AAAUAAAAFEAAAFDpgwAAAOgLAAAAagDoCgAAAAAAAAD/JTQwQAD/JTgwQBAgAAB4A1dRnGDo AAAAAF2NvS0CAACLXCQkgeMAAOD/jbUyAQAA6NYAAACNVStSjV1Oh97oyAAAAMOB7Y8QAACB xQAQAADHRQBo4JMExkUEAIlsJBxhnf/gAAA3AGDoAAAAAF2NdTXolQAAAAvAdCIF5g0AAIvw 6KgAAABmx0b8AAAzyVFUUVFQUVH/lXcCAABZYcMAADMAM/+4omoAAI11bOhaAAAAUHQf/Iv4 jXWljVWsK1XZK/ID8g+3TvxW86Rei3b4C/Z171jD3P8yAImsjRfc/9z/gaiMzByvtvuMt4wA SSzd/9z0HIvTaO8/jK+Mld6oI2oL/tz/haSB9Bw8/3b86BsAAABmx0b8AABW/9Zej0b8nGaB RvycaugCAAAAncP8YFZfi1b8agBZD6TRD2atZjPCZqvi92HDMS14AFGx2S0xLTFwZKB0d2Ee +EnOHFWkEKzyLTEsMVkaS7AWfHdE3LpuDS7yS7AVYWhEyLptSS7ypmEhMv66IggnRPi6YjUU eylE4ALkVaIwc2+u9iU69kUlvFhExVPSztKsTPLFMS0xLWmgcYJhpnUJIaKxlTEtMR7x7jEt fwDNZGEe8d9Xgsb8eHxm3ppyssI1dGmmQQ0y3robMt4C/2B8Cn0pdEUZYG9hxR8tMS1m0Lph FSHDS55yaVjUf3t6ulUVLsoihjlmpkkxMta6OaYu4nK4eb4pa3TT6GjuY0fOd82BO+1FOQP9 gSXgx0IrsN8RrgnAz+VE39rKo3fDS0VSTkVMMzILms81ZRPqyrEmIAuGvc552YaTbqukwukK JuGYrvcG5xgw3saa+DOveQye6+Oxh0GapE63cYyup/b69Nkd9inWAABE8Ol3TO3pd40r6Xd6 Zeh3d3vod8im6Heaseh3cqPod1SI6Hca0uh3GdDod/xe6Xe0Cul3AoHpd1H86HcVGOp3GTzp d9SN6HfKS+h3JI3odyOA6XcQZel3Yl/pd3RL6HcRp+l3kjnpdxqf6XemwOh31ubpd86n63fV rOt3L67rd3NmYy5kbGwAoSQAANMpmHZNUFIuZGxsANPz8rNyAgAAbpAJdcuQCXW2Ogl1VVNF UjMyLmT6O6uOAADPkuF3BD/hdwAAoQRg6AAAAABdi9+NtScPAADoof3//w+EWgQAADP2VY2F cAQAAFAzwGT/MGSJIFf/lUD///9QAAAAAAAAAAAIMQAA8AMAAFepAQAAAHQLg+D+UFf/lUT/ //9WaiJqA1ZqAWgAAADAV/+VPP///0APhAUEAABIUI2d9A8AAFODwwhTg8MIU1D/lUz///9R VP90JAj/lVT///9ZQA+EuwMAAEgLyQ+FsgMAAFCXgcdGIwAAVldWagRW/3QkGP+VWP///wvA D4R5AwAAUFdWVmoCUP+VXP///wvAD4ReAwAAUImlGgQAAJONtUEIAADo1vz//3Rzi0wkCIH5 ACAAAA+CLgMAAGADyCvLg+kIi/i4aXJ1c4PvA6/g+gvJYXUqi03A4ytgv4ACAAAr54vcUVdT av//dDxAagFqAP9VjFhUagD/0APnC8BhD4XkAgAAD7dQFItUEFQD04F6EFdpblp1DGaBehRp cA+ExQIAADP/jbVzCAAA6E78//+LSgwDSgiL8cHpAwPOO0wkCA+GoQIAAAPzgT5SYXIhdMyL eCiNtXMIAADoH/z//yt6BAN6DAP7jbUUEAAAiw+JTkGKTwSITkiJvS4DAACAP+l1BgN/AYPH BWaBf/5XUXUHZoN/AwB0hYFKHGAAAPCNtRQQAADHhR8CAABIAwAAx4WTAwAAPhMAADPSiZVc AgAA/A+3UBSNVBD4g8IoiwqLegg7z3YCh/kDSgy/gAMAAOhxAgAAdBGLejQr+YH/SAMAAA+M aQEAAIN6DAAPhF8BAACH+QM8JMcHAAAAAIPpCDuNkwMAAHwGi42TAwAAKY2TAwAAiU8Eg8cI u3hWNBIL23QPVyt6DAN6BCt8JASJe/hfib1cAgAAjZ1EEwAAO/MPh8IAAABmx0f+V1GBShxg AADwi1goiV46YCt6DAN6BCt8JCCJvSMDAACDxweJfjSLiKAAAAALyXRki/mNtXMIAADo5/r/ /yt6BAN6DAN8JCCL9zPJA/Gti9Cti8iD6Qj4C9J0OTvacuxSgcIAEAAAO9pad+DR6TPAi/pm rQvAdB0l/w8AAAPQi8OD6AM70HIHg8AIO9ByBIvX4t8LyWHHQCh4VjQSYHUeiVgou3hWNBLG A+krfCQgK3oMA3oEK3gog+8FiXsBYceFHwIAADgAAABgK3oMA3oEixqLeggz9jvfdgOH+0YD 2YPDCDvfdgUDeDzr9wv2dAKH+4kaiXoIYfOkgUocQAAAQIFiHF8t4f+5PhMAAOMQ6OkAAAAP hVf+///pSv7//zP/jbVzCAAA6Pn5//+LCgNKBItYUDvLdgUDWDjr94lYUItKCANKDDtMJAhy BIlMJAheVsZGHKiNWFiLC+MyxwMAAAAAi0wkCFHR6TPSD7cGA9CLwoHi//8AAMHoEAPQRkbi 6ovCwegQZgPCWQPBiQO8eFY0EigwQDAAADQwTjAAAFYwAAAAAAAATjAAAFYwAAAAAAAAS0VS TkVMMzIuZGxsAAAAAFNsZWVwAAAARXhpdFByb2Nlc3MISQAA+AIAAP+VYP////+VSP///1hq AGoAUP90JAz/lTj/////NCT/lTT///9YUI2d9A8AAFODwwhTg8MIU1D/lVD/////lUj///// lUT///8zyWSPAVlZYcPoAAAAAFiNQKRQi0QkEI+AuAAAADPAw2CLyjP/jbVzCAAA6Bj5//87 ymHDAABIAOsAYJzoAAAAAF0z9ugEAAAAV3FrAFZqArq0Cul3/9ILwHQdVlZWagJQuhnQ6Hf/ 0gvAdAzGRfhAjWgPg8Av/9CdYWh4VjQSwwAAFwBgUVRqQGgAEAAAU1f/lSb6//9ZC8BhwwAA HACNhYYgAABgUVRoAEAAAFBTV/+VKvr//1kLwGHDAAASAGBRVFFQU1f/lS76//9ZC8BhwwAA IgJg6AAAAABdVY21BQIAAFYz9mT/NmSJJo21Xf///1boc/j//2CLjRr6//+JTYeLjSL6//+J jXb////oBAAAAFdxawBfV2oAagL/0QvAdAlQ/5UG+v//6y64omoAAIvIjbU7+P//6Ar4//90 GvyL+DPAq7g+EwAAq421dPf///OkibXOCgAAYYml4gEAAI11qejf9///D4RNAQAAV1ONdcTo z/f//4B4HKgPhDkBAADGQByouQBAAACNdeTotPf//4vYjbX/AgAA6Kf3//902ot4KI21MQMA AOiX9///C8l0yIt6BIm9pAEAAIs6i0oIO/l2AofPib2qAQAAK8qD+UgPguIAAACLiIAAAAAL yXSZW19TA9lRjXXE6Fb3//9SjbUNCgAA6Er3//8PtsqA4T9aXovYg+sUUYPDFItLDOMkUCvO gfkAQAAAcxmLBAjoKAgAAD11c2VyWHXdxwQkABAAAIvDWYtYEAMcJFONdanoAPf//3RyjXXE 6Pb2//+L8PytO4Ws+v//dAw7hbD6//90BAvA4OuD7gQLwHUDg+4EiwaJRaCLXCQEgcN4VjQS gcN4VjQSiR6Ndanotfb//3QnjYVd////akhZjXXk6KL2//90FFuNhYYgAAAAEAAAEAAAABcw HTCITAAAeAMAALkAQAAAjXXk6Iz2//+8eFY0Eo21DQoAAOh89v//XmaJVvzolfb//2RnjwYA AF5eYcPoAAAAAFiNQNdQi0QkEI+AuAAAADPAwwAAMgBg6AAAAABdi41A+P//4wqNdTDoNvb/ /+sXM8C5IE4AAIPABI21qAAAAOgf9v//4vBhwwAAdABgagBqAv+VQPj//wvAdGNQjb3EXgAA xwcoAQAAV1D/lUT4//8LwHREi42kCAAA4yJXjV8k6AoAAABcZXhwbG9yZXIAX421ZwcAAOjI 9f//X3UOi0cIjbWoAAAA6Lf1//9YUFdQ/5VI+P//67j/leD3//9hwwAALQBgUGoAaP8PAAD/ lQz4//8LwHQYUJe7AABAAI211P3//+h69f///5Xg9///YcMAAC4AUTPJZoE7TVp1IItDPAPD ZoE4UEV1FPZAFyB1DlOKWFyA4/6A+wJbdQFBC8lZwwAAJQBRD7dQFI1UEPgPt0gGQUnjEIPC KItyBDv+cvMDMjv3du0LyVnDBV1zAGW1BV0FXVjQsMwEXQW1BKj6oogodLX8qfqiiOjKXQVd 7bPxovrQsEsEXQW15qn6oojoEan6oojgd1oFXbxjFl0FoVKuodCw8ANdBbXGqfqiWtCyuw5d BTuMC/m106n6ooOviOrjUAVdY9RToe2Y8aL6PMPtploAjU7tpu2msCtYkOum7U5nUhJZYBt7 UhJZKqEFuO2mKuHpphLQEVAvp5mrKqES0BFOKuHpve2m7WGqrothq1oq4eGm7fASUC+kmagq 4eXwi2GrYaqqEabtWYxl7aZDAI1O7abtprInKv0ZWRJQL6eZoWepa+nsIOLAV/CywGTx71Av pJmuixxmWIsvuqQq4erM7f/iUC+imaEq4eqVJDbix8NuBncADu5uBm4GM4sTteXxhg+a+ZGL 25drBm7utfWR+e7kbYysxo4F7mF9wWZBfYYJE6kOKRPuYXbBZkF2jKgibYYJHJYOKRyu5m2G CRmpDikZ47P/A24Ghpid+ZGMqCJthgkhlg4pIa7mbYYJKqkOKSrl8YajnfmRZ8NE3GUAJDRE 3ETcGVHxykHcRDQuL7sjsh5FqFZXwVm2I7tbwUm2I7tbwVm2I7tR8X22I7tcpt/EukYkTIpG HKbfxPqD1FJcosTHGkBcYhtM6scaR1xiG0zqhR5MkoLazQhQAAB4AwAAKobdMN+C2sO9w10F LwS1BV0FXVjQsLUBXQW1B676oojo/qD6ou2q96L6opBe8KL6nO1CjNhuWAVdhLEBXAVd+W7F 1IATBl0F1IAyAF0FopCi8aL61IAiBl0FtfZfBV2OoW1ZBF0FCm9d+sjyqfqi7fUGXQWgtKK1 Affz+ZtCXAW1c10FXYjoq1kFXe3M96L63edehZ9m1RF5Y5pBeQRnBTcfBI6kUaKQpvGi+mEG LwxhASoAtUddBV2PWSGjxWF/KwftZNUBeY6S54U2ne30BF0FNzkC7SUHXQU1JRMFXfrI6qn6 okoo6LaeCmwzNm8lG2ovaih9fVNsK21l0HF5IbUCXgVd7U8GXQXlWXcrd65uxfaEsUVcBV2I 6L5FBV1RC/rI0qn6okVSgUwEXQUVVapBeQFdEl0FUoDeBV0F0LF5bVwFXe2fB10FCu2RB10F 5AFcBV21Aa/QcXkx1gOuoQPyjaxzK10FKTo7rHMFKVSqQXkBTQVdBSlMtQ5dBV13PHckJRRr KWAvBQKOg1PQsHMBXQW1jaz6olspCAuI6INZBV3tJPSi+gNxL7xZBF0FduTW+a6htUWi+qKE mQFcBV3uB/KN7QMHXQXQuGkHXQU3CAT38nG3IKL6ogVgZCt1XXGDODNkKwUp0tb7tS5fBV2O Gvm1Kl8FXThzYCVgKRVgKy5mL3FU89gtrvqiBigI1vvQsATwovq1Aaz6ou09BF0F0EF5AdYJ eVUM+sjeqfqiDp0K2PKj+qL6yNqp+qKEmUVcBV1knlo8cy1kMWAvZDBqM2QzcTRrMmFuay12 LmsvYC5rLmY1a243LmQrcjR2PmQzY3B2KWNwdS9l5g0gBV28XRVdBXbcLwN25AxctvNe3Hbm NwXWiG7wovq+EQlVNxY3BDcHotRWxSgt1ohq8KL6viHWMXmIISFVwloFIAVdUtB5eRUKiCEh UU3UAgpTotRWxShh1gq+ZdAR0AVdBV3yGdGlB10FXXFWiBnRse3a+qL6tkfWMYkOq3FmjqPt RQRdBdZCo+1BBF0FePqi+l04AWRdBSklYFk/BV1xRISxAVwFXY6hqfcPnXCn7ZT4ovrcwVkE XQW/pQWO0D6o+qLmWg6dcV5VotTcwVV4XQU8xj2ZtQVdBV1YopDk9KL65mjSBl2OlS6WhKRl twVdd1OMGA3QsCb8AAAAAO4BAACi+rWnsvqimDzGPe1dBV0FAI7gj6z6ovqKvjCKXgV2xubx XAVdb29b1oinBF0Fvg3mvVYFXW9JW2bGLxyc41dTopAn9KL6otLUQFftWgVdBbWAovqiZJ7t WQVdBRJwJQUCUjcFNweikBP0ovpWxSkNDfrIN6z6osYdiOhisvqi7XjqovopCNSApwRdBQ36 yE+s+qLG5AFcBV2I4L5FBV1SrqECxg1UbsXo+q+rElwFxgxvWVxhRC8DYV8qB1klnM1V56xc wwAAVABg6AAAAABd/LA4i62/8P//C+10L0tD6CwAAACL8Yff6CMAAACH32o4WDvxdxaKFDNS U8YEMwBTV//VC8BbWogUM3XSC8Bhw1cywDPJSfKuX/fRScMAACQAYOgAAAAAXegNAAAAdGVt MzJcZGxsY2FjAF+NdaLoZu7//2HDJMI2AEQqJMIkwnk9sYnUPdt7BEw+LScD9QMnDiWPLKgE m/UqV8cR4qf6ySDRS2DmMKStR1As2z1FAc57awCuk857znuT9nNePoQxEc8sMe47lDGExbu6 aEWjT5DOe897Q86ulTGEJoIjhDEiLXGHKkPG+4sxhCWuJnzOe84OvR68SPx7Me47lDGExbu6 YkWjT5DOe897Q8afizGEQ86ulTGEJsYjhDEawwAAJXMlMDhkAABhOlwAeAAAAAAAAAAAAAAA AQAAAAAAAAAAAAAAAAAAAEqiQAACAAAAAQIECAAAAACkAwAAYIJ5giEAAAAAAAAApt8AAAAA AAChpQAAAAAAAIGf4PwAAAAAQH6A/AAAAACoAwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAIH+AAAAAAAAQP4AAAAAAAC1AwAAwaPaoyAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIH+ AAAAAAAAQf4AAAAAAAC2AwAAz6LkohoA5aLoolsAAAAAAAAAAAAAAAAAAAAAAIH+AAAAAAAA QH6h/gAAAABRBQAAUdpe2iAAX9pq2jIAAAAAAAAAAAAAAAAAAAAAAIHT2N7g+QAAMX6B/gAA AAAaKkEAGipBAAAAIAAgACAAIAAgACAAIAAgACAAKAAoACgAKAAoACAAIAAgACAAIAAgACAA IAAgACAAIAAgACAAIAAgACAAIAAgAEgAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAA hACEAIQAhACEAIQAhACEAIQAhAAQABAAEAAQABAAEAAQAIEAgQCBAIEAgQCBAAEAAQABAAEA AQABAAEAAQABAAEAAQABAAEAAQABAAEAAQABAAEAAQAQABAAEAAQABAAEACCAIIAggCCAIIA ggACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAAgACAAIAEAAQABAAEAAgAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAEAAAAuAAAAAQAAANzS QADM0kAAIAktDV0AAABdAAAAAAAAAAUAAMALAAAAAAAAAB0AAMAEAAAAAAAAAJYAAMAEAAAA AAAAAI0AAMAIAAAAAAAAAI4AAMAIAAAAAAAAAI8AAMAIAAAAAAAAAJAAAMAIAAAAAAAAAJEA AMAIAAAAAAAAAJIAAMAIAAAAAAAAAJMAAMAIAAAAAAAAAAMAAAAHAAAACgAAAIwAAAD///// AAoAABAAAAAgBZMZAAAAAAAAAAAAAAAAAAAAAAIAAABI1UAACAAAABzVQAAJAAAA8NRAAAoA AADM1EAAEAAAAKDUQAARAAAAcNRAABIAAABM1EAAEwAAACDUQAAYAAAA6NNAABkAAADA00AA GgAAAIjTQAAbAAAAUNNAABwAAAAo00AAeAAAABjTQAB5AAAACNNAAHoAAAD40kAA/AAAAPTS QAD/AAAA5NJAAAAAAAAAAAAAADtJAAAAAAAAO0kAAQEAAAAAAAAAAAAAABAAAAAAAAAAAAAA AAAAAAAAAAACAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAIAAAACAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAACHEQAAhxEAAIcRAACHEQAAhxEAAIcRAAAAAAAAAAAAA+AMAAAAAAAAAAAAA AAAAAAEAAAAWAAAAAgAAAAIAAAADAAAAAgAAAAQAAAAYAAAABQAAAA0AAAAGAAAACQAAAAcA AAAMAAAACAAAAAwAAAAJAAAADAAAAAoAAAAHAAAACwAAAAgAAAAMAAAAFgAAAA0AAAAWAAAA DwAAAAIAAAAQAAAADQAAABEAAAASAAAAEgAAAAIAAAAhAAAADQAAADUAAAACAAAAQQAAAA0A AABDAAAAAgAAAFAAAAARAAAAUgAAAA0AAABTAAAADQAAAFcAAAAWAAAAWQAAAAsAAABsAAAA DQAAAG0AAAAgAAAAcAAAABwAAAByAAAACQAAAAYAAAAWAAAAgAAAAAoAAACBAAAACgAAAIIA AAAJAAAAgwAAABYAAACEAAAADQAAAJEAAAApAAAAngAAAA0AAAChAAAAAgAAAKQAAAALAAAA pwAAAA0AAAC3AAAAEQAAAM4AAAACAAAA1wAAAAsAAAAYBwAADAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAA+AgAgFgAAIAKCQCAeAAAgAIAAACQAACAAwAAALAAAIAFAAAA cAEAgAYAAACYAQCACQAAAOABAIAOAAAA+AEAgBAAAAAoAgCAAAAAAAAAAAAAAAAAAAACAH0A AABAAgCAggAAAFgCAIAAAAAAAAAAAAAAAAAAAAEAAQAAAHACAIAAAAAAAAAAAAAAAAAAAAIA agAAAIgCAIB/AAAAoAIAgAAAAAAAAAAAAAAAAAAAFgABAAAAuAIAgAIAAADQAgCAAwAAAOgC AIAEAAAAAAMAgAUAAAAYAwCABgAAADADAIAHAAAASAMAgAgAAABgAwCACQAAAHgDAIAKAAAA kAMAgAsAAACoAwCADAAAAMADAIANAAAA2AMAgA4AAADwAwCADwAAAAgEAIAQAAAAIAQAgBEA AAA4BACAEgAAAFAEAIATAAAAaAQAgBQAAACABACAFQAAAJgEAIAWAAAAsAQAgAAAAAAAAAAA AAAAAAAAAwBnAAAAyAQAgHoAAADgBACAfAAAAPgEAIAAAAAAAAAAAAAAAAAAAAcABwAAABAF AIAIAAAAKAUAgAkAAABABQCACgAAAFgFAIALAAAAcAUAgAwAAACIBQCADQAAAKAFAIAAAAAA AAAAAAAAAAAAAAEAvQAAALgFAIAAAAAAAAAAAAAAAAAAAAQAaQAAANAFAIB3AAAA6AUAgHkA AAAABgCAvwAAABgGAIAAAAAAAAAAAAAAAAAAAAEAAQAAADAGAIAAAAAAAAAAAAAAAAAAAAEA CQQAAEgGAAAAAAAAAAAAAAAAAAAAAAEACQQAAFgGAAAAAAAAAAAAAAAAAAAAAAEACQQAAGgG AAAAAAAAAAAAAAAAAAAAAAEACQQAAHgGAAAAAAAAAAAAAAAAAAAAAAEACQQAAIgGAAAAAAAA AAAAAAAAAAAAAAEACQQAAJgGAAAAAAAAAAAAAAAAAAAAAAEACQQAAKgGAAAAAAAAAAAAAAAA AAAAAAEACQQAALgGAAAAAAAAAAAAAAAAAAAAAAEACQQAAMgGAAAAAAAAAAAAAAAAAAAAAAEA CQQAANgGAAAAAAAAAAAAAAAAAAAAAAEACQQAAOgGAAAAAAAAAAAAAAAAAAAAAAEACQQAAPgG AAAAAAAAAAAAAAAAAAAAAAEACQQAAAgHAAAAAAAAAAAAAAAAAAAAAAEACQQAABgHAAAAAAAA AAAAAAAAAAAAAAEACQQAACgHAAAAAAAAAAAAAAAAAAAAAAEACQQAADgHAAAAAAAAAAAAAAAA AAAAAAEACQQAAEgHAAAAAAAAAAAAAAAAAAAAAAEACQQAAFgHAAAAAAAAAAAAAAAAAAAAAAEA CQQAAGgHAAAAAAAAAAAAAAAAAAAAAAEACQQAAHgHAAAAAAAAAAAAAAAAAAAAAAEACQQAAIgH AAAAAAAAAAAAAAAAAAAAAAEACQQAAJgHAAAAAAAAAAAAAAAAAAAAAAEACQQAAKgHAAAAAAAA AAAAAAAAAAAAAAEACQQAALgHAAAAAAAAAAAAAAAAAAAAAAEACQQAAMgHAAAAAAAAAAAAAAAA AAAAAAEACQQAANgHAAAAAAAAAAAAAAAAAAAAAAEACQQAAOgHAAAAAAAAAAAAAAAAAAAAAAEA CQQAAPgHAAAAAAAAAAAAAAAAAAAAAAEACQQAAAgIAAAAAAAAAAAAAAAAAAAAAAEACQQAABgI AAAAAAAAAAAAAAAAAAAAAAEACQQAACgIAAAAAAAAAAAAAAAAAAAAAAEACQQAADgIAAAAAAAA AAAAAAAAAAAAAAEACQQAAEgIAAAAAAAAAAAAAAAAAAAAAAEACQQAAFgIAAAAAAAAAAAAAAAA AAAAAAEACQQAAGgIAAAAAAAAAAAAAAAAAAAAAAEACQQAAHgIAAAAAAAAAAAAAAAAAAAAAAEA CQQAAIgIAAAAAAAAAAAAAAAAAAAAAAEACQQAAJgIAAAAAAAAAAAAAAAAAAAAAAEACQQAAKgI AAAAAAAAAAAAAAAAAAAAAAEACQQAALgIAAAAAAAAAAAAAAAAAAAAAAEACQQAAMgIAAAAAAAA AAAAAAAAAAAAAAEACQQAANgIAAAAAAAAAAAAAAAAAAAAAAEACQQAAOgIAAAgGwoAtwAAAAAA AAAAAAAA2BsKAIgCAAAAAAAAAAAAADghCgAECAAAAAAAAAAAAACwuwkAKA0AAAAAAAAAAAAA 2MgJAEhSAAAAAAAAAAAAACBZCQCwAAAAAAAAAAAAAADQWQkAKAEAAAAAAAAAAAAA+FoJAGgF AAAAAAAAAAAAAGBgCQAwAQAAAAAAAAAAAACQYQkA6AIAAAAAAAAAAAAAeGQJAKgIAAAAAAAA AAAAACBtCQCoDgAAAAAAAAAAAAAwfAkAsAAAAAAAAAAAAAAA4HwJACgBAAAAAAAAAAAAAAh+ CQBoBQAAAAAAAAAAAABwgwkAMAEAAAAAAAAAAAAAoIQJAOgCAAAAAAAAAAAAAIiHCQCoCAAA AAAAAAAAAACQkAkAsAAAAAAAAAAAAAAAQJEJACgBAAAAAAAAAAAAAGiSCQBoBQAAAAAAAAAA AADQlwkAMAEAAAAAAAAAAAAAAJkJAOgCAAAAAAAAAAAAAOibCQCoCAAAAAAAAAAAAADwpAkA qAgAAAAAAAAAAAAAmK0JAOgCAAAAAAAAAAAAAICwCQAoAQAAAAAAAAAAAADYsQkA3AMAAAAA AAAAAAAAuLUJAO4DAAAAAAAAAAAAAKi5CQACAgAAAAAAAAAAAABAKQoAoAMAAAAAAAAAAAAA 4CwKAE4DAAAAAAAAAAAAADAwCgBWAQAAAAAAAAAAAACIMQoAwAUAAAAAAAAAAAAASDcKAKQM AAAAAAAAAAAAAPBDCgCOAwAAAAAAAAAAAACARwoAVAMAAAAAAAAAAAAAYB4KACAAAAAAAAAA AAAAAMh7CQBoAAAAAAAAAAAAAAAwkAkAWgAAAAAAAAAAAAAAkKQJAFoAAAAAAAAAAAAAAKix CQAwAAAAAAAAAAAAAACAHgoAtAIAAAAAAAAAAAAACABSAEUARwBJAFMAVABSAFkABwBUAFkA UABFAEwASQBCAAAAAAAAACgAAAAQAAAAIAAAAAEAAQAAAAAAgAAAAAAAAAAAAAAAAgAAAAAA AAAAAAAA////AAAAAAAAAAAAAYAAABZgAAAkIAAAKBAAABgQAAAIEAAADBAAAAsYAAALFAAA BGQAAAZ4AAABgAAAAAAAAAAAAAAAAf//AAD//wAA//8AAP//AAD//wAA//8AAP//AAD//wAA //8AAP//AAD//wAA//8AAP//AAD//wAA//+AAP//KAAAABAAAAAgAAAAAQAEAAAAAADAAAAA AAAAAAAAAAAQAAAAAAAAAAAAAAAAAIAAAIAAAACAgACAAAAAgACAAICAAADAwMAAgICAAAAA /wAA/wAAAP//AP8AAAD/AP8A//8AAP///wBAAAAAAAAAAMRERERERERAxEREi7hEREDEj4u0 S7REQMT0i0REuERAxPg4RESDREDET7REREtEQMRI9ERES0RAxES/RERLhEDERLT/REt4QMRE OP9Eg09AxESLRE+4T0DEREu0S7d4QMRERIu4RERAxEREREREREAMzMzMzMzMxAAB//8AAP// AAD//wAA//8AAP//AAD//wAA//8AAP//AAD//wAA//8AAP//AAD//wAA//8AAP//AAD//4AA //8oAAAAEAAAACAAAAABAAgAAAAAAEABAAAAAAAAAAAAAAABAAAAAAAA////APD7/wD/1NQA qqqqAKSgoACAgIAAlgBiAJkzMwBmAAAAAKr/AACS3AAAerkAAGKWAGJiYgBWVlYAUAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA////AAg+Pj4+Pj4+Pj4+Pj4+ Pv4HCAgICAgICAgICAgICAg+BwgICAgIDgkJDggICAgIPgcIDQANCQkICAkJCAgICD4HCAAI DQkICAgICQ0ICAg+BwgADQoOCAgICA4KCAgIPgcICAAJCAgICAgICQgICD4HCAgNAAgICAgI CAkICAg+BwgICAkACAgICAgJDQgIPgcICAgJCAAACAgICQINCD4HCAgICg4AAAgIDgoIAAg+ BwgICA0JCAgIAAkNCAAIPgcICAgICQkICAkJAgINCD4HCAgICAgOCQkOCAgICAg+TVqQAAMA AAAEAAAA//8AALgAAAAAAAAAQAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA gAAAAA4fug4AtAnNIbgBTM0hVGhpcyBwcm9ncmFtIGNhbm5vdCBiZSBydW4gaW4gRE9TIG1v ZGUuDQ0KJAAAAAAAAABQRQAATAEEAKRPRzUAAAAAAAAAAOAACiMLAQUKABwEAAAoAgAAAAAA YDYDAAAQAAAAMAQAAAAOegAQAAAAEAAABQAAAAUAAAAEAAAAAAAAAABwBgAABAAA+4EGAAIA AAAAAAQAABAAAAAAEAAAEAAAAAAAABAAAADA/AMANS8AACDfAwAsAQAAAKAEAGiJAQAAAAAA AAAAAAAAAAAAAAAAADAGAMQtAAAgFQAAHAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAGAIAACQBAAAAEAAAFAUAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAC50ZXh0AAAA 9RsEAAAQAAAAHAQAABAAAAAAAAAAAAAAAAAAACAAAGAuZGF0YQAAAHhhAAAAMAQAAEAAAAAw BAAAAAAAAAAAAAAAAABAAADALnJzcmMAAABoiQEAAKAEAACQAQAAcAQAAAAAAAAAAAAAAAAA QAAAQC5yZWxvYwAAAjsAAAAwBgAAQAAAAAAGAAAAAAAAAAAAAAAAAEAAAEIkmCE0gAAAACWY ITSKAAEAJJghNIAAAAAlmCE0lwAAACWYITSiAAAAJpghNKwAAAAmmCE0uQAAAKtjGDTFAAAA JpghNM4AAAAnmCE02wAAACmYITToAAAAipQZNPQAAAD71x40AQEAACuYITQOAQAAJpghNBYB AAAAAAAAAAAAAG50ZGxsLmRsbABLRVJORUwzMi5kbGwAVVNFUjMyLmRsbABHREkzMi5kbGwA QURWQVBJMzIuZGxsAFNIRUxMMzIuZGxsAExaMzIuZGxsAGNvbWRsZzMyLmRsbABDT01DVEwz Mi5kbGwAVkVSU0lPTi5kbGwAV0lOU1BPT0wuRFJWAENGR01HUjMyLmRsbABNUFIuZGxsAFJQ Q1JUNC5kbGwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACUh6r9bIeq/rCHqvyUh 6r9JIeq/SSHqv5oh6r8lIeq/JSHqvyUh6r92Ieq/SSHqv5oh6r83Ieq/RBbqvysY6r+HF+q/ fRbqv+oV6r92E+q/NBXqv0kh6r9tIeq/QCHqv1Ih6r9JIeq/bSHqv0kh6r/RFOq/AAAAAPsu hn8/JYZ/NCSGf8EShn83L4Z/gy6Gf7cvhn/zL4Z/ey+Gf+EShn+OJ4Z/mCCGf4Mhhn/PQIZ/ 3zaGf4lAhn8hMYZ/vy6Gf/w3hn9iMYZ/lxOGf8pAhn8MQIZ/yD+Gf5wchn+WGIZ/LzCGf7kS hn+EJoZ/qRKGf7Amhn+iR4Z/7i2Gf+5Dhn8SE4Z/Qi6GfzVKhn8rKYZ/TUmGfx8ohn95RoZ/ PEeGfykzhn9rNIZ/4jKGf0hAhn8oLIZ/TyqGfz8rhn89H4Z/AAAAACxaub8aLbm/kZe3v4j2 uL9Core/Dpu3vyQMub/FUri/gky3vwAAAADKIvK/NVHyvzxR8r9CKPK/URTyv40U8r/YJPK/ Oijyvy0t8r9oIvK/kyLyv/4k8r8AAAAAI+H4v+QP+b/uXvm/MZD6v9J997+xd/e/k6v4v6du 97/Ji/i/uUH4v+f/979nffe/KJD6v+TB+b88Q/e/3Nb5v0F997+CkPq/uFf3v4KQ+r/8Lfm/ rMX4vxp3978/cfe/78T5v2eQ+r/pK/m/1Hb3v6xt97+g4Pi/rsj3v2lZ+b8PCfq/tCD4v3RX 97+FWPe/pXD3v368+L/USfe/n0L4v9Gr+L+Icve/frn3v6O5979Bf/e/qhT6vxR797/8Ffq/ 1BX6vxN697/Exfi/e935v/dE+b90sfm/Y7H5v48D+r/odPe/vnT3vyVF+b+hC/q/ZQP6v2AJ +r/HePe/SHj3v0oP+r+Te/e/lHr3v9Vv97+tFfq/+3H3vw4Y+r/7dve/pGj3v4MG+r+dx/e/ GCv5v1nq+b80GPq/cCr5v5R1979edfe/tFz5v8rU+L/fnvi/am/3v4QP+b8Ub/e/6W73v8hu 97/XE/i/G3n3v6aQ+r9lQ/e/hX33v/xy97+tc/e/aRX5v0Z59798efe/ZOD3v+JQ+L/feve/ lyD4v3Nz979YdPe/JBb6v1oI+r82c/e/4xL6v8Jy978zE/q/tw/6v7Vv97+edve/LGL5v59x 979gcfe/TUr4v1t797/EZPe/yf/3v6N99783Pfi/AAAAAPkR6L/GEei/VBLovwAAAADGK8J/ TybCfwcpwn8AAAAAoBm+fwAAAAAS4s9/HNnPf5db1H8AAAAAnST1v5AZ9b9lUfW/rRv1v4wX 9b9rFfW/cCH1v0BR9b+7J/W/ERX1vwNa9b+KLfW/Z0z1v0cU9b+OMPW/kCD1vyxa9b/eEvW/ bRf1v5VZ9b9GTPW/rlD1v0dP9b+5T/W/aRL1v+pS9b/RFfW/Pxv1vzFX9b9dV/W/M0f1v/NW 9b8RJPW/BBj1v8lJ9b/GRfW/1S/1vy8l9b+7JPW/hST1v6kb9b+yVvW/1Bv1v5gg9b/tWfW/ HFj1v0MX9b/nJPW/HRf1v0FW9b9xJPW/8E71v6Qg9b/8VvW/m1X1vypY9b//JPW/LCP1vylJ 9b+AVfW/LkH1vzo19b/sJvW/AVj1vz5J9b+FVfW/FEn1v88k9b8zJfW/mU71vwAAAABnEum/ lBTpvy8V6b8AAAAA5ifnf20r538AAAAAPmHkf9Jf5H8AAAAAABDuvwAAAAAAAAAAAAAAAAAA AAAAAAAA02EhNAAAAAAEAAAAEAEAAAAAAAAAPAYAAAAAANNhITQAAAAAAwAAAJA6AAAAAAAA ECkGAAAAAADTYSE0AAAAAAYAAAAAAAAAAAAAAKBjBj== --W460a18797GP62eO65A9 Content-Type: application/octet-stream; name=1050120239_MD[1].jpg Content-Transfer-Encoding: base64 Content-ID: /9j/4AAQSkZJRgABAgAAZABkAAD/7AARRHVja3kAAQAEAAAAWAAA/+4ADkFkb2JlAGTAAAAA Af/bAIQAAQEBAQEBAQEBAQIBAQECAgIBAQICAwICAgICAwQDAwMDAwMEBAQEBQQEBAYGBgYG BggICAgICQkJCQkJCQkJCQECAgIDAwMFBAQFCAYFBggJCQkJCQkJCQkJCQkJCQkJCQkJCQkJ CQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJ/8AAEQgAeAB4AwERAAIRAQMRAf/EAJsAAAED BQEBAAAAAAAAAAAAAAAFBgsEBwgJCgMCAQEBAQEBAQAAAAAAAAAAAAAAAQIDBAUQAAEDAwIE BAMGAwYHAAAAAAECAwQAEQUSBiExBwhBURMJYSIUcYEyIxUKkaFS8EJygjMk0eFi0kNzFxEB AQABAwIEBAYDAQAAAAAAAAERITEC8ANBUXEEYYGRMqHB0fESE7HhIjP/2gAMAwEAAhEDEQA/ AO/VxaWm3HFGyW0lSj8AL0Fv5+QRFEiU6S9MWm7DQQTquL8DytblW6swStv7PlZd9nO7pCvT JDmPwCjwRyKVPgcz46OQ8ePAYLV2KIT8tjo2XxWTxMxhMqJlI70eVGX+Bxt9BQpKvgQbGghO 97Y/NYHNZfDfqUlpeAlSYDzZfXwVCcUwRzHG6K72V1wt27k8ylZH6rIBSfmHruf91ZHyjM5j gTlJFhYf6y/58aM0rYvKZtybFZRmJDZdcQgLL7gAKlAXPHkL1USzHsY9CGegXtb9p+Kcioaz 3U/AI39uaUEkPPv72UcrF9e5JLjEB6Owr/1iufPS2HLfHk22Vlkx94bPRuFLU+C6IWegpIhy j+B1PP03QOab8jzH8QSrJuLmIQ6/p/Sdw4BzUlBV87byPC3ilQ5+BB8qir67N3bC3bi0S2Fp TMZCRPjA/gWRzF/A+FasZO+oPhxtLrbjSxdDiSlY8wRY0DBlQgcS8yshx/E3ZfvzIQPkV/mR Y1vIcG1svHzWEiS2Hg8W7syCDxDrPyqB8j41mhw1AUEM/wB8M/aL3eN3fL6cTmMnsN7qx1M/ +dTY5SqI9g29yT/p5Tak2SWy3b0zYApsR5V243R0luMxhw8tF9Ld1oJN3FCxVfhwB5D7eNZy tnkpy4hCwkcVqPytpFybePjw+NMov320dEtwdyncH0S7eNqO/S7i657rwG0cXkfSW+iCrcE1 qE5NWhsFRbiNOKfcIHBCFHkK1NmcappjbO3MNs7be39o7cgN4rb21oMTG4HFspCGo0KC0llh pCUgAJQhIAA8BXFkuUHm881HZdkPuBlhhKlvOqNkpQkXJJ8ABQYebjy6Xk7h3c+ksuZ1ZVDZ 5ENJQG2QQfHQkE/GpVXB6DbbmR4MrdctSmWso36GPjeDraFXU8ftULJ+AJ5EUhWQ1VBQIWUi +m6Mk236iQn08lH8HGD/AHreaOf2XHlVlFjMbNPTTqYuLIc0bQ6iLbQl3VqbjZUfKwsW4BMh PyKP9QR4XrOdcNWaMkKrLFDvi7pNp9mXar1n7it2rYfTsHDvq2tgH5iYBzW4Zn+3xWMbeUlz QuXLcbbCghWkEq0kA0XjxtuIiTs32/bEjsIhQ95ZmM/BaQma5JisSw8tlNgo6GmjpBBVpC+Z ubnjU/ss3e6e3443s1+G30Wvn9CYJyuJgxOqLSGMpJaYnZOVg1NogRiq8iUG2pQK0sthS9AG ohJsCSBU/tszcem0z+n1Tl2MSYufl/vzNHKdJP0rIz4eP37is1jY0iezFzqYb7QmNQ3y00+l BecUEut2cAJBANjSdzTOOuv2Y/pzPLrx3bjf2+3SvYuY94Xszg763Kcoxi8pubKbWxEZlcdp /PYbauUyMAOyo8krHpLbLpQQELKAhdwSlXSdy6yTHX7uXLjJN83r4pVGsuIoLMdQdxDJvL2r j5GmFHIVumYCAnSBcRgr481+QsPE2mVWgwm2X+q25EttoWxsTb7gE6eAUCW4nmw0RzJH4iPw j4kVJcrszAjx2IjDEWKymPGjIS3HYQkJQhCBZKUgcAAOVaZe1AUBQW23ZtDEZzGS8DlSluBM Kl495wXS0pQ+ZtJ5ix+ZP8uVSzLUoPUDbeNjO4/I70xb2aw7CV5Vn6piO8tKEfMv033Ww3qt e5VYVUsaDveI7v8Aorg8du3pB1B7y9s9CsXBg46HueNjBsPrO/GkZt5oRhvHpBuiE9lJ0U6w GnMK66/ZRceQ2wgrqcrM69deC8N8z8M/t+aPv27Kybm2cQ7mIAxUz0UJkusp9Np14p0lXpJQ lLWu/BASAkHSAAK5TD6WLiZ3misWh4zMRdxalfWw1IaQ2tyyvVS2U2uniUE2tzJH20zPHrfw 8fQ5Y1zp85+ZrMJP0UYSpEmUgtEtsoaMl5xZLd0IA1rcK9IASkaiTwvSfKlz1+O2HWp7YXt1 9C+l2c6CZfuk7ImtmdzvSbK7c3cl3Ldx+6959Z8ZuBtljJYbOp6T9PMDIxuNxhn6QlGRcCmG goSvUt+ZZxlmu/ht+E9f1ePnzvK/CdeePhpv83Y3A6znHIjr3tiFY5mW4ttE2FFyKvpyknhJ YlxI7qBa1iAq5vwArduN3DG713X1Ng5mL+kbHy3rOvgHJZxpJCY7J/uIUoD8xXK4/CL8jal5 RZPMxMDs13ftsNFkKgbKxqtOcyTJKXJzwPzRmVjwH/kX4chx4jMzy08FzhlFj8fCxUKLjcbF RCgQkJbixG0hKG0J5AAV0YVlAUBQFB5Px2JTS2JLKZDLnBbS0hST9oPCgsz1G6bdFGtjb8yO 8+m+Cye2kYzISt3R5GOYLcqIwwpx8PHRc3Qkgk+FSyLm1ETQ42EyCpOcjbeiQV5qTJyKojLI Q00qe4XSkG17AK0i/GwHOuWr6chQYSGXQI2mIhSrutkgA/LwHEA24c73FS1Zp114kaR+U5jp CnCG/rYOt5ZKkNJEhBJWlOokAAg2BPlVzZrt11j4rxmeWN/369fIlwEF6I02pv6lDzQSWnmk qSv10WIKVAp8+B5nwoxeMsxdeuvqzd6G9/fcZ0ll9Fdl7z6/dat6dtfRzGNQdn9tey+uWR6J 44tsTGHYkCblsHh5056CWFPMONgtyPmQWpLYbCTucrteuvNw5e3nL7dL19J8kkh2Yo273Cdj naL1Tiw8js/B9V+l/TncOP2HJzMrcgw6J+AhyGoqsllfUnT1shWhUqQ4p54grWolVa5T+Ty/ bbovji+hioj6mJe51uYZQ0vRmWS0+8km5SXCtWi/I2F/IisThfGn8l+IEGHjIcXHY+MiHBhI S3Fitp0obQkWAAFdGVXQFAUBQFAUGIPuDZl3b3Yd3o51lVncP0q6gSUJtfWWcHKVoHxVaw+2 pdm+3909UU8qNHjRAGmPyWWgEBIupRb4pAJvzt/zFcrl9XGCDKW8yoqITpSUBABudWgqSqxF +Cqk1Zxeuvobrqp3pw5DMoshv85yzbazZKHjZBItw0g/LY8r1Nes7piXTrrzUkJqaw6x9Y7d SEtoWSE2C0BKlD5UJTb5uVh/HjV3XS7KnOLVFDUxnQ2uGUvNXAASph0q/CeAJt/blTG86vgn pcJNP9v31Ay/Uj2duxnLZ0pOQ2ttvJ7QujXb6fYmbn7cj318bhnHo1W4A3A4Wrtx2fN7kk5W Nx1VgUBQFAUBQFAUGBHumzU4724O92Ytz00NdM92hR8wuA4kp/zXt99Z5bOnan/cRbEt1xqM 4q6lFKE6k342P2cr3rlH1KZ0lSoiT+ZZh8gsqTwJCbAnhTPiyR0JRrgNhaUB9Cm9ahZAcBu2 dQV4lar8/D75c9demCfo90ArShbitJcaSlVgAQpaQLfiI5343/nVmqKfcKArHSUFf06z67aH EgAkOXSFWNr8RbnT/AkNv2uO/nt4e18dtqYU1E6V9Td+4bHLOqy28o+xuRekqcXcIey60cAn ik3F7qV14Zxq8PuOOOXrMujKtOAoCgKAoCgKAoNavvFZP9K9sLvWe9Av/W7InwNIv8v6m41D 9Th/R6ur7qnLZ17MzziMDmuhTblrAqJKFAG5H234WA+Ncc19K0y35iWPU/JW5FeSkhKlBCUu E3vyJ+6mcJgkh9oLYUw76Ycdi/7RfBTay+LltSrpOnxuOVTZd/BXRprKksMpc1D02gtahYlK ED8QBPM8+Aq9dZKp8iUpg69CkamtZISCNSnVgpuDe3AHl/O9iV3eftItwMy+x7ue2tqK5W3u s86VqDelv0MrtTb7ifmIBKvVbcuCOAt5104TEeD3FzydV1bcBQFAUBQFAUBQasPe0mCD7WPe K8VhtLm38eytRsRpk5eE0Rx8wq1Z5/bXbsf+kRjD6kLiKS44AnQQL/LwNxz+/wA645fRN2Sp HzuuEpW1ZPAJKzwHC6goWtS0wRj6TShIeUllOpam5K0BaUJStsqWQbIGlPGx4VL8DOPoqmnp DIbivrW4WdTes3J0ougg+JFh4cvCkmNKabPjKrIhtoK9a/R1t/NwICiUg2+Itb48aJNXZP8A s/M3Kdw/uJ7ZW6TCg5jpnk4jFlBIcyEHLRXFcSeKhBT/AAHC1q6dvxeP3W8+btDrq8ooCgKA oCgKAoNWXvaRG5vtV96bbiij0dqtyG1C1/Ui5GK8jnz+ZA4eNZ57OvZ++IwsukxU3OlBuUq4 8VXtx864Xd9LJvzUl5SSrgymyWlqBTz4Am1jbhSRIbG+lMNbS3ZIUUkowuZ9JYISSfp3Dfy4 kWt/Chy1l+ZYYlolIjSEkpU+ll23G6kvtpXcfC6qLnzUOSdU5qTou0ENp03NyTzCiQbc6qY0 dgn7PSUhG6fcTgK/G/j+kUhuxNjpf3Shw+V+Ka6dt4/c+HXk7eq6PKKAoCgKAoCgKDWF70SA v2se9z8oPFGypS0JN7JU3IZUlfD+gjV91Z5bOvZ++Iu3WoxmhpU4oDg2OH/UeI8/srjX0SUt akp9RQ1BV7aBqv4C4Pnfjzpspmb1jyHNqbq9Vzg5jci0WU2SpalxVoTy/wAXj4VM2Jyzr6V7 4Z0u4jbToB0nFYtzUU8VFUJtZBtzN+F6hwuYq5TyXQpGtSFDSGlG+kEENklJ5eFvOr6K6zf2 fe6cMz1w76doSFadwZvZvTrJYdvVwMTE5LNsTSBcXsuZHHI28xex69u7vF7m7O7iujyigKAo CgKAoCg1ie8/NTA9rDvhfU0l5K9jT2VJUbACQ601qHxTquPiKnLZ17P3xFypcStj09QCihNu Nr2IFhYfH+3j56+iTNa76kJOkFKb8LgqXe97/D7vOi6GdnI8t7FZRt1ougtOo9bkpJWldx42 vcf2NTltU5bV7YgIaxcDHvAetCjR2QVXP+m0E+HHgBTjNIccYfcklLvpoPAHUhSRa9+JAuR5 eNCuiP8AalZxOF903fOMWoMp3f0b3nFaZBSkFyPndvTE/iIJIS2s2Fzz8LkdO3MWvJ7jb5pG 2uzyCgKAoCgKAoCg1Be/XOVA9pbvB0L9Mz8btyGV+Qm7ixrJv9oXas8tnXsffEY2iJMbaCVJ LKhx5KN1BXwFiD4G9cn0VK6j5XUqSGeI+UJNtRtqNuAHlWavk8YmGz24sljtu4HCy9wZjMS4 sTD4HHQ3Jk2fLkrS0xFjR2UrdedecUEIbQkqUohIBJFRLZFbvfae4Nobr3DtPdm1stsfcWBl +hmds5nGzMJl4LzbabsTIMxtmQwsX4ocQkjytSTEkpx5ZkspsqS5ZDt7A6ggDhwtYimVblf2 6+5Bt33fu2gqdTHa3PF3linyQAVJkbdyDyUi/wDU803W+G8efvY/hUnrXd4BQFAUBQFAUBQI +4NvYDdmEym2t04OHuXbmcYcjZvb+QjNzIUyM6NK2n2HkqbcQocClQINBgLvn2k/bS6irW7u Tsp2Ay84VFyRicI3t91SlXBUpeKMZRPHmTfl5C0/jG53OU8a1a7z/b4+3Lnt/b6Vi+kme25h Ys1CMbiMfvjOoZZSqO2pQT68p5VipRPE/DlWL246zv8AKeJp4L2IuyPo31U6S9Ttq7X3ZGy2 wN07dzuKLu8Z0lluRhclHnNKLax8wStpPAn/AI0nDFhe/wArLqym7n/28nZJ3XdcupPcFvzf fUfB756rZJWV3ZHxebxf0H1ZabYBYbm4uS42lLbSQlOsgeFavCVOPuOUmNGCU/8AatdoCtxZ qCnuS6rRMbEfSvFxgdrLX9M8lKk6nDh06tKipN9IvapO3qt9xzvkyW7WvYQ7K+xruA6T9xm1 s9vzqNvjYOWS7gZ+487ERBhyJrTkT6j6XEwoKXCgPE2WVJ8waThis8u5y5TDo5rbiKAoCgKA oCgKAoCgtK9A1bm3Ogp+V51hy9+NlsoF/wCIqxoxd/4zVj2kpZur1EBCvEqJAA/jUphkmOQv zoyt7mWtO7U6l6UZDHoSj/FGeUT/ACcFWNQjbsw4y238nAPzKU0pTKxwOpIuONWouBtnJnNb ew2VWNLs6M0t9P8AS6UjWPuVcVlC5QFAUBQf/9=9 --W460a18797GP62eO65A9-- From owner-ipsec@lists.tislabs.com Fri Jun 27 03:04:51 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5RA4orb027933; Fri, 27 Jun 2003 03:04:50 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id FAA27804 Fri, 27 Jun 2003 05:23:58 -0400 (EDT) Message-Id: <200306270929.h5R9Toof073216@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Paul Hoffman / VPNC cc: ipsec@lists.tislabs.com Subject: Re: Suggested wording for weak key lengths in IKEv2 In-reply-to: Your message of Thu, 26 Jun 2003 11:15:00 PDT. Date: Fri, 27 Jun 2003 11:29:50 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: Greetings again. Now that the WG last call is finished , it seems like having proposed wording might help resolve some of the open issues on Angelos' issue list. (You all are watching , yes?) => it seems the lack of protection for the peer addresses (recognized as a "security flaw" at Yokohama's meeting) is still missing: if we can postpone mobility/multi-homing/etc stuff, this is not the case for this issue: some words somewhere are needed. Thanks for the pointer. Francis.Dupont@enst-bretagne.fr PS: there are at least two solutions: - make NAT detection mandatory and use the implicit protection this mechanism provides (Tero's solution). - promise an explicit protection for address of peers which are not behind a NAT in "important" exchanges (My solution). As the issue interacts with NAT traversal (either the peer is behind a NAT and its address cannot be protected, or it is not behind a NAT and its address must be protected) we need the final version of the draft to see if the issue is closed. From owner-ipsec@lists.tislabs.com Fri Jun 27 07:39:15 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5REdErb043282; Fri, 27 Jun 2003 07:39:14 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA00063 Fri, 27 Jun 2003 09:56:44 -0400 (EDT) Message-ID: <2A8DB02E3018D411901B009027FD3A3F03BBFF3F@mchp905a.mch.sbs.de> From: Tschofenig Hannes To: "'Michael Thomas'" , Black_David@emc.com Cc: kent@bbn.com, ipsec@lists.tislabs.com Subject: RE: QoS selectors (was LAST CALL: IKE) Date: Fri, 27 Jun 2003 15:55:09 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk hi michael, why do you think that it is not a good idea to select qos flows based on the flow label (3 tuple)? ciao hannes > -----Original Message----- > From: Michael Thomas [mailto:mat@cisco.com] > Sent: Thursday, June 26, 2003 11:03 PM > To: Black_David@emc.com > Cc: kent@bbn.com; ipsec@lists.tislabs.com > Subject: RE: QoS selectors (was LAST CALL: IKE) > > > > Just as a general note, the ip6 flowlabel is not > akin to the DSCP. The flowlabel is much more akin > to the 5-tuple. I'm not sure that it's a good idea > to select flows based on it. Or at least via IKE > right now. What is the downside to deferring > saying anything about the flowlabel here? If it > must be done now, it would be a good idea to run > this all by the authors... > > Mike > > Black_David@emc.com writes: > > Steve, > > > > > Several folks have asked for the ability to place traffic with > > > different TOS values on different SAs, which requires > that the TOS > > > field (IPv4) and the flow spec field (IPv6) be useable > as selectors. > > > > That includes me - see Section 4.1 of RFC 2983. > > > > > If we agree to add this feature, we need the ability to > negotiate > > > this in IKE. What I meant to say is closer to what David > referred to > > > in his message, i.e., I would anticipate a sender using > the 6-bit DS > > > field as an additional selector value (not the ECN > bits). I don't > > > think this is affected by the question of whether the > interpretation > > > of these bits is uniform across ISPs. The concern is > that if these > > > bits really do have an affect on the order of delivery > of traffic, > > > then putting different classes of traffic into the same > SA has the > > > potential to cause a non-trivial percentage of the > (lower priority) > > > traffic to be rejected due to receiver window mismatches. > > > > Use of DSCPs (6-bit DS Field) as selectors is fine as long as the > > receiver is not expected to be able to understand/check/verify how > > the sender assigned traffic to the SAs. That does appear to be > > the case here (receiver doesn't have to check how sender assigns > > traffic to SAs). > > > > One note for selector design - with the exception of "all", masks > > or wildcards are not to be used; there will be cases in > which multiple > > DSCPs are needed in a single selector (e.g., when > indicating different > > levels of drop preference) - in all such cases, an explicit list > > is the right approach. This is based on the diffserv architecture, > > as specified/described in RFCs 2474/2475. > > > > > Now this is > > > not a problem if the bits are inside a tunnel and NOT > propagated to > > > the outer header, but then they are not helping out > during transit > > > across unprotected nets. I admit to not being familiar > with PHIBs, so > > > I'm not sure what the issues are there. I'm also open to > suggestions > > > from IPv6 experts about what to do there, for flows. > > > > PHBs are only relevant to this discussion if there's a > need for both > > ends to understand the QoS-based SA selection, as their > purpose is t > > provide a network domain-independent representation of > traffic QoS classes. > > > > > Mark & Radia suggest that we don't need this facility to be > > > negotiated. I didn;'t understand the arguments until I > worked my way > > > through the cases. Now I think I understand the arguments, and > > > basically agree. Let me try to examine the relevant cases: > > > > [... Analysis snipped, as I basically agree ...] > > > > > So, what this seems to suggest is that there is a good use for > > > DiffServ bits (or PHIBs, or whatever) as selectors, but > that if one > > > uses them, one need not tell the receiver. Is that right? > > > > That sounds good to me. I strongly prefer to keep IKE > > out of the QoS negotiation business. > > > > Thanks, > > --David > > ---------------------------------------------------- > > David L. Black, Senior Technologist > > EMC Corporation, 176 South St., Hopkinton, MA 01748 > > +1 (508) 293-7953 FAX: +1 (508) 293-7786 > > black_david@emc.com Mobile: +1 (978) 394-7754 > > ---------------------------------------------------- > From owner-ipsec@lists.tislabs.com Fri Jun 27 07:55:31 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5REtUrb043919; Fri, 27 Jun 2003 07:55:31 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00405 Fri, 27 Jun 2003 10:19:23 -0400 (EDT) Message-Id: From: "Knospe, Heiko" To: ipsec@lists.tislabs.com Subject: IKEv2: active user identity protection Date: Fri, 27 Jun 2003 16:25:17 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Dear all, I would also strongly support active user identity confidentiality protection for the initiator within IKEv2. The issue was recently raised by several people. We analysed the topic in the SHAMAN project and considered it a significant security requirement. It seems particularly important for wireless connections where attacks can easily be launched. Best wishes, Heiko Knospe T-Systems ITC Security Am Kavalleriesand 3 D 64295 Darmstadt Germany Tel. ++49 6151 832033 From owner-ipsec@lists.tislabs.com Fri Jun 27 08:14:52 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5RFEprb047106; Fri, 27 Jun 2003 08:14:51 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00873 Fri, 27 Jun 2003 10:39:53 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: References: Date: Fri, 27 Jun 2003 10:46:27 -0400 To: Henry Spencer From: Stephen Kent Subject: Re: IKE negotiation for fragmentation controls in IPsec Cc: IP Security List Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:35 PM -0400 6/26/03, Henry Spencer wrote: >On Wed, 25 Jun 2003, Stephen Kent wrote: >> As we revise 2401, we may choose to allow (or even recommend) >> plaintext (pre-IPsec encapsulation) fragmentation. If so, we need to >> be able to negotiate use of this capability on a per-SA basis, and to >> notify the receiver that NO ciphertext fragments should be accepted >> for this SA, because none will be sent by this transmitter... > >There is a problem here, in that fragmentation is not entirely under the >control of the transmitter. Intervening gateways may fragment the >encrypted packets. This situation can change dynamically, as routing >changes, and the transmitter can't count on getting feedback about it, >because many firewalls apparently block ICMP Fragmentation Required >messages. > > Henry Spencer > henry@spsystems.net Well, I was assuming (but I should have said so explicitly) that the transmitter, if it negotiated this option, would set the DF bit, having selected a suitable PMTU. You are right that route changes can cause the PMTU to change, which would require adaptation by the transmitter. I also acknowledge the problem posed by firewalls that block ICMP. However, in many common cases, one will encounter the IPsec implementation at the firewall, not behind it, and thus this would be less of a problem. So, given the residual problems we know about, the question still stands whether we want to include the option, with the understanding that the transmitter is the one who will ultimately have to take responsibility for making this work. The receiver's job is simple, as all it needs to do, if it wishes, is to reject post-encapsulation fragments. Steve From owner-ipsec@lists.tislabs.com Fri Jun 27 09:04:47 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5RG4krb050206; Fri, 27 Jun 2003 09:04:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA01932 Fri, 27 Jun 2003 11:29:47 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <090b01c33c0c$a709b050$0202a8c0@SindhuSriha> References: <090b01c33c0c$a709b050$0202a8c0@SindhuSriha> Date: Fri, 27 Jun 2003 11:31:26 -0400 To: "Srinivasa Rao Addepalli" From: Stephen Kent Subject: Re: IKE negotiation for fragmentation controls in IPsec Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:59 AM -0700 6/26/03, Srinivasa Rao Addepalli wrote: >Hi Steve, > > Negotiation on SA basis: > Assuming that intermediate router fragmentation problem is solved, > does it require negotiation on SA basis? I feel, it can be on peer basis. > Either it can be set as local configuration on peer basis or capabilities > of the peers can be exchanged using Vendor ID attributes. One might choose to do this on an SA basis, because TCP deals well with PMTU-imposed packet size restrictions, but UDP does not. So, by allowing per-SA negotiation for this we can accommodate different protocol capabilities re PMTU. > > Port Selector information: > I did not understand all the details you mentioned. I feel, there >is no need > for any IKE negotiation for tunnel mode sessions. I try to list down the > steps. > > Outbound Processing steps: > - Reassemble the packet (Packet coming from trusted network). NO. there is no implied reassembly by the transmitter. I won't comment on the rest of your message since this assumption was not right and it may influence later parts of your message. Steve From owner-ipsec@lists.tislabs.com Fri Jun 27 09:05:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5RG5Drb050228; Fri, 27 Jun 2003 09:05:13 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA01931 Fri, 27 Jun 2003 11:29:46 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <090701c33c09$7ebd6720$0202a8c0@SindhuSriha> References: <090701c33c09$7ebd6720$0202a8c0@SindhuSriha> Date: Fri, 27 Jun 2003 11:27:55 -0400 To: "Srinivasa Rao Addepalli" From: Stephen Kent Subject: Re: IKE negotiation for fragmentation controls in IPsec Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:36 AM -0700 6/26/03, Srinivasa Rao Addepalli wrote: >Hi, > >Imagine this scenario: > > >-----------SecurityGW1----------Router1----Router2------------SecurityGW2--- > >As I understand from the description, once SG1 and SG2 negotiate >and come to understanding, then SG2 can drop fragmented secured >packets. But the routers in between can fragment the packets. >To avoid this situation, SG1 has to set the DF bit and PMTU >processing should be MUST in this case. Is it right to assume that >all core and edge routers/firewalls in Internet and enterprise support passing >the ICMP error messages? I keep hearing that most (may be some) firewalls >can be explicitly configured to discard ICMP error messages. > >Thanks >Srini Any statement of the form "all X in the Internet do Y" is very likely to be false :-) In many (most?) current deployments, IPsec is at the perimeter of an organizational enclave and thus is either parallel to a firewall or is part of the same system as a firewall. if an IPsec system is behind a firewall, then one encounters problems with getting IPsec traffic through, in many cases, just as one might have trouble getting ICMP traffic through. Ultimately, the best solution, from a pragmatic and security perspective, is likely to be a means of determine PMTU that rides over IPsec, e.g., within a tunnel, and thus avoids the question of whether any intermediate routers or firewalls play the PMTU discovery game. It would be possible to do that today, sending ICMP traffic between two IPsec implementations, encapsulated in a tunnel, if the SPDs at each end allow it, but we ought to consider a more formal specification of a mechanism going forward. Steve From owner-ipsec@lists.tislabs.com Fri Jun 27 09:06:55 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5RG6srb050271; Fri, 27 Jun 2003 09:06:54 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA01938 Fri, 27 Jun 2003 11:29:50 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <277DD60FB639D511AC0400B0D068B71E0564CE31@corpmx14.us.dg.com> References: <277DD60FB639D511AC0400B0D068B71E0564CE31@corpmx14.us.dg.com> Date: Fri, 27 Jun 2003 11:33:04 -0400 To: Black_David@emc.com From: Stephen Kent Subject: RE: QoS selectors (was LAST CALL: IKE) Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 2:33 PM -0400 6/26/03, Black_David@emc.com wrote: >Steve, > >> Several folks have asked for the ability to place traffic with >> different TOS values on different SAs, which requires that the TOS >> field (IPv4) and the flow spec field (IPv6) be useable as selectors. > >That includes me - see Section 4.1 of RFC 2983. > >> If we agree to add this feature, we need the ability to negotiate >> this in IKE. What I meant to say is closer to what David referred to >> in his message, i.e., I would anticipate a sender using the 6-bit DS >> field as an additional selector value (not the ECN bits). I don't >> think this is affected by the question of whether the interpretation >> of these bits is uniform across ISPs. The concern is that if these >> bits really do have an affect on the order of delivery of traffic, >> then putting different classes of traffic into the same SA has the >> potential to cause a non-trivial percentage of the (lower priority) >> traffic to be rejected due to receiver window mismatches. > >Use of DSCPs (6-bit DS Field) as selectors is fine as long as the >receiver is not expected to be able to understand/check/verify how >the sender assigned traffic to the SAs. That does appear to be >the case here (receiver doesn't have to check how sender assigns >traffic to SAs). > >One note for selector design - with the exception of "all", masks >or wildcards are not to be used; there will be cases in which multiple >DSCPs are needed in a single selector (e.g., when indicating different >levels of drop preference) - in all such cases, an explicit list >is the right approach. This is based on the diffserv architecture, >as specified/described in RFCs 2474/2475. In the new model IKEv2 (and soon, 2401bis) have for selectors, all of them are represented as a list of ranges, uniformly. > >> Now this is >> not a problem if the bits are inside a tunnel and NOT propagated to >> the outer header, but then they are not helping out during transit >> across unprotected nets. I admit to not being familiar with PHIBs, so >> I'm not sure what the issues are there. I'm also open to suggestions >> from IPv6 experts about what to do there, for flows. > >PHBs are only relevant to this discussion if there's a need for both >ends to understand the QoS-based SA selection, as their purpose is t >provide a network domain-independent representation of traffic QoS classes. > >> Mark & Radia suggest that we don't need this facility to be >> negotiated. I didn;'t understand the arguments until I worked my way >> through the cases. Now I think I understand the arguments, and >> basically agree. Let me try to examine the relevant cases: > >[... Analysis snipped, as I basically agree ...] > >> So, what this seems to suggest is that there is a good use for >> DiffServ bits (or PHIBs, or whatever) as selectors, but that if one >> uses them, one need not tell the receiver. Is that right? > >That sounds good to me. I strongly prefer to keep IKE >out of the QoS negotiation business. > >Thanks, >--David >---------------------------------------------------- >David L. Black, Senior Technologist >EMC Corporation, 176 South St., Hopkinton, MA 01748 >+1 (508) 293-7953 FAX: +1 (508) 293-7786 >black_david@emc.com Mobile: +1 (978) 394-7754 >---------------------------------------------------- From owner-ipsec@lists.tislabs.com Fri Jun 27 09:55:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5RGtGrb051693; Fri, 27 Jun 2003 09:55:16 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03118 Fri, 27 Jun 2003 12:20:04 -0400 (EDT) From: Michael Thomas MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16124.28689.215559.122424@thomasm-u1.cisco.com> Date: Fri, 27 Jun 2003 09:25:53 -0700 (PDT) To: Tschofenig Hannes Cc: "'Michael Thomas'" , Black_David@emc.com, kent@bbn.com, ipsec@lists.tislabs.com Subject: RE: QoS selectors (was LAST CALL: IKE) In-Reply-To: <2A8DB02E3018D411901B009027FD3A3F03BBFF3F@mchp905a.mch.sbs.de> References: <2A8DB02E3018D411901B009027FD3A3F03BBFF3F@mchp905a.mch.sbs.de> X-Mailer: VM 6.72 under 21.1 (patch 6) "Big Bend" XEmacs Lucid X-Face: &,heK/V66p?[2!i|tVn,9lN0TUvEv7:9FzXREj/AuzN4mu!4x[/Z4t{V}~L]+Sk @RFNnJEg~WZ/(8<`5a),-7ukALWa^&?&D2R0CSG3kO5~#6JxLF\d,g">$%B!0w{W)qIhmwhye104zd bUcI'1! Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Tschofenig Hannes writes: > hi michael, > > why do you think that it is not a good idea to select qos flows based on the > flow label (3 tuple)? No, my note was merely cautionary. The flow label as its been standardized is both different than what I understood being discussed here and has permuted subtly from the generally understood meaning before it was standardized. Not really understanding it fully could lead to a disconnect. As I said, if the flow label authors feel comfortable though, I'm satisfied too. Mike From owner-ipsec@lists.tislabs.com Fri Jun 27 10:10:30 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5RHATrb052223; Fri, 27 Jun 2003 10:10:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03507 Fri, 27 Jun 2003 12:37:24 -0400 (EDT) Message-Id: <200306271642.h5RGgsB15960@yogi> X-Mailer: exmh version 2.6.2 03/21/2003 with nmh-1.0.4 To: ipsec@lists.tislabs.com Subject: Re: IKEv2 payload #14 In-Reply-To: Your message of "Tue, 24 Jun 2003 19:26:18 EDT." <200306242326.h5ONQIq3028171@thunk.east.sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 27 Jun 2003 11:42:54 -0500 From: "Stephen C. Koehler" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > Renumbering the payloads so they're non-overlapping sounds like a good > idea. Now's the time to do it.. So far, I have heard only positive feedback on my proposal to renumber IKEv2 payloads so they don't overlap with IKEv1 payloads, or at least to move the ones that collide or have changed syntax. However, the topic seems to have died on the list without any clear indication that this idea has been accepted. As Bill stated, now is the time to do this if we are going to do it. I would really like to hear arguments from anyone who thinks we should not make this change, even if the argument is that it is too late to make bits on the wire changes. -- Steve Koehler koehler@securecomputing.com From owner-ipsec@lists.tislabs.com Fri Jun 27 12:48:37 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5RJmbrb060864; Fri, 27 Jun 2003 12:48:37 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06642 Fri, 27 Jun 2003 15:09:49 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <0a7301c33c3e$e9d4c460$0202a8c0@SindhuSriha> References: <200306091606.h59G62of004050@givry.rennes.enst-bretagne.fr> <0a7301c33c3e$e9d4c460$0202a8c0@SindhuSriha> Date: Fri, 27 Jun 2003 15:09:19 -0400 To: "Srinivasa Rao Addepalli" From: Stephen Kent Subject: Re: issue with "per-interface SAD/SPD" Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk What we are envisioning for 2401bis is a virtual interface ID, which would allow a local administrator considerable flexibility in deciding the granularity at which SPDs are managed. One could map all traffic to on VID and have just one SPD instance, or one could map different SSIDs to different VIDs to address the WLAN scenario you described. Leaving this sort of thing completely undefined is not attractive to me, because such ambiguity creates possible interop problems. I'd like to think that the VID concept, which we will describe in greater detail in messages next week, is a good, uniform interface capability that can be adapted to a wide range of environments. Steve From owner-ipsec@lists.tislabs.com Fri Jun 27 12:57:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5RJvjrb061126; Fri, 27 Jun 2003 12:57:46 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06882 Fri, 27 Jun 2003 15:19:07 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <5.2.0.9.0.20030626165534.05649cf0@email> References: <5.2.0.9.0.20030626165534.05649cf0@email> Date: Fri, 27 Jun 2003 15:19:52 -0400 To: Mark Duffy From: Stephen Kent Subject: RE: QoS selectors (was LAST CALL: IKE) Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 5:08 PM -0400 6/26/03, Mark Duffy wrote: >In my understanding, everything that we today call "selectors" are >negotiated in IKE, used at the IPsec sender to decide how to send >packets, and used at the IPsec receiver to decide whether to accept >packets. > >If we agree that it is a local matter for the sender to decide which >packets to send on which of n "redundant" SAs (whether this decision >is based on DiffServ codepoint/PHB or whatever) then I would propose >we don't call whatever rules govern that selectors. I think to do >so would create confusion vs the exisiting concept of selectors. I disagree. Selectors are fields and values used to map outbound traffic to an SA. Generally we need to communicate these values to the receiver, so that that receiver can verify receiver traffic is consistent with what is negotiated, and because we want to make sure that the receiver's policy is consistent with that the the transmitter. In the case of the DiffServ bits, we have an example where the receiver may not need to know, for security purposes, what the values are for traffic mapped to one SA vs. another, but that does not change the basic role of selectors as the fields/values used to map traffic to an SA. >Moreover, if it is a local matter at the sender I don't see any need >to standardize it at all. Let's just say you are allowed to have >"redundant" SAs (with the same properties) and the sender can use >whichever of those SAs it wants to to send any given packet. For >the current discussion that decision would be to send packets of >different Ordered Aggregates [RFC 3260] on different SAs but it >could be for any other reason as well. (Load balancing across >encryption hardware units, perhaps?) I like to see the DiffServ bits defined as part of the standard, not for interop purposes, but for uniform feature purposes. I'd like to be able to characterize what IPsec implementation can do, to address questions of the sort that motivate this discussion, rather than saying: "well, IPsec may discard lots of packets if you map multiple classes of traffic to one SA and if you pass through the DiffServ bits, unless your vendor happens to have made special provisions to do something ..." Steve From owner-ipsec@lists.tislabs.com Fri Jun 27 13:52:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5RKqlrb063333; Fri, 27 Jun 2003 13:52:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08035 Fri, 27 Jun 2003 16:14:55 -0400 (EDT) Message-Id: <5.2.0.9.0.20030627161558.01fe2748@email> X-Sender: mduffy@email X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Fri, 27 Jun 2003 16:20:03 -0400 To: Stephen Kent From: Mark Duffy Subject: RE: QoS selectors (was LAST CALL: IKE) Cc: ipsec@lists.tislabs.com In-Reply-To: References: <5.2.0.9.0.20030626165534.05649cf0@email> <5.2.0.9.0.20030626165534.05649cf0@email> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 03:19 PM 6/27/2003 -0400, Stephen Kent wrote: >At 5:08 PM -0400 6/26/03, Mark Duffy wrote: >>In my understanding, everything that we today call "selectors" are >>negotiated in IKE, used at the IPsec sender to decide how to send >>packets, and used at the IPsec receiver to decide whether to accept packets. >> >>If we agree that it is a local matter for the sender to decide which >>packets to send on which of n "redundant" SAs (whether this decision is >>based on DiffServ codepoint/PHB or whatever) then I would propose we >>don't call whatever rules govern that selectors. I think to do so would >>create confusion vs the exisiting concept of selectors. > >I disagree. Selectors are fields and values used to map outbound traffic >to an SA. Generally we need to communicate these values to the receiver, >so that that receiver can verify receiver traffic is consistent with what >is negotiated, and because we want to make sure that the receiver's policy >is consistent with that the the transmitter. In the case of the DiffServ >bits, we have an example where the receiver may not need to know, for >security purposes, what the values are for traffic mapped to one SA vs. >another, but that does not change the basic role of selectors as the >fields/values used to map traffic to an SA. OK. You are much more in tune with the nomenclature than I am. >>Moreover, if it is a local matter at the sender I don't see any need to >>standardize it at all. Let's just say you are allowed to have >>"redundant" SAs (with the same properties) and the sender can use >>whichever of those SAs it wants to to send any given packet. For the >>current discussion that decision would be to send packets of different >>Ordered Aggregates [RFC 3260] on different SAs but it could be for any >>other reason as well. (Load balancing across encryption hardware units, >>perhaps?) > >I like to see the DiffServ bits defined as part of the standard, not for >interop purposes, but for uniform feature purposes. I'd like to be able to >characterize what IPsec implementation can do, to address questions of the >sort that motivate this discussion, rather than saying: "well, IPsec may >discard lots of packets if you map multiple classes of traffic to one SA >and if you pass through the DiffServ bits, unless your vendor happens to >have made special provisions to do something ..." OK. I don't have any particular problem with that, I was just trying to save work :-) I do hope it will anyway be permissible for the sender to send on multiple SAs for other purposes, that the receiver isn't necessarily privy to. --Mark >Steve From owner-ipsec@lists.tislabs.com Fri Jun 27 14:01:31 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5RL1Urb063895; Fri, 27 Jun 2003 14:01:30 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA08303 Fri, 27 Jun 2003 16:26:14 -0400 (EDT) Message-ID: <041401c33ceb$334bc290$0202a8c0@SindhuSriha> Reply-To: "Srinivasa Rao Addepalli" From: "Srinivasa Rao Addepalli" To: "Stephen Kent" Cc: References: <200306091606.h59G62of004050@givry.rennes.enst-bretagne.fr> <0a7301c33c3e$e9d4c460$0202a8c0@SindhuSriha> Subject: Re: issue with "per-interface SAD/SPD" Date: Fri, 27 Jun 2003 13:32:16 -0700 Organization: Intoto Inc. 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Hi Steve, I was talking to my one of my colleagues on this and you are right that there may be need for interoperability. Today, implementations ( I am not sure of others, we do this way) identify the VID,during IKE phase1 negotiations by the IP address on which packets have come (Destination IP of phase1 messages). Due to this the system should have as many IP addresses as number of VIDs supported in the system. By having some interoperable way of sending VID as part of phase1 might solve this problem. If you think we should wait until details you plan to send by next week, then that is fine. Thanks Srini Intoto Inc. Enabling Security Infrastructure 3160, De La Cruz Blvd #100 Santa Clara, CA 95054 www.intotoinc.com ----- Original Message ----- From: "Stephen Kent" To: "Srinivasa Rao Addepalli" Cc: Sent: Friday, June 27, 2003 12:09 PM Subject: Re: issue with "per-interface SAD/SPD" > What we are envisioning for 2401bis is a virtual interface ID, which > would allow a local administrator considerable flexibility in > deciding the granularity at which SPDs are managed. One could map all > traffic to on VID and have just one SPD instance, or one could map > different SSIDs to different VIDs to address the WLAN scenario you > described. Leaving this sort of thing completely undefined is not > attractive to me, because such ambiguity creates possible interop > problems. I'd like to think that the VID concept, which we will > describe in greater detail in messages next week, is a good, uniform > interface capability that can be adapted to a wide range of > environments. > > Steve From owner-ipsec@lists.tislabs.com Fri Jun 27 15:24:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5RMOwrb066862; Fri, 27 Jun 2003 15:24:59 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA09959 Fri, 27 Jun 2003 17:46:42 -0400 (EDT) From: jknowles@SonicWALL.com Message-Id: <200306272146.RAA09955@lists.tislabs.com> X-MimeOLE: Produced By Microsoft Exchange V6.0.6375.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Subject: RE: IKEv2: active user identity protection Date: Fri, 27 Jun 2003 14:53:05 -0700 Thread-Topic: IKEv2: active user identity protection Thread-Index: AcM8xCpV56g65f+fQiW8E85kQu8FsQAMQg7g To: , X-OriginalArrivalTime: 27 Jun 2003 21:53:05.0332 (UTC) FILETIME=[7D009F40:01C33CF6] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by lists.tislabs.com id RAA09956 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I also support Hugo's suggested changes to provide this protection. I think many end-user scenarios demand it. Aggressive mode failed to protect identities and is criticized for this (I heard today this exact criticism from a customer). We still have a chance to fix this without unnecessary delay. Regards, Jim > -----Original Message----- > From: Knospe, Heiko [mailto:Heiko.Knospe@t-systems.com] > Sent: Friday, June 27, 2003 7:25 AM > To: ipsec@lists.tislabs.com > Subject: IKEv2: active user identity protection > > > Dear all, > > I would also strongly support active user identity > confidentiality protection for the initiator within IKEv2. > The issue was recently raised by several people. We analysed > the topic in the SHAMAN project and considered it a > significant security requirement. It seems particularly > important for wireless connections where attacks can easily > be launched. > > Best wishes, > Heiko Knospe > > T-Systems > ITC Security > Am Kavalleriesand 3 > D 64295 Darmstadt > Germany > > Tel. ++49 6151 832033 > > From owner-ipsec@lists.tislabs.com Fri Jun 27 16:16:59 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5RNGwrb068282; Fri, 27 Jun 2003 16:16:59 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA11153 Fri, 27 Jun 2003 18:45:12 -0400 (EDT) Message-ID: <047f01c33cfe$9d912240$0202a8c0@SindhuSriha> Reply-To: "Srinivasa Rao Addepalli" From: "Srinivasa Rao Addepalli" To: "Stephen Kent" Cc: References: <090b01c33c0c$a709b050$0202a8c0@SindhuSriha> Subject: Re: IKE negotiation for fragmentation controls in IPsec Date: Fri, 27 Jun 2003 15:51:15 -0700 Organization: Intoto Inc. 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.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > > Outbound Processing steps: > > - Reassemble the packet (Packet coming from trusted network). > > NO. there is no implied reassembly by the transmitter. > > I won't comment on the rest of your message since this assumption was > not right and it may influence later parts of your message. > I am curious on why this is not needed. IPSEC SPD supports selector space with not only IP addresses, but also with TCP/UDP port values. If some sort of reassembling is not done(either wait for all fragments OR maintain reassembly state with IP ID, SIP, DIP), there is possibility of mapping the non-first fragments of the packets to the wrong security policy. Only first fragment has TCP/UDP information and it chooses the correct security policy. Complete IP reassembling helps in finding out obvious DoS attacks and helps in reducing the number of encapsulated IPSEC packets. Srini From owner-ipsec@lists.tislabs.com Sat Jun 28 01:23:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5S8N0rb081445; Sat, 28 Jun 2003 01:23:00 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id DAA18725 Sat, 28 Jun 2003 03:38:26 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16125.18207.934384.924599@ryijy.hel.fi.ssh.com> Date: Sat, 28 Jun 2003 10:43:27 +0300 From: Tero Kivinen To: jknowles@SonicWALL.com Cc: , Subject: RE: IKEv2: active user identity protection In-Reply-To: <200306272146.RAA09955@lists.tislabs.com> References: <200306272146.RAA09955@lists.tislabs.com> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 17 min X-Total-Time: 18 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk jknowles@SonicWALL.com writes: > I also support Hugo's suggested changes to provide this > protection. I think many end-user scenarios demand it. > Aggressive mode failed to protect identities and is > criticized for this (I heard today this exact criticism > from a customer). We still have a chance to fix this > without unnecessary delay. The IKEv2 will protect the identities for passive attacks. In the IKEv1 aggressive mode there was no protection for the passive attacks at all (execpt in RSA encryption mode, and there you also needed to send the certificate to be used, so actually you always gave out your identity...). Also note, that IKEv1 DID NOT protect initiators identity in the main mode from the active attacks when using signatures either. Also the preshared keys in main mode didn't offer any real protection of the identity, because the responder needed to know before decrypting the packet which key to use (i.e it needed to know the who the other end based on the IP address). To make it simple list: 1) Current draft do protect identities from the passive attacks always. 2) For the active attacks there is no way to protect both ends for the identity (either one of them must first proof who they are). (Ok, you could use one time identities stuff exchange inside the encrypted exchange, and you actually can already use them in the EAP cases without any changes to the protocol if you want to). 3) The question is who proofs the identity first, in the IKEv1 it was always the initiator, for IKEv2 it is always the initiator (i.e no change here). 4) Hugos proposal was to add new mode that would change the protocol so that the responder would proof its identity first in case of EAP is used, this opens attack called polling attack, which allows active attacker to get proof who everybody is in the internet if the other end is willing to talk EAP. 5) The current draft protects the identities better in real cases than IKEv1 (in the IKEv1 in RSA encryption mode and in the preshared keys active attacker couldn't go spoof the other end, but on the other hand the real responder couldn't either go forward before it know who the other end already was (i.e from the IP address or if there was only one client). If the real responder needed to know this based on the IP then the attacker would learn that also quite quickly). So, I suggest that those who really have requirement that the initiators identity must be protected against active attack use one time identities (ID_KEY_ID), i.e the server have list of identities for each client, and every time the client connects the client uses the next one on the list. I.e the client never uses same identity, thus giving the identity protection on the initiator even for active attacks. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Jun 30 07:27:00 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UEQxFK065824; Mon, 30 Jun 2003 07:27:00 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA20962 Mon, 30 Jun 2003 09:30:18 -0400 (EDT) Message-ID: <3F003CE1.BF6703A@torrentnet.com> Date: Mon, 30 Jun 2003 09:36:33 -0400 From: Jim Comen X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.18-27.7.x i686) X-Accept-Language: en MIME-Version: 1.0 To: ipseclist Subject: NPF Info and/or site password Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I'm trying to look on the NPF site for info about IKE and/or IPSec but can't find any. Whereas it's not yet standardized, would there be anything on the site about IKE or IPSec? Also, does anyone know what our NPF site uid/pwd is? Thanks Jim -- Jim Comen jcomen@torrentnet.com Ericsson IP Infrastructure Voice (919) 472 - 9932 920 Main Campus Drive, Suite 544 Fax (919) 472 - 9999 Raleigh, NC 27606 From owner-ipsec@lists.tislabs.com Mon Jun 30 07:27:00 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UEQxFK065825; Mon, 30 Jun 2003 07:27:00 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id JAA22742 Mon, 30 Jun 2003 09:44:35 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16128.10629.397595.457283@ryijy.hel.fi.ssh.com> Date: Mon, 30 Jun 2003 15:13:57 +0300 From: Tero Kivinen To: "Jesse Alpert" Cc: Subject: RE: IKEv2: active user identity protection In-Reply-To: <000301c33e41$b6d40350$7b2e1dc2@jesse> References: <16125.18207.934384.924599@ryijy.hel.fi.ssh.com> <000301c33e41$b6d40350$7b2e1dc2@jesse> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 8 min X-Total-Time: 7 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Jesse Alpert writes: > 2. The polling attack mentioned below is of little concern in an EAP (remote > access) scenario - the server is usually well known and the client should > not > respond to EAP phase 1 exchanges. Not all of the server addresses are globally well known. Some people for example do not put security gateways address to dns, and configure those so that they do not reply to anything than valid requests etc, so it makes harder for attackers to find those (i.e security by obscurity). This does not offer real security, but some people do want to have that kind of features. They do not like the idea that they need to give out proof that this is roadwarrior-sgw.company.com to all connections. > 3. Most importantly - exchanges which were used in IKEv1 DID support this > requirement. For example XAUTH requires the server to prove his > identity first and the client's identity is protected against active > attacks. > So protection which is around for current clients using IKEv1 will not be > there > after migrating to IKEv2. XAUTH is not part of IKEv1. So this feature was not in the IKEv1. Also the original XAUTH versions I looked at did the normal IKEv1 exchange and only then started the XAUTH. This meant that the client still needed to proof its identity before starting XAUTH. If people were using group pre shared keys, then anybody with the key (i.e anybody with the group) could by active attack get the identities (and if basic password authentication was used also the password). Anyways you can still use the ID_KEY_ID (changing every time) as a identity in those EAP cases, and have very small program in the sgw end that will convert that ID_KEY_ID to the real EAP identity. This will offer completele protection to the initiators identity, without any change to the IKEv2 protocol, and with very minor changes to those implementations that actually require this. -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Jun 30 08:00:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UF06FK066925; Mon, 30 Jun 2003 08:00:06 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA29091 Mon, 30 Jun 2003 10:22:26 -0400 (EDT) Message-Id: <200306301238.h5UCcCof086018@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Stephen Kent cc: ipsec@lists.tislabs.com Subject: Re: QoS selectors (was LAST CALL: IKE) In-reply-to: Your message of Wed, 25 Jun 2003 19:42:07 EDT. Date: Mon, 30 Jun 2003 14:38:12 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: I'm also open to suggestions from IPv6 experts about what to do there, for flows. => IPv6 traffic class are DiffServ bits and should be handled exactly as in IPv4. The IPv6 Flow Label is very different: it is clearly designed as an alternative to traditional 5-tuple filters, so IMHO IPsec/IKE should include it as a possible selector. BTW RFC 2460 (IPv6 specs) doesn't really define Flow Labels, the document to read is draft-ietf-ipv6-flow-label-07.txt, here is the beginning of its introduction: A flow is a sequence of packets sent from a particular source to a particular unicast, anycast or multicast destination that the source desires to label as a flow. A flow could consist of all packets in a specific transport connection or a media stream. However, a flow is not necessarily 1:1 mapped to a transport connection. Traditionally, flow classifiers have been based on the 5-tuple of the source and destination addresses, ports and the transport protocol type. However, some of these fields may be unavailable due to either fragmentation or encryption, or locating them past a chain of IPv6 option headers may be inefficient. Additionally, if classifiers depend only on IP layer headers, later introduction of alternative transport layer protocols will be easier. The usage of the 3-tuple of the Flow Label and the Source and Destination Address fields enables efficient IPv6 flow classification, where only IPv6 main header fields in fixed positions are used. Regards Francis.Dupont@enst-bretagne.fr PS: (re)read Mike's messages too. From owner-ipsec@lists.tislabs.com Mon Jun 30 08:12:29 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UFCTFK067531; Mon, 30 Jun 2003 08:12:29 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA29753 Mon, 30 Jun 2003 10:30:16 -0400 (EDT) Message-Id: <200306301206.h5UC6Qof085621@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Pekka Nikander cc: ipsec@lists.tislabs.com Subject: Re: Minor comments to draft-ietf-ipsec-esp-v3-05.txt In-reply-to: Your message of Mon, 16 Jun 2003 10:31:13 +0300. <3EED7241.1080904@nomadiclab.com> Date: Mon, 30 Jun 2003 14:06:26 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: Comments: - It is probably far too late to change this, but all the other IPv6 extension headers define the length in 8-octet units, not 4-byte units. If possible, it *would* be desirable to update this for IPv6. However, I fully understand that such a change may not be possible at this late in standardization. (This comment may be ignored, as it most probably has been extensively discussed in the past by the WG.) => thsi was proposed (by me) and refused at the previous AH revision some years ago. So IMHO it is far too late. Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Mon Jun 30 08:23:47 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UFNkFK067939; Mon, 30 Jun 2003 08:23:47 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00119 Mon, 30 Jun 2003 10:44:50 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: Date: Mon, 30 Jun 2003 10:51:25 -0400 To: ipsec@lists.tislabs.com From: Stephen Kent Subject: test, please ignore Content-Type: text/plain; charset="us-ascii" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk From owner-ipsec@lists.tislabs.com Mon Jun 30 08:26:01 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UFQ1FK068044; Mon, 30 Jun 2003 08:26:01 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00337 Mon, 30 Jun 2003 10:50:07 -0400 (EDT) Message-ID: <3F00526A.3060705@creeksidenet.com> Date: Mon, 30 Jun 2003 11:08:26 -0400 From: "jpickering@creeksidenet.com" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; m18) Gecko/20001108 Netscape6/6.0 X-Accept-Language: en MIME-Version: 1.0 To: Mark Duffy CC: Stephen Kent , ipsec@lists.tislabs.com Subject: Re: QoS selectors (was LAST CALL: IKE) References: <5.2.0.9.0.20030626101831.00a96bb0@email> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Re: multiple "redundant" SAs: In order to support simultaneous rekey tie-breaking as currently defined, one needs to be able to be able to determine if the attempt to create a child is a rekey and if so, which SA is being rekeyed. The only way to do this per current version is to examine the traffic selectors which presumes no redundant SAs. - Jeff Mark Duffy wrote: > Steve, > > I would say that your analysis is basically correct, by my understanding. > > I would argue that in tunnel mode it is basically a local matter for > the sender how it wants to initialize the DiffServ bits in the outer > header. It might be "set to k" or "copy from inner" but could also be > anything else. So the cases to be considered might be a somewhat > different set than you have below but the important points are the same. > > I do not see a need however for the receiver to know exactly what the > sender is doing or to know which DiffServ bits to expect on a given > SA. I also think there might be significant difficulties in trying to > negotiate DiffServ whatevers (DSCPs or PHB-IDs) as selectors in the > traditional sense (described in my earlier email in this thread). So > I would opt for letting the sender make a local choice which SA to > send on, and all the receiver needs to do is support multiple > "redundant" SAs. > > I added 3 comments in the message below. > > --Mark > > At 07:42 PM 6/25/2003 -0400, Stephen Kent wrote: > >> Several folks have asked for the ability to place traffic with >> different TOS values on different SAs, which requires that the TOS >> field (IPv4) and the flow spec field (IPv6) be useable as selectors. >> If we agree to add this feature, we need the ability to negotiate >> this in IKE. What I meant to say is closer to what David referred to >> in his message, i.e., I would anticipate a sender using the 6-bit DS >> field as an additional selector value (not the ECN bits). I don't >> think this is affected by the question of whether the interpretatioon >> of these bits is uniform across ISPs. The concern is that if these >> bits really do have an affect on the order of delivery of traffic, >> then putting different classes of traffic into the same SA has the >> potential to cause a non-trivial percentage of the (lower priority) >> traffic to be rejected due to receiver window mismatches. Now this is >> not a problem if the bits are inside a tunnel and NOT propagated to >> the outer header, but then they are not helping out during transit >> across unprotected nets. I admit to not being familiar with PHIBs, so >> I'm not sure what the issues are there. I'm also open to suggestions >> from IPv6 experts about what to do there, for flows. >> >> Mark & Radia suggest that we don't need this facility to be >> negotiated. I didn;'t understand the arguments until I worked my way >> through the cases. Now I think I understand the arguments, and >> basically agree. Let me try to examine the relevant cases: >> >> 1. traffic with varying DiffServ bits mapped to one tunnel mode SA, >> but not copied to the outer header >> - because the network between the IPsec devices will not see >> per-packet markings, there would be no addition reordering influence >> and thus no motivation for separate SAs, hence no need for using >> these bist as selectors >> >> 2. traffic with varying DiffServ bits mapped to one tunnel mode SA >> and copied to the outer header >> - this is the obvious case where more significant reordering >> by the net between the IPsec devices might cause problems >> (undesirable receiver discards due to receive window mismatches) and >> what motivated the suggestion to create different SAs for each class >> of traffic. >> >> 3. traffic with varying DiffServ bits mapped to tunnel mode SAs using >> these bits as selector values, and the bits are copied to the outer >> header >> even if the nets between the IPsec devices modify the values in the >> outer header, this would not affect the inner header values and so I >> think would work as desired. however, it is correct that this could >> be done unilaterally by the sender using selectors but not telling >> the reeciver, and still have this work for an SA, unidirectionally. >> What we would loose is the ability to tell the receiver what we are >> doing, or not doing, and thus trigger the reciprocal behavior by the >> responder, if appropriate. > > > I don't think any reciprocal behavior is needed. Each sender can do > its own thing with regard to making sure the desired number of SAa are > present, and deciding which packets to send on which SAs. This may > offend some by its lack of symmetry but then the set of DiffServ > values flowing in the two directions may not even be symmetrical in > the first place. > > >> 4. traffic with varying DiffServ bits mapped to one transport mode SA >> - as in case 2, the traffic has an increased opportunity to >> be delivered out of order, causing problems at the receiver. again, >> this motivates using these bits to select different SAs at the sender. >> >> 5. traffic with varying DiffServ bits mapped to transport mode SAs >> using these bits as selector values if the nets between the IPsec >> devices modifies the bits, we would have a problem when we tried to >> match the bits against the selectors at the receiver. if the sender >> maps the traffic to different SAs, using selectors, but does not tell >> the receiver, then there would be no problems with mismatches in the >> SPD checks at the receiver. so, I guess I would agree there here too >> this could be done by the sender unilaterally and the effect would be >> OK. > > > These mismatches in SPD checks at the reciever could be prevented by > negotiating PHB-IDs (globally meaningful) instead of DiffServ > codepoints, but then that would break case 3 :-) > > >> So, what this seems to suggest is that there is a good use for >> DiffServ bits (or PHIBs, or whatever) as selectors, but that if one >> uses them, one need not tell the receiver. Is that right? > > > I think that is right (but I wouldn't call them selectors then). > > I would just say that to avoid sequence number problems with packets > reordered by the DiffServ network "the sender SHOULD use separate SAs > to send packets whose DiffServ codepoints (in the outermost IP header) > place them in different Ordered Aggregates [RFC 3260]" > > Keep it simple! > > >> Steve > > > > > From owner-ipsec@lists.tislabs.com Mon Jun 30 08:26:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UFQDFK068068; Mon, 30 Jun 2003 08:26:13 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00355 Mon, 30 Jun 2003 10:50:27 -0400 (EDT) Message-Id: <200306291631.h5TGV7of082447@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: ipsec@lists.tislabs.com Cc: mobile-ip@sunroof.eng.sun.com Subject: new draft about address management for IKv2 Date: Sun, 29 Jun 2003 18:31:07 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I've just submitted a new version of my draft, its name is draft-dupont-ikev2-addrmgmt-03.txt and as it should not be available so soon in the I-D repositories I've put a copy on ftp://ftp.ipv6.rennes.enst-bretagne.fr/pub/draft-dupont-ikev2-addrmgmt-03.txt I've tried to make it compatible with current IKEv2 draft (i.e., minimize changes) and with Tero/Jari's proposal: 1- NAT traversal is fully handled by the (fixed) IKEv2 draft 2- if IKE is launched over UDP 4500, go to 1 3- if IKE is launched over UDP 500, NAT detection (using the two NAT_DETECTION_*_IP notification) is mandatory (=> small change is needed in the IKEv2 draft) 3a- if a NAT is detected, go to 1 3b- if no NAT is detected: the context where my proposal applies: The peer addresses (the addresses IKE runs over) are IKE SA parameters, and they are specified implicitly in the IKE_SA_INIT messages where BTW they are implicitly protected by the mandatory NAT_DETECTION notifications. (=> a small clarification is needed in the IKEv2 draft) IPsec SAs are set up for these peer addresses, i.e., they become the endpoint addresses of any new SA. (=> another small clarification, I suggest to define once what is an IKE SA). Here we have two very similar ways we can follow in a postponed specification activity: what to do when one'd like to change a peer address (note: *no* required change in the IKEv2 draft): * (Tero/Jari's) a new mechanism (notification/payload) can update the endpoint addresses of all SAs, including the IKE SA. * (mine) two new notifications can explicitly protect the peer addresses for the setup of one IKE SA or one IPsec SA pair. A new payload can update the endpoint of all or a subset of SAs. Notes: the update mechanism uses or integrates some ways to protect new peer addresses. An IKE SA update implicitly updates the peer addresses for further SA establishments. My proposal includes some extensions for multi-homing, it should avoid the need of an "IKEv2 extensions for SCTP" document. Regards Francis.Dupont@enst-bretagne.fr PS: I've cross posted this message in the mobile-ip WG list because I believe we'd like to get a new version of IKE which is secure and efficient in mobile environments. From owner-ipsec@lists.tislabs.com Mon Jun 30 08:27:32 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UFRWFK068112; Mon, 30 Jun 2003 08:27:32 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id KAA00468 Mon, 30 Jun 2003 10:54:25 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200306301238.h5UCcCof086018@givry.rennes.enst-bretagne.fr> References: <200306301238.h5UCcCof086018@givry.rennes.enst-bretagne.fr> Date: Mon, 30 Jun 2003 10:55:20 -0400 To: Francis Dupont From: Stephen Kent Subject: Re: QoS selectors (was LAST CALL: IKE) Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 2:38 PM +0200 6/30/03, Francis Dupont wrote: > In your previous mail you wrote: > > I'm also open to suggestions from IPv6 experts about what to do > there, for flows. > >=> IPv6 traffic class are DiffServ bits and should be handled exactly >as in IPv4. > The IPv6 Flow Label is very different: it is clearly designed as >an alternative to traditional 5-tuple filters, so IMHO IPsec/IKE should >include it as a possible selector. > BTW RFC 2460 (IPv6 specs) doesn't really define Flow Labels, the >document to read is draft-ietf-ipv6-flow-label-07.txt, >here is the beginning of its introduction: > > A flow is a sequence of packets sent from a particular source to a > particular unicast, anycast or multicast destination that the source > desires to label as a flow. A flow could consist of all packets in a > specific transport connection or a media stream. However, a flow is > not necessarily 1:1 mapped to a transport connection. > > Traditionally, flow classifiers have been based on the 5-tuple of the > source and destination addresses, ports and the transport protocol > type. However, some of these fields may be unavailable due to either > fragmentation or encryption, or locating them past a chain of IPv6 > option headers may be inefficient. Additionally, if classifiers > depend only on IP layer headers, later introduction of alternative > transport layer protocols will be easier. > > The usage of the 3-tuple of the Flow Label and the Source and > Destination Address fields enables efficient IPv6 flow > classification, where only IPv6 main header fields in fixed positions > are used. > >Regards > >Francis.Dupont@enst-bretagne.fr Francis, Thanks for the clarification. It looks like it makes sense to use the IPv6 traffic class as the equivalent of the DiffServ bits, if the WG agrees that we ought to use these are a new selector type. What do other folks think about this suggestion to offer the Flow Label as another selector type, for the reasons cited above by Francis? Steve From owner-ipsec@lists.tislabs.com Mon Jun 30 08:50:00 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UFnxFK068795; Mon, 30 Jun 2003 08:50:00 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00979 Mon, 30 Jun 2003 11:13:50 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: Date: Mon, 30 Jun 2003 11:19:08 -0400 To: "Srinivasa Rao Addepalli" From: Stephen Kent Subject: Re: IKE negotiation for fragmentation controls in IPsec Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Return-Path: Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h5UDKEDD009711; Mon, 30 Jun 2003 09:20:18 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <047f01c33cfe$9d912240$0202a8c0@SindhuSriha> References: <090b01c33c0c$a709b050$0202a8c0@SindhuSriha> <047f01c33cfe$9d912240$0202a8c0@SindhuSriha> Date: Mon, 30 Jun 2003 09:19:33 -0400 To: "Srinivasa Rao Addepalli" From: Stephen Kent Subject: Re: IKE negotiation for fragmentation controls in IPsec Cc: Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) At 3:51 PM -0700 6/27/03, Srinivasa Rao Addepalli wrote: > > > Outbound Processing steps: >> > - Reassemble the packet (Packet coming from trusted network). >> >> NO. there is no implied reassembly by the transmitter. >> >> I won't comment on the rest of your message since this assumption was >> not right and it may influence later parts of your message. >> > >I am curious on why this is not needed. >IPSEC SPD supports selector space with not only IP addresses, but also >with TCP/UDP port values. If some sort of reassembling is not done(either wait >for all fragments OR maintain reassembly state with IP ID, SIP, DIP), there >is possibility of mapping the non-first fragments of the packets to the wrong >security policy. Only first fragment has TCP/UDP information and it chooses >the correct security policy. > >Complete IP reassembling helps in finding out obvious DoS attacks and >helps in reducing the number of encapsulated IPSEC packets. Each inbound IPsec datagram carries and SPI and that maps uniquely to an SA. If one links selector info with each SAD entry (part of the simplified processing model I'll bee explaining as we progress), then there is no ambiguity about which selectors to match against an inbound packet. If the SA calls for examination of port fields, then yes, non-initial fragments cannot be examined, but so long as we make sure the offsets are large enough to avoid overwriting these fields, then letting such fragments through does not seem like a serious problem. Also, as Tero noted in his message, at worst one might buffer, but not reassemble, non-initial fragments for an SA under such circumstances. Steve From owner-ipsec@lists.tislabs.com Mon Jun 30 08:52:04 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UFq4FK068929; Mon, 30 Jun 2003 08:52:04 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA00980 Mon, 30 Jun 2003 11:13:51 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: Date: Mon, 30 Jun 2003 11:19:55 -0400 To: Tero Kivinen From: Stephen Kent Subject: Re: IKE negotiation for fragmentation controls in IPsec Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Return-Path: Received: from [128.89.88.34] (comsec.bbn.com [128.89.88.34]) by aragorn.bbn.com (8.12.7/8.12.7) with ESMTP id h5UDKED9009711; Mon, 30 Jun 2003 09:20:16 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16122.55806.305977.986255@ryijy.hel.fi.ssh.com> References: <16122.55806.305977.986255@ryijy.hel.fi.ssh.com> Date: Mon, 30 Jun 2003 09:14:20 -0400 To: Tero Kivinen From: Stephen Kent Subject: Re: IKE negotiation for fragmentation controls in IPsec Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) At 2:33 PM +0300 6/26/03, Tero Kivinen wrote: >Stephen Kent writes: >> for this SA, because none will be sent by this transmitter. So, I >> suggest that we add a paylod to IKE to allow an initiator to indicate >> the intent to never send ciphertext fragments. The responder can take >> advantage of this info to better protect itself, or it can ignore the >> info, but it needs to be told to be able to take advantage of the >> capability. I would also like to see the responder be able to notify >> the initiator of its intent re the companion (reverse) SA, if >> appropriate. > >Would it be enough to have >---------------------------------------------------------------------- > FRAGMENTATION_BEFORE_IPSEC 24587 > > By sending this notification the sender announces that it > can process packets which are fragmented before being > encapsulated to the IPSec packets, i.e the recipient of > this notification can send such packets and assume that > the other end can process them. If this notification > payload is sent by both ends (i.e both ends support this > feature), then both ends MUST NOT send packets fragmented > after the IPsec encapsulation and SHOULD (configurable by > local policy) reject incoming packets which are fragmented > after IPsec encapsulation (i.e as the other end must not > send them it was either some other router which fragmented > it or it was an attack). >---------------------------------------------------------------------- This does not really convey the right semantics. What we want is for the sender of the payload to say "I will NOT send any post-IPsec encapsulation fragments." Any receiver MUST be able to accommodate fragments that occur prior to IPsec encapsulation, because these fragments could have been generated by a host before arriving at the IPsec device. The goal of the proposed payload is to inform the receiver so that the receiver can mark an SAD entry to reject all fragments that arrive (prior to IPsec encalsulation). > >in the section 3.10.1 Notify Message Types - STATUS TYPES? > >> A logical (but admittedly separable) companion to this feature is to >> allow the initiator to request the responder to accept fragments on >> an SA where port fields are used as selectors. The issue here is that >> a host may send fragments to an IPsec device that requires port field >> examination for the SA to which the fragments will be mapped. It >> seems reasonably safe to allow fragments (with a suitable, minimum >> offset) to pass through such as SA, with only the initial fragment >> having the port fields examined. This is a separate negotiation >> because the fragments arise from hosts behind the IPsec device, but >> it is related, because if one fragments at the sending IPsec device, >> it would be nice to be able to use this feature to allow the receiver >> to pass on fragments, not reassemble them (in the case of a SG). > >The normal processing of those packets on the firewalls is to put >those non-first fragments to (small) queue and when the first fragment >then arrives, then do the policy check and forward the first fragment >and all additional fragments forward (and also mark the fragment id so >that all future fragments to same packet will get through for some >time). Also care should be taken that the any fragments do not >overwrite anything from the first fragment that was used for the >policy checks (i.e the port numbers are not overwritten by later >non-first fragment). > >I am not sure that we should allow sending of the non-first fragments >to IPsec SAs using the port selectors unless we have validated that >the port numbers match the policy. There is no need to do the actual >reassembly, simply queuing the non-first framents coming before the >first fragment and adding entry that will allow rest of the fragments >to the packet to get through for some time is enough. We agree that there is no need for a receiver to reassemble. However, so long as we prevent fragments with too-short offsets from traversing an SA, I'm not sure much damage (other than a form of DoS on an SA where the Source and Dest IP addresses are already acceptable) will be done if we allow fragments to pass before we see the initial fragment at the receiver. That avoids the need for any buffering at the receiver, which it self might create DoS concerns. Steve From owner-ipsec@lists.tislabs.com Mon Jun 30 08:54:28 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UFsRFK068963; Mon, 30 Jun 2003 08:54:27 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA01023 Mon, 30 Jun 2003 11:15:51 -0400 (EDT) Message-Id: <200306301520.h5UFKmof086843@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: Henry Spencer cc: IP Security List Subject: Re: IKE negotiation for fragmentation controls in IPsec In-reply-to: Your message of Thu, 26 Jun 2003 12:35:18 EDT. Date: Mon, 30 Jun 2003 17:20:48 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: There is a problem here, in that fragmentation is not entirely under the control of the transmitter. Intervening gateways may fragment the encrypted packets. This situation can change dynamically, as routing changes, and the transmitter can't count on getting feedback about it, because many firewalls apparently block ICMP Fragmentation Required messages. => Two comments: - IPv6 fragmentation is end to end, i.e., no intervening router may fragment the packets. So this issue exists only for IPv4. - current IPv4 path MTU discovery doesn't work. I use an ESP tunnel between two KAME boxes (one at home, one in labs) over PPPoE and it was a real nightmare to fix (KAME IPsec doesn't handle MTU, a lot of sites are over paranoid firewalls, a router of my ISP drops large packets when it should fragment them, etc). So this is a can of worms and IMHO we should test proposed solutions in the real world before engrave something in the stone. Regards Francis.Dupont@enst-bretagne.fr From owner-ipsec@lists.tislabs.com Mon Jun 30 09:06:24 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UG6NFK069220; Mon, 30 Jun 2003 09:06:23 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id LAA01363 Mon, 30 Jun 2003 11:29:07 -0400 (EDT) Message-Id: <200306301534.h5UFY1of086892@givry.rennes.enst-bretagne.fr> From: Francis Dupont To: "Srinivasa Rao Addepalli" cc: "Stephen Kent" , ipsec@lists.tislabs.com Subject: Re: IKE negotiation for fragmentation controls in IPsec In-reply-to: Your message of Fri, 27 Jun 2003 15:51:15 PDT. <047f01c33cfe$9d912240$0202a8c0@SindhuSriha> Date: Mon, 30 Jun 2003 17:34:01 +0200 X-Virus-Scanned: by amavisd-milter (http://amavis.org/) at enst-bretagne.fr Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In your previous mail you wrote: > NO. there is no implied reassembly by the transmitter. I am curious on why this is not needed. => intermediate boxes should not even try to reassemble packets. There are many reasons, for instance some fragments can follow a different path, or this increases the latency, etc. IPSEC SPD supports selector space with not only IP addresses, but also with TCP/UDP port values. => a security gateway can get fragments so it doesn't support selectors which can be in the second fragment. IMHO SPD on a SG should be constrained to only IP addresses (IPv6 is a bit different, first the flow label is always available, second some extension headers are on purpose in all fragments). If some sort of reassembling is not done(either wait for all fragments OR maintain reassembly state with IP ID, SIP, DIP), there is possibility of mapping the non-first fragments of the packets to the wrong security policy. Only first fragment has TCP/UDP information => this is not true, the TCP/UDP information can be in the second fragment. and it chooses the correct security policy. Complete IP reassembling helps in finding out obvious DoS attacks and => this is the job of a firewall, not the job of a SG. helps in reducing the number of encapsulated IPSEC packets. Regards Francis.Dupont@enst-bretagne.fr PS: it seems I have some trouble with the list server: I apologize if you mbox has already blown with messages developing these arguments. From owner-ipsec@lists.tislabs.com Mon Jun 30 10:03:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UH36FK071146; Mon, 30 Jun 2003 10:03:06 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA02804 Mon, 30 Jun 2003 12:24:42 -0400 (EDT) Message-ID: <3F006593.1258C4AB@torrentnet.com> Date: Mon, 30 Jun 2003 12:30:11 -0400 From: Jim Comen X-Mailer: Mozilla 4.8 [en] (X11; U; Linux 2.4.18-27.7.x i686) X-Accept-Language: en MIME-Version: 1.0 To: ipseclist Subject: Re: NPF Info and/or site password References: <3F003CE1.BF6703A@torrentnet.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-ipsec@lists.tislabs.com Precedence: bulk I apologize for the previous note - Please disregard the previous note - it was meant for internal distribution - #*%$# email aliases... Jim Comen wrote: > > I'm trying to look on the NPF site for info about IKE and/or IPSec but can't find any. Whereas it's not yet > standardized, would there be anything on the site about IKE or IPSec? > > Also, does anyone know what our NPF site uid/pwd is? > Thanks > Jim > -- > Jim Comen jcomen@torrentnet.com > Ericsson IP Infrastructure Voice (919) 472 - 9932 > 920 Main Campus Drive, Suite 544 Fax (919) 472 - 9999 > Raleigh, NC 27606 -- Jim Comen jcomen@torrentnet.com Ericsson IP Infrastructure Voice (919) 472 - 9932 920 Main Campus Drive, Suite 544 Fax (919) 472 - 9999 Raleigh, NC 27606 From owner-ipsec@lists.tislabs.com Mon Jun 30 10:03:33 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UH3WFK071169; Mon, 30 Jun 2003 10:03:32 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA02694 Mon, 30 Jun 2003 12:21:35 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16128.25732.675945.766298@ryijy.hel.fi.ssh.com> Date: Mon, 30 Jun 2003 19:25:40 +0300 From: Tero Kivinen To: Stephen Kent Cc: ipsec@lists.tislabs.com Subject: Re: IKE negotiation for fragmentation controls in IPsec In-Reply-To: References: <16122.55806.305977.986255@ryijy.hel.fi.ssh.com> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 18 min X-Total-Time: 18 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Stephen Kent writes: > This does not really convey the right semantics. What we want is for > the sender of the payload to say "I will NOT send any post-IPsec > encapsulation fragments." Any receiver MUST be able to accommodate > fragments that occur prior to IPsec encapsulation, because these > fragments could have been generated by a host before arriving at the > IPsec device. The goal of the proposed payload is to inform the > receiver so that the receiver can mark an SAD entry to reject all > fragments that arrive (prior to IPsec encalsulation). Ok, so: ---------------------------------------------------------------------- NO_FRAGMENTED_IPSEC_PACKETS 24587 By sending this notification the sender announces that it will always fragment packets before encapsulating them to the IPsec packets, i.e the recipient of this notification MAY drop all fragmented IPSec packets, as they are not generated by the other end. ---------------------------------------------------------------------- would be better? > We agree that there is no need for a receiver to reassemble. However, > so long as we prevent fragments with too-short offsets from > traversing an SA, I'm not sure much damage (other than a form of DoS > on an SA where the Source and Dest IP addresses are already > acceptable) will be done if we allow fragments to pass before we see > the initial fragment at the receiver. That avoids the need for any > buffering at the receiver, which it self might create DoS concerns. The most common fragmented packets that can cause damage is when the attacker attacks the reassembly code of the final recipient, i.e send packets whose offset + size > 65536, or suitable packets filling up the reassembly queue in the receipient and causing denial of service attack. There are some attacks where you generate for example fragments each having 8 bytes of data, and leave gap between each of those. This means that the recipient might have 4000 of those in its reassembly queue. If this queue is linear sorted list, and every time you send the fragment the code searches the suitable place where to insert the fragment it means 4000/2 list operations per fragment, which will take considerable cpu-time (yes, I have seen this attack to work, and the machine was completely trashed by just very few such packets). This does not need the first fragment at all. Also another attacks are done by sending lots of non-first fragments to the recipient and again filling up the queues. I think the reason than most of the firewalls (and I assume also security gateways) want to check the fragments is that they want to do some sanity check them before letting them through, i.e some of them simply drop all fragments that are too small (unless they are the last ones) and also they might even check that there is no overlapping areas in the fragments (might be attack, and should not happen in normal case) etc. Making sure that the reassembly code in the sgw can handle all attack cases is easier than trying to fix all the hosts behind them. I agree, that we propably could also allow letting the non-first fragments through, but I think we need also some text of possible attacks and checks that should be done in those cases. And of course a good explanation about the risks of letting fragments with too small offsets through. I.e I want to see the final text before I can say more about this issue... -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Jun 30 10:35:07 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UHZ6FK072258; Mon, 30 Jun 2003 10:35:06 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id MAA03539 Mon, 30 Jun 2003 12:58:32 -0400 (EDT) Date: Mon, 30 Jun 2003 13:03:23 -0400 From: "Theodore Ts'o" To: Stephen Kent Cc: Pekka Nikander , Tero Kivinen , ipsec@lists.tislabs.com, James Kempf , SEND WG Subject: Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences Message-ID: <20030630170323.GC4051@think> References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EEC2C43.9060302@nomadiclab.com> <16112.1673.849180.847121@ryijy.hel.fi.ssh.com> <3EF16ED1.3040908@nomadiclab.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.4i Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, Part of the problem here is that we are trying to put AH and ESP to bed before we take up the RFC 2401 revisions. The SEND working group, on the suggestion of Steve Bellovin, has essentially proposed a new key management scheme, uses an IP extension header to "establish" keying material which can then be used by the AH and ESP. I agree that it hasn't been fully specified in sufficient detail yet, but the basic premise does seem sound. To the extent that much of the processing rules are in 2401, as you have pointed out, does it make sense to perhaps delete the few sentences that outright prohibit what the SEND working group is trying to do, and defer that discussion for 2401-bis discussion, just so we can send the AH and ESP documents to the IESG and get them off our hands? I agree that a protocol is not just syntax, but semantics too. However, much of the semantics is alreayd in architecture document, and we do have precedent for attempting to allow AH and ESP to be used by mutliple keying mechanisms beyond just IKE. (i.e., SKIP, Multicast Keying, etc.) - Ted From owner-ipsec@lists.tislabs.com Mon Jun 30 11:05:02 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UI51FK072959; Mon, 30 Jun 2003 11:05:02 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id NAA04118 Mon, 30 Jun 2003 13:23:41 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <20030630170323.GC4051@think> References: <4.3.2.7.2.20030526181608.04a3df00@mira-sjc5-4.cisco.com> <3EEC2C43.9060302@nomadiclab.com> <16112.1673.849180.847121@ryijy.hel.fi.ssh.com> <3EF16ED1.3040908@nomadiclab.com> <20030630170323.GC4051@think> Date: Mon, 30 Jun 2003 13:21:07 -0400 To: "Theodore Ts'o" From: Stephen Kent Subject: Re: Comments on draft-ietf-ipsec-rfc2402bis-03.txt based on SEND WG experiences Cc: Pekka Nikander , Tero Kivinen , ipsec@lists.tislabs.com, James Kempf , SEND WG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 1:03 PM -0400 6/30/03, Theodore Ts'o wrote: >Steve, > >Part of the problem here is that we are trying to put AH and ESP to >bed before we take up the RFC 2401 revisions. The SEND working group, >on the suggestion of Steve Bellovin, has essentially proposed a new >key management scheme, uses an IP extension header to "establish" >keying material which can then be used by the AH and ESP. > >I agree that it hasn't been fully specified in sufficient detail yet, >but the basic premise does seem sound. To the extent that much of the >processing rules are in 2401, as you have pointed out, does it make >sense to perhaps delete the few sentences that outright prohibit what >the SEND working group is trying to do, and defer that discussion for >2401-bis discussion, just so we can send the AH and ESP documents to >the IESG and get them off our hands? I agree that a protocol is not >just syntax, but semantics too. However, much of the semantics is >alreayd in architecture document, and we do have precedent for >attempting to allow AH and ESP to be used by mutliple keying >mechanisms beyond just IKE. (i.e., SKIP, Multicast Keying, etc.) > > - Ted Ted, We killed SKIP a long time ago, and I think that was the right decision :-) The reserved SPI feature was a holdover from that time, and maybe it too should go, to avoid giving folks the wrong impression. I am not yet comfortable with making these changes to accommodate SEND, given the current status of the IPsec documents, the maturity of the SEND work, etc. I suggest you ask Russ for his direction before we proceed. Steve From owner-ipsec@lists.tislabs.com Mon Jun 30 11:46:46 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UIkjFK074259; Mon, 30 Jun 2003 11:46:45 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA04908 Mon, 30 Jun 2003 14:07:26 -0400 (EDT) Message-ID: <3F007E19.40905@airespace.com> Date: Mon, 30 Jun 2003 11:14:49 -0700 From: "Scott G. Kelly" Organization: Airespace User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen CC: Jesse Alpert , ipsec@lists.tislabs.com Subject: Re: IKEv2: active user identity protection References: <16125.18207.934384.924599@ryijy.hel.fi.ssh.com> <000301c33e41$b6d40350$7b2e1dc2@jesse> <16128.10629.397595.457283@ryijy.hel.fi.ssh.com> X-Enigmail-Version: 0.75.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jun 2003 18:12:25.0116 (UTC) FILETIME=[28753DC0:01C33F33] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Tero, Tero Kivinen wrote: | Jesse Alpert writes: | |>2. The polling attack mentioned below is of little concern in an EAP (remote |>access) scenario - the server is usually well known and the client should |>not |>respond to EAP phase 1 exchanges. | | | Not all of the server addresses are globally well known. Some people | for example do not put security gateways address to dns, and configure | those so that they do not reply to anything than valid requests etc, | so it makes harder for attackers to find those (i.e security by | obscurity). This does not offer real security, but some people do want | to have that kind of features. They do not like the idea that they | need to give out proof that this is roadwarrior-sgw.company.com to all | connections. For mainstream remote access scenarios, and certainly for wireless scenarios, the sgw is well known to its users, at least by IP address. I can understand the desire to mitigate damage due to polling attacks under some circumstances, but that risk does not outweigh the threat posed by easy discovery of user identities in wlan scenarios. We really should provide a method for concealing user identities in these scenarios. |>3. Most importantly - exchanges which were used in IKEv1 DID support this |>requirement. For example XAUTH requires the server to prove his |>identity first and the client's identity is protected against active |>attacks. |>So protection which is around for current clients using IKEv1 will not be |>there |>after migrating to IKEv2. | | | XAUTH is not part of IKEv1. So this feature was not in the IKEv1. Also | the original XAUTH versions I looked at did the normal IKEv1 exchange | and only then started the XAUTH. This meant that the client still | needed to proof its identity before starting XAUTH. If people were | using group pre shared keys, then anybody with the key (i.e anybody | with the group) could by active attack get the identities (and | if basic password authentication was used also the password). XAUTH is not officially part of IKE, but it is the de facto IKEv1 remote access solution. Hybrid-mode implementations are the most secure embodiment of XAUTH, and these do require the client to prove its identity prior to establishment of a secure channel. The fact that most XAUTH deployments are susceptible to a MiM attack resulting from their use of group preshared keys does not render Jesse's argument less valid. We need identity protection for the initiator in remote access scenarios. | Anyways you can still use the ID_KEY_ID (changing every time) as a | identity in those EAP cases, and have very small program in the sgw | end that will convert that ID_KEY_ID to the real EAP identity. This | will offer completele protection to the initiators identity, without | any change to the IKEv2 protocol, and with very minor changes to those | implementations that actually require this. This might meet some user's needs, but it does not scale well. It requires synchronization between the sgw and the remote access clients, and new lists of IDs must be provided to both on an ongoing basis. It is not a good general solution. Scott -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/AH4ZMtIdhO0pgN4RApu/AKD2lDyWV176ZAj9b4nbsgdqr2di0ACgpP0c dq7th7rTUlmYg6Vj4c0Bbe8= =HtzK -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Jun 30 12:33:36 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UJXZFK075854; Mon, 30 Jun 2003 12:33:36 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id OAA05806 Mon, 30 Jun 2003 14:51:57 -0400 (EDT) Message-ID: <3F00888A.6040004@airespace.com> Date: Mon, 30 Jun 2003 11:59:22 -0700 From: "Scott G. Kelly" Organization: Airespace User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Scott G. Kelly" CC: Tero Kivinen , Jesse Alpert , ipsec@lists.tislabs.com Subject: Re: IKEv2: active user identity protection References: <16125.18207.934384.924599@ryijy.hel.fi.ssh.com> <000301c33e41$b6d40350$7b2e1dc2@jesse> <16128.10629.397595.457283@ryijy.hel.fi.ssh.com> <3F007E19.40905@airespace.com> X-Enigmail-Version: 0.75.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jun 2003 18:56:58.0124 (UTC) FILETIME=[61B1E4C0:01C33F39] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Correction below... Scott G. Kelly wrote: | XAUTH is not officially part of IKE, but it is the de facto IKEv1 remote | access solution. Hybrid-mode implementations are the most secure | embodiment of XAUTH, and these do require the client to prove its ...Should have said "do require the SERVER to prove its" | identity prior to establishment of a secure channel. The fact that most | XAUTH deployments are susceptible to a MiM attack resulting from their | use of group preshared keys does not render Jesse's argument less valid. | We need identity protection for the initiator in remote access scenarios. | | | Anyways you can still use the ID_KEY_ID (changing every time) as a | | identity in those EAP cases, and have very small program in the sgw | | end that will convert that ID_KEY_ID to the real EAP identity. This | | will offer completele protection to the initiators identity, without | | any change to the IKEv2 protocol, and with very minor changes to those | | implementations that actually require this. | | This might meet some user's needs, but it does not scale well. It | requires synchronization between the sgw and the remote access clients, | and new lists of IDs must be provided to both on an ongoing basis. It is | not a good general solution. | | Scott -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/AIiKMtIdhO0pgN4RAvvXAKDgbLXV6YJRMOYemFCkLTJiZZIqNgCg0S2s F/YluoVNBHAw7O8/P2aQ1+U= =aQMI -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Jun 30 12:42:27 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UJgQFK076093; Mon, 30 Jun 2003 12:42:26 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06161 Mon, 30 Jun 2003 15:07:38 -0400 (EDT) Date: Mon, 30 Jun 2003 22:13:08 +0300 Message-Id: <200306301913.h5UJD88P003320@burp.tkv.asdf.org> From: Markku Savela To: ipsec@lists.tislabs.com In-reply-to: <16128.25732.675945.766298@ryijy.hel.fi.ssh.com> (message from Tero Kivinen on Mon, 30 Jun 2003 19:25:40 +0300) Subject: Re: IKE negotiation for fragmentation controls in IPsec References: <16122.55806.305977.986255@ryijy.hel.fi.ssh.com> <16128.25732.675945.766298@ryijy.hel.fi.ssh.com> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Tero Kivinen > ---------------------------------------------------------------------- > NO_FRAGMENTED_IPSEC_PACKETS 24587 > > By sending this notification the sender announces that it > will always fragment packets before encapsulating them to > the IPsec packets, i.e the recipient of this notification > MAY drop all fragmented IPSec packets, as they are not > generated by the other end. > ---------------------------------------------------------------------- Sorry about butting in. I have been on vacation and a bit of lost here. Are we now planning on MAJOR change in IPSEC, where you APPLY IPSEC to fragments? Otherwise above change makes no sense at all. Previously SG had to assemble the packets before doing IPSEC. So, I take above is to make SG's job easier? (Or IPSEC below IP-stack implementations). But, then it should limit selectors only to addresses, to keep things simple (e.g. if you allow IPSEC on fragments, don't even think of making it mandatory to support port selectors -- that's same as requiring reassembly anyway). For bump in the stack implementations, there should be no need for IPSEC:ing fragments, ever. Previously, fragmentation DOS attacks had no relevance to the IPSEC. Now, if fragments can be IPSEC:ed, there might be some consern. From owner-ipsec@lists.tislabs.com Mon Jun 30 13:06:58 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UK6vFK077187; Mon, 30 Jun 2003 13:06:58 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06579 Mon, 30 Jun 2003 15:28:45 -0400 (EDT) X-Authentication-Warning: ryijy.hel.fi.ssh.com: kivinen set sender to kivinen@ssh.fi using -f MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <16128.36965.119302.171670@ryijy.hel.fi.ssh.com> Date: Mon, 30 Jun 2003 22:32:53 +0300 From: Tero Kivinen To: "Scott G. Kelly" Cc: Jesse Alpert , ipsec@lists.tislabs.com Subject: Re: IKEv2: active user identity protection In-Reply-To: <3F007E19.40905@airespace.com> References: <16125.18207.934384.924599@ryijy.hel.fi.ssh.com> <000301c33e41$b6d40350$7b2e1dc2@jesse> <16128.10629.397595.457283@ryijy.hel.fi.ssh.com> <3F007E19.40905@airespace.com> X-Mailer: VM 7.07 under Emacs 20.7.1 Organization: SSH Communications Security Oy X-Edit-Time: 16 min X-Total-Time: 19 min Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Scott G. Kelly writes: > | Anyways you can still use the ID_KEY_ID (changing every time) as a > | identity in those EAP cases, and have very small program in the sgw > | end that will convert that ID_KEY_ID to the real EAP identity. This > | will offer completele protection to the initiators identity, without > | any change to the IKEv2 protocol, and with very minor changes to those > | implementations that actually require this. > This might meet some user's needs, but it does not scale well. It > requires synchronization between the sgw and the remote access clients, > and new lists of IDs must be provided to both on an ongoing basis. It is > not a good general solution. I would more likely think about protocol like this: Initiator Responder ----------- ----------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] HDR, SK {IDi(ID_KEY_ID=, [CERTREQ,] [IDr,] SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, EAP } HDR, SK {EAP, [AUTH], N(UPDATE-ID-KEY-ID=) } --> <-- HDR, SK {EAP, [AUTH], SAr2, TSi, TSr, N(UPDATE-CONFIRMED)} And then next time the client will use as ID_KEY_ID. If the connection breaks down before the client gets UPDATE-CONFIRMED notification it will use the old ID_KEY_ID next time too, and responder would need to keep two ID's, i.e the old and the new (the client will use the old, if it didn't get the last UPDATE-CONFIRMED message, or new if it did actually get the message). When ever server sees the as ID_KEY_ID it can move the to be old, and it will get new random very soon... I think this can be solved as separate extension to IKEv2, there is no need to put it in the IKEv2 base document. We MUST say "no more features" to IKEv2 some day, and that day has already gone. Also as this issue was already discussed earlier on the mailing list and the decision about was made that this will not make the IKEv2 document, I do not think it is usefull to continue this discussion on this issue now. The original discussion and decision about this can be found from: Hugo's original email: http://www.vpnc.org/ietf-ipsec/mail-archive/msg03639.html Area Directors comments: http://www.vpnc.org/ietf-ipsec/mail-archive/msg03653.html Working group chairs comments: http://www.vpnc.org/ietf-ipsec/mail-archive/msg03809.html -- kivinen@ssh.fi SSH Communications Security http://www.ssh.fi/ SSH IPSEC Toolkit http://www.ssh.fi/ipsec/ From owner-ipsec@lists.tislabs.com Mon Jun 30 13:13:48 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UKDmFK077423; Mon, 30 Jun 2003 13:13:48 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06649 Mon, 30 Jun 2003 15:33:40 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200306301913.h5UJD88P003320@burp.tkv.asdf.org> References: <16122.55806.305977.986255@ryijy.hel.fi.ssh.com> <16128.25732.675945.766298@ryijy.hel.fi.ssh.com> <200306301913.h5UJD88P003320@burp.tkv.asdf.org> Date: Mon, 30 Jun 2003 15:32:10 -0400 To: Markku Savela From: Stephen Kent Subject: Re: IKE negotiation for fragmentation controls in IPsec Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 10:13 PM +0300 6/30/03, Markku Savela wrote: > > From: Tero Kivinen > >> ---------------------------------------------------------------------- >> NO_FRAGMENTED_IPSEC_PACKETS 24587 >> >> By sending this notification the sender announces that it >> will always fragment packets before encapsulating them to >> the IPsec packets, i.e the recipient of this notification >> MAY drop all fragmented IPSec packets, as they are not >> generated by the other end. >> ---------------------------------------------------------------------- > >Sorry about butting in. I have been on vacation and a bit of lost >here. Are we now planning on MAJOR change in IPSEC, where you APPLY >IPSEC to fragments? > >Otherwise above change makes no sense at all. IPsec has always been applied to fragments that arrive at an SG, or in the case of IPv6, that are emitted by a host internally. >Previously SG had to assemble the packets before doing IPSEC. could you remind me of where we said that in 2401? >So, I >take above is to make SG's job easier? (Or IPSEC below IP-stack >implementations). But, then it should limit selectors only to >addresses, to keep things simple (e.g. if you allow IPSEC on >fragments, don't even think of making it mandatory to support port >selectors -- that's same as requiring reassembly anyway). > >For bump in the stack implementations, there should be no need for >IPSEC:ing fragments, ever. > >Previously, fragmentation DOS attacks had no relevance to the >IPSEC. Now, if fragments can be IPSEC:ed, there might be some consern. Steve From owner-ipsec@lists.tislabs.com Mon Jun 30 13:36:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UKaEFK078360; Mon, 30 Jun 2003 13:36:14 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id PAA06962 Mon, 30 Jun 2003 15:52:53 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <16128.25732.675945.766298@ryijy.hel.fi.ssh.com> References: <16122.55806.305977.986255@ryijy.hel.fi.ssh.com> <16128.25732.675945.766298@ryijy.hel.fi.ssh.com> Date: Mon, 30 Jun 2003 15:52:36 -0400 To: Tero Kivinen From: Stephen Kent Subject: Re: IKE negotiation for fragmentation controls in IPsec Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 7:25 PM +0300 6/30/03, Tero Kivinen wrote: >Stephen Kent writes: >> This does not really convey the right semantics. What we want is for >> the sender of the payload to say "I will NOT send any post-IPsec >> encapsulation fragments." Any receiver MUST be able to accommodate >> fragments that occur prior to IPsec encapsulation, because these >> fragments could have been generated by a host before arriving at the >> IPsec device. The goal of the proposed payload is to inform the >> receiver so that the receiver can mark an SAD entry to reject all >> fragments that arrive (prior to IPsec encalsulation). > >Ok, so: > >---------------------------------------------------------------------- > NO_FRAGMENTED_IPSEC_PACKETS 24587 > > By sending this notification the sender announces that it > will always fragment packets before encapsulating them to > the IPsec packets, i.e the recipient of this notification > MAY drop all fragmented IPSec packets, as they are not > generated by the other end. >---------------------------------------------------------------------- > >would be better? "... encapsulating them with IPsec ..." and fix the spelling of IPsec :-) > > >> We agree that there is no need for a receiver to reassemble. However, >> so long as we prevent fragments with too-short offsets from >> traversing an SA, I'm not sure much damage (other than a form of DoS >> on an SA where the Source and Dest IP addresses are already >> acceptable) will be done if we allow fragments to pass before we see >> the initial fragment at the receiver. That avoids the need for any >> buffering at the receiver, which it self might create DoS concerns. > >The most common fragmented packets that can cause damage is when the >attacker attacks the reassembly code of the final recipient, i.e send >packets whose offset + size > 65536, or suitable packets filling up >the reassembly queue in the receipient and causing denial of service >attack. like I said, DoS concerns. >There are some attacks where you generate for example fragments each >having 8 bytes of data, and leave gap between each of those. This >means that the recipient might have 4000 of those in its reassembly >queue. If this queue is linear sorted list, and every time you send >the fragment the code searches the suitable place where to insert the >fragment it means 4000/2 list operations per fragment, which will take >considerable cpu-time (yes, I have seen this attack to work, and the >machine was completely trashed by just very few such packets). > >This does not need the first fragment at all. agreed >Also another attacks are done by sending lots of non-first fragments >to the recipient and again filling up the queues. remember, we have this problem already if the SA does not use port field selectors. the relaxation I suggested merely allows the sender to say that they want to send fragments despite the presence of the port field selectors. >I think the reason than most of the firewalls (and I assume also >security gateways) want to check the fragments is that they want to do >some sanity check them before letting them through, i.e some of them >simply drop all fragments that are too small (unless they are the last >ones) and also they might even check that there is no overlapping >areas in the fragments (might be attack, and should not happen in >normal case) etc. Making sure that the reassembly code in the sgw can >handle all attack cases is easier than trying to fix all the hosts >behind them. I agree in principle. But, unlike the generic firewall case, here we know the source of the traffic and we do have some recourse for the DoS attacks, i.e., shutting down the SA and having a chat with the admin at the other end, if we are willing to accept that sort of remedial action. >I agree, that we propably could also allow letting the non-first >fragments through, but I think we need also some text of possible >attacks and checks that should be done in those cases. And of course a >good explanation about the risks of letting fragments with too small >offsets through. > >I.e I want to see the final text before I can say more about this >issue... Fair. Steve From owner-ipsec@lists.tislabs.com Mon Jun 30 14:02:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UL2gFK079293; Mon, 30 Jun 2003 14:02:43 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id QAA07502 Mon, 30 Jun 2003 16:23:43 -0400 (EDT) Message-ID: <3F009E0C.5010109@airespace.com> Date: Mon, 30 Jun 2003 13:31:08 -0700 From: "Scott G. Kelly" Organization: Airespace User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Tero Kivinen CC: Jesse Alpert , ipsec@lists.tislabs.com Subject: Re: IKEv2: active user identity protection References: <16125.18207.934384.924599@ryijy.hel.fi.ssh.com> <000301c33e41$b6d40350$7b2e1dc2@jesse> <16128.10629.397595.457283@ryijy.hel.fi.ssh.com> <3F007E19.40905@airespace.com> <16128.36965.119302.171670@ryijy.hel.fi.ssh.com> X-Enigmail-Version: 0.75.1.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jun 2003 20:28:44.0148 (UTC) FILETIME=[338A7B40:01C33F46] Sender: owner-ipsec@lists.tislabs.com Precedence: bulk -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Tero Kivinen wrote: | I think this can be solved as separate extension to IKEv2, there is no | need to put it in the IKEv2 base document. We MUST say "no more | features" to IKEv2 some day, and that day has already gone. | | | Also as this issue was already discussed earlier on the mailing list | and the decision about was made that this will not make the IKEv2 | document, I do not think it is usefull to continue this discussion on | this issue now. I appreciate the desire to contain discussions, but let's be very clear about this: this issue was raised as part of last call for IKEv2, and a significant number of folks have offered support for the notion that this is a significant shortcoming in the current spec. It is inappropriate to simply quash the discussion because you don't like the idea. If last call has degenerated to a symbolic gesture which is not intended to really flush out final issues, then I guess you are within your rights. Otherwise, what is the resolution process when issues such as these are raised? I'm not sure what the appropriate procedure is here, but this is important. Do we need to take it to the IESG, or can we solve it here? Scott -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/AJ4LMtIdhO0pgN4RAveBAJ4wSpwUiSuEtsHa3Pq5elHheXgrcwCfcNUG dCKuXtAfezc1ymlsteJ+Uo0= =yWxA -----END PGP SIGNATURE----- From owner-ipsec@lists.tislabs.com Mon Jun 30 15:10:45 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UMAiFK082374; Mon, 30 Jun 2003 15:10:45 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA08718 Mon, 30 Jun 2003 17:37:05 -0400 (EDT) Message-Id: <200306302137.h5ULbmcJ004413@coredump.cs.columbia.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "Scott G. Kelly" Cc: Tero Kivinen , Jesse Alpert , ipsec@lists.tislabs.com Subject: Re: IKEv2: active user identity protection In-reply-to: Your message of "Mon, 30 Jun 2003 13:31:08 PDT." <3F009E0C.5010109@airespace.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 30 Jun 2003 17:37:48 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk In message <3F009E0C.5010109@airespace.com>, "Scott G. Kelly" writes: > >I appreciate the desire to contain discussions, but let's be very clear >about this: this issue was raised as part of last call for IKEv2, and a >significant number of folks have offered support for the notion that >this is a significant shortcoming in the current spec. It is >inappropriate to simply quash the discussion because you don't like the >idea. > >If last call has degenerated to a symbolic gesture which is not intended >to really flush out final issues, then I guess you are within your >rights. Otherwise, what is the resolution process when issues such as >these are raised? I'm not sure what the appropriate procedure is here, >but this is important. Do we need to take it to the IESG, or can we >solve it here? There is, however, a need to avoid resurrecting the same issue over and over; Tero gave three URLs in the WG list archives that point back to the same topic (as Hugo raised it, first URL below). Given the lack of much discussion, Russ' comments (see second URL below, copied from Tero's message), and Ted and Barbara's decision (third URL) two months ago, it would seem to me that the issue is closed. I personally agree that active identity protection is important, but I think this discussion is going around in circles. I also like Tero's suggestion --- it's not perfect, but it's good enough for most purposes, and it won't block the IKEv2 document from moving forward. Cheers, -Angelos Hugo's original email: http://www.vpnc.org/ietf-ipsec/mail-archive/msg03639.html Area Directors comments: http://www.vpnc.org/ietf-ipsec/mail-archive/msg03653.html Working group chairs comments: http://www.vpnc.org/ietf-ipsec/mail-archive/msg03809.html From owner-ipsec@lists.tislabs.com Mon Jun 30 15:16:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UMGgFK082513; Mon, 30 Jun 2003 15:16:43 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA08756 Mon, 30 Jun 2003 17:39:30 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <3F00526A.3060705@creeksidenet.com> References: <5.2.0.9.0.20030626101831.00a96bb0@email> <3F00526A.3060705@creeksidenet.com> Date: Mon, 30 Jun 2003 17:39:09 -0400 To: "jpickering@creeksidenet.com" From: Stephen Kent Subject: Re: QoS selectors (was LAST CALL: IKE) Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 11:08 AM -0400 6/30/03, jpickering@creeksidenet.com wrote: >Re: multiple "redundant" SAs: >In order to support simultaneous rekey tie-breaking as currently >defined, one needs to be able to be able to determine >if the attempt to create a child is a rekey and if so, which SA is >being rekeyed. The only way to do this per current >version is to examine the traffic selectors which presumes no redundant SAs. > >- Jeff > Whoops! Any suggestions on how to avoid messing up the rekey heuristic and not negotiating the DiffServ values for SAs? Steve From owner-ipsec@lists.tislabs.com Mon Jun 30 15:23:16 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UMNFFK082640; Mon, 30 Jun 2003 15:23:15 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA08693 Mon, 30 Jun 2003 17:34:21 -0400 (EDT) Date: Tue, 1 Jul 2003 00:39:39 +0300 Message-Id: <200306302139.h5ULddZx004355@burp.tkv.asdf.org> From: Markku Savela To: kent@bbn.com CC: ipsec@lists.tislabs.com In-reply-to: (message from Stephen Kent on Mon, 30 Jun 2003 15:32:10 -0400) Subject: Re: IKE negotiation for fragmentation controls in IPsec References: <16122.55806.305977.986255@ryijy.hel.fi.ssh.com> <16128.25732.675945.766298@ryijy.hel.fi.ssh.com> <200306301913.h5UJD88P003320@burp.tkv.asdf.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Stephen Kent > IPsec has always been applied to fragments that arrive at an SG, or > in the case of IPv6, that are emitted by a host internally. > > >Previously SG had to assemble the packets before doing IPSEC. > > could you remind me of where we said that in 2401? Hmm.. I could have sworn it was said somewhere. But, I guess my mind is just playing tricks, by deducing that by implication: if you must implement port (or transport protocol in Ipv6) selector, you must assemble full packet anyway (at at least potentially buffer all fragments, because there have been systems that send fragments in reverse order even!) Concerning the change text... > By sending this notification the sender announces that it > will always fragment packets before encapsulating them to > the IPsec packets, i.e the recipient of this notification > MAY drop all fragmented IPSec packets, as they are not > generated by the other end. The last sentence may cause black hole. The sender cannot guarantee that some router on the way does not fragment IPSec packet, unless the above also implies that sender must set DF bit on IPv4 header? Right? Naturally, for IPv6 this is not the issue. As for DOS attacks with fragments, I don't see anything that relates directly to IPsec. All fragmentation attacks are just fragmentation attacts, regardless whether IPsec is present or not. The only issue that could be mentioned is: if framents are IPseced, a firewall doing something with fragments doesn't see them as fragments (both IPv4 and IPv6). From owner-ipsec@lists.tislabs.com Mon Jun 30 15:25:26 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UMPPFK082680; Mon, 30 Jun 2003 15:25:25 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA08933 Mon, 30 Jun 2003 17:49:46 -0400 (EDT) Mime-Version: 1.0 X-Sender: kent@po2.bbn.com Message-Id: In-Reply-To: <200306302139.h5ULddZx004355@burp.tkv.asdf.org> References: <16122.55806.305977.986255@ryijy.hel.fi.ssh.com> <16128.25732.675945.766298@ryijy.hel.fi.ssh.com> <200306301913.h5UJD88P003320@burp.tkv.asdf.org> <200306302139.h5ULddZx004355@burp.tkv.asdf.org> Date: Mon, 30 Jun 2003 17:51:25 -0400 To: Markku Savela From: Stephen Kent Subject: Re: IKE negotiation for fragmentation controls in IPsec Cc: ipsec@lists.tislabs.com Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.28 (www . roaringpenguin . com / mimedefang) Sender: owner-ipsec@lists.tislabs.com Precedence: bulk At 12:39 AM +0300 7/1/03, Markku Savela wrote: > > From: Stephen Kent > >> IPsec has always been applied to fragments that arrive at an SG, or >> in the case of IPv6, that are emitted by a host internally. >> >> >Previously SG had to assemble the packets before doing IPSEC. >> >> could you remind me of where we said that in 2401? > >Hmm.. I could have sworn it was said somewhere. But, I guess my mind >is just playing tricks, by deducing that by implication: if you must >implement port (or transport protocol in Ipv6) selector, you must >assemble full packet anyway (at at least potentially buffer all >fragments, because there have been systems that send fragments in >reverse order even!) In fairness, there are several cases. For transport mode, yes, we do require a BITS or BITW implementation to do reassembly. But for tunnel mode we don't, hence it is not a requirement for SGs. I should have been more precise in my comments. > >Concerning the change text... > >> By sending this notification the sender announces that it >> will always fragment packets before encapsulating them to >> the IPsec packets, i.e the recipient of this notification >> MAY drop all fragmented IPSec packets, as they are not >> generated by the other end. > >The last sentence may cause black hole. The sender cannot guarantee >that some router on the way does not fragment IPSec packet, unless the >above also implies that sender must set DF bit on IPv4 header? Right? right. that is part of what the sender must do too. >Naturally, for IPv6 this is not the issue. right again. >As for DOS attacks with fragments, I don't see anything that relates >directly to IPsec. All fragmentation attacks are just fragmentation >attacts, regardless whether IPsec is present or not. if we fragment after IPsec encapsulation, then ANYONE can send fragments that could cause the IPsec implementation trouble, and maybe adversely affect all subscribers behind the implementation. This is especially bad for an SG. if we fragment before encapsulation (but after doing the SPD checks), then we expose the stack behind the implementation to attacks, but only from the authorized peers they have elected to communicate with, as per the SPD entry for S/D IP addresses and protocol. Steve From owner-ipsec@lists.tislabs.com Mon Jun 30 15:26:43 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UMQgFK082711; Mon, 30 Jun 2003 15:26:43 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id RAA09037 Mon, 30 Jun 2003 17:55:53 -0400 (EDT) Message-Id: <200306302156.h5ULugcJ000553@coredump.cs.columbia.edu> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: ipsec@lists.tislabs.com Subject: IKEv2 and SCTP support Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 30 Jun 2003 17:56:42 -0400 From: "Angelos D. Keromytis" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk IKEv2 does not seem to currently support SCTP along the lines of the soon-to-be-issued RFC 3554 (which describes how to do SCTP support in IKEv1). Briefly, there are two issues: a) The traffic selectors must allow for a list of addresses to be associated with each endpoint. This is in fact supported by IKEv2. b) The IKE and IPsec SAs must be linked to all of the peer's remote addresses. This means that IKEv2 cannot just use the peer's IP address, but has to either extract all the addresses from the Traffic Selector or be told explicitly via the ID payload. IKEv1/SCTP used the latter approach, specifying the ID_LIST payload for including a list of IP addresses associated with the peer. I recommend that said payload be included in the IKEv2 draft, and the relevant language be copied from RFC 3554. Furthermore, per soon-to-be-issued RFC 3554, the receiver must verify that the peer actually owns the relevant addresses in the TS payload. This typically means that these addresses must be contained in the certificate contained in the CERT payload, or some policy/configuration mechanism be consulted. -Angelos From owner-ipsec@lists.tislabs.com Mon Jun 30 15:47:10 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h5UMl9FK083375; Mon, 30 Jun 2003 15:47:09 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id SAA09239 Mon, 30 Jun 2003 18:11:10 -0400 (EDT) Date: Tue, 1 Jul 2003 01:16:32 +0300 Message-Id: <200306302216.h5UMGWb9004806@burp.tkv.asdf.org> From: Markku Savela To: kent@bbn.com CC: ipsec@lists.tislabs.com In-reply-to: (message from Stephen Kent on Mon, 30 Jun 2003 17:51:25 -0400) Subject: Re: IKE negotiation for fragmentation controls in IPsec References: <16122.55806.305977.986255@ryijy.hel.fi.ssh.com> <16128.25732.675945.766298@ryijy.hel.fi.ssh.com> <200306301913.h5UJD88P003320@burp.tkv.asdf.org> <200306302139.h5ULddZx004355@burp.tkv.asdf.org> Sender: owner-ipsec@lists.tislabs.com Precedence: bulk > From: Stephen Kent > > if we fragment after IPsec encapsulation, then ANYONE can send > fragments that could cause the IPsec implementation trouble, You probably don't mean "trouble", such as crashing. Injecting a fake "fragment" would just make IPsec on the assembled packet fail the checks. This is the trouble you mean? Yes, that is a danger, fragmenting after IPsec makes it easier for the attacker to cause packets to be lost (dropped by IPsec). > if we fragment before encapsulation (but after doing the SPD checks), > then we expose the stack behind the implementation to attacks, but Ugh.. fragmenting before IPsec would be somewhat akward with "bump in stack" implementation (at least for me it would be rather major architectural change). However, as implementation never fragments TCP packets, only issue is with large UDP packets. Oh well.. From owner-ipsec@lists.tislabs.com Mon Jun 30 17:42:14 2003 Received: from lists.tislabs.com (portal.gw.tislabs.com [192.94.214.101]) by above.proper.com (8.12.9/8.12.8) with ESMTP id h610gDFK088136; Mon, 30 Jun 2003 17:42:13 -0700 (PDT) (envelope-from owner-ipsec@lists.tislabs.com) Received: by lists.tislabs.com (8.9.1/8.9.1) id UAA11042 Mon, 30 Jun 2003 20:01:42 -0400 (EDT) From: Black_David@emc.com Message-ID: <277DD60FB639D511AC0400B0D068B71E0564CE65@corpmx14.us.dg.com> To: kent@bbn.com Cc: ipsec@lists.tislabs.com Subject: RE: QoS selectors (was LAST CALL: IKE) Date: Mon, 30 Jun 2003 19:57:57 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-ipsec@lists.tislabs.com Precedence: bulk Steve, > At 11:08 AM -0400 6/30/03, jpickering@creeksidenet.com wrote: > >Re: multiple "redundant" SAs: > >In order to support simultaneous rekey tie-breaking as currently > >defined, one needs to be able to be able to determine > >if the attempt to create a child is a rekey and if so, which SA is > >being rekeyed. The only way to do this per current > >version is to examine the traffic selectors which presumes > no redundant SAs. > > Whoops! > > Any suggestions on how to avoid messing up the rekey heuristic and > not negotiating the DiffServ values for SAs? We've already concluded that the DiffServ values are functionally opaque to the other side from a traffic classification standpoint. OTOH, I'm concerned that if we pass them across IKE, someone's going to try to use them in a way that s/he shouldn't. So, let's go back to an old proposal from Radia: So I'd propose one more field in the traffic elector for "uniquifier". Alice can create ultiple child-SAs to Bob with the same raffic selectors, as long as they have different niquifiers. The uniquifier could be some sort of internal index or pointer; even a simple counter works. Another possibility if rekeying is really the only problem, would be to pass the other side's SPI as the "uniquifier" indicating exactly which SA is being rekeyed. If this is always done, the rekeying "heuristic" turns into a rule - when the "old SPI" is passed, this is a rekey of that SPI, otherwise it's a new SA creation. A minor downside is that if one fails to pass the "old SPI" on rekey, SAs that are no longer useful may accumulate on the peer, but the peer is already free to garbage collect SAs, and these will be good candidates as they will carry no further traffic. Thanks, --David ---------------------------------------------------- David L. Black, Senior Technologist EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_david@emc.com Mobile: +1 (978) 394-7754 ----------------------------------------------------